That will work, but I can't tell from John's original post if in his case the occurs-depending on AND the "record varying" data names are the same. The fact that they are all the same in your example is what makes it work.
If all the "depending on" parts are the same name, your technique will certainly work, even if the "vlen-record" is in the LINKAGE section. The key is to make all of them use the same name. Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Wednesday, September 11, 2013 4:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL "problem" (not really), but sort of. I'm not sure if I'm understanding this 100% correctly, but take a look at this: identification division. program-id. vlen. environment division. input-output section. file-control. select vlen-file assign to vlenfl. data division. file section. fd vlen-file record varying depending on vlen-len. 01 vlen-buffer. 05 pic x occurs 1 to 252 depending on vlen-len. working-storage section. 01 at-end-sw pic x value 'N'. 88 at-end value 'Y'. 01 vlen-record. 05 vlen-len pic 9(4) comp-5. 05 vlen-data. 10 pic x occurs 1 to 32760 depending on vlen-len. linkage section. procedure division. open input vlen-file perform until at-end * move zero to vlen-len read vlen-file into vlen-data at end set at-end to true not at end display vlen-len display vlen-data end-read end-perform close vlen-file goback. It appears to me to work (even if the "move zero to vlen-len" statement is uncommented). I believe that the key here is the "record varying depending on vlen-len". I haven't looked at the generated code, but my guess is that this generates code that first moves the actual length red into vlen-len and then moves the data from the buffer into vlen-data, but only for a length of vlen-len. Obviously in the case of the original example the vlen-record area is being passed in via the linkage section. But that should not matter, as long as its big enough to hold the largest possible record size in the file. Frank >________________________________ > From: "Farley, Peter x23353" <peter.far...@broadridge.com> >To: IBM-MAIN@LISTSERV.UA.EDU >Sent: Wednesday, September 11, 2013 2:11 PM >Subject: Re: COBOL "problem" (not really), but sort of. > > >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 > > ---------------------------------------------------------------------- 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
