View previous topic :: View next topic |
Author |
Message |
manu Beginner
Joined: 26 Dec 2002 Posts: 47 Topics: 19
|
Posted: Tue Jan 29, 2019 9:22 am Post subject: Dataset names -Best practices |
|
|
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 |
|
Back to top |
|
|
Nic Clouston Advanced
Joined: 01 Feb 2007 Posts: 1075 Topics: 7 Location: At Home
|
Posted: Tue Jan 29, 2019 11:33 am Post subject: |
|
|
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. _________________ Utility and Program control cards are NOT, repeat NOT, JCL. |
|
Back to top |
|
|
kolusu Site Admin
Joined: 26 Nov 2002 Posts: 12368 Topics: 75 Location: San Jose
|
|
Back to top |
|
|
misi01 Advanced
Joined: 02 Dec 2002 Posts: 620 Topics: 173 Location: Stockholm, Sweden
|
Posted: Wed Jan 30, 2019 4:08 am Post subject: |
|
|
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. _________________ Michael |
|
Back to top |
|
|
manu Beginner
Joined: 26 Dec 2002 Posts: 47 Topics: 19
|
Posted: Wed Jan 30, 2019 3:14 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
kolusu Site Admin
Joined: 26 Nov 2002 Posts: 12368 Topics: 75 Location: San Jose
|
Posted: Wed Jan 30, 2019 4:49 pm Post subject: |
|
|
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. _________________ Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
www.linkedin.com/in/kolusu |
|
Back to top |
|
|
manu Beginner
Joined: 26 Dec 2002 Posts: 47 Topics: 19
|
Posted: Wed Jan 30, 2019 5:50 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
expat Intermediate
Joined: 01 Mar 2007 Posts: 475 Topics: 9 Location: Welsh Wales
|
Posted: Thu Jan 31, 2019 2:11 am Post subject: |
|
|
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
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 _________________ If it's true that we are here to help others,
then what exactly are the others here for ? |
|
Back to top |
|
|
t-bonham@scc.net Supermod
Joined: 18 Oct 2012 Posts: 30 Topics: 0 Location: Minneapolis, MN
|
Posted: Fri Feb 01, 2019 12:44 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
|
|