Cobol - Re: Heads Up - LE PE

Author

Re: Heads Up - LE PE - PK15432

William M. Klein

2006-02-20, 9:55 pm

to: comp.lang,.cobol

For IBM sites that

A) use any release of Enterprise COBOL

B) have programs with SEARCH ALL where the key and data-item being compared are
NOT the same length

you really, REALLY, need to look at APARs:

PK15432
see:
http://www-1.ibm.com/support/docvie...uid=isg1PK15432

and

PQ95214
see:
http://www-1.ibm.com/support/docvie...uid=isg1PQ95214

As I read these (and I could be mistaken) the bottom-line is that the run-time
behavior for the same source code will be different in Enterprise COBOL V3R4
compiled program (and later) from that with earlier LE conforming compilers.
This is "intentional" - but probably not expected.

You can read more about this in the IBM-MAIN thread that follows the following
note.

--
Bill Klein
wmklein <at> ix.netcom.com
"Mark Zelden" <mark.zelden@ibm-main.lst> wrote in message
news:LISTSERV%200602161041268099.045A@BAMA.UA.EDU...
> We recently rolled out RSU0512 maintenance which included a fix to allow
> the LE support for Enterprise Cobol for z/OS V3R4 NF PTF to get applied
> (which itself was PEd).
>
> It turns out there is a new PE related to this support (it went PE on
> 01/19/2006 - 2 days before our rollout).
>
> A short description of PK15432 is:
>
> "a change in behavior of COBOL programs that include
> SEARCH ALL ... WHEN statements if the search argument
> is longer than the key"
>
>
> No fix is available yet, so the PTFs (including support for
> Enterprise Cobol for z/OS V3R4) must be backed out or code
> changes are required. See the APAR text for details.
>
> We were alerted from our applications area when they found
> "bad data". We are trying to assess the impact now and this
> could be a long clean up effort.
>
> Hopefully this post will save someone else.
>
> --
> Mark Zelden
> Sr. Software and Systems Architect - z/OS Team Lead
> Zurich North America and Farmers Insurance Group
> mailto: mark.zelden@zurichna.com
> Systems Programming expert at http://expertanswercenter.techtarget.com/
> Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to listserv@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

Arnold Trembley

2006-02-21, 3:55 am

I forwarded this to our COBOL sysprogs. It appears to be caused by
Language Environment 1.7, rather than the specific release of the
COBOL compiler.

I'm not sure if we have the problem, but when we use SEARCH ALL, we
normally make the key and the search argument have identical Picture
clauses, which would prevent the problem.

William M. Klein wrote:

> to: comp.lang,.cobol
>
> For IBM sites that
>
> A) use any release of Enterprise COBOL
>
> B) have programs with SEARCH ALL where the key and data-item being compared are
> NOT the same length
>
> you really, REALLY, need to look at APARs:
>
> PK15432
> see:
> http://www-1.ibm.com/support/docvie...uid=isg1PK15432
>
> and
>
> PQ95214
> see:
> http://www-1.ibm.com/support/docvie...uid=isg1PQ95214
>
> As I read these (and I could be mistaken) the bottom-line is that the run-time
> behavior for the same source code will be different in Enterprise COBOL V3R4
> compiled program (and later) from that with earlier LE conforming compilers.
> This is "intentional" - but probably not expected.
>
> You can read more about this in the IBM-MAIN thread that follows the following
> note.
>

--
http://arnold.trembley.home.att.net/

2006-02-21, 6:55 pm

Arnold Trembley wrote:
> I forwarded this to our COBOL sysprogs. It appears to be caused by
> Language Environment 1.7, rather than the specific release of the COBOL
> compiler.
>
> I'm not sure if we have the problem, but when we use SEARCH ALL, we
> normally make the key and the search argument have identical Picture
> clauses, which would prevent the problem.
>
>
It is actually rather complicated, caused primarily by LE on z/OS 1.7.
But, there are also PTFs that add Ent. COBOL V3.4 support to pre-1.7 LE
that can cause the same behavior. There are also implications for
non-Enterprise COBOL that use CMPR2. [NOCMPR2 on those compilers seems
to avoid the problem if you are not on Ent. COBOL.]

Prevention, by having identical PICs is the best solution for all. But,
if you are using the SEARCH ALL you should read all of the APARs in the
chain to be sure you don't miss something.

William M. Klein

2006-02-21, 6:55 pm

To follow-up,

As I understand the "current direction" what the LE run-time will EVENTUALLYL do
is to check for the relese of the compiler used and then take different action
(at run-time) depending upon which compiler was used.

This sounds pretty UGLY to me, but does sound like a "better" solution than
simply CHANGING the run-time behavior of previously compiled programs.

--
Bill Klein
wmklein <at> ix.netcom.com
"CG" <carl.gehr.RemoveThis@ThisToo.attglobal.net> wrote in message
news:ab90a$43fb5d69$453db2dd$13703@FUSE.NET...
> Arnold Trembley wrote:
> It is actually rather complicated, caused primarily by LE on z/OS 1.7. But,
> there are also PTFs that add Ent. COBOL V3.4 support to pre-1.7 LE that can
> cause the same behavior. There are also implications for non-Enterprise COBOL
> that use CMPR2. [NOCMPR2 on those compilers seems to avoid the problem if you
> are not on Ent. COBOL.]
>
> Prevention, by having identical PICs is the best solution for all. But, if
> you are using the SEARCH ALL you should read all of the APARs in the chain to
> be sure you don't miss something.

Clark Morris

2006-02-23, 7:55 am

On Tue, 21 Feb 2006 22:53:48 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>To follow-up,
>
>As I understand the "current direction" what the LE run-time will EVENTUALLYL do
>is to check for the relese of the compiler used and then take different action
>(at run-time) depending upon which compiler was used.
>
>This sounds pretty UGLY to me, but does sound like a "better" solution than
>simply CHANGING the run-time behavior of previously compiled programs.

How did the prior behavior ever last so long? I think it violates the
COBOL standard regarding compares and gives results that I would have
considered incorrect.

Sponsored Links