|
This is part two of the series that began with
What is System-Managed Storage?
What is Device Independence?
For data set allocations, device independence is the characteristic that allows an allocation to behave consistently regardless of the type of device on which the data set is allocated. For example, a device dependent allocation done in tracks or cylinders would result in a larger actual space allocation on a 3390 than on a 3380.
Why is Device Independence Important?
Suppose you previously had a large number of 3380s, many of which were soon to be replaced by 3390s. If you have programs or allocations which specify a specific unit type, then all programs or allocations which are to use the new devices must be modified. This can be a time-consuming, labor-intensive process, depending on how many programs and how much JCL must be modified.
Of course, it is possible that an esoteric such as SYSDA was used rather than a specific device type. In this case, you can simply add the new devices to the esoteric. However, if users are specifying space allocation in device dependent units such as tracks and cylinders, then they will receive a larger space allocation if their data sets are directed to the new devices. This could result in wasting a substantial amount of space.
Another consideration is user-specified block size. Optimum block size depends on the characteristics of the data set you are allocating and the physical geometry of the device on which it is being allocated. If you have programs or JCL that specify specific block sizes, they may make efficient use of space on one type of device, but waste a substantial amount of space on another.
How Do I Achieve Device Independence?
Much of what you need to do to achieve device independence can be done simply by activating the storage management subsystem (SMS). When you initially activate SMS, it may run with a null configuration, with no data sets on the system under the control of SMS. To do this, issue the following operator command:
SET SMS=xx
The 'xx' refers to an IGDSMSxx member in SYS1.PARMLIB which points to two empty SMS control data sets: an active control data set (ACDS) and a communications data set (COMMDS).
You can achieve further device independence by implementing a minimal SMS configuration. Such a configuration may place no data sets under the control of SMS, or you may choose to begin managing a few data sets. For more information, see the
DFSMSdfp Storage Administration Reference on the
DFSMS/MVS Publications page.
Device Independence with a Null Configuration
As soon as you start SMS, even if no SMS configuration has been established, two functions are available: new space parameters and system determined block size.
Without SMS, you can use the SPACE parameter for allocations such as JCL or dynamic allocation (SVC 99) to allocate data sets in blocks, tracks or cylinders. With SMS, an additional parameter can be used: AVGREC. This parameter allows you to specify SPACE in bytes (U), kilobytes (K), or megabytes (M). Because such allocations specify an
absolute space amount, they are completely device independent and will never need to be changed due to installation of new devices.
System-determined block size is the function which allows the system to determine the optimal block size for your data set. You can request it by specifying BLKSIZE=0 or by leaving BLKSIZE blank when performing allocations via ISPF option 3.2. The system will then determine the block size for the data set, taking into account both the characteristics of the data set (such as record format or logical record length) and the device geometry of the device on which the data set is being allocated.
A data set which uses system-determined block size is considered to be
reblockable. Because of this, a new block size can be determined if DFSMShsm migrates the data set from one device type and restores it to another. A data set can also be reblocked if DFSMSdss is used to move it between devices of different geometries. This can facilitate such functions as space management and recovery without wasting space on volumes.
Device Independence with a Minimal Configuration
When you implement a minimal SMS configuration it must include the base configuration information, at least one storage class, at least one storage group, and a storage group ACS routine. The base configuration information is an SMS construct which applies to the entire SMS complex, rather than to specific data sets. Included in it are a default unit and default device geometry.
In a non-SMS environment, the UNIT parameter is required for nearly all allocations (an exception is VSAM allocations done using IDCAMS). Unless an esoteric is used consistently, this can result in a large number of device dependent allocations. With SMS and a minimal configuration, the UNIT parameter may be removed from
all allocations. If you choose not to make JCL changes, UNIT is ignored for SMS allocations, although it still applies to any non-SMS allocations.
The UNIT parameter is never required for SMS-managed allocations. This is because SMS selects the actual volume(s) for the allocation, and in doing so also selects a unit type. The UNIT parameter is required for non-SMS allocations. However, it may be taken from the default unit in the SMS base configuration information rather than from explicit user specification. This has two benefits:
- It allows most allocations to be done independent of specific unit type (an exception might be an absolute track allocation).
- Users need not know ahead of time whether or not allocations will be SMS-managed. With default unit, the unit may be omitted in either case.
In addition, the default device geometry in the SMS base configuration information may be used when allocating new data sets to convert CYL or TRK requests into KB or MB. You can use the default device geometry to specify the default number of bytes per track and tracks per cylinder. SMS converts all space requests in tracks (TRK) or cylinders (CYL) into requests for space in KB or MB.
If a generic device type such as the 3380 is specified, SMS uses the device geometry for that generic device to convert tracks or cylinders into KB or MB. If an esoteric device type such as SYSDA or no UNIT is specified, SMS uses the default device geometry to convert tracks and cylinders into KB or MB. If the users specify space in tracks or cylinders, and they specify an esoteric UNIT or no UNIT, a default device geometry must be provided
prior to converting these allocations to system-managed data sets.
The advantage to using the default device geometry is that it allows a consistent amount of space to be allocated regardless of device type when an allocation is done in device-dependent units. However, some care must be taken when using it. If the default device geometry you specify does not match the geometry for which the allocation was originally intended, it may result in either more or less space being allocated that was actually required.
In Summary
There are several steps that must be taken to achieve device independence. By activating SMS and utilizing it carefully, these are some of the benefits you can achieve:
- Installation of new devices without requiring JCL changes
- Allocation of a consistent amount of space across varying device types
- Reduction in wasted space due to inefficient block sizes
[
Previous Article |
Next Article |
All Articles ]
| 
