Cut and paste, but only a small portion from a CompuWare CWMPMAIN COBOL listing. Didn't really clean it up properly. On Sep 11, 2013 5:58 PM, "Frank Swarbrick" <[email protected]> wrote:
> If you're still up for it... > > The program you've posted is not valid COBOL. Did you retype it? Or do > you have some sort of pre-processor that converts it to valid COBOL? Even > forgetting that, I don't see how this could possibly ever work. > XDF-RECORDV is an implicit redefines of XDF-RECORD. But in LINK-RECORD > they are concatenated. So I'm afraid it doesn't look like this is > "reality". > > Frank > > > > > > >________________________________ > > From: John McKown <[email protected]> > >To: [email protected] > >Sent: Wednesday, September 11, 2013 3:23 PM > >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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
