本文发表在 rolia.net 枫下论坛我是主机SP。问问大家怎么管理自己的JCL的，有平时维护用的，也有项目投产时候用到的。现在JCL越来越多了，都不知道去哪里找了。大家多说说
TSO naming conventions ZT from IBM
TSO certainly has a very recognizable data set naming convention. The rules are fairly simple and easy to understand:
Three levels of qualification
userid.dsname.dstype
Standard set of data set types (e.g., CLIST, FORT, PLI, CNTL, etc.)
All of the TSO functions, commands, etc. and also the ISPF/PDF functions tend to complement this naming convention. Therefore, for an ease of use and a transportability issue, it is generally a good idea to maintain this convention.
Some applications run with production-type data under TSO using the standard JCL PROCs, CLISTs, PANELS, etc. that would be used for the normal production data. For example, consider a programming application that had a naming convention of:
library.dstype.project.version.release
where,
library: (PROD, DEVL, or TEST)
dstype: (SOURCE, MACRO, LOAD, OBJ, JCL, etc.)
project: (APPLIC1, APPLIC2, . . .)
version: (V1, V2, . . .)
release: (R1, R2, . . .)
It would certainly be acceptable for unit testing on certain data to be done under a TSO userid such that the userid would be substituted for the "library" and all of the remaining qualifiers would stay the same. The key point here is the usability of the system and the need to manage it differently based on what set of data this actually is.
我现在的构想
1. USERID.LPARID.DSTYPE like IBMSE01.PLEX1.JCL
2. USERID.LPARID.PROJECTID.DSTYPE like IBMSE01.PLEX1.PRO1.JCL
3. XXXXX ???
大家来说说阿~要不JCL越来越多，管理混乱，找起来也不方便更多精彩文章及讨论，请光临枫下论坛 rolia.net
TSO naming conventions ZT from IBM
TSO certainly has a very recognizable data set naming convention. The rules are fairly simple and easy to understand:
Three levels of qualification
userid.dsname.dstype
Standard set of data set types (e.g., CLIST, FORT, PLI, CNTL, etc.)
All of the TSO functions, commands, etc. and also the ISPF/PDF functions tend to complement this naming convention. Therefore, for an ease of use and a transportability issue, it is generally a good idea to maintain this convention.
Some applications run with production-type data under TSO using the standard JCL PROCs, CLISTs, PANELS, etc. that would be used for the normal production data. For example, consider a programming application that had a naming convention of:
library.dstype.project.version.release
where,
library: (PROD, DEVL, or TEST)
dstype: (SOURCE, MACRO, LOAD, OBJ, JCL, etc.)
project: (APPLIC1, APPLIC2, . . .)
version: (V1, V2, . . .)
release: (R1, R2, . . .)
It would certainly be acceptable for unit testing on certain data to be done under a TSO userid such that the userid would be substituted for the "library" and all of the remaining qualifiers would stay the same. The key point here is the usability of the system and the need to manage it differently based on what set of data this actually is.
我现在的构想
1. USERID.LPARID.DSTYPE like IBMSE01.PLEX1.JCL
2. USERID.LPARID.PROJECTID.DSTYPE like IBMSE01.PLEX1.PRO1.JCL
3. XXXXX ???
大家来说说阿~要不JCL越来越多，管理混乱，找起来也不方便更多精彩文章及讨论，请光临枫下论坛 rolia.net