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
