Rules for using z/OS - updated 2016-06-29

This forum provides the support of Dezhi Mainframe systems. Please post your questions about logon, usage of our mainframe environment.

Moderators: sysprog, prino, sfan, steve-myers, Tim001

Rules for using z/OS - updated 2016-06-29

Postby prino » Mon 24 Sep 2012, 10:15

Here's a number of rules you have to stick to when using the FanDeZhi z/OS system. If you decide that you don't want to pay attention to them, you will loose your access to the system.

  1. Do not apply for a userid that starts with 'IBM', 'TSO' (or variations, like 'T50' or 'TS0'), 'USER' or 'RACF', they will not be allowed onto the system! Furthermore, any userid that starts with a letter and is followed by six digits will be revoked as soon as out maintenance jobs detect it!

  2. When you apply for a TSO userid at the "Apply New TSO Userid" page, do not enter the same in the "Your Name" box. We want to see "real names" in a "Firstname Lastname" format, if your name exceeds 20 characters, try to shorten it in a meaningful way, but make sure there is a space between your first- and lastname. Don't try to be funny by using "Tom Cruise", "James Bond", "MF Lover" and the like, doing so is a guarantee to be kicked off. This policy is effective from 2014-08-27, it will not be applied retrospectively to existing users.

    If you violate any of the rules below and we see a
    Code: Select all
    ICH408I USER(OOPSMAN ) GROUP(USERG02 ) NAME(OOPSMAN              )

    the likelihood that you will be banned immediately is about 100%.

  3. First and foremost, do not do anything that causes RACF violations. This includes among others

    • issuing RACF commands
    • accessing data sets of other users, this includes trying to allocate data sets with an HLQ that is not your userid
    • trying to look at output of jobs of other users in SDSF, especially jobs from users BCT188/BCT188A.
    • using DITTO (whether on catalogs or normal datasets)
    • anything that tries to update the master catalog
    The admins do not look kindly on these actions, and it's more than likely that you will be banned.

  4. Any command that interferes with the operation of the system.

  5. Do not share your userid with anyone else. Shared userids are removed from the system without any warning.

  6. FanDeZhi is not to be used for training purposes:

    • if you don't know z/OS, go to a reputable training institute that pays for access to an up-to-date z/OS system, not one that uses the free facilities of FanDeZhi without paying for them!
    • if you're employed, your employer should be using their z/OS system to train you, and not try to save money by offloading you onto FanDeZhi!
  7. No normal programmer would ever write a "Hello, World!" program in any language. If you do, you are abusing the system and will be banned.

  8. If you want to debug your programs, do not use use any commands that write to the Console, such as DISPLAY in PL/I or WTO in Assembler. Use Debug Tool, which is now available on the main ISPF menu. You are of course allowed to write to any self-defined output files, or, if you're using PL/I, to use the various options of the PUT statement.

  9. Do not copy IBM procedures into your own libraries, learn how to use the standard procedures, and how to use JCL overrides to make them work with your data sets.

  10. When you submit a job, check that

    • it isn't looping - if it is taking more than a few minutes, cancel it!
    • it isn't waiting for data sets - if it is, get out of those data sets, do not submit umpteen more copies of the same job
    • that it doesn't produce excessive amounts of output - if it does, cancel it!
    • always purge the output of jobs that ended in a S722 abend!
  11. Always use the 'SUB' or 'SUBMIT' command while in Edit or View. It will take you to SDSF when the system decides that you have too many old jobs in the spool, so that you can purge them.

  12. Delete all your jobs from the spool before you log off!

  13. There are many options on the 'IBM Products Panel' menu reached by the 'M More Additional IBM Products' option on the primary ISPF menu, but just because they are there, do not assume that you can try them "Just to see what they are doing"!

  14. Do not allocate oversized data sets, allocating something with (CYL,(50,50)) (and we have seen even worse) will result in those data sets being deleted without warning. Ditto for VSAM data sets, do not use more space than you need. Also do not allocate multi-volume data sets, they will get the same treatment, i.e. deletion without warning! Do not define GDG's with excessive (> 10) limits, and make sure you create the base with the 'NOEMPTY' and 'SCRATCH' options!

  15. Always make the blocksize of any data set you allocate as close as possible to, but not exceeding to a half-track, i.e. 27998 bytes. For an FB(80) data set this means a BLKSIZE=27920, for any VB data set this means BLKZIZE=27998. We do not want to see any more FB(80) data sets with a BLKSIZE=800! Any FB(80) source data set (COBOL, PL/I, JCL, DBRM, CNTL, PROC, OBJ) that does not have a BLKSIZE=27920 is subject to deletion without warning, and if you persist in allocating such datasets, you will be banned!

  16. Regularly compress your PDS'es ('Z' command in option 3.4) and free unused space ('F' command in option 3.4)

  17. When you display all your datasets using ISPF 3.4, and enter just your userid on the 3.4 panel, you will always see something like this:

    Code: Select all
        Command - Enter "/" to select action             Message      Volume
        --------------------------------------------------------------------
                 ITSME                                                *ALIAS

    Do not attempt to delete this entry. It is required so the system can locate your datasets. Worse, what you are really trying to do (though you probably don't realize it) is to delete the entire catalog where your datasets are cataloged. That won't work; the security arrangements in the system won't allow it, but the admins react to this by preventing your userid from using the system.

  18. Connected to the previous item above, do not use SRCHFOR on DSLIST panel from option 3.4 when your '*ALIAS' is displayed. Put your userid.* on the panel and that will result in the '*ALIAS' not being shown. Issuing SRCHFOR when your own, or for that matter, any other '*ALIAS' entry is shown will cause RACF violations on catalog data sets and as we don't know what caused these when we see them they will be treated as all RACF violations, and you'll be thrown off the system.

  19. Use of COBOL and PL/I

    The catalogued procedures to use COBOL and PL/I can be found in 'SYSFAN.PROCLIB', the procedures are:

    • for PL/I (Enterprise PL/I V3R9)
      Code: Select all
      IBMZC    - Enterprise PL/I  Compile only
      IBMZCB   - Enterprise PL/I  Compile and bind
      IBMZCBG  - Enterprise PL/I  Compile, bind and go
      IBMZCPG  - Enterprise PL/I  Compile, prelink, load and run
      IBMZCPL  - Enterprise PL/I  Compile, prelink and link
      IBMZCPLG - Enterprise PL/I  Compile, prelink, link and run

      The PL/I compiles all use a set of very restrictive compile options, so that about every questionable issue is flagged, the compiler options can be found in 'SYSFAN.PROCLIB(PXEP39Z)'. In the event that you need to override any of these options, and the admins would consider this not just highly likely, but also very undesirable, you can do so by adding the following override to the invocation of the above procedures:

      Code: Select all
      //PLI.PLIUSER DD DSN=&SYSUID..whatever,DISP=SHR

      with &SYSUID..whatever (or &SYSUID.whatever(anymem)) containing the overriding options.

      Note: Enterprise PL/I V4R3 (& V3R7) can be used by using appropriate overrides on the procedures, but Debug Tool will use V3R9.

    • for COBOL (Enterprise COBOL V4R1)
      Code: Select all
      IGYWC    - Enterprise COBOL Compile only
      IGYWCG   - Enterprise COBOL Compile, load and run
      IGYWCL   - Enterprise COBOL Compile and link
      IGYWCLG  - Enterprise COBOL Compile, link and run
      IGYWCPG  - Enterprise COBOL Compile, prelink, load and run
      IGYWCPL  - Enterprise COBOL Compile, prelink and link
      IGYWCPLG - Enterprise COBOL Compile, prelink, link and run

      Use these procedures with appropriate overrides, do not copy them to your own libraries, and do not roll your own, as doing so is a valid reason to get yourself banned!

  20. When you apply for a userid, the system will create the following eight datasets for you:

    • userid.ADCD.ISPCLT1
    • userid.ADCD.ISPCLT2
    • userid.ADCD.ISPLST1
    • userid.ADCD.ISPLST2
    • userid.ADCD.ISPPROF
    • userid.ISPF.ISPPROF
    • userid.ISPTLIB
    • userid.JCL.CNTL
    With the sole exception of the very last, 'userid.JCL.CNTL', these datasets should not be used for anything, and most certainly not for program source, compile procedures and other non-system data. The are only to be used by ISPF, and not by you.

  21. Use of CICS: Effective 2016-01-14, we want to see the following structure in every CICS Program:

    • The userid and name of the person who has written the program
    • A short description of the function of the program
    • The transaction code and CICS group that the program will run in
    The above data needs to be put in a structure with the following format - the PL/I format is given, if you use COBOL you need to use exactly the same layout! A '*' field in PL/I is equivalent to a FILLER in COBOL.

    Code: Select all
    dcl 1 cicsident,
          2 *       char  (8) init ('**CICS**'),
          2 *       char  (8) init ('Userid: '),
          2 userid  char  (8),
          2 *       char  (8) init ('Name:   '),
          2 name    char (20) init ('***Your name as supplied when registering***'),
          2 *       char (12) init ('Description:')
          2 desc    char (80) init ('***A short description of what this on-line program is supposed to do***'),
          2 *       char (12) init ('CICS GROUP: '),
          2 groop   char  (8) init ('***CICS GROUP that this program will be put into***'),
          2 *       char (12) init ('CICS TRAN:  '),
          2 tran    char  (8) init ('***CICS Transaction that will run this program***');


    To prevent the current PL/I (and possible future COBOL) compiler from removing an otherwise unused structure, the userid field needs to be filled in in code!
    Code: Select all
    cicsiden.userid = 'your TSO userid';

    Please note that this rule will be applied retrospectively, the admins are planning to clean out 'SYSFAN.CICS.LOAD' completely in the coming period, and any new load module that does not contain the above information will ruthlessly be deleted.

OK, you've read the rules, now think for a moment if you can abide by them...


If yes, you can apply for a TSO userid, but if there is only the tiniest bit of doubt, we would suggest that you don't, because you'll be kicked off the system in no time. Our statistics show that this happens with about 95% of all new users!

And for what it's worth,

Once Banned = Banned Forever!
Robert AH Prins
robert.ah.prins @ the.17+Gb.Google thingy
Some programming here :mrgreen:
prino
 
Posts: 491
Joined: Sat 06 Jun 2009, 21:41
Location: Oostende, Belgium

Return to Dezhi systems: Mainframe

Who is online

Users browsing this forum: No registered users and 1 guest

cron