topic Re: DCL Synchronize command in Operating System - OpenVMS

DCL Synchronize command

Jesse Chambless — Tue, 21 Oct 2003 07:36:44 GMT

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.

Re: DCL Synchronize command

Thomas Pauli — Tue, 21 Oct 2003 07:52:33 GMT

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

Re: DCL Synchronize command

Jesse Chambless — Tue, 21 Oct 2003 07:58:02 GMT

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,

Re: DCL Synchronize command

Jesse Chambless — Tue, 21 Oct 2003 08:28:23 GMT

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,

Re: DCL Synchronize command

Thomas Pauli — Tue, 21 Oct 2003 08:31:46 GMT

But is this queue a generic queue?

Re: DCL Synchronize command

Jesse Chambless — Tue, 21 Oct 2003 08:33:26 GMT

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

Re: DCL Synchronize command

Thomas Pauli — Tue, 21 Oct 2003 08:40:23 GMT

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'

Re: DCL Synchronize command

Jesse Chambless — Tue, 21 Oct 2003 08:42:31 GMT

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

Re: DCL Synchronize command

Jesse Chambless — Tue, 21 Oct 2003 09:12:17 GMT

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.

Re: DCL Synchronize command

Martin P.J. Zinser — Tue, 21 Oct 2003 09:51:42 GMT

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

Re: DCL Synchronize command

Åge Rønning — Tue, 21 Oct 2003 11:00:36 GMT

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.

Re: DCL Synchronize command

Ian Miller. — Tue, 21 Oct 2003 11:05:19 GMT

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

Re: DCL Synchronize command

Mike O'Malley — Tue, 21 Oct 2003 16:03:02 GMT

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

Re: DCL Synchronize command

Antoniov. — Wed, 22 Oct 2003 00:33:59 GMT

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

Re: DCL Synchronize command

Antoniov. — Wed, 22 Oct 2003 00:36:31 GMT

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

Re: DCL Synchronize command

Jesse Chambless — Tue, 11 Nov 2003 08:23:48 GMT

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.

Re: DCL Synchronize command

Antoniov. — Tue, 11 Nov 2003 08:52:38 GMT

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

Bye
Antoniov