-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Michael G Phillips
Sent: Saturday, September 28, 2013 8:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL problem (not really), but sort of.
Thanks. I'll point him to it. He
Michael G Phillips wrote:
Thanks. I'll point him to it. He has already, somewhat jokingly, said fix
it! But COBOL doesn't have the DWIW (Do What I Want) verb.
I'm still waiting for the DWIT (Do What I'm Thinking) and RAE (Remove All
Errors) instructions... ;-)
Add this action: WF (Wait
Thanks. I'll point him to it. He has already, somewhat jokingly, said fix
it! But COBOL doesn't have the DWIW (Do What I Want) verb.
I'm still waiting for the DWIT (Do What I'm Thinking) and
RAE (Remove All Errors) instructions... ;-)
-MAIN@LISTSERV.UA.EDU
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
John McKown wrote:
OP here. I guess I shouldn' t post while ticked off at someone. Apologies.
Not me, I would just be 'p*ssed off!' ;-)
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
John McKown writes:
But COBOL doesn't have the DWIW (Do What I Want) verb.
We're working on it. :-)
Just be patient and keep smiling, John. You'll get there. Perhaps (as
another idea) there's already a bit of working, tested, efficient code in
house that implements substantially the same
On 09/12/2013 01:33 AM, Timothy Sipples wrote:
John McKown writes:
But COBOL doesn't have the DWIW (Do What I Want) verb.
We're working on it. :-)
Just be patient and keep smiling, John. You'll get there. Perhaps (as
another idea) there's already a bit of working, tested, efficient code
, 2013 7:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
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
-MAIN@LISTSERV.UA.EDU] On
Behalf Of John McKown
Sent: Wednesday, September 11, 2013 7:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
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
: 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
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
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 7:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: COBOL problem (not really), but sort
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
: Wednesday, September 11, 2013 11:02 AM
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
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
How about not making this about padding. My guess would be that cobol clears
the storage before the read instead of padding storage after the read. I would
telling the programmer:
Before a READ INTO, the storage is cleared with nulls. The size of the area to
be cleared is set by his program in
@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
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
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
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL problem (not really), but sort of.
I'm not sure if I'm understanding this 100% correctly, but take a look at this:
identification division.
program-id. vlen.
environment division.
input-output section.
file-control.
select vlen-file
] 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
, 2013 2:11 PM
Subject: Re: COBOL problem (not really), but sort of.
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
I agree.
From: Farley, Peter x23353 peter.far...@broadridge.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, September 11, 2013 3:02 PM
Subject: Re: COBOL problem (not really), but sort of.
That will work, but I can't tell from John's original post
] 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
-
From: IBM Mainframe Discussion List
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown
Sent: Wednesday, September 11, 2013 7:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: COBOL problem (not really), but sort of.
A programmer came by today with a problem. He is sometimes getting
-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL problem (not really), but sort of.
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
From: John McKown john.archie.mck...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU
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
, September 11, 2013 5:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
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
, September 11, 2013 5:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
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
29 matches
Mail list logo
