From: SMTP%"MACRO32%WKUVX1.BITNET@uu7.psi.com" 26-MAY-1993 08:27:27.14 To: EVERHART CC: Subj: Re: "optional" efn and iosb arguments X-Listname: "VMS Internals, MACRO, & BLISS Discussions" Warnings-To: <> Errors-To: MacroMan%WKUVX1.BITNET@uu7.psi.com Sender: MacroMan%WKUVX1.BITNET@uu7.psi.com X-Newsgroups: vmsnet.internals Subject: Re: "optional" efn and iosb arguments Message-Id: <1993May26.201229.2296@zl2tnm.gen.nz> From: don@zl2tnm.gen.nz Reply-To: MACRO32%WKUVX1.BITNET@uu7.psi.com Date: 26 May 93 20:12:29 +1300 Distribution: world Organization: The Wolery Lines: 95 To: MACRO32@WKUVX1.BITNET X-Gateway-Source-Info: USENET In article <1993May25.085020.2058@cmkrnl.com>, jeh@cmkrnl.com writes: > In article <1993May25.201653.2295@zl2tnm.gen.nz>, don@zl2tnm.gen.nz writes: >> IF YOU DO NOT SPECIFY AN IOSB [on $QIOW] YOU DO NOT KNOW IF THE >> I/O HAS COMPLETED SUCCESSFULLY (OR AT ALL). > That depends. If your code uses NO asynchronous operations then it MUST be > your $QIOW completion that set the flag, since there won't be any other > $QIOW's or other event-flag-setting requests pending. Can you *absolutely* *guarantee* that the code (a) won't be run with some hack or other setting EFNs in exec mode, and (b) that the code won't be lifted out and used somewhere where there are asynchronous operations? If not, put the IOSB in and check its status *now* and save yourself several kinds of grief later. Fine for baby programs. But even baby programs grow up to be big programs sometimes. That unprotected $QIOW can leap out of the woodwork and bite you (particularly if it's a read). >> There are various bits of code around that do things in exec mode >> independently of the rest of the process that may set event flags >> when you least expect it. > I don't think that anything in RMS runs "independently of the rest of the > process" unless you've asked it to via the ASY option. Even when it does run, I was talking about some of the hacks that float about to do things like update prompts, change window titles on DECwindows screens & so-on. OK, they're not standard VMS, but why take risks? > a good idea! But if you have no "no-wait" system service calls you can > get away without them. Provided you don't care about I/O completion status. You _should_ care about completetion status. Not caring about completion status is generally bad programming, in all but a very tiny number of cases. Personally, if I'm writing stuff that uses $QIO[W] and friends that doesn't use asynch calls, I just keep one iosb around and re-use it. I also make a habit if checking the IOSB. Hell, it's usually only one more line of code (even in MACRO!). > When the manual says "optional argument" it means "the service will not > consider the arguments invalid if they are 0, passed by value". By that test, > efn and iosb really are "optional" for $QIOW. And even for $QIO. That _wasn't_ the point. When you depend on software to be reliable, such hair-splitting is irrelevant. Henry Spencer says it better than I: The Ten Commandments for C Programmers (Annotated Edition) Henry Spencer [...] 6 If a function be advertised to return an error code in the event of difficulties, thou shalt check for that code, yea, even though the checks triple the size of thy code and produce aches in thy typing fingers, for if thou thinkest ``it cannot happen to me'', the gods shall surely punish thee for thy arrogance. All true believers doth wish for a better error-handling mechanism, for explicit checks of return codes are tiresome in the extreme and the temptation to omit them is great. But until the far-off day of deliverance cometh, one must walk the long and winding road with patience and care, for thy Vendor, thy Machine, and thy Software delight in surprises and think nothing of producing subtly mean- ingless results on the day before thy Thesis Oral or thy Big Pitch To The Client. Occasionally, as with the ferror() feature of stdio, it is possible to defer error checking until the end when a cumulative result can be tested, and this often produceth code which is shorter and clearer. Also, even the most zealous beli- ever should exercise some judgement when dealing with functions whose failure is totally uninteresting... but beware, for the cast to void is a two-edged sword that sheddeth thine own blood without remorse. 'nuff said. 8-) Don Stokes, CSC Network Manager, Victoria University of Wellington, New Zealand Ph+64 4 495-5052 Fax+64 4 471-5386 Work:don@vuw.ac.nz Home:don@zl2tnm.gen.nz