UNPAX of ZFS from product installation file fails

Products

• Allocate DASD Space and Placement

Issue/Introduction

We have run into an issue when attempting to unpax from an Broadcom Installation file. In this case the file to be unpaxed is a ZFS file. We use PGM=GIMUNZIP to perform the unpax. Here is the error we get:

 

ADR780I (001)-TDDS (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN LOGICAL DATA SET FORMAT AND WAS CREATED BY   
                         Z/OS DFSMSDSS VERSION 2 RELEASE 5 MODIFICATION LEVEL 0 ON 2022.242 14:00:48                
ADR395I (001)-NEWDS(01), DATA SET CAI.PORTPKG.NM4170.GA.CNM4H00.ZFS ALLOCATED WITH NEWNAME DT24363.CNM4H00.ZFS, IN  
                         CATALOG SYS1.USERCAT.TSO, ON VOLUME(S): $BEAAD                                             
ADR380E (001)-DALOC(04), DATA SET CAI.PORTPKG.NM4170.GA.CNM4H00.ZFS NOT PROCESSED, 13-00008                         
ADR415W (001)-TDLOG(01), NO DATA SETS WERE COPIED, DUMPED, OR RESTORED FROM ANY VOLUME                              
ADR480W (001)-TDLOG(01), THE FOLLOWING DATA SETS WERE NOT PROCESSED FROM THE LOGICALLY FORMATTED DUMP TAPE DUE TO   
                         ERRORS:                                                                                    
                          CAI.PORTPKG.NM4170.GA.CNM4H00.ZFS              

 

If we use the VDSBYPAS DD in our job, we do not receive the error. It appears that GIMUNZIP dynamically invokes ADRDSSU. In our VAM routines, we exit out if PGM=ADRDSSU. In this case the PGM=GIMUNZIP, so it appears that VAM is not exiting out of the routines.   

We are looking to see if there is a workaround to this issue rather than putting in a VDSBYPAS DD in the job. We would prefer to use VAM pooling to successfully complete the allocation of the ZFS file without having to hardcode a volume for the allocation. 

I will attach the failed job output with VAMDIAGS turned on. 

This is not urgent. We have a workaround. We are just looking for a long term solution around this issue.                                  

Environment

Release : 12.5

Resolution

Allocate has a documented restriction of not supporting the re-direction of DF/DSS restores:

 

“

Allocate is unable to successfully redirect non-SMS-managed DFDSS-requested allocations. Unpredictable results can

occur if the bypass DD statement, default name VDSBYPAS, is not used to exempt such allocations from processing.

“

 

You can minimize the impact to the 'GIMUNZIP' program by adding to your ASR after the

 

 &PGM = 'ADRDSSU' THEN   
    EXIT CODE(0)  

statement

 

IF (&PGM = 'GIMUNZIP') AND (&MODULE = 'ADRTDDS') THEN 
EXIT CODE(0)

 

This way the 'GIMUNZIP' program is only impacted when DF/DSS is trying to allocate the data set.

 

Since this DFDSS restriction has been in place in Allocate for many years, I am not aware of any other methodology to allow Allocate to select a volume for these DFDSS allocations.  But I can research further.

 

 

At this time since the allocation done by the DF/DSS product are not intercepted by ALLOCATE we are not aware of any other way that Allocate can help at this point.