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 <thomas.b...@swedbank.se>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:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of John McKown
> > Sent: Wednesday, September 11, 2013 10:16 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > 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 <
> > peter.far...@broadridge.com> 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:IBM-MAIN@LISTSERV.UA.EDU]
> > > On Behalf Of John McKown
> > > Sent: Wednesday, September 11, 2013 2:27 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > 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 <jcew...@acm.org>
> > 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 jcew...@acm.org
> > > >
> > > > --------------------------------------------------------------------
> > > > -- For IBM-MAIN subscribe / signoff / archive access instructions,
> > > > send email to lists...@listserv.ua.edu 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 lists...@listserv.ua.edu 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 lists...@listserv.ua.edu 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
