From the Boeblingen HCD Team
HCD News -- HCD News -- HCD News -- HCD News -- HCD News
Migration to HCD
Your Feedback Is Important to Us
With the availability of MVS/ESA 5.1 and the number of installations migrating to this MVS version, the migration from IOCP/MVSCP to Hardware Configuration Definition (TM) (HCD) becomes very important, especially since MVSCP support is no longer available with MVS/ESA 5.1 and MVS/ESA 5.1 requires an IODF to IPL.
Even though a one time migration to HCD is the preferred way of dealing with this, a migration to create an IODF can be performed every time the configuration is changed, as long as new hardware does not require a complete switch to HCD e.g. IBM 3495 Tape Library. HCD 5.1 introduced the partial migration function which allows you to update existing processor or operating system definitions in the IODF via IOCP or MVSCP statements. For details refer to the HCD: User's Guide.
In HCD 5.1, which is also available to MVS/SP 4.3 users as the 'HCD Usability Feature', additional migration enhancements have been provided.
In the following please find some hints and tips for migrating your existing IOCP/MVSCP definitions into the IODF format.
The HCD Migration function takes IOCP/MVSCP input and creates or updates an IODF. During this process, HCD validates the input. Any violation of device specification or connectivity rules as well as syntactical errors within the control statements will prevent building of an IODF. Through messages which are shown as result of the migration step, HCD will provide information which can be used to correct the IOCP/MVSCP input. When all corrections are done, in a new migration step, HCD will now create or update the IODF.
Q: Where do I find validation information?
A: All findings will be saved in two data sets. Syntax errors will be stored in a data set of type 'LISTING', all other findings in a data set of type 'MESSAGES'. For both data sets the following naming conventions apply: 'user-id.name of input data set.type'. The data sets are automatically created during the migration step. Existing data sets of the same name are replaced. The data sets can be preallocated, using as DD name HCDASMP (LISTING) and HCDPRINT (MESSAGES) e.g. to get different names or different space allocations.
Q: Can I migrate a data set containing IOCP as well as MVSCP statements ( a combined IOCP/MVSCP data set ) ?
A: Yes, this can be done.
Doing this, two cases have to be distinguished
- processor running in BASIC mode
- processor running in LPAR mode
In the first case the information in the combined data set will be converted in one step and the resulting IODF contains the corresponding CSS and operating system information.
In the second case different approaches have to be taken depending on the information contained in the combined input data set.
Note that on the HCD migration panel, the data set name has to be specified as a combined data set. Both a processor-id and an operating system configuration-id have to be specified to receive the IOCP/MVSCP related definitions respectively.
If 2 ( or more ) IODEVICE statements refer to the same device number, the migration has to be performed in 2 steps: First the combined data set has to be migrated to a processor-id as an IOCP only data set (MVSCP parts are ignored). Then the duplicate device numbers have to be removed and now the data set can be migrated to an operating system configuration-id as an MVSCP only data set.
Q: Can I migrate multiple IOCP and MVSCP data sets, that is multiple processor and operating system definitions into one IODF ?
A: Yes, this can be done.
The recommendation is to migrate one after the other, the IOCP data sets first and then the MVSCP data sets.
Device considerations: An IOCP may contain duplicate device numbers when defining an LPAR configuration. In that case, more than one device with the same device number is defined in the IODF. A conflict may occur if an MVSCP input data set is migrated with the same device number and HCD has now the choice to associate this device definition to one of the existing definitions.
HCD uses the CU numbers as criteria to decide how to relate a device number to multiple existing devices in the IODF, having that same device number.
Starting with HCD 5.1, this HCD internal default handling can be overruled by specifying an associated processor (and partition for an LPAR processor) when migrating the MVSCP input data set. Then HCD regards a device from that processor (partition) configuration as the very same device when device number and device type match, even if the CU numbers are different.
CU considerations: If the same CU number is specified in more than one IOCP input data set, HCD assumes this to be a single physical CU because in an IODF CU numbers must be unique. To ensure successful migration of the additional IOCP input data sets CU type as well as device number and type of attached devices must match.
LPAR considerations: Prior to HCD 5.1 the migration function assumed that the IOCP data set contains complete processor configurations. If this is not the case, e.g. there exists one data set per LPAR, these data sets had to be merged prior to migrating to HCD.
With HCD 5.1 a partial migration facility is available, allowing to migrate e.g. single LPAR definitions into the same processor configuration.
Q: Can I have Assembler statements in my IOCP/MVSCP input data sets?
A: The HCD migration function invokes the Assembler program to parse the IOCP and MVSCP control statements. This allows the usage of conditional assembler statements to select the I/O configuration definitions to be migrated if the input data set contains the definition of multiple processor and/or operating system configurations.
Q: Why doesn't HCD accept all control unit or device types coded in the IOCP?
A: HCD does a more rigorous validation than the IOCP program e.g. the UNIT parameter of the CNTLUNIT and IODEVICE statements. HCD validates this parameter against the device configuration rules defined in the Unit Information Modules (UIMs). The set of UIMs installed determines the device support of HCD. This information can be obtained via the 'Query' function in the dialog or by printing a new report 'Print Supported Hardware' (available via PTFs UW90104, UW90105).
IBM provides the UIMs for IBM devices, these UIMs are shipped together with the device support code ( e.g DFP for DASD devices ). In most cases, your MVS system should contain the UIMs for IBM supplied devices.
In case of non-IBM devices, the following actions should be taken:
- if a UIM for the CU or device type exists it should be installed
- ask the vendor for the UIM
- if the characteristics of the CU or device type match those of another supported, do one of the following:
- specify those in the IOCP
- use device type 'DUMMY' for an unsupported device type, the corresponding CU type is also called 'DUMMY'
- use a control unit type of 'NOCHECK' if the CU type is not known
- Write the UIM on your own (a sample UIM 'CBDSUIM' is provided in SYS1.SAMPLIB which can be used to write a UIM).
Q: Why doesn't HCD accept the processor definition in the IOCP even though the correct processor type is defined?
A: This situation can occur during batch migration, if the processor is an EMIF capable processor. Most EMIF capable processors are supported via more than one support level. HCD needs to know the correct support level, which can be passed onto HCD via parameter string. The correct support levels can be found through the HCD dialog via 'Query installed processors' or by printing the 'Supported Hardware' Report.
When working with the HCD dialog, HCD prompts the user to select the relevant processor support level when defining the processor.
Q: Why are migrated devices not enabled for dynamic reconfiguration, even though the device supports dynamic?
A: If the DYNAMIC parameter is not specified in an MVSCP input data set the default when migrating is DYNAMIC=NO. Since some products do not support dynamic reconfiguration, a conscious decision should be made. Either change the MVSCP input data set specifying DYNAMIC=YES or use the HCD dialog after migration.
Q: When migrating the IOCP/MVSCP to HCD while migrating from MVS/SP 4.x to MVS/SP 5.x, under which HCD should I do the migration?
A: If ever possible the migration should be done under HCD 5.x. If migrating from MVS/SP 4.3 the HCD Usability Feature should be installed. This contains the functionality of HCD 5.1 with the following migration advantages:
- if the same CU number is contained in several IOCPs, fewer conflicts occur
- if the same device numbers are contained in several configurations fewer conflicts occur
With HCD 5.1 during migration it is also possible to specify associated processor/partition for MVSCP migration, which can be used for conflict resolution if duplicate device numbers exist.
- incremental update of the configuration
Parts of a configuration can be migrated into non-empty processor / operating system configurations in the IODF ("partial migration").
- accepting duplicate labels (duplicate labels in the input data sets are ignored).
- mapping of CU types.
With HCD 5.1 a predefined mapping between CU type in the input data set and CU type as known to HCD can be set up in the HCD profile.
HCD 5.1 can also be installed for migration purposes on MVS/SP 4.2.
Q: Should I have one or multiple IODFs?
A: It is recommended to have the configurations for all processors that share the same equipment in one IODF. This guarantees consistency of the definitions, since the definitions for shared equipment have only to be entered once. It simplifies systems management and reduces the possibility of errors. In addition, the graphical display function will give a better overview over your configurations as the scope of the graphical reports is limited to one IODF.
Q: Should I have one or multiple Operating Systems definitions, one for each LPAR?
A: Here one should distinguish between the two situations:
- the definitions for the OSs in the LPARs are symmetric
In this case only one OS should be defined. This has the advantage, that the information has to be entered once only and is always in synch.
- the definitions for the OSs are different
In this case multiple definitions should be done.
If you like the idea of the 'HCD Newsletters', or if you don't like it, or if you have suggestions for topics you want to hear about
please call (49-7031-164237)
or fax (49-7031-164240)
or send a note to IBMMAIL(DEIBMHCD)
or on INTERNET: HCDHOT@BOEVM3.VNET.IBM.COM.
© IBM Corp. 1995
HCD / HCM home page