Re: SUPERC allocation errors z/OS V1.8 - fix

2007-02-22 Thread Veilleux, Jon L 
>From Shmuel Metz:
> Did he specify a member name or just a bare PDS name? If the former
then I'd suggest   > opening a PMR; if the latter then I would say tha

There is an ETR and IBM has recreated the problem. Yes, there was a
member name. 

Jon L. Veilleux
[EMAIL PROTECTED]
(860) 636-2683 



-
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SUPERC allocation errors z/OS V1.8 - fix

2007-02-21 Thread Shmuel Metz (Seymour J.) 
In
<[EMAIL PROTECTED]>,
on 02/15/2007
   at 01:46 PM, "Veilleux, Jon L" <[EMAIL PROTECTED]> said:

>We ran into an interesting situation with z/OS V1.8. One of our folks
>uses a PDS for his listing dataset in ISPF 3.12 and 3.14. This
>stopped working when we upgraded to z/OS V1.8. After hitting enter we
>got: "Listing not generated". When we hit PF1 for more information we
>received: "Abnormal completion (RC=25). Existing list DS attribute
>conflict."

Did he specify a member name or just a bare PDS name? If the former
then I'd suggest opening a PMR; if the latter then I would say that
ISPF is working properly.

Is it possible that IBM changed the DCB attributes for the listing?
That could also explain the message.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SUPERC allocation errors z/OS V1.8 - fix

2007-02-21 Thread Shmuel Metz (Seymour J.) 
In <[EMAIL PROTECTED]>, on 02/16/2007
   at 08:03 AM, Paul Gilmartin <[EMAIL PROTECTED]> said:

>This "hole" has existed in the Classic file system since OS/360.
>(Shmuel might correct my conjecture about history).  Likewise there's
>the venerable pitfall of allocating a PDS and failing to specify a
>member, thus overwriting the directory.

We lost a proclib that way in SVS. That prompted be to write an
IEBGENER alternative that would not allow a PDS name without a member
on SYSUT2. There was also the problem of an explicit DCB parameter
changing the attributes of an existing PDS, causing use of existing
members to fail.

>Rightly, both holes should be closed once and for all (perhaps 
>leaving a back door to allow reading a PDS directory sequentially). 

I wouldn't call that leaving a hole; OPEN should and does treat input
and output differently.

>But the fix should be done not haphazardly by individual 
>applications, each applying its developers' idiosyncratic concept of 
>what the rule should be, but uniformly, in OPEN code.

That must be done carefully, because it is legitimate to omit the
member name when the application program will supply it.

>For the PDS/PS fix, Rexx is an individual application that gets it
>right:  It fails the attempt to open a PDS with no member specified,
>but allows it if the programmer allocates with overriding DSORG(PS)
>(the back door).

That sounds like it's still too easy to inadvertently destroy a
directory.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SUPERC allocation errors z/OS V1.8 - fix

2007-02-16 Thread Paul Gilmartin 
In a recent note, Matthew Stitt said:

> Date: Fri, 16 Feb 2007 08:41:37 -0600
> 
> In this case, you are probably dealing with a record length type of error.
> I've seen this in the past, where a PDS has a record length of 133, and the
> output was probably trying to use 121 for its length.
> 
> Most likely someone in SUPERC development closed(?) a hole in code.  In my
> opinion, B. A. D. now.
> 
This "hole" has existed in the Classic file system since OS/360.
(Shmuel might correct my conjecture about history).  Likewise there's
the venerable pitfall of allocating a PDS and failing to specify
a member, thus overwriting the directory.  Rightly, both holes
should be closed once and for all (perhaps leaving a back door to
allow reading a PDS directory sequentially).  But the fix should
be done not haphazardly by individual applications, each applying
its developers' idiosyncratic concept of what the rule should be,
but uniformly, in OPEN code.

For the PDS/PS fix, Rexx is an individual application that gets
it right:  It fails the attempt to open a PDS with no member
specified, but allows it if the programmer allocates with overriding
DSORG(PS) (the back door).  Simply, that well-designed code should
be moved from Rexx to OPEN, making the behavior uniform for all
applications.

Conway's law strikes again.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SUPERC allocation errors z/OS V1.8 - fix

2007-02-16 Thread Matthew Stitt 
In this case, you are probably dealing with a record length type of error. 
I've seen this in the past, where a PDS has a record length of 133, and the
output was probably trying to use 121 for its length.

Most likely someone in SUPERC development closed(?) a hole in code.  In my
opinion, B. A. D. now.

On Thu, 15 Feb 2007 13:06:54 -0700, Paul Gilmartin <[EMAIL PROTECTED]>
wrote:

>In a recent note, Mark Zelden said:
>
>> Date: Thu, 15 Feb 2007 12:56:03 -0600
>>
>> On Thu, 15 Feb 2007 13:46:08 -0500, Veilleux, Jon L <[EMAIL PROTECTED]>
>> wrote:
>>
>> >We ran into an interesting situation with z/OS V1.8. One of our folks
>> >uses a PDS for his listing dataset in ISPF 3.12 and 3.14. This stopped
>> >working when we upgraded to z/OS V1.8. After hitting enter we got:
>> >"Listing not generated". When we hit PF1 for more information we
>> >received: "Abnormal completion (RC=25). Existing list DS attribute
>> >conflict."
>> >Through some diligent tracing by our ISPF support guy we found that PTF
>> >UA31856 caused the problem. When we removed it all was well.
>> >Just thought I'd let everyone know.
>> >
>> Thanks for letting us know.  But I just checked and that PTF is not
>> marked PE (at least not yet), so what you really need to do is open
>> a PMR with IBM to find out if this is WAD or BAD.   Is it documented
>> anywhere that the listing data set can't be a PDS member?
>>
>It has long been my experience that while SuperC has accepted
>HFS members as comparands, ironically it will not allow its output
>to be directed to an HFS member.  I haven't reported this because
>of the highly likely WAD (IMO BAD).  Now I'd better check (before
>and after UA31856) to see that IBM hasn't made this even worse.
>
>It's my impression that much of IBM treats HFS as a second-class
>citizen -- if it's broke they see little need to fix it -- they
>take APARs as SUG, etc.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SUPERC allocation errors z/OS V1.8 - fix

2007-02-15 Thread Paul Gilmartin 
In a recent note, Mark Zelden said:

> Date: Thu, 15 Feb 2007 12:56:03 -0600
> 
> On Thu, 15 Feb 2007 13:46:08 -0500, Veilleux, Jon L <[EMAIL PROTECTED]>
> wrote:
> 
> >We ran into an interesting situation with z/OS V1.8. One of our folks
> >uses a PDS for his listing dataset in ISPF 3.12 and 3.14. This stopped
> >working when we upgraded to z/OS V1.8. After hitting enter we got:
> >"Listing not generated". When we hit PF1 for more information we
> >received: "Abnormal completion (RC=25). Existing list DS attribute
> >conflict."
> >Through some diligent tracing by our ISPF support guy we found that PTF
> >UA31856 caused the problem. When we removed it all was well.
> >Just thought I'd let everyone know.
> >
> Thanks for letting us know.  But I just checked and that PTF is not
> marked PE (at least not yet), so what you really need to do is open
> a PMR with IBM to find out if this is WAD or BAD.   Is it documented
> anywhere that the listing data set can't be a PDS member?
> 
It has long been my experience that while SuperC has accepted
HFS members as comparands, ironically it will not allow its output
to be directed to an HFS member.  I haven't reported this because
of the highly likely WAD (IMO BAD).  Now I'd better check (before
and after UA31856) to see that IBM hasn't made this even worse.

It's my impression that much of IBM treats HFS as a second-class
citizen -- if it's broke they see little need to fix it -- they
take APARs as SUG, etc.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SUPERC allocation errors z/OS V1.8 - fix

2007-02-15 Thread Veilleux, Jon L 
Mark Zelden wrote: 
>Thanks for letting us know.  But I just checked and that PTF is not
marked PE (at least not yet), so what you really need > to do is open a
PMR with IBM to find out if this is WAD or BAD.   Is it documented
anywhere that the listing data set   > can't be a PDS member? 
We have an ETR open with IBM.  
PDSes are supported. The ISPF User's Guide specifies:
"If you enter the name of a data set that does not exist, SuperC
allocates it for you. The data set is allocated as a sequential data set
unless you enter a member name after it, in which case it is allocated
as a partitioned data set. "

Jon L. Veilleux
[EMAIL PROTECTED]
(860) 636-2683 


-
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SUPERC allocation errors z/OS V1.8 - fix

2007-02-15 Thread Mark Zelden 
On Thu, 15 Feb 2007 13:46:08 -0500, Veilleux, Jon L <[EMAIL PROTECTED]>
wrote:

>We ran into an interesting situation with z/OS V1.8. One of our folks
>uses a PDS for his listing dataset in ISPF 3.12 and 3.14. This stopped
>working when we upgraded to z/OS V1.8. After hitting enter we got:
>"Listing not generated". When we hit PF1 for more information we
>received: "Abnormal completion (RC=25). Existing list DS attribute
>conflict."
>Through some diligent tracing by our ISPF support guy we found that PTF
>UA31856 caused the problem. When we removed it all was well.
>Just thought I'd let everyone know.
>Jon
>
>Jon L. Veilleux
>[EMAIL PROTECTED]
>(860) 636-2683
>

Thanks for letting us know.  But I just checked and that PTF is not
marked PE (at least not yet), so what you really need to do is open
a PMR with IBM to find out if this is WAD or BAD.   Is it documented 
anywhere that the listing data set can't be a PDS member? 

Regards,

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group:  G-ITO
mailto:[EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html