Re: IMS..IMS..Gotta love IMS. Why is my PCB failing?
OK, so here is the final diagnosis: They had an error in their automated build process that was causing the programs to be translated by the CICS translator, which prefixed the LINKAGE SECTION with the CICS EIB area. That meant that the LINKAGE section mapping didn't match the actual passed in data. Whew. That was fun :) David Logan -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Richard Peurifoy Sent: Thursday, May 28, 2009 9:33 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IMS..IMS..Gotta love IMS. Why is my PCB failing? David Logan wrote: Just to provide an interesting update on this: It appears that the engineers are compiling these COBOL programs in some odd way. When I compile them, they work. I wonder if it could be that they are compiling them on a different platform. I know they like to compile their stuff on z/OS 1.4 still (and all of our IMS testing has been done on z/OS 1.8) Anyway, that's the update. No coding error, it's somehow environmental. Thanks again to those who gave me the tips to speed up my productivity! This might be caused by using uninitialized fields, or indexing past the end of an array. What you get depends on what happens to be in memory. The SSRANGE COBOL option can help find array index problems. For uninitialized fields, you either have to find them and initialized them before you use them or use the set the LE option to clear memory. -- Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IMS..IMS..Gotta love IMS. Why is my PCB failing?
Just to provide an interesting update on this: It appears that the engineers
are compiling these COBOL programs in some odd way. When I compile them,
they work. I wonder if it could be that they are compiling them on a
different platform. I know they like to compile their stuff on z/OS 1.4
still (and all of our IMS testing has been done on z/OS 1.8)
Anyway, that's the update. No coding error, it's somehow environmental.
Thanks again to those who gave me the tips to speed up my productivity!
-Original Message-
From: David Logan [mailto:loga3...@comcast.net]
Sent: Wednesday, May 27, 2009 6:58 AM
To: 'IBM Mainframe Discussion List'
Subject: RE: IMS..IMS..Gotta love IMS. Why is my PCB failing?
OK, that was all I needed, thanks. I put displays in around everything that
even touched the PCB, and I found the program that was horking it up.
Thanks!
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Bill Klein
Sent: Wednesday, May 27, 2009 6:06 AM
To: IBM-MAIN@bama.ua.edu
Subject: IMS..IMS..Gotta love IMS. Why is my PCB failing?
When you are running this with BTS, are you ALSO using an interactive
language-specific debugger, e.g. Xpediter, Debug-Tool, or similar. (They all
have ways of running with BTS). If so, then I would trace when/how those
fields are getting correctly filled in under BTS in the program logic - and
figure out why the code is NOT getting to that place online.
Without knowing a WHOLE LOT MORE, my first guess is that your application is
not checking for a bad status on a preceding call to DL/I and that you are
assuming some of the PCB fields are already filled in (which they are when
things go well) but that are not filled in when something previously failed.
However, that is just a guess.
As I say, stepping thru the source code and monitoring or watching those
fields under BTS, should get you started on where the logic problem is.
David Logan loga3...@comcast.net wrote in message
news:035801c9dec0$8089a040$819ce0...@net...
I have yet another mystifying situation. When I run my transaction online,
I
get a U0476. When I run it under BTS, is happily blows right by the same
code (crashes later, but Ill work on that later.)
It crashes on this:
CALL CEETDLI USING GHU - and yes, I have tried CBLTDLI, no
difference
G1CPCOM-PCB
TYPE-SEG-LTQA
LTERM-QSSA
TYPE-SSA
Under online IMS, my PCB looks like this. This is the one that fails:
3 PAÍQUEUESEGDJLOGAN 2.70COMMDBPX
4F44DC444075DECECECC44414440CDDDCCD4F4FFCDDDCCDE444044
030071000150845452570003413671502B7036444277000F00
Under BTS, the above call works, and my PCB looks like this:
G1CPCOM 03 PA {QUEUESEGIOPCB 2.70COMM u
CFCDCDD4FF44DC44000CDECECECC0001CDDCC444F4FFCDDD000A00
71373640030071000F60845452570003967320002B7036440F940F
It appears that there are various fields that have EBCDIC spaces that
shouldn't in the online PCB. So I spent a lot of time reviewing the LANG=
on
the PSBGEN at the recommendation of the messages manual. But, as it turns
out, LANG=, LANG=ASSEM and LANG=COBOL all generate the same PCB value, so
that's not it.
So what is it? Where do I need to be looking?
Thanks!
David Logan
(p.s. Perhaps somebody also knows how to reload a program in IMS after a
relink without cycling IMS. In CICS, you can issue a NEWCOPY. What do I
need to do in IMS to use a new load module?)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IMS..IMS..Gotta love IMS. Why is my PCB failing?
I believe that all COBOL modules in a run unit should all be compiled with very similar compiler and binder options. Generally you may use most any compiler version, but the COBOL runtimes have to be the latest and greatest LE. I would also observe that 'unpredictable results' could very well include seemingly successful tests. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of David Logan Sent: Thursday, May 28, 2009 6:46 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IMS..IMS..Gotta love IMS. Why is my PCB failing? Just to provide an interesting update on this: It appears that the engineers are compiling these COBOL programs in some odd way. When I compile them, they work. I wonder if it could be that they are compiling them on a different platform. I know they like to compile their stuff on z/OS 1.4 still (and all of our IMS testing has been done on z/OS 1.8) Anyway, that's the update. No coding error, it's somehow environmental. Thanks again to those who gave me the tips to speed up my productivity! -Original Message- From: David Logan [mailto:loga3...@comcast.net] Sent: Wednesday, May 27, 2009 6:58 AM To: 'IBM Mainframe Discussion List' Subject: RE: IMS..IMS..Gotta love IMS. Why is my PCB failing? OK, that was all I needed, thanks. I put displays in around everything that even touched the PCB, and I found the program that was horking it up. Thanks! ..snip NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IMS..IMS..Gotta love IMS. Why is my PCB failing?
David Logan wrote: Just to provide an interesting update on this: It appears that the engineers are compiling these COBOL programs in some odd way. When I compile them, they work. I wonder if it could be that they are compiling them on a different platform. I know they like to compile their stuff on z/OS 1.4 still (and all of our IMS testing has been done on z/OS 1.8) Anyway, that's the update. No coding error, it's somehow environmental. Thanks again to those who gave me the tips to speed up my productivity! This might be caused by using uninitialized fields, or indexing past the end of an array. What you get depends on what happens to be in memory. The SSRANGE COBOL option can help find array index problems. For uninitialized fields, you either have to find them and initialized them before you use them or use the set the LE option to clear memory. -- Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
IMS..IMS..Gotta love IMS. Why is my PCB failing?
I have yet another mystifying situation. When I run my transaction online, I
get a U0476. When I run it under BTS, is happily blows right by the same
code (crashes later, but Ill work on that later.)
It crashes on this:
CALL CEETDLI USING GHU - and yes, I have tried CBLTDLI, no
difference
G1CPCOM-PCB
TYPE-SEG-LTQA
LTERM-QSSA
TYPE-SSA
Under online IMS, my PCB looks like this. This is the one that fails:
3 PAÍQUEUESEGDJLOGAN 2.70COMMDBPX
4F44DC444075DECECECC44414440CDDDCCD4F4FFCDDDCCDE444044
030071000150845452570003413671502B7036444277000F00
Under BTS, the above call works, and my PCB looks like this:
G1CPCOM 03 PA {QUEUESEGIOPCB 2.70COMM u
CFCDCDD4FF44DC44000CDECECECC0001CDDCC444F4FFCDDD000A00
71373640030071000F60845452570003967320002B7036440F940F
It appears that there are various fields that have EBCDIC spaces that
shouldn't in the online PCB. So I spent a lot of time reviewing the LANG= on
the PSBGEN at the recommendation of the messages manual. But, as it turns
out, LANG=, LANG=ASSEM and LANG=COBOL all generate the same PCB value, so
that's not it.
So what is it? Where do I need to be looking?
Thanks!
David Logan
(p.s. Perhaps somebody also knows how to reload a program in IMS after a
relink without cycling IMS. In CICS, you can issue a NEWCOPY. What do I
need to do in IMS to use a new load module?)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
IMS..IMS..Gotta love IMS. Why is my PCB failing?
When you are running this with BTS, are you ALSO using an interactive
language-specific debugger, e.g. Xpediter, Debug-Tool, or similar. (They all
have ways of running with BTS). If so, then I would trace when/how those
fields are getting correctly filled in under BTS in the program logic - and
figure out why the code is NOT getting to that place online.
Without knowing a WHOLE LOT MORE, my first guess is that your application is
not checking for a bad status on a preceding call to DL/I and that you are
assuming some of the PCB fields are already filled in (which they are when
things go well) but that are not filled in when something previously failed.
However, that is just a guess.
As I say, stepping thru the source code and monitoring or watching those
fields under BTS, should get you started on where the logic problem is.
David Logan loga3...@comcast.net wrote in message
news:035801c9dec0$8089a040$819ce0...@net...
I have yet another mystifying situation. When I run my transaction online,
I
get a U0476. When I run it under BTS, is happily blows right by the same
code (crashes later, but Ill work on that later.)
It crashes on this:
CALL CEETDLI USING GHU - and yes, I have tried CBLTDLI, no
difference
G1CPCOM-PCB
TYPE-SEG-LTQA
LTERM-QSSA
TYPE-SSA
Under online IMS, my PCB looks like this. This is the one that fails:
3 PAÍQUEUESEGDJLOGAN 2.70COMMDBPX
4F44DC444075DECECECC44414440CDDDCCD4F4FFCDDDCCDE444044
030071000150845452570003413671502B7036444277000F00
Under BTS, the above call works, and my PCB looks like this:
G1CPCOM 03 PA {QUEUESEGIOPCB 2.70COMM u
CFCDCDD4FF44DC44000CDECECECC0001CDDCC444F4FFCDDD000A00
71373640030071000F60845452570003967320002B7036440F940F
It appears that there are various fields that have EBCDIC spaces that
shouldn't in the online PCB. So I spent a lot of time reviewing the LANG=
on
the PSBGEN at the recommendation of the messages manual. But, as it turns
out, LANG=, LANG=ASSEM and LANG=COBOL all generate the same PCB value, so
that's not it.
So what is it? Where do I need to be looking?
Thanks!
David Logan
(p.s. Perhaps somebody also knows how to reload a program in IMS after a
relink without cycling IMS. In CICS, you can issue a NEWCOPY. What do I
need to do in IMS to use a new load module?)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IMS..IMS..Gotta love IMS. Why is my PCB failing?
OK, that was all I needed, thanks. I put displays in around everything that
even touched the PCB, and I found the program that was horking it up.
Thanks!
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Bill Klein
Sent: Wednesday, May 27, 2009 6:06 AM
To: IBM-MAIN@bama.ua.edu
Subject: IMS..IMS..Gotta love IMS. Why is my PCB failing?
When you are running this with BTS, are you ALSO using an interactive
language-specific debugger, e.g. Xpediter, Debug-Tool, or similar. (They all
have ways of running with BTS). If so, then I would trace when/how those
fields are getting correctly filled in under BTS in the program logic - and
figure out why the code is NOT getting to that place online.
Without knowing a WHOLE LOT MORE, my first guess is that your application is
not checking for a bad status on a preceding call to DL/I and that you are
assuming some of the PCB fields are already filled in (which they are when
things go well) but that are not filled in when something previously failed.
However, that is just a guess.
As I say, stepping thru the source code and monitoring or watching those
fields under BTS, should get you started on where the logic problem is.
David Logan loga3...@comcast.net wrote in message
news:035801c9dec0$8089a040$819ce0...@net...
I have yet another mystifying situation. When I run my transaction online,
I
get a U0476. When I run it under BTS, is happily blows right by the same
code (crashes later, but Ill work on that later.)
It crashes on this:
CALL CEETDLI USING GHU - and yes, I have tried CBLTDLI, no
difference
G1CPCOM-PCB
TYPE-SEG-LTQA
LTERM-QSSA
TYPE-SSA
Under online IMS, my PCB looks like this. This is the one that fails:
3 PAÍQUEUESEGDJLOGAN 2.70COMMDBPX
4F44DC444075DECECECC44414440CDDDCCD4F4FFCDDDCCDE444044
030071000150845452570003413671502B7036444277000F00
Under BTS, the above call works, and my PCB looks like this:
G1CPCOM 03 PA {QUEUESEGIOPCB 2.70COMM u
CFCDCDD4FF44DC44000CDECECECC0001CDDCC444F4FFCDDD000A00
71373640030071000F60845452570003967320002B7036440F940F
It appears that there are various fields that have EBCDIC spaces that
shouldn't in the online PCB. So I spent a lot of time reviewing the LANG=
on
the PSBGEN at the recommendation of the messages manual. But, as it turns
out, LANG=, LANG=ASSEM and LANG=COBOL all generate the same PCB value, so
that's not it.
So what is it? Where do I need to be looking?
Thanks!
David Logan
(p.s. Perhaps somebody also knows how to reload a program in IMS after a
relink without cycling IMS. In CICS, you can issue a NEWCOPY. What do I
need to do in IMS to use a new load module?)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
