SMPPTS Spill Data Set

[Hashem Tawakol]

Hi,
I have created one SMPPTS spill data set to complete receive job for large number of PTFS, After the APPLY and ACCEPT most of the PTFS deleted and I would like to delete the spill data set which still have few entries on it.
If someone tried that before can you please advise the steps to do that?

Hashem

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

[Lizette Koehler]

Since this is a PDS
SMPPTS1 SMPPTS2 etc...

You could create SMPPTS and copy the entries from SMPPTS1 and SMPPTS2 into SMPPTS.

Or you could compress the spill file and release any additional space an leave it in-case you have a large number to receive again.

SMPE only looks at your SMPPTSx files. So you should not have an issue if you copy everything into one file. I would also copy with NO REPLACE. Just incase.

Lizette

-----Original Message-----
Of Hashem Tawakol
Sent: Wednesday, February 13, 2013 8:48 AM
Subject: SMPPTS Spill Data Set
Hi,
I have created one SMPPTS spill data set to complete receive job for large number of
PTFS, After the APPLY and ACCEPT most of the PTFS deleted and I would like to delete
the spill data set which still have few entries on it.
If someone tried that before can you please advise the steps to do that?
Hashem

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

[Staller, Allan]

1) Copy all members from the SMPPTS spill dataset to be deleted to original SMPPTS dataset.
2) Remove DDDEFS pointing to the SMPPTS SPILL dataset.
3) Delete the dataset.
4) Remove references to the deleted SMPPTS spill dataset from all JCL.

HTH,

<snip>
I have created one SMPPTS spill data set to complete receive job for large number of PTFS, After the APPLY and ACCEPT most of the PTFS deleted and I would like to delete the spill data set which still have few entries on it.
If someone tried that before can you please advise the steps to do that?
</snip>

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

[Skip Robinson]

If you needed a spill data set in the past, you'll probably need one again
some day. Given the trouble it takes to create and then delete a spill
data set, I'm with others in recommending that you just leave it. I've
never deleted one, but I know that displaying a sysmod in the Global zone
shows which PTS it lives in. If you just move sysmods outside of SMPE.,
will Global zone display choke? My suggestions:

1. Make any PTS a PDSE so that you won't have directory block shortages.

2. Update SMPE management options so that compress is not attempted on any
except the *last* defined PTS. If you use PDSEs, compress will not work
anyway, but why bother trying?

3. In the case of a PDSE growing excessively large, you may want to shrink
it manually now and then.

.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
***@sce.com



From: "Staller, Allan" <***@KBMG.COM>
To: IBM-***@LISTSERV.UA.EDU,
Date: 02/13/2013 08:05 AM
Subject: Re: SMPPTS Spill Data Set
Sent by: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU>



1) Copy all members from the SMPPTS spill dataset to be deleted to
original SMPPTS dataset.
2) Remove DDDEFS pointing to the SMPPTS SPILL dataset.
3) Delete the dataset.
4) Remove references to the deleted SMPPTS spill dataset from all JCL.

HTH,

<snip>
I have created one SMPPTS spill data set to complete receive job for large
number of PTFS, After the APPLY and ACCEPT most of the PTFS deleted and I
would like to delete the spill data set which still have few entries on
it.
If someone tried that before can you please advise the steps to do that?
</snip>


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

[Staller, Allan]

<snip>
If you needed a spill data set in the past, you'll probably need one again some day. Given the trouble it takes to create and then delete a spill data set, I'm with others in recommending that you just leave it. I've never deleted one, but I know that displaying a sysmod in the Global zone shows which PTS it lives in. If you just move sysmods outside of SMPE., will Global zone display choke? My suggestions:
</snip>

IIRC (check the archives) John Eels (Kurt Q. ?) once stated that SMP didn't care. It just looked until it found the PTF and did whatever was required. I have found this to be the case.

<snip>
1. Make any PTS a PDSE so that you won't have directory block shortages.
</snip>

Agreed.

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

[Pommier, Rex R.]

Skip,

To answer your question about a Global zone display choking, the answer is "no". I have done just what the original poster asked about, moved all the remaining PTFs from SMPPTS1,2 back to SMPPTS, removed the DDDEFs etc, and deleted the SMPPTSx datasets. SMP/E will happily find the PTFs in their new location.

Rex


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Skip Robinson
Sent: Wednesday, February 13, 2013 10:41 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: SMPPTS Spill Data Set

If you needed a spill data set in the past, you'll probably need one again some day. Given the trouble it takes to create and then delete a spill data set, I'm with others in recommending that you just leave it. I've never deleted one, but I know that displaying a sysmod in the Global zone shows which PTS it lives in. If you just move sysmods outside of SMPE., will Global zone display choke? My suggestions:

1. Make any PTS a PDSE so that you won't have directory block shortages.

2. Update SMPE management options so that compress is not attempted on any except the *last* defined PTS. If you use PDSEs, compress will not work anyway, but why bother trying?

3. In the case of a PDSE growing excessively large, you may want to shrink it manually now and then.

.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
***@sce.com



From: "Staller, Allan" <***@KBMG.COM>
To: IBM-***@LISTSERV.UA.EDU,
Date: 02/13/2013 08:05 AM
Subject: Re: SMPPTS Spill Data Set
Sent by: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU>



1) Copy all members from the SMPPTS spill dataset to be deleted to
original SMPPTS dataset.
2) Remove DDDEFS pointing to the SMPPTS SPILL dataset.
3) Delete the dataset.
4) Remove references to the deleted SMPPTS spill dataset from all JCL.

HTH,

<snip>
I have created one SMPPTS spill data set to complete receive job for large
number of PTFS, After the APPLY and ACCEPT most of the PTFS deleted and I
would like to delete the spill data set which still have few entries on
it.
If someone tried that before can you please advise the steps to do that?
</snip>


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

The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you.



NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information.
If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited.
If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety.

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

[Kurt Quackenbush]

...If you just move sysmods outside of SMPE.,
will Global zone display choke?

No it won't choke. SMP/E doesn't persist any knowledge of which SMPPTS
data set a SYSMOD resides in.

2. Update SMPE management options so that compress is not attempted on any
except the *last* defined PTS. If you use PDSEs, compress will not work
anyway, but why bother trying?

If you use PDSEs, SMP/E is smart enough to not bother trying to
compress, so no need to change the RETRYDDN list in your OPTIONS entry.
If you use PDSs, then you definitely should keep SMPPTS and spill data
sets in your RETRYDDN list. I recommend using PDSEs.

Kurt Quackenbush -- IBM, SMP/E Development

[Tom Marchant]

I would like to delete the spill data set ...

What is the benefit of doing that?

[Paul Gilmartin]

Post by Skip Robinson
3. In the case of a PDSE growing excessively large, you may want to shrink
it manually now and then.

Will MIGRATE/RECALL accomplish this for a PDSE? (I believe it will for PDS,
and for PS, but only if secondary extents are defined.)

Is there a better way?

-- gil

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

[Robert A. Rosenberg]

At 12:07 -0600 on 02/13/2013, Paul Gilmartin wrote about Re: SMPPTS

Post by Paul Gilmartin

Post by Skip Robinson
3. In the case of a PDSE growing excessively large, you may want to shrink
it manually now and then.

Will MIGRATE/RECALL accomplish this for a PDSE? (I believe it will for PDS,
and for PS, but only if secondary extents are defined.)
Is there a better way?
-- gil

I may be wrong but I think that the RECALL will restore the PDSE as
it was not as a compressed copy. What will work is to allocate a new
(empty) PDSE and do an IEBCOPY of the old one into it. This will
created a compressed copy. Now delete the old copy and rename the new
copy to its name.

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

[Mark Zelden]

Post by Paul Gilmartin

Post by Skip Robinson
3. In the case of a PDSE growing excessively large, you may want to shrink
it manually now and then.

Will MIGRATE/RECALL accomplish this for a PDSE? (I believe it will for PDS,
and for PS, but only if secondary extents are defined.)
Is there a better way?

You can just use FREE on ISPF 3.4 to release unused extents.

--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

[John Gilmore]

You can certainly use ISPF 3.4 "to release unused extents".

This, however, is the equivalent of compressing (sic) a PDSE iff and
only if its members are stowed originally and replaced in LIFO
sequence.

I can think of situations---certain recursive processes are obvious
candidates---in which this might be the case, but they are highly
unusual. Much more often than not every PDSE extent will contain a
current member or members. We are usually dealing here with a heap
rather than a stack.

John Gilmore, Ashland, MA 01721 - USA

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

[Edward Jaffe]

Post by Mark Zelden

Post by Paul Gilmartin

Post by Skip Robinson
3. In the case of a PDSE growing excessively large, you may want to shrink
it manually now and then.

Will MIGRATE/RECALL accomplish this for a PDSE? (I believe it will for PDS,
and for PS, but only if secondary extents are defined.)
Is there a better way?

You can just use FREE on ISPF 3.4 to release unused extents.

Partial release has never worked well for PDSE because of the way PDSE is
architected internally. Only tracks above the highest active block can be
released; there can be big "gaps" inside the PDSE of unused data; "free" blocks
were obtained using an algorithm that did not care where the blocks were located
in the data set.

Wayne Rhoten discussed at SHARE in San Francisco improvements to PDSE (V1) such
that it now prefers lower-numbered RBNs to higher-numbered RBNs when looking for
"free" blocks to store new member and directory data. This should make partial
release work much better for PDSE going forward.
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

[John Gilmore]

When I first heard about the scheme Edward Jaffe has just mentioned I
did some simulations. If optimality is identified with extents-used
minimization they suggest that the new scheme will work better than
the old one but not nearly so well as a full optimization, which would
require the solution of an integer linear-programming problem having
smallish embedded knapsack problems, a variant of the newsprint-roll
cutting problem.

John Gilmore, Ashland, MA 01721 - USA

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

[Edward Jaffe]

Post by John Gilmore
When I first heard about the scheme Edward Jaffe has just mentioned I
did some simulations. If optimality is identified with extents-used
minimization they suggest that the new scheme will work better than
the old one but not nearly so well as a full optimization, which would
require the solution of an integer linear-programming problem having
smallish embedded knapsack problems, a variant of the newsprint-roll
cutting problem.

But would that not require "active" data movement/cleanup whenever a block is freed?

I think they settled for something they could pull off without radical
re-architecture to the library or its serialization mechanisms.
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

[Paul Gilmartin]

Post by Mark Zelden

Post by Paul Gilmartin

Post by Skip Robinson
3. In the case of a PDSE growing excessively large, you may want to shrink
it manually now and then.

Will MIGRATE/RECALL accomplish this for a PDSE? (I believe it will for PDS,
and for PS, but only if secondary extents are defined.)
Is there a better way?

You can just use FREE on ISPF 3.4 to release unused extents.

MIGRATE/RECALL, IIRC does:

o compress

o release unused extents

o consolidate remaining extents

o Trims the now single extent snugly to DS1LSTAR.

(Not necessarily as distinct operations.)

The last isn't necessarily a Good Thing; as soon as you touch
it, you get a secondary extent.

-- gil

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

[Hashem Tawakol]

Thanks for all suggestions.

Hashem

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

[Shane Ginnane]

Post by Edward Jaffe
Wayne Rhoten discussed at SHARE in San Francisco improvements to PDSE (V1) such
that it now prefers lower-numbered RBNs to higher-numbered RBNs when looking for
"free" blocks to store new member and directory data. This should make partial
release work much better for PDSE going forward.

Let's hope so. My 'nother basic SMS q was associated with this issue.
A truckload of overallocated (active) PDSE for load modules. The responsible user attempted release (as they showed around half unused), later trying reallocation (using LIKE=) in a multivolume d/class.
The results were underwhelming to say the least.

Why after all these years are we only now getting solutions to (some of) the short-comings in PDSE ?.

Shane ...

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

[John Gilmore]

Edward Jaffe wrote:

| But would that not require "active" data movement/cleanup
| whenever a block is freed?

and of course it would. How much of this would be required appears to
depend upon what kind of member-replacement process is going on.

There is some evidence---my sample is from six shops but for only 113
PDSEs---that an 80-20-like process is frequent, i.e., that 80 percent
of the replacement activity is with only 20 per cent of the members.
If this is common then keeping a list with counts of the last n
replacement operations weighted for duplications would make it
possible to use a very small amount of this sort of thing to great
advantage.

Shane's point merits comment too. PDSEs were radically
under-instrumented at the beginning and still are; for this reason
discussion of their deficiencies quickly degenerates into competitive
anecdotage. One of the largest contributions IBM could make just now
would be to greatly improve optional SMF-based instrumentation for
PDSEs,

We all understood the deficiencies of PDSs, and PDSEs were a laudable
initiative, but they were also a half-hearted or, perhaps better,
underbudgeted one.

John Gilmore, Ashland, MA 01721 - USA

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

[Mike Schwab]

The longer since the last update of a member, the less likely it is to
be replaced. Store by last update. Copying to a new PDS is
alphabetical, and makes the first few compresses particulaly
inefficient (lots of members to be moved).

Post by John Gilmore
| But would that not require "active" data movement/cleanup
| whenever a block is freed?
and of course it would. How much of this would be required appears to
depend upon what kind of member-replacement process is going on.
There is some evidence---my sample is from six shops but for only 113
PDSEs---that an 80-20-like process is frequent, i.e., that 80 percent
of the replacement activity is with only 20 per cent of the members.
If this is common then keeping a list with counts of the last n
replacement operations weighted for duplications would make it
possible to use a very small amount of this sort of thing to great
advantage.
Shane's point merits comment too. PDSEs were radically
under-instrumented at the beginning and still are; for this reason
discussion of their deficiencies quickly degenerates into competitive
anecdotage. One of the largest contributions IBM could make just now
would be to greatly improve optional SMF-based instrumentation for
PDSEs,
We all understood the deficiencies of PDSs, and PDSEs were a laudable
initiative, but they were also a half-hearted or, perhaps better,
underbudgeted one.
John Gilmore, Ashland, MA 01721 - USA

[Bill Fairchild]

This could also be done for PDSes, when copying/compressing, as well as PDSEs. First copy the directory to a work space, then sort entries in the work space by last update, copy directory to output file, copy members by oldest update instead of alphabetical order, and update each directory entry for where that member begins as its corresponding member starts being rewritten. This assumes that the date of last update is saved somewhere. And do not update the date of last update when copying/compressing. Just one of many possible ways to speed up IEBCOPY for old style PDSes.

Bill Fairchild
Programmer
Rocket Software
408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA
t: +1.617.614.4503 * e: ***@rocketsoftware.com * w: www.rocketsoftware.com

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Mike Schwab
Sent: Thursday, February 14, 2013 8:59 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Change in PDSE Architecture (Was: SMPPTS Spill Data Set)

The longer since the last update of a member, the less likely it is to be replaced. Store by last update. Copying to a new PDS is alphabetical, and makes the first few compresses particulaly inefficient (lots of members to be moved).

| But would that not require "active" data movement/cleanup whenever a
| block is freed?
and of course it would. How much of this would be required appears to
depend upon what kind of member-replacement process is going on.
There is some evidence---my sample is from six shops but for only 113
PDSEs---that an 80-20-like process is frequent, i.e., that 80 percent
of the replacement activity is with only 20 per cent of the members.
If this is common then keeping a list with counts of the last n
replacement operations weighted for duplications would make it
possible to use a very small amount of this sort of thing to great
advantage.
Shane's point merits comment too. PDSEs were radically
under-instrumented at the beginning and still are; for this reason
discussion of their deficiencies quickly degenerates into competitive
anecdotage. One of the largest contributions IBM could make just now
would be to greatly improve optional SMF-based instrumentation for
PDSEs,
We all understood the deficiencies of PDSs, and PDSEs were a laudable
initiative, but they were also a half-hearted or, perhaps better,
underbudgeted one.
John Gilmore, Ashland, MA 01721 - USA

--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

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

[John Gilmore]

Mike Schwab's idea is a good one for some but not for all PDSE members

In some of them replacement probabilities are different, more like
those associated with magnetic hysteresis or elastic fatigue: the
longer they have gone unreplaced the likelier their replacement
becomes.

No single a priori rule is likely to be satisfactory. Data-driven
selection of one from among a small number of them is going to be
needed.

John Gilmore, Ashland, MA 01721 - USA

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