OP here. I guess I shouldn' t post while "ticked off" at someone. Apologies. The real "problem" is that I simply was not able to explain to the programmer __in terms that made sense to a COBOL programmer__ what was happening. His concept of READ ... INTO was that the READ was reading _directly_ INTO the receiving area. I have now learned, from this discussion, that the way that a COBOL programmer would say it is that the READ ... INTO is simply a shortcut way of saying READ FILE followed by a MOVE FD TO 01 statement. And that is why it works sometimes and S0C4-4's other times. I would guess that if the programmer made the ODO variable be the name of the variable in the FD which does contain the correct value, that it would work as he wants every time. I don't know why he put the ODO variable into a WORKING STORAGE variable. I am, and think like, an HLASM programmer. So my explanations sometimes are in the correct "dialect" when I talk to COBOL-only people.
Again, many thanks to all. I'll try to explain to him when I get back from vacation on Monday. On Thu, Sep 12, 2013 at 7:20 PM, Clark Morris <[email protected]>wrote: > On 11 Sep 2013 10:21:17 -0700, in bit.listserv.ibm-main you wrote: > > >I can try that. The programmer says that he intents to define the passed > in > >area in the calling program at the front of his WORKING-STORAGE so that > the > >area is larger. I.e. it is _planning_ on a buffer overflow and _hoping_ > >that it doesn't affect the calling program. I don't have authority to > >disallow this. And we don't do any kind of peer review because we just > >don't have the people left. > > > In the sub-routine change the READ ... INTO to a READ followed by a > MOVE of the record just read and some value if AT END is reached. > > Clark Morris > > > >On Wed, Sep 11, 2013 at 12:09 PM, Thomas Berg <[email protected] > >wrote: > > > >> I would say: the READ .. INTO .. statement doesn't look at the numerical > >> value in the length field, it only looks at the max possible length as > >> defined. And acts accordingly. > >> > >> > >> > >> 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 7:02 PM > >> > To: [email protected] > >> > Subject: COBOL "problem" (not really), but sort of. > >> > > >> > 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. > >> > > >> > -- > >> > 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 > -- 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
