Edward Jaffe wrote:
I can't for the life of me explain why this is not HIPER, but if you
use PDSEs in your shop I highly recommend APAR OA30338.
FYI. This APAR has now been marked HIPER DATALOSS.
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 9024
In
,
on 06/08/2010
at 12:29 PM, "Chase, John" said:
>I'll hazard a guess that you're still proficient with EDLIN on DOS,
>too. :-)
But why would he admit to a familiarity with Mr. EDLIN?
Of course, I too have dark secrets in my past.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
In , on
06/08/2010
at 01:17 PM, Tony Harminc said:
>I discovered much to my surprise today that TSO EDIT doesn't support
>PDSEs.
Ouch!
>Well perhaps I'm the only person left on the planet who still
>remembers how to use TSO EDIT,
You may be the only one who will admit I, but I guaranty tha
Vernooij, CP - SPLXM wrote:
You mentioned the EAV volume. Do you have indications that this is part
of the problem, i.e. the problem only occurs on EAV volumes?
No. EAV has nothing to do with it. The problem can occur on volumes of
any size.
--
Edward E Jaffe
Phoenix Software Internationa
"Edward Jaffe" wrote in message
news:<4c0def64.9020...@phoenixsoftware.com>...
> I can't for the life of me explain why this is not HIPER, but if you
use
> PDSEs in your shop I highly recommend APAR OA30338.
>
> Without this fix, we had broken PDSEs that could not be read,
accessed,
> or even d
>I would NOT suggest PDSE for large libraries that are constantly opened and
>closed.
>This has proven disastrous for an extremely large customer in the west with
>CA7 JCL
>Libraries (we're talking 22-30 seconds to get to the member and open it).
>Recent PTFs
>(in the last year or so), have fixed i
30338 for PDSE Users
Mark Zelden wrote:
> You can go back to past posts of mine and see... but my client has been
> using Endevor controlled PDSEs for production for many years and we
> haven't had any problems. This includes CICS DFHRPL libraries, batch
> production JCL
Mark Zelden wrote:
You can go back to past posts of mine and see... but my client has been
using Endevor controlled PDSEs for production for many years and we
haven't had any problems. This includes CICS DFHRPL libraries, batch
production JCL and PROCLIBs that were statically defined to JES2 in
>We even have a small monoplex LPAR where IGDSMSxx is set to have the default
>PO as PDSE (so even ISPF "work" data sets and
profile data sets get created as PDSE, against IBM's recommendations).
I used to be a big fan of PDSE, when it first came out.
But, I've seen so many problems over the past
On Tue, 8 Jun 2010 18:38:47 +, Ted MacNEIL wrote:
>>I suppose the pervasiveness of this issue depends entirely on how many
PDSEs you have in your shop and how many of them get corrupted before
>you notice there is an issue.
>
>And, over on the CICS-L, people are recommending PDSE for producti
>I suppose the pervasiveness of this issue depends entirely on how many PDSEs
>you have in your shop and how many of them get corrupted before
you notice there is an issue.
And, over on the CICS-L, people are recommending PDSE for production DFHRPL
libraries.
I would think NOT!
-
Too busy drivi
On Tue, 8 Jun 2010 13:17:05 -0400, Tony Harminc wrote:
>On 8 June 2010 11:54, Clark Morris wrote:
>
>> And we knock Microsoft Windows. Somehow the reliability and design of
>> PDSE seems to be lacking. For starters it isn't even a superset of
>> PDS when it comes to function because it can't b
Ed Finnell wrote:
In a message dated 6/8/2010 8:00:40 A.M. Central Daylight Time,
mzel...@flash.net writes:
Reading the description, it looks like a problem that would only affect
a single data set. How did it affect so many data sets and volumes
in your environment?
Yes. The proble
On 06/08/10 13:17, Tony Harminc wrote:
On 8 June 2010 11:54, Clark Morris wrote:
And we knock Microsoft Windows. Somehow the reliability and design of
PDSE seems to be lacking. For starters it isn't even a superset of
PDS when it comes to function because it can't be used for
SYS1.NUCLEU
Chase, John wrote:
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Tony Harminc
On 8 June 2010 11:54, Clark Morris wrote:
And we knock Microsoft Windows. Somehow the reliability and design of
PDSE seems to be lacking. For starters it isn't even a superset of
PDS
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Tony Harminc
>
> On 8 June 2010 11:54, Clark Morris wrote:
>
> > And we knock Microsoft Windows. Somehow the reliability and design of
> > PDSE seems to be lacking. For starters it isn't even a superset of
> > PDS
On 8 June 2010 11:54, Clark Morris wrote:
> And we knock Microsoft Windows. Somehow the reliability and design of
> PDSE seems to be lacking. For starters it isn't even a superset of
> PDS when it comes to function because it can't be used for
> SYS1.NUCLEUS, SYS1.LINKLIB or SYS1.LPALIB.
I dis
Mark Jacobs wrote:
On 06/08/10 10:45, Edward Jaffe wrote:
Mark Zelden wrote:
Ed, I guess your shop isn't big enough or important enough. :-)
It's not marked DATALOSS either. My guess is after this thread it
will be.
I just complained that it wasn't marked DATALOSS or HIPER. It seems
li
gt;-Original Message-
>From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
>Mark Jacobs
>Sent: Tuesday, June 08, 2010 10:58 AM
>To: IBM-MAIN@bama.ua.edu
>Subject: Re: APAR OA30338 for PDSE Users
>
>On 06/08/10 10:45, Edward Jaffe wrote:
&
On Tue, 8 Jun 2010 07:45:57 -0700, Edward Jaffe
wrote:
>Mark Zelden wrote:
>> Ed, I guess your shop isn't big enough or important enough. :-) It's
>> not marked DATALOSS either. My guess is after this thread it will be.
>>
>
>I just complained that it wasn't marked DATALOSS or HIPER. It seem
acobs
Sent: Tuesday, June 08, 2010 10:58 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: APAR OA30338 for PDSE Users
On 06/08/10 10:45, Edward Jaffe wrote:
> Mark Zelden wrote:
>> Ed, I guess your shop isn't big enough or important enough. :-)
>> It's not marked DATALOSS either.
On 06/08/10 10:45, Edward Jaffe wrote:
Mark Zelden wrote:
Ed, I guess your shop isn't big enough or important enough. :-)
It's not marked DATALOSS either. My guess is after this thread it
will be.
I just complained that it wasn't marked DATALOSS or HIPER. It seems
like DATALOSS applies
> Maybe it's not HIPER because research shows nobody but me uses >PDSE. ;-)
Unfortunately we have tons of them.
Bob Shannon
Rocket Software
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists..
Mark Zelden wrote:
Ed, I guess your shop isn't big enough or important enough. :-) It's
not marked DATALOSS either. My guess is after this thread it will be.
I just complained that it wasn't marked DATALOSS or HIPER. It seems like
DATALOSS applies for sure. And, if it was HIPER I would
In a message dated 6/8/2010 8:00:40 A.M. Central Daylight Time,
mzel...@flash.net writes:
Reading the description, it looks like a problem that would only affect
a single data set. How did it affect so many data sets and volumes
in your environment?
>>
What was the one at AA back in ear
Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
Shane Ginnane
Sent: Tuesday, June 08, 2010 9:38 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: APAR OA30338 for PDSE Users
Far be it from me to debunk PDSE after all these years as one of IBMs flagship
products
Far be it from me to debunk PDSE after all these years as one of IBMs flagship
products, but I only use
PDSE when I have to.
Nice concept, badly implemented - has always looked like the marketing droids
driving the techos.
Shane ...
>I can't for the life of me explain why this is not HIPER, bu
On Tue, 8 Jun 2010 00:21:08 -0700, Edward Jaffe
wrote:
>I can't for the life of me explain why this is not HIPER,
Ed, I guess your shop isn't big enough or important enough. :-) It's
not marked DATALOSS either. My guess is after this thread it will be.
> but if you use
>PDSEs in your shop
>I can't for the life of me explain why this is not HIPER, but if you use
>PDSEs in your shop I highly recommend APAR OA30338.
Thanks for the heads-up!
After reading the apar description and resolution, it doesn't even sound like
IBM has found out *why* there was an overlaid eyecatcher. This soun
I can't for the life of me explain why this is not HIPER, but if you use
PDSEs in your shop I highly recommend APAR OA30338.
Without this fix, we had broken PDSEs that could not be read, accessed,
or even deleted and that led to abends in HSM, CATALOG errors, DADSM
errors, corrupted VTOCs with
30 matches
Mail list logo
