Page 1 of 1
UNIT parameter in JCL.
Posted: Fri Apr 09, 2021 11:49 am
by 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.
Re: UNIT parameter in JCL.
Posted: Wed Apr 28, 2021 2:00 pm
by 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.
Re: UNIT parameter in JCL.
Posted: Thu Apr 29, 2021 1:11 pm
by sumit_kaur
Thanks Anuj.
What is SMS in your reply?
Re: UNIT parameter in JCL.
Posted: Fri Apr 30, 2021 2:17 pm
by Ashish Pawar
But if we still give a UNIT=DASD in the JCL, what's wrong will it do?
Re: UNIT parameter in JCL.
Posted: Sun May 02, 2021 7:29 pm
by 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.
Re: UNIT parameter in JCL.
Posted: Sun May 02, 2021 7:40 pm
by sumit_kaur
Robert Sample wrote: ↑Sun May 02, 2021 7:29 pmDepending 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?
Re: UNIT parameter in JCL.
Posted: Fri Jun 11, 2021 7:16 pm
by Rohit Jain
Robert Sample wrote: ↑Sun May 02, 2021 7:29 pmDepending 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?
Re: UNIT parameter in JCL.
Posted: Sun Jun 20, 2021 6:08 pm
by Anuj Dhawan
If you look at the description about "UNIT parameter" in z/OS MVS JCL Reference SA23-1385-00", you'll find this:
z/OS MVS JCL Reference SA23-1385-00 wrote:
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.
Re: UNIT parameter in JCL.
Posted: Tue Aug 03, 2021 12:22 am
by 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?
Re: UNIT parameter in JCL.
Posted: Tue Aug 03, 2021 5:31 am
by 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.
Re: UNIT parameter in JCL.
Posted: Wed Aug 18, 2021 5:32 pm
by Rohit Jain
Robert Sample wrote: ↑Tue Aug 03, 2021 5:31 am
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.