This might explain the joblog bit...
Saving job logs:
i5/OS jobs have a log. Most i5/OS programs write status and error messages
to the job log as they run. Our Program Call server is no different. As it
runs it dumps information to the job log as it runs. When most jobs end, the
job log goes to an output queue. Our servers are different here. They start
and stop so often during normal processing, that writing their job log to an
output queue would eventually take all the space on the server. To avoid
this problem the server does not write its job log to an output queue. It
throws it away. The problem is that, in a debugging situation, there is
valuable data in the job log.
When debugging you want the job log saved so that you can figure out what is
wrong with the programs. You can override the default 'discard-job-log'
behaviour by changing the job description of the server job. The job
description has a whole pile of run-time tuning knobs for the server jobs.
Changing one of these parameters tells the server job to save the job log.
On pre-V4R4 systems, the name of the Client Access Host Server Job
Description object is QDFTJOBD.
In V4R4, the object is named QZBSJOBD.
Using the CHGJOBD command, specify the appropriate Job Description (QDFTJOBD
or QZBSJOBD), and set the "Message logging" parameter's "Text" option to
*SECLVL
The above came from
http://www-03.ibm.com/systems/i/software/toolbox/faqpgmcall.html
-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Dave Murvin
Sent: 29 October 2008 22:17
To: java400-l@xxxxxxxxxxxx
Subject: Problems with pcml Autostart jobs not ending
Hello,
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
Message ID . . . . . . : MCH2004 Severity . . . . . . . : 40
Message type . . . . . : Escape
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.
Message ID . . . . . . : CPC1210 Severity . . . . . . . : 50
Message type . . . . . : Completion
Date sent . . . . . . : 10/29/08 Time sent . . . . . . :
13:23:09
Message . . . . : Prestart job ending due to maximum use.
Cause . . . . . : The number of program start requests that the
prestart job
handled was the maximum defined by the MAXUSE parameter on the
prestart job
entry in the subsystem description.
Recovery . . . : The MAXUSE value can be changed by the Change
Prestart Job
Entry (CHGPJE) command if needed.
As far as I can tell, we already have this set to *NOMAX
Display Prestart Job Entry Detail
System: B
Subsystem description: QUSRWRK Status: ACTIVE
Program . . . . . . . . . . . . . . . . . . . . : QZRCSRVS
Library . . . . . . . . . . . . . . . . . . . : QSYS
User profile . . . . . . . . . . . . . . . . . . : QUSER
Job . . . . . . . . . . . . . . . . . . . . . . : QZRCSRVS
Job description . . . . . . . . . . . . . . . . : QZBSJOBD
Library . . . . . . . . . . . . . . . . . . . : QSYS
Start jobs . . . . . . . . . . . . . . . . . . . : *YES
Initial number of jobs . . . . . . . . . . . . . : 1
Threshold . . . . . . . . . . . . . . . . . . . : 1
Additional number of jobs . . . . . . . . . . . : 2
Maximum number of jobs . . . . . . . . . . . . . : *NOMAX
Maximum number of uses . . . . . . . . . . . . . : 1
Wait for job . . . . . . . . . . . . . . . . . . : *YES
Pool identifier . . . . . . . . . . . . . . . . : 1
The other message is probably associated with the CPC1210 message above
Message ID . . . . . . : CPIAD07 Severity . . . . . . . : 40
Message type . . . . . : Diagnostic
Date sent . . . . . . : 10/29/08 Time sent . . . . . . :
13:23:09
Message . . . . : Host server error occurred with reason code 7.
Cause . . . . . : A error with reason code 7 occurred during host
server
processing; the reason codes and their meanings are as follows:
1 -- Resolve to the host server daemon program failed.
2 -- Retrieval of the host server daemon program lock failed.
3 -- Submit job to start the host server daemon job failed.
4 -- Allocation of the host server daemon program failed.
5 -- Starting of the host server job failed.
6 -- Ending of the host server daemon job failed.
7 -- Activation of the host server job failed.
8 -- Processing of exchange random seed request failed.
Sorry for the lengthy email, but wanted to present all the data.
Thanks for your help.
Dave
midrange.com
