Operations log directly on to SOLVESSI for SOLVE Operations Automation via an ICC 3270 Session when shutting down an LPAR.
Not sure if this issue started with a recent hardware update from a z13 to a z15, of if it was in the months before. It did work in the past, and is required.
Not sure if any of these configuration items related to this.
Have 2 Sysplex, one with 10 LPARs, and one with 2 LPARs.
The 10 LPARS are in CSS 00, and the 2 LPARs are in CSS 01
Can only successfully attach a device to SOLVESSI from the smaller sysplex.
When attempting to attach device 0102 to an LPAR in the 10 LPAR sysplex get the following issue:
F SOLVSSI,ATT 0102
ATT 0102
NS6A11 ATTACH STARTED FOR DEVICE: 0102
NS6C07 DEVICE ALLOCATION ERROR - ADDRESS 0102 REQUESTED, ADDRESS 3FFF RETURNED
NS6F01 DETACH COMPLETE FOR DEVICE: 0102
Not sure what 3FFF is relating to, maybe a boundary, but we do not have a device in that range defined.
On the working LPARs we get the following:
F SOLVSSI,ATT 0102
ATT 0102
NS6A11 ATTACH STARTED FOR DEVICE: 0102
NS6C06 ATTACH COMPLETE FOR DEVICE: 0102
Release : 11.9
Component : SOLVE:Operations Automation for z/OS
Verify if using IBM’s System Managed Storage (SMS) across the 10 LPAR sysplex.
It seems that device addresses have changed on these Lpars, could be related to SMS ACS routine.
SOLVE/NetMaster does not allow the address to be different.
In testing here when the attach is issued the SSI job output contains -
IEF237I 0811 ALLOCATED TO SYS00001
For SMS allocations there is a different message
IGD103I SMS ALLOCATED TO DDNAME
Check to see if seeing the IGD message when you issue the ATTACH
The dynamic allocation issued by the SSI contains the UNIT and a return DD name tuple. Because the device address starts with a 0 the UNIT value is specified as 3 digits. So it is similar to the JCL statement //SYS00001 DD UNIT=102.
The result was related to a poor bit of code in the SMS ACS routine where an exit point was missing after a null storage class was set for non-DASD devices.