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 :-)

[Åge Rønning]

Could it be that you've got SYNCHRONIZE problems because qmgr reused an entry number between the time the original job was submitted and the batch stream went to synchronize with it?

One possible workaround is to subm/retain=until="TOMORROW"
to make sure you sync against correct entry.

You might want to delete the entry at the end of your procedure to clean up the queue.

[Ian Miller.]

re your side note about seeing how commands are defined - see Joe Meadows VERB utility from e.g http://vms.process.com/scripts/fileserv/fileserv.com?VERB

[Mike O'Malley]

Regarding your batch queue definition:

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


Adding W:SD allows anyone on the system to submit (S) to the queue and delete (D) any job in the queue. The delete access you need is already available with O:D (owner of job may delete it).

[Antoniov.]

Hi,
I have same problem. Some year ago I've used SYNCHRO command but DCL procedure sometimes fails; now I don't remember the reason but now I use a DCL procedure to synchonize work.
You can see the example DCL procedure that you can change.
If you are interesting I can search in my old documentation to discover exactly reason of this problem.

Bye
Antoniov

[Antoniov.]

OOPS
file .com means binary in windows; you cannot see attachment.
Now I changed name to SYNCHRO.TXT.

[Jesse Chambless]

To all who responded.

Many thanks! I have made several modifications to the command procedure but the following seems to have fixed/worked around the problem.

I added a 30 second delay before the synchronize command to give the job controller time to get everything set up and open. I also am using the entry number vice the name in the procedures.

Again, many thanks to all who responded.

[Antoniov.]

Hi Jessie
Sumbit som point to Pauli has helped giving a good idea.

Bye
Antoniov