On 26-Mar-2012 22:42 , kavi8586@xxxxxxxxx wrote:
Need information on QZDASOINIT prestart job, which gets submitted
for database request while using .NET provider.
A prestart job is started in advance of any utilization by a specific
user, i.e. pre-started, not /submitted/ in order to start some known work.
This prestart jobs use prestart job entries in the subsystem
description QUSRWRK, and automatically starts whenever the subsystem
starts.
Only according to the "Start jobs" (STRJOBS) setting, which could be
*NO. For STRJOBS(*NO), a STRPJE would need to be issued explicitly.
Implicitly started for STRJOBS(*YES), would be the specified "Initial
number of jobs" (INLJOBS), which then await work\start-requests.
And the subsequent QZDASOINIT job will get submitted for every
database request with the Job date (031812, though current date is
032312) same as automatically submitted job date (031812, QUSRWRK
SBS start date).
A database request effectively attaches\associates with an existing
job, typically in a _reuse_ of that job. If no waiting job is available
because the other jobs are associated already with some work, then the
"Threshold" (THRESHOLD) is met, and the "Additional number of jobs"
(ADLJOBS) are started and thus added to the available pool of PJs, if
not exceeding the "Maximum number of jobs" (MAXJOBS).
Given the original Initial jobs that were started in advance of being
associated with a specific program start request for which a user is
then assigned\switched-to in that job, the start date of those jobs
reflected as the Job Date seems reasonable and likely enough.? If the
job to which the program start request associates was started due to the
threshold having been met, then I suspect that the newly created
/additional/ job would have the current date as its "Job date" (DATE).
Because the system ends a job which has reached the "Maximum number of
uses" (MAXUSE), a new job replaces that job, and similarly I would
expect a new job date.
This is not a scheduled job, and so we don’t have a
control over this job.
Effectively scheduled, with job status "PSRW" meaning "The initial
thread of the job is a prestart job waiting for a program start
request." Control is most directly via the PreStart job settings, which
includes a job description and other Work Management, plus a user; these
would offer some additional control. There are also KB articles
describing other means of controlling QZDASOINIT Work Management, to
have them operate in different subsystem(s) and pool(s); links have been
posted in replies to messages on this list, which should be in the archive.
Anybody have idea on why the new instance of the job is getting
submitted with the job date same as automatically started job date?
Also, I cannot see the job log of the automatically started job, due
to QSECOFR profile auth.
I can not review a specific case to be sure [I also can not view an
active job or joblog for *N/QUSER/QZDASOINIT for _lack of_ the special
authority *JOBCTL and\or other special authorities], but presumably the
job date will remain the original start date for the prestart job until
any of: the job is ended with ENDJOB and a new PJ replaces that PJ, the
prestart jobs are all ended by ENDPJ and new job(s) are started with
STRPJ, the subsystem is ended with ENDSBS [or system ended\pwrdwn] and
the subsystem is restarted with PJE having STRJOBS(*YES), or a new PJ is
started after the threshold or the number of job reuses has been met for
which a _new_ PJ [instead of a job reuse] is the effect.
Also is there any way to control this job?
?CHGPJE SBSD(QUSRWRK) PGM(QZDASOINIT)
CHGJOBD of the *JOBD associated with the PJE.
Regards, Chuck
midrange.com
