Script error when executing in batch queue

[smg_atlas]

Hi there,

I've been provided a script which needs to be run every day. After researching this forum, I was able to schedule it via the batch queue like so:

type DBLOCKCLEAN.COM
$ dblockclean = f$environment("PROCEDURE")
$ SUBMIT 'dblockclean' -
/AFTER="TOMORROW+19:30"/NOPRINT/KEEP -
/NAME=dsa0 [backup.lockcheck]dvaxkillsuts.com -
/log=dsa0:[backup.lockcheck]dblockclean.log

This seemed to work as it placed dvaxkillsuts.com into the batch queue as I wanted.
Problem is, when it executes at 1930, it doesn't kill the open sessions as it needs to.

When we run this script manually, it kills the active database sessions - when it runs via the batch queue, it does not.
Am I doing something wrong with how I submit this job to the queue? A problem in the script itself?
I'd be grateful for any insight!

Here is the script that gets executed at 1930:

$ PIPE RMU/SH USERS TRAFFIC_STATS_RDB_DB | SEA SYS$INPUT "WISHART","CLARKR","AND
ERSONJ","STRICKLAND" /OUT=SYS$LOGIN:DVAX_SUTS.LIS
$ OPEN INPUT_FILE SYS$LOGIN:DVAX_SUTS.LIS
$ OPEN/WRITE OUTPUT_FILE SYS$LOGIN:TEMP.COM
$ READ_LOOP:
$ READ/END_OF_FILE=ENDIT INPUT_FILE REC1
$ WRITE OUTPUT_FILE "$ STOP/ID= "+F$EXTRACT(6,8,REC1)
$ GOTO READ_LOOP
$ ENDIT:
$ CLOSE INPUT_FILE
$ CLOSE OUTPUT_FILE
$ msg "Following processes have been stopped:"
$ type sys$login:temp.com
$ !@SYS$LOGIN:TEMP.COM
$ EXIT


Thanks,

Mike

[Steven Schweda]

> [...] /log=dsa0:[backup.lockcheck]dblockclean.log

Any clues in there?

[Hoff]

Context and error messages make this easier to debug.

And in general, you've been provided with a DCL command procedure with some sort of unspecified problems and/or with a different intended use than the present sequence, and you're asking for debugging and coding support here? Odd. It would seem more expedient to get in contact with whomever gave you this DCL procedure, and ask them for help.

As for other spots to look beyond the log file that Steve mentions (and do look there first!), also do look in the intermediate files used here:

SYS$LOGIN:DVAX_SUTS.LIS
SYS$LOGIN:TEMP.COM

The DCL procedure also appears to have code selected from and integrated from various spots; there are commented-out lines and some odd differences in coding styes.

There are also potential issues with error handling (potential for collision with temporary files, lack of SET NOON or ON processing), with privileges (most database operations require privileges (and this DCL doesn't enable them).

There are some other areas of potential improvements, such as using CLOSE /NOLOG before the open. Less of an issue with a batch job, having an open file can derail interactive invocations.

Do some debug.

Or contact whomever gave you the tool.

Get some training on DCL and/or find a copy of the DCL book I wrote a while back and/or take a look at the OpenVMS User's Guide.

Or a combination of these.

But regardless, you're going to have to do some debugging here to get to the bottom of this.

[John Gillings]

Mike,

You create a file called TEMP.COM containing a sequence of STOP/ID commands to kill your processes, BUT the procedure never gets executed because the second last line is commented out. The procedure therefore says it has stopped the processes, but it hasn't.

Why create a temporary file at all? It's just clutter. The file itself is clearly "one shot" because it's specific to a single point in time state, which it then destroys. Leaving it around is slightly dangerous as it kills what are effectively random PIDs (though the mechanism for allocating PIDs avoids short term reuse of PIDs, so will protect you from most accidents).

Even if that were fixed, the SUBMIT command you've posted seems to be assuming the /NAME qualifier names the procedure to execute. It doesn't, it's just the job name. Your SUBMIT command therefore just submits and executes itself, but gives itself the name of another procedure. A recipe for confusion!

Here's how I'd code it, with the SUBMIT logic included in the procedure itself.

DVAXKILLSUTS.COM

$ self=F$PARSE(";",F$ENVIRONMENT("PROCEDURE"))
$ IF p1.NES."" THEN GOTO 'p1'
$ IF F$MODE().EQS."BATCH" THEN @'self' SUBMIT
$ PIPE RMU/SHOW USERS TRAFFIC_STATS_RDB_DB | -
SEARCH/NOHEAD SYS$PIPE "WISHART","CLARKR","ANDERSONJ","STRICKLAND" |-
@'self' KILL
$ EXIT
$ SUBMIT:
$ SUBMIT 'self' -
/AFTER="TOMORROW+19:30"/NOPRINT/KEEP -
/LOG='F$PARSE("DSA0:[BACKUP.LOCKCHECK].LOG",self)'
$ EXIT
$ KILL: READ/END_OF_FILE=ENDIT SYS$PIPE REC1
$ pid=F$EDIT(F$ELEMENT(0,":",REC1),"COLLAPSE")-"-"
$ IF F$INTEGER("%x"+pid).NE.0
$ THEN
$ WRITE SYS$OUTPUT "Stopping ''REC1'"
$ STOP/IMAGE/ID='pid'
$ ENDIF
$ GOTO KILL
$ ENDIT:
$ EXIT

Note I've put in a sanity check to check the value extracted from the listing looks reasonable. I'm also using STOP/IMAGE as it's a bit safer.

To submit it:

$ @DVAXKILLSUTS SUBMIT

it will then resubmit itself daily.

[The Brit]

Mike,
I have a couple of comments about the initial submission script you posted. There does seem to be a couple of problems with it.

type DBLOCKCLEAN.COM
$ dblockclean = f$environment("PROCEDURE")
$ SUBMIT 'dblockclean' -
/AFTER="TOMORROW+19:30"/NOPRINT/KEEP -
/NAME=dsa0 [backup.lockcheck]dvaxkillsuts.com -
/log=dsa0:[backup.lockcheck]dblockclean.log


1. The Qualifier "/NAME" is deceiving you. It is NOT the name of the script that was submitted, it is just the name that is listed in the batch queue, under "JOB NAME"
2. I also assume that you didn't cut-n-paste the text, since there is a colon missing after DSA0 in the /NAME line.

The code above simply resubmits itself, nothing else. The log file should verify that.

Try

$ SUBMIT DSA0:[backup.logcheck]dvaxkillsuts.com -
/AFTER="TOMORROW+19:30"/NOPRINT/KEEP -
/NAME="dvaxkillsuts" -
/log=dsa0:[backup.lockcheck]dvaxkillsuts.log


Dave.

[Hoff]

It's also possible to use RMU to close a database and/or to toss users off a database, too. Nuking connected processes tends to mean Rdb has to clean up after the nuked users; that does and should work, but it's not necessarily the most efficient strategy.

[smg_atlas]

Thanks so much for your help!

Steven: I checked the log file dsa0:[backup.lockcheck]dblockclean.log and all it shows is the execution of the batch job - it executed successfully.

John and The Brit: Thanks for pointing out about the /name qualifier deceiving me! I'll try the suggestions you mention.

I see what you mean about the 2nd last line being commented out, but correct me if I'm wrong in thinking that the file in question is just a record of the process id's stopped?
Ie: the actual topping of the processes is done by the reading in from the .lis and doing the stop/id on it? (if that makes sense).

I'm not coming from a OpenVMS background at all and appreciate all your help to date.

[H_Bachner]

Mike,

> I see what you mean about the 2nd last line being commented out, but
> correct me if I'm wrong in thinking that the file in question is just a
> record of the process id's stopped?

No, you write the STOP commands to file TEMP.COM (and don't stop any process at this point). So you need to execute the file to get the STOP commands do their work. Just remove the "!" in fromt of that line.

Hans.

[John Gillings]

Mike,

>Ie: the actual topping of the processes is
>done by the reading in from the .lis and
>doing the stop/id on it? (if that makes
>sense).

No. As Hans said, you're writing the STOP command to a temporary file, rather than executing them.

It doesn't make much sense to me to write the file. What's the point? It just adds complexity, and leaves potentially dangerous junk on your disk. If accidently executed at some future time it may kill random processes.

You could simplify your procedure by removing the temporary file (see the procedure I posted earlier).

On the other hand, it sounds like an even better idea is Hoff's suggestion to use RMU to close the data base. Replace the whole procedure with a single command:

$ RMU/CLOSE/CLUSTER/WAIT/ABORT=FORCEX TRAFFIC_STATS_RDB_DB

(please check the Rdb documentation to make sure this does what you want, in particular, you may want /ABORT=DELPRC, depending on how you want incomplete transactions and recovery journals dealt with).

[smg_atlas]

Thanks for the help, problem has been resolved by following some of the suggestions / ideas presented. Points awarded.