IBM Mainframe Forum

Statement of Problem:
=====================
When invoking TSO/E commands from a batch COBOL program using the IKJTSOEV / IKJEFTSR methodology; and attempt to process the data that was
captured in the //SYSTSPRT output, we "sometimes" get S001 Reason 0004 ABENDs. I say sometimes, because most of the times, we
do not ABEND. Like just now, I ran the process 150 times (not concurrently) and only 2 of those invocations ABENDed.

Background
===========
We have successfully tested batch COBOL programs that are able to in turn, invoke TSO/E commands in batch:
To carry this out, we use the already proven two-fold recommended methodology of:
(1) dynamically calling the IKJTSOEV IBM service to establish a TSO environment.
(2) dynamically calling the IKJEFTSR IBM service utility to perform the desired TSO/E command.

The above methodology has been successfully tested for a number of TSO/E commands such as "LISTALC STATUS", "LISTC LVL" and even dynamic file allocation.
For those commands that produce a listing (such as LISTALC STATUS, or LISTC LVL), the output is viewable in the //SYSTSPRT DD SYSOUT=* output.

We are even able to "push the envelope" and process the //SYSTSPRT output within the same COBOL program and step. We do this, by coding in the JCL something like:
//SYSTSPRT DD DSN=&&TEMP,DISP=(NEW,PASS) - and in turn, adding to the COBOL program FILE CONTROL and FD statements to recognize the SYSTSPRT file.
After the call to IKJEFTSR is complete, we issue COBOL "CANCEL" statements for the IKJTSOEV and IKJEFTSR invocations. We then follow that by
OPENING the SYSTSPRT file for INPUT, READING through the file to process the records, and then CLOSING the file. As mentioned in the beginning,
this works most of the time. But for an extreme minority of invocations, we experience a "ABEND=S001 U0000 REASON=00000004" abend.
Even when it ABENDs, most of the SYSTSPRT file has been processed and the ABEND happens just before the end-of-file condition.
It would appear that the ABEND is happening in the calling COBOL program just after it has read the final record in the //SYSTSPRT file.
We have been testing with the "LISTALC STATUS" and "LISTC LVL" TSO/E commands, and both types of invocations produce these intermittent
ABENDs.

Our systems people have a theory that maybe TSO is not being totally shut-down within the COBOL program's execution and there is some
contention on the //SYSTSPRT file. I think there might be some contention between different resources but I am not sure.

Can anyone offer any assistance as to what tweaking we should do to ward off these intermittent ABEND's.
thanks in advance.
twolights58

The description for abend 001 mentions message IEC020I. Do you get message IEC020I? What was the text included in the message?

Did you read the description for this message?

If the return code is 4, for QSAM, ABE or an incorrect value for EROPT parameter in the DCB and/or no error handling (SYNAD) exit was specified.

Thank-you Pedro for replying.

Yes - we are receiving the "IEC020I DCB EROPT=ABE OR AN INVALID CODE, AND/OR NO SYNAD EXIT SPECIF" message.
I am not sure what this message means, but there are SYSTEM programmers here assisting me and they
looked at the message.
As mentioned, 95% of the times the job works. To me this indicates that
there are some risks to trying to process the //SYSTSPRT file in the same step, which will lead to failure 5% of the times.
These risks must have to do with something else happening at the same time in the environment.
The system programmers here at work who are assisting, suggested coding "EROPT=ACC" to force the program to accept
any bad file status codes returned from the //SYSTSPRT file.
I did just that, and this warded off the S001-4 forced ABENDs to at least allow some of the DISPLAYS to execute in order
to reveal more information to what was happening during these failures. I discovered that for all of these infrequent failures, the
program has successfully read the final SYSTSPRT record, and between that final successful read, and
before the next read (which under normal conditions would lead to the end-of-file condition), somehow,
the file-status code for the SYSTSPRT file becomes "30". According to the manuals, '30' means:
"The I/O statement was unsuccessfully executed as the result of a boundary violation for a sequential file or as the
result of an I/O error, such as a data check parity error, or a transmission error".

So should I conclude that there are unavoidable contention risks (i.e. 5% of the times) to reading in as input, the SYSTSPRT file within the same step that created it,
or is there some adjustment that can be made (COMPILE options, JCL, COBOL code, Z/OS) to remove these risks ?

thanks in advance for any advice.
twolight58

Sorry, I am not sure how this translates to COBOL...

You can specify an error analysis routine, called a SYNAD exit, in the DCB. Normally, it would try to recover from various problems. My suggestion is to code a dummy exit that issues RC=0 (??). I believe that will prevent the S001 abend. Note: you may hide legitimate S001 abends by doing this, but my reading of your problem is that it should not be an issue.

See chapter 31 of 'DFSMS Using Data Sets', SC23-6855. This is more of an assembler topic than a TSO & ISPF topic.

thanks Pedro !
I will speak to the one Assembler programmers who I know around here to see if he can create that "dummy exit"
that you advise. I will try to keep everyone posted should we be able to come up with that exit.

But as a work-around, I am able to call IDCAMS from a similar COBOL program. While IDCAMS
does not offer the totality of functions within the TSO/E suite of available commands, it will
perform a "LISTCAT LVL" search; which is one of things that I need COBOL to be able
to invoke.
IDCAMS writes its output to the //SYSPRINT DD and not the //SYSTSPRT DD.
(the //SYSPRINT output is VB, LRECL=125).
Similar to what were are doing through the IKJTSOEV/IKJEFTSR methodology,
with the IDCAMS approach, the same COBOL program (in the same step)
is reading in the //SYSPRINT output, as its input, and
processing it; and so far, without any S001-4 ABENDS.
I have submitted the IDCAMS version as much as 300 times in a row, and
no ABENDS.

Does the fact that the "IDCAMS //SYSPRINT" output performs without any
ABENDS reveal anything to solve the problem that we are experiencing
with the IKJEFTSR //SYSTSPRT output ?