Has any one put on the PTFs? Any experience good or bad with their use?
Don Imbriale
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf
Of Knutson, Sam
Sent: Wednesday, April 12, 2006 8:22 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Heads Up - LE PE
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
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 to
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 COBOL
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
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.
, 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 Enterprise Cobol 3.2
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
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
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
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
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
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
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
]
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 a fix to allow
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
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 in
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
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 have
19 matches
Mail list logo
