In a recent note, Walt Farrell said:
> Date: Tue, 19 Sep 2006 14:00:51 -0400
>
> It is, in fact, likely that if a program were to cause an integrity
> problem when run in TSO that it would also cause an exposure when run in
> batch. However, I can envision some odd kinds of effects that could
> pose problems in TSO that would not pose problems in batch, given the
> differences between "normal" tasks and jobstep tasks.
>
OK. My sysadmin added GIMSMP to the TSOAUTH list in PARMLIB.
for a test, I set up a target library so it regularly runs out
of space. For example, I see in SMPOUT:
[ ... ]
GIM44001I SYSTEM ABEND E37 OCCURRED WITH A REASON CODE OF '00000004'X AF
TER SMP/E CALLED THE IEWL
UTILITY. THE
linklib LIBRARY RAN OUT OF SPACE.
GIM43903I RETRY PROCESSING WILL BE ATTEMPTED FOR THE linklib LIBRARY.
GIM30302I COMPRESS PROCESSING WAS SUCCESSFUL FOR THE linklib LIBRARY. TH
E RETURN CODE WAS 00.
[ ... ]
GIM20502I SMP/E PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 00.
SMP/E IS AT LEVEL 34.10.
This looks excellent. It ran out of space, as I forced it,
and appears to have recovered by compressing the target library.
But in SYSTSPRT:
>>> "call *(GIMSMP) 'PROCESS=WAIT'"
IKJ56641I GIMSMP ENDED DUE TO ERROR+
IKJ56641I SYSTEM ABEND CODE 0E37 REASON CODE 00000004
+++ RC(-4095) +++
SMP/E recovered from the SE37. Why, then, is TSO reporting
a failure? If the program invoked by CALL terminates with
status=0, I'd expect CALL likewise to report status=0.
Feels like material for a PMR, but against which component?
Rexx? TSO? SMP/E? Other (specify)?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
