OMG
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 11:24 PM > To: [email protected] > 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 > <[email protected]>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:[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 > > > > > > -- > 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
