More fun with the DR server. All the data and user disks are image backed up and restored to the DR server each night (operations are quiesced so we know they are clean). System disk gets an occasional standalone backup that is restored to the DR box production system disk (it is running on an alternate disk for all of these ops), but most nights an evil online backup is performed, transferred, and then only specific files (SYSUAF, etc) are overlayed on the DR server's offline production system disk.

Is there a best way to stop all batch queues when/if this system is booted on its production disk? It will have jobs that were pending at the time backup was done (the standalone backups) which will of course try to run when the batch queues start. We want the job controller up, queue manager _preferably_ up, print queues don't care, but batch queues ALL stopped.

Queues are a mix of autostart and normal queues. I can change the autostarts to not be autostart.

Right now my thought is to make sure all the batch queue defines and starts are in a single startup procedure (they are supposed to be but the system was customer managed for many years and now they are not) and drop in a no-op procedure same name next higher version that just exits.

The onsite manager would have docs telling them to check the queues, clear the jobs as needed, and then delete the no-op file and run the real one.

Or could pick out the serial number or MAC address or other unique ID and run batch startups when on the main server and bypass when on the DR server.

Looked through the startup whitepaper and docs for means to use a different boot option selection but I don't see a way to pass that intention through to the startup

Ideas appreciated.
Thanks
Rich

On 2022-06-20 17:13:36 +0000, Rich Jordan said:

> More fun with the DR server. All the data and user disks are image
> backed up and restored to the DR server each night (operations are
> quiesced so we know they are clean). System disk gets an occasional
> standalone backup that is restored to the DR box production system disk
> (it is running on an alternate disk for all of these ops), but most
> nights an evil online backup is performed, transferred, and then only
> specific files (SYSUAF, etc) are overlayed on the DR server's offline
> production system disk.
>
> Is there a best way to stop all batch queues when/if this system is
> booted on its production disk? It will have jobs that were pending at
> the time backup was done (the standalone backups) which will of course
> try to run when the batch queues start. We want the job controller up,
> queue manager _preferably_ up, print queues don't care, but batch
> queues ALL stopped...

Stopping everything is easy. Restarting (just) what devices and batch
queues you want restarted is harder, and requires a specific script,
err, procedure for the restart.

I'd possibly look to (mis)use a site-specific tailored version of
FIXQUE to transfer over the data in your home-grown "cluster" failover
configuration; for the specific case here. VSI has a copy of FIXQUE
posted.

Pragmatically, you're writing migration and reinstallation tools.
Piecemeal. You could step back from this piecemeal design approach, and
stop trying to match the details of the environments (and those always
get skewed), and work to migrate the data, and to manage and re-install
the apps and tools tools using PCSI or VMSINSTAL or less-bueno
home-grown installers. This also means an easier approach for creating
and re-creating a test environment.

I'm not a big fan of using batch queues for job scheduling, either.
Those tend to get tangled, which means incrementally creating a
feature-deprived job scheduler on a foundation ill-suited for the goal.
But you're already invested in this approach, so that's unlikely to
change.

--
Pure Personal Opinion | HoffmanLabs LLC