Thanks for the insights. Ctrl-Esc is mapped to SysRqs.
The user's message queue status was set to *NOTIFY but she had 4
interactive sessions. The user message queue was allocated to a
different session.
The program that was active in the 'hung' session has a message handling
program that does send formatted messages TOPGMQ(*PRV). The user had
done over 2600 entries each of which would have caused a message to be
sent.
QJOBMSGQFL is set to *PRTWRAP. I did not see that happen. Other message
queue values (QJOBMSGQMX, QJOBMSGQSZ, QJOBMSGQTL) are set at the shipped
levels (64, 16, 24). This is a V6R1 system with lots of disk & memory
and only 4 users each running 4 sessions.
We will do the WRKJOB OUTPUT(*PRINT) next time it happens.
Thanks again.
Bonnie Lokenvitz
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Friday, May 28, 2010 12:54 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: RPGLE program quits on READ of subfile control
On 27-May-2010 13:23, Bonnie Lokenvitz wrote:
I am working with an interactive production program that is used
daily.
About once a month it quits functioning for one user after she
has entered 2000+ lines (which are written to a file in QTEMP).
The program stops after it writes the subfile control record and
attempts the following READ statement.
Today I had the user do a CTRL/ESC to a new session, log on, log
off. This made the READ statement in the original session work.
Any ideas of what is going on?
What is Ctrl-Esc mapped to? Presumably SysRqs [System Request]
such that SysRqs-1 effects TFRSECJOB, or SysRqs shows the System
Request panel? If so, are the other activities required, or might
just SysRqs followed by F12 to return to the processing get things
going again? Regardless, when it happens again, probably better to
have another user\job request a WRKJOB OUTPUT(*PRINT) against the
apparently-hung job to see its status and program stack.
FWiW the return to a job after the sequence of TFRSECJOB, signon,
and signoff, will check the break\notify for the workstation [&
user?] message queue. The DLVRY() setting for the user or the
workstation message queue might be germane.
Regards, Chuck
midrange.com
