I agree.
>________________________________ > From: "Farley, Peter x23353" <[email protected]> >To: [email protected] >Sent: Wednesday, September 11, 2013 3:02 PM >Subject: Re: COBOL "problem" (not really), but sort of. > > >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:[email protected]] On >Behalf Of Frank Swarbrick >Sent: Wednesday, September 11, 2013 4:50 PM >To: [email protected] >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" <[email protected]> >>To: [email protected] >>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:[email protected]] On >>Behalf Of John McKown >>Sent: Wednesday, September 11, 2013 2:27 PM >>To: [email protected] >>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 <[email protected]> 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 [email protected] >>> >>> ---------------------------------------------------------------------- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to [email protected] 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 [email protected] 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 [email protected] with the message: INFO IBM-MAIN >> >> > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] 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 [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
