ject: Re: Heads Up - LE PE - PK15432
>
>The 'SEARCH ALL' APARs PK15432 and PK16765 have closed with PTFs
>available.
>
***
Bear Stearns is not responsible for any recommendation, solicitation,
offer o
The 'SEARCH ALL' APARs PK15432 and PK16765 have closed with PTFs
available.
Best Regards,
Sam Knutson, GEICO
Performance and Availability Management
mailto:[EMAIL PROTECTED]
(office) 301.986.3574
IBM: I Bring Madness
The '85 Standard didn't include "national" data types, so the issue that IBM
was TRYING to fix wasn't defined there. However, the '02 Standard (page 814
says
"The comparison associated with each WHEN phrase is executed in accordance
with the rules specified for conditional expressions. (See 8.8.4
Anyone know what the Cobol 'standard' has to say on the subject?
-Original Message-
Clark Morris
The thing that is baffling me in this discussion is how "ABCD" could
ever have been considered = "ABCDEF" in a COBOL comparison of unequal
length operands because my understanding of all COBO
On 20 Feb 2006 04:14:46 -0800, in bit.listserv.ibm-main
[EMAIL PROTECTED] (Barbara Nitz) wrote:
>>What else is anyone using to assess the risk? Are you electing
>>to back out the PE without waiting for any reports of problems at your
>>site or fixes from IBM?
>
>We backed out the ptf and went back
I'd like to thank you all for bringing this to my attention.
Monday we did a review of our Cobol programs that use the SEARCH ALL and we
found 2 programs that needed to be changed. We had installed Cobol 3.4 and
associated maintenanc on Jan 15. One of the programs that needs to be
change explain
, 2006 1:15 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Heads Up - LE PE - PK15432
>What else is anyone using to assess the risk? Are you electing to back
>out the PE without waiting for any reports of problems at your site or
>fixes from IBM?
We backed out the ptf and went back to Enterpr
>What else is anyone using to assess the risk? Are you electing
>to back out the PE without waiting for any reports of problems at your
>site or fixes from IBM?
We backed out the ptf and went back to Enterprise Cobol 3.2 since we weren't
sure that Enterprise Cobol 3.4 would work without the pq-ptf
In a message dated 2/19/2006 12:01:15 P.M. Central Standard Time,
[EMAIL PROTECTED] writes:
And
depending on what downstream programs process or people looking at
data see, the condition may not be detected quickly or easily.
>>
Yeah this could get nasty. Feeds to Data Warehouse, Data Sto
On Sat, 18 Feb 2006 19:44:52 -0500, Bob Rutledge <[EMAIL PROTECTED]> wrote:
> I have a job ready to pull PK15432 and a couple relatives but
>I doubt that I'll have to use it after two months.
>
As far as anyone knew, we ran fine with the PK15432 for close to
a month, so time may not be a good ind
We installed the fix for PK15432 on 11 Dec. 2005 as part of our last maintenance
roll-out before year-end freeze. I've had one problem and the program was
easily fixed (after I wrote a note for the auditors explaining why we replaced a
program in the financial software.) I have a job ready to
Roland's handy COBANAL freeware detects the presence of the Search which
I can find in the output by searching on 'SearchY'. I can also
have our Endeavor administrator scan the source libraries for 'SEARCH
ALL'. What else is anyone using to assess the risk? Are you electing
to back out th
it is marked HIPER now ...
APAR Identifier .. PK15432 Last Changed 06/02/17
EXEC BINARY SEARCH ALL ... WHEN .. GIVES DIFFERENT RESULT AFTER
PQ95214 IF SEARCH ARGUMENT IS LONGER THAN 06/01/19 PTF PECHANGE
Symptom .. IN INCORROUT Status ... CLOSED PE
OK. Now I'm getting confused ... I went back to the FM's and
Enterprise Cobol 3.3.0 and previous
SEARCH ALL
WHEN phrase (binary search)
If the WHEN relation-condition is specified, the compare is based on the
length and sign of data-name. For example, if the length of data-name is
shorter than
On Thu, 16 Feb 2006 16:55:30 -0500, Porowski, Ken <[EMAIL PROTECTED]>
wrote:
>Although the compares are working differently with PK15432 are they not
>WAD (working as designed/documented) ?
>
>As I read the examples in the APAR it was broken and is now fixed
>(granted, appropriate HOLDDATA would h
Although the compares are working differently with PK15432 are they not
WAD (working as designed/documented) ?
As I read the examples in the APAR it was broken and is now fixed
(granted, appropriate HOLDDATA would have been nice). Or am I reading
this wrong?
Therefore, an alphameric search argu
On Thu, 16 Feb 2006 15:22:03 -0500, Jousma, David <[EMAIL PROTECTED]>
wrote:
>Yep, we were burned by that one too. Had a lengthy conversation with
>IBM support on this one, finally got them to fess up that this behavior
>change was part of the ENT COB 3.4 support, although it was not
>documented
Here are more comments from my ETR with IBM"
I guess the rules did change(names removed), from my ETR:
David,
OK, found two pmrs claiming behavior changed by the APAR. It's related
to search/search all comparing the key. In this case we closed a
loophole after enhancing National datatypes
EMAIL PROTECTED]
616.653.8429
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Mark Zelden
Sent: Thursday, February 16, 2006 11:41 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Heads Up - LE PE - PK15432
We recently rolled out RSU0512 maintenance which included
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 descripti
20 matches
Mail list logo