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

copying queue database between systems

Valued Contributor

copying queue database between systems


About to go LIVE with a new system (Integrity Server running VMS8.4, Node Name - CHAS)


Looking to Migrate the Queue Database across from the current system (Alpha DS20 VMS 8.3, also Node Name CHAS)


Can I simply


On Alpha


$ stop/queue/manager/cluster

$ set def systemdisk:[sys0.syscommon.sysexe]




On Integrity




Since node names are identical presume queues will be identical and start with no problems?


Valued Contributor

Re: copying queue database between systems

I came across another thread on the subject form JESS
he had written a nifty little command file to create a command file to run on the migrated node - works perfectly thanks JESS
John Gillings
Honored Contributor

Re: copying queue database between systems



  Answering your question, no I wouldn't expect the queues to  start with no problems. It might workbut only under a very restrictive set of circumstances. Queue entries refer to files by FID, so unless you have image copies of all disks, entries will break. There are possibly other entities within the queue manager data base using physical (resolved), rather than logical references, like identifiers. The queue manager is a notoriously intractable file for backing up and restoring even on the same system. I certainly wouldn't trust it on a different system, no matter how closely you think you've cloned the old one.


  It's relatively easy to convert the output of SHOW QUEUE/FULL into SUBMIT commands to regenerate jobs. I'd guess that's what Jess's procedure does.


  More generally, if you have a system with some set of jobs that are expected to be regularly scheduled, please make sure you have a procedure that can check everything is present and correct. That way your problem becomes moot. You just execute the checker when the system starts.


My procedures all have a self submit branch which knows when, where and how the procedure should execute, invoked with


$ @<prodcedure> #SUBMIT [<after>] [<queue>] [<logfile>] [<params>...]


using common code, so everything behaves the same way.

A crucible of informative mistakes