When we started 5.1 migration, we obtained the Local-variables CEEDUMP for
batch but not for CICS. I remember opened a PMR and the issue was the lack of
SYS1.CCSLIB in RPL concatenation.
Check it in LNKLST & RPL.
Regards, salva.
> URL to the APAR please? Google cannot find it.
Sorry, could not find it myself from home right before posting. Was looking it
up from the PMR. Will check from the office tomorrow and post.
--
Peter Hunkeler
--
For
COBOL5 and CEEDUMP
>Anyway, TEST is much improved with COBOL V5/V6, we put the Debug data
>in a NOLOAD class segment in the Program Object, so that it is always
>available, always in sync with the load, and never takes up memory at runtime
>unless it is needed. An example of when
>Anyway, TEST is much improved with COBOL V5/V6, we put the Debug data in a
NOLOAD class segment in the Program Object, so that it is always available,
always in sync with the load, and never takes up memory at runtime unless
it is needed. An example of when it is needed is when a CEEDUMP is
>A further question: the CEEDUMP we receive in COBOL 5 lacks a dump of the
>WORKING STORAGE SECTION. Can this be remedied by changing compile-time or
>run-time parameters?
I know this is old, not sure if it got answered or not...
To get WORKING-STORAGE (and LOCAL-STORAGE) date items listed in
age-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Thursday, January 26, 2017 8:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: A further question regarding COBOL5 and CEEDUMP
>
> It would help to know wha
t; To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: A further question regarding COBOL5 and CEEDUMP
>
> A further question: the CEEDUMP we receive in COBOL 5 lacks a dump of the
> WORKING STORAGE SECTION. Can this be remedied by changing compile-time or
> run-time parameters?
>
> Please advis
wrote:
> Are there any whizzes out there who specialize in reading and deciphering
> CEEDUMPs?
> I have a question for you. In a COBOL5 CEEDUMP, how do I locate the
> *index* of an array (i.e., an array that is defined with "indexed by") in
> the dump?
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Peter Hunkeler
> Sent: Tuesday, January 10, 2017 11:58 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COBOL5 and ceedump
>
>
> >> And as for the
>> And as for the "standard way" to cheat the Cobol table restriction (I'm no
--
Peter Hunkeler
>> Cobol programmer, sorry): Cheating is cheating. Shudder But it explains
>> at
>> least why IBM agreed to change the code. Thanks.
>>
>
>Not cheating, accomplishing a business need despite
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Peter Hunkeler
> Sent: Tuesday, January 10, 2017 2:28 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: AW: Re: COBOL5 and ceedump
>
>
> >A frequent,
Last I heard, SSRANGE was deprecated for production use due to high overhean.
Yes, a deliberate area left specifically to catch any overflow and for no other
purpose, similar to a patch-area.
Technique arises before SSRANGE exists. If SSRANGE were subsequently used, it
would/could catch the
Yes, a deliberate area left specifically to catch any overflow and for no other
purpose, similar to a patch-area.
Technique arises before SSRANGE exists. If SSRANGE were subsequently used, it
would/could catch the problem, but it is not as simple as the APAR text makes
out (from memory of the
There is a conflation of two issues, with the first being in two parts.
Issue 1) Part a) Can't define enough storage for a table due to COBOL limits.
This is only an issue for "old" programs, where limits for table-size were
imposed by the compiler. The "expedient" approach was to define
>A frequent, even standard way to get past the size limit of a COBOL array, or
>more appropriately table, was to define more "empty" space after it. Since
>subscript bounds checking was always turned off for performance reasons, you
>could effectively address substantially larger than the
Gibney, Dave wrote:
>A frequent, even standard way to get past the size limit of a COBOL array, or
>more appropriately table, was to define more "empty" space after it. Since
>subscript bounds checking was always turned off for performance reasons, you
>could effectively address substantially
n the size limit of any
single 01 item.
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Peter Hunkeler
> Sent: Monday, January 09, 2017 10:42 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: AW: Re: COBOL5 and ceedu
See also here, where a policy-shift was revealed (towards the end of the
thread) to consider replicating V4 results where reasonable.
https://www.ibm.com/developerworks/community/forums/html/topic?id=0f54483b-6f83-441d-a5fc-22a3d333dddf=25
Ironically this has included deliberate replication of
Unfortunately an old technique was still in use, and hit many clients. See here
for some detail:
https://www.ibm.com/developerworks/community/forums/html/topic?id=c476d2c9-0d4e-4073-97c5-6384d8f381c0=25
--
For IBM-MAIN
>For APAR PI65115, it looks like a separate APAR PI68274, was opened for Cobol
>6.1
>If you look at the information page for PI65115:
>http://www-01.ibm.com/support/docview.wss?uid=swg1PI65115
Out of interest I had a look at what this is all about, and I must admit I'm
baffled. What does that
The full "Fix list for Enterprise COBOL for z/OS" for V5+ is here:
http://www-01.ibm.com/support/docview.wss?uid=swg27041164
This is segregated by compiler release/version and also includes the runtime
(Language Environment).
Gesendet: Montag, 9. Januar 2017 20:39
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: COBOL5 and ceedump
Hello everyone,
Does anyone know if this APAR is available for COBOL 5.2 and if it is available
for COBOL 6.1?
I mean, would a specific APAR even be need for COBOL 6.1? Or would this APAR
(PI65115
University of Florida
(352) 273-1298
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Cameron Conacher
Sent: Monday, January 09, 2017 2:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL5 and ceedump
Hello everyone,
Does anyone know
moved to the top of the
> associated storage area.
>
> HTH Roland
>
>
> -Ursprüngliche Nachricht-
> Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im
> Auftrag von Steff Gladstone
> Gesendet: Sonntag, 8. Januar 2017 17:51
> An: IBM-MAIN@LIST
On Sun, 8 Jan 2017 18:51:14 +0200, Steff Gladstone <steff.gladst...@gmail.com>
wrote:
"In a COBOL5 CEEDUMP, how do I locate the *index* of an array (i.e., an array
that is defined with "indexed by") in >the dump?"
If you consult the "
: Sonntag, 8. Januar 2017 19:24
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: AW: COBOL5 and ceedump
Would be nice to know the APAR. :-)
Cheers, Martin
Martin Packer,
zChampion, Principal Systems Investigator, Worldwide Cloud & Systems
Performance, IBM
+44-7802-245-584
email: martin
2017 17:48
Subject: AW: COBOL5 and ceedump
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
Hi Steff,
depending on your service level the index is defined in front of the
array. Look at this APAR text
Starting with COBOL V5.1, index-names were located in memo
Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag
von Steff Gladstone
Gesendet: Sonntag, 8. Januar 2017 17:51
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: COBOL5 and ceedump
Are there any whizzes out there who specialize in reading and deciphering
CEEDUMPs?
I have a question for you. In a COBOL5
The offset should be in the compiler listing.
On Sun, Jan 8, 2017 at 10:51 AM, Steff Gladstone
<steff.gladst...@gmail.com> wrote:
> Are there any whizzes out there who specialize in reading and deciphering
> CEEDUMPs?
> I have a question for you. In a COBOL5 CEEDUMP,
Are there any whizzes out there who specialize in reading and deciphering
CEEDUMPs?
I have a question for you. In a COBOL5 CEEDUMP, how do I locate the
*index* of an array (i.e., an array that is defined with "indexed by") in
the dump?
Thanks in advance,
Steff
30 matches
Mail list logo
