Product installation with Chorus Software Manager fails during Post Installation Cleanup and CSMSRV comes down with CC 160

Document ID : KB000044544
Last Modified Date : 14/02/2018
Show Technical Document Details

Symptoms:

MSMTC stops with RC=160 and creates a Javadump.

This happened during the post installation cleanup step of any product installation done by Chorus Software Manager 6.0 on z/OS 1.13.

 

The product installation itself was completed, but MSMTC terminated.

BPXM023I (CAMSM)  231

    231             JVMDUMP039I Processing dump event "gpf", detail "" at 2016/05/10

    231             09:49:12 - please wait.

    231

 11.49.12 STC26237  BPXM023I (CAMSM)  232

    232             JVMDUMP032I JVM requested System dump using 'CAMSM.JVM.MSMTCS.D160510

   232             T094912.X&DS' in response to an event

 

-JOBNAME  STEPNAME PROCSTEP    RC   EXCP    CPU    SRB  CLOCK   SERV  PG   PAGE   SWAP    VIO SWAPS STEPNO

-MSMTCS            CSMSRV     160  2771K   1.06    .00  42.95  5550K   0      0      0      0     0     3

 

Environment: 

z/OS 1.13

CSM 6.0

Cause:

Deletion of an old leftover and archived temporary dataset failed with S0C4 ABEND in IBM's remove() function during the post installation cleanup step.

During our tests we identified that the 64-bit version of IBM’s remove() function abended on z/OS 1.13 on archived data sets only. This happened also without having Chorus Software Manager involved.

Workaround:

Retrieve temporary data sets from archive before running the next product installation.

The naming of these temporary datasets is based on the GIMUNZIP Temporary Prefix* defined in Settings – Software Installation, followed by the name of the MSM STC and then Pn (n is a nummer)
Sample: PUBLIC.MSMTC.P1.*

Additional Information:  

During the installation, GIMUNZIP utility runs to unarchive temporary data sets or USS files as a part of an installation. The temporary data sets are allocated with HLQ as defined in System Settings – Software installation - GIMUNZIP Temporary Prefix.MSMTC-STC-name.Pn .
(Sample: PUBLIC.MSMTC.P1.*)
During clean-up after installation, all such temporary data sets are deleted. The deleting process has following steps:

  • CSM calls LISTCAT utility to get all data sets with a specified hlq (sample: PUBLIC.MSMTC.P1)
  • CSM deletes all data sets that LISTCAT utility returns.

So, here the problem is that during clean-up the LISTCAT returned not only temporary data sets related to this installation of a product but also some other data sets. CSM successfully deleted all temporary data sets from current installation but then CSM crashed when trying to delete those leftover datasets supplied by LISTCAT utility, which were archived.