MVSFORUMS.com :: View topic - Dataset names -Best practices

through

[^/[Print]\]

MVSFORUMS.com -> Job Control Language(JCL)

#1: Dataset names -Best practices Author: manu,

Posted: Tue Jan 29, 2019 9:22 am
—
Hello,

I am looking to get inputs on dataset name best practices .There is a limit of 44.In my organization,we need to have different qualifiers in production and test. There are several test environments and that needs to be identified in the DS name too. The first few qualifiers are used for security also.Due to even lesser limit for GDG we had to use different DS names in test vs. production. I would like to get some thoughts/recommendations on the best ways to name a DS with in the limit. Please point out any materials which are already available on this topic. Thank you

Thanks,
Manu

#2: Author: Nic Clouston, Location: At Home

Posted: Tue Jan 29, 2019 11:33 am
—
It is not what is "best practice" - whatever that is as it can vary from organisation to organisation - but what are the defined standards within your organisation.

#3: Author: kolusu, Location: San Jose

Posted: Tue Jan 29, 2019 11:53 am
—
manu,

You may want to look up this White Paper, System Z Dataset Naming Standards

#4: Author: misi01, Location: Stockholm, Sweden

Posted: Wed Jan 30, 2019 4:08 am
—
I've seen 2 types of naming standards. At Svenska Handelsbanken, the standard there was that any CREATED files were called

Quote:

creating_system.(environ).receiving_system.program_creator

This meant, for example, that if system AAAA creates a file that system BBBB will be using as input, and the program creating the file is CCCC, then the resulting file would be called

Quote:

AAAA.(environ).BBBB.CCCC01/02/03 etc etc

Environ contained nothing if the file was created in production, otherwise it contained a test level identifier (FT, ST, PT etc).

Where I'm working now (and the previous contract), they use a different logic where the naming standard is

Quote:

environ.system_id.job_name.filename.stepname

where job_name are the last 4 positions of the job that creates the file, filename seems to be some sort of "random" naming convention, and stepname is the unique step name in the actual job.

I think the biggest difference between the first and the second is that the first convention was based on the fact (amongst other things) that all filenames and DDnames were defined in a repository. In the latter examples, the installations had no repository installed.

Presonally, I think the former standard is "better" and easier to understand (amongst other things because you could query where a DD-name was used and have access to ALL the jobs using it, be it for input or output.

#5: Author: manu,

Posted: Wed Jan 30, 2019 3:14 pm
—
Thanks all for you reply.We follow something similar to the second type mentioned by Michael.There are standards for initial few qualifiers but none regarding DS length.
In some situations the production file name is closer to 44 and it exceeds 44 if ID for each test regions has to be inserted in DSN.
So this requires a different test file name and overrides in JCLs etc.I guess it can be avoided by having production files names less than 44,so that ID for different test regions can be included in DSN with JCL symbols.I posted here to get an idea of other similiar issues that folks have encountered due to DSN length limit. Thanks

#6: Author: kolusu, Location: San Jose

Posted: Wed Jan 30, 2019 4:49 pm
—

manu wrote:

Thanks all for you reply.We follow something similar to the second type mentioned by Michael.There are standards for initial few qualifiers but none regarding DS length.
In some situations the production file name is closer to 44 and it exceeds 44 if ID for each test regions has to be inserted in DSN.
So this requires a different test file name and overrides in JCLs etc.I guess it can be avoided by having production files names less than 44,so that ID for different test regions can be included in DSN with JCL symbols.I posted here to get an idea of other similiar issues that folks have encountered due to DSN length limit. Thanks

Manu,

You do realize that you have PDS's that can have 44+8 byte as the length of the name? You can also have PDS as a GDG too.

#7: Author: manu,

Posted: Wed Jan 30, 2019 5:50 pm
—
ok. Thanks for the info. I think mostly PS datasets are used to hold business data in our org and not looking to change it.

#8: Author: expat, Location: Welsh Wales

Posted: Thu Jan 31, 2019 2:11 am
—
I have always used a three byte application id along with a one byte environment id.

e.g. AAAD.dataset_name belongs to the AAA application in the Development environment, where AAAU is the same application in the UAT environment, and I'll let you all guess at AAAP Shocked

I did write some REXX that basically moved JCL code between environments and made subtle changes as it progressed from Dev to Prd, things like backup datasets were written to DASD in Dev and immediately archived via HSM, but in Prd the backups were on tape.

So easy to do once you have decided on what's what

#9: Author: t-bonham@scc.net, Location: Minneapolis, MN

Posted: Fri Feb 01, 2019 12:44 pm
—

manu wrote:

In some situations the production file name is closer to 44 and it exceeds 44 if ID for each test regions has to be inserted in DSN.
So this requires a different test file name and overrides in JCLs etc.I guess it can be avoided by having production files names less than 44,so that ID for different test regions can be included in DSN with JCL symbols.I posted here to get an idea of other similiar issues that folks have encountered due to DSN length limit.

The problem here seems to be poor design of the DS naming standards -- that you have to insert a test identifier in the name.

Most shops have a part of the name that is always included, and identifies either Production or Test usage. Thus you only have to replace the prod part of the name with the appropriate test region name. That's much easier to do, and safer -- you can easily have automatic security warnings if a test user tries to access a production dataset.

MVSFORUMS.com -> Job Control Language(JCL)

output generated using printer-friendly topic mod. All times are GMT - 5 Hours

Page 1 of 1