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:[email protected]] On > Behalf Of John McKown > Sent: Wednesday, September 11, 2013 10:16 PM > To: [email protected] > 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 < > [email protected]> 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:[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 > > > > > > -- > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
