From: Howard Brazee on 23 Jun 2008 11:28 On Sat, 21 Jun 2008 08:00:46 GMT, Arnold Trembley <arnold.trembley(a)worldnet.att.net> wrote: >You might also try changing the READ statement as follows, to see if >it has any effect on the behavior of the program: > >READ DSCCQNMN-FILE > INVALID KEY CONTINUE >END-READ > >Do NOT add a period after the END-READ keyword. Why are you so adamant about not having a period here? >The reason I suggest this is that I seem to recall there may be >problems with omitting the INVALID KEY clause on a random read to a >KSDS VSAM file. What does that do?
From: Michael Mattias on 23 Jun 2008 11:50 >>The reason I suggest this is that I seem to recall there may be >>problems with omitting the INVALID KEY clause on a random read to a >>KSDS VSAM file. IIRC, there's a problem with not including an INVALID KEY clause on any kind of read of an indexed file unless a USE procedure is in effect. ie... READ indexed_file_name IF INVALID KEY clause present, control transferred to INVALID KEY statements If no INVALID KEY clause present, the USE procedure is invoked I forgot what happens if neither is present.. maybe just FILE-STATUS is updated? But of there is no FILE-STATUS defined, I have to believe it's a fatal program error. (Whatever it is, it's certainly silly to have 'none of the above'). MCM
From: Howard Brazee on 23 Jun 2008 12:41 On Mon, 23 Jun 2008 10:50:00 -0500, "Michael Mattias" <mmattias(a)talsystems.com> wrote: >I forgot what happens if neither is present.. maybe just FILE-STATUS is >updated? But of there is no FILE-STATUS defined, I have to believe it's a >fatal program error. (Whatever it is, it's certainly silly to have 'none of >the above'). I always write my programs with FILE-STATUS. But I'm the only one in this IBM shop who does.
From: Robert on 23 Jun 2008 13:33 On Sun, 22 Jun 2008 23:09:05 -0700 (PDT), vbarathee(a)gmail.com wrote: Ws-first-read will never be set, due to missing period. > OPEN INPUT MQFORM-FILE > > IF SUCCESSFUL-IO > NEXT SENTENCE > ELSE > MOVE ERROR-OPENING-INPUT-FILE TO ERROR-MESSAGE > MOVE WS-MQFORM-STATUS TO WS-RETURN-CODE > SET WS-ERROR-FOUND TO TRUE > PERFORM 9100-PROCESS-ERROR THRU 9100-EXIT > GO TO 2000-EXIT > END-IF > >* >*C READS FIRST RECORD ... >* > SET WS-FIRST-RECORD > TO TRUE. > > PERFORM 4400-READ-INPUT THRU 4400-EXIT. >* You don't need it. Rewrite this: > READ MQFORM-FILE. > IF SUCCESSFUL-IO > MOVE WS-LIT-NO TO WS-FIRST-READ-FLAG > ADD 1 TO WS-CNT > ELSE > IF END-OF-FILE > SET WS-EOF TO TRUE > IF WS-FIRST-RECORD > MOVE ERROR-EMPTY-INPUT-FILE TO ERROR-MESSAGE > MOVE WS-MQFORM-STATUS TO WS-RETURN-CODE > PERFORM 9100-PROCESS-ERROR THRU 9100-EXIT > END-IF > ELSE > SET WS-ERROR-FOUND TO TRUE > MOVE ERROR-READING-INPUT-FILE TO ERROR-MESSAGE > MOVE WS-MQFORM-STATUS TO WS-RETURN-CODE > PERFORM 9100-PROCESS-ERROR THRU 9100-EXIT > END-IF. READ MQFORM-FILE. IF SUCCESSFUL-IO ADD 1 TO WS-CNT ELSE IF END-OF-FILE SET WS-EOF TO TRUE IF WS-CNT EQUAL TO ZERO ....
From: Arnold Trembley on 24 Jun 2008 03:25
Howard Brazee wrote: > On Sat, 21 Jun 2008 08:00:46 GMT, Arnold Trembley > <arnold.trembley(a)worldnet.att.net> wrote: > >> You might also try changing the READ statement as follows, to see if >> it has any effect on the behavior of the program: >> >> READ DSCCQNMN-FILE >> INVALID KEY CONTINUE >> END-READ >> >> Do NOT add a period after the END-READ keyword. > > Why are you so adamant about not having a period here? Because I read the source example too quickly. I missed the fact that the END-IF's were not correctly aligned with the IF's and assumed the READ was within a larger IF. A period will not cause any problem. > >> The reason I suggest this is that I seem to recall there may be >> problems with omitting the INVALID KEY clause on a random read to a >> KSDS VSAM file. > > What does that do? There may be no difference at all. Michael Matthias made the best case for this, and it would be an easy test to do. I had a theory that the lack of an INVALID KEY clause might result in the Operating System intercepting a "not found" condition (file status 23) and causing the abend. My theory is probably wrong. I am inclined to agree with DocDwarf that there is some problem with the ILBOWAT0. It's likely that WS-SECONDS-TO-WAIT is now above the line, and the ILBOWAT0 actually executed is AMODE(24), RMODE(24), and unable to deal with AMODE(31) addresses, which should certainly cause an addressing exception like a S0C4. If the original poster would try commenting out the CALL to ILBOWAT0 and testing again we might find out if that is the problem. If ILBOWAT0 is the problem, then the original poster will have to find another way to force a wait, perhaps Doc would be willing to contract to write a 31-bit compatible WAIT subroutine. If ILBOWAT0 is not the problem, then something must be wrong with the KSDS VSAM file that has been added to the program. I am very curious as to what the real problem is, and there's only so much I can do to diagnose this remotely. -- http://arnold.trembley.home.att.net/ |