×
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.
I have asked this question before and received several answers. We
chose to try the simplest answer and the solution seems to work, but I
have questions about the results.
Review of the problem:
We have an RPGLE shipment posting program that gets called by a Java
program. These jobs are sent to the QUSRWRK subsystem. Each time the
Java program calls the RPGLE program, a new job is started in QUSRWRK.
The old problem was that they never completed and the only way to get
them to go away was to shutdown the subsystem.
The Java code snippet as it now stands with the suggested correction:
// Call PSHPINF API
pcml.callProgram("PSHPINF"); // program name
// Disconnect //A BR02027
sys.disconnectAllServices(); //A BR02027 <== This is the change we
added.
In testing the new version, the subsystem jobs seem to go away, but
there is something funny going when I look at the job log.
DSPJOB Opt 3 - Display job run attributes, if active
(No run attributes, the job is not active) <== Looks good so
far
DSPJOB Opt 11 - Display call stack, if active
(No call stack) <==
Looks good
DSPJOB option 10 - Job log if active <== This is kind of
strange. Job log did not go to spool file
Job 519591/QUSER/QZRCSRVS started on 10/29/08 at 13:18:31 in subsyste
QUSRWRK in QSYS. Job entered system on 10/29/08 at 13:18:31.
ACGDTA for 519591/QUSER/QZRCSRVS not journaled; reason 1.
User SHPTST_SVC from client 127.0.0.1 connected to server.
Library QSYS2924 not found.
Client request - run program BSITST/PSHPINF.
Job 519591/QUSER/QZRCSRVS held by user DAVEM with option SPLFILE(*NO)
Job 519591/QUSER/QZRCSRVS released by user DAVEM.
Job 519591/QUSER/QZRCSRVS changed by DAVEM.
Delivery 23460 package 2811 has already been processed through Varsit
Trans NOK Delivery: 23460 Pkg: 2811 Order: Carrier: UPS Ship Inst:
ACGDTA for 519591/QUSER/QZRCSRVS not journaled; reason 1.
ACGDTA for 519591/QUSER/QZRCSRVS not journaled; reason 1.
Prestart job ending due to maximum use.
Host server error occurred with reason code 7.
Object ZRCUSRSPC in QTEMP type *USRSPC deleted.
Object ZRCRPCSPC in QTEMP type *USRSPC deleted.
Job 519591/QUSER/QZRCSRVS ended on 10/29/08 at 13:23:09; 1 seconds used
end code 10 .
Waiting on event not valid at this time.
<== This is what concerns me
Date sent . . . . . . : 10/29/08 Time sent . . . . . . :
13:23:09
Message . . . . : Waiting on event not valid at this time.
Cause . . . . . : A thread attempted to wait for a specific event, but
previously the thread indicated not to be interrupted by any event.
Recovery . . . : If this is an interactive job, sign off and sign on
again.
Report the problem using the Analyze Problem (ANZPRB) command.
Technical description . . . . . . . . : The wait on event instruction
was
sent while the thread was masked. To help determine the cause of the
error,
turn trace on (TRCJOB command) before you re-create this error.
This seems to keep part of the job active so the joblog does not get
written to the spool file. Should we be concerned about this? Should
we be doing something differently?
I also have a question about two other messages in the job log.
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.