×

Loading...
Ad by
  • 最优利率和cashback可以申请特批,好信用好收入offer更好。请点链接扫码加微信咨询,Scotiabank -- Nick Zhang 6478812600。
Ad by
  • 最优利率和cashback可以申请特批,好信用好收入offer更好。请点链接扫码加微信咨询,Scotiabank -- Nick Zhang 6478812600。

请教Mainframe达人

本文发表在 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
Report

Replies, comments and Discussions:

  • 工作学习 / 专业技术讨论 / 请教Mainframe达人
    本文发表在 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
    • On call 时回你个贴,供参考. 你的构思是对的. 有个有意义的库名很便于管理. 就象在Windows 里开有意义的目录一样. 最好在每个JCL 里的开头加上Comments这样便于维护,也方便交接.
      • 呵呵,谢谢回帖,请问谁能找到相对全一点的系统维护用到的作业SAMPLE