×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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>>
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.