SMS can cause errors when it overrides the DSN TYPE when installing SYSVIEW using IBM utility GIMUNZIP.
Overriding the DSN TYPE from PDS to PDS/E and vice versa.
The IBM GIMUNZIP program executed in the UNZIPJCL job at customer sites will only unzip the same type of data set org that was created when the GIMZIP utility was used to create the data set at CA when the pax file was built.
The GIMUNZIP utility is there to ensure that the SYSVIEW installation data sets are created exactly at the customer sites as they are in CA R&D labs where the pax file is created and tested - so that a delivered PDS will only expand into a PDS at the customer site, a PDSE will only be expanded to a PDSE.
If a customer site has SMS rules that force PDSE creation then IBM's GIMUNZIP utility will fail. This is documented by IBM and they suggest using the same data set as is transported. This can be done by changing the SMS allocation rule for GIMUNZIP HLQs so that SMS will not force any change in the data set organization, i.e. to a PDS to a PDSE.
The error messages generated during an UNZIPJCL job run for changed REL files indicate that the SMS data set allocation rules, at sites who employ SMS to override data set allocations, are changing the data set org structure from PDS to PDSE and this will cause a failure.
We suggest then that storage teams who utilize SMS allocation rules for PGM=GIMUNZIP make changes such that data sets having a HLQ of "OEM.CAI" be allowed to be allocated with the original characteristics rather than being overridden by SMS to have a type of PDSE.