Re: CPYF gives CPC2957 as completion message but hangs job

Although it seems similar to the problem I recall having, the mention in a prior message that the noted condition "has happened consistently the last 3 times they've run the job" would seem to suggest otherwise. So be sure to also search the web for CPF5170 and review those messages [mostly from this list]. Those messages allude to review the interactive subsystem monitor job for errors logged there. The history log may also have some worthwhile messaging for when the issue occurs. FWiW there are also the LIC log and PAL in STRSST, each may record something over the time the application is started until the hangup occurs. Before canceling the session, beyond a DSPJOBLOG OUTPUT(*PRINT) and WRKJOB OUTPUT(*PRINT) against the /hung/ job, I would suggest collecting also, a spooled process dump formatted for cursors from the STRSST, D/A/D feature.

I was not aware the CPF5170 transpired when canceling the session. FWiW the canceled session would typically effect CPF5140. That the CPF5170 "Device &4 session not active" occurred instead, I believe indicates that the system had [and perhaps recorded in sbs monitor job, QHST, or a QSYSxxx## job?] already deactivated the device prior to the active DSPMSG processing [for the break message, which was added to the call stack via an event, above the appperforming CPYF] being notified of the condition. That is because the QT3REQIO from QWSGET was patiently waiting for input [e.g. Enter to return from the DSPMSG display] or in an effective hang condition.

If the problem is solid, i.e. each time run the problem occurs, then a TRCJOB is probably worthwhile to have active against the job since just before the application starts. Start tracing from a servicing job, a job which previously issued STRSRVJOB against the job that will presumably fail while the application is running.

Regards, Chuck

Peter Dow wrote:

This was from their live environment; they'll be refreshing their
test environment for other reasons, but I'll try to reproduce the
problem there and get a spooled job log with timestamps.

In the meantime, just to clarify, the job will sit in DSPW status
until the Rumba telnet session is manually terminated, at which
point it gets the CPF5170. Hopefully this will be apparent in
the forthcoming spooled joblog (it may be tomorrow before I'm
able to do it).


On 5/5/2010 11:14 PM, CRPence wrote:

Some corrections, inline:

CRPence wrote:

<<SNIP>>

The origin of the device error, how the device error is handled
according to the DEVRCYACN of the job, and how the emulator&
job reacted to both, seems to be the crux.

FWiW I recall over some years having some occasional but rare issues with break messages /hanging/ my session with the II
Input Inhibited indicator left on [and IIRC using DSCJOB or
ENDJOB to recover]; an issue which I eventually concluded most
likely had come about when I was actively typing while the
DSPMSG suddenly appeared with a panel of output-only text. I
never used Rumba however, and I do not recall ever getting a
specific resolution; having changed my user profiles to have
DLVRY(*HOLD) probably prevented some occurrences that might
have otherwise persisted.

<<SNIP>>