×
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.
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
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.
midrange.com
