APAR status
Closed as canceled.
Error description
. Last Updated: 06/30/95 VOLREF . . . This informational APAR addresses known problems in DFSMS . Tape Mount Management (TMM) methodology. The list also . includes problems that have already been fixed. This APAR . will be updated as and when problems get resolved. . . ************ Problems that have been RESOLVED ************** . . 1. Failure in SMS because of SMS volume count limit of 59 . Solution: Reduce user specified volume count to 59 . OY40354 . . 2. Failure in SMS if the volume count is more than the . number of volumes in the selected storage group . Solution: Do not fail allocation OY32669 . . 3. Tape data sets can get extended to 5 volumes as a . default but on DASD this cannot be accomplished without . a change in JCL . Solution: Provide volume count as a Data Class parameter . OY40197 . . 4. TRTCH=COMP/NOCOMP clashes with VSAM key values in JFCB . Solution: Differentiate between tape and VSAM . allocations. See OY42354 . . 5. SMF 14/15 record suppression . Solution: OY33622 . . 6. Warning message if expiration date is limited by . Management Class . Solution: OY24771 . . 7. Data class invalid for non-SMS data sets . Solution: OY30326 . . 8. ACS cannot recognize UNIT=AFF specified . Solution: Pass 'AFF=' as the value for &UNIT See APARs . OY32843 and OY35214 . . 9. TMM storage groups fill up very fast and need a very big . storage group as data sets redirected to DASD have to be . overallocated and cannot wait until DFHSM space . management cycle . Solution: Partial Release on Close. See OY39465, . OY39466, OY39467, OY42757, and OY43095 . . 10. Interval migration is required for TMM storage groups . Solution: OY43025, OY43026, OY44496 . . 11. Release on close does not work when EXCP is used . Solution: OY48521 . . 12. IMS GSAM errors . . a. Reblocking of GSAM DASD datasets on a HSM MIGRATE or . RECALL results in errors . . b. If GSAM tape allocations are directed to DASD, . accessed during IMS checkpoint, and are migrated . before the restart window, errors can occur . . Solution: OY45560, OY45724 . . 13. IDCAMS DELETE of tape data sets results in an allocation . and a mount and this causes unnecessary delays and . overhead. . Solution: Detect a tape data set and do an uncatalog. . See OY60176 . . 14. Incorrect volume count is used when RETAIN is specified . and the data class has a default volume count . Solution: OY57741 . . 15. The volume count is lost on migrate/recall . Solution: OY59536, OY60092 . . 16. Restart fails when checkpointed data sets get migrated. . The following messages may occur: . MSGIHJ007I RESTART NOT SUCCESSFUL FOR jobname . (220) MODULE = IGC0N05B . MSGIHJ009I ERROR ON ddname . MSGIEF450I jobname stepname - ABEND=S13F . ABEND13F . . Solution: OY63624, OY63625/OW00598, OY65741, . OY65742/OW00739, OY64885, OY64816/OW00735, . OW11824/OW11841, and OW11843/OW11844. . . 17. Restart fails for IMS GSAM data set if they are migrated . Solution: OY64814, OY64816/OW00735, OY64885, OY64892, . OY64893/OW00737 and IMS APARs PN45211, PN45212 . . 18. When a non-specific tape intended GDS allocation is . directed to DASD and is not opened, data loss can occur . if the new empty generation rolls off the oldest . generation. Data integrity problems can occur because . programs which expect valid data encounter the empty . generation. Job failures can also occur for . non-specific, non-generation data sets, if the job/step . is rerun. . Solution: OY66484 and OW01827 . . 19. IEBGENER fails for concatenated data sets if one or more . of the data sets in the concatenation are left on tape . and the tape data set is not the first in the . concatenation . Solution: OY66366/OY66223 . . 20. When using TMM storage groups along with 'spill' storage . groups (volumes/group in QUINEW status), datasets are . allocated to the 'spill' volumes even though the TMM . volumes have enough space to satisfy the allocation. The . problem is caused by the the dual purpose of the high . threshold value; an SMS allocation threshold and a DFHSM . threshold for interval migration. . Solution: OY65847/OW00241 . . 21. A TMM DASD dataset is not migrated to L2 storage if it's . migration to L1 storage failed due to insufficient L1 . space. . Solution: OY65880/OY65882/OW00419 . . **** Additional problems resolved by SMS 1C0 or MVS 522 **** **** For additional details on the specifics of SMS **** **** release 1C0 implementation of VOL=REF processing **** **** see the following manuals: **** Implementing System Managed Storage (SC26-3123-03) **** **** DFSMSdfp Storage Administration Reference **** **** (SC26-4920-02) **** **** Planning for Installation (SC26-4919-02) **** ************************************************************ . . Depending on unique JCL coding practices, the problems . listed below may or may not apply to all TMM users. Many . customers have experienced tape mount reductions and . improved tape utilization without resolution to these . problems. . . This APAR will be updated when there is significant . progress to report on the resolution of these problems. . . The resolution of some of these problems requires complex . design changes in multiple components and/or products. A . resolution for such problems may not be available until . subsequent releases. . . 1. VOL=REF and/or UNIT=AFF . . a. Allocation fails when the referencing and referenced . data sets are not directed to the same storage group . as the ACS routines cannot determine that VOL=REF . was specified. . RESOLUTION: Resolved by DFSMS/MVS 1.3.0. (New values in &ALLVOL and &ANYVOL ACS read-only variables.) . b. Allocation fails when a NEW DD references another . NEW DD which in turn references an existing MOD or . OLD DD and the first DD is SMS managed. . example: DD1 DISP=OLD . DD2 VOL=REF=DD1,DISP=(NEW,CATLG).... . DD3 VOL=REF=DD2,DISP=(NEW,CATLG).... . . RESOLUTION: Resolved by DFSMS/MVS 1.3.0. (Resolution of reference deferred until locates are done for mod/old data sets.) c. VOL=REF not specified and UNIT=AFF specified. If the . referenced data set is directed to DASD and a NEW or . MOD treated as NEW referencing data set is not . redirected to DASD then Allocation or JES3 fails the . referencing data set allocation. . RESOLUTION: Resolved by MVS/SP 5.2.2 (or OS/390) and up-level JES3. (Allows UNIT=AFF to point to DASD when data set is on DASD due to being placed there by SMS.) . d. Allocation for the referencing data set fails if a . data class was not derived by the ACS routines, . since space is usually not specified for tape data . sets. . ***** Also, take care when using LIKE= for DS's to be TMM'ed. If the ds being LIKED to is a model DSCB originally allocated with SPACE=(0,n) then this space value will be derived via LIKE=. LIKE= overrides over rides any space value assigned via dataclas. With space = 0 the allocation may fail with a JCL error and msgigd17045i "SPACE not Specified.....". To get around this problem re- allocate the model DSCB with a "real" space value, adequate to accomodate the largest of the ds's which will LIKE= to it. If "wasted" dasd space is a problem then use PARTIAL RELEASE in an SMS assigned MGMTCLAS management class to release over allocated space when the ds is closed. RESOLUTION: Resolved by DFSMS/MVS 1.3.0. (Data class processing was moved so that it is now handled with VOL=REF processing. . e. Allocation fails when all of the referencing data . sets are not directed to SMS DASD using VOL=REF and . the referenced data set was directed to DASD. . . LIMITED RESOLUTION: This is still true for VOL=REF since it is one way of implying stacking. IBM intends no change to allow data sets using VOL=REF to be directed to different media. This would cause other problems. However, additional information is provided via &ALLVOL and &ANYVOL read-only variables so that construct assigned can be directed consistently. . f. Using VOL=REF with SMS managed data sets forces the . referencing data set to be allocated in the same . storage group as the referenced data set. This can . cause large data sets to be allocated in the small . data set pool. . . The following messages may occur with the above . problems: . MSGIEF475I VOL ON INELIGIBLE PERMRES OR RESERVED . DEVICE . MSGIEF318I UNIT=AFF INVALID FOR REQUEST SPECIFYING. NEW DIRECT ACCESS DATA SET . MSGIAT4301 UNIT TYPE PARAMETER FOR STEPNAME IS NOT. VALID - JOB FAILED . MSGIGD17045I SPACE NOT SPECIFIED FOR ALLOCATION OF . DATA SET . . Resolved by DFSMS/MVS 1.3.0. (For ATL, the data sets still need to go in the same storage group. This is because they must go on the same tape and a tape can be in only one storage group. For DASD, another storage group can be assigned as long as it is of compatible type (POOL or VIO). ) . . g. All datasets which meet criteria outlined in . Allocation APAR OY66484 which are not opened are . deleted at step termination. MSGIGD105I is received . indicating the deletion of the DASD dataset. . Applications which have been altered to recognize a . TMM redirected dataset as being a DASD dataset may . fail if the DASD dataset is deleted. . . See APAR OW08887 . .
Local fix
Problem summary
Problem conclusion
Temporary fix
Comments
Informational APAR only
APAR Information
APAR number
II06908
Reported component name
V2 LIB INFO ITE
Reported component ID
INFOV2LIB
Reported release
001
Status
CLOSED CAN
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
1993-04-20
Closed date
1993-04-20
Last modified date
1996-10-29
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Applicable component levels
[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19N","label":"APARs - OS\/390 environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":null,"label":null},"Product":{"code":"SG19O","label":"APARs - MVS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SSSN3L","label":"z\/OS Communications Server"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]
Document Information
Modified date:
13 December 2020