Cobol and VSAM I/O
in [Cobol]
|
Prev: COBOL versions Mainframe
Next: COBOL Trends
From: Anonymous on 1 Sep 2009 10:19 In article <4A9C0032.6F0F.0085.0(a)efirstbank.com>, Frank Swarbrick <Frank.Swarbrick(a)efirstbank.com> wrote: >Comments interspersed... Usually grumpiness interspersed between the interspersions. [snip] >From >http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg50/1.12.14. > >It then goes on to give a couple of options how to do this. It gives three >options, but recommends only two: > >1) Omit FILE STATUS clause and don't use DECLARATIVES. The program will >abend if there is an I/O error. [*] >3) Use the FILE STATUS clause *and* a DECLARATIVES error procedure. On >error set SORT-RETURN to 16 and then make sure that you check SORT-RETURN >after the sort statement to make sure is succeeded. [**] > >[*] This is how we've were doing it, but again its worth noting for the VSAM >file that an error on the open does *not* cause an abend. It's only the >error on the read that causes the abend. Which led me to my original >question. > >[**] This answers my other question. Don't do a GOBACK/STOP RUN (which was >what I had tried). Set SORT-RETURN and then check it. Standard Interview Question Number 564 from... oh, aways back when: 'What should you do after every OPEN, CLOSE, READ, WRITE or REWRITE?' 'Check the FILE-STATUS associated with the dataset involved in the action.' (The first time I was asked that I got this puzzled look on my face and used an ascending vocal inflection (indicating a question, usually) in my response... I could not believe someone was asking me what I thought was the equivalent of 'What do you do before leaving the lavatory?' 'Check to make sure one's zipper/buttons is/are shut'. The interviewer said this was the first time he'd heard anyone answer that question correctly on the first go.) I've worked on sites where knowledge of DECLARATIVES was minimal-to-nonexistent; I have never worked on a site where at least *familiarity* (if not the practise of using) FILE STATUS was equally alien. [snip] >I disagree. If there is a guarantee (as there seems to be for QSAM) that >I/O errors will always, when FILE STATUS is not present, cause an abend, why >should I not make use of this? Assuming any sort of guarantee in data processing is not, in my experience, a Very Good Idea. 'What does a programmer do when given an 80-character record?' 'Reserve ten characters for future use.' Checks for NUMERIC, ON SIZE, INVALID KEY/FILE STATUS... these are there for their reasons. Has anyone out there received A Guarantee from a Corner-Office Idiot (or, even worse... A Salesperson!) that 'this field will *never* be zero!' or 'There'll *always* a Master File record for any given Order File record'... and gotten the 2:am call when there ain't? > >What is easier to debug? This? >IGZ0200W A file attribute mismatch was detected. File FFND-MTCE-FILE-QSAM in >program SORTTST1 was defined as a > physical sequential file and the file specified in the ASSIGN >clause was a VSAM data set. >IGZ0035S There was an unsuccessful OPEN or CLOSE of file FFMNTFL2 in program >SORTTST1 at relative location X'0532'. > Neither FILE STATUS nor an ERROR declarative were specified. The >status code was 39. > From compile unit SORTTST1 at entry point SORTTST1 at statement 32 >at compile unit offset +00000532 at entry > offset +00000532 at address 0DC00532. > > >Or this? >Error opening file FFMNTFL2; status=39 > >I say the former. I say that it depends on who is doing the debugging. [snip] >Here is one more question. If using FILE STATUS checking does it ever make >sense to use the "AT END" and "INVALID KEY" clauses? If I don't use FILE >STATUS, or use it in conjunction with DECLARATIVES I might have something >like this: > >PERFORM UNTIL CTF-EOF > READ CARD-TYPE-FILE > AT END CONTINUE > NOT AT END > PERFORM 0200-CARD-TYPE-RECORD > END-READ >END-PERFORM > >(actually if the above doesn't use FILE STATUS at all then AT END would set >an EOF flag, but otherwise it's the same). Ow... been a few years but I'd say that if a FILE STATUS is coded for CARD-TYPE-FILE the AT END condition populates it with a 10. ]snip] >However I have seen this and think it's a bad mismash of the two: > >PERFORM UNTIL CTF-AT-END > READ CARD-TYPE-FILE > AT END > SET CTF-AT-END TO TRUE > END-READ > IF CTF-SUCCESSFUL > PERFORM 0200-CARD-TYPE-RECORD > ELSE > ...ERROR STUFF HERE... > END-IF >END-PERFORM > >I just made that example up, but I know I've seen something like it, and I >think it's pointless. You should use one method or the other, but not both. > Am I wrong? That depends on the criteria for 'right'. Consider the Ancient Scenario: PROCEDURE DIVISION. PERFORM 0000-HOUSEKEEPING THRU 0000-EXIT. PERFORM 5000-MAIN-LINE THRU 5000-EXIT UNTIL NO-MORE-INPUT. PERFORM 9000-EOJ THRU 9000-EXIT. GOBACK. .... 0000-HOUSEKEEPING. PERFORM 6000-READ-CARDFILE THRU 6000-EXIT. IF NO-MORE-INPUT (do stuff for empty dataset) GO TO 0000-EXIT. .... 6000-READ-CARDFILE. READ CARDFILE INTO WS-CARDREC AT END MOVE 'N' TO WS-MORECARDS-IND. ADD 1 TO CARDRECS-READ-CTR. 6000-EXIT. Now... I know this violates all the rules about periods/full-stops and inline performs and bunch of other stylistic stuff... .... and I my experience has also shown me that this kind of simple, 1977-era coding runs for decades and can be dealt with by the archetypical 2-year programmer. I am not against such newfangled fripperies as 'SET NO-MORE-INPUT TO TRUE', no... but I'm not about to go through a library of several thousand programs to change and test without the budget to do so, either, as the Bean Counters and the Users and everyone else have expressed annoyance at such things. (note - in the Really Oldene Dayse one was taught to always check for MORE-INPUT before NO-MORE-INPUT as the assumption was that... there was going to be more input and checking for the less-common condition was wasteful... every CPU-second costs money, y'know) DD
From: Howard Brazee on 1 Sep 2009 10:29 On Mon, 31 Aug 2009 16:54:10 -0600, "Frank Swarbrick" <Frank.Swarbrick(a)efirstbank.com> wrote: > >This one still bugs the heck out of me. I wonder what chance I'd have >getting a compile or run-time option (not sure which would be appropriate) >to eliminate the possibility of file status "97". Is there actually anyone >out there who both treats file status 97 as a successful open *and* does >something special when it is received (other than just treating it as of 00 >was received)? If no one is doing that, then what is even the point of its >existence? The point of its existence is to make life difficult for programmers. It has no redeeming value. -- "In no part of the constitution is more wisdom to be found, than in the clause which confides the question of war or peace to the legislature, and not to the executive department." - James Madison
From: Howard Brazee on 1 Sep 2009 10:31 On Mon, 31 Aug 2009 16:54:10 -0600, "Frank Swarbrick" <Frank.Swarbrick(a)efirstbank.com> wrote: >(actually if the above doesn't use FILE STATUS at all then AT END would set >an EOF flag, but otherwise it's the same). Where I use FILE STATUS, I don't use AT END nor declaratives. And I use FILE STATUS wherever I can. -- "In no part of the constitution is more wisdom to be found, than in the clause which confides the question of war or peace to the legislature, and not to the executive department." - James Madison
From: Howard Brazee on 1 Sep 2009 10:52
On Tue, 1 Sep 2009 14:19:46 +0000 (UTC), docdwarf(a)panix.com () wrote: >>[**] This answers my other question. Don't do a GOBACK/STOP RUN (which was >>what I had tried). Set SORT-RETURN and then check it. > >Standard Interview Question Number 564 from... oh, aways back when: > >'What should you do after every OPEN, CLOSE, READ, WRITE or REWRITE?' > >'Check the FILE-STATUS associated with the dataset involved in the >action.' While that has been automatic for decades, what I hadn't is checking SORT-RETURN. At least until I needed it once. >Checks for NUMERIC, ON SIZE, INVALID KEY/FILE STATUS... these are there >for their reasons. Has anyone out there received A Guarantee from a >Corner-Office Idiot (or, even worse... A Salesperson!) that 'this field >will *never* be zero!' or 'There'll *always* a Master File record for any >given Order File record'... and gotten the 2:am call when there ain't? Sometimes programmers just assume. Coding SSAN as PIC 9(09) DISPLAY never made sense, and these days packed-decimal or binary has lost its advantage. And requiring Zip codes to be numeric is US centric (and might someday be changed). It's easy to see such with Web pages when they won't accept 9 digit zip codes, with or without dashes, require phone numbers to be of particular formats, etc. -- "In no part of the constitution is more wisdom to be found, than in the clause which confides the question of war or peace to the legislature, and not to the executive department." - James Madison |