I am trying to run Chapter 16 Step 2 of the Upgrade In Place for the z/VM 7.1 install on my test system.
I followed the steps documented in https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-mainframe-software/traditional-management/ca-vm-secure-for-z-vm-with-security/3-2/administrators/upgrade-z-vm-in-place.html but when I ran the INSTUPGR STAGE1 (COMMIT I received an error. The $LOGFILE has this information.
17 Jun 2020 16:01:18 Called by: INSTS1EX for SETUP
17 Jun 2020 16:01:18 Parms.1: SETUP
17 Jun 2020 16:01:18 Parms.2: VERSION
17 Jun 2020 16:01:18 Parms.3: 710.01
17 Jun 2020 16:01:18 Exiting with return code: 9
The INSTUPGR $DEBUG$ file has this information.
****************************************************
* INSTUPGR $DEBUG$ E
* Created on: 17 Jun 2020 at 16:01:14
* By user: MIGMAINT on VMDR640
* Command entered: INSTUPGR STAGE1 ( COMMIT
****************************************************
*
IUGUPG8338I Now executing: INSTS1EX 710
Exit Call = EXEC UPGDMIXT INSTS1EX SETUP UPGRDIRSTEM. 3
Stem Records
1 SETUP
2 VERSION
3 710.01
IUG1EX8518E The following error was returned from a call to
IUG1EX8518E directory exit 9 :
IUG1EX8520E Version not compatible
IUGUPG8342E Command 'INSTS1EX 710' failed with RC=100
The INSTUPGR $CONSLOG file had this information.
IUGUPG8392I INSTUPGR STAGE1 ( PRIME ended successfully
****************************************************
* INSTUPGR $CONSLOG E
* Created on: 17 Jun 2020 at 16:01:14
* By user: MIGMAINT on VMDR640
* Command entered: INSTUPGR STAGE1 ( COMMIT
****************************************************
*
IUG1EX8518E The following error was returned from a call to
IUG1EX8518E directory exit 9 :
IUG1EX8520E Version not compatible
IUGUPG8376E INSTUPGR STAGE1 ( COMMIT ended in error.
I'm running VM:Secure 3.2 RSU-2001.
Release : 3.2
Component : CA VM:Secure for z/VM
z/VM 7.1
Did not have access to updated UPGDMIXT EXEC.
If you ran VMDEPLOY to ALTERNATE, and have VM:Secure with RSU-2001 running off ALTERNATE, the issue is that the updated UPGDMIXT EXEC would be on the VMSECURE ALTPUBLIC disk ... and not the default PUBLIC disk (referenced in the VMSERVER NAMES file entry for VMSECURE).
If this is the case, you can just deploy the VMSECURE "public" updates to the (PRIMARY) PUBLIC disk by issuing:
VMDEPLOY VMSECURE PUBLIC
This will only deploy the updated VM:Secure materials that go on the PUBLIC disk (the PRIMARY environment). All other VMSECURE PRIMARY disks will remain unchanged.