DCL Synchronize command

[Jesse Chambless]

I have several command procedures that use the SYNCHRONIZE command to maintain timing inside the procedure. The next step depends on the previous one completing normally before continuing.

My problem is that the command does not work consistantly. It will work perfectly for 4 or 5 days and then simply fail. I have ensured that the next command procedure is submitted with the same user as the main procedure. I would really appreciate help with this problem.

Here is a sample of the code.

$ Submit/log=hisd_workdir:load_cerner1020.log -
/name=load_cerner/USER=CHAMBJX -
/param=("10/20/2003","1020") HISD_WORKDIR:LOAD_cerner_CHARGE
Job LOAD_CERNER (queue UPENN2_SYSBATCH, entry 3195) started on UPENN2_SYSBATCH
$!wait for load_cerner_charge to finish and check if it is successful
$ show time
21-OCT-2003 08:00:01
$ SYNCHRONIZE LOAD_CERNER

Thanks in advance.

[Thomas Pauli]

Hello,
the documentation of the SYNCHRONIZE command emphasizes the need for delete (d)
access of the job. Is there a chance that the job runs on diferent queues on
different opportunities? For example through a generic queue? That this queues
have different access rights? This might explain the strange bahavior!
Regards,
T. Pauli

[Jesse Chambless]

The job is submitted to the same queue each time. It re-queues itself each run to the same queue that it is currently running on. I could set the process to have all privs -bypass as the jobs starts but don't know if that will help.

I am willing to try just about anything at this point.

It does appear that when the job fails, it is smaller than the other times. I do not know if that would have any bearing or not.

Thanks,

[Jesse Chambless]

I checked the protection on the batch queue and found that world had S priv. I reset the world protection to SD. I will keep an eye on it.

As a side note, is there a way to extract/look at the DCLTABLE.EXE entries to see how the commands are defined?

Thanks,

[Thomas Pauli]

But is this queue a generic queue?

[Jesse Chambless]

Nope. Batch execution queue. Here is the defination.

Batch queue UPENN2_SYSBATCH, idle, on UPENN2::
/BASE_PRIORITY=10 /JOB_LIMIT=20 /OWNER=[1,4] /PROTECTION=(S:M,O:D,G:R,W:SD)
/RETAIN=ERROR

[Thomas Pauli · Accepted solution]

Remains to check the user of the submitting process and its privileges. Sure that there is only one job LOAD_CERNER executing? To make sure to synchronize on the right process you might want to use the $ENTRY variable:
$ SUBMIT ...
$ ENTRY = $ENTRY
$ SYNCHRONIZE/ENTRY='ENTRY'

[Jesse Chambless]

Thanks. I will give that a try. I wasn't aware that I could get the entry in that manner.

[Jesse Chambless]

I have also discovered that using the mis-spelled work SYNCRONIZE will also work. I have tested the entry suggestion and it appears to work with my small test. I have searched for any .CLD files that would have re-defined the SYNCHRONIZE command but have found none on the system.

[Martin P.J. Zinser]

Well, DCL does not care very much after the first 4 characters, so essentially the stuff after sync... may contain spelling errors.

Other example:

$ renane temp.txt temp1.txt

works perfectly fine :-)