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

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 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].