2 Doing Physical Exports and Imports

The EXPORT and IMPORT facilities give you the tools to create physically portable MVCs. At the source site, you use EXPORT to consolidate VTVs on MVCs (if necessary), and produce a Manifest File that describes the MVC contents (VTVs on the MVC). You then eject the MVCs from the source site, physically transport them to the target site, then IMPORT them, using the Manifest File to update the CDS with information on the imported MVCs and VTVs. Note that you can import VTVs into a CDS without VTCS being active. You then enter the MVCs into the target site.

Note:

If you decide to return exported MVCs back to the source system, no special VTCS processing is required; just enter the MVCs into an LSM at the source system.
For each VTV imported, the only MVC copies that will be created will be for MVCs that have been exported and imported through the same statements. This has a particular significance when importing Duplexed VTVs. Such a VTV will only have copies on both MVCs after the import if both MVCs are present in the same Manifest file and imported as a result of the same IMPORT statement.

You export by either of the following general methods:

Export by VTV or Management class, which consolidates the selected VTVs onto a new set of MVCs. As Consolidation takes time and requires VTSS resources the preferred option is to perform Export by MVC or Storage Class. For more information, see "Exporting and Importing by Management Class."
Export by MVC or Storage Class. An export by storage class or MVC does not require any Consolidation post-processing of VTVs, and there is no data movement required. The export simply creates a Manifest File that describes the contents of the selected MVCs For more information, see "Exporting and Importing by Storage Class."
Note:
If you export by:
- VTV volsers - Use a TMS or VTVRPT report to identify the required VTVs.
- MVCs volsers - Use MVCRPT report to identify the required MVCs.
- Management Class - Review your Management Class definitions to identify the required Management Classes.
- Storage Classes - Review your Storage Class definitions to identify the required Storage Classes.

Exporting and Importing by Management Class

The following examples show MVC export and import by management class.

Note:

When an Export is done by MGMTclas or VTV, the CDS does not maintain the MVC information in the VTV record. The MVC is marked as (E)xport in this case.

Example: Exporting by Management Class from the Source VSM System

This is the "send" phase of export/import, where you get the desired data packaged up and moved out of the source VSM system.

To export from a source VSM system, do the following:

Identify the Management Classes used for export.
Export by Management Class:
```
//EXPORT EXEC PGM=SLUADMIN,PARM='MIXED' REGION=6M
//STEPLIB  DD DSN=hlq.SEALINK,DISP=SHR
//MOVE1    DD DSN=hlq.REMOTE2,DISP=(,CATLG,DELETE), 
//            UNIT=SYSDA,SPACE=(CYL,(1,1),RLSE),
//            DCB=(RECFM=FB,LRECL=80,BLKSIZE=27920)
//SLSPRINT DD SYSOUT=* 
//SLSIN    DD * 
  EXPORT MGMT (PAY,ACCOUNT) MANIFEST(MOVE1)
```
In this example, the output manifest file is MOVE1, which is required for the import. Because you exported by Management Class, EXPORT consolidates (makes copies of) the selected VTVs on export MVCs. The export MVCs are marked as read-only and as exported in the CDS, and are now available for ejection from a source system LSM.These consolidated VTV copies are additional copies and are not recorded in the CDS. For example, if the VTV was duplexed before the export, the CDS records both duplexed copies, but the third additional copy used for consolidation is not recorded in the CDS. The original VTVs, therefore, are still available to the source system. You can use the data on the original VTVs or scratch and reuse them.

Caution:
Schedule the export for a time when the exported data is not being updated!
Remove the MVCs for export from the MVC pool. For more information, see Managing HSC and VTCS.
Eject the MVCs for export from a source VSM system LSM. For more information, see Managing HSC and VTCS.
If desired, at the source system, scratch or make unavailable the exported VTVs or reuse the data they contain.

After the export, the source system retains the CDS records of the exported VTVs and MVCs. The export MVCs are marked as exported and readonly in the source system CDS. At this point, you have two choices, depending on why you exported the VTVs:
- If you exported the VTVs to provide a backup copy at a second site, leave the VTVs as readonly in the source system CDS so they cannot be updated.
- If you are permanently moving the exported VTVs to a second site, then scratch or otherwise make them unavailable in the source system CDS. Use the HSC scratch utilities to scratch exported VTVs.

Example: Importing by Management Class into the Target VSM System

It is a month later, and you are finally ready for the "receive" (import) portion of the export/import operation.

To import into a target VSM system, do the following:

If the VTVs and MVCs you are importing are not in the target system CDS, redo your POOLPARM/VOLPARM definitions to add these volsers as described in Configuring HSC and VTCS.

If necessary, increase the CDS size on the target VSM system. For more information, see Configuring HSC and VTCS or Managing HSC and VTCS.

What if there were duplicate VTV volsers across the source and target systems? In general, do the following:
- If the source system has more current VTVs with the same volsers as those on the target system, specify REPLACE(ALL).
- If you are moving the VTVs from the source to the target system (first time export/import), specify REPLACE(NONE). In this case, you must decide what to do with the duplicate VTVs on a case by case basis.
Enter the MVCs for import into a target VSM system LSM.

For more information, see Managing HSC and VTCS. You want to get the MVCs physically in place before you use IMPORT to tell the CDS that it has some new MVCs and VTVs.
Optionally, do a "validate" run of IMPORT:
```
//IMPORT EXEC PGM=SLUADMIN,PARM='MIXED' REGION=6M 
//STEPLIB  DD DSN=hlq.SEALINK,DISP=SHR
//REMOTE1  DD DSN=hlq.REMOTE1,DISP=SHR 
//SLSPRINT DD SYSOUT=* 
//SLSIN DD *
  IMPORT MANIFEST(MOVE1) NOUPDATE
```
This shows example JCL to run the IMPORT utility where:
- The Manifest File is the export Manifest specified in Step 2.
- REPLACE(NONE) (the default) specifies that VTCS does not overwrite duplicate VTVs.
- IMMDRAIN(NO) (the default) specifies that VTCS does not drain all imported VTVs to VTSS space.
- NOUPDATE specifies that the CDS is not updated (validate run only).
- INACTCDS is not specified, so HSC is active.
Doing a validate run is optional but highly recommended, because you really want to see what is going to happen before you push the button. Study carefully the Import Report. Like what you see? Continue with Step 4.
Note:
- IMPORT is valid only if FEATures VSM(ADVMGMT) is specified.
- Ensure that the "to" CDS has the same features (enabled by CDS level) as the "from" CDS. For example, if the "from" CDS has Large VTV page sizes enabled and 2/4 Gb VTVs have been created, then the "to CDS" must have the same capabilities, otherwise the import fails.
Do an actual run of IMPORT:
```
//IMPORT EXEC PGM=SLUADMIN,PARM='MIXED' REGION=6M
//STEPLIB  DD DSN=hlq.SEALINK,DISP=SHR
//REMOTE1  DD DSN=hlq.REMOTE1,DISP=SHR
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
  IMPORT MANIFEST(MOVE1) REPLACE(ALL)
```
This shows example JCL to run the IMPORT utility where, as in the "validate" run, REPLACE(NONE) (the default) specifies that VTCS does not overwrite duplicate VTVs.

Note:
What if you want to return the MVCs to the source system? If so, you can specify IMMDRAIN(YES) to drain the import MVCs.
Adjust your VTV definitions as needed. For example, you need to define any new VTVs to the target system's TMS.
Do one of the following:
- Optionally, run MVCMAINT to make imported MVCs writable. VTCS imports MVCs as readonly. To make them writable, you run MVCMAINT, specifying READONLY OFF. The chances are that you are going to want to use the new MVCs at the target system, and this is the first step.
  
  Next, add the imported MVCs to the MVC pool as described in Managing HSC and VTCS. At this point, the MVCs can be reclaimed, drained, migrated to, recalled from, and so forth.
- If you specified IMMDRAIN(YES) in Step 4, you can return the MVCs to the source system.

Exporting and Importing by Storage Class

The following examples show export and import by storage class from a source VSM.

Note:

When an Export is done by STORclas or MVC, the CDS maintains the MVC information in the VTV record the CDS. The MVC is marked as (R)ead-Only in this case.

Example: Exporting by Storage Class from the Source VSM System

This is the "send" phase of export/import, where you get the desired data packaged up and moved out of the source VSM system.

To export from a source VSM system, do the following:

Identify the Storage Classes used for export.
Export by Storage Class:
```
//EXPORT EXEC PGM=SLUADMIN,PARM='MIXED' REGION=6M
//STEPLIB  DD DSN=hlq.SEALINK,DISP=SHR
//MOVE2    DD DSN=hlq.REMOTE2,DISP=(,CATLG,DELETE),
//             UNIT=SYSDA,SPACE=(CYL,(1,1),RLSE),
//             DCB=(RECFM=FB,LRECL=80,BLKSIZE=27920)
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
  EXPORT STOR(OFF1,OFF2) MANIFEST(MOVE2) 
```
In this example, the output manifest file is MOVE2, which is required for the import. Because you exported by Storage Class, they system creates a Manifest File but no VTV consolidation occurs. The export MVCs are marked as read-only in the CDS, and are now available for ejection from a source system LSM.The VTVs were resident on the MVCs removed from the LSM can still be used provided they are resident on other MVCs.

Caution:
Schedule the export for a time when the exported data is not being updated!
Remove the MVCs for export from the MVC pool. For more information, see Managing HSC and VTCS.
Eject the MVCs for export from a source VSM system LSM. For more information, see Managing HSC and VTCS.
If desired, at the source system, scratch or make unavailable the exported VTVs or reuse the data they contain.

After the export, the source system retains the CDS records of the exported VTVs and MVCs. The export MVCs are marked as exported and readonly in the source system CDS. At this point, you have two choices, depending on why you exported the VTVs:
- If you exported the VTVs to provide a backup copy at a second site, leave the VTVs as readonly in the source system CDS so they cannot be updated.
- If you are permanently moving the exported VTVs to a second site, then scratch or otherwise make them unavailable in the source system CDS. Use the HSC scratch utilities to scratch exported VTVs.

Example: Importing by Storage Class into the Target VSM System

It is a month later, and you are finally ready for the "receive" (import) portion of the export/import operation.

To import into a target VSM system, do the following:

If the VTVs and MVCs you are importing are not in the target system CDS, redo your POOLPARM/VOLPARM definitions to add these volsers as described in Configuring HSC and VTCS.

If necessary, also increase the CDS size on the target VSM system. For more information, see Configuring HSC and VTCS or Managing HSC and VTCS.

What if there were duplicate VTV volsers across the source and target systems? In general, do the following:
- If the source system has more current VTVs with the same volsers as those on the target system, specify REPLACE(ALL).
- If you are moving the VTVs from the source to the target system (first time export/import), specify REPLACE(NONE). In this case, you must decide what to do with the duplicate VTVs on a case by case basis.
Enter the MVCs for import into a target VSM system LSM.

For more information, see Managing HSC and VTCS. Can you see what is going on here? You actually want to get the MVCs physically in place before you use IMPORT to tell the CDS that it has some new MVCs and VTVs.
Optionally, do a "validate" run of IMPORT.
```
//IMPORT EXEC PGM=SLUADMIN,PARM='MIXED' REGION=6M 
//STEPLIB  DD DSN=hlq.SEALINK,DISP=SHR
//REMOTE1  DD DSN=hlq.REMOTE1,DISP=SHR
//SLSPRINT DD SYSOUT=* 
//SLSIN DD *
  IMPORT MANIFEST(REMOTE1) NOUPDATE
```
This shows example JCL to run the IMPORT utility where:
- The Manifest File is the export Manifest specified in Step 2.
- REPLACE(NONE) (the default) specifies that VTCS does not overwrite duplicate VTVs.
- IMMDRAIN(NO) (the default) specifies that VTCS does not drain all imported VTVs to VTSS space.
- NOUPDATE specifies that the CDS is not updated (validate run only).
- INACTCDS is not specified, so HSC is active.
Doing a validate run optional but highly recommended, because you really want to see what is going to happen before you push the button for real. Study carefully the Import Report. Like what you see? Continue with Step 4.
Note:
- IMPORT is valid only if FEATures VSM(ADVMGMT) is specified.
- Ensure that the "to" CDS has the same features (enabled by CDS level) as the "from" CDS. For example, if the "from" CDS has Large VTV page sizes enabled and 2/4 Gb VTVs have been created, then the "to CDS" must have the same capabilities, otherwise the import fails.
Do an actual run of IMPORT:
```
//IMPORT EXEC PGM=SLUADMIN,PARM='MIXED' REGION=6M
//STEPLIB  DD DSN=hlq.SEALINK,DISP=SHR
//REMOTE1  DD DSN=hlq.REMOTE1,DISP=SHR
//SLSPRINT DD SYSOUT=*
//SLSIN DD * 
  IMPORT MANIFEST(REMOTE1)
```
This shows example JCL to run the IMPORT utility where, as in the "validate" run, REPLACE(NONE) (the default) specifies that VTCS does not overwrite duplicate VTVs.

Note:
What if you want to return the MVCs to the source system? If so, you can specify IMMDRAIN(YES) to drain the import MVCs.
Adjust your VTV definitions as needed.
Do one of the following:
- Optionally, run MVCMAINT to make imported MVCs writable. VTCS imports MVCs as readonly. To make them writable, you run MVCMAINT, specifying READONLY OFF. The chances are that you are going to want to use the new MVCs at the target system, and this is the first step.
  
  Next, add the imported MVCs to the MVC pool as described in Managing HSC and VTCS. At this point, the MVCs can be reclaimed, drained, migrated to, recalled from, and so forth.
- If you specified IMMDRAIN(YES) in Step 4, you can return the MVCs to the source system.