Authors: Theresa Dowden and Kurt Quackenbush
IBM Corporation
SMP/E Development
Poughkeepsie, NY
Phone: (845)433-4084 and (845)433-4085
email: dowden@us.ibm.com
email: kurtq@us.ibm.com
16 Oct 2000
IBM is providing information in this document to assist customers with SMPPTS out of space issues. IBM does not guarantee the results if these recommendations are followed.
All statements regarding IBM's future direction and intent are subject to change or withdrawal without notice and represent goals and objectives only.
The following terms are registered trademarks of the IBM Corporation in the United States or other countries or both:
The SMPPTS data set is a partitioned data set, and is used during SMP/E RECEIVE processing as storage for SYSMODs. Both Modification Control Statements (MCS) and any inline data from the SYSMODs are stored in the SMPPTS data set. The SMPPTS must be large enough to contain all the SYSMODs in the SMPPTFIN data set which will be received.
With an increasing trend toward larger and larger PTFs, the size limits of the SMPPTS are being reached. More and more users are experiencing problems with their SMPPTS data set running out of space. The SYSMODs currently stored in their SMPPTS along with the space required for incoming SYSMODs is exceeding one physical volume of space in some instances. However, the SMPPTS data set is a partitioned data set, and partitioned data sets are restricted to one single volume.
This document will explain several ways to relieve this space issue. Specifically, it will address three areas:
If SMS is active on your system, you can allocate the SMPPTS data set as a PDSE. This will allow you to use the SMPPTS without needing to compress the data set periodically to remove wasted space, which may occur over time as members are deleted from the data set.
Allocate the SMPPTS data set using system-determined blocksize. Do this by specifying BLKSIZE=0. This will allow the system to create a data set with an optimal blocksize for the device on which the data set will reside.
See the DFSMS/MVS Using Data Sets book for more information on system-determined blocksize.
The SMP/E REJECT command allows you to clean up the global zone, SMPPTS, and associated entries and data sets. REJECT has four modes; MASS, SELECT, NOFMID, and PURGE modes.
In PURGE mode, SMP/E will reject all SYSMODs that have been accepted into the specified distribution zones. PURGE mode can be used when SYSMODs were not automatically deleted once they were accepted. This will be the case if NOPURGE was coded in the OPTIONS entry used to process the distribution zone. SMP/E's default is to purge during ACCEPT processing. However, you may have added NOPURGE to the OPTIONS entry in order to prevent this. So, unless you have modified the OPTIONS entry to add NOPURGE, SMP/E automatically deletes global zone SYSMOD entries, HOLDDATA entries, SMPPTS MCS entries, and SMPTLIB data sets when SYSMODs are accepted.
If NOPURGE is being used in your OPTIONS entry, you may choose to run a REJECT PURGE command to clean up your SMPPTS data set and global zone. Run this command by specifying the following:
Figure 1. REJECT PURGE command
SET BDY(GLOBAL).
REJECT PURGE (os390d,cicsdlb,jes2dlb)
HOLDDATA
COMPRESS(SMPPTS).
|
where os390d, cicsdlb, and jes2dlb indicate which distribution zones (or ZONESETs) to check for applicability. Since no SYSMOD types (APARs, FUNCTIONS, USERMODS) were specified on the above command, SMP/E will only delete PTFs (the default) from the global zone and SMPPTS. SYSMOD entries in the global zone and MCS entries in the SMPPTS data set for applicable SYSMODs will be deleted.
The HOLDDATA operand on the above command indicates HOLDDATA entries associated with the SYSMOD entries being rejected should also be deleted from the global zone.
If you have not allocated your SMPPTS data set as a PDSE, you should use the COMPRESS operand to compress your SMPPTS data set as shown above.
See the SMP/E Commands book for more information about the REJECT command.
OS/390 Version 2 Release 5 SMP/E introduced a new function called PTF Compaction in the SMPPTS Data Set. SMP/E will compact inline element data in SYSMODs in the SMPPTS data set in order to reduce the storage requirements of the data set.
If you are running OS/390 Version 2 Release 5 SMP/E or above, SMPPTS compaction is the default. Inline element data is automatically compacted during RECEIVE processing. You can see the data has been compacted by browsing the SMPPTS data set. Within the members of the SMPPTS data set, compacted inline element data will start with the characters "$$GIMC". The element data will be expanded as needed during APPLY and ACCEPT processing.
Compaction is controlled by the COMPACT subentry in the global zone OPTIONS entry. If you wish to change the COMPACT subentry, you may use UCLIN, or the SMP/E dialogs. Note that COMPACT(YES) is the default, so that compaction is automatically performed. To use UCLIN to change the value from NO to YES, use the following:
Figure 2. Resetting the COMPACT subentry
SET BDY(GLOBAL).
UCLIN.
REP OPTIONS(GLOBOPT) COMPACT(YES).
ENDUCL.
|
To use the SMP/E dialogs, follow the following steps:
Figure 3. Resetting the COMPACT subentry with the SMP/E Dialogs
From the main SMP/E dialog (GIM@PRIM), select 1 (Administration)
(GIMAD) - select option 1 (Definition)
(GIMADDF) - enter the zone name "Global"
(GIMDFMB1) - press enter to get to the next panel
(GIMDFMC) - select option 2 (OPTIONS)
(GIMDF0A) - select the OPTIONS entry you wish to update
(GIMDF0C) - select 4 (General)
(GIMDF0H) - scroll forward to locate "Compact SMPPTS"
fill in the value of YES or NO (YES is the default)
|
If you are running with OS/390 Version 1 Release 1, 2, 3 SMP/E or OS/390 Version 2 Release 4 SMP/E or SMP/E Release 8.1, APAR IR36477 allowed for the expansion of compacted data at these lower release levels. The applicable PTFs are:
-
OS/390 Version 1 Release 3 and Version 2 Release 4 SMP/E
- UR48877
- UR48878
- UR48879
-
OS/390 Version 1 Release 2 SMP/E
- UR48874
- UR48875
- UR48876
-
OS/390 Version 1 Release 1 SMP/E and SMP/E Release 8.1
- UR48871
- UR48872
- UR48873
After installing these PTFs, any SMPPTS data set which contains SYSMOD members compacted by OS/390 Version 2 Release 5 SMP/E and above can be used with lower levels of SMP/E, which will recognize the compacted data and expand it as necessary during APPLY and ACCEPT.
SMP/E also provides a service routine, GIMCPTS, which will compact or expand inline element data within SYSMODs in the SMPPTS. In OS/390 Version 2 Release 5 SMP/E and above, GIMCPTS can be run to compact data which already existed in the SMPPTS data set before SMP/E began receiving data and compacting it with Release 5. Testing has shown, on average, a 33% recovery of space in the SMPPTS after running this service routine. If you are running a lower level of SMP/E, you can order OS/390 Version 2 Release 5 or above, install SMP/E, and then steplib to this level of SMP/E in order to run GIMCPTS to compact your SMPPTS data set. As long as you have the above PTFs installed, SMP/E will recognize the compacted data and expand it during APPLY and ACCEPT processing.
GIMCPTS is also provided in earlier releases of SMP/E, but for expansion purposes only. If you want to run GIMCPTS to compact data in your SMPPTS, you must use the OS/390 Version 2 Release 5 (or above) SMP/E version of GIMCPTS.
Here is a sample jobstream:
Figure 4. Sample jobstream for GIMCPTS
//JOBx JOB ...
//COMPACT EXEC PGM=GIMCPTS,PARM='COMPACT'
//*
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=SMP.OS390R5.SMPPTS,DISP=SHR
//SYSUT2 DD DSN=SMP.OS390R5.SMPPTS.COMPACT,DISP=OLD
|
When this jobstream is executed, the GIMCPTS service routine will compact the inline element data within all SYSMOD members in the SMPPTS data set and write them to the new SMPPTS data set. You should only attempt to compact a partitioned data set in place if it is a PDSE. If the data set is a simple PDS however, it is likely the data set will get an out of space condition during the operation, unless a large amount of free space is available. Instead of compacting the SMPPTS data set in place, a new data set could be allocated and used to receive the compacted data, as shown above.
See the OS/390 Version 2 Release 5 (or above) SMP/E Reference for more details about compaction and running GIMCPTS.
During SMP/E accept processing, PTFs will be purged from the SMPPTS data set unless NOPURGE has been specified in the active OPTIONS entry. Once a PTF has been purged from the SMPPTS data set, if that PTF is found again during RECEIVE processing (from a CBPDO or ESO for example), since it no longer exists in the SMPPTS data set, it will be received again. However, there is really no need to RECEIVE the PTF again. So, SMP/E introduced Enhanced RECEIVE Processing in OS/390 Version 2 Release 5 SMP/E.
Enhanced RECEIVE processing allows users to prevent the RECEIVE command from processing SYSMODs that are already applied or accepted. Users can specify this with the OPTIONS entry, on the RECEIVE command, or both. This enhancement reduces the need for the user to manage the SMPPTS with REJECT commands.
The most automated method of preventing SYSMODs from being received after they have already been applied or accepted is to define a Receive Zone Group in an OPTIONS entry and then make that OPTIONS entry active during RECEIVE command processing.
A Receive Zone Group is a list of zones and/or zonesets, which will be checked during RECEIVE processing. If a SYSMOD has been applied into a target zone which is part of the Receive Zone Group, or accepted into a distribution zone which is part of the Receive Zone Group, it will not be received into the SMPPTS data set. Zones and zonesets which are part of a Receive Zone Group can contain both target and distribution zones.
For example, if you do not want PTFs received into the SMPPTS after they have been accepted into any of your distribution zones, you could define your distribution zones as a Receive Zone Group.
A Receive Zone Group can be defined by using the RECZGRP subentry of an OPTIONS entry. The following UCLIN can be used to set up the RECZGRP subentry in the RECOPT OPTIONS entry:
Figure 5. Defining a Receive Zone Group - OPTIONS entry
SET BDY(GLOBAL).
UCLIN.
ADD OPTIONS(RECOPT) RECZGRP(os390d,cicsdlb,jes2dlb).
ENDUCL.
|
Then, to make the RECOPT OPTIONS entry active during a RECEIVE command, use the following SET and RECEIVE command or add RECOPT as an OPTIONS subentry in the GLOBALZONE entry in the global zone.
Figure 6. Activating OPTIONS entry at RECEIVE
SET BDY(GLOBAL) OPTIONS(RECOPT).
RECEIVE SYSMODS.
|
During RECEIVE processing, any SYSMODs which have already been accepted in zones os390d, cicsdlb, or jes2dlb are not selected to be processed by this RECEIVE command. These SYSMODs will not be received into the SMPPTS data set. In addition, "ALLZONES" can be specified in the RECZGRP subentry to indicate all target and dlib zones defined by a ZONEINDEX subentry in the GLOBALZONE entry are eligible to be checked during RECEIVE command processing.
See the OS/390 Version 2 Release 5 (or above) SMP/E Reference for details about the OPTIONS entry.
If you do not want to make use of the OPTIONS entry method for enhanced RECEIVE, another way to achieve the same thing is to use the ZONEGROUP operand on your RECEIVE command, as follows:
Figure 7. Defining a Receive Zone Group - RECEIVE command
SET BDY(GLOBAL).
RECEIVE ZONEGROUP(os390d,cicsdlb,jes2dlb) SYSMODS.
|
This RECEIVE command will receive SYSMODs that have not been applied or accepted into any of the defined zones. If a SYSMOD has been applied or accepted into one of the zones, that SYSMOD will not be received into the SMPPTS. The ZONEGROUP can identify zones, zonesets, or both. You can also specify "ALLZONES" which uses all target and dlib zones listed in the ZONEINDEX subentry of the GLOBALZONE entry as the Receive Zone Group. The ZONEGROUP operand on the RECEIVE command will override any values specified on the RECZGRP and RECEXZGRP subentries in the OPTIONS entry.
See the OS/390 Version 2 Release 5 (or above) SMP/E Commands book for details about RECEIVE command syntax and processing.
During RECEIVE processing, SMP/E will RECEIVE all service SYSMODs and dependent functions which are applicable to one of the SRELs and one of the FMIDs defined in the FMID subentry in the GLOBALZONE entry.
When SYSMODs are superseded or deleted in all distribution zones managed by the global zone, SMP/E does not automatically delete FMIDs from the FMID subentry in the GLOBALZONE entry. This may cause service and dependent functions to be received for FMIDs which have been superseded and/or deleted.
For example, if OS/390 Version 2 Release 5 SMP/E (HMP1B00) is installed, it supersedes and deletes OS/390 Version 2 Release 3 SMP/E (HMP1A00). HMP1A00 will still exist in the GLOBALZONE FMID subentry, and any PTFs for HMP1A00 which appear on a future CBPDO or ESO will be received into the SMPPTS data set during the RECEIVE of that CBPDO or ESO.
In order to eliminate receiving these extraneous SYSMODs, the FMID subentry in the GLOBALZONE entry can be maintained by deleting FMIDs which exist for deleted and/or superseded FMIDs.
One way to do this is by using the REJECT command in NOFMID mode. NOFMID mode rejects SMPPTS MCS entries, global zone SYSMOD entries, and HOLDDATA for all SYSMODs applicable to functions that are not part of the system. In addition, by using the DELETEFMID operand, you can specify one or more FMID subentries that are to be deleted from the GLOBALZONE entry before SMP/E selects the SYSMODs and HOLDDATA to be rejected. In order to determine which FMIDs to specify with the DELETEFMID operand, you can use the LIST command against your distribution zones. Any FMIDs which are superseded or deleted are candidates to be used on the DELETEFMID operand. After determining these FMIDs, use the following REJECT command to delete the SMPPTS MCS entries, global zone SYSMOD entries, and HOLDDATA entries for these SYSMODs.
Figure 8. REJECT NOFMID Command
SET BDY(GLOBAL).
REJECT NOFMID DELETEFMID(fmid,fmid...)
HOLDDATA
COMPRESS(SMPPTS).
|
If you have not allocated your SMPPTS as a PDSE, you should use the COMPRESS operand to compress your SMPPTS data set as shown above. See the SMP/E Commands book for more information about the REJECT and LIST commands.
Rather than use the LIST command and manually determine which FMIDs to delete, you can also use the sample programs provided below, which make use of the SMP/E API. The sample programs help you to create a REJECT NOFMID command (similar to the one above) for the FMIDs that are superseded or deleted in the DLIB zones you specify in the sample programs.
Note: These sample programs can only be used with OS/390 Version 1 Release 3 SMP/E and above because SMP/E API support was introduced in that release.
These samples have also been provided in SMP/E APARs IR41183 and IR41893. The following SMP/E PTFs provide the latest level of these samples:
- UR51852 for OS/390 Version 1 Release 3 SMP/E
- UR51853 for OS/390 Version 2 Release 5 SMP/E
- UR51846 for OS/390 Version 2 Release 7 SMP/E
If after trying all the suggestions already mentioned, you still have not reclaimed enough space in your SMPPTS data set, then you should consider defining one or more SMPPTS spill data sets. SMPPTS spill data sets are used to contain SYSMODs when the primary SMPPTS data set is full. Specifically, when the primary SMPPTS data set is full, SYSMODs are written to the first spill data set. When the first spill data set is full, SYSMODs are then written to the second spill data set, and so on. This continues until all SYSMODs are written to one of the data sets, or until the primary SMPPTS and all of the spill data sets are full.
Note: SMPPTS spill data sets is a new function in SMP/E provided by PTF UR52517 for OS/390 Version 2 Release 5 and 6, and by PTF UR52518 for OS/390 Version 2 Release 7, 8, 9, and 10.
SMPPTS spill data sets are permanent partitioned data sets which you allocate and manage just like the SMPPTS data set. You then define these permanent spill data sets to SMP/E using either DD statements or DDDEF entries. The first spill data set must be specified with a DD statement or DDDEF entry named SMPPTS1, the second must be specified with a DD statement or DDDEF entry named SMPPTS2, and so on, up to a maximum of SMPPTS99. When you specify SMPPTS spill data sets, do not skip any spill data set ddnames; if a spill data set is omitted, this indicates the end of the list, and SMP/E ignores any spill data sets which may follow the omitted data set. For example, if you specify only SMPPTS1 and SMPPTS3, then SMP/E uses only SMPPTS1 and ignores SMPPTS3.
If SMPPTS spill data sets are defined using DDDEF entries, then the DDDEF entries for the spill data sets must be added to all zones (global, target and distribution zones). If the DDDEF entries are added only to the global zone, the spill data sets will not be detected and used during APPLY and ACCEPT processing and you will likely get a message indicating a SYSMOD could not be located in the SMPPTS data set.
Whether your SMPPTS spill data sets are defined by DDDEF entries or DD statements, SMP/E will refer to each of the data sets, in sequential order, when writing to, reading from, and deleting SYSMOD members from the SMPPTS data sets. Also, after SMP/E writes a SYSMOD member to the SMPPTS or a spill data set, SMP/E does not keep track of which data set that SYSMOD member resides in. This means you are free to manage the SMPPTS and spill data sets however you want. You can merge data sets, split data sets, and move members from one data set to another, without affecting SMP/E.
As part of SMPPTS spill data set support, SMP/E will now compress an out-of-space SMPPTS data set and retry any operation which results in an out-of-space condition. The RETRYDDN subentry of an OPTIONS entry indicates if SMP/E should compress data sets and retry operations. You should specify RETRYDDN(ALL) in your active OPTIONS entry. This tells SMP/E to compress all out-of-space data sets and retry operations. The primary SMPPTS data set, and all SMPPTS spill data sets are eligible for RETRY processing.
If RETRYDDN(ALL) is not specified, then SMP/E will not compress the SMPPTS or spill data sets. Rather, an out-of-space condition will cause SMP/E to simply move on to the next data set in sequential order, without first compressing the data set and retrying the operation.
Contact z/OS
Send us your questions and comments.
|
