Copying or Moving the VFS

You copy a VFS by copying all of the VFS0* files in the VFS subvol to a new subvol. The preferred way to do this is by using the PAK and UNPAK utilities (or similarly BACKUP and RESTORE) since they automatically update alternate key file references. A move is a copy to a new location, followed by a delete of the original.

Before attempting to copy the VFS, make sure its files are not open.

TEXT

tacl> fup listopens $DATA.MYVFS.VFS0*

Copy the VFS files in subvol $DATA.MYVFS to $DATA.MYNEWVFS.

TEXT

tacl> pak myvfspak, $DATA.MYVFS.VFS0*, audited, listall
tacl> unpak myvfspak, $*.*.*, audited, listall, map names ($DATA.MYVFS.* to $DATA.MYNEWVFS.*)

Alternatively, you can use FUP DUP to copy the files, but you must manually update the alternate key file references.

CODE

tacl> volume $data.mynewvfs
tacl> fup
- dup $data.myvfs.vfs0*, *, saveall
- alter vfs00, altfile (0, vfs000), audit
- alter vfs000, audit
- alter vfs01, audit
- alter vfs02, audit
- alter vfs03, altfile (0, vfs030), audit
- alter vfs030, audit
- alter vfs04, audit
- alter vfs05, altfile (0, vfs050), audit
- alter vfs050, audit
- exit

Specify the new location of the VFS using the -vfs command line argument when starting the SOAPam process. Once you have verified that you have successfully copied the VFS to its new location, you may delete the original if desired.

If you are copying to another NonStop system, note that the VFS contains your server certificate (if installed) which is contains information specific to the host name used to access SOAPam Server. You may need to obtain a new server certificate for your additional system.

If the copy procedure is to be repeated periodically (as you migrate your service definitions from a development VFS to a production VFS, for example), consider using the VFSMGR utility's export/import features to copy that content, leaving server certificate and other settings intact.