Moving an Account |
|
|
Moving an account within the same QM environment usually requires nothing more than copying the entire account directory, changing the pathname in the QM.ACCOUNTS file and modifying any VOC records that reference the account pathname such as those describing locally catalogued subroutines for which the FULL.PATH option of the CATALOGUE command was used.
Moving an account to a different server is more complex and requires the steps below.
Note: It is essential that there are no QM sessions accessing a file while it is moved using an operating system level command. Failure to observe this rule may result in file corruption.
Linux to Linux or Windows to Windows
1.Copy the entire account directory to the new server, preferably using the same pathname as the original system. 2.Ensure that the new account location is referenced from the QM.ACCOUNTS file. 3.If the account pathname has changed, any reference to the old pathname in the VOC file must be changed. 4.Identify any files outside of the account directory that are used by the application and copy these, again preserving or modifying the pathname. 5.If the application uses globally catalogued subroutines, these must be recatalogued on the new system. If all application accounts are being moved, the easiest way to do this is to copy the global catalogue directory (the gcat subdirectory of the QMSYS account) from the original system to a temporary location on the new system and then use the *IMPGCAT tool to import the items that are not part of QM itself. 6.Ensure that any external software used by the application is available on the new system.
Windows to Linux
There are two additional problems when moving from Windows to Linux. •Operating system pathnames are case insensitive in Windows but case sensitive in Linux. •Directory files use a carriage return / linefeed pair as the newline in Windows and just a linefeed in Linux. The COPY command has a TEXT or BINARY option that may be useful.
The case sensitivity issue applies to all operating system files and directories within the account, including record ids in directory files though movement of these may be helped by use of the TO.UPPERCASE or TO.LOWERCASE options of the COPY command. It can only be resolved by examination of the application to ensure that casing is as expected.
The line terminator issue can be resolved by use of the *FIXDIR tool but it is essential that this is not applied to directories that hold binary data such as QMBasic object code.
Linux to Windows
The same two additional issues apply as for Windows to Linux but the case sensitivity issue is less of a problem moving in this direction. It is important to note that on a Lunix system, a directory file could have two records named, for example, "A" and "a" but on a Windows system these are both the same record and one will overwrite the other.
Copying Items from the QMSYS Account Directory
It is strongly recommended that users do not copy the QMSYS account in its entirety because this may result in system errors, especially if the two systems are running different releases of QM. Instead, selective copying/editing should be used.
Copying an Entire System to a New Server
As an alternative to the steps described above, moving an entire system to a new server of the same type (Windows/Linux/etc) can be done as follows:
Install QM on the new system. This will require a change to the licence and it may be useful to visit www.openqm.com/emergency.htm to generate a seven day "emergency licence" which will be replaced by a new permanent licence later.
1.Shutdown QM on both the old and new servers.
2.Use an operating system tool to copy all account directories, including QMSYS to the new server, using the same pathnames as on the old server.
3.Reinstall QM on the new server so that any standard parts of QM such as globally catalogued programs that were copied from the old server are replaced with the correct versions for the release of QM being used on the new server. If the old system uses encryption, the installer will request entry of the master key.
4.If the old server was a replication subscriber, the RPLSRVR configuration parameter may need updating.
|