Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Delaying DCL Commands

 
Highlighted
New Member

Delaying DCL Commands

First, let me apologize, I spent time searching for this question, but could not find it, so I'm starting a new thread.

I have a program that I want to do the following things: Execute File_A.com, Wait till File_A.com is finished, and then Execute File_B.com

Currently the program does a spawn/nowait submit File_B.com to remote notes and then a submit File_B.com to itself. This sends a command to all remote nodes to shutdown and then gives the host node the same command.

I want to execute a File_A.com (which deletes the temporary folders... which takes anywhere from 1-2 minutes) to remote nodes, wait for it to finish deleting before submitting File_B.com.

I've tried using spawn/wait and different forms of submit to no success. Basically, it submits File_A.com to run, but submits File_B.com at the same time and just shuts the computer down before anything gets deleted. I'm new to DCL.

Is there anyway I can easily code this without hard coding a WAIT 00:02:00 into the code?

I want to thank everyone in advance for their help.

- Dev
17 REPLIES 17
Highlighted
Honored Contributor

Re: Delaying DCL Commands


Check out the $ SYNC command.

Also, you may want to call the job controller directory to submit a job, but admittedly a LIB$SPAWN call is much easier.

Hmmm... it woudl perhpas be nice to have a LIB$SUBMIT kind of call which takes a SUBMIT or PRINT string as one would use at DCL level and parse it into a corresponding SYS$SNDJBC call.

Does anyone have anything handy? Freeware?


Hein
Highlighted
Honored Contributor

Re: Delaying DCL Commands

Implement your application clean-up sequence within the SYSHUTDWN.COM procedure and use SYSMAN to send a SHUTDOWN to all hosts?

Better still, implement your application clean-up sequence in SYSTARTUP_VMS.COM procedure, and then use SYSMAN to send the SHUTDOWN command to all hosts.

Highlighted
Frequent Advisor

Re: Delaying DCL Commands

Either create a C.COM that runs A.COM & B.COM and submit that, or submit the jobs to a queue with a JOB_LIMIT of 1 ?

Highlighted
Trusted Contributor

Re: Delaying DCL Commands

Hi Dev,

Welcome to DCL.

What I'd do in this case is code what I want into a command procedure which would call SYSMAN.

SYSMAN is able to do things on remote nodes. It requires a password for the remote nodes if they're not in your present login environment (i.e. it shouldn't ask in a cluster, but if you're connecting to another node that's not clustered with your present one then it will ask for a password.)

You'd need to do something like this:

$ MC SYSMAN
set environment/node=(nodea,nodeb,nodec,noded)
do delete disk$user:[mydirectory]temp*.txt
shutdown node/min=0/reboot_check/invoke/noauto
$ exit

If I've remembered my syntax right, the /noauto should prevent the node from automatically rebooting - i.e. it will shutdown, not reboot.
/min=0 says, "do it now"
/reboot_check tells the systems to check that they have the basic expected files that VMS needs to reboot this system. It doesn't check for user files so doesn't guarantee that the system will startup correctly, just does a best effort that VMS will start.

Alternatively, submit jobs to a batch queue with a job limit of one so that the shutdown job will have to wait behind the delete job.
Highlighted
Honored Contributor

Re: Delaying DCL Commands

Dev,

I too would use SYSMAN's DO command, following a SET ENVIRONMENT.

A batch queue on each node would leave open a variety of race conditions if the other node were shut down or shutting down. SYSMAN would be entirely synchronous, and the request would disappear in those cases.

As a safety, the clean-out step should also be included in the application's STARTUP processing on system reboot.

- Bob Gezelter, http://www.rlgsc.com
Highlighted
Honored Contributor

Re: Delaying DCL Commands

Application cleanup during shutdown catches a few cases; those that involve a clean shutdown.

Cleanup at startup time catches all the cases.

If you have restrictive startup time constraints, then look to move the scratch directory (directories?) and cache directories to the side via RENAME and create and start with a new scratch directory at startup, and then clean up the older scratch directories once the application is running and has some cycles available for the task.

Yet better, that performs periodic cleanup of the caches or scratch files as some OpenVMS application environments can operate continuously for days or weeks and can (depending on the application) build up cruft or file versions at run-time.

But shutdown is not particularly effective.

I'd use the site-specific SYSTARTUP_VMS.COM procedure or the application startup procedure (mumble_STARTUP.COM, usually), or directly integrate the file management tasks into the application.
Highlighted
Honored Contributor

Re: Delaying DCL Commands

Dev,

You're correct to avoid the simplistic "wait 2:00" method. It's bound to fail at some time.

As others have suggested, batch jobs and SYNCHRONIZE or SYSMAN are definite possibilities. You can also use RSH or SSH, which are synchronous.

Another option is to use the lock manager. If you're V8.3 or higher, you can use a shared indexed file and READ/WAIT to implement a dead man lock.

So your procedure A.COM locks the record, when it's finished it releases the record. B.COM can READ/WAIT the same record. This scales nicely for multiple nodes, using the node name as part of the record key. This scales to multiple nodes.

I've included a procedure that automatically distributes cleanup and shutdown across a cluster, using RMS locks. Note that it assumes TCPIP proxies across the cluster to use RSH. Because RSH is synchronous, it's not actually necessary to use the locks. If you want to make the jobs on each node execute in parallel, modify the procedure to run an asynch process on the remote node, then you will need the locking.
A crucible of informative mistakes
Highlighted
Trusted Contributor

Re: Delaying DCL Commands

Why are you telling other nodes in the cluster to delete files when you could probably directly do that from the node you are on?

If you do that then it's just a cluster shutdown from the node where you are.

Further, what's your reason for deleting these files prior to shutdown?

There could be several different reasons but I suggest that deleting during startup (perhaps via batch job) could be an easier option and maybe deleting them after startup might give you the option of reviewing them before they are deleted.
Highlighted
Trusted Contributor

Re: Delaying DCL Commands

"Hmmm... it would perhaps be nice to have a LIB$SUBMIT kind of call which takes a SUBMIT or PRINT string as one would use at DCL level and parse it into a corresponding SYS$SNDJBC call.

Does anyone have anything handy? Freeware?"

23 years ago, before queues supported ACLs, I wrote a substitute print command that effectively did that. It's pretty straight forward to map the job/file attribute qualfiers to SJC item codes, but you have to process wildcard file specifications and the selection criteria (/since, /before, etc) qualifers yourself.
I'm looking for marbles all day long.