Problem with batch jobs using the same command file

[Synergy_1]

I submit a batch job using X.COM and name the job X1. While X1 is active, I submit batch job X2, also using command file X.COM.

X.COM displays its job entry, job name and process ID. X1.LOG displays X1 as its job as expected. However, X2.LOG displays X1's job entry, name and PID. Is this a bug? Is there a work around? This was on version 7.3-2 of OpenVMS.

Thanx

Chuck Paulissen

The following shows the actual process:


$TYP X.COM
$ SET NOON
$ SAY := WRITE SYS$OUTPUT
$ JE = F$GETQUI("DISPLAY_ENTRY","ENTRY_NUMBER")
$ JN = F$GETQUI("DISPLAY_ENTRY","JOB_NAME")
$ JP = F$GETQUI("DISPLAY_ENTRY","JOB_PID")
$ SAY "Entry Number=''JE'"
$ SAY "Job Name=''JN'"
$ SAY "Job PID=''JP'"
$ WAIT 00:00:05
$EXIT:
$ EXIT
$SUBMIT/NAME=X1/LOG=PPS_LOG:X1.LOG X
Job X1 (queue BRONER_BATCH, entry 646) started on BRONER_BATCH
$SUBMIT/NAME=X2/LOG=PPS_LOG:X2.LOG X
Job X2 (queue BRONER_BATCH, entry 647) started on BRONER_BATCH
$

Job X1 (queue BRONER_BATCH, entry 646) completed
$

Job X2 (queue BRONER_BATCH, entry 647) completed
$TYP PPS_LOG:X1.LOG
$ Set NOON
Entry Number=646
Job Name=X1
Job PID=00050CD3
PPS_CPAULISS job terminated at 4-SEP-2007 16:00:54.81

Accounting information:
Buffered I/O count: 280 Peak working set size: 5744
Direct I/O count: 143 Peak virtual size: 173616
Page faults: 851 Mounted volumes: 0
Charged CPU time: 0 00:00:00.09 Elapsed time: 0 00:00:05.31
$
$TYP PPS_LOG:X2.LOG
$ Set NOON
Entry Number=646
Job Name=X1
Job PID=00050CD3
PPS_CPAULISS job terminated at 4-SEP-2007 16:00:56.47

Accounting information:
Buffered I/O count: 280 Peak working set size: 5744
Direct I/O count: 140 Peak virtual size: 173616
Page faults: 851 Mounted volumes: 0
Charged CPU time: 0 00:00:00.08 Elapsed time: 0 00:00:05.12
$

[Hein van den Heuvel · Accepted solution]

F$GETQUI("DISPLAY_ENTRY"...) is a wildcard operation. Chech the HELP or manuals.
It matched all your jobs, and does NOT start with the current job.

You _could_ contrain the wildcard passing a job name, but that would defeat the purpose.
Change code to look like:

:
$ JE = F$GETQUI("DISPLAY_ENTRY","ENTRY_NUMBER",p1)
:
and submit as:

$ SUBMIT/noti/NAME=X1/LOG=X1.LOG x/param=x1

The right solution is prbably to use DISPLAY_JOB, not DISPLAY_ENTRY with the "THIS_JOB" option.

Something like:
:
$ JE = F$GETQUI("DISPLAY_job","ENTRY_NUMBER",,"THIS_JOB")
:

Enjoy,
Hein.

[Hein van den Heuvel]

Oh, and to address the subject line:

"Problem with batch jobs using the same command file"

In case that was not yet blatantly obvious... the 'same command file' was a red herring.
Two distinct commands files would have behaved exactly the some.

fwiw,
Hein.

[Jan van den Ende]

Synergy,

to begin with:

WELCOME to the VMS Forums!!

The reason that your way at least partly works, is that your default batch queue (SYS$BATCH, or the one pointed to by LNM SYS$BATCH) just happens to be the first (maybe only?) one scanned.
And, there are precious few jobs IN that queue, or you might have a far bigger chance of hitting on any of the others.

SYS$GETQUI is not exactly the most "human-friendly" construct, and F$GETQUI is just a wrapper to make it available in DCL.
Howver, it _IS_ a very powerfull tool!
But to be able to use it, it is really necessary to look up the effects of the WILDCARD and the FREEZE_CONTEXT control parameters.
Again: not exactly human-friendly syntax, but powerfull.

The DCL manual has (under Lexical functions, F$GETQUI) some rather good examples. Quite instructive to work though them to get the feel for it.

hth

Proost.

Have one on me.

jpe

[Ian Miller.]

examples of using F$GETQUI can be found at
http://dcl.openvms.org