UNIT parameter in JCL.

[sumit_kaur]

Hi,

Recently in our company they have started rejecting the JCL or PROCs which have UNIT parameter coded. The argument is that per the new 'mainframe standards' UNIT parameter is no longer required. My question is how would they control harm done by existing UNIT parameter which is in use by existing JCL and PROC? How it is handled? Please someone explain it to me, if you know.

[Anuj Dhawan]

For a site managed by SMS, UNIT parameter is not required for DASD devices allocation. I doubt that it's a generalized statement like you make it sound per your question. As the DSNs which need to get allocated on TAPEs would still require UNIT.

[sumit_kaur]

Thanks Anuj.

What is SMS in your reply?

[Ashish Pawar]

But if we still give a UNIT=DASD in the JCL, what's wrong will it do?

[Robert Sample]

From the JCL Reference manual for z/OS 2.1:

Note: With SMS, you do not need to use the UNIT parameter to specify a device for an SMS-managed data set. Use the STORCLAS parameter (described in ) or let an installation-written automatic class selection (ACS) routine select a storage class for the data set.

Also with SMS, for a non-SMS-managed data set, if your storage administrator has set a system default unit under SMS, you do not need to specify UNIT. Check with your storage administrator.

Depending on how your site is set up, using UNIT=DASD may be ignored -- or it may cause the allocation to use the wrong storage pool, causing various problems. SMS is System Managed Storage. The ACS routine can allocate a dataset to a volume based upon different levels of the dataset name, or the requested space, or the organization of the dataset, and so forth.

[sumit_kaur]

Depending on how your site is set up, using UNIT=DASD may be ignored -- or it may cause the allocation to use the wrong storage pool, causing various problems.

Thank you Robert.

This is what I want to know, what type of problems can it cause? Could you please guide?

[Rohit Jain]

Depending on how your site is set up, using UNIT=DASD may be ignored -- or it may cause the allocation to use the wrong storage pool, causing various problems. SMS is System Managed Storage. The ACS routine can allocate a dataset to a volume based upon different levels of the dataset name, or the requested space, or the organization of the dataset, and so forth.

I also have a question onthis. If the UNIT parameter can be ignored then why coding it can be a problem? Is it because that UNIT parameter coded on step is given preference?

[Anuj Dhawan]

If you look at the description about "UNIT parameter" in z/OS MVS JCL Reference SA23-1385-00", you'll find this:

Note: With SMS, you do not need to use the UNIT parameter to specify a device for an SMS-managed data set. Use the STORCLAS parameter (described in ) or let an installation-written automatic class selection (ACS) routine select a storage class for the data set.

Also with SMS, for a non-SMS-managed data set, if your storage administrator has set a system default unit under SMS, you do not need to specify UNIT. Check with your storage administrator.

Purpose: Use the UNIT parameter to ask the system to place the data set on:

• A specific device.
• A certain type or group of devices.
• The same device as another data set.

The UNIT parameter can also tell the system how many devices to assign and request that the system defer mounting the volume until the data set is opened.

So if one's intention is to use a default device for a given dataset - let the system decide about it. When you code UNIT at step level, system will owner it and if it's not per storage rules, you'll have a lot of data on devices you don't want them to be on. It'll disturb your overall strategy about storage. If you are part of storage tiering at enterprise level, it can create more damage than cure to your storage-policies.

In simple words, let the system decide the 'unit' of storage, provided your shop is SMS managed. And one can safely assume that nearly all the shops are SMS managed now a days.

[Ashish Pawar]

Thanks for the explanation Anuj.

But then how come these many JCLs have ended all with the UNIT parameters at so many places? How do different companies handle it? And why were they coded with UNIT, at first place?

[Robert Sample]

And why were they coded with UNIT, at first place?

JCL was available with the System 360, announced in April 1964. The UNIT parameter was used to specify the precise device (or group of devices) for an allocation of a data set. SMS was announced in early 1988 -- 24 years later -- so there was a LOT of JCL written using the UNIT parameter. IBM strongly supports backwards compatibility so they're not going to get rid of the UNIT parameter of JCL until something is changed that requires it to go away. Some sites have thousands (or tens of thousands) of job streams that they execute, almost all of which were originally coded with the UNIT parameter. While many companies will remove the UNIT parameter as they're doing maintenance on their job streams, they really have no reason to have a project to clean up the UNIT parameter since that would be an expensive project with no real benefits (the JCL will execute the same with or without the parameter), so why not leave them in the JCL? And many job streams can run for years without changes so removing the UNIT parameter as part of other changes being made will typically require many years to change every job stream.

[Rohit Jain]

And why were they coded with UNIT, at first place?

JCL was available with the System 360, announced in April 1964. The UNIT parameter was used to specify the precise device (or group of devices) for an allocation of a data set. SMS was announced in early 1988 -- 24 years later -- so there was a LOT of JCL written using the UNIT parameter. IBM strongly supports backwards compatibility so they're not going to get rid of the UNIT parameter of JCL until something is changed that requires it to go away. Some sites have thousands (or tens of thousands) of job streams that they execute, almost all of which were originally coded with the UNIT parameter. While many companies will remove the UNIT parameter as they're doing maintenance on their job streams, they really have no reason to have a project to clean up the UNIT parameter since that would be an expensive project with no real benefits (the JCL will execute the same with or without the parameter), so why not leave them in the JCL? And many job streams can run for years without changes so removing the UNIT parameter as part of other changes being made will typically require many years to change every job stream.

This is helpful. Yes, that make sense and I understood Robert. Thanks again.