Hi all,
Thanks to the 13 who responded with suggestions and comments re. JINFO.
Here are my amendments to Draft-1. I am happy to re-send the full draft-1
specs to those who missed the first round, but to save bandwidth I am
only sending the changes this pass.
Jeff Vance, CSY
-=-=-=-=-=-=-=-=-=-=-=-=-=
> how about stdin_spid and stdlist_spid for the stdin and stdlist spool
> file id numbers?
?????????????
> ...be able to have the JINFO retrieve information from a log file for
> jobs that have finished. Then one could also retrieve the finish time
> for the job.
I am not planning on adding this feature to JINFO. Although I see value
in having all job related info available via a single function, I believe
you can get this information from the system log file.
> any chance we may see something along the lines of AINFO (account info),
> GINFO, UINFO, etc.
Good idea for a later project!
> change to
> INTRO_DATE_YMD INTINTRODATE
> INTRO_DATE_FMT FMTINTRODATE
> INTRO_TIME_HMS INTINTROTIME
> INTRO_TIME_FMT FMTINTROTIME
> SUBM_DATE_YMD INTSUBMD
> SUBM_DATE_FMT FMTSUBMDATE
> SUBM_TIME_HMS INTSUBMTIME
> SUBM_TIME_FMT FMTSUBMTIME
OK with me. How do others feel?
> With EXECPRI being type int, will this be the current priority
> value?
My mistake. The "exec_pri" item will be a formatted string: "AS", "BS"
"CS", "DS", "ES".
> For scheduled jobs, is introdate/time the scheduled time?
It appears to be the scheduled date/time.
> Support both job/session numbers and [jobname,]user.acct for the
> first argument.
OK.
Syntax: JINFO ( jobID, item [,status] )
jobID Required. String identifying the target job or session that
information is being requested for. Format is "[#]J|Snnn" or
"[jobname,]user.acct" (wildcarding is supported), or "0".
If set to "0" the current job/session is used as the
target job.
This results in new status uses and values:
-999 - internal error, please report.
-5 - insufficient capabilities for specified item.
-4 - unable to retrieve item, e.g. 'restart' requested for a
session.
-3 - illegal job ID specification, syntax error.
-2 - unknown item requested.
-1 - non-existent job(s).
0 - success, or the number of jobs that match "jobID" when
it is specified as "[jobname,]user.acct".
positive - the number of jobs that match "jobID" when
it is specified as "[jobname,]user.acct".
Another example:
setvar _jobs jinfo('jpay,@.payroll','job_id',status)
if status > 0 and wordcnt(_jobs) < status then
# more jobs match than fit into a CI var...
...
setvar j 0
while setvar(job,word(_jobs,,setvar(j,j+1))) <> "" do
if jinfo(job,'exists') ...
JINFO Item Values and Descriptions
Note: if more than one job matches a "user.acct" jobID the only
supported item is "job_ID". If the "user.acct" format is specified
and only one job matches then all of the items are available.
mnemonic type * description/comments
-------- ------ --------------------------------------------------
...
job_ID string unique job identifier, "#J|Snnnn". When the
"user.acct" form is specified JINFO returns a
list of job IDs separated by a space. Eg.:
"S24 S25 J13 J15".
> Support both mnemonic and numeric items.
My plan is still to support only mnemonic items. I still see scripts
that invoke FINFO with a number, which makes the script less readable.
Also, JINFO will not be calling the JOBINFO intrinsic so there is no
leverage there. There are many offered JINFO items that are not available
via JOBINFO().
> List the mnemonics in JOBINFO order.
As I say above I am not calling JOBINFO; however, I am open to any
order (for help text) that makes sense.
> Don't require the # in the job/session id. 'j1' s/b == '#j1'.
Done. See revised syntax above.
> I would have expected the first parameter to have the option to be a job
> name,user.account, and the second parameter to possibly be the EXEC,SCHED
> status, and a return value to be a count of them. Maybe the EXEC/SCHED
> status is part of the first parameter, and the second parameter could be
> COUNT or JSNUM if there where only one.
The first arg can now be "[jobname,]user.acct" with wildcards. It is the
same syntax used by the new PAUSE-for-a-job JOB= parameter. The job's
state can be determined via the "state" item which will return "EXEC",
"SUSP", "WAIT", "INIT", "SCHED" The count is visible via the existing status
argument.
> a user with OP capability should be able to get at most information for
> all jobs (like output pri, num copies), to be consistent with things like
> NBSPOOL which we use, and presumably SPIFF, which we don't.
OK.
Restrictions:
------------
No special capabilities are required to get any info about your own
job/session, or to get any of the data displayed by the SHOWJOB command for
any job/session on the system. Users with OP or SM capability can get all
items for any job/session.
For users lacking OP or SM capability:
To get data not shown by SHOWJOB about another job logged onto your same
"user.acct" you will need AM capability, unless JOBSECURITY is set to LOW.
If JOBSECURITY is LOW, jinfo() considers the job as if it is "you".
To get info not shown by SHOWJOB about jobs logged on as any user in your
same account you need AM or capability, independent of the JOBSECURITY
setting.
> how can you tell at present that the system is running in
> 'degraded mode', apart from the fact that no jobs seem to be logging on?
Today you see a console message and that's about it. With JINFO
you can determine programmatically.
> beyond 'Last command executed' I'd like to see the line (record?) number
> being executed.
This doesn't appear easy to implement. How widespread is this need?
Can it be done later?
--
|
