Re: PDSE

[Shmuel Metz (Seymour J.)]

In <4474451749672711.wa.juergen.kellerdeutscheboerse@bama.ua.edu>,
on 01/19/2012
   at 06:26 AM, Juergen Keller 
said:

>... we added this dataset to LINKLIST to get rid of the steplib. When
>I now delete all members and copy the new version to that dataset I
>will receive D37.

Try unallocating it from the linklist.
 
-- 
 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Don Imbriale]

>From the DFSMS Using Data Sets manual:

*PDSE Unused Space*

PDS gas is the unreclaimed space in a PDS that was vacated when members
were deleted or rewritten. Users often overallocate their PDSs to allow for
the inevitable amount of PDS gas that would develop over time. With PDSEs,
you do not need to add additional space to the allocation to allow for
growth of the data set due to gas.

Studies show that a typical installation has 18% to 30% of its PDS space in
the form of gas. This space is unusable to the data set until it has been
compressed. A PDSE dynamically reuses all the allocated space according to
a first-fit algorithm. You do not need to make any allowance for gas when
you allocate space for a PDSE.

Space is only reclaimed for an OPEN for output when it is the only open for
output on that system. PDSE space cannot be reclaimed immediately after a
member is deleted or dated. If a deleted or updated member still has an
existing connection from another task (or the input DCB from an ISPF edit
session), the member space is not reclaimed until the connection is
released and the data set is opened for output and that OPEN for OUTPUT is
the only one on that system.

ABEND D37 can occur on a PDSE indicating it is FULL, but another member can
still be saved in the data set. Recovery processing from an ABEND D37 in
ISPF closes and reopens the data set. This new open of the data set allows
PDSE code to reclaim space so a member can now be saved.


- Don Imbriale


On Thu, Jan 19, 2012 at 7:26 AM, Juergen Keller <
juergen.kel...@deutsche-boerse.com> wrote:

> hello,
>
> I have a very strange "problem". Maybe there is someone having an idea how
> to solve it. So what happens:
>
> We have a pdse-load-library (with only primary allocation - no secondary!)
> for testing software. Now when testing a new versions we first delete all
> members with a batch-job and copy the new version to this dataset. This
> worked fine in the past but now ...
>
> ... we added this dataset to LINKLIST to get rid of the steplib. When I
> now delete all members and copy the new version to that dataset I will
> receive D37. I can see that after deleting all members the dataset is still
> filled with 80%. Someone told me that I have to do a LLA REFRESh afterwards
> but that did not help. When you browse that dataset ISPF says that there
> are no members in, but its still 80% used. Then I do an ISPF-COPY for one
> member and then its only filled with 1%. When doing the same with a batch
> job it does not help.
>
> I'm quite sure that it has to do with the LINKLIST and the PDSE-format. I
> tested it with z/OS 1.10 and 1.12 .. no difference. Has anyone had the same
> problem before and has a solution for me? Any comments are welcome.
>
> regards Juergen
>
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Joel C. Ewing]

On 01/19/2012 07:38 AM, Don Imbriale wrote:

From the DFSMS Using Data Sets manual:


*PDSE Unused Space*

PDS gas is the unreclaimed space in a PDS that was vacated when members
were deleted or rewritten. Users often overallocate their PDSs to allow for
the inevitable amount of PDS gas that would develop over time. With PDSEs,
you do not need to add additional space to the allocation to allow for
growth of the data set due to gas.

Studies show that a typical installation has 18% to 30% of its PDS space in
the form of gas. This space is unusable to the data set until it has been
compressed. A PDSE dynamically reuses all the allocated space according to
a first-fit algorithm. You do not need to make any allowance for gas when
you allocate space for a PDSE.

Space is only reclaimed for an OPEN for output when it is the only open for
output on that system. PDSE space cannot be reclaimed immediately after a
member is deleted or dated. If a deleted or updated member still has an
existing connection from another task (or the input DCB from an ISPF edit
session), the member space is not reclaimed until the connection is
released and the data set is opened for output and that OPEN for OUTPUT is
the only one on that system.

ABEND D37 can occur on a PDSE indicating it is FULL, but another member can
still be saved in the data set. Recovery processing from an ABEND D37 in
ISPF closes and reopens the data set. This new open of the data set allows
PDSE code to reclaim space so a member can now be saved.


- Don Imbriale


On Thu, Jan 19, 2012 at 7:26 AM, Juergen Keller<
juergen.kel...@deutsche-boerse.com>  wrote:


hello,

I have a very strange "problem". Maybe there is someone having an idea how
to solve it. So what happens:

We have a pdse-load-library (with only primary allocation - no secondary!)
for testing software. Now when testing a new versions we first delete all
members with a batch-job and copy the new version to this dataset. This
worked fine in the past but now ...

... we added this dataset to LINKLIST to get rid of the steplib. When I
now delete all members and copy the new version to that dataset I will
receive D37. I can see that after deleting all members the dataset is still
filled with 80%. Someone told me that I have to do a LLA REFRESh afterwards
but that did not help. When you browse that dataset ISPF says that there
are no members in, but its still 80% used. Then I do an ISPF-COPY for one
member and then its only filled with 1%. When doing the same with a batch
job it does not help.

I'm quite sure that it has to do with the LINKLIST and the PDSE-format. I
tested it with z/OS 1.10 and 1.12 .. no difference. Has anyone had the same
problem before and has a solution for me? Any comments are welcome.

regards Juergen


...


From Juergen's initial problem description and the DFSMS manual quote I 
certainly would have expected the space reclaim to have occurred, but 
perhaps not until after the LLA refresh.  It sounds like his update 
should have been the only OPEN for OUTPUT/UPDATE, and it doesn't seem at 
all reasonable that LINKLIST/LLA/VLF should be holding any active 
connects to PDSE members that wouldn't be reset by an LLA REFRESH  (and 
they certainly should not have any OPENs for OUTPUT).  Perhaps he didn't 
retry the update operation after the REFRESH, as it sounds plausible it 
might take the next OPEN OUTPUT after the REFRESH before space might be 
reclaimed.


I have seen some other counter-intuitive PDSE reclaim behavior, which 
has at times made me wonder if the manual's description of space reclaim 
was 100% accurate:
	We had an application ISPF table library PDS with some rather large 
tables which might get updated 100's of times in the course of a week, 
mostly in-place updates because of table padding, but eventually a 
library compress would be needed.  Unfortunately, once or twice a year 
when the system load was unusually heavy, someone would think they were 
hung and attention-out of their ISPF session right in the middle of a 
table update and trash a table.  Since PDSE's don't allow updates 
in-place, this sounded like an obvious candidate for migration to PDSE 
to eliminate the integrity issue, using PDSE space reclaim to solve the 
space/compress problem the ISPF in-place updates on a PDS were intended 
to solve.


The Unexpected:
 Over the course of the first day on a PDSE, the table PDSE library 
grew to over 20 times the typical size of the original PDS.  Finally, as 
ISPF users began to logout at the end of the day, the deleted space 
began to be reclaimed.  The PDSE stabilized to this same daily pattern 
consistently and ceased to grow, so it did solve the integrity problem 
and was retained for that reason, but the extreme delay on space reclaim 
and resulting size increase was an unpleasant surprise.


In retrospect, the peculiar behavior above may be explainable by the 
ISPF internal behavior of keeping table libraries OPEN even after all 
referenced t

Re: PDSE

[Alan Playford]

Try running an IEBCopy compress against the data set (option "z" against. 
TSO-ISPF display of the PDSE). It might be a little complicated as it's in the 
Linklist, and so disp=old wouldn't work (still allocated to LLA), so you'll 
have to use disp=shri in a batch job. 

Run this after deleting the members, and you'd also be as well to run an LLA 
refresh after this and then again after populating it again. 

Al Playford

On 19 Jan 2012, at 17:50, "Joel C. Ewing"  wrote:

> On 01/19/2012 07:38 AM, Don Imbriale wrote:
>>> From the DFSMS Using Data Sets manual:
>> 
>> *PDSE Unused Space*
>> 
>> PDS gas is the unreclaimed space in a PDS that was vacated when members
>> were deleted or rewritten. Users often overallocate their PDSs to allow for
>> the inevitable amount of PDS gas that would develop over time. With PDSEs,
>> you do not need to add additional space to the allocation to allow for
>> growth of the data set due to gas.
>> 
>> Studies show that a typical installation has 18% to 30% of its PDS space in
>> the form of gas. This space is unusable to the data set until it has been
>> compressed. A PDSE dynamically reuses all the allocated space according to
>> a first-fit algorithm. You do not need to make any allowance for gas when
>> you allocate space for a PDSE.
>> 
>> Space is only reclaimed for an OPEN for output when it is the only open for
>> output on that system. PDSE space cannot be reclaimed immediately after a
>> member is deleted or dated. If a deleted or updated member still has an
>> existing connection from another task (or the input DCB from an ISPF edit
>> session), the member space is not reclaimed until the connection is
>> released and the data set is opened for output and that OPEN for OUTPUT is
>> the only one on that system.
>> 
>> ABEND D37 can occur on a PDSE indicating it is FULL, but another member can
>> still be saved in the data set. Recovery processing from an ABEND D37 in
>> ISPF closes and reopens the data set. This new open of the data set allows
>> PDSE code to reclaim space so a member can now be saved.
>> 
>> 
>> - Don Imbriale
>> 
>> 
>> On Thu, Jan 19, 2012 at 7:26 AM, Juergen Keller<
>> juergen.kel...@deutsche-boerse.com>  wrote:
>> 
>>> hello,
>>> 
>>> I have a very strange "problem". Maybe there is someone having an idea how
>>> to solve it. So what happens:
>>> 
>>> We have a pdse-load-library (with only primary allocation - no secondary!)
>>> for testing software. Now when testing a new versions we first delete all
>>> members with a batch-job and copy the new version to this dataset. This
>>> worked fine in the past but now ...
>>> 
>>> ... we added this dataset to LINKLIST to get rid of the steplib. When I
>>> now delete all members and copy the new version to that dataset I will
>>> receive D37. I can see that after deleting all members the dataset is still
>>> filled with 80%. Someone told me that I have to do a LLA REFRESh afterwards
>>> but that did not help. When you browse that dataset ISPF says that there
>>> are no members in, but its still 80% used. Then I do an ISPF-COPY for one
>>> member and then its only filled with 1%. When doing the same with a batch
>>> job it does not help.
>>> 
>>> I'm quite sure that it has to do with the LINKLIST and the PDSE-format. I
>>> tested it with z/OS 1.10 and 1.12 .. no difference. Has anyone had the same
>>> problem before and has a solution for me? Any comments are welcome.
>>> 
>>> regards Juergen
>>> 
>> ...
> 
> From Juergen's initial problem description and the DFSMS manual quote I 
> certainly would have expected the space reclaim to have occurred, but perhaps 
> not until after the LLA refresh.  It sounds like his update should have been 
> the only OPEN for OUTPUT/UPDATE, and it doesn't seem at all reasonable that 
> LINKLIST/LLA/VLF should be holding any active connects to PDSE members that 
> wouldn't be reset by an LLA REFRESH  (and they certainly should not have any 
> OPENs for OUTPUT).  Perhaps he didn't retry the update operation after the 
> REFRESH, as it sounds plausible it might take the next OPEN OUTPUT after the 
> REFRESH before space might be reclaimed.
> 
> I have seen some other counter-intuitive PDSE reclaim behavior, which has at 
> times made me wonder if the manual's description of space reclaim was 100% 
> accurate:
>We had an application ISPF table library PDS with some rather large tables 
> which might get updated 100's of times in the course of a week, mostly 
> in-place updates because of table padding, but eventually a library compress 
> would be needed.  Unfortunately, once or twice a year when the system load 
> was unusually heavy, someone would think they were hung and attention-out of 
> their ISPF session right in the middle of a table update and trash a table.  
> Since PDSE's don't allow updates in-place, this sounded like an obvious 
> candidate for migration to PDSE to eliminate the integrity issue, using PDSE 
> space reclaim to solve the space/compress probl

Re: PDSE

[Veilleux, Jon L]

Did you unallocate the PDSE from the LNKLST and PLLA, and VLF before you did 
your delete and reload? 

SETPROG LNKLST,UNALLOCATE
P LLA
P VLF

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Juergen Keller
Sent: Thursday, January 19, 2012 7:27 AM
To: IBM-MAIN@bama.ua.edu
Subject: PDSE

hello,

I have a very strange "problem". Maybe there is someone having an idea how to 
solve it. So what happens:
 
We have a pdse-load-library (with only primary allocation - no secondary!) for 
testing software. Now when testing a new versions we first delete all members 
with a batch-job and copy the new version to this dataset. This worked fine in 
the past but now ...
 
... we added this dataset to LINKLIST to get rid of the steplib. When I now 
delete all members and copy the new version to that dataset I will receive D37. 
I can see that after deleting all members the dataset is still filled with 80%. 
Someone told me that I have to do a LLA REFRESh afterwards but that did not 
help. When you browse that dataset ISPF says that there are no members in, but 
its still 80% used. Then I do an ISPF-COPY for one member and then its only 
filled with 1%. When doing the same with a batch job it does not help. 
 
I'm quite sure that it has to do with the LINKLIST and the PDSE-format. I 
tested it with z/OS 1.10 and 1.12 .. no difference. Has anyone had the same 
problem before and has a solution for me? Any comments are welcome.
 
regards Juergen

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: INFO IBM-MAIN
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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Schwarz, Barry A]

IEBCOPY compress generates an error message for a PDSE.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Alan Playford
> Sent: Thursday, January 19, 2012 10:08 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: PDSE
>
> Try running an IEBCopy compress against the data set (option "z" against.
> TSO-ISPF display of the PDSE). It might be a little complicated as it's in
> the Linklist, and so disp=old wouldn't work (still allocated to LLA), so
> you'll have to use disp=shri in a batch job.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Paul Gilmartin]

On Thu, 19 Jan 2012 11:09:27 -0800, Schwarz, Barry A wrote:

>IEBCOPY compress generates an error message for a PDSE.
> 
Become familiar with:

Title:  z/OS V1R12 DFSMS Using Data Sets
Document Number: SC26-7410-10

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d490/3.8.7.1

 3.8.7.1 Establishing Connections to Members

Someone might be failing to issue a DISConnect or RELEASE.

(It's not at all clear to me why this problem shouldn't occur similarly
with a classic PDS.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Joel C. Ewing]

On 01/19/2012 02:55 PM, Paul Gilmartin wrote:

On Thu, 19 Jan 2012 11:09:27 -0800, Schwarz, Barry A wrote:


IEBCOPY compress generates an error message for a PDSE.


Become familiar with:

Title:  z/OS V1R12 DFSMS Using Data Sets
Document Number: SC26-7410-10

 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d490/3.8.7.1

  3.8.7.1 Establishing Connections to Members

Someone might be failing to issue a DISConnect or RELEASE.

(It's not at all clear to me why this problem shouldn't occur similarly
with a classic PDS.)

-- gil


...
How could this be an issue with the classic PDS?  Surely the "connection 
to members" concept doesn't exist for a traditional PDS, as old member 
data can only be eliminated by completely reorganizing, compressing the 
PDS.  With no re-use of deleted-member space, there is no need for a 
special mechanism to prevent over-write of a deleted member while some 
other task is still reading the now-deleted version of the member.


The referenced 3.8.7.1 specifically applies to PDSE libraries; but it 
also implies that if LLA REFRESH is not sufficient to DISConnect or 
RELEASE all the old member connects on a PDSE in the LINKLIST and allow 
the deleted PDSE space to be re-used (don't know for sure that this is 
the case, but Juergen's experience that started this thread at least 
raises that as one possibility), then LLA REFRESH would seem to be 
failing to do something it really ought to be doing.


Someone surely is in a position to set up a simple test case, or may 
have already tested this:  A PDSE library in LINKLIST/LLA which no one 
is actually using with but members and minimal free space; delete all 
members; check whether there is enough free space to re-create the 
members; if not, do an LLA REFRESH on the library; re-check whether 
there is now free space for the new members.  If the deleted space is 
never freed, I would say we have a problem that needs fixing.


I gather from past warnings on ibm-main about forcing dynamic LINKLIST 
updates on running address spaces that there are some cases where only a 
partial load of a PDSE program object member has been done and a 
potential of additional future loading activity still exists.  If z/OS 
is smart enough to recognize this situation, then one would want it to 
preserve a PDSE member connection in such a case and continue to make 
the old member version available to the old A/S even across an LLA 
REFRESH; but I would also suspect this technique unlikely to be in use 
on a typical Installation library added to LINKLIST.


--
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Peter Relson]

>Try running an IEBCopy compress against the data set (option "z" against. 

>TSO-ISPF display of the PDSE). It might be a little complicated as it's 
>in the Linklist, and so disp=old wouldn't work (still allocated to LLA), 
>so you'll have to use disp=shri in a batch job. 

This is not good advice, in general. Of course it's your system, so 
shooting yourself in the foot is always an option you are allowed to take.

The system allocates LNKLST data sets for a reason -- so that you can't 
get the data set DISP=OLD which in turn means that if you're doing things 
right you will not be able to do such damaging operations as compress 
(where for compress "doing things right" means getting the data set 
DISP=OLD, and by "damaging" I mean damaging to other processes that might 
have knowledge of where a member is within the data set, not damaging to 
the data set itself).

Bluntly, if you compress a LNKLST data set without DISP=OLD, then don't 
complain if something related to that data set no longer works.

If you must compress the data set, then get it out of the LNKLST and out 
of LLA management. And note that there is no fully safe way to do the 
former unless you have added the data set to the now-activated LNKLST set 
after IPL and are able to terminate/restart all jobs that started after 
that LNKLST set was activated.

Should compress require DISP=OLD? Maybe. But that's unlikely to change, 
and definitely won't change as a system default (one could imagine giving 
the customer a knob to ask that for their system the default be that).

Peter Relson
z/OS Core Technology Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Bob Shannon]

>Try running an IEBCopy compress against the data set (option "z" against

I believe compress is skipped for a PDSE.

Bob Shannon
Rocket Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Paul Gilmartin]

On Thu, 19 Jan 2012 17:37:12 -0600, Joel C. Ewing  wrote:

>On 01/19/2012 02:55 PM, Paul Gilmartin wrote:
>> On Thu, 19 Jan 2012 11:09:27 -0800, Schwarz, Barry A wrote:
>>
>> Someone might be failing to issue a DISConnect or RELEASE.
>>
>> (It's not at all clear to me why this problem shouldn't occur similarly
>> with a classic PDS.)
>>
>...
>How could this be an issue with the classic PDS?  Surely the "connection
>to members" concept doesn't exist for a traditional PDS, as old member
>data can only be eliminated by completely reorganizing, compressing the
>PDS.  With no re-use of deleted-member space, there is no need for a
>special mechanism to prevent over-write of a deleted member while some
>other task is still reading the now-deleted version of the member.
> 
The issue reported by the OP wasn't that a member was
overwritten; the issue was that the data set ran out of space.

Conceptually, any user who has done a BLDL and saved the TTR
has a connection to the member.  PDSE merely formalized the
process.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[John Gilmore]

Paul Gilmartin wrote:


Conceptually, any user who has done a BLDL and saved the TTR has a
connection to the member.  PDSE merely formalized the process.


and this point is an important one.  One of the crucial differences
between a traditional PDS and a PDSE is that, while  the gas in a PDS
is removable only by reorganizing it, the gas in a PDSE is largely
eliminated dynamically, by reusing the space occupied by deleted
members.

This laudable effort of course gives rise to another instance of an
old and very familiar class of problems.  If, say, I LOAD a copy of
the reentrant module MCGUFFIN and you then LOAD a copy of MCGUFFIN,
your LOAD is converted into a virtual one: a usage count is
incremented and you are provided with the address of the same copy of
MCGUFFIN that I am using.  My DELETE then decrements the usage counter
and iff doing so reduces that count to zero is the strorage occupied
by MCGUFFIN freed/recovered.

Now PDSE management makes available all of the usage-count facilities
needed to ensure that DELETE operations are virtual or real as
appropriate if they are used.  If they go unused the space in a PDSE
will be exhausted.

Still, there is a significant net gain.  PDSEs can be managed
correctly, while PDSs cannot; and this brings me to my single
criticism of Paul Gilmartin's language.  The weasel word 'merely' in
"PDSE merely formalizes the process" is inappropriate.  This change
was a large step forward in an imperfect world.  Clots will still be
able to botch things up---How not?---but the tools are available for
those who wish to use them.

Here, as always with this class of problems, if you increment a usage
count you must also decrement it.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Joel C. Ewing]

On 01/20/2012 08:54 AM, Paul Gilmartin wrote:

On Thu, 19 Jan 2012 17:37:12 -0600, Joel C. Ewing  wrote:


On 01/19/2012 02:55 PM, Paul Gilmartin wrote:

On Thu, 19 Jan 2012 11:09:27 -0800, Schwarz, Barry A wrote:

Someone might be failing to issue a DISConnect or RELEASE.

(It's not at all clear to me why this problem shouldn't occur similarly
with a classic PDS.)


...
How could this be an issue with the classic PDS?  Surely the "connection
to members" concept doesn't exist for a traditional PDS, as old member
data can only be eliminated by completely reorganizing, compressing the
PDS.  With no re-use of deleted-member space, there is no need for a
special mechanism to prevent over-write of a deleted member while some
other task is still reading the now-deleted version of the member.


The issue reported by the OP wasn't that a member was
overwritten; the issue was that the data set ran out of space.


Not really.  The context of "this problem" in "It's not clear to me why 
this problem..." was a discussion of member disconnect or release, and 
the original problem that started the thread was more along the lines of 
why isn't deleted space for a LNKLST PDSE library being freed and and 
available for reuse, even after an LLA REFRESH, as one would expect, 
rather than why is the data set out of space (which would have been 
obvious for a PDS that hadn't been compressed).

   JC Ewing


Conceptually, any user who has done a BLDL and saved the TTR
has a connection to the member.  PDSE merely formalized the
process.

-- gil


...

--
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Schumacher, Otto]

It is my felling that IEBCOPY should be corrected to compress a PDSE inplace to 
degas a dataset defined as a lnklst library.  If copy done under TSO releases 
to the lnklst  dataset releases the gas bubbles in the PDSE then IEBCOPY 
ULTILITY should also accomplish this task to relieve the a D37 error. We should 
not have to create a new library in order to release the gas bubbles. 

Regards
Otto Schumacher
 
HP Enterprise Services
Infrastructure Specialist
Ahold Account
CICS & Capacity Technical Support
Ahold Building 
1200 Brookfiled Blvd.
2S-034
Greenville,  South Carolina, 29607
Cell: 864 569--5338
Tel: 864 987-1417
Fax: provide upon request
E-mail: otto.schumac...@hp.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Joel C. Ewing
Sent: Thursday, January 19, 2012 6:37 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: PDSE

On 01/19/2012 02:55 PM, Paul Gilmartin wrote:
> On Thu, 19 Jan 2012 11:09:27 -0800, Schwarz, Barry A wrote:
>
>> IEBCOPY compress generates an error message for a PDSE.
>>
> Become familiar with:
>
> Title:  z/OS V1R12 DFSMS Using Data Sets
> Document Number: SC26-7410-10
>
>  
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d490/3.8.7.1
>
>   3.8.7.1 Establishing Connections to Members
>
> Someone might be failing to issue a DISConnect or RELEASE.
>
> (It's not at all clear to me why this problem shouldn't occur similarly
> with a classic PDS.)
>
> -- gil
>
...
How could this be an issue with the classic PDS?  Surely the "connection 
to members" concept doesn't exist for a traditional PDS, as old member 
data can only be eliminated by completely reorganizing, compressing the 
PDS.  With no re-use of deleted-member space, there is no need for a 
special mechanism to prevent over-write of a deleted member while some 
other task is still reading the now-deleted version of the member.

The referenced 3.8.7.1 specifically applies to PDSE libraries; but it 
also implies that if LLA REFRESH is not sufficient to DISConnect or 
RELEASE all the old member connects on a PDSE in the LINKLIST and allow 
the deleted PDSE space to be re-used (don't know for sure that this is 
the case, but Juergen's experience that started this thread at least 
raises that as one possibility), then LLA REFRESH would seem to be 
failing to do something it really ought to be doing.

Someone surely is in a position to set up a simple test case, or may 
have already tested this:  A PDSE library in LINKLIST/LLA which no one 
is actually using with but members and minimal free space; delete all 
members; check whether there is enough free space to re-create the 
members; if not, do an LLA REFRESH on the library; re-check whether 
there is now free space for the new members.  If the deleted space is 
never freed, I would say we have a problem that needs fixing.

I gather from past warnings on ibm-main about forcing dynamic LINKLIST 
updates on running address spaces that there are some cases where only a 
partial load of a PDSE program object member has been done and a 
potential of additional future loading activity still exists.  If z/OS 
is smart enough to recognize this situation, then one would want it to 
preserve a PDSE member connection in such a case and continue to make 
the old member version available to the old A/S even across an LLA 
REFRESH; but I would also suspect this technique unlikely to be in use 
on a typical Installation library added to LINKLIST.

-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Scott Ford]

So this has my curiosity peaked, how does IBM suggest doing a compress on a 
Linklist lib that needs compressing, inquiring minds would love to know ?

Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Jan 20, 2012, at 8:09 AM, Peter Relson  wrote:

>> Try running an IEBCopy compress against the data set (option "z" against. 
> 
>> TSO-ISPF display of the PDSE). It might be a little complicated as it's 
>> in the Linklist, and so disp=old wouldn't work (still allocated to LLA), 
>> so you'll have to use disp=shri in a batch job. 
> 
> This is not good advice, in general. Of course it's your system, so 
> shooting yourself in the foot is always an option you are allowed to take.
> 
> The system allocates LNKLST data sets for a reason -- so that you can't 
> get the data set DISP=OLD which in turn means that if you're doing things 
> right you will not be able to do such damaging operations as compress 
> (where for compress "doing things right" means getting the data set 
> DISP=OLD, and by "damaging" I mean damaging to other processes that might 
> have knowledge of where a member is within the data set, not damaging to 
> the data set itself).
> 
> Bluntly, if you compress a LNKLST data set without DISP=OLD, then don't 
> complain if something related to that data set no longer works.
> 
> If you must compress the data set, then get it out of the LNKLST and out 
> of LLA management. And note that there is no fully safe way to do the 
> former unless you have added the data set to the now-activated LNKLST set 
> after IPL and are able to terminate/restart all jobs that started after 
> that LNKLST set was activated.
> 
> Should compress require DISP=OLD? Maybe. But that's unlikely to change, 
> and definitely won't change as a system default (one could imagine giving 
> the customer a knob to ask that for their system the default be that).
> 
> Peter Relson
> z/OS Core Technology Design
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Paul Gilmartin]

On Fri, 20 Jan 2012 18:19:03 +, Schumacher, Otto wrote:

>It is my felling that IEBCOPY should be corrected to compress a PDSE inplace 
>to degas a dataset defined as a lnklst library.  If copy done under TSO 
>releases to the lnklst  dataset releases the gas bubbles in the PDSE then 
>IEBCOPY ULTILITY should also accomplish this task to relieve the a D37 error. 
>We should not have to create a new library in order to release the gas bubbles.
>
??? WTF ???

Re-read John Gilmore's recent contribution to this thread.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Scott Ford]

Are we saying PDSEs don't need compressing...wow

Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Jan 20, 2012, at 1:19 PM, "Schumacher, Otto"  wrote:

> It is my felling that IEBCOPY should be corrected to compress a PDSE inplace 
> to degas a dataset defined as a lnklst library.  If copy done under TSO 
> releases to the lnklst  dataset releases the gas bubbles in the PDSE then 
> IEBCOPY ULTILITY should also accomplish this task to relieve the a D37 error. 
> We should not have to create a new library in order to release the gas 
> bubbles. 
> 
> Regards
> Otto Schumacher
>  
> HP Enterprise Services
> Infrastructure Specialist
> Ahold Account
> CICS & Capacity Technical Support
> Ahold Building 
> 1200 Brookfiled Blvd.
> 2S-034
> Greenville,  South Carolina, 29607
> Cell: 864 569--5338
> Tel: 864 987-1417
> Fax: provide upon request
> E-mail: otto.schumac...@hp.com
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf 
> Of Joel C. Ewing
> Sent: Thursday, January 19, 2012 6:37 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: PDSE
> 
> On 01/19/2012 02:55 PM, Paul Gilmartin wrote:
>> On Thu, 19 Jan 2012 11:09:27 -0800, Schwarz, Barry A wrote:
>> 
>>> IEBCOPY compress generates an error message for a PDSE.
>>> 
>> Become familiar with:
>> 
>> Title:  z/OS V1R12 DFSMS Using Data Sets
>> Document Number: SC26-7410-10
>> 
>> 
>> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d490/3.8.7.1
>> 
>>  3.8.7.1 Establishing Connections to Members
>> 
>> Someone might be failing to issue a DISConnect or RELEASE.
>> 
>> (It's not at all clear to me why this problem shouldn't occur similarly
>> with a classic PDS.)
>> 
>> -- gil
>> 
> ...
> How could this be an issue with the classic PDS?  Surely the "connection 
> to members" concept doesn't exist for a traditional PDS, as old member 
> data can only be eliminated by completely reorganizing, compressing the 
> PDS.  With no re-use of deleted-member space, there is no need for a 
> special mechanism to prevent over-write of a deleted member while some 
> other task is still reading the now-deleted version of the member.
> 
> The referenced 3.8.7.1 specifically applies to PDSE libraries; but it 
> also implies that if LLA REFRESH is not sufficient to DISConnect or 
> RELEASE all the old member connects on a PDSE in the LINKLIST and allow 
> the deleted PDSE space to be re-used (don't know for sure that this is 
> the case, but Juergen's experience that started this thread at least 
> raises that as one possibility), then LLA REFRESH would seem to be 
> failing to do something it really ought to be doing.
> 
> Someone surely is in a position to set up a simple test case, or may 
> have already tested this:  A PDSE library in LINKLIST/LLA which no one 
> is actually using with but members and minimal free space; delete all 
> members; check whether there is enough free space to re-create the 
> members; if not, do an LLA REFRESH on the library; re-check whether 
> there is now free space for the new members.  If the deleted space is 
> never freed, I would say we have a problem that needs fixing.
> 
> I gather from past warnings on ibm-main about forcing dynamic LINKLIST 
> updates on running address spaces that there are some cases where only a 
> partial load of a PDSE program object member has been done and a 
> potential of additional future loading activity still exists.  If z/OS 
> is smart enough to recognize this situation, then one would want it to 
> preserve a PDSE member connection in such a case and continue to make 
> the old member version available to the old A/S even across an LLA 
> REFRESH; but I would also suspect this technique unlikely to be in use 
> on a typical Installation library added to LINKLIST.
> 
> -- 
> Joel C. Ewing,Bentonville, AR   jcew...@acm.org
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Mike Schwab]

With a PDSE, you really only need to do a compress after a significant
number of deletes.  Additions and replacements usually reuse space
previously used by a member that was replaced or deleted.

On Fri, Jan 20, 2012 at 2:49 PM, Scott Ford  wrote:
> Are we saying PDSEs don't need compressing...wow
>
> Sent from my iPad
> Scott Ford

-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Gibney, Dave]

In theory and with proper planning, one should not need to compress active 
linklisted libraries, PDS or PDSE.
After all, you should not be updating your live system datasets. Maintenance 
should be done on copies and brought in via (rolling) IPL.

The idea of application libraries in the linklist is not something I like, but 
they can certainly be dynamically added after IPL and removed, update/compress, 
re-added for maintenance. Even here, a copy with decent change control is a 
better idea.

After saying this, I do have a couple libraries where this need arises. But, 
with them, I do know which address spaces are using them and I am not risking 
full system outage if I cheat.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Scott Ford
> Sent: Friday, January 20, 2012 12:46 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: PDSE
> 
> So this has my curiosity peaked, how does IBM suggest doing a compress on
> a Linklist lib that needs compressing, inquiring minds would love to know ?
> 
> Sent from my iPad
> Scott Ford
> Senior Systems Engineer
> www.identityforge.com
> 
> 
> 
> On Jan 20, 2012, at 8:09 AM, Peter Relson  wrote:
> 
> >> Try running an IEBCopy compress against the data set (option "z" against.
> >
> >> TSO-ISPF display of the PDSE). It might be a little complicated as it's
> >> in the Linklist, and so disp=old wouldn't work (still allocated to LLA),
> >> so you'll have to use disp=shri in a batch job.
> >
> > This is not good advice, in general. Of course it's your system, so
> > shooting yourself in the foot is always an option you are allowed to take.
> >
> > The system allocates LNKLST data sets for a reason -- so that you can't
> > get the data set DISP=OLD which in turn means that if you're doing things
> > right you will not be able to do such damaging operations as compress
> > (where for compress "doing things right" means getting the data set
> > DISP=OLD, and by "damaging" I mean damaging to other processes that
> might
> > have knowledge of where a member is within the data set, not damaging
> to
> > the data set itself).
> >
> > Bluntly, if you compress a LNKLST data set without DISP=OLD, then don't
> > complain if something related to that data set no longer works.
> >
> > If you must compress the data set, then get it out of the LNKLST and out
> > of LLA management. And note that there is no fully safe way to do the
> > former unless you have added the data set to the now-activated LNKLST
> set
> > after IPL and are able to terminate/restart all jobs that started after
> > that LNKLST set was activated.
> >
> > Should compress require DISP=OLD? Maybe. But that's unlikely to change,
> > and definitely won't change as a system default (one could imagine giving
> > the customer a knob to ask that for their system the default be that).
> >
> > Peter Relson
> > z/OS Core Technology Design
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Paul Gilmartin]

On Fri, 20 Jan 2012 16:57:12 -0600, Mike Schwab wrote:

>With a PDSE, you really only need to do a compress after a significant
>number of deletes.  Additions and replacements usually reuse space
>previously used by a member that was replaced or deleted.
>
"usually"?  When do they not.  What utility would you use to compress a
PDSE?  Repro; delete; rename?  Inquiring minds want to know.

>On Fri, Jan 20, 2012 at 2:49 PM, Scott Ford  wrote:
>> Are we saying PDSEs don't need compressing...wow
>>
Yeah.  At what point in the history of PDSE did they add that enhancement?
I haven't seen it in any recent IBM announcements.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Mike Schwab]

I migrate and recall them.
With the original release of PDSEs.

On Fri, Jan 20, 2012 at 5:59 PM, Paul Gilmartin  wrote:
> On Fri, 20 Jan 2012 16:57:12 -0600, Mike Schwab wrote:
>
>>With a PDSE, you really only need to do a compress after a significant
>>number of deletes.  Additions and replacements usually reuse space
>>previously used by a member that was replaced or deleted.
>>
> "usually"?  When do they not.  What utility would you use to compress a
> PDSE?  Repro; delete; rename?  Inquiring minds want to know.
>
>>On Fri, Jan 20, 2012 at 2:49 PM, Scott Ford  wrote:
>>> Are we saying PDSEs don't need compressing...wow
>>>
> Yeah.  At what point in the history of PDSE did they add that enhancement?
> I haven't seen it in any recent IBM announcements.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Edward Jaffe]

On 1/20/2012 6:07 PM, Mike Schwab wrote:

I migrate and recall them.
With the original release of PDSEs.


At this point, I imagine Paul is lamenting the lack of an emoticon conveying 
sarcasm.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Peter Relson]

>how does IBM suggest doing a compress on a Linklist lib that needs 
>compressing, inquiring minds would love to know 

There is no suggestion. This is simply not an operation that is supported 
or can be supported in general.

Peter Relson
z/OS Core Technology Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Scott Ford]

Dave,
I am finally in the 'new world order of IT'  planning is a four letter word.

Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Jan 20, 2012, at 7:07 PM, "Gibney, Dave"  wrote:

> In theory and with proper planning, one should not need to compress active 
> linklisted libraries, PDS or PDSE.
> After all, you should not be updating your live system datasets. Maintenance 
> should be done on copies and brought in via (rolling) IPL.
> 
> The idea of application libraries in the linklist is not something I like, 
> but they can certainly be dynamically added after IPL and removed, 
> update/compress, re-added for maintenance. Even here, a copy with decent 
> change control is a better idea.
> 
> After saying this, I do have a couple libraries where this need arises. But, 
> with them, I do know which address spaces are using them and I am not risking 
> full system outage if I cheat.
> 
> Dave Gibney
> Information Technology Services
> Washington State University
> 
> 
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
>> Behalf Of Scott Ford
>> Sent: Friday, January 20, 2012 12:46 PM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: PDSE
>> 
>> So this has my curiosity peaked, how does IBM suggest doing a compress on
>> a Linklist lib that needs compressing, inquiring minds would love to know ?
>> 
>> Sent from my iPad
>> Scott Ford
>> Senior Systems Engineer
>> www.identityforge.com
>> 
>> 
>> 
>> On Jan 20, 2012, at 8:09 AM, Peter Relson  wrote:
>> 
>>>> Try running an IEBCopy compress against the data set (option "z" against.
>>> 
>>>> TSO-ISPF display of the PDSE). It might be a little complicated as it's
>>>> in the Linklist, and so disp=old wouldn't work (still allocated to LLA),
>>>> so you'll have to use disp=shri in a batch job.
>>> 
>>> This is not good advice, in general. Of course it's your system, so
>>> shooting yourself in the foot is always an option you are allowed to take.
>>> 
>>> The system allocates LNKLST data sets for a reason -- so that you can't
>>> get the data set DISP=OLD which in turn means that if you're doing things
>>> right you will not be able to do such damaging operations as compress
>>> (where for compress "doing things right" means getting the data set
>>> DISP=OLD, and by "damaging" I mean damaging to other processes that
>> might
>>> have knowledge of where a member is within the data set, not damaging
>> to
>>> the data set itself).
>>> 
>>> Bluntly, if you compress a LNKLST data set without DISP=OLD, then don't
>>> complain if something related to that data set no longer works.
>>> 
>>> If you must compress the data set, then get it out of the LNKLST and out
>>> of LLA management. And note that there is no fully safe way to do the
>>> former unless you have added the data set to the now-activated LNKLST
>> set
>>> after IPL and are able to terminate/restart all jobs that started after
>>> that LNKLST set was activated.
>>> 
>>> Should compress require DISP=OLD? Maybe. But that's unlikely to change,
>>> and definitely won't change as a system default (one could imagine giving
>>> the customer a knob to ask that for their system the default be that).
>>> 
>>> Peter Relson
>>> z/OS Core Technology Design
>>> 
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Joel C. Ewing]

On 01/21/2012 07:54 AM, Peter Relson wrote:

how does IBM suggest doing a compress on a Linklist lib that needs
compressing, inquiring minds would love to know


There is no suggestion. This is simply not an operation that is supported
or can be supported in general.

Peter Relson
z/OS Core Technology Design



So the only functionally-equivalent, officially-sanctioned way to 
accomplish this goal is still to

(1) create a new dataset with a different name and copy the data to it,
(2) modify PARMLIB LNKLST defs to replace the old library in linklist 
with the new at next IPL,

(3) IPL.
And if for some reason you really must have the original dataset name, 
repeat the process to get back to the old name.


All the other techniques that have been described here in the past to 
achieve this and bypass or defer the need for an IPL either don't 
guarantee the new library will be seen by all address spaces or carry 
some risk.  While those of us who have been around long enough are 
fairly certain of specific cases at our own installation where the risks 
of alternative methods are small enough and acceptable, it is 
understandable that IBM does not wish to "endorse" techniques whose 
success depends on SysProg competence and judgement and also in many 
cases upon the tacit cooperation of Murphy in keeping unrelated system 
failures from occurring in a narrow transition window during which 
libraries and PARMLIB might be in a state where successful IPL and 
recovery from system failure is not be possible (without an independent 
z/OS recovery system).


--
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Scott Ford]

Peter,

I a agree with everyone, but I am finding lost of knowledge and old habits 
prevail.
I learned MVS from an older timer, older than I am, I am 61. So, ask a lot of 
questions and refine 
How I approach things, etc.  Compression of Link libraries was one of those 
areas. I have seen the compression on the fly for years, no damage no harm. 
Most of the shops I worked in, we had a maintenance cycle. Some others 
maintenance time  was not existent.

I don't feel  nowadays shops are really planning. Don't know why, but as a 
vendor have been seeing a lot of it lately. I learned via GSS working in NYC 
and saw planning work.



Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Jan 21, 2012, at 8:54 AM, Peter Relson  wrote:

>> how does IBM suggest doing a compress on a Linklist lib that needs 
>> compressing, inquiring minds would love to know 
> 
> There is no suggestion. This is simply not an operation that is supported 
> or can be supported in general.
> 
> Peter Relson
> z/OS Core Technology Design
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Paul Gilmartin]

On Sat, 21 Jan 2012 10:02:25 -0600, Joel C. Ewing wrote:
>
>So the only functionally-equivalent, officially-sanctioned way to
>accomplish this goal is still to
>(1) create a new dataset with a different name and copy the data to it,
>(2) modify PARMLIB LNKLST defs to replace the old library in linklist
>with the new at next IPL,
>(3) IPL.
>And if for some reason you really must have the original dataset name,
>repeat the process to get back to the old name.
> 
Can LINKLIST contain aliases?  If so:

(0) Place the alias name in PARMLIB LINKLIST defs;
IDCAMS DEFINE ALIAS to the real data set name.
(1) create a new dataset with a different name and copy the data to it,
(2) IDCAMS DELETE ALIAS; DEFINE ALIAS to identify the new data set.
(3) LLA REFRESH to identify members in the new data set.

Why not?  (I know; I've been corrupted by UNIX symbolic links, and
imagine aliases are similar.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Joel C. Ewing]

On 01/21/2012 10:25 AM, Paul Gilmartin wrote:

On Sat, 21 Jan 2012 10:02:25 -0600, Joel C. Ewing wrote:


So the only functionally-equivalent, officially-sanctioned way to
accomplish this goal is still to
(1) create a new dataset with a different name and copy the data to it,
(2) modify PARMLIB LNKLST defs to replace the old library in linklist
with the new at next IPL,
(3) IPL.
And if for some reason you really must have the original dataset name,
repeat the process to get back to the old name.


Can LINKLIST contain aliases?  If so:

(0) Place the alias name in PARMLIB LINKLIST defs;
 IDCAMS DEFINE ALIAS to the real data set name.
(1) create a new dataset with a different name and copy the data to it,
(2) IDCAMS DELETE ALIAS; DEFINE ALIAS to identify the new data set.
(3) LLA REFRESH to identify members in the new data set.

Why not?  (I know; I've been corrupted by UNIX symbolic links, and
imagine aliases are similar.)

-- gil


If an alias name is acceptable in linklist, that still wouldn't solve 
the problem.  Any system enqueues are always done on the real name at 
the time of initial allocation for linklist, and the physical location 
and size of the dataset becomes fixed to the linklist once the dataset 
is initially allocated and is not changed by a REFRESH.  If an active 
linklist dataset is  renamed, cataloged elsewhere, or even deleted, 
linklist still points to the same original DASD tracks.


The only way to physically change the location and/or size of a linklist 
library is to deallocate and reallocate it, which requires activating a 
new linklist definition and eliminating any usage of the prior active 
linklist.  The latter is the difficult part because it can only be done 
by forcing a linklist update on  all long running address spaces, some 
of which cannot be stopped/restarted without an IPL and others of which 
cannot be restarted without disruption to end users.  As has been 
discussed in the past on this list, forcing a linklist update on an 
arbitrary running address space is an "unnatural" act that involves 
risk, and could in the worst case cause z/OS system failure and force an 
IPL.


--
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[R.S.]

Well,
THE ONLY 100% POLITICALLY CORRECT WAY TO solve problem with LNKLST 
libraries:

DO NOT UPDATE.

Any exception to the rule aboce requires special consideration.
I.e. You can replace single module, but you have to check free space before.
Then you have to schedule PDS compress at next service window.

For mass updates - that should mean SMPE APPLY - you should do it on 
"cold" set of libraries, not on live system, so you can compress the 
libraries just after update.


Trick: if you really need to update some lirbary frequently, then remove 
it from IPL-time-PROGxx, add this library after IPL. There is a 
difference. IPL-time lnklst is "more equal" than dynamically added LNKLST.


HTH
--
Radoslaw Skorupka
Lodz, Poland


--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[John Gilmore]

It may perhaps be time to restate the obvious.

LINKLST has come to be  used in situations remote from its original
narrow focus, which was to improve real and virtual program-fetch
performance from certain system datasets.

It does this well, but it was never intended that volatile program
libraries---those some of the members of which are frequently
replaced---be included in it.

The natural, appropriate update time for LINKLST is IPL time,  Some
sysprogs in some shops may well be able to cheat on this in some
situations; but the competence and judg[e]ment required to do so are
personal; and these cheats should not be institutionalized; in
particular, their use should never be delegated to people of 'junior
understanding'.  They should probably not even be talked about much.

So far as I can judge from what has been posted here, the real problem
is not an arcane, PDSE-related one.  It is that some libraries that do
not belong there have made their way into LINKLST.

John Gilmore, Ashland, MA 01721 - USA

-- 
John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Scott Ford]

Exactly, John


Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Jan 21, 2012, at 1:27 PM, John Gilmore  wrote:

> It may perhaps be time to restate the obvious.
> 
> LINKLST has come to be  used in situations remote from its original
> narrow focus, which was to improve real and virtual program-fetch
> performance from certain system datasets.
> 
> It does this well, but it was never intended that volatile program
> libraries---those some of the members of which are frequently
> replaced---be included in it.
> 
> The natural, appropriate update time for LINKLST is IPL time,  Some
> sysprogs in some shops may well be able to cheat on this in some
> situations; but the competence and judg[e]ment required to do so are
> personal; and these cheats should not be institutionalized; in
> particular, their use should never be delegated to people of 'junior
> understanding'.  They should probably not even be talked about much.
> 
> So far as I can judge from what has been posted here, the real problem
> is not an arcane, PDSE-related one.  It is that some libraries that do
> not belong there have made their way into LINKLST.
> 
> John Gilmore, Ashland, MA 01721 - USA
> 
> -- 
> John Gilmore, Ashland, MA 01721 - USA
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[retired mainframer]

:>:-Original Message-
:>:From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
:>:Behalf Of Joel C. Ewing
:>:Sent: Saturday, January 21, 2012 8:02 AM
:>:To: IBM-MAIN@bama.ua.edu
:>:Subject: Re: PDSE
:>:
:>:So the only functionally-equivalent, officially-sanctioned way to
:>:accomplish this goal is still to
:>:(1) create a new dataset with a different name and copy the data to it,
:>:(2) modify PARMLIB LNKLST defs to replace the old library in linklist
:>:with the new at next IPL,
:>:(3) IPL.
:>:And if for some reason you really must have the original dataset name,
:>:repeat the process to get back to the old name.

If you need the original DSN, after populating the new dataset, uncatalog
the original and rename the replacement (both actions not restricted by the
current enqueue).  This will eliminate the need for the second IPL.  And
after the IPL, you can rename the original dataset and delete it even though
the DSN is enqueued by LLA (assuming you the correct RACF access).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Shmuel Metz (Seymour J.)]

In
,
on 01/21/2012
   at 01:27 PM, John Gilmore  said:

>LINKLST has come to be  used in situations remote from its original
>narrow focus, which was to improve real and virtual program-fetch
>performance from certain system datasets.

That wasn't its original purpose.
 
-- 
 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Joel C. Ewing]

On 01/21/2012 04:21 PM, retired mainframer wrote:

:>:-Original Message-
:>:From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
:>:Behalf Of Joel C. Ewing
:>:Sent: Saturday, January 21, 2012 8:02 AM
:>:To: IBM-MAIN@bama.ua.edu
:>:Subject: Re: PDSE
:>:
:>:So the only functionally-equivalent, officially-sanctioned way to
:>:accomplish this goal is still to
:>:(1) create a new dataset with a different name and copy the data to it,
:>:(2) modify PARMLIB LNKLST defs to replace the old library in linklist
:>:with the new at next IPL,
:>:(3) IPL.
:>:And if for some reason you really must have the original dataset name,
:>:repeat the process to get back to the old name.

If you need the original DSN, after populating the new dataset, uncatalog
the original and rename the replacement (both actions not restricted by the
current enqueue).  This will eliminate the need for the second IPL.  And
after the IPL, you can rename the original dataset and delete it even though
the DSN is enqueued by LLA (assuming you the correct RACF access).



This technique is only possible if it is acceptable for the replacement 
DSN to be on a different volume, AND the original DSN volume is not an 
SMS volume, but I too have used this in the past when system datasets 
were divided between two non-SMS volumes and volume residency didn't 
matter.


 One must also recognize that there is a slight risk here: that between 
the "uncatalog" step and the final "rename" there is a window during 
which the system is in a state where a successful IPL may not be 
possible should the system crash; so to not tempt fate, you don't want 
to do this during a storm when the UPS is down or elongate the window by 
allowing yourself to be interrupted in the middle of the process -- and 
having an alternative recovery system available for the unlikely 
worst-case scenario is goodness.  I was never hit by a system failure in 
the middle of one of these sequences, but I am convinced it is only 
because I was sufficiently paranoid and Murphy knew I had recovery 
alternatives at hand.:)


If the object is to find, if possible, a procedure which passes through 
no window of risk where a system outage could leave you unable to IPL, 
then to preserve the original DS name I think you are stuck with two 
IPL's --  an unpleasant enough prospect that most SysProgs quickly learn 
alternatives (like the one above) that accept some tolerable level of risk.

--
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Peter Relson]

>So the only functionally-equivalent, officially-sanctioned way to 
>accomplish this goal is still to
>(1) create a new dataset with a different name and copy the data to it,
>(2) modify PARMLIB LNKLST defs to replace the old library in linklist 
>with the new at next IPL,
>(3) IPL.
>And if for some reason you really must have the original dataset name, 
>repeat the process to get back to the old name.

If the data set was in the IPL-time LNKLST set, yes. If the data set was 
not in the IPL-time LNKLST set, then it depends on whether 
or not you are able to recycle any spaces that were started after you 
activated the post-IPL LNKLST set.

If push came to shove, most are likely aware of the LNKLST UPDATE 
function. It's there if you're willing to risk it, and not complain if 
something bad happens. 

Regardless, you should expect to have to remove the data set to be 
compressed from the active LNKLST (by activating a new LNKLST set without 
the data set), making sure that no one is using that data set within their 
LNKLST set (by recycling, terminating, or using UPDATE), and making sure 
that LLA is not managing that data set (by informing LLA not to manage 
this data set, or terminating LLA).
Then you can compress the data set.

>techniques whose 
>success depends on SysProg competence and judgement 

If it were a question of competence and judgment, we would happily tell 
you what to do. It is not. 

>I have seen the compression on the fly for years, no damage no harm.
And others have seen harm.  The system is yours, you can do what you want. 
You just shouldn't expect a ton of sympathy.

Peter Relson
z/OS Core Technology Design>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[John Gilmore]

Peter Relson wrote:


If it were a question of competence and judgment, we would happily
tell you what to do. It is not.


It is a question of karma or luck too, and that can run out.

--jg

On 1/22/12, Peter Relson  wrote:
>>So the only functionally-equivalent, officially-sanctioned way to
>>accomplish this goal is still to
>>(1) create a new dataset with a different name and copy the data to it,
>>(2) modify PARMLIB LNKLST defs to replace the old library in linklist
>>with the new at next IPL,
>>(3) IPL.
>>And if for some reason you really must have the original dataset name,
>>repeat the process to get back to the old name.
>
> If the data set was in the IPL-time LNKLST set, yes. If the data set was
> not in the IPL-time LNKLST set, then it depends on whether
> or not you are able to recycle any spaces that were started after you
> activated the post-IPL LNKLST set.
>
> If push came to shove, most are likely aware of the LNKLST UPDATE
> function. It's there if you're willing to risk it, and not complain if
> something bad happens.
>
> Regardless, you should expect to have to remove the data set to be
> compressed from the active LNKLST (by activating a new LNKLST set without
> the data set), making sure that no one is using that data set within their
> LNKLST set (by recycling, terminating, or using UPDATE), and making sure
> that LLA is not managing that data set (by informing LLA not to manage
> this data set, or terminating LLA).
> Then you can compress the data set.
>
>>techniques whose
>>success depends on SysProg competence and judgement
>
> If it were a question of competence and judgment, we would happily tell
> you what to do. It is not.
>
>>I have seen the compression on the fly for years, no damage no harm.
> And others have seen harm.  The system is yours, you can do what you want.
> You just shouldn't expect a ton of sympathy.
>
> Peter Relson
> z/OS Core Technology Design>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>


-- 
John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Scott Ford]

I would like to clarify a item or two that I mis-stated in a previous email,
Haven't used PDSE, most PDS and they were in the linklist,
The only time I have seen them compressed is during system time, during a 
maintenance
Window with qualified folks, secondly if they are paying the bucks, well what 
can I say,
I usually was just a hired gun. Especially working for IBM as a consult, which 
I have numerous times. 

Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Jan 22, 2012, at 8:34 PM, John Gilmore  wrote:

> Peter Relson wrote:
> 
> 
> If it were a question of competence and judgment, we would happily
> tell you what to do. It is not.
> 
> 
> It is a question of karma or luck too, and that can run out.
> 
> --jg
> 
> On 1/22/12, Peter Relson  wrote:
>>> So the only functionally-equivalent, officially-sanctioned way to
>>> accomplish this goal is still to
>>> (1) create a new dataset with a different name and copy the data to it,
>>> (2) modify PARMLIB LNKLST defs to replace the old library in linklist
>>> with the new at next IPL,
>>> (3) IPL.
>>> And if for some reason you really must have the original dataset name,
>>> repeat the process to get back to the old name.
>> 
>> If the data set was in the IPL-time LNKLST set, yes. If the data set was
>> not in the IPL-time LNKLST set, then it depends on whether
>> or not you are able to recycle any spaces that were started after you
>> activated the post-IPL LNKLST set.
>> 
>> If push came to shove, most are likely aware of the LNKLST UPDATE
>> function. It's there if you're willing to risk it, and not complain if
>> something bad happens.
>> 
>> Regardless, you should expect to have to remove the data set to be
>> compressed from the active LNKLST (by activating a new LNKLST set without
>> the data set), making sure that no one is using that data set within their
>> LNKLST set (by recycling, terminating, or using UPDATE), and making sure
>> that LLA is not managing that data set (by informing LLA not to manage
>> this data set, or terminating LLA).
>> Then you can compress the data set.
>> 
>>> techniques whose
>>> success depends on SysProg competence and judgement
>> 
>> If it were a question of competence and judgment, we would happily tell
>> you what to do. It is not.
>> 
>>> I have seen the compression on the fly for years, no damage no harm.
>> And others have seen harm.  The system is yours, you can do what you want.
>> You just shouldn't expect a ton of sympathy.
>> 
>> Peter Relson
>> z/OS Core Technology Design>
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>> 
> 
> 
> -- 
> John Gilmore, Ashland, MA 01721 - USA
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Barbara Nitz]

>It may perhaps be time to restate the obvious.
>
>LINKLST has come to be  used in situations remote from its original
>narrow focus, which was to improve real and virtual program-fetch
>performance from certain system datasets.
>
>It does this well, but it was never intended that volatile program
>libraries---those some of the members of which are frequently
>replaced---be included in it.

'Frequently replaced': Because IBM insists on the customer having this-or-that 
ptf installed before they even look at the problem? Which still requires IPL if 
the dataset is in the IPL linklist, as we have learned. So much for 24/7/365.

>The natural, appropriate update time for LINKLST is IPL time,  Some
>sysprogs in some shops may well be able to cheat on this in some
>situations; but the competence and judg[e]ment required to do so are
>personal; and these cheats should not be institutionalized; in
>particular, their use should never be delegated to people of 'junior
>understanding'.  They should probably not even be talked about much.

Unfortunately, not enough happens for sysprogs to even *want* to use an IPL to 
update linklist datasets. For PDSs, the 
shutdown application - remove from lla - remove lnklst enq - update dataset - 
compress - return to lla - return lnklst enq - restart application works quite 
well. If I try to tell my colleagues that they should generate a different 
linklist for such a change and *not* use update jobname(*) on it to get rid of 
the old linklist they will refuse. Every time. Because the mechanism/concept 
that is behind the linklist switch is awkward in a real-world-environment. The 
implications are generally not really understood. And if the linklist dataset 
is a PDSE, then all bets are off, because what goes on behind the scenes with 
PDSEs is even less understood generally. And to think that PDSEs are the only 
things that can run on EAVs in the extended space!
I am hated here when I try to enforce no secondary space or IPLs for changes to 
linklist datasets. And only the fact that we had a common storage overlay 
caused by PDSE code two days after a setprog update,jobname(*) (that IBM 
refused to look at under the guise of "you used a command you shouldn't") 
enabled me to ban update jobname(*) in this installation.

>So far as I can judge from what has been posted here, the real problem
>is not an arcane, PDSE-related one.  It is that some libraries that do
>not belong there have made their way into LINKLST.
Because vendors and IBM demand to have their datasets it put into LINKLIST. 
Partly because they don't support ISPLLIB and dynamic steplib is frowned upon 
by IBM, too. Partly because vendors and components other than those supported 
by Peter Relson have no clue about the impacts of having datasets in linklist.
Now what came first, the hen or the egg? Since usage has changed, the way it 
works should have been changed, too. I don't hold my breath.

Barbara

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Tom Marchant]

On Sat, 21 Jan 2012 10:25:34 -0600, Paul Gilmartin wrote:

>Can LINKLIST contain aliases?

IIRC (but I may not remember correctly) SETPROG ADD can specify an 
alias.  However,

>If so:
>
>(0) Place the alias name in PARMLIB LINKLIST defs;
>IDCAMS DEFINE ALIAS to the real data set name.
>(1) create a new dataset with a different name and copy the data to it,
>(2) IDCAMS DELETE ALIAS; DEFINE ALIAS to identify the new data set.
>(3) LLA REFRESH to identify members in the new data set.

LLA is not Link list.

LLA REFRESH does not close, free, allocate and open the LINKLIST set. 
It re-reads the directory.

Think about it.  Stop LLA.  LINKLIST keeps on satisfying requests, 
albeit more slowly.  The system opened the LINKLIST set when the 
LINKLIST ACTIVATE was done.

Start LLA again.  If LLA is using different data sets than what are 
in the LINKLIST because you tried to outsmart the system, you will 
have errors.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[John Gilmore]

Barbara Nitz writes:


Because vendors and IBM demand to have their datasets it put into
LINKLIST. Partly because they don't support ISPLLIB and dynamic
steplib is frowned upon by IBM, too. Partly because vendors and
components other than those supported by Peter Relson have no clue
about the impacts of having datasets in linklist.


I have called around a bit this morning; and it would appear that
Barbara may even have understated the dimensions of this problem.

Without an elaborate investigation that would be inappropriate (and
inevitably incomplete too), it is impossible to say just what fraction
of these demands is justified; but it does seem clear that a
significant number of them are not, that some ISVs and some IBM groups
are putting things in LINKLST because it is chic to do so, i.e., (as
some SVCs were written in the past) as a species of oneupmanship.

This surprises me, both because putting something into LINKLST is too
easy to be a convincing demonstration of any sort of prowess and
because of the maintenance complications that doing so brings in
train.

Still, it is happening; and since forbidding the use of LINKLST to
anyone is now an unenforceable non-starter, it seems clear 1) that
new, side-effect free mechanisms for refreshing it are needed and 2)
that it will be very difficult to provide them transparently.

John Gilmore, Ashland, MA 01721 - USA

On 1/23/12, Tom Marchant  wrote:
> On Sat, 21 Jan 2012 10:25:34 -0600, Paul Gilmartin wrote:
>
>>Can LINKLIST contain aliases?
>
> IIRC (but I may not remember correctly) SETPROG ADD can specify an
> alias.  However,
>
>>If so:
>>
>>(0) Place the alias name in PARMLIB LINKLIST defs;
>>IDCAMS DEFINE ALIAS to the real data set name.
>>(1) create a new dataset with a different name and copy the data to it,
>>(2) IDCAMS DELETE ALIAS; DEFINE ALIAS to identify the new data set.
>>(3) LLA REFRESH to identify members in the new data set.
>
> LLA is not Link list.
>
> LLA REFRESH does not close, free, allocate and open the LINKLIST set.
> It re-reads the directory.
>
> Think about it.  Stop LLA.  LINKLIST keeps on satisfying requests,
> albeit more slowly.  The system opened the LINKLIST set when the
> LINKLIST ACTIVATE was done.
>
> Start LLA again.  If LLA is using different data sets than what are
> in the LINKLIST because you tried to outsmart the system, you will
> have errors.
>
> --
> Tom Marchant
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>


-- 
John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Shmuel Metz (Seymour J.)]

In
,
on 01/22/2012
   at 08:34 PM, John Gilmore  said:

>It is a question of karma or luck too, and that can run out.
 ___
  ^
 will
 
-- 
 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Shmuel Metz (Seymour J.)]

In <2352892735591824.wa.nitzibmgmx@bama.ua.edu>, on 01/23/2012
   at 02:35 AM, Barbara Nitz  said:

>The implications are generally not really understood.

Neither are the implications of update jobname(*).
 
-- 
 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Art Gutowski]

On Mon, 23 Jan 2012 07:54:52 -0600, Tom Marchant  
wrote:

>On Sat, 21 Jan 2012 10:25:34 -0600, Paul Gilmartin wrote:
>
>>Can LINKLIST contain aliases?
>
>IIRC (but I may not remember correctly) SETPROG ADD can specify an
>alias.  However,
>
>From MVS Init & Tuning, on SETPROG LNKLST:

DSNAME(dsname) 
The 44-character name of a data set or library that you want to add to the 
specified LNKLST set or delete from the specified LNKLST set. DSN, LIB, LIBRARY 
are accepted synonyms for this parameter. 

The data set can be a PDS or a PDSE. (IBM suggests that you use PDSEs because 
of the limitations on the number of extents for a LNKLST concatenation. See 
"Concatenating data sets to the LNKLST concatenation" in topic 74.4.4.) For the 
LNKLST created at IPL, the dsname cannot be an alias. 

So, NO, as of z/OS 1.12, ALIAS entries are not allowed.  Static System Symbols, 
however are allowed.  Which prompts me to mention that IBM and vendors do not 
only suggest/recommend/require datasets be in the LinkList FSVO "performance", 
or due to a lack of support or understanding of ISPLLIB/dynamic STEPLIB, or 
because it's "cool" (or "chic").  It is also a reasonable means to maintain 
target/execution libraries by VR/M and/or Maintenance level *and* insulate 
applications and users from dataset name changes.  

[...]

Regards,
Art Gutowski
Compuware Corporation

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Shmuel Metz (Seymour J.)]

In <0474239580859420.wa.arthur.gutowskicompuware@bama.ua.edu>, on
01/23/2012
   at 04:14 PM, Art Gutowski  said:

>So, NO, as of z/OS 1.12, ALIAS entries are not allowed.

ITYM are not allowed at IPL time.
 
-- 
 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Barbara Nitz]

>and it would appear that
>Barbara may even have understated the dimensions of this problem.
Me? Everybody tells me I always exaggerate. :-) But I can list more grievances 
for this topic

>Still, it is happening; and since forbidding the use of LINKLST to
>anyone is now an unenforceable non-starter, it seems clear 1) that
>new, side-effect free mechanisms for refreshing it are needed and 2)
>that it will be very difficult to provide them transparently.

My guess is that it is easily solvable by putting this into z/OSMF. 
After all, the clickers have no clue what they're doing, anyway. That's why 
they need it clickable. z/OSMF also makes transparency a non-brainer.

Barbara

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Art Gutowski]

On Mon, 23 Jan 2012 22:11:49 -0500, Shmuel Metz (Seymour J.) 
 wrote:

>In <0474239580859420.wa.arthur.gutowskicompuware@bama.ua.edu>, on
>01/23/2012
>   at 04:14 PM, Art Gutowski  said:
>>On Mon, 23 Jan 2012 07:54:52 -0600, Tom Marchant  
>>wrote:
>>>On Sat, 21 Jan 2012 10:25:34 -0600, Paul Gilmartin wrote:
>
>>>Can LINKLIST contain aliases?
>
>>IIRC (but I may not remember correctly) SETPROG ADD can specify an
>>alias.  However, [...]
>
>>So, NO, as of z/OS 1.12, ALIAS entries are not allowed.
>
>ITYM are not allowed at IPL time.

Tom...hand me a towel, so I can wipe this egg off my face... Thanks for setting 
me straight - LNKLST cannot, PROGxx LNKLST ADD can.  Since APF is another story:

74.1.1 Defining aliases in the APF list
Do not define aliases in the APF list because IBM's data management services 
(for example, OPEN processing) map an alias to its actual library name and 
query the APF list by the actual library name. An alias in the APF list does 
not authorize anything. 

...for consistency, I would use DSN with a symbolic qualifier, or volume, 
unless LNKAUTH=LNKLST, then it doesn't matter.

Just out of idle curiosity, I looked and found no documented restriction for 
aliases in LPALSTxx...do I take that to mean dataset aliases are supported?  
(Never thought to try it.)

Regards,
Art Gutowski

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Schumacher, Otto]

I recommend that you use the real dataset name not the alias name in the 
LINKLIST and use the symbolic alias to isolate the required JCL changes if the 
dataset is required in any JCL.  Since the dataset is in the LINKLIST then you 
should not need to specify the dataset in any JCL. 

Regards
Otto Schumacher
 
HP Enterprise Services
Infrastructure Specialist
Ahold Account
CICS & Capacity Technical Support
Ahold Building 
1200 Brookfiled Blvd.
2S-034
Greenville,  South Carolina, 29607
Cell: 864 569--5338
Tel: 864 987-1417
Fax: provide upon request
E-mail: otto.schumac...@hp.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Art Gutowski
Sent: Tuesday, January 24, 2012 10:38 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: PDSE

On Mon, 23 Jan 2012 22:11:49 -0500, Shmuel Metz (Seymour J.) 
 wrote:

>In <0474239580859420.wa.arthur.gutowskicompuware@bama.ua.edu>, on
>01/23/2012
>   at 04:14 PM, Art Gutowski  said:
>>On Mon, 23 Jan 2012 07:54:52 -0600, Tom Marchant  
>>wrote:
>>>On Sat, 21 Jan 2012 10:25:34 -0600, Paul Gilmartin wrote:
>
>>>Can LINKLIST contain aliases?
>
>>IIRC (but I may not remember correctly) SETPROG ADD can specify an
>>alias.  However, [...]
>
>>So, NO, as of z/OS 1.12, ALIAS entries are not allowed.
>
>ITYM are not allowed at IPL time.

Tom...hand me a towel, so I can wipe this egg off my face... Thanks for setting 
me straight - LNKLST cannot, PROGxx LNKLST ADD can.  Since APF is another story:

74.1.1 Defining aliases in the APF list
Do not define aliases in the APF list because IBM's data management services 
(for example, OPEN processing) map an alias to its actual library name and 
query the APF list by the actual library name. An alias in the APF list does 
not authorize anything. 

...for consistency, I would use DSN with a symbolic qualifier, or volume, 
unless LNKAUTH=LNKLST, then it doesn't matter.

Just out of idle curiosity, I looked and found no documented restriction for 
aliases in LPALSTxx...do I take that to mean dataset aliases are supported?  
(Never thought to try it.)

Regards,
Art Gutowski

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Shmuel Metz (Seymour J.)]

In <6841965402587229.wa.arthur.gutowskicompuware@bama.ua.edu>, on
01/24/2012
   at 09:37 AM, Art Gutowski  said:

>Just out of idle curiosity, I looked and found no documented
>restriction for aliases in LPALSTxx...do I take that to mean dataset
>aliases are supported?

My guess is that nothing will support an alias at IPL time. OTOH, I'm
fairly confident that you can add an LPA module from an alias after
IPL.
 
-- 
 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Juergen Keller]

Hello all,
thank you for your updates and hints. Lets bring the discussion to an end ...
The "problem" started when we began to install z/OS 1.12 and my colleagues did 
not want me to use dynamic steplib in the future (that was another post some 
month ago). So we decided to bring this load library to LNKLST. This worked 
fine for some weeks. No we wanted to install some maintenance to this library 
and this did not work as expected. The library is PDSE and from the posts I 
learned that we should not do what I wanted to do. So finally we decided to 
remove it from LNKLST and define it as a STEPLIB to the logon-procedure. That 
solves all the problems with lnklst and makes it much more easier to install 
maintenance. 
Bringing a dataset to LNKLST has nothing to do with "chic" or something else. 
Its just a way to make lmods available for users in an easy way. All the 
following problems when its PDSE and in LNKLST and you want to add/change lmods 
where not expected and I was a little bit surprised. By the way ... I'm not a 
z/OS-sysprog - only responsible for non-z/OS-software. So I was not aware of 
all the restrictions z/OS has. But I know that (I think) a lot of sysprogs do 
what they should not do. Yes I understand Peter and Jim and some others who say 
what I should not do, whats on my own risk and whats not supported and and and 
 I know some of these problems more than 30 years and since that time there 
is no useable supported solution from IBM. But that's another discussion.
Finally ... this PDSE-library was moved to logon-procedure and removed from 
LNKLST and all works fine and we have to live with all the secondary effects.
regards Juergen 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Mark Zelden]

On Wed, 25 Jan 2012 02:51:16 -0600, Juergen Keller 
 wrote:

>Finally ... this PDSE-library was moved to logon-procedure and removed from 
>LNKLST and all works fine and we have to live with all the secondary effects.
>regards Juergen

STEPLIBs in logon procs are bad from a performance perspective.  Especially if 
you 
have a large system (dozens to hundreds of concurrent ISPF users)  and share it 
from 
multiple LPAR.   Every time someone hits enter in ISPF or issues other commands 
the
library will be searched. 

If you must use a STEPLIB in your logon proc, you should at least add it to LLA 
with the
FREEZE option and train the people who maintain the library that an LLA update
is needed when they make changes.

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Shmuel Metz (Seymour J.)]

In <3446216946961664.wa.markmzelden@bama.ua.edu>, on 01/25/2012
   at 07:33 AM, Mark Zelden  said:

>STEPLIBs in logon procs are bad from a performance perspective.

Not if you do as your wrote in your second paragraph.

>If you must use a STEPLIB in your logon proc, you should at least
>add it to LLA with the FREEZE option

And there goes your performance impact.
 
-- 
 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE

[Frank Swarbrick]

Might it be nice to have something other than the LNKLST that behaves as sort 
of a "global" JOBLIB?  I'm specifically referring to for batch jobs, but I 
imagine it would be useful for TSO as well.  In this could be specified those 
libraries that don't need much of what LNKLST provides (don't ask me what it 
provides; I'm just an applications developer), but do need a way to apply 
"globally" to any job that is running.

I imagine something similar to the PROCLIB parm of JES2's JOBCLASS statement.  
An example:


JOBCLASS(?) PROCLIB=00, LOADLIB=00

PROCLIB(PROC00) DD(1)=(DSNAME=SYS2.&SYSNAME..PROCLIB),    
    DD(2)=(DSNAME=SYS2.&ZOSRLVL..PROCLIB),    
    DD(3)=(DSNAME=SYS1.IBM.PROCLIB),  
    DD(4)=(DSNAME=SYS2.&ZOSRLVL..COMPILE.PROCLIB),
    DD(5)=(DSNAME=SYS3.PROCLIB),  
    DD(6)=(DSNAME=SYS2.PROCLIB),  
    DD(7)=(DSNAME=SYS6.IMD1.PROCLIB), 
    DD(8)=(DSNAME=PGMR.TOOLSLIB.PROC),UNCOND  

LOADLIB(LOAD00) DD(1)=(DSNAME= ... etc ...)

Perhaps different job classes would/could have different PROCLIBs and different 
LOADLIBs, depending on what applications you run in each class.  Probably would 
be useful to be able to specify more than one set of dynamic DD's as well:


JOBCLASS(Q) LOADLIB=(01,00)  /* LOAD01 ahead of LOAD00 */


LOADLIB(LOAD00) DD(1)=(DSNAME= ... etc ...)
LOADLIB(LOAD01) DD(1)=(DSNAME= ... etc ...) 

I would imagine, further, that with this in place a JCL JOBLIB/STEPLIB 
statement could have an option to either override the "class level" JOBLIB or 
to simply concatenate the JCL DD's ahead of the "class level" DD's.

Not knowing things at the system level, it seems workable to me.  But I'm sure 
I'll hear lots of reasons why its a bad idea.  So go for it.

Frank





>
> From: Juergen Keller 
>To: IBM-MAIN@bama.ua.edu 
>Sent: Wednesday, January 25, 2012 1:51 AM
>Subject: Re: PDSE
> 
>Hello all,
>thank you for your updates and hints. Lets bring the discussion to an end ...
>The "problem" started when we began to install z/OS 1.12 and my colleagues did 
>not want me to use dynamic steplib in the future (that was another post some 
>month ago). So we decided to bring this load library to LNKLST. This worked 
>fine for some weeks. No we wanted to install some maintenance to this library 
>and this did not work as expected. The library is PDSE and from the posts I 
>learned that we should not do what I wanted to do. So finally we decided to 
>remove it from LNKLST and define it as a STEPLIB to the logon-procedure. That 
>solves all the problems with lnklst and makes it much more easier to install 
>maintenance. 
>Bringing a dataset to LNKLST has nothing to do with "chic" or something else. 
>Its just a way to make lmods available for users in an easy way. All the 
>following problems when its PDSE and in LNKLST and you want to add/change 
>lmods where not expected and I was a little bit surprised. By the way ... I'm 
>not a z/OS-sysprog - only responsible for non-z/OS-software. So I was not 
>aware of all the restrictions z/OS has. But I know that (I think) a lot of 
>sysprogs do what they should not do. Yes I understand Peter and Jim and some 
>others who say what I should not do, whats on my own risk and whats not 
>supported and and and  I know some of these problems more than 30 years 
>and since that time there is no useable supported solution from IBM. But 
>that's another discussion.
>Finally ... this PDSE-library was moved to logon-procedure and removed from 
>LNKLST and all works fine and we have to live with all the secondary effects.
>regards Juergen 
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: PDSE Anomaly?

[Mark Zelden]

On Mon, 18 May 2009 13:53:48 -0700, Longnecker, Dennis
 wrote:

>On my test lpar I applied some DB2 maintenance to a module.   I could
browse the module and indeed the fix was on.
>
>On my production LPAR, I wanted to copy that module over to the product
libraries, so I did a TSO =3.3 copy and placed it in the production load
library.   I browsed that production load library, and the fix was not on. 
I browsed the original library, and the fix was not on.  The original
library is cataloged to the same volume (usercat), so I know it was pointing
to the same place.


Are the 2 systems in the same sysplex?  If not, did you do the 3.3 copy from
test to prod on the prod system or the test system?   If they aren't in the same
sysplex, then you can really get yourself in trouble here if you did the
copy from the test system (write to prod from test as opposed to read from
test on prod).

Is PDSESHARING set to normal or extended?  Are both system set up the
same way?  This question assumes they are both in the same sysplex.

>
>I tried LLA, refreshes, inactivating LLA, and even IPL'ing, but could not
see the fix on the load libraries from my production LPAR (still looked good
in test).
>

Is the library in the LNKLST on either system?  Which one(s)?  Is it in 
LLA on either system?  A library can be in LLA without being in LNKLST.

>Finally, on the TSO =1 screen, I entered the dataset name AND the volser
and then I could see that the fix was on.  I went out and went back in
without specifying the volser, and the fix was STILL on.
>
>It appears it was cached or something, even through an IPL?   Any
suggestions?
>

Something...  but not sure what.   Most likely a user error of some kind.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDSE Anomaly?

[Linda Mooney]

Hi Dennis, 



We have to watch out for this too.  If you have a same name dataset on two 
different lpars and the alias is related to one user catalog one one lpar and 
to a different user catalog on the other lpar, you will see this behavior as 
each lpar will supply the correct dataset for its catalog lookup.  When you 
supply the volser, the catalog lookup is bypassed - only the named volume is 
searched for the dataset.  You can confirm this is your issue by doing a IDCAMS 
listcat on each lpar. 



Linda 
- Original Message - 
From: "Dennis Longnecker"  
To: IBM-MAIN@bama.ua.edu 
Sent: Monday, May 18, 2009 1:53:48 PM GMT -08:00 US/Canada Pacific 
Subject: PDSE Anomaly? 

On my test lpar I applied some DB2 maintenance to a module.   I could browse 
the module and indeed the fix was on. 

On my production LPAR, I wanted to copy that module over to the product 
libraries, so I did a TSO =3.3 copy and placed it in the production load 
library.   I browsed that production load library, and the fix was not on.  I 
browsed the original library, and the fix was not on.  The original library is 
cataloged to the same volume (usercat), so I know it was pointing to the same 
place. 

I tried LLA, refreshes, inactivating LLA, and even IPL'ing, but could not see 
the fix on the load libraries from my production LPAR (still looked good in 
test). 

Finally, on the TSO =1 screen, I entered the dataset name AND the volser and 
then I could see that the fix was on.  I went out and went back in without 
specifying the volser, and the fix was STILL on. 

It appears it was cached or something, even through an IPL?   Any 
suggestions? 

Dennis 

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

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

Re: PDSE Anomaly?

[Linda Mooney]

Hi Dennis, 



Mark is right in his comments.  This could be bad if you are in a sysplex.  In 
my response I was assuming two monoplex lpars. 



Linda 
- Original Message - 
From: "Linda Mooney"  
To: IBM-MAIN@bama.ua.edu 
Sent: Monday, May 18, 2009 3:32:12 PM GMT -08:00 US/Canada Pacific 
Subject: Re: PDSE Anomaly? 

Hi Dennis, 



We have to watch out for this too.  If you have a same name dataset on two 
different lpars and the alias is related to one user catalog one one lpar and 
to a different user catalog on the other lpar, you will see this behavior as 
each lpar will supply the correct dataset for its catalog lookup.  When you 
supply the volser, the catalog lookup is bypassed - only the named volume is 
searched for the dataset.  You can confirm this is your issue by doing a IDCAMS 
listcat on each lpar. 



Linda 
- Original Message - 
From: "Dennis Longnecker"  
To: IBM-MAIN@bama.ua.edu 
Sent: Monday, May 18, 2009 1:53:48 PM GMT -08:00 US/Canada Pacific 
Subject: PDSE Anomaly? 

On my test lpar I applied some DB2 maintenance to a module.   I could browse 
the module and indeed the fix was on. 

On my production LPAR, I wanted to copy that module over to the product 
libraries, so I did a TSO =3.3 copy and placed it in the production load 
library.   I browsed that production load library, and the fix was not on.  I 
browsed the original library, and the fix was not on.  The original library is 
cataloged to the same volume (usercat), so I know it was pointing to the same 
place. 

I tried LLA, refreshes, inactivating LLA, and even IPL'ing, but could not see 
the fix on the load libraries from my production LPAR (still looked good in 
test). 

Finally, on the TSO =1 screen, I entered the dataset name AND the volser and 
then I could see that the fix was on.  I went out and went back in without 
specifying the volser, and the fix was STILL on. 

It appears it was cached or something, even through an IPL?   Any 
suggestions? 

Dennis 

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

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

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

Re: PDSE Anomaly?

[Longnecker, Dennis]

Exactly right two monoplex LPARS.

In my situation on

LPAR 1  DB2PROD.SDSNLOAD is cataloged on SYS033
LPAR 2  DB2PROD.SDSNLOAD is cataloged on SYS033

On LPAR 1, I copied a load module from DSN910.SDSNLOAD to the DB2PROD.SDSNLOAD 
library.

On LPAR 2, I could not see the updated load module in DB2PROD.SDSNLOAD (on 
sys033); even after LLA and after numerous IPL's.  ONLY after specifying the 
volser (SYS033) in the tso browse was it able to see the correct module.   
THEN, without specifying the volume serial number it displayed okay.

Confusing

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Linda Mooney
Sent: Monday, May 18, 2009 3:36 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: PDSE Anomaly?

Hi Dennis,



Mark is right in his comments.  This could be bad if you are in a sysplex.  In 
my response I was assuming two monoplex lpars.



Linda
- Original Message -
From: "Linda Mooney" 
To: IBM-MAIN@bama.ua.edu
Sent: Monday, May 18, 2009 3:32:12 PM GMT -08:00 US/Canada Pacific
Subject: Re: PDSE Anomaly?

Hi Dennis,



We have to watch out for this too.  If you have a same name dataset on two 
different lpars and the alias is related to one user catalog one one lpar and 
to a different user catalog on the other lpar, you will see this behavior as 
each lpar will supply the correct dataset for its catalog lookup.  When you 
supply the volser, the catalog lookup is bypassed - only the named volume is 
searched for the dataset.  You can confirm this is your issue by doing a IDCAMS 
listcat on each lpar.



Linda
- Original Message -
From: "Dennis Longnecker" 
To: IBM-MAIN@bama.ua.edu
Sent: Monday, May 18, 2009 1:53:48 PM GMT -08:00 US/Canada Pacific
Subject: PDSE Anomaly?

On my test lpar I applied some DB2 maintenance to a module.   I could browse 
the module and indeed the fix was on.

On my production LPAR, I wanted to copy that module over to the product 
libraries, so I did a TSO =3.3 copy and placed it in the production load 
library.   I browsed that production load library, and the fix was not on.  I 
browsed the original library, and the fix was not on.  The original library is 
cataloged to the same volume (usercat), so I know it was pointing to the same 
place.

I tried LLA, refreshes, inactivating LLA, and even IPL'ing, but could not see 
the fix on the load libraries from my production LPAR (still looked good in 
test).

Finally, on the TSO =1 screen, I entered the dataset name AND the volser and 
then I could see that the fix was on.  I went out and went back in without 
specifying the volser, and the fix was STILL on.

It appears it was cached or something, even through an IPL?   Any 
suggestions?

Dennis

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

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

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

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

Re: PDSE Anomaly?

[John McKown]

On Tue, 19 May 2009, Longnecker, Dennis wrote:

> Exactly right two monoplex LPARS.
> 
> In my situation on
> 
> LPAR 1  DB2PROD.SDSNLOAD is cataloged on SYS033
> LPAR 2  DB2PROD.SDSNLOAD is cataloged on SYS033
> 
> On LPAR 1, I copied a load module from DSN910.SDSNLOAD to the
> DB2PROD.SDSNLOAD library.
> 
> On LPAR 2, I could not see the updated load module in DB2PROD.SDSNLOAD
> (on sys033); even after LLA and after numerous IPL's.  ONLY after
> specifying the volser (SYS033) in the tso browse was it able to see the
> correct module.  THEN, without specifying the volume serial number it
> displayed okay.
> 
> Confusing
> 

Mainly because what you are doing is unsupported by IBM. So results are 
interesting. It is also a really good way to wipe out a PDSE entirely if 
you update it from both systems. Done that. I think the reason is that 
parts of the PDSE are buffered by z/OS and not immediately "hardened" to 
the DASD. This is why you cannot share a UNIX filesystem either in this 
situation.

-- 
Trying to write with a pencil that is dull is pointless.

Maranatha!
John McKown

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

Re: PDSE Anomaly?

[Kevin Mckenzie]

Read/write sharing of PDSEs between z/OS images not in the same sysplex is 
incredibly dangerous, and very much not supported.  What happens when you 
do share read/write between PDSEs is undefined; if you're lucky, you can 
recover, if you aren't, you have to restore the dataset from backup. 
Read-only sharing between images works, but is also not supported.

I don't think IBM has done enough to get this message out, because 
questions like this seem to pop up on a regular basis, but, very simply, 
do not make updates of any sort to a PDSE that is being shared beyond the 
boundaries of a sysplex.  SMS and other things cache data about the 
structure and contents of PDSEs, and they trust that the cached data 
matches reality, and if you make an update from outside the sysplex, the 
cached data does not match the contents of the PDSE, and at the least 
weird, and at the worst bad, things are pretty much guaranteed to happen. 
If possible, I'd suggest restoring your DB2PROD.SDSNLOAD from backup, and 
if you're going to make changes to it, only do so when all the images 
accessing it outside the bounds of the sysplex of the image making the 
update are down.  If that's not possible, you need to create multiple 
instances of DB2PROD.SDSNLOAD, one for each sysplex accessing it.
---
Kevin McKenzie

External Phone: 845-435-8282, Tie-line: 8-295-8282
z/OS BCP SVT, Dept FXKA, Bldg 706/2D38 



From:
"Longnecker, Dennis" 
To:
IBM-MAIN@bama.ua.edu
Date:
05/19/2009 07:01 PM
Subject:
Re: PDSE Anomaly?
Sent by:
IBM Mainframe Discussion List 



Exactly right two monoplex LPARS.

In my situation on

LPAR 1  DB2PROD.SDSNLOAD is cataloged on SYS033
LPAR 2  DB2PROD.SDSNLOAD is cataloged on SYS033

On LPAR 1, I copied a load module from DSN910.SDSNLOAD to the 
DB2PROD.SDSNLOAD library.

On LPAR 2, I could not see the updated load module in DB2PROD.SDSNLOAD (on 
sys033); even after LLA and after numeros IPL's.  ONLY after specifying 
the volser (SYS033) in the tso browse was it able to see the correct 
module.   THEN, without specifying the volume serial number it displayed 
okay.

Confusing

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On 
Behalf Of Linda Mooney
Sent: Monday, May 18, 2009 3:36 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: PDSE Anomaly?

Hi Dennis,



Mark is right in his comments.  This could be bad if you are in a sysplex. 
 In my response I was assuming two monoplex lpars.



Linda
- Original Message -
From: "Linda Mooney" 
To: IBM-MAIN@bama.ua.edu
Sent: Monday, May 18, 2009 3:32:12 PM GMT -08:00 US/Canada Pacific
Subject: Re: PDSE Anomaly?

Hi Dennis,



We have to watch out for this too.  If you have a same name dataset on two 
different lpars and the alias is related to one user catalog one one lpar 
and to a different user catalog on the other lpar, you will see this 
behavior as each lpar will supply the correct dataset for its catalog 
lookup.  When you supply the volser, the catalog lookup is bypassed - only 
the named volume is searched for the dataset.  You can confirm this is 
your issue by doing a IDCAMS listcat on each lpar.



Linda
- Original Message -
From: "Dennis Longnecker" 
To: IBM-MAIN@bama.ua.edu
Sent: Monday, May 18, 2009 1:53:48 PM GMT -08:00 US/Canada Pacific
Subject: PDSE Anomaly?

On my test lpar I applied some DB2 maintenance to a module.   I could 
browse the module and indeed the fix was on.

On my production LPAR, I wanted to copy that module over to the product 
libraries, so I did a TSO =3.3 copy and placed it in the production load 
library.   I browsed that production load library, and the fix was not on. 
 I browsed the original library, and the fix was not on.  The original 
library is cataloged to the same volume (usercat), so I know it was 
pointing to the same place.

I tried LLA, refreshes, inactivating LLA, and even IPL'ing, but could not 
see the fix on the load libraries from my production LPAR (still looked 
good in test).

Finally, on the TSO =1 screen, I entered the dataset name AND the volser 
and then I could see that the fix was on.  I went out and went back in 
without specifying the volser, and the fix was STILL on.

It appears it was cached or something, even through an IPL?   Any 
suggestions?

Dennis

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

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

--
For IBM-MAIN 

Re: PDSE Anomaly?

[Linda Mooney]

Hi Dennis, 



We have run a z/OS 2 lpar monoplex config for a long time .  We never share 
linklisted datasets or PDSEs between the lpars.  We never directly update a 
linklisted dataset from the other lpar.  Most of the linklisted datasets do 
have the same names in both lpars, catalogued only to the monoplex they belong 
to, on different DASD and those packs are online only to the lpar they belong 
to .  When I migrate a member or a library from test to production, I copy the 
members/ library to a shared pack and  then, from the shared pack copy to the 
linklist library.  I don't do the copies through TSO, I use batch.  I use batch 
for the audit trail and because it is my preference. 



If you are seeing indications of updates in PDSe cache that don't belong to the 
monplex, I would view that as a very risky condition.  



Linda 
- Original Message - 
From: "Dennis Longnecker"  
To: IBM-MAIN@bama.ua.edu 
Sent: Tuesday, May 19, 2009 3:52:34 PM GMT -08:00 US/Canada Pacific 
Subject: Re: PDSE Anomaly? 

Exactly right two monoplex LPARS. 

In my situation on 

LPAR 1  DB2PROD.SDSNLOAD is cataloged on SYS033 
LPAR 2  DB2PROD.SDSNLOAD is cataloged on SYS033 

On LPAR 1, I copied a load module from DSN910.SDSNLOAD to the DB2PROD.SDSNLOAD 
library. 

On LPAR 2, I could not see the updated load module in DB2PROD.SDSNLOAD (on 
sys033); even after LLA and after numerous IPL's.  ONLY after specifying the 
volser (SYS033) in the tso browse was it able to see the correct module.   
THEN, without specifying the volume serial number it displayed okay. 

Confusing 

-Original Message- 
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Linda Mooney 
Sent: Monday, May 18, 2009 3:36 PM 
To: IBM-MAIN@bama.ua.edu 
Subject: Re: PDSE Anomaly? 

Hi Dennis, 



Mark is right in his comments.  This could be bad if you are in a sysplex.  In 
my response I was assuming two monoplex lpars. 



Linda 
- Original Message - 
From: "Linda Mooney"  
To: IBM-MAIN@bama.ua.edu 
Sent: Monday, May 18, 2009 3:32:12 PM GMT -08:00 US/Canada Pacific 
Subject: Re: PDSE Anomaly? 

Hi Dennis, 



We have to watch out for this too.  If you have a same name dataset on two 
different lpars and the alias is related to one user catalog one one lpar and 
to a different user catalog on the other lpar, you will see this behavior as 
each lpar will supply the correct dataset for its catalog lookup.  When you 
supply the volser, the catalog lookup is bypassed - only the named volume is 
searched for the dataset.  You can confirm this is your issue by doing a IDCAMS 
listcat on each lpar. 



Linda 
- Original Message - 
From: "Dennis Longnecker"  
To: IBM-MAIN@bama.ua.edu 
Sent: Monday, May 18, 2009 1:53:48 PM GMT -08:00 US/Canada Pacific 
Subject: PDSE Anomaly? 

On my test lpar I applied some DB2 maintenance to a module.   I could browse 
the module and indeed the fix was on. 

On my production LPAR, I wanted to copy that module over to the product 
libraries, so I did a TSO =3.3 copy and placed it in the production load 
library.   I browsed that production load library, and the fix was not on.  I 
browsed the original library, and the fix was not on.  The original library is 
cataloged to the same volume (usercat), so I know it was pointing to the same 
place. 

I tried LLA, refreshes, inactivating LLA, and even IPL'ing, but could not see 
the fix on the load libraries from my production LPAR (still looked good in 
test). 

Finally, on the TSO =1 screen, I entered the dataset name AND the volser and 
then I could see that the fix was on.  I went out and went back in without 
specifying the volser, and the fix was STILL on. 

It appears it was cached or something, even through an IPL?   Any 
suggestions? 

Dennis 

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

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

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

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

-

Re: PDSE cache

[Rob Scott]

Miklos

Barbara Nitz has explored this area in great detail in various threads over the 
last few years.

Check the archives and read her posts - they are excellent.


Rob Scott
Lead Developer
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Miklos Szigetvari
Sent: 01 July 2011 14:53
To: IBM-MAIN@bama.ua.edu
Subject: PDSE cache

Hi

Started in zOS 1.11 the SMS PDSE1 address space with large cache, 
buffer_beyond_close  etc.
For my big surprise no any change in a program runtime, which is intensively 
using modules from PDSE libraries.

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

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

Re: PDSE cache

[Miklos Szigetvari]

Hi

Thank you, I will read her posts, but reading now it only works for SMS 
managed PDSE.

My PDSE's are not SMS managed.
D SMS,PDSE1,HSPSTATS says that  all my dataset 's are cache eligible.

On 7/1/2011 4:11 PM, Rob Scott wrote:

Miklos

Barbara Nitz has explored this area in great detail in various threads over the 
last few years.

Check the archives and read her posts - they are excellent.


Rob Scott
Lead Developer
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Miklos Szigetvari
Sent: 01 July 2011 14:53
To: IBM-MAIN@bama.ua.edu
Subject: PDSE cache

Hi

Started in zOS 1.11 the SMS PDSE1 address space with large cache, 
buffer_beyond_close  etc.
For my big surprise no any change in a program runtime, which is intensively 
using modules from PDSE libraries.

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

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



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

Re: PDSE cache

[Peter Relson]

Simple rule: if you want modules cached, the library needs to be managed 
by LLA.

If LLA deems the module cache-worthy then it will either do the caching 
using VLF or may notify PDSE processing to do it.

If I remember correctly, long ago, long before z/OS 1.11, PDSE processing 
used to try to cache almost everything. Then all of that caching was 
removed. And then it was put back for cases where LLA felt it worthwhile.

Peter Relson
z/OS Core Technology Design

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

Re: PDSE cache

[Miklos Szigetvari]

Hi

With LLA and load modules it works fine, but I would need to cache other 
type PDSE members(AFP resources ).
From the SMF 14 record cache section I see it was not from cache, but 
don't see the reason why and if I can change this .



On 7/2/2011 4:40 PM, Peter Relson wrote:

Simple rule: if you want modules cached, the library needs to be managed
by LLA.

If LLA deems the module cache-worthy then it will either do the caching
using VLF or may notify PDSE processing to do it.

If I remember correctly, long ago, long before z/OS 1.11, PDSE processing
used to try to cache almost everything. Then all of that caching was
removed. And then it was put back for cases where LLA felt it worthwhile.

Peter Relson
z/OS Core Technology Design

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




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

Re: PDSE cache

[Barbara Nitz]

>With LLA and load modules it works fine, but I would need to cache other
>type PDSE members(AFP resources ).
> From the SMF 14 record cache section I see it was not from cache, but
>don't see the reason why and if I can change this .

SMF Type 14 will NOT show you PDSE activity. PDSE have their own SMF record
that you will need to check.

Having said that, independent of SMS-management, if the complete size of the
PDSE members that you need to cache exceeds the maximum size of the PDSE
cache (16GB IIRC), you won't have any performance benefit, as only the most
used members will stay in that cache. And if they are all evenly used,
you'll get thrashing.

In addition, beware recfm V in any shape or size. PDSE development told me
that that will require extra I/O every time due to some sort of internal
organization. (That I understand they have no plans of changing).

How many members in your PDSE(s)? What is the size of the PDSE(s)? How long
does it take to do an ISPF 3.4 from enter to seeing the directory?

Regards, Barbara

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

Re: PDSE cache

[Miklos Szigetvari]

Hi

Thank you Barbara, I see you are the proper expert in this field
In my SMF 14 records there is the PDSE  Statistic section, and I see the 
directory cache hits , but no data member

hits.
It is a AFP resource library (not SMS managed) , 600 members and all are 
relatively small (1 -4 K bytes), but a server application opens again 
and again.

I hope to set the proper SMS PDSE1 options


On 7/4/2011 9:41 AM, Barbara Nitz wrote:

With LLA and load modules it works fine, but I would need to cache other
type PDSE members(AFP resources ).
 From the SMF 14 record cache section I see it was not from cache, but
don't see the reason why and if I can change this .

SMF Type 14 will NOT show you PDSE activity. PDSE have their own SMF record
that you will need to check.

Having said that, independent of SMS-management, if the complete size of the
PDSE members that you need to cache exceeds the maximum size of the PDSE
cache (16GB IIRC), you won't have any performance benefit, as only the most
used members will stay in that cache. And if they are all evenly used,
you'll get thrashing.

In addition, beware recfm V in any shape or size. PDSE development told me
that that will require extra I/O every time due to some sort of internal
organization. (That I understand they have no plans of changing).

How many members in your PDSE(s)? What is the size of the PDSE(s)? How long
does it take to do an ISPF 3.4 from enter to seeing the directory?

Regards, Barbara

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




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

Re: PDSE cache

[Barbara Nitz]

>In my SMF 14 records there is the PDSE  Statistic section, and I see the
>directory cache hits , but no data member hits.
>It is a AFP resource library (not SMS managed) , 600 members and all are
>relatively small (1 -4 K bytes), but a server application opens again
>and again.
>I hope to set the proper SMS PDSE1 options

How long does a 3.4 of the PDSE take? 
Barbara

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

Re: PDSE cache

[Miklos Szigetvari]

On 7/4/2011 1:49 PM, Barbara Nitz wrote:

In my SMF 14 records there is the PDSE  Statistic section, and I see the
directory cache hits , but no data member hits.
It is a AFP resource library (not SMS managed) , 600 members and all are
relatively small (1 -4 K bytes), but a server application opens again
and again.
I hope to set the proper SMS PDSE1 options

How long does a 3.4 of the PDSE take?
Barbara

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


The dataset is not too big (555 members), the directory list is very 
fast (immediatly got the reply) .
Seems the directory cache active, but the membe data cache only for SMS 
managed datasets .


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

Re: PDSE cache

[Elmer Latorre]

Hi Miklos,
Adding to Peter Relson's mail.
Member data for Non-SMS PDSEs are not cached. 
If The PDSE is not a pogram object then it must be an SMS managed for 
member caching to occur and the sequential response in the storage clase 
must be set to a very low value.

Elmer Latorre
PDSE Devepment Team 

On 7/2/2011 4:40 PM, Peter Relson wrote:
> Simple rule: if you want modules cached, the library needs to be managed
> by LLA.
>
> If LLA deems the module cache-worthy then it will either do the caching
> using VLF or may notify PDSE processing to do it.
>
> If I remember correctly, long ago, long before z/OS 1.11, PDSE processing
> used to try to cache almost everything. Then all of that caching was
> removed. And then it was put back for cases where LLA felt it worthwhile.
>
> Peter Relson
> z/OS Core Technology Design
>

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

Re: PDSE cache

[Miklos Szigetvari]

Hi

Thank you.
Exactly the same as our experience has shown.

The point I don't understand , after activate PDSE cache for non SMS
i.e the directory cache should work, we didn't noticed any performance 
change, but after put the

libraries into LLA, the improvement was dramatic .

We have some PDSE's opened very often by a server, we hope some 
performance after putting to SMS managed volumes.



On 7/5/2011 7:58 PM, Elmer Latorre wrote:

Hi Miklos,
Adding to Peter Relson's mail.
Member data for Non-SMS PDSEs are not cached.
If The PDSE is not a pogram object then it must be an SMS managed for
member caching to occur and the sequential response in the storage clase
must be set to a very low value.

Elmer Latorre
PDSE Devepment Team

On 7/2/2011 4:40 PM, Peter Relson wrote:

Simple rule: if you want modules cached, the library needs to be managed
by LLA.

If LLA deems the module cache-worthy then it will either do the caching
using VLF or may notify PDSE processing to do it.

If I remember correctly, long ago, long before z/OS 1.11, PDSE processing
used to try to cache almost everything. Then all of that caching was
removed. And then it was put back for cases where LLA felt it worthwhile.

Peter Relson
z/OS Core Technology Design


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




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

Re: PDSE Performance

[Starr, Alan]

Hi George,

I believe that the answer to your question is a qualified "yes". I believe that 
the time lapse is due to infrequent OPENs of the PDSE. Thus, the directory has 
to be read, in its entirety, into cache (a data space). Once the directory 
resides in cache, subsequent member lists are speedy until the dataset is 
closed (and its directory is purged from cache).

There are statements in IGDSMSxx that may help:

PDSE_DIRECTORY_STORAGE(16G)causes the data space cache for directories to 
be the maximum size.
PDSE_BUFFER_BEYOND_CLOSE (YES) causes directory entries to be retained after 
the dataset is closed.

Both of the above can be set dynamically via a command (I'm almost sure)

I believe that the latter statement causes directory entries to be retained for 
up to 15 minutes after the dataset has been closed. Note that, if you have 
multiple systems sharing the PDSE, updates to the directory in an LPAR will NOT 
be propagated to all sharing LPARs (i.e. because data spaces are not shared 
between LPARs).

Regards,
Alan

 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
George Mosley
Sent: Thursday, August 12, 2010 09:59
To: IBM-MAIN@bama.ua.edu
Subject: PDSE Performance

I know there has been plenty of previous discussion on this topic. However, I 
couldn't find a simple answer to what I'm after.
We have a relatively small number of large PDSE's (25-30K members) that take 
inordinately long to bring up member lists for (PDF 3.4) - ~20 seconds or more 
on the first go-round. Timing drops to 3-4 seconds on subsequent accesses in 
same session.
Is there anything simple in terms of blocking, allocation (primary vs 
secondary), etc. that would impact performance and could be easily tuned?
Thanks.
George Mosley

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

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

Re: PDSE Performance

[Hank Oerlemans]

See if  http://www.redbooks.ibm.com/abstracts/sg246106.html?Open  is 
helpful.

Hank O




From:   George Mosley 
To: IBM-MAIN@bama.ua.edu
Date:   13/08/2010 03:12 AM
Subject:PDSE Performance
Sent by:IBM Mainframe Discussion List 



I know there has been plenty of previous discussion on this topic. 
However, I 
couldn't find a simple answer to what I'm after.
We have a relatively small number of large PDSE's (25-30K members) that 
take 
inordinately long to bring up member lists for (PDF 3.4) - ~20 seconds or 
more 
on the first go-round. Timing drops to 3-4 seconds on subsequent accesses 
in 
same session.
Is there anything simple in terms of blocking, allocation (primary vs 
secondary), etc. that would impact performance and could be easily tuned?
Thanks.
George Mosley

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


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

Re: PDSE Performance

[Barbara Nitz]

>I know there has been plenty of previous discussion on this topic. However, I
>couldn't find a simple answer to what I'm after.
>We have a relatively small number of large PDSE's (25-30K members) that 
take
>inordinately long to bring up member lists for (PDF 3.4) - ~20 seconds or more
>on the first go-round. Timing drops to 3-4 seconds on subsequent accesses in
>same session.
>Is there anything simple in terms of blocking, allocation (primary vs
>secondary), etc. that would impact performance and could be easily tuned?

Contrary to what Alan Starr said, my answer is a simple and definite NO. Here's 
why:
Bringing up the ISPF 3.4 screen for the first time means that basically the 
complete PDSE is read. The directory is spread out, and I assume that the 
next 'directory entry' (or rather, the next 4K block containing directory 
information) can only be found by reading the predecessor. In my case (10K 
member that are all large) it takes more than 1 IO's per dataset to get 
the first 3.4 screen. That time is basically IO time, and I wait around 
90seconds. Your members appear to be smaller than mine, so you don't wait 
as long.
BUFFER_BEYOND_CLOSE is useless. We do have it on, both for SMSPDSE1 and 
SMSPDSE. Our directory caching is set to take the default of 2G (come on, 
how large can a *directory* be ?!? ), and it does NOT cache entries. Unless I 
have my small 'keep-it-open' program running, in my case the second ISPF 3.4 
takes as long as the first. And as Alan said, even my program only helps for 
the first less than 15 minutes, per system.

I also *assume* (but don't know how to verify that) that in our case the 2G 
directory cache is severely insufficient, as I think PDSE keeps the whole 4K 
block (where *something* small is directory information) in that cache. 
Considering that we have about 10 of those beasties, all in the 5500-6000cyl 
range, not even a maximum of 16GB cache would help us, not to mention that 
16GB of virtual storage actually *used* would cause an inordinate amount of 
paging (and in our case, DFSORTs usage of 6GB for sort jobs lets us hit the 
30% warning threshold that health checker screams about).

But your enquiry came at a very opportune time, as I am finally getting a 
discussion with the PDSE developers next week to discuss and address this 
exact same problem, bypassing the usual ETR and the 'please put on all 
available maintenance' crap. So stay tuned. And if others have the same 
problem, please speak up, as that will give me ammunition in that talk. I 
suspect that solving this performance issue will require a major design change 
on PDSEs part.

Best regards, Barbara Nitz

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

Re: PDSE Performance

[Gerald Scharitzer]

Dear Colleagues,

if I remember correctly, then the directory structure of PDSEs was designed
to speed up finding specific members as opposed to listing the entire
directory.

To my best of knowledge the directory structure of PDSs is sequential
(ordered list) while for PDSEs it is hierarchical (tree-based).
Theoretically, finding a specific member should therefore result in linear
(O(n)) effort for PDSs and logarithmic effort (O(log n)) for PDSEs. Does
anybody have any measurements on that and would like to share it with us?

I guess the main purpose of PDSEs is to serve as program libraries and in
many cases doing this in library concatenations, which are searched for
specific programs by the loader. On the contrary it is not obvious for me,
which use case requires listing a directory of 25K to 30K members
efficiently, but maybe you can update me on that.

The bad directory listing performance probably stems from the index pages
being scattered across the entire PDSE instead of being nicely ordered at
the beginning of the dataset. Does copying and thus defragmenting the
library also reorganize the index pages?

  Kind regards

  Gerald Scharitzer

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

Re: PDSE Performance

[Gerald Scharitzer]

Dear Colleagues,

if I remember correctly, then the directory structure of PDSEs was
designed to speed up finding specific members as opposed to listing
the entire directory.

To my best of knowledge the directory structure of PDSs is sequential
(ordered list) while for PDSEs it is hierarchical (tree-based).
Theoretically, finding a specific member should therefore result in
linear (O(n)) effort for PDSs and logarithmic effort (O(log n)) for
PDSEs. Does anybody have any measurements on that and would like to
share it with us?

I guess the main purpose of PDSEs is to serve as program libraries and
in many cases doing this in library concatenations, which are searched
for specific programs by the loader. On the contrary it is not obvious
for me, which use case requires listing a directory of 25K to 30K
members efficiently, but maybe you can update me on that.

The bad directory listing performance probably stems from the index
pages being scattered across the entire PDSE instead of being nicely
ordered at the beginning of the dataset. Does copying and thus
defragmenting the library also reorganize the index pages?

  Kind regards

  Gerald Scharitzer

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

Re: PDSE Performance

[Barbara Nitz]

>if I remember correctly, then the directory structure of PDSEs was
>designed to speed up finding specific members as opposed to listing
>the entire directory.

In my opinion, waiting 90 seconds for a sequential read is too long, no matter 
what the objective was. Considering that PDSEs are the only ones that can 
have more than 65K tracks in the primary allocation, it is NOT acceptable. 

And our heavy user (IBMs fault analyzer for sidefiles) regularly gets the 
'there 
may be a PDSE problem' and once you issue the command, it shows that it is 
one of those large ones. Besides, Fault Analyzer stops interactive analysis 
after 10 minutes being stuck, and whenever I looked at the resulting dump, FA 
was stuck in I/O operations, which is supposedly benefitting from the 
hierarchical stuff. It isn't.

>The bad directory listing performance probably stems from the index
>pages being scattered across the entire PDSE instead of being nicely
>ordered at the beginning of the dataset. Does copying and thus
>defragmenting the library also reorganize the index pages?

No. It used to, a few years back I routinely recopied the large datasets and 
that boosted performance. That was *before* BUFFER_BEYOND_CLOSE. These 
days, a copy of one of the large ones takes up to 90 minutes, and it does not 
make it one second faster after the copy. Using ISPF 3.4 to measure and test 
is just a nice, reproducible test case.

Regards, Barbara Nitz

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

Re: PDSE Performance

[Richard Peurifoy]

On 8/12/2010 11:42 PM, Barbara Nitz wrote:


BUFFER_BEYOND_CLOSE is useless. We do have it on, both for SMSPDSE1 and
SMSPDSE. Our directory caching is set to take the default of 2G (come on,
how large can a *directory* be ?!? ), and it does NOT cache entries. Unless I
have my small 'keep-it-open' program running, in my case the second ISPF 3.4
takes as long as the first. And as Alan said, even my program only helps for
the first less than 15 minutes, per system.


Barbara,

I am curious if you have tried having your 'keep-it-open' program
close and re-open the file every 10 min? Or maybe try having the
program issue a DESERV to read the directory every 10 min. Seems
silly to have to do something like this, but maybe it would get
the system to keep the directory cached.

--
Richard

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

Re: PDSE Performance

[Barbara Nitz]

>I am curious if you have tried having your 'keep-it-open' program
>close and re-open the file every 10 min? Or maybe try having the
>program issue a DESERV to read the directory every 10 min. Seems
>silly to have to do something like this, but maybe it would get
>the system to keep the directory cached.

No, I didn't. close and open itself doesn't really help, it just keeps 
the 'connection' to the PDSE. *Someone* has to go and really read the 
directory to get it into cache, and a sequential reading of the directory for 
all 
of the affected datasets here takes about 45 minutes, way more than the 15 
minutes maximum the caching effect lasts, so I didn't bother. Remember, I 
have about 26 of those big beasties.

For what it's worth, *right now* buffer_beyond_close appears to work. But 
we've had that before, and then at some point it stopped again. So I am just 
waiting and this time around will pounce when it doesn't work. The task is to 
take a dump about 5 minutes after the closing of the dataset. 

And I was told that in my case the VB format of the members is the reason for 
the slow reading of the directory, as apparently for VB there is a lot more I/O 
going on. It would explain why I saw more than 1 I/Os for the job when 
I 'only' had 1 member in it. The jury's out on that, but at least I now 
have 
an ETR open for this.  (Plus my other guesses about what happens were more 
or less right, not that that is any consolation.)

Best regards, Barbara

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

Re: PDSE Help!

[Mark Zelden]

On Mon, 18 Aug 2008 15:49:03 -0400, Ken Porowski <[EMAIL PROTECTED]> wrote:

>I have a PDSE in linklist on one plex and not referenced on another
>plex.  
>The PDSE was updated from the plex not using it (all shared dasd).
>An LLA refresh was performed on one system of the using plex.
>Task which uses the lib gets the 'old' members.
>I do not run restartable SMSPDSE1.
>
>Attempting a member list gets an IEC036I 002-A4.
>
>Any easy way to fix this?
>
>Yes, I know I wasn't supposed to do this but I forgot it was a PDSE.
>
>TIA

Probably S.O.L.  But I would try removing the library from LLA control
on all systems where it may be managed - CSVLLAxx with
REMOVE(data.set) and F LLA,UPDATE=XX (if it is in the lnklst it *is* being
managed). Then rebuild a new lnklst set from the current.  Then re-updating
the library from the plex where it is being used.  Then re-add to LLA.

Let us know if you ever get it to work without an IPL.  

--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS 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

Re: PDSE Help!

[Mark Zelden]

On Mon, 18 Aug 2008 15:20:37 -0500, Mark Zelden <[EMAIL PROTECTED]>
wrote:

>On Mon, 18 Aug 2008 15:49:03 -0400, Ken Porowski <[EMAIL PROTECTED]> wrote:
>
>>I have a PDSE in linklist on one plex and not referenced on another
>>plex.
>>The PDSE was updated from the plex not using it (all shared dasd).
>>An LLA refresh was performed on one system of the using plex.
>>Task which uses the lib gets the 'old' members.
>>I do not run restartable SMSPDSE1.
>>
>>Attempting a member list gets an IEC036I 002-A4.
>>
>>Any easy way to fix this?
>>
>>Yes, I know I wasn't supposed to do this but I forgot it was a PDSE.
>>
>>TIA
>
>Probably S.O.L.  But I would try removing the library from LLA control
>on all systems where it may be managed - CSVLLAxx with
>REMOVE(data.set) and F LLA,UPDATE=XX (if it is in the lnklst it *is* being
>managed). Then rebuild a new lnklst set from the current.  Then re-updating
>the library from the plex where it is being used.  Then re-add to LLA.
>
>Let us know if you ever get it to work without an IPL.
>
>--

The new lnklst I mentioned above would also be on all sharing systems.
If that task can't be restarted, you also would need to do a
"SETPROG LNKLST,UPDATE,JOB=whatever"  .

--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS 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

Re: PDSE Help!

[Ken Porowski]

Could I try

SETPROG LINKLIST,UNALLOCATE on all systems in the plex
P LLA on all systems in the plex
Empty and reload the PDSE with the correct members (I fear my update
from another system may have broken it)
S LLA,SUB=MSTR
SETPROG LINKLIST,ALLOCATE
 
All the above with the task that would be using the PDSE down.

Should/will this work?

Would PDSESHARING(EXTENDED) really do anything for me?  It seems like
the restartable SMSPDSE1 does not work for linklisted PDSEs.
 
My RTFM and IBM-MAIN searches seem to imply that attempting to refresh a
Linklisted PDSE does not work.

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Mark Zelden
Sent: Monday, August 18, 2008 4:21 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: [IBM-MAIN] PDSE Help!

On Mon, 18 Aug 2008 15:49:03 -0400, Ken Porowski <[EMAIL PROTECTED]>
wrote:

>I have a PDSE in linklist on one plex and not referenced on another 
>plex.
>The PDSE was updated from the plex not using it (all shared dasd).
>An LLA refresh was performed on one system of the using plex.
>Task which uses the lib gets the 'old' members.
>I do not run restartable SMSPDSE1.
>
>Attempting a member list gets an IEC036I 002-A4.
>
>Any easy way to fix this?
>
>Yes, I know I wasn't supposed to do this but I forgot it was a PDSE.
>
>TIA

Probably S.O.L.  But I would try removing the library from LLA control
on all systems where it may be managed - CSVLLAxx with
REMOVE(data.set) and F LLA,UPDATE=XX (if it is in the lnklst it *is*
being managed). Then rebuild a new lnklst set from the current.  Then
re-updating the library from the plex where it is being used.  Then
re-add to LLA.

Let us know if you ever get it to work without an IPL.  

--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead Zurich North America
/ Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED]
z/OS 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

--
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: PDSE Help!

[Mark Zelden]

On Mon, 18 Aug 2008 15:30:29 -0500, Mark Zelden <[EMAIL PROTECTED]>
wrote:

>On Mon, 18 Aug 2008 15:20:37 -0500, Mark Zelden <[EMAIL PROTECTED]>
>wrote:
>
>>On Mon, 18 Aug 2008 15:49:03 -0400, Ken Porowski <[EMAIL PROTECTED]> wrote:
>>
>>>I have a PDSE in linklist on one plex and not referenced on another
>>>plex.
>>>The PDSE was updated from the plex not using it (all shared dasd).
>>>An LLA refresh was performed on one system of the using plex.
>>>Task which uses the lib gets the 'old' members.
>>>I do not run restartable SMSPDSE1.
>>>
>>>Attempting a member list gets an IEC036I 002-A4.
>>>
>>>Any easy way to fix this?
>>>
>>>Yes, I know I wasn't supposed to do this but I forgot it was a PDSE.
>>>
>>>TIA
>>
>>Probably S.O.L.  But I would try removing the library from LLA control
>>on all systems where it may be managed - CSVLLAxx with
>>REMOVE(data.set) and F LLA,UPDATE=XX (if it is in the lnklst it *is* being
>>managed). Then rebuild a new lnklst set from the current.  Then re-updating
>>the library from the plex where it is being used.  Then re-add to LLA.
>>
>>Let us know if you ever get it to work without an IPL.
>>
>>--
>
>The new lnklst I mentioned above would also be on all sharing systems.
>If that task can't be restarted, you also would need to do a
>"SETPROG LNKLST,UPDATE,JOB=whatever"  .
>

Still thinking...   

I have seen issues in trying to fix PDSE related LNKLST / LLA issues when
the library name doesn't change.   Since this is a LNKLST data set, why
not restore or copy from a good copy to a new name (from the correct
sysplex of course), re-update,  then create a new lnklst set using that
new name, then SETPROG LNKLST,UPDATE,JOB=whatever for the task
that is having the problem.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Mark

--
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: PDSE Help!

[Mark Zelden]

On Mon, 18 Aug 2008 16:34:26 -0400, Ken Porowski <[EMAIL PROTECTED]> wrote:

>Could I try
>
>SETPROG LINKLIST,UNALLOCATE on all systems in the plex


Doesn't actually do anything but release the ENQ.

--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS 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

Re: PDSE Help!

[Ken Porowski]

But it would let me update the PDSE that is in linklist on all members
of the plex (although only actually used on one of them). 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Mark Zelden
Sent: Monday, August 18, 2008 4:38 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: [IBM-MAIN] PDSE Help!

On Mon, 18 Aug 2008 16:34:26 -0400, Ken Porowski <[EMAIL PROTECTED]>
wrote:

>Could I try
>
>SETPROG LINKLIST,UNALLOCATE on all systems in the plex


Doesn't actually do anything but release the ENQ.

--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead Zurich North America
/ Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED]
z/OS 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

--
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: PDSE Help!

[Kevin Mckenzie]

You could try this (haven't tested it, but I think it should work, 
assuming you haven't made any changes to the PDSE on the plex that has it 
in linklist):  remove PDSE from LLA and linklist.  On the system you made 
the change from, copy the contents of the PDSE into a new PDSE, accessible 
from both systems.  Add the new PDSE to LLA and linklist on the original 
plex.  If you've made changes from both plexes, I don't think there's any 
good way to recover.

Kevin McKenzie

External Phone: 845-435-8282, Tie-line: 8-295-8282
z/OS BCP SVT, Dept FXKA, Bldg 706/2D38 



From:
Ken Porowski <[EMAIL PROTECTED]>
To:
IBM-MAIN@BAMA.UA.EDU
Date:
08/18/2008 03:50 PM
Subject:
PDSE Help!



I have a PDSE in linklist on one plex and not referenced on another
plex. 
The PDSE was updated from the plex not using it (all shared dasd).
An LLA refresh was performed on one system of the using plex.
Task which uses the lib gets the 'old' members.
I do not run restartable SMSPDSE1.

Attempting a member list gets an IEC036I 002-A4.

Any easy way to fix this?

Yes, I know I wasn't supposed to do this but I forgot it was a PDSE.

TIA

Ken Porowski
AVP Systems Software
CIT Group
V: 973-740-5459
E: [EMAIL PROTECTED]



--
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



--
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: PDSE Help!

[Ken Porowski]

Changes were only performed from the plex without the PDSE in linklist,
all I want is for the other plex to be able to pick up the changes.
Easy to do with a PDS, why so difficult with a PDSE? 

-Original Message-
Kevin Mckenzie

You could try this (haven't tested it, but I think it should work,
assuming you haven't made any changes to the PDSE on the plex that has
it in linklist):  remove PDSE from LLA and linklist.  On the system you
made the change from, copy the contents of the PDSE into a new PDSE,
accessible from both systems.  Add the new PDSE to LLA and linklist on
the original plex.  If you've made changes from both plexes, I don't
think there's any good way to recover.

Kevin McKenzie


Ken Porowski <

I have a PDSE in linklist on one plex and not referenced on another
plex. 
The PDSE was updated from the plex not using it (all shared dasd).
An LLA refresh was performed on one system of the using plex.
Task which uses the lib gets the 'old' members.
I do not run restartable SMSPDSE1.

Attempting a member list gets an IEC036I 002-A4.

Any easy way to fix this?

Yes, I know I wasn't supposed to do this but I forgot it was a PDSE.

TIA

--
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: PDSE Help!

[Ken Porowski]

With PDSE_BUFFER_BEYOND_CLOSE = NO does the linklist OPEN essentially
negate this because the PDSE will never be closed (unless I allocate a
new linklist set and force all tasks to use it).  

-Original Message-
Porowski, Ken

Changes were only performed from the plex without the PDSE in linklist,
all I want is for the other plex to be able to pick up the changes.
Easy to do with a PDS, why so difficult with a PDSE? 

-Original Message-
Kevin Mckenzie

You could try this (haven't tested it, but I think it should work,
assuming you haven't made any changes to the PDSE on the plex that has
it in linklist):  remove PDSE from LLA and linklist.  On the system you
made the change from, copy the contents of the PDSE into a new PDSE,
accessible from both systems.  Add the new PDSE to LLA and linklist on
the original plex.  If you've made changes from both plexes, I don't
think there's any good way to recover.

Kevin McKenzie


Ken Porowski <

I have a PDSE in linklist on one plex and not referenced on another
plex. 
The PDSE was updated from the plex not using it (all shared dasd).
An LLA refresh was performed on one system of the using plex.
Task which uses the lib gets the 'old' members.
I do not run restartable SMSPDSE1.

Attempting a member list gets an IEC036I 002-A4.

Any easy way to fix this?

Yes, I know I wasn't supposed to do this but I forgot it was a PDSE.

TIA

--
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: PDSE Help!

[Mark Zelden]

On Mon, 18 Aug 2008 16:45:32 -0400, Ken Porowski <[EMAIL PROTECTED]> wrote:

>Changes were only performed from the plex without the PDSE in linklist,
>all I want is for the other plex to be able to pick up the changes.
>Easy to do with a PDS, why so difficult with a PDSE?
>

Because the changes to the space map are communicated via XCF, which of
course means within the sysplex only.   

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS 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

Re: PDSE Help!

[Ken Porowski]

 
From: Porowski, Ken 

PLEX-1 has PDSE in linklist
PLEX-2 does not have PDSE in linklist
IEBCOPY with DISP=SHR run on PLEX-1 and got  213-70 IEBCOPY with
DISP=SHR run on PLEX-2 ran clean LLA refresh on PLEX-1 Bounced task
using PDSE (via linklist) on PLEX-1 (one system only, all others will
not reference the PDSE) Task using PDSE does not get new members.

Currently 'fixed' by allocating a new PDSE and loading it with the
updated members.
Allocated a new linklist set replacing the 'bad' PDSE with the new one.
Activated the new linklist set on all members of PLEX-1 SETPROG
LNKLST,UPDATE,JOB=*

On a different member of PLEX-1 I tried (before the 'fix' mentioned
above) P LLA SETPROG LNKLST,UNALLOCATE S LLA,SUB=MSTR SETPROG
LNKLST,ALLOCATE This was definitely the wrong move, LLA would not
initialize because of the 'broken' PDSE Linklist unable to find modules
Abends all over the place.
ABEND0F4 RSN24
ABEND023 RSN17
ABEND023 RSN201
212-00 on DUMPSRV
Do not try this at home!

Fixed for now but I wonder what is the 'proper' way of handling a PDSE
in linklist?

--
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: PDSE Help!

[Kevin Mckenzie]

The proper way of handling a PDSE anywhere is after interacting with it on 
a given plex, not to make changes to it from another plex.  You can share 
PDSE's read-only, but never read-write.  We've been burned by that on many 
occasions within System Test. 

Kevin McKenzie

External Phone: 845-435-8282, Tie-line: 8-295-8282
z/OS BCP SVT, Dept FXKA, Bldg 706/2D38 



From:
Ken Porowski <[EMAIL PROTECTED]>
To:
IBM-MAIN@BAMA.UA.EDU
Date:
08/18/2008 06:25 PM
Subject:
Re: PDSE Help!



 
From: Porowski, Ken 

PLEX-1 has PDSE in linklist
PLEX-2 does not have PDSE in linklist
IEBCOPY with DISP=SHR run on PLEX-1 and got  213-70 IEBCOPY with
DISP=SHR run on PLEX-2 ran clean LLA refresh on PLEX-1 Bounced task
using PDSE (via linklist) on PLEX-1 (one system only, all others will
not reference the PDSE) Task using PDSE does not get new members.

Currently 'fixed' by allocating a new PDSE and loading it with the
updated members.
Allocated a new linklist set replacing the 'bad' PDSE with the new one.
Activated the new linklist set on all members of PLEX-1 SETPROG
LNKLST,UPDATE,JOB=*

On a different member of PLEX-1 I tried (before the 'fix' mentioned
above) P LLA SETPROG LNKLST,UNALLOCATE S LLA,SUB=MSTR SETPROG
LNKLST,ALLOCATE This was definitely the wrong move, LLA would not
initialize because of the 'broken' PDSE Linklist unable to find modules
Abends all over the place.
ABEND0F4 RSN24
ABEND023 RSN17
ABEND023 RSN201
212-00 on DUMPSRV
Do not try this at home!

Fixed for now but I wonder what is the 'proper' way of handling a PDSE
in linklist?

--
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



--
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: PDSE Help!

[Mark Zelden]

On Mon, 18 Aug 2008 18:24:02 -0400, Ken Porowski <[EMAIL PROTECTED]> wrote:

>
>From: Porowski, Ken
>
>PLEX-1 has PDSE in linklist
>PLEX-2 does not have PDSE in linklist
>IEBCOPY with DISP=SHR run on PLEX-1 and got  213-70 IEBCOPY with
>DISP=SHR run on PLEX-2 ran clean LLA refresh on PLEX-1 Bounced task
>using PDSE (via linklist) on PLEX-1 (one system only, all others will
>not reference the PDSE) Task using PDSE does not get new members.
>
>Currently 'fixed' by allocating a new PDSE and loading it with the
>updated members.
>Allocated a new linklist set replacing the 'bad' PDSE with the new one.
>Activated the new linklist set on all members of PLEX-1 SETPROG
>LNKLST,UPDATE,JOB=*
>
>On a different member of PLEX-1 I tried (before the 'fix' mentioned
>above) P LLA SETPROG LNKLST,UNALLOCATE S LLA,SUB=MSTR SETPROG
>LNKLST,ALLOCATE This was definitely the wrong move, LLA would not
>initialize because of the 'broken' PDSE Linklist unable to find modules
>Abends all over the place.
>ABEND0F4 RSN24
>ABEND023 RSN17
>ABEND023 RSN201
>212-00 on DUMPSRV
>Do not try this at home!


213-70:  OPEN detected a cross-system share conflict for the PDSE.  

If you did it in the order you described, there must have been some kind
of reference from plex-2.

>
>Fixed for now but I wonder what is the 'proper' way of handling a PDSE
>in linklist?
>

Don't share PDSE from another sysplex at all.  If you do break the rules by
sharing (which we do)... then it can be shared READ only.  Period.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS 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

Re: PDSE Clarification

[Steven Conway]

1.  No.

2.  No more or less than with a PDS.

3.  Shudder.  DON'T do that.  PDSEs shared across sysplex boundaries WILL 
be corrupted.

4.  

Steve Conway
Lead Systems Programmer
Information Systems & Services Division
Computer & Network Operations
Phone:   (703) 450-3156
Fax:(703) 450-3197



   "Sivakumar, Manikandan" <[EMAIL PROTECTED]> 
   Sent by: IBM Mainframe Discussion List 
   05/19/2008 08:39 AM
   Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@BAMA.UA.EDU
cc

Subject
PDSE Clarification






Greetings Folks,

 

I would appreciate if you clarify my following queries on PDSE. As
vendor start using the load library in PDSE format I need all your
valuable suggestions.

 

1. Should PDSE Load Libraries  that reside in LNKLST be allocated
with secondary space specified?

If YES, why and what potential problems may occur? (Normally we never
allocate secondary space to our LNKLST datasets because of potential
problems which leads to abend=s106)

2. What procedures & precautions should we follow to update a PDSE
Load Library that is shared among all the systems in a single SYSPLEX
and 

the load library also resides in the LNKLST of all the systems in this
single SYSPLEX?

3. What procedures & precautions should we follow to update a PDSE
loadlib that is in the LNKLST and shared across multi SYSPLEX's?

4. Please explain the ramifications of the "PDSESHARING" parm
settings.

 

Thanks in advance.

 

Regards, Mani

 

 



The information contained in this transmission may contain privileged and 
confidential information and is intended only for the use of the person(s) 
named above. If you are not the intended recipient, any review, 
dissemination, distribution or duplication of this communication is 
strictly prohibited. If you received this email in error, please contact 
the sender immediately by reply e-mail and destroy all copies of the 
original message. This email is not intended as an offer or solicitation 
for the purchase or sale of any financial instruments.

--
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



--
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: PDSE Clarification

[Knutson, Sam]

1. YES.  Unlike PDS if a PDSE in link list takes an extent fetches will
continue to work correctly.  Unlike a PDS a PDSE only counts as 1 extent
event though it make take up to 123 extents of physical space.


Best Regards, 

Sam Knutson, GEICO 
System z Performance and Availability Management 
mailto:[EMAIL PROTECTED] 
(office)  301.986.3574  

"Think big, act bold, start simple, grow fast..." 


   "Sivakumar, Manikandan" <[EMAIL PROTECTED]> 
   Sent by: IBM Mainframe Discussion List 
   05/19/2008 08:39 AM
   Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@BAMA.UA.EDU
cc

Subject
PDSE Clarification






Greetings Folks,

 

I would appreciate if you clarify my following queries on PDSE. As
vendor start using the load library in PDSE format I need all your
valuable suggestions.

 

1. Should PDSE Load Libraries  that reside in LNKLST be allocated
with secondary space specified?

If YES, why and what potential problems may occur? (Normally we never
allocate secondary space to our LNKLST datasets because of potential
problems which leads to abend=s106)

2. What procedures & precautions should we follow to update a PDSE
Load Library that is shared among all the systems in a single SYSPLEX
and 

the load library also resides in the LNKLST of all the systems in this
single SYSPLEX?

3. What procedures & precautions should we follow to update a PDSE
loadlib that is in the LNKLST and shared across multi SYSPLEX's?

4. Please explain the ramifications of the "PDSESHARING" parm
settings.

 

Thanks in advance.

 

Regards, Mani

 

This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

--
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: PDSE Clarification

[Mark Zelden]

On Mon, 19 May 2008 09:10:42 -0400, Steven Conway
<[EMAIL PROTECTED]> wrote:

>1.  No.
>


>
>1. Should PDSE Load Libraries  that reside in LNKLST be allocated
>with secondary space specified?
>

1. Doesn't matter.  PDSE always counts as 1.   


Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS 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

Re: PDSE Clarification

[Steven Conway]

Sam and Mark are, as usual, correct.  I let habit overcome technical 
reality.  Bad sysprog, bad.

Steve Conway
Lead Systems Programmer
Information Systems & Services Division
Computer & Network Operations
Phone:   (703) 450-3156
Fax:(703) 450-3197



   Mark Zelden <[EMAIL PROTECTED]> 
   Sent by: IBM Mainframe Discussion List 
   05/19/2008 10:11 AM
   Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@BAMA.UA.EDU
cc

Subject
Re: PDSE Clarification






On Mon, 19 May 2008 09:10:42 -0400, Steven Conway
<[EMAIL PROTECTED]> wrote:

>1.  No.
>


>
>1. Should PDSE Load Libraries  that reside in LNKLST be allocated
>with secondary space specified?
>

1. Doesn't matter.  PDSE always counts as 1. 


Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS 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



--
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: PDSE Sharing

[Mark Zelden]

On Thu, 12 Apr 2007 13:07:21 -0500, Dennis Trojak
<[EMAIL PROTECTED]> wrote:

>Well I hate to open this can of worms but I wonder if anybody has
>suggestions on how to prevent damaging a PDSE in a dual SYSPLEX
>environment running a MIMPLEX. 

Don't do it if it hurts. :-)

>I am running NORMAL not EXTENDED
>PDSESHARING 

Doesn't matter.  

>and I know that IBM (and CA) does NOT support this mode for
>cross-system/sysplex updates so I follow this rule with my target
>datasets. 

IBM doesn't support sharing PDSE across sysplexes  - period.   Although
many shops (like ours) share some as READ ONLY (sysres dsns).  Same
is true with HFS (we share a read only unix root).

>The question I have is how do I prevent users from breaking
>this rule with their own product PDSEs? I can tell them to stick to the
>LPAR that has the PDSE open but that doesn't guarantee they will follow
>the rule. I know there are other MIMPLEX sites out there so how do you
>handle this?

We handle it with SMS. 

All the application PDSE libraries (which are all Endevor controlled)
are SMS controlled.  Really a throwback from the days when PDSE data sets
had to be SMS controlled.   The SMS pools are not shared between the 
sysplexes.  

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

Re: PDSE Sharing

[Anthony Saul Babonas]

RACF, ACF2 or Top Secret.Protect us from ourselves.  

My gun cabinet has a lock.  If it did not, it would be a box.


 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Dennis Trojak
Sent: Thursday, April 12, 2007 1:07 PM
To: [EMAIL PROTECTED]
Subject: PDSE Sharing

Well I hate to open this can of worms but I wonder if anybody has
suggestions on how to prevent damaging a PDSE in a dual SYSPLEX environment
running a MIMPLEX. I am running NORMAL not EXTENDED PDSESHARING and I know
that IBM (and CA) does NOT support this mode for cross-system/sysplex
updates so I follow this rule with my target datasets. The question I have
is how do I prevent users from breaking this rule with their own product
PDSEs? I can tell them to stick to the LPAR that has the PDSE open but that
doesn't guarantee they will follow the rule. I know there are other MIMPLEX
sites out there so how do you handle this?
Dennis

--
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

--
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: PDSE <-> PDS

[Barry Schwarz]

Unless the catalog has a PDSE indicator and you use the same catalog for both 
IPL's, how would anyone know of this "inconsistency"?

"Chase, John" <[EMAIL PROTECTED]> wrote:Hi, All,

I'm getting ready to SMP/E-install a new version of a product, and this new
version delivers the load library in a PDSE (earlier version is PDS). The
target load library will live on extended SYSRES with a SYS1 hlq, and will
be indirectly cataloged.

Does anybody see any "issue" with having a PDS or a PDSE "active" for the
same DSN, depending on which RES set is IPLed? IOW, say RESA has the "old"
SYS1.PRODUCT.LOADLIB as a PDS and RESB has the "new" one as a PDSE. Any
"issue" with simply IPLing from one RES or the other?

TIA,

-jc-

--
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



-
 Click here to donate to the Hurricane Katrina relief effort.

--
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: PDSE <-> PDS

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Barry Schwarz
> 
> Unless the catalog has a PDSE indicator and you use the same 
> catalog for both IPL's, how would anyone know of this "inconsistency"?

The same master catalog is used for both SYSRES sets.  I don't know whether
there is or is not such a thing as a "PDSE indicator" for a non-SMS dataset.
One certainly is not coded in the IDCAMS command to indirectly catalog a
dataset (DEFINE NONVSAM NAME(data.set.name) DEVICETYPES()
VOLUMES(&SYSRn)).

-jc-

--
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: PDSE configuration concerns

[Staller, Allan]

1)  ro* all,setsms psdesharing(extended)  ??? check the syntax and/or
the command, I am doing this from memory
2) update IGDSMS00 as appropriate on all systems
3) IIRC, fallback is a sysplex-side IPL.

I did this about 6 months ago and have had no issues.

You might also want to implement to PDSE RAS address space at the same
time. Check out PDSE_RESTARTABLE_AS(YES)
This address space will not start until the next IPL, however, a rolling
IPL is sufficient for this.

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

Re: PDSE configuration concerns

[Mingee, David]

Hi Ralph,  We have been using PDSESHARING (EXTENDED) FOR 5 YEARS with only 1 
minor blip and it was fixed by adding the below statements to IGDSMS00:

PDSE_MONITOR(YES,60,30)  
PDSESHARING(EXTENDED)
PDSE_RESTARTABLE_AS(YES) 
PDSE1_MONITOR(YES)   
PDSE1_LRUCYCLES(15)  
PDSE1_LRUTIME(60)
PDSE1_HSP_SIZE(0)
PDSE1_BMFTIME(3600)  
One big benefit is multiple users across multiple LPARS can share a pdse for 
input/output, except if 2 users are manipulating the same MEMBER and one is for 
update and the need for compress is gone.  I think you will like it. 



David L. Mingee
Principal Systems Administrator
Indianapolis Production Control 
Data Center Operations / Operations Technical Support

Work Ext  782-6460
Work Direct Dial  317 581-6460
Home 317 598-0919 / Cell 317 341-0885



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Ralph Wendt
Sent: Thursday, October 13, 2011 1:26 AM
To: IBM-MAIN@bama.ua.edu
Subject: PDSE configuration concerns

All:

We have 3 LPARS, with SHARING set to Normal.
We would like to change SHARING to Extended.

What kind of issues can I expect from implementing this change?

How would I perform the fallback? One member at a time, or a sysplex wide IPL?

Any relevant comments would be appreciated.

Ralph.

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

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