Mainframe Playground

Search for PRINT command in “z/OS SDSF Operation and Customization”.

Enter selected output with 'S' action character and issue following commands:

This is three phase process. First command creates data set:: ODSN - data set name in which output will be saved. * - volser, '*' defines that data set is cataloged and no volser is needed. N - data set disposition (NEW, OLD, MOD, SHR) Another way to copy output from spool is XDC action character on selected output. In this case panel will appear where you'll be able to specify operation details. Note: You can also use PRINT or PT keyword instead o PRT.

Enter selected job entry with '?' action character and from there enter JESMSGLG output. Act the same way as 9n Task#1 but specify O(OLD) disposition.

XDC panel can also be used in this case.

Enter User Log (U) and act the same way as before:

Go to the begging of the log. Use TOP command or M(MAX) command with PF7. Now you can issue following commands:

When you are printing SYSLOG it is required to use print limiting parameters, you cannot easily print entire log like in USERLOG case.

Use CSR scrolling option so you can easily set selected output on the first line to be printed and then issue commands:

This time you'll need to use command with time parameter:

Full command format in this case is PRT hh:mm:ss dd/mm/yy hh:mm:ss dd/mm/yy

Check “JES2 Initialization and Tuning Guide” and “JES2 Initialization and Tuning Reference” for more info about JES2 setting. The latter document describes in detail each initialization statement. For lighter reading check JES2 part in “ABCs of z/OS System Programming Volume 2”.

You'll have to modify both Job Class and Output Class for this Task.

Normally JES2 is stopped only during IPLs, only critical errors may be a reason for JES2 restart during normal system work. Still if such situations appears you need to know how to perform such activity. Check very carefully both shutdown and startup commands before performing this task. Also pay attention if any WTOR appears during the activity. This activity may cause other errors so make sure you check carefully SYSLOG for any problems that may require your attention.

JES2 Monitor commands use '$JDxxxxx' format.

Check SYSAFF keyword in “JCL Reference”. This function is not available in older z/OS versions.

Check description of '$TA' command in “JES2 Commands”. To retain it after IPL you'll need to add it to JES2PARM as well.

What's initialization statement? Initialization statement suggest it is simply a startup parameter, it's correct although you can also modify most initialization statement during JES2 run. Such modification is called 'dynamic' setting change. Basically initialization statements define setting in standard keyword-value manner. ____________________ What's the default name of member that stores JES2 setting? By default setting is stored in JES2PARM member. The name can be different depending on your installation setting. It's name and localization is defined in JES2 startup procedure. There is also a '$D INITINFO' command that will display this information. Almost always single member (JES2PARM) stores JES2 setting. It's very unlikely to have many members like in case of for example PROGxx members but it is possible. If you for some reason need to use more members or simply temporarily add some additional setting in JES2PARM you can use INCLUDE initialization statement to add content from another data set. ____________________ List JES2 address spaces. JES2 consists of four mandatory address spaces. It's similar situation like with DB2, JES2 works like a Master address space so it manages startup and shutdown of other address spaces. JES2 – main JES2 address space. It accepts JOBs, STCs and TSUs and controls the data flow for them. JES2AUX – auxiliary address space. It's like a safeguard against JES2 failures, it can provide some of JES2 functionality even when JES2 is broken, therefore decreasing impact on the system. JES2MON – monitor address space. Provides statistical and diagnostic information about JES2. It's most useful during JES2 failure or when it doesn't responds. You can communicate with that address space with '$JD*' commands. JESXCF – JES support for Parallel Sysplex. ____________________ Describe JES2 start modes. Basically there are two modes: WARM and COLD. The most important information is that you should never start JES2 in COLD mode. Why? Because it clears entire Spool and Checkpoint data set. As you can imagine it's equal to a big data lost and unpredictable problems. COLD start is done only when JES2 is started for the first time or sometimes during migration activities. So basically JES2 is always stared in WARM mode. Depending on JES2 configuration and last JES2 end there are five variations of WARM start: - All-member warm start – when no other MAS member is active. - Single-member warm start – when other MAS members are active. - Quick start – when there is no need to update job and output queues. - Hot start – after JES2 abend. - Auto start – also done after abend but here JES2 is restarted by other MAS member. For more info check “Restarting JES2” chapter in “JES2 Initialization and Tuning Guide”. ____________________ How can you start JES2 sub-system? JES2 is started as any other task with 'S JES2' often there are additional parameters specified in the command for example 'S JES2,PARM='WARM,NOREQ''. To avoid any errors always check what command is used in particular installation. JES2 is usually started automatically via COMMNDxx member or Automation software – search there for the appropriate command variation. JES2 startup parameters are described in “Specifying the Start Options” chapter of “JES2 Initialization and Tuning Guide”. ____________________ How can you stop JES2 sub-system? '$P JES2' – during normal shutdown JES2 will wait for all tasks that run under it to end before it will go down. You can display those tasks with '$D JES2' command. '$P JES2,ABEND' – abnormal end. JES2 will not wait for tasks, it will simply end. ____________________ What will happen to address spaces running under JES2 after executing '$P JES2,ABEND' command? Tasks will continue to run without interruption, but no new task or job will be able to start under JES2. That also means that no TSO user will be able to logon to z/OS. Also all tasks will still be able to write data to Spool and you'll be able to use SDSF to view Spool data sets including SYSLOG. Of course JES2 commands will fail but you can use JES2MON commands, for example '$JDSTATUS' if JES2 is down you'll see in it's output: '$HASP9151 JES2 ADDRESS SPACE NOT ACTIVE' ____________________ What's defined by “MEMB” initialization statement? All JES2 initialization statements (JES2 setting) are described in “JES2 Initialization and Tuning Reference”. You'll find there that it defines MAS member (Multi-Access Spool). MAS means sharing Spool and Checkpoint data sets in many LPARs. It does not require Parallel Sysplex although most configurations use it when in MAS. In MAS you can easily submit jobs from one system to another and view Spool data from the entire MAS. Note: MEMBer(nn) - IBM uses special naming convention in their documentation. Uppercase letters define mandatory parameter form. In this example you can code this parameter as MEMB or MEMBER. ____________________ What will happen if you'll update job class A dynamically (with command) after IPL. Will it be retained after system load? Yes, it will be retained after IPL. A lot of JES2 setting is stored in Checkpoint Data Set. For example classes or resources. This means that after IPL setting is still retained and will be kept until COLD JES2 restart. Of course this is just 'good to know' knowledge. All setting that should be permanently changed must be also updated in PARMLIBs. During JES2 initialization you are able to see which setting saved in Checkpoint Data Set does not match JES2PARM, for example:

You should correct such values so both Checkpoint and JES2PARM setting are identical. ____________________ How can you modify JES2 initialization statements. Basically you can make two modification types. You can change the setting directly in PARMLIB, it will be applied after JES2 restart, IPL most often. You can also change setting dynamically via JES2 command or SDSF panels. Before PARMLIB modification always double check it's localization with '$DINITINFO' command. During any modification you need to be aware when it is possible and how to change it, here are few options that may be required to apply setting: - JES2 WARM restart - JES2 COLD restart - Dynamic (Commands or SDSF panels) Action needed for specific parameter is pointed out in “JES2 Initialization and Tuning Reference”. Here are two examples: - JOBCLASS - “$T JOBCLASS operator command or cold start” - of course cold start is not an option so you can only change it dynamically. This also means that changes done to JOBCLASS will be retained after JES2 WARM start and lost during cold start. - Dynamic PROCLIB - “$T PROCLIB command, warm start or hot start” - This means that changes to PROCLIB are not saved in Checkpoint data set. Because of this dynamic changes wont be retained after JES2 restart so you must always update JES2PARM in this case. Note: You can easily recognize setting that can be modified via SDSF by paying attention to color convention in SDSF panels. There are basically two types of records: - Active (White & Red) – when something is active, resource, device, job or started task - it's written in white & red color. White color defines fields that cannot be modified while red color defines fields you can overwrite. Of course you must know what are acceptable values for specific fields. - Inactive (Blue & Green) – jobs that are finished, held or those that are waiting for something are marked inactive. Also idle or disabled devices (printers, nodes) are shown in that color.

What's JES2 startup command used on your system? The easiest way is to use '$D INITINFO' command. If for some reason it doesn't work, for example you have old z/OS version you should check COMMNDxx PARMLIB member or System Automation setting. ____________________ Where JES2 setting is stored? The same command '$D INITINFO' displays location of JES2PARM member. It's defined in JES2 startup procedure so if you'll ever need to change the name or location of this library you should update it first. JES2 startup procedure is obviously not defined in JES2 PROCLIB, after all they're not known before JES2 start. When you start JES2 (or any other subsystem that runs outside JES2) system searches for startup procedure in PROCLIB concatenation defined by Master Scheduler (MSTJCLxx). ____________________ How many initiators are controlled by JES2 and how many by WLM? JES2 controlled initiators are static. They are defined during IPL and cannot be added dynamically. WLM controlled initiators are added and closed dynamically by WLM accordingly to the workload needs. You can check it in INIT panel. Some systems will have only static initiators.

____________________ How many tracks one Track Group (TG) has? Track Group is simply an allocation unit for Spool. You define DASD data sets in tracks or cylinders. Spool is allocated in Track Groups, by default one Group has three tracks. Now you know why JES2 Spool is also called TGS (Track Group Space). You can check it in two ways: - 'SP' panel in SDSF – search for 'TrkPerTG' column. - '$DSPL,LONG' command. ____________________ How large (in tracks) SYSLOG is? Now that you know what Track Group is it's easy to check how much tracks on Spool particular job allocates. Again you can display it in two ways: - 'ST' panel in SDSF – search for 'TGNum' column. - '$Djobid,LONG' – search for 'TGS' parameter. So if 'TGS=430' and Track Group has 3 tracks, SYSLOG will use 1290 tracks in Spool. ____________________ How large (in cylinders) Spool is? What's the limit for Spool size? Enter 'SP' SDSF panel and search for 'PTracks' column. PTracks – Total Spool Size (all spool volumes available to the system). PTrackU – Used Spool Space in all volumes. DTracks – Size of particular Spool volume. DtrackU – Use space in particular Spool volume. You can display similar information with '$DSPL,LONG' command. To check size limit for entire Spool issue '$DSPOOLDEF' command:

Values here are shown in TG(Track Group) so there are actually 96045 Tracks are allocated for Spool. MAX parameter defines maximum limit. It's important to remember about it because when you add or resize Spool volume you cannot exceed that value. Fortunately you can easily change that value with JES2 SET command. Another important parameter is VOLUME – it's a mask that defines volumes eligible to be used as Spool. In this example only MVSSP* volumes can be used as Spool volumes. ____________________ How many Spool volumes are used on your system? At that point that should be easy: - 'SP' SDSF panel. - '$DSPL' command. ____________________ How many MAS members are defined in your installation? You can check MAS configuration with '$DMEMBER' command or in 'MAS' panel in SDSF. It's worth remembering that via that panel you can see information about Checkpoint Data Set usage: - PrevCkpt – time since last Checkpoint operation done by particular member. - ActHold – amount of time for which member is locking Checkpoint. ____________________ How many Output classes there are? Job classes can be checked via 'JC' panel in SDSF. Unfortunately Output classes don't have such panel so you must use '$DOUTCLASS' command to display them. If you want to display each class in single line simply limit display to single parameter, for example '$DOUTCLASS,OUTDISP'. ____________________ Do you have any output class that purges SYSOUTs routed to it? On most systems there is at least one Output class defined with PURGE output disposition. SYSOUTs assigned to this class are purged immediately after execution. Often class 'X' is used for this purpose. You can check it with following command: '$DOUTCLASS,OUTDISP' ____________________ How many jobs can be stored in Spool? Each job that is stored on Spool takes not only physical space on TGS but also in Checkpoint Data Set. Each Job and SYSOUT has it's own record in Checkpoint Data Set. Those records are used by all members in MAS so each JES2 subsystem is aware of jobs that are running on other systems. For example: By default two jobs with the same name cannot run at the same time, this is also true in MAS. When you submit a two jobs with the same name from two MAS members, the job executed later will wait until the other one is finished. In 'RM' panel you'll find various JES2 resources. TGS is displayed there which can be useful for monitoring Spool space in almost real time, simply turn on auto-refresh '&2'. We're interested here in 'JQES' resource. To find more information about it use 'D' action character next to it:

So JQES resource is defined by 'JOBDEF' initialization statement. Search for the parameter with the same value as shown in RM panel, in this case 'JOBNUM=9000' Now you can read all about it in “JES2 Initialization and Tuning Reference” - JOBDEF statement, JOBNUM parameter: “Specifies the maximum number (must be no greater than 1,000,000) of jobs that can be in the JES2 job queue at any given time. This value includes all TSU, STC jobs, and batch jobs.”. ____________________ How many Job output elements can be stored in Spool? You can check it in exactly the same way as before but this time we're interested in 'JOES' resource (OUTDEF statement, JOENUM parameter). JQES and JOES are two resources you should remember. Sometimes there may be a Spool problem not related to actual Spool space but those limits. For example some task may enter loop which in each iteration produces one SYSOUT and 'JOES' resource will start to deplete fast. Of course you need to identify and take care of this task, but to gain more time you can increase JOES limit via SDSF. Remember that each resource from 'RM' panel needs Checkpoint Data Set space so if your Checkpoint is fully utilized you will be unable to increase them.

There are 36 default job classes (A-Z, 0-9) and two special classes TSU (for TSO address spaces) and STC (for Started Tasks). So in total there are 38 classes and you can add more user defined classes if needed. Here are various options how you can manage setting of multiple classes at once: - JOBCLASS(class) – setting for single class - JOBCLASS(class,class,class) – setting for three specific classes - JOBCLASS(?) - setting for 36 job classes (A-Z, 0-9) - JOBCLASS(*) - setting for all classes including TSU and STC In this assignment we need the simplest version. In this assignment setting must be applied immediately – that means that we need to change it with command. It must be also retained after IPL. As you already know Job Classes setting is stored in Checkpoint Data Set and therefore it will be retained after IPL even without PARMLIB modification. Still permanent changes should be always applied in PARMLIBs so we'll also have to do it. JOBCLASS parameters that needs to be changed: - TIME=(60,00) - MODE=WLM - COMMAND=EXECUTE - HOLD=YES First let's change current setting with a command: - '$D JOBCLASS(T),LONG' – it's useful to copy current setting somewhere, just in case. More importantly you can see here parameter syntax so you don't have to check in documentation. - '$T JOBCLASS(T),TIME=(60,00),MODE=WLM,COMMAND=EXECUTE,HOLD=YES' Now you can use the new setting but JES2PARM also needs to be modified: - First check member name and it's location with '$DINITINFO' command. - Create a backup copy of JES2PARM. - Check syntax in documentation. - Modify JES2PARM accordingly:

The modification itself if pretty easy but you must be very careful during all actions in any PARMLIB member, so double check syntax in documentation, all commas, comments and so on. All options you haven't specified here will be taken from universal definition JOBCLASS(*), JOBCLASS(?) or will simply have default value. Default values are underlined in parameter descriptions. After you're done with the exercise you should of course change the setting back to the original.

Consider following job:

After execution it will produce four spool data sets:

First three are outputs produced by JES2. Those outputs are controlled by OUTDISP parameter in JOBCLASS initialization statement. All other outputs are produced by programs executed in the job. Those outputs are controlled by OUTDISP parameter in OUTCLASS initialization statement. Modify both JOBCLASS and OUTCLASS with the name 'T': - '$TJOBCLASS(T),OUTDISP=(PURGE,PURGE)' - '$TOUTCLASS(T),OUTDISP=(PURGE,PURGE)' Now submit job with following setting (check outputs with '?' action character): - CLASS=A & MSGCLASS=A – 4 outputs - CLASS=A & MSGCLASS=T – 3 JES2 produced outputs - CLASS=T & MSGCLASS=A – 1 IDCAMS produced output - CLASS=T & MSGCLASS=T – 0 outputs So if your goal is to remove all outputs both Job and Output classes needs to be modified.

You cannot stop JES2 normally when any task is running under it. This means that normal JES2 shutdown is done only during IPLs when all tasks are closed anyway. In such case standard '$PJES2' command is used. When you need to restart JES2 without IPL you need to issue '$PJES2,ABEND'. In that case JES2 will not wait for the any tasks to end. Active tasks won't be affected, but none of them will be able to end (it won't be able to enter Output processing phase). Of course no new jobs or task will be able to run when JES2 is down unless you start them under Master Scheduler. Before JES2 restart you need to check two things: - '$DJES2' – tasks running under JES2. Just to confirm that each of them is fine after restart. - '$DINITINFO' – for command used to start JES2. JES2 shutdown options: - '$PJES2' – standard command used during IPL. - '$PJES2,ABEND' – used for JES2 shutdown while there are some tasks running under JES2. - '$PJES2,ABEND,FORCE' – strongest version of the command. Be careful with it because if '$PJES2,ABEND' won't work it's likely that the problem is not related to JES2 but some more global problem. - '$PJES2,TERM' – this command can be used only during IPL. After issuing it you won't be able to restart JES2 manually. To sum it up the only option to restart JES2 during normal system processing is '$JES2,ABEND'. During shutdown following WTOR will appear: “$HASP098 ENTER TERMINATION OPTION”. In $HASP098 description you'll find specific options. DUMP is obviously not needed for this assignment so 'END' option can be used. Now no new job will be executed and no new user will be able to logon. In SDSF you'll see that although JES2 is down it's address spaces (JESXCF, JES2MON and JES2AUX) are fine. You can still use JES2MON commands to check JES2. Now you need command you've copied from '$DINITINFO' output. Standard command: 'S JES2,PARM='WARM,NOREQ''. Of course the most important thing is to start it in WARM – this is default mode but it won't hurt to additionally specify it here. JES2 will automatically detect running tasks so you can reissue '$DJES2' command to compare them.

- '$JDSTATUS' – displays status of JES2 subsystem along with any serious error messages. This is most useful command here. Whenever there are some problems with JES2 subsystem, it is not responding or some of it's function doesn't work you can check here is JES2MON detected any problems with JES2. - '$JDMONITOR' – display status of JES2MON and it's functions. - '$JDDETAILS' – you'll find here resource utilization so it's great way to check them without access to SDSF. Wait Table can point you to activities that are blocking JES2 processing and you can even see amount of Central Storage used by JES2. - '$JDHISTORY' – displays JES2 resources usage over time which can point you to some periodical problems or to a time in which problem appeared. From those commands '$JDSTATUS' is definitely worth remembering. Except that JES2MON is not that useful although you should know what information you can find in it.

JCL Code:

'SYSAFF=MVS2' will submit job to MVS2 MAS member. In job output you'll find: “$HASP373 JSADEK01 STARTED - WLM INIT - SRVCLASS BATCHMED - SYS MVS2” Additionally you'll find that 'D IPLINFO' command was issued on MVS2.

Of course first step is to find proper command. We're looking for Purge command but in case of JES2 selection criteria are almost identical in '$D', '$P' or '$C' command. Because of that it's good practice to always test selection criteria with '$D' and then simply change the operation. The needed command: '$DOJQ,JM=JSADEK*': - 'DO' (Display Output) – it will display only outputs so no active jobs or user session will be selected. - 'JQ' (Job Queue) – instead of single job we'll work on the entire job queue. - 'JM' (Job Mask) – JM keyword allows you to specify prefix of outputs you want to select. Thanks to '$D' command you can safely test if only desired outputs are selected before issuing '$P'. To display each SYSOUT in different line you can select only single parameter for each one: '$DOJQ,JM=JSADEK*,OUTDISP' Setting up automatic command is pretty easy: '$TA PUR1,T=24.00,I=86400,'$POJQ,JM=JSADEK*'. Notice that now '$P' instead of '$D' is used. 'T' parameter describes time since last midnight, not an hour at which command will be executed. So if 'T=00.01' is used the command would be executed immediately. It also means that this is start of an interval so if it's issued at 13:25 then this would be the hour at which command is issued every day. Using 'T=24.00,I=86400' ensures that command will be issued at midnight every day. You can display all Automatic Commands with '$TA,ALL' command and cancel it with '$CA name' command. But in this assignment it should be a permanent change so JES2PARM must be updated. All you need to do is to simply add this command at the end of JES2PARM. It will be issued automatically during JES2 initialization: '$HASP604 ID PUR1 T= 24.00 I=86400 L=INTERNAL $POJQ,JM=JSADEK*' As you can see 'L' parameter is not set to INTERNAL which pretty much means that it was issued by JES2 itself.

Master Scheduler PROCLIBs are defined in Master Scheduler startup procedure (MSTJCLxx). JES2 Static PROCLIBs are defined in JES2 startup procedure (JES2). JES2 Dynamic PROCLIBs are defined as JES2 initialization statements (JES2PARM).

Remember that Dynamic concatenations overwrite Static ones so always ensure you don't overwrite any existing PROCLIB concatenation, Static or Dynamic, when defining new one. To add new Dynamic PROCLIB concatenation you need to use '$ADD PROCLIB' command but when you add another data set to the existing concatenation you use '$T PROCLIB' check 'JES2 Commands' document for more details.

Master Scheduler PROCLIBs must contain startup procedures for every task that is to be started independently of JES2. Obviously JES2 startup procedure must be stored here. JES2 can use two types of PROCLIB concatenation. Static is defined in JES2 startup procedure and cannot be modified dynamically. To update it you must change the startup procedure and restart JES2 which is usually equal to an IPL. Dynamic JES2 PROCLIB concatenation is defined in JES2PARM and can be updated dynamically with command. This is recommended option: - It eliminates need of JES2 restart. - Error in Dynamic PROCLIBs won't prevent JES2 from starting which is the case with Static PROCLIBs. - They're much easier to manage. In this assignment we'll work with Dynamic PROCLIBs since nowadays they are used on almost every system. 1. Checking MASTER PROCLIB concatenation. - 'D IPLINFO' – prefix of IEASYSxx. If 'IEASYS LIST = 01 (OP)' it means that IEASYS01 & IEASYS00 is used. 'OP' means that it's user defined member. - 'D PARMLIB' – concatenation that stores IEASYSxx member. - MSTJCL=xx – parameter in IEASYSxx that defines MSTJCL suffix. MSTJCLxx is also stored in PARMLIBs. It's the only startup procedure stored in PARMLIB, after all at the time when Master Scheduler is started no PROCLIB concatenation is known to the system. - IEFPDSI – DD statement in MSTJCLxx startup procedure that defines MASTER PROCLIBs. You'll find JES2 startup procedure in there. 2. Checking JES2 Static PROCLIB concatenation. - Almost always JES2 startup procedure is called JES2 but if you have two JES2 subsystem the name can very, in this case simply check it's name in SDSF. - You already know MSTJCLxx PROCLIBs – search there for JES2 member. - PROCxx – definition of Static PROCLIB concatenation. 3. Checking JES2 Dynamic PROCLIB concatenation. - You already have JES2 startup procedure. Check there HASPPARM DD statement – it defines data set and member name of JES2 initialization statements (JES2PARM by default). It can be also displayed with '$DINITINFO command. - PROCLIB – in JES2PARM search for PROCLIB initialization statement, it defines Dynamic JES2 PROCLIBs. - This is the optional concatenation so on some systems it may not exist. Note: On older systems only Dynamic PROCLIBs are displayed with '$DPROCLIB' command. On newer Systems '$DPROCLIB' will also display Static JES2 PROCLIB and mark them appropritely:

In this example only one PROCLIB concatenation is defined – PROC00. Often more are used, for example PROC00, PROC01 and PROC02. First one can be used for Jobs, second one for Started Tasks and last one for TSO Logon Procedures.

You need only to issue two commands: - '$ADD PROCLIB(PROC66),DD(1)=(DSN=USER.TEST.PROCLIB)' - '$T PROCLIB(PROC66),DD(2)=(DSN=USER.PROD.PROCLIB)' Notice that when you create new PROCLIB concatenation you need to use ADD command, but when adding new data set SET($T) command is used. Also make sure you use 'PROCxx' naming convention, otherwise you won't be able to specify it in JOBCLASS. JES2 searches for the procedure from the beginning so USER.TEST.PROCLIB should be defined before USER.PROD.PROCLIB. Suppose you have procedure called LISTDASD in PROD PROCLIB. You need to modify it and test changes. You could of course create backup copy and modify the original but the better way is to simply copy it to TEST PROCLIB – JES2 will find it first and test version will be used. As always naming convention is also important. You cannot simply add to system concatenations data sets with your user ID because RACF protect them, also if you add data set with wrong HLQ it may be assigned to wrong Management Class and DFHSM may migrate or even remove them. Because all that you should use HLQ and volume that is used from storing PROCLIBs. This kind of information should be included in system documentation. Note: There are two ways in which you manage PROCLIB libraries - SMS and non-SMS: - '$T PROCLIB(PROC66),DD(2)=(DSN=USER.PROD.PROCLIB)' – SMS must be active. - '$T PROCLIB(PROC66),DD(2)=(DSN=USER.PROD.PROCLIB,UNIT=SYSDA,VOL=SYSEC2)' – SMS doesn't have to be active. Most often it doesn't matter since almost all software runs after SMS startup so you can use first version. But meke sure that startup procedures for basic system tasks like TSO, VTAM, SDSF etc. are in libraries independent from SMS. All other tasks like CICS, DB2, TWS can be safely stored in libraries which need SMS to be accessed.

In Task#2 you've added PROC66 to JES2 PROCLIBs but it is still unusable at that point. Now, you must assign it to some class. In this Task class 'T' will be used: - '$T JOBCLASS(T),PROCLIB=66' Now you can test it with simple job:

Job will end fine with class T but if you run it in any other class JES2 won't search PROC66 and job will end in error. In the job output, just after JCL code, you can find info about library in which executed procedure was found: “IEFC001I PROCEDURE DUMMY01 WAS EXPANDED USING SYSTEM LIBRARY USER.TEST.PROCLIB”. Note 1: By using different PROCLIB concatenation for different classes you can speed up search and simplify management of PROCLIBs: - JOBCLASS(?),PROCLIB=00 – all Job classes (A-Z, 0-1) will use PROC00. - JOBCLASS(STC),PROCLIB=01 – Started Task procedures (started with 'S procname,parameters' command) are in libraries defined by PROC01 concatenation. - JOBCLASS(TSU),PROCLIB=02 – Logon procedures for TSO users will be stored in libraries defined in PROC02 concatenation. - JOBCLASS(T),PROCLIB=66 – single class 'T' will use separate PROCLIB concatenation. Such class can be used for testing purposes. Note 2: To sum it up here are PROCLIB characteristics you need to know: - Static PROCLIBs are defined in JES2 startup procedure and cannot be updated dynamically (without JES2 restart). - Dynamic PROCLIBs are defined in JES2PARM and can be updated dynamically. This type is recommended and should be always used. - Dynamic changes are not retained after JES2 restart so you always need to update JES2PARM for setting that must be kept after IPL. - Always use “PROCxx” naming convention in order to have full PROCLIB functionality. - Static and Dynamic PROCLIBs can be used at the same time if you define them with different names. - If both Static and Dynamic PROCLIB is defined with the same name (PROC00 for example), Dynamic definition overwrites the Static. - Job Class defines which PROCLIB concatenation is used by specific Class.

This Task let's you test how SMS and non-SMS libraries in PROCLIB will behave in case of data set migration. First you need to modify PROC66 so only one of them requires SMS to be accessed: - '$T PROCLIB(PROC66),DD(1)=(DSN=USER.TEST.PROCLIB)' - '$T PROCLIB(PROC66),DD(2)=(DSN=USER.PROD.PROCLIB,VOL=MVSLB1,UNIT=SYSDA)' Ensure that both DUMMY01 and DUMMY02 works correctly. Now you can move those libraries to a different volume. You can do this with IEHMOVE Utility:

Note that always when you move data sets from one volume to another you must consider SMS configuration. ACS routines may prevent you from moving the data sets. If that's your case you can use ADRDSSU Utility with BYPASSACS control statement to overwrite them. After move is done check DUMMY01 and DUMMY02 procedures. What happened? Both procedures cannot be found. In case of “USER.PROD.PROCLIB” it's understandable, after all volume doesn't match. But SMS managed library also cannot be found, it is because JES2 allocates the library during startup or dynamic command, it does not monitors data set operations. To update JES2 setting you still need to reissue command: - '$T PROCLIB(PROC66),DD(1)=(DSN=USER.TEST.PROCLIB)' This command doesn't change the definition but rather refreshes it. This command check if data set exists and uses SMS to locate it so all information related to PROC66 are updated. Of course second DD also must be updated with the correct volume: - '$T PROCLIB(PROC66),DD(2)=(DSN=USER.PROD.PROCLIB,VOL=MVSLB2,UNIT=SYSDA)' To sum it up - depending on SMS doesn't mean that JES2 allocations are updated dynamically – you must still issue command to update the setting. What in that case are benefits of using SMS here? You don't have to pay attention to volume on which data set resides and you don't need to update JES2PARM. Note: Actually every “$T PROCLIB” command updates the entire PROCxx concatenation so in this assignment you could only issue: - '$T PROCLIB(PROC66),DD(2)=(DSN=USER.PROD.PROCLIB,VOL=MVSLB2,UNIT=SYSDA)' And DD(1) would be also updated. This is another benefit of using SMS manged libraries, if all libraries are migrated you can update setting with a single command.

As described in “JES2 Commands” to remove data set from PROCLIB concatenation you have to use null value in DSN parameter: - '$T PROCLIB(PROC66),DD(1)=(DSN=)' DD(n) – 'n' number is automatically changed from 2 to 1. Also if you use '$T PROCLIB(PROC66),DD(78)=(DSN=TEST)' JES2 will still use DD(3), not 78. To remove the entire concatenation PROC66 you need to use '$DEL' command: - '$DEL PROCLIB(PROC66)' Now it's time to modify JES2PARM, as always: - confirm member and data set names with '$DINITINFO' command. - create backup member of JES2PARM. - double check syntax comparing it to existing PROCLIB statements in JES2PARM and/or “JES2 Initialization and Tuning Reference”.

Those libraries will store user created procedures so they don't have to be available during IPL. Because of this we'll use SMS to access them and therefore avoid unnecessary JES2PARM modification if ever data sets are moved to a different volume. Of course you also need to modify JOBCLASS(T) both in JES2PARM and dynamically (so Checkpoint Data Set is updated).

Spool Offload Facility enables you to move SYSOUTs and Jobs from Spool to user defined data set. It's used for various Spool operations. For example if you want to move Spool data from one system to another you cannot copy SYS1.HASPACE but you can offload all SYSOUTs and held jobs to Offload Data Set and unload them to a different JES2 configuration. It's also useful during Spool volume removal. It's different than printing outputs with XDC command or offloading SYSOUTs with use of BETA or similar software. Spool Offload Task saves spool data without any conversion, in it's original format. Because of that you won't be able to view it but you can send it back to the Spool which is impossible otherwise. Check “JES2 Initialization and Tuning Guide” for more details about Spool Offload Facility.

You'll find guidance in “JES2 Initialization and Tuning Guide”. Focus on “Chapter 3: SPOOL volume configuration”. You'll also need “JES2 Commands”. You can allocate SYS1.HASPACE with a job but on newer z/OS versions JES2 can do it for you so if you have current z/OS release all you need is a little bit of research and few JES2 commands. You can start with checking parameters defined by SPOOLDEF initialization statement.

In case of Merge and Migrate operations you need to pay attention to the space available in source volumes (the ones you move). Space needed on target volume is not equal to a space used in source volume. It works like mapping operation so the highest used track on source volume defines space needed on the target volume. See “Calculating tracks” chapter in “JES2 Commands” for more details. Some spool operations such as Migration require that no active Job or Task uses it. If spool is used by many Tasks IPL may be required here. Other operations such as Spool removal additionally require that no single SYSOUTs is present on the Spool. Spool Offload Task is useful in such situations.

1. Simple IEBBR14 jobs will be fine for this assignment. Confirm that they are waiting in Input queue in Hold status 'I' panel in SDSF. 2. You can view all Spool Offload Tasks in 'SO' panel in SDSF:

Each task has four logical devices: - JT – Job Transmitter – for sending job before execution. - ST – SYSOUT Transmitter – for sending jobs after they have ended. - JR – Job Receiver – for receiving jobs that weren't executed yet. - SR – SYSOUT Receiver – for receiving outputs. In this assignment we're working with jobs before execution so we'll use JT and JR devices. 3. First you need to find out the name off Offload Data Set: - Use 'D' action character next to the OFFLOAD1 record in 'SO' panel. - Or use '$DOFFLOAD1' command. As always copy all setting that you want to change to restore it when you're done with the activity. To allocate new Offload Data Set you need to know it's characteristics so copy them from existing one. If you use option 'S' to display data set characteristics before entering 3.2 panel they will be automatically substituted in fields in 3.2 panel. Basically offload data set should have following characteristics:

4. When data set is allocated you can change OFFLOAD1 setting: - '$TOFFLOAD1,DSN=USER.OFFLOAD' 5. Now you need to define which jobs are to be transmitted to the Offload Data Set. This is set separately for each device. Display and copy setting for JT device setting the same way you have checked Offload Task setting. We are interested in WS (Work Selection) parameter. It defines which filters are used for job selection. For example WS=(JOB,V/) means that filters defined by JOBNAME and VOLUME will be taken into consideration. Criteria specified after '/' character do not have to be exact match, you can check '$TOFFn.xx' commands in “JES2 Commands” to find out what exact match means for each criteria. In this Task we are only interested in job name: - '$TOFF1.JT,WS=(-CL,JOB/),JOBNAME=JSADEKX' - '-CL' – removes previous selection criteria. - 'JOB' – new filter will based on the job name so JOBNAME filter must be also set. 6. Now everything is set and we can start offload task. It is done with command: - '$S OFFLOAD1,TYPE=TRANSMIT' But before that you should ensure that no other outputs are transmitted. When you start transmission both Jobs and SYSOUTs are transmitted. You can check 'ST' setting to ensure that no SYSOUT is transmitted, but easier way is to simply Drain the transmitter. - '$P OFF1.ST' Now only workload that matches OFF1.JT selection criteria will be selected. When transmission is done close it with '$P OFFLOAD1' command. 7. To receive the jobs back into the Spool you also need to check device setting. This time job receiver 'JR' needs to be modified: - '$TOFF1.JR,WS=(-CL,JOB/),JOBNAME=JSADEKX' And to receive outputs: - '$POFF1.SR' - '$SOFFLOAD1,TYPE=RECEIVE' In this case transmission is automatically ended when all jobs are moved back to spool so you don't need to issue '$P' command. 8. Now you can simply release the jobs and they will be executed normally. 9. After you're done make sure you restore original setting and remove data set you've allocated. Note: Each Transmission overwrites Offload Data Set so if any outputs are already stored in the data set they'll be lost. Because of that it's good habit to change the data set name if you're not sure if you can use default one.

1. Before any action you must check Spool setting with '$DSPOOLDEF' command:

Here are parameters you need to consider: - SPOOLNUM – maximum number of spool volumes to use. Usually it's set to 32 and you don't need to do anything with it. - TGSPACE=MAX – this is maximum size of all active spool volumes. If you are already close to that limit you need to increase this value. It's must be the multiplication of 16288, but don't worry about it, JES2 will automatically round up your value to the closes multiplication of 16288. - VOLUME - defines that only volumes starting with JESYS* can be used as spool. What's spool volume? Spool itself is simply a data set called by default SYS1.HASPACE, since there can be only one such data set on volume, a volume that contains it is called Spool volume. It's the same situation as with Master Catalog Volume – it's simply a volume that contains Master Catalog. 2. Now we need a volume on which Spool will be allocated. You already know the required name. In this example current Spool volume is called JESYS1 so new volume will be called JESYS2. If you don't have such volume you'll have to Initialize (reformat) some existing not used volume, here is job that does that:

Before volume initialization you need to put it offline: 'V 128A,OFFLINE'. You can read about each parameter in ICKDSF documentation. The amount of space you allocate for the VTOC depends on how much data sets could be stored on the volume. Model 3390 can store 50 DSCBs per track. DSCB is simply a VTOC record. There are few types of DSCBs there is type for data set primary extend, secondary extend, free space location on DASD and so on. For simplification you can assume that one DSCB is one data set extend. First track on volume is reserved for bootstrap and volume label. Because of this you need to start from track 1, not 0. In this example VTOC started at track 1 and uses first 3 cylinders on DASD, after that VTOC index uses fourth track. There are two keywords VFY and NODS that are here to avoid mistakes. VFY requires so you also specify DASD volser, not only it's device number. NODS ensures that no DASD is formatted if there are any data sets on it. Note: Spool volumes are recommended to be used solely for SYS1.HASPACE. Also this data set should be uncataloged and therefore volume must not be SMS-managed. 3. Create Spool data set. JES2 allows very fast spool addition, you can do that simply by issuing a command: - '$S SPL(JESYS2),FORMAT,RESERVED=YES,SPACE=(MAX)' – in case you want to use entire volume solely for Spool. In this case ensure that MAX limit in SPOOLDEF allows allocation of that size. This is recommended option but in this Assignment you don't have follow this recommendation and use 1000 cylinder Spool: - '$S SPL(JESYS2),FORMAT,SPACE=(CYL,1000)' In older versions of z/OS Spool data set had to be defined manually:

BLKSIZE = BUFSIZE in SPOOLDEF definition. Spool data set must be single volume and single extend so CONTIG keyword should be used in SPACE parameter. When SYS1.HASPACE is already allocated you can activate it with following command: - '$S SPL(JESYS2)' Now Spool is added and you can view it in 'SP' panel. You can submit few jobs and check which of them are stored on new volume: - '$DJQ,SPL=(V=JESYS2),STATUS'

To move Spool from one volume to another it must be in INACTIVE status. You can view SPOOL status in 'SP' SDSF panel. To stop spool volume you must use HALT command (not STOP). - '$Z SPOOL(JESYS2)' Now the problem may appear. If any active task or job is currently using spool it will be stucked in HALTING status. This simply means that no new allocations are allowed but current workload must end before Spool volume becomes INACTIVE. If single job or task is using it you may wait until it ends or recycle the task. If the spool is in use for a long time it's probably used by tens of Started Tasks. In this case you need to IPL a system. After IPL all tasks will use ACTIVE Spool and the one you've halted will become INACTIVE. When Spool is in INACTIVE status you can copy it to different volume with simple command: - '$MSPL(JESYS2),TARGET=JESYS3,FORMAT,SPACE=(CYL,1000)' Of course you should first ensure that there is enough space and volser naming convention is correct. Spool volume will enter into MIGRATING status, it may take a while. After migration process volume will be automatically started. Now you can confirm is all SYSOUTs are present on the new volume: - '$DJQ,SPL=(V=JESYS3),STATUS' Note: Migration operation copies SYS1.HASPACE data set, it doesn't move it. So SYS1.HASPACE will still be present on JESYS2 volume although it won't be used by JES2 anymore.

Spool extension (resize) is even easier than migration. All you need to do is to ensure that there is enough space on the volume and issue the command: - '$TSPL(JESYS3),SPACE=(CYL,2000)' It can be done on Spool in ACTIVE status so no need to worry about Spool allocations.

Spool merge is a bit strange operation. It does not mean that SYSOUTs from one volume are copied to another. Rather the entire Spool is mapped, it is copied inside another Spool volume. Because of that two things happen: - Space needed in target volume is equal to a highest address of allocated Track Group. So even if 20 TG are used but the last one is stored at TG address 500 then 500 TG are needed in Target volume. - After the process is done SYSOUTs from source volume are still displayed as if they were still stored in the source volume, although they now reside on Target volume. It's like there is one Spool volume inside another. SYS1.HASPACE on JESYS2 is already allocated to we simply need to add it to JES2: - '$S SPL(JESYS2)' Submit few jobs so both JESYS2 and JESYS3 are not empty. Use '$DJQ,SPL=(V=JESYS2),STATUS' again to check all Jobs and SYSOUTs that are using each of spool volumes. Copy them to the notepad for later comparison. If there are any Started Tasks that are allocating either of the Spools you may need to re-IPL the system later. If that's your case - wait for it until Task#6. Merge is done the same command as migration. The difference is that now both volumes are used by JES2: - '$MSPL(JESYS3),TARGET=JESYS2' After migration process is done all SYSOUTs from JESYS3 are copied to JESYS2 and JESYS3 enters MAPPED status. SYSOUTs are still displayed as if they were in JESYS3 but this volume in now stored as part of JESYS2. You can now remove SYS1.HASPACE from JESYS3 and you'll still be able to access those SYSOUTs.

To remove Spool from JES2 configuration you need to issue Stop command: - '$P SPL(JESYS2)' If there is anything stored on the volume it will enter DRAINING status and stay that way until all outputs are removed from it. - If any running Task or Job is using the Spool volume it must end. DRAINING status means that no new allocations are allowed so you can be sure that after recycle it will use another volume. If spool was used for a long time many tasks use it, the best solution is to re-IPL the system. - If you use some kind of tasks that offloads SYSOUTs from spool – it may take care of those existing SYSOUTs. - If not you need to deal with the situation manually, purge them or use Spool Offload Task to move them to Offload Data Set and then back to the ACTIVE Spool. Of course latter solution is needed if outputs needs to be archived. Currently you should have two Spool volumes to remove (one actually since the JESYS3 on is MAPPED into JESYS2):

We cannot drain or halt volumes while they are MAPPED. So we need to deal with JESYS3 first. You already know how to use Spool Offload Task so let's put those skills to good use: 1. Check and copy current setting so you can later restore it: - '$DOFFLOAD1' - '$DOFF1.ST' 2. We want to transmit SYSOUTs so to avoid undesired Job transmission, drain JT task: - '$POFF1.JT' 3. Change data set used for offload (optional): - '$TOFFLOAD1,DSN=USER.OFFLOAD' 4. Set work selection criteria: - '$TOFF1.ST,WS=(V,-Q,-OUTD),VOLUME=(JESYS3)' 5. Start transmission: - '$SOFFLOAD1,TYPE=TRANSMIT' 6. Stop transmission after transfer is done: - '$POFFLOAD1' This way you can offload data set from logical JESYS3 (that is stored as part of physical JESYS2 Spool). At that point no more SYSOUTs are in JESYS3 so it is completely removed. To restore SYSOUTs to current volumes remove all work selection criteria and drain JR device: - '$DOFF1.SR' - '$POFF1.JR' - '$TOFF1.SR,WS=(-Q,-OUTD)' - '$SOFFLOAD1,TYPE=RECEIVE' As you may remember each transmission overwrites the Offload Data Set so if you Offload SYSOUTs from JESYS2 before receive the ones from Mapped JESYS3 will be lost. Now that JESYS2 is no longer used for mapping you can Drain it: - '$PSPL(JESYS2)' It enters status DRAINING – and it will be hanged in it until all allocations are freed and SYSOUTs removed from it. You can offload it the same way as before: - '$TOFF1.ST,VOLUME=(JESYS2)' - '$SOFFLOAD1,TYPE=TRANSMIT' - '$POFFLOAD1' And just like before, after all SYSOUTs are moved from JESYS2 it is removed from Spool configuration. After Receiving SYSOUTs back to Spool your job is almost done: - '$SOFFLOAD1,TYPE=RECEIVE' All you need to do is to restore original Offload Task setting and reinitialize volumes used for that exercise.

Check “Checkpoint data set definition and configuration” chapter in “JES2 Initialization and Tuning Guide” document. You'll also need “JES2 Commands”.

The procedure is not very intuitive because of that Task itself gives a description of steps needed for this activity. To replace active Checkpoints you'll have to use JES2 Reconfiguration Dialog. It's started with '$T CKPTDEF,RECONFIG=YES'. In this activity it's especially important to update JES2PARM unless you want to restore setting immediately after you're done with this Assignment.

This Task can be done only on z/OS 2.2 or later. In previous releases Checkpoint resize can be done as described in Task#2. You can check if JES2 support this function with '$D ACTIVATE' command.

What's the purpose of Checkpoint Data Set? Basically Checkpoint Data Set is used for three purposes: - It's used for communication in MAS. Because of this only one Checkpoint is used in MAS and all members refer to it to manage workload. - It stores setting that needs to be shared by all members such as Classes or list of all Jobs and SYSOUTs stored in spool. - It stores all these information on DASD so it is not lost during JES2 restart. For example if you have some Jobs held in Input queue – they'll can wait there for years. IPLs will not affect them because their status is stored in Checkpoint Data Set and JCL code is stored in Spool. ____________________ What's stored in Checkpoint? All resources visible via 'RM' SDSF panel, most importantly: - Records of all Jobs that are still active along with pointers to their location on Spool. - Records of all SYSOUTs that are still active along with pointers to their location on Spool. ____________________ Do you need Checkpoint Data Set in Single-MAS configuration? Yes, although in this case Checkpoint is not used for communication between JES2 subsystems. All information written in Checkpoint data set are also stored in Central Storage. But what would happen in case of IPL or some hardware failure? All this data would be lost so in Single-MAS configuration Checkpoint is used as hard copy of JES2 queues and setting. You need it during each JES2 restart and of course in case of any JES2 or hardware failures. ____________________ How many Checkpoint Data Sets should be defined to JES2? Minimum one Checkpoint Data Sets is defined but normally two are used: CKPT1 and CKPT2. In this mode JES2 uses dual logging so if any of these data sets becomes corrupted or unavailable there is still second one ready to use. This also means that each I/O operation is slightly slower but data there is so important data set that dual-logging mode is pretty much mandatory. It's also good to have two spares defined: NEWCKPT1 and NEWCKPT2. Those aren't used for anything but can come in handy if you'll need to quickly change checkpoint size or location. So in total it's recommended to have four checkpoint data sets allocated, two active and two spares. ____________________ What's the recommended Checkpoint Data Set configuration? There are three main checkpoint configurations: - Dual logging in Duplex mode – standard dual logging mode. - Dual logging in Dual mode – alternative dual logging mode that reduces amount of I/O operations needed. - Single logging – not recommended. Additionally you can place checkpoint data set in Coupling Facility or on standard DASD. It's recommended to store primary Checkpoint Data Set (CKPT1) in Coupling Facility because it gives better performance and secondary on DASD in case connection to CF is lost by any reason. To sum it up it's best to have dual logging in Duplex mode with primary Checkpoint defined in CF structure and secondary on DASD. ____________________ What are recommendations for volumes that should be used for Checkpoint Data Sets? To ensure high performance Checkpoint Data Sets should be stored in high speed and low usage devices. It's also not recommended to put it on the same DASD that is used by Spool because it's always high usage device. For the best performance different volumes should be used for Checkpoint and each Spool. Also if both Checkpoint Data Sets are stored on DASDs they should be places on different devices, mainly to avoid single point of failure. It is also recommended to exclude Checkpoint Data Sets from GRS mechanism so access to them is not blocked by it. ____________________ Describe JNUM, JQES, JOES and BERT resources. - JNUM – Maximum value for Job ID. Usually default value of 9999 is enough but on production system with high workload it's good to increase this number. By increasing it you also change syntax of Job ID. Instead of JOB03982, J0643274 will be used. - JQES – Number of Jobs that are allowed to be stored in Spool. Shortage of this resource is rarely a problem and it's usually caused by some problem with Spool offload. - JOES – Number of Job output elements. Those are not SYSOUTs so they're not equal to elements visible when you issue '?' access character on specific output. Shortage may appear if some program enters loop in which new outputs are produced in each iteration. - BERT – This is additional space in checkpoint created to store extensions for other JES2 records such as JQES or JOES. JQES and JOES records have fixed length and not all data can be stored there. For example if you run a job with additional data such as Accounting Information, this additional data is stored in BERTs.

First you need to calculate needed space. “Determining the size of your checkpoint data set” chapter in “JES2 Initialization and Tuning Guide” describes this process. Here is simple procedure to calculate it: - '$D CKPTSPACE' command shows how much space is currently used in Checkpoint Data Sets. In this Task our goal is to increase it by 200%. - CAPACITY=3480 – this number defines number of 4K pages used. - 3390 DASD stores 180 x 4K records per Cylinder so in this example 20 Cylinders are currently used. New checkpoints are defined in similar way as Spool. You can use command to allocate then dynamically (since z/OS 2.2) or you can do that via batch job:

The same volumes are used here for Checkpoints and Spools. This is not recommended approach since it may degrade performance but on test systems it doesn't really matter. Now we can add it as spare Checkpoint Data Sets called NEWCKPT1 and NEWCKPT2: - '$T CKPTDEF,NEWCKPT1=(DSN=SYS1.HASPCKP1,VOLSER=JESYS1)' - '$T CKPTDEF,NEWCKPT2=(DSN=SYS1.HASPCKP2,VOLSER=JESYS2)' To replace currently used Checkpoints we need to use JES2 reconfiguration dialog. To start the dialog issue '$T CKPTDEF,RECONFIG=YES'. JES2 will issue a WTOR and instructions, among them you'll find:

This pretty much means that data from CKPT1 will be copied to NEWCKPT1 which will become active checkpoint. So you can answer to WTOR with first option. JES2 will ask you for confirmation with another WTOR for which 'CONT' needs to be answered. After that JES2 Checkpoint will be replaced. During that process it will be unavailable to MAS members but since Checkpoints are not usually large this will take few seconds max. After that you can do the same thing with CKPT2. Check with '$D CKPTSPACE' command how much additional space is now available in Checkpoint. The last and the most important thing is JES2PARM modification. If you forget it there may be serious problems during JES2 restart.

Before performing this activity you can check if your configuration supports dynamic Checkpoint operations with '$D ACTIVATE' command. Most systems use z11 checkpoint mode. z22 mode which is available since z/OS 2.2 enables many dynamic Checkpoint operations including Checkpoint resize. Also all MAS member must run z/OS 2.2 to be able to use this mode. If JES2 uses z22 mode you need only one command: - '$T CKPTDEF,CKPT1=SPACE=(CYL,50)' - '$T CKPTDEF,CKPT2=SPACE=(CYL,50)'

The easiest way to modify all those values is to use SDSF but you can use '$T' command as well. Still, 'RM' panel is useful to for finding name of initialization statement used for resource definition. Simply issue 'D' action character next to any resource:

In this example 'D' was issued next to BERT resource. As you can see it issues '$D CKPTSPACE' command and CKPTSPACE is the initialization statement that defines BERT limit. The same way you'll find out that JNUM is defined by RANGE keyword in JOBDEF initialization statement. JQES defines amount of Jobs that can be stored in Spool (this of course included outputs and active JOBs, STCs and TSUs). If you want to check if Checkpoint is large enough to for needed modification you can issue '$D CKPTSPACE', then increase the value by 1000 and reissue the command to calculate how much 4K blocks is used by 1000 JQES and if there is enough left for your change. Accordingly to recommendations JOES value should be 2.5 times larger than JQES so 25000 in our case. BERTs are calculated accordingly to the formula "JOBNUM + JOENUM/4 + 100": 10000 + 25000/4 + 100 = 16350 For simplification you can assume formula JQES * 1.5 so 15000 in our case. The difference is not significant and it's easy to remember and calculate. Note: When you try to increase some resource to much and there is not enough space in Checkpoint your command will simply fails. In that case you can follow procedure from Task#2 or resize the Checkpoint dynamically as described in Task#3.