Review process around starting VTAM dependant Netview autotasks

Note: This “IBM Idea” was suggested to be raised by IBM support as a pathway to fixing an identified product flaw with the re-start of VTAM dependant Netview autotasks.    

Please refer to case “TS015636631  Gateway links not started post IPL” for a detailed background and case history.  

Internal autotask DSIHPDST may not always be successfully started by Netview. This can result in ongoing errors:     

     DSI072A RMTCMD COMMAND ABORTED. DSIHSNDS RETURN CODE = 220

     Note: DSI072A reason code 220 indicates that task DSIHPDST is inactive

Normal scenario:

-           IPL with System Automation starting prior to VTAM

-           Autotask DSIHPDST was started (CNMSTYLE default) and failed (as expected) due to VTAM not being active.

-           Netview attempts one restart of failed VTAM dependant autotasks when VTAM initializes

-           Autotask is restarted

Problem Scenario:

Netview did not attempt a restart of the failed VTAM dependant autotasks due to a timing issue.

It was observed that the IST020I VTAM init message was issued whilst autotask DSIHPDST was terminating and prior to it completing its termination.    

IBM support recommendation was to set DSIHPDST and DSI6DST autotasks to START=N in CNMSTGEN and apply a usermod to CNMEVTAM to start the autotasks from there.   

Idea to consider:

-           IBM should be aware of what tasks are VTAM dependant, and when they are specified as START=Y in CNMSTYLE/CNMSTGEN simply start them at the appropriate time and not prior to VTAM starting.

Other considerations:   

-           A temporary usermod to CNMEVTAM, as recommended, could be applied by customers, but if this is to be an ongoing recommendation, I would suggest that a documented user exit be provided (like CNMSTYLE has CNMSTGEN).  

-           The timing issue was described by as being in “a range of ms”. This implies to me that a slight tweak of the process may be all that is needed mitigate this issue without re-designing it. I don’t feel that the current process of re-starting VTAM related autotasks needs to be abandoned.

-           Having internal tasks with START=N in CNMSTYLE/CNMSTGEN then later started in elsewhere like in CNMEVTAM may obscure/confuse others in the future maintaining the style definitions.         

-           Review the existing documentation around this as IBM support stated “maybe the documentation … should be more clearer …”