Operating System - OpenVMS
1827882 Members
1208 Online
109969 Solutions
New Discussion

copying queue database between systems

 
robert70
Valued Contributor

copying queue database between systems

Hi,

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]

$ copy SYS$QUEUE_MANAGER.QMAN$JOURNAL to INTEGRITY

$ copy SYS$QUEUE_MANAGER.QMAN$QUEUES to INTEGRITY

 

On Integrity

 

$start/queue/manager

 

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

 

2 REPLIES 2
robert70
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

Robert,

 

  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