This section describes two operating environments on VSE from which you can migrate a database:
When you move the database from VSE, you can move it to one of these operating systems:
If you do not have a database on VM, you can migrate your database from a VSE to a VM operating system by archiving the database on VSE, generating a new database on VM, and then restoring the archived database on VM. For more information, see Moving a Database.
If you already have a database on VM, you can move the data in your VSE database to the VM database using the UNLOAD and RELOAD commands. For more information on the UNLOAD and RELOAD commands, see the DB2 Server for VSE & VM Database Services Utility manual. If you move the data this way, you have to unload and reload all dbspaces and packages. When the database is on VM, you must recreate all views and indexes, and reestablish the authorities and privileges each user has with GRANT and REVOKE commands for the tables moved from VSE. This is similar to regenerating a database. For more information, see Preparing for Database Regeneration.
When migrating from a prior release, you may want to update the SNA NETID file. For information on this task, see Updating the SNA NETID File.
Before attempting to move a database from a VSE to a VM operating system, you should understand the database manager on VM as well as on VSE. You must know how to define and generate a database on VM before you can move a VSE database to VM.
In a DB2 Server for VM database, you can choose a VM resource identifier (resid) in addition to the server name. The resid identifies the application server to VM.
For more information on this, see Choosing an Application Server Name and VM Resource Identifier.
There is no need to convert the data in a database when you move the database from a VSE to a VM operating system; the data is system-independent. You must have the same release level of the database manager installed on both operating systems, otherwise the database manager at the lower release level must be migrated first. Once both databases are using the same release level, archive the database on VSE and restore it on VM.
Although the database manager itself does not require you to convert user-created packages when you move from VSE to VM, any program that is moved will have to be compiled and linked again in the VM environment. If you have revised any programs, you should repreprocess these programs. Remember to use the preprocessor KEEP option to retain existing authorizations on the program.
Views are stored as packages. These packages do not need to be recreated.
The VSE programs moved to the VM operating system must be recompiled and linked in the VM operating system. Some of the programs can be run in a CMS/DOS environment without modification. The CMS/DOS environment does not support all VSE macros and functions; some programs must be recoded. Programs that do not need to be recoded still have to be preprocessed, compiled, and link-edited in the VM environment.
The CICS/VSE programs cannot be converted to the CMS environment; they must be rewritten to be used in CMS.
You might choose to move some VSE databases to VM. In such cases, you can run the database on VM, with VSE running as a guest under VM. Users and applications in VSE can also access databases on VM through VSE guest sharing. For more information on guest sharing, see VSE Guest Sharing Configuration.
If you have databases on VSE, use the DB2 Server for VSE manuals. See the DB2 Server for VSE & VM Master Index and Glossary manual for a list of these manuals.