There is a system dump of 66D with reason code 31 at 12:01 today.
Some users report to us around 14:15 that Option 1 of the Alchemist ISPF interface is frozen.
We have to recycle (eventually cancel) Alchemist base task to fix this issue around 14:24.
Abend S66D-31 means: a TSO/E service that requires a TSO/E environment was invoked in a non-TSO/E environment.
If you encounter this abend you should review any PCL that is invoking a TSO environment, such as IKJEFT01 or IKJEFT1A. These utilities are provided to simulate a TSO environment during batch processing. Since Alchemist request processing is done within the Alchemist address space, this is not a true batch environment so this can lead to problematic results on occasion. Most adverse situations have been addressed with an Alchemist solution, for example, by providing a PCL SEND command which eliminates the need to submit a TSO SEND.
Here are three past examples of situations that caused S66D-31 abends and all involved use of IKJEFT01:
- IKJEFT01 SYSTSIN missing END statement, such as this DB2 input:
ALLOCATE DBRMLIB ...DSN S(DB2Z)BIND PACKAGE ...END <- this statement was missing so the following FREE was being executed as a DB2 command and failed. FREE FI(DBRMLIB) ... Adding this END resolved that 66D-31 problem.
- CLIP using IKJEFT01 to invoke TSO SEND In one case, analysis of the S66D dump showed that the abend occurred on a call to CLIP9 STATUS=N. This caused the CLIP PX engine to die so no other CLIPs could be processed...therefore a restart of Alchemist was needed. The CLIP9 that caused this abend included a IKJEFT01 step used to submit a TSO SEND. This customer also recently increased to MTL=10, which allows for 10 concurrent PX engines and an increased chance of overlap between these pseudo TSO environments. The solution for this CLIP was to replace the IKJEFT01 step with PCL SEND commands. PCL SEND is not reliant on a TSO environment. PCL ensures that the required environment is available.
- Running homegrown code via IKJEFT01. If removing the homegrown code resolves the S66D abends, this indicates that the custom code is the culprit and requires review.
If you encounter an S66D-31 abend and it is not explained by any of the above or other analysis of your use of IKJEFxxx:
- Send the Alchemist started task log and dump to CA Support for review.
- Indicate if any recent PCL or system changes have been made around the time this behavior started.
- Send any relevant PCL especially all that executes IKJEFxxx or the equivalent.