IPC requested enhancements

Requesting the the following enhancement to IPC. .

1. Indicating IPLing from DEAC in PIDT table section 2

When a processor gets ipled from DEAC, the processor sends an IPC message to all active loosely-coupled processors saying I'm ipling from deac. This is done right after IPC is established the first time but before the processor goes down due to the software IPL. Receiving processors set an indicator at PIDT section 2 showing the sending processor is IPLing from DEAC. When the processor establishes IPC again after the software IPL, it sends an IPC message. At this time receiving processors clear the IPLing from DEAC indicator.



The purpose of this indicator is to avoid sending IPC messages to the processor IPLing from DEAC as it will go thru software IPL. We have seen IPC message build-up at active processors' outbound queue causing issues such as low/no core blocks, particularly when utility type jobs are running at active processors which tend to generate heavy IPC traffic.



We made it is the SIPCC user's responsibility to check the indicator and build the SIPCC destination field accordingly.



Hope this local modification is taken by IBM and make it is the system's responsibility to check the indicator and remove a processor from the SIPCC destination if a processor is getting IPLed from DEAC rather than making it SIPCC user's responsibility.



2. Holding low priority IPC message until the system reaches 1052 state

We hold low priority IPC messages until the system reaches 1052 state by putting them to IGT table input queue. We created two fields at IGT table entry section (first and last on input queue). When the system reaches 1052 state, we interrogate the input queue and process IPC messages if there's any.



In loosely-coupled environment applications may get activated at a processor even before it gets to 1052 state due to IPC requests from NORM state processors. Low priority IPC messages are usually from applications and they may access globals and tables (e.g. WGTA) before they are loaded to memory causing CTL-3, OPR-4 or unpredictable errors eventually disrupting the system restart.