If you're still up for it... The program you've posted is not valid COBOL. Did you retype it? Or do you have some sort of pre-processor that converts it to valid COBOL? Even forgetting that, I don't see how this could possibly ever work. XDF-RECORDV is an implicit redefines of XDF-RECORD. But in LINK-RECORD they are concatenated. So I'm afraid it doesn't look like this is "reality".
Frank >________________________________ > From: John McKown <john.archie.mck...@gmail.com> >To: IBM-MAIN@LISTSERV.UA.EDU >Sent: Wednesday, September 11, 2013 3:23 PM >Subject: Re: COBOL "problem" (not really), but sort of. > > >I have now studied the program source. Let's just drop this discussion >because the program is junk. > >FD XDF-FILE. > >01 XDF-RECORD >02 XDF-REC-LNG S9(5) COMP +400 >02 FILLER X(04) SPACES >02 XDF-KEY X(16) MP05356899M00 >01 XDF-RECORDV >02 XDF-DATA OCCURS 00 TO 12040 > DEPENDING ON XDF-REC-LNG. > > >WORKING-STORAGE SECTION. >01 WSV-WORK-VARIABLES >02 WSV-X1 9(2). >02 WSV-REC-LNG S9(5) COMP. > >LINKAGE-SECTION. >01 MSSXDFIO-LINKAGE >02 MSSXDFIO-FILE X(01) A > 88 MSSXDFIO-FILE-ACTV 'A' > 88 MSSXDFIO-FILE-ARCH 'R' >02 MSSXDFIO-RC X(02) 00 >01 LINK-RECORD >02 LINK-REC-LNG S9(5) COMP +400 >02 FILLER X(04) SPACES >02 LINK-KEY X(16) MP05356899M00 >02 LINK-DATAX > 03 LINK-DATA OCCURS 00 TO 13000 > DEPENDING ON WSV-REC-LNG > >PROCEDURE DIVISION USING MSSXDFIO-LINKAGE LINK-RECORD. > >MOVE LINK-REC-LNG TO WSV-REC-LEN. >READ FILE INTO LINK-RECORD. > >In the dump, WSV-REC-LEN at the time of the S0C4-4 is +1077952576! What the >programmer expected was that the READ would read the logical record into >the FD area (true). And then MOVE however much was just READ into >LINK-RECORD, apparently with NO regard to the value of WSV-REC-LEN at the >time of the copy. This is just poor coding. And he doesn't want to change >it to be proper. The values in the FD area are correct after the READ. But >he doesn't want to do a MOVE after the READ. I don't know why. I don't >think he really understands how COBOL does things. And he is not a >youngster. > > >I am now on vacation for 4 days. Thanks to all. > > > > > >On Wed, Sep 11, 2013 at 3:39 PM, Thomas Berg <thomas.b...@swedbank.se>wrote: > >> I thought the length field was in LINKAGE SECTION given by the caller ? >> >> >> >> Best Regards >> Thomas Berg >> ___________________________________________________________________ >> Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) >> >> >> >> >> > -----Original Message----- >> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> > Behalf Of John McKown >> > Sent: Wednesday, September 11, 2013 10:16 PM >> > To: IBM-MAIN@LISTSERV.UA.EDU >> > Subject: Re: COBOL "problem" (not really), but sort of. >> > >> > Well explained. I will keep this to show him when this next abends. It >> > is a problem just waiting for a critical month end to come around. >> > >> > >> > On Wed, Sep 11, 2013 at 3:11 PM, Farley, Peter x23353 < >> > peter.far...@broadridge.com> wrote: >> > >> > > If I am not misremembering, Mr. Robert Heinlein's character Lazurus >> > > Long >> > > said: "Ignorance is curable, only stupidity is fatal." >> > > >> > > Second, let's try one more time to penetrate the thick cranial >> > > boundary in question (not yours): >> > > >> > > IF the FILE definition looks like this: >> > > >> > > FD IN-FILE ... . >> > > 01 FILE-RECORD. >> > > 05 FILE-REC-LEN PIC S9(5) COMP. >> > > 05 FILE-REC-DATA OCCURS 1 TO 32760 >> > > DEPENDING ON FILE-REC-LEN >> > > PIC X. >> > > >> > > And the working-storage area looks like this: >> > > >> > > 01 WORK-RECORD. >> > > 05 WORK-REC-LEN PIC S9(5) COMP. >> > > 05 WORK-REC-DATA OCCURS 1 TO 32760 >> > > DEPENDING ON FILE-REC-LEN >> > > PIC X. >> > > >> > > Then the process will work BUT ONLY AS THREE SEPARATE STATEMENTS: >> > > >> > > READ IN-FILE >> > > AT END (do endfile processing) >> > > NOT AT END >> > > MOVE FILE-REC-LEN TO WORK-REC-LEN. >> > > MOVE FILE-RECORD TO WORK-RECORD. >> > > END-READ >> > > >> > > The reason that it does not work with READ INTO is that the >> > > occurs-depending-on variable IS NOT YET KNOWN BEFORE THE READ for the >> > > working-storage record area. The MOVE is done at the 01 LEVEL, and in >> > > this case the TO-occurs-depending-on-variable must be set BEFORE the >> > > MOVE begins. READ does not do that for you; it never did and never >> > will. >> > > >> > > You might ask him how he thinks the READ is supposed to knows what the >> > > correct value for the OTHER occurs-depending-on-variable is supposed >> > to be? >> > > Especially if it is passed in as a LINKAGE SECTION item, the program >> > > containing the READ CANNOT KNOW what that value is at the present >> > > time, NOR what its current value is. Rules of MOVE mean that the >> > > value must be set BEFORE THE MOVE BEGINS. READ does not and will not >> > do it for you. >> > > >> > > If that doesn't make it all the way through the dense bony material >> > > with which you are dealing, then I guess your answer is best: ignore >> > the results. >> > > >> > > Good luck. >> > > >> > > Peter >> > > >> > > -----Original Message----- >> > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> > > On Behalf Of John McKown >> > > Sent: Wednesday, September 11, 2013 2:27 PM >> > > To: IBM-MAIN@LISTSERV.UA.EDU >> > > Subject: Re: COBOL "problem" (not really), but sort of. >> > > >> > > What you said was basically what I told the programmer to do. What he >> > > really wants is for the READ .... INTO to do is to read in the record >> > > "somewhere" (i.e. the I/O buffer). The ODO value is within the record >> > > itself. So he was wanting COBOL to effectively do a MOVE of the ODO >> > > variable, then do the rest of the MOVE dependent on the just updated >> > > value of the ODO variable. Like a "two stage" move. I told him that I >> > > didn't think COBOL would do it that way, but he basically insisted >> > > that it was what he wanted and was going to get or die (ABEND) trying. >> > > I don't know why he doesn't just READ without the INTO and then MOVE >> > > from the 01 in the FD to the 01 in the LINKAGE SECTION (sorry, said >> > > WORKING STORAGE in previous posts). He just doesn't want to. I have >> > > noted the program name and will just shrug if/when it starts abending >> > in production (if it gets that far). >> > > >> > > >> > > On Wed, Sep 11, 2013 at 1:13 PM, Joel C. Ewing <jcew...@acm.org> >> > wrote: >> > > >> > > > On 09/11/2013 12:02 PM, John McKown wrote: >> > > > > A programmer came by today with a problem. He is sometimes getting >> > > > > a >> > > > S0C4-4 >> > > > > abend in a COBOL program. This is a subroutine. One of the >> > > > > parameters passed in is a data area, which can be of various >> > > > > lengths. It is >> > > defined >> > > > > with an OCCURS DEPENDING ON with a data element within the area. >> > I.e. >> > > the >> > > > > first 05 level is PIC S9(5) COMP. The subroutine does a READ of a >> > > > > data >> > > > set >> > > > > into this area. This is where the abend occurs. The reason is >> > > > > because >> > > the >> > > > > OCCURS DEPENDING ON maximum size is significantly larger than what >> > > > > the caller is passing it. And the READ to the 01 is trying to pad >> > > > > the >> > > entire >> > > > > possible 01 level with blanks. >> > > > > >> > > > > The problem is how do I describe this to a COBOL programmer who >> > > > > just doesn't "get it". He expects COBOL to _not_ pad the "non >> > existent" >> > > > > occurrences with blanks. And, if fact, to not even reference this >> > > > > area wherein they would have resided, had they existed. I'm just >> > > > > get "deer >> > > in >> > > > > headlights" looks. I'm not using the correct words, somehow. >> > > > > >> > > > >> > > > Presumably the "area" in question is the target of INTO as in >> > "READ... >> > > > INTO area". >> > > > >> > > > The manuals say data movement for READ to the INTO "area" is >> > > > governed by the rules for "MOVE", and the semantics for MOVE says >> > > > any length evaluation of the receiving field is determined just >> > > > "before" any data is moved. Is the DEPENDING ON variable in the >> > > > receiving group item initialized to the proper expected value or to >> > > > the maximum acceptable value that the calling program can accept >> > prior to the READ? >> > > > >> > > > The way I read the manuals, the implicit MOVE of the READ >> > > > instruction will replace the DEPENDING ON value in the receiving >> > > > structure, so afterwards it should reflect the actual number of >> > > > occurrences present, but the length of the MOVE and any padding of >> > > > the receiving field as part of that MOVE will be based on contents >> > > > of the receiving field's DEPENDING ON variable prior to the move. >> > > > >> > > > If the programmer is expecting COBOL to *assume* that the length of >> > > > the receiving field is the length of the source field (in this case, >> > > > the record just read), the manuals seem to explicitly indicate that >> > > > is not the way things work. >> > > > >> > > > If my understanding is correct, a more efficient way to avoid >> > > > unnecessary padding would be to do a READ without "INTO", then set >> > > > the DEPENDING ON value in the receiving area to minimum of max count >> > > > space supplied by caller and the DEPENDING ON value in the actual >> > > > record read, and finally MOVE the file record to the receiving area. >> > > > >> > > > -- >> > > > Joel C. Ewing, Bentonville, AR jcew...@acm.org >> > > > >> > > > -------------------------------------------------------------------- >> > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, >> > > > send email to lists...@listserv.ua.edu with the message: INFO >> > > > IBM-MAIN >> > > > >> > > >> > > >> > > >> > > -- >> > > As of next week, passwords will be entered in Morse code. >> > > >> > > Maranatha! <>< >> > > John McKown >> > > >> > > ---------------------------------------------------------------------- >> > > For IBM-MAIN subscribe / signoff / archive access instructions, send >> > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > > >> > > This message and any attachments are intended only for the use of the >> > > addressee and may contain information that is privileged and >> > confidential. >> > > If the reader of the message is not the intended recipient or an >> > > authorized representative of the intended recipient, you are hereby >> > > notified that any dissemination of this communication is strictly >> > > prohibited. If you have received this communication in error, please >> > > notify us immediately by e-mail and delete the message and any >> > attachments from your system. >> > > >> > > ---------------------------------------------------------------------- >> > > For IBM-MAIN subscribe / signoff / archive access instructions, send >> > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > > >> > >> > >> > >> > -- >> > As of next week, passwords will be entered in Morse code. >> > >> > Maranatha! <>< >> > John McKown >> > >> > ---------------------------------------------------------------------- >> > For IBM-MAIN subscribe / signoff / archive access instructions, send >> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > > > >-- >As of next week, passwords will be entered in Morse code. > >Maranatha! <>< >John McKown > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
