Re: [OpenVMS Alpha V7.3-2] Batch/Print Job Numbering
- From: "AEF" <spamsink2001@xxxxxxxxx>
- Date: 19 Feb 2006 23:39:03 -0800
Dave Froble wrote:
AEF wrote:
David J Dachtera wrote:
AEF wrote:
David J Dachtera wrote:
Peter 'EPLAN' LANGSTOEGER wrote:
In article <43F6A30C.BCF5B109@xxxxxxxxxxx>, David J Dachtera <djesys.nospam@xxxxxxxxxxx> writes:
[...]
If you can, try this:
$ SUBMIT/qualifier(s) filespec/HOLD
$ JENTRY = F$FAO( "!7ZL", '$ENTRY' )
$ SET ENTRY '$ENTRY'/LOG=[ddcu:<dir>]filename_'JENTRY'.LOG/NOHOLD
That will produce fewer logs to sift through since you can then get a
listing of every entry number used for that job in ascending order by
entry number.
Personally, though, I agree with Michael: if the job is retained on
error, that entry number won't be re-used so long as that queue remains
retained.
That's not his problem. Imagine his queue numbers run from 1 to 1000.
His system runs 3000 jobs one day. Now he has found that entry 442 has
been retained on error. Now which of the 3 log files that contain 442
is the one that was retained in the queue??? Even though job 442 may be
reatined in the queue, that same number may have been used earlier in
the day.
How many times has that entry number been re-used?
Well, in this case, 3. But apparently it is too much. I think even a
low number is too much because you may have to do it many times. It's
like putting your return address on an envelope by hand. A former
housemate once made fun of pre-printed address labes as "Gee, how lazy
can you be?" Well, he didn't pay many bills himself. If he had to do it
a dozen times a month or more I think he'd get the point.
If the job's entry number:
$ enbr = F$GETQUI("DISPLAY_JOB","AFTER_TIME",,"THIS_JOB")
...is output to the log file, that will help naarow it down, but not
pin-point the target log.
Again, he wants it narrowed down completely.
Interesting thing about /RETAIN: if a job is retained, even when a queue
is set /RETAIN=ALWAYS, /DELETE of the log file doesn't take effect until
the entry is itself is DELETEd.
Well, that's good, no? I'm sure you'd complain if the log file were
deleted upon completion!
So, one other possible solution might be to SET the QUEUE /RETAIN=ERROR
and specify a "null" queue as the default print destination for batch
logs, then SUBMIT the jobs using /NOKEEP explicitly (to over-ride any
defaults due to symbols, etc.). That way, the only batch logs that will
remain on disk are those where the entry was retained due to the queue's
current SETtings.
That narrows it down even further. SHOW ENTRY/FULL or the appropriate
F$GETQUI() calls to automate the task for an entry would then be useful
to get down even closer to the target log using the completion time of
the job and the RDTs of the log files on disk.
It would be most helpful, of course, if the queue manager would update
the entry with the actual target filespec for the log file. Then again,
Yes, that would indeed be nice, at least for this case.
given that there does not seem to be a way to retrieve that outside of a
great deal of VMS "black magic", that may not even be possible right
Well, get the job_pid with f$getqui, make a temp file from show
dev/files, and search the temp file for the pid -- is that a lot of
black magic? (It *is* a somewhat roundabout way of doing things, but
sometimes you have no choice -- as in calculating the number of
combinations of n things taken r at a time. This is described in
probability field as follows: If you can't count the sheep, count their
legs and divide by four.) The macro that achieves the same result may
be, but it's already written and just has to be hunted down in archives
of this ng.
now. It would likely require considerable enhancement to
LOGINOUT.EXE(?).
Why doesn't he just add some kind of index or timestamp to the log-file
name? That seems like the best solution to me.
AEF
What seems the best solution to me is a utility that:
1) Could re-set the number to 0 or 1, depending upon what's stored, last
used, or next to use.
2) Could set the rollover number.
Every night at midnight, or whenever one wanted to, set the job numbers
to start at 1. As long as the range selected is large enough, ever job
in a day would have a unique number. That is what the OP wanted, right?
Yes, but he wanted this as a solution to a problem that has another
immediate solution: Add an index number or time stamp to the file name,
as in
$ INDEX = F$CVTIME("",,"TIME") - punctuation
$ SUBMIT EXCITING.COM /LOG=EXCITING-'INDEX'
but for some reason either he didn't see this solution or I don't know
what. The least the OP could do is tell us why *this* solution is not
going to work for him. ;-) Well, maybe it's some third-party software
that submits these jobs and he doesn't want to or can't muck with it.
David Froble Tel: 724-529-0450
AEF
.
- References:
- [OpenVMS Alpha V7.3-2] Batch/Print Job Numbering
- From: Peter 'EPLAN' LANGSTOEGER
- Re: [OpenVMS Alpha V7.3-2] Batch/Print Job Numbering
- From: David J Dachtera
- Re: [OpenVMS Alpha V7.3-2] Batch/Print Job Numbering
- From: AEF
- Re: [OpenVMS Alpha V7.3-2] Batch/Print Job Numbering
- From: David J Dachtera
- Re: [OpenVMS Alpha V7.3-2] Batch/Print Job Numbering
- From: AEF
- Re: [OpenVMS Alpha V7.3-2] Batch/Print Job Numbering
- From: Dave Froble
- [OpenVMS Alpha V7.3-2] Batch/Print Job Numbering
- Prev by Date: Re: [OpenVMS Alpha V7.3-2] Batch/Print Job Numbering
- Next by Date: Re: "A Historical Look at the VAX"
- Previous by thread: Re: [OpenVMS Alpha V7.3-2] Batch/Print Job Numbering
- Next by thread: Re: [OpenVMS Alpha V7.3-2] Batch/Print Job Numbering
- Index(es):
Relevant Pages
|