Upgrade Accelerator

There are two types of updates for Accelerator, patches and new versions. Patches replace specific files in an installation and save an archive of the changed files so you can revert. A new release is a complete set of files, usually installed in a directory that is a sibling of your current version.

The simplest method to change to a different server is to use the following steps (shutdown and restart on new version):

Install new software
Notify users that Accelerator will be shutdown
At an idle time, shut down the Accelerator server with ncmgr stop
Change startup files (.vovrc) to refer to the new software installation
Start the server, running the new version, with ncmgr start
Notify users that Accelerator is available again

In some cases, for example, it may be impractical to shut down the Accelerator server for even a short time:

you have a very busy installation, and Accelerator is never idle
you have jobs running and you do not want to lose them
you want to keep the order of jobs in the queue. In such cases you can use one of the following methods.
1. Switch vovserver and vovtaskers separately, using ncmgr stop -freeze.
2. Start a new Accelerator queue on new version, sending new jobs to it, shutting down the current Accelerator queue after all jobs have been retired.

Here are the steps for the ncmgr stop -freeze method.

From a shell with your current Altair Accelerator version, stop vovserver with ncmgr stop -freeze. This instructs vovtaskers with jobs to wait for a new vovserver and reconnect to it.
vovtaskers with no jobs should exit right away, and ones with jobs will enter the SUSP state. Their names will change to indicate they are stopping (and to permit new vovtaskers to start with the regular names).
From a shell with the new Altair Accelerator version, start the vovserver using ncmgr start.
Check on the browser UI Admin page that vovserver is running the expected version.

Here are the steps for the overlapping queues method.

Create a new queue, running the new server software
Direct nc run to send new jobs to the new queue
After some time, all jobs in the old queue have completed
The old queue may be now be shut down

Overlapping Queues

Please read these steps to the end and understand them before doing the procedure. This procedure is preliminary, and may need to be adapted to your Accelerator configuration.

Install and verify the new software version. The vovcheck command may be helpful.
Start a new queue, for example with name vnc2.
```
% ncmgr start -queue vnc2
```
Copy configuration files (policy.tcl, resources.tcl, taskers.tcl etc.) from the configuration directory of the old queue to that of the new queue in such a way that the two queues are functionally the same.
Get the new queue ready.
```
% ncmgr reset -queue vnc2 -full
```
In the setup.tcl file of the new queue, set the environment variables NC_OLDQUEUE and NC_OLDVERSION to point to the old queue.
```
# This is a fragment of the setup.tcl file for the new queue
# USE THESE FOR MIGRATION FROM AN OLD QUEUE.
setenv NC_OLDQUEUE	
vnc setenv NC_OLDVERSION 5.4.7
```
Note: This goes in the setup.tcl file so that these environment variables will always be set in the context of vnc2.
Test the new queue. By setting the environment variable NC_QUEUE to vnc2,the Accelerator commands will use that as the default queue.
```
% setenv NC_QUEUE "vnc2"
% nc run sleep 10
% nc list
% nc mon
```
Note: You may use the -queue option as an alternative to setting NC_QUEUE. For example, you might use
```
% nc -queue vnc list -a     # Show all jobs in old queue.
% nc -queue vnc2 run sleep 10       # Submit a sleep job to new queue.
% nc -queue vnc2 list               # Show your jobs (only) in new queue.
```
Once you are satisfied that the second queue is ready, make it the default queue. The default queue is always namedvnc, and is where the newly-submitted jobs will be placed.
```
% cd $VOVDIR/local/vncConfig
% mv vnc.tcl vnc1.tcl; ln -s vnc2.tcl vnc.tcl
```
Note: In the example above, vnc.tcl is moved to vnc1.tcl to preserve its contents, in case you want to reactivate the original queue. The two commands are on the same line, separated by a semicolon, so that the file vnc.tcl will be unavailable for the shortest possible time. Check carefully!
Now all the newly-submitted jobs will go to vnc2, while commands such as nc info, nc stop, nc forget, etc. will be run on both queues.
Error messages are filtered out, because a job ID which is valid in the first queue will not be valid in the second, and conversely. To see the results with messages, query the queues separately by using the -queue option of Accelerator commands.
When all jobs in the old queue have been retired, you can shut down the old queue.