Warning: This is another one of my "bitchy" messages complaining about things that people have been "getting along" with for many years. You have been warned, so please don't complain back to me if you think I'm concerned over nothing. Just don't read the rest of the message if this bothers you.
Some Cobol programmers know about the dreaded "status 97" issue. Essentially, if a KSDS is opened for I-O and the job is cancelled before the file is successfully closed then the next time the file is opened VSAM will do an implicit VERIFY. If the VERIFY succeeds then a file status of '97' (rather than '00') is returned to the Cobol program. From what I can tell from googling, if the file *is in fact damaged* then it will not return '97' but will rather return a different file status, one that indicates the file was not succesfully opened. I've not been able to recreate the latter situation, so I'm not sure what file status that would be. All this being said, the point is that this file status of 97 is the "same" as status 00, except that status 97 indicates that not only was the file opened successfully but an implicit VERIFY was also completed successfully. The question I have is, "why do I care?" Of what benefit is it for me, as a Cobol programmer, to know this information. Should I be doing something with it? Already on the syslog do we see messages such as this: IEC161I 056-084,VSAMIO,STEP00,FILE1,,,FJS.MYKSDS,FJS.MYKSDS.DATA, 744 IEC161I CATALOG.USERCAT.PPCAT IEC161I 056-084,VSAMIO,STEP00,FILE1,,,FJS.MYKSDS,FJS.MYKSDS.INDEX, 745 IEC161I CATALOG.USERCAT.PPCAT IEC161I 062-086,VSAMIO,STEP00,FILE1,,,FJS.MYKSDS,FJS.MYKSDS.DATA, 746 IEC161I CATALOG.USERCAT.PPCAT That's fine. But is there something I should be doing? I can't think of anything. So my question now is, why should status 97 even exist? The Cobol standard says that any file status with the first of the two characters being the character '0' was a successful I/O. According to the Cobol 2002 standard (I don't have the Cobol 85 standard available): "Certain classes of I-O status values indicate fatal exception conditions. These are: any that begin with the digit 3 or 4, and any that begin with the digit 9 that the implementor defines as fatal." So in this case IBM has chosen to make status '97' not only "not fatal", but in fact absolutely successful. I am unable to determine of the standard actually allows a '9' error to be considered successful, or if it should only be a non-fatal or fatal error. Anyway, the point(!) to all of this is I would like to make a requirement to IBM Enterprise Cobol to have an option to no longer set a file status of 97 when this occurs, but rather to set the file status to 00. While it would be nice to say that we simple handle 97 the same as 00, this is not the case. We are a VSE shop migrating to z/OS, and while '97' is documented as a possibility, I can't recall a time that we ever actually got one. I have tried doing things to cause it to occur on VSE (such as canceling and flushing the job) but it never occurs. In any case I dare say 90% of our programs do not "expect" a file status of 97. So since 97 doesn't seem to be useful I am trying to make sure it never occurs. Thus the requirement. In our testing we've already run in to it several times. Yes, I realize we "should" simply change the programs to conform to the IBM compiler. But my feeling is that it's the status 97 that does not "conform" to the Cobol standard, so Enterprise Cobol should, as an option at least, be made to conform, and thus eliminate our need to conform to a non-conforming implementation. (And even if status 97 does technically conform, it's still annoying. <g>) Any thoughts? It is interesting to note that at the assembler level this situation appears to *not* cause the OPEN macro to set R15 to something other than 0. The VSAM feedback code (ACBERFLG?) is set to 118 (X'76'), but that is it. R15 is set to 0. With Cobol, along with the FILE STATUS code of 97 I also get: VSAM return code 0008 VSAM function code 0000 VSAM feedback code 0076 This seems to say that VSAM set R15 to 8, but the assembler program I wrote to test this shows R15=0. (I am not an assembler programmer, so I could have screwed it up. I'd be glad to post it if anyone wants to validate it.) So is the Cobol runtime "making up" this VSAM return code of 8? Hmmm... What do assembler programs generally do? Do you assume if the open returned a 0 that you're good to go? Do you ever check ACBERFLG if the I/O was successful (R15=0)? I'd be fine with the "VSAM status" codes still being set (if the program has specified to receive them) as long as the primary status code is 00. (Yes, currently the VSAM status code field is "undefined" if the primary status code is set to 00. I don't see any good reason for this ether.) Anyone know how C and PL/I handle this situation? I have neither compiler available (and don't know PL/I even if I did!). OK. I'm prepared to either be 1) totally ignored, or 2) inundated with responses I don't agree with. Let's get it over with. :-) Frank >>> The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
