IBM Z System Automation

Hello,

With OA55378, ICSF will be started earlier in the IPL via "S ICSF,SUB=MSTR" in COMMNDxx.

I currently have ICSF defined with a parent of JES2.  This will no longer work.

TechDocs FLASH10882 titled "z/OS Encryption Requires ICSF to Start Early in IPL" also states that ICSF should be shutdown after JES2.

I thought I had read, but now can not find that ICSF should also be shutdown after OMVS, in case any ZFS files are encrypted.

What is the recommended was to code this in SA?

Regards,

John

Hello John,

We're working on a recommendation and out-of-the-box support for managing the ICSF address space with SA.  This includes support for shutting it down after OMVS and JES2.

Let's follow up after the holidays and I can share how we're going to address this.

Merry Christmas and a Happy New Year.

Best regards,

Jürgen

Hello Jürgen,

That sounds great!

Merry Christmas and a Happy New Year!

Regards,

John

Hi John,

the ICSF address space is responsible for encrypting data on a z14 box. This can be data of normal data sets content, zFS data content, SMF records , … you name it.

Depending on your companies rules and for logging purposes it can be required, to have encrypted data available as early as possible. That's why it is recommended to start the ICSF address space out of the COMMNDxx member (SUB=MSTR)

Additionally it can be required to collect/log data (also SMF data) of a z/OS system shutdown including the shutdown of OMVS. Unfortunately the SA infrastructure itself relies on the existence of an initialized OMVS.

Based on these facts and knowing the needs of several customers we think of creating a solution for this issue. This includes a shutdown of the system as we know it today including the local automation manager (which might be the last one) and OMVS. In that way the NetView looses its automation agent functionality but the NetView toolbox still exists.

Afterwards and as an additional step the customer is able to specify a serialized sequence of commands which will be executed one after the other synchronously.

This sequence may include Z EOD, and a stop mechanism to terminate a specified list of lasting address spaces (like ICSF). Once the lasting address spaces are gone the NetView address space itself will terminate.

I hope this helps you to understand our thoughts and addresses your issues regarding to the ICSF automation.

Regards,

Gunnar

Hello Gunnar,

Thanks for your response and thoughts.

An interesting problem.  So at shutdown, SA goes away, but NetView will remain, and it can issue a series of commands to finish the shutdown.

Without SA, can NetView verify if the commands worked or not?

Regards,

John

Hi John,

because it is at the very end of of a systems life the scripts are intended to shutdown lasting address spaces. That's why there will be logic up to a certain point to verify whether stopping such an address space was successful. If the stop command failed then the administrator gets informed and manual intervention would be required.

Regards

Gunnar

Hello Gunnar,

Has an APAR been created for this?

I would like to track it, or pull down the PTF if it is available.

Regards,

John

Hi John,

this is a future item. It might be part a new product release in the future.

Regards,

Gunnar