Document Number SC31-6908-00
Trident Services and E.S.A. Software makes no warranty of any kind, expressed or implied, with regard to the programs or documentation. Trident Services and E.S.A. Software shall not be liable in any event for incidental or consequent damages in connection with or arising out of the furnishing, performance, or use of these programs.
Information in this manual is subject to change without notice and does not represent a commitment on the part of the vendor. The software described in this manual is furnished under a license agreement, and may be used or copied only in accordance with the terms of that agreement.
IBM Operating System Environment Manager (OSEM) for z/OS. Licensed materials - Property of IBM. 5799-HAX
(c) Copyright IBM Corp 2005. All rights reserved.
(c) Copyright E.S.A. Software 1990-2005. All rights reserved.
No parts of this publication may be copied or distributed, transmitted, transcribed, stored in a retrieval system, translated into any human or computer language, or disclosed to third parties without the express written permission of IBM Corp or E.S.A. Softare.
The following are trademarks of IBM Corp:
The following are trademarks of Computer Associates International:
First Edition (April 2005)
This edition applies to Operating System Environment Manager for z/OS (OSEM for z/OS) Version 6 Release 0 Modification 0 (Program Number 5799-HAX).
This section provides a list of important topics, which you will need to consider prior to installing OS/EM. The intent is to assist you in assessing the impact, if any, that OS/EM will have on your installation.
You must supply Trident Services with the CPU serial number of each machine that OS/EM will run on. This number is available from IBM (or other manufacturer if your CPU is not from IBM) and consists of a six digit number. The four low-order numbers are the important ones.
If you are unsure of your CPU serial number, you may enter the following command on an MVS master console to obtain it.
D M=CPU IEE174I 12.42.25 DISPLAY M 618 PROCESSOR STATUS ID CPU SERIAL 0 + 0114BA3746 1 + 1114BA3746 2 + 2114BA3746 CPC ND = 009672.R31.IBM.02.000000052227 CPC ID = 00 + ONLINE - OFFLINE . DOES NOT EXIST CPC ND CENTRAL PROCESSING COMPLEX NODE DESCRIPTOR CPC ID CENTRAL PROCESSING COMPLEX IDENTIFIER
In this sample display, the serial number of ID 0 is '0114BA'. The last 4 characters are the CPU model number. OS/EM uses the last 4 characters of the serial number, in this case '14BA'.
Every user exit currently in use at your installation should be thoroughly documented as to it's use and the location of both source and load members. All such exits should be functioning properly and should not modify any control blocks not specifically allowed at the exit point. Further, your exits should do nothing more than what is explicitly allowed in the relevant IBM documentation.
If any of these exits can be replaced by using OS/EM's optional facilities, determine if the optional facilities meet all your needs. If your exits contain more functions than those supplied by OS/EM, consider recoding your exits leaving only those functions not supplied by OS/EM.
You will also need to determine at what point you want the optional OS/EM functions to be invoked, either before your own exits or after all your exits have been processed. It is entirely possible that a conflict can develop between your own exits and the optional functions. For example, the optional functions supplied for IKJEFF10 modify the JOB statement. If your IKJEFF10 exit depends on certain information in a certain format on the JOB statement, the OS/EM optional processing might result in a different result for your exit.
In order to use the RELOAD function provided in the ISPF Interface, all user exits need to be defined to the Interface using the Basic Exits Functions. Although OS/EM will automatically find and load all user exits which have the standard IBM module names and are in the Linklist whether or not they have been defined to the Interface, the list of modules eligible to be reloaded is built from your entries in the Basic Exits Functions. If you prefer not to enter this information, please refer to "RELOAD Command" on page RELOAD-1 in the OS/EM Reference Manual for instructions on reloading modules manually.
Note: This information will be added automatically to the interface during the upgrade process or during the 'REBUILD' function from the 'MAINTENANCE' section of the interface.
Many products, such as job schedulers and SYSOUT archival systems, depend on exits to accomplish their work. You should know at which exit points these supplied exits are invoked, and where they currently reside.
Many of these products also require the same exit point. You should determine in what order they should be invoked if OS/EM is to load and enable them.
The OS/EM optional feature Job Routing allows an installation to route jobs to specific LPARs within a MAS. The Job Routing Communications dataset must be on DASD shared by each LPAR within the MAS. Additionally the Job Routing function must be enabled on each LPAR within a MAS concurrently. Failure to do so will result in jobs not being allowed to execute on LPARs where Job Routing is active if they have been through the interpreter on a LPAR without Job Routing. Conversely, LPARs within the MAS without Job Routing active may select jobs for execution without the specified resources.
At installations where it is not permissible for a 3rd party product to manage RACF user exits, you may specify to OS/EM to use SAF as the security system in use (see Step 7 of the installation instructions.) This will disable OS/EM from managing RACF exits as well as disallowing use of any OS/EM feature for RACF such as Surrogate Password Control, while still allowing calls to RACF for validation of other controls such as JOBCLASSCHECK (see Step 6 of the installation instructions.)
You should determine which of your exits have been installed via the SMP/E USERMOD process. Once OS/EM has been installed, SMP/E knowledge of such exits is no longer necessary. OS/EM dynamically loads its interface modules during initialization; and these, in turn, dynamically load your user exit modules. Therefore, after successful installation, you should remove the exits from SMP/E by the RESTORE function and link them into an OS/EM accessible library with different names (e.g. MYUJI), then update the OS/EM initialization parms to load the new names.
If your installation does not currently have a consistent dataset naming convention, one should be developed to make full use of the OS/EM DASD allocation built-in facility. At a minimum, the naming convention should be able to distinguish between production and test datasets. Ideally, your convention should be able to segregate the various types of datasets in your installation, datasets used primarily for online applications, those datasets used primarily for batch, etc.
Think in terms of classes of data. That is, you might have datasets used for online applications. These datasets should be allocated for the least amount of volume, channel, and control unit contention. Such datasets would constitute a class in OS/EM terms, a dataset name group.
To ensure that these dataset name groups get the processing you want them to have, volumes should be pooled. If you have volumes that have multiple physical and logical paths, these volumes should be reserved for those datasets that have critical access requirements for online datasets. By listing these volumes in a particular OS/EM volume group and designating the proper dataset name group to this volume group, you can ensure that all such datasets will be properly allocated.
If your installation has an existing dataset naming convention, determine if an adequate number of dataset name groups can be created to accomplish your allocation goals. You may find that, without too much re-working of your existing convention, you can group datasets in a satisfactory manner.
OS/EM can also be of benefit in migrating to a new dataset naming convention. You can define a couple of dataset name groups representing a subset of the new convention, establish one or two volume groups for these dataset name groups, and as you allocate datasets under the new names, they will be placed on these reserved volumes. Once volumes are free of datasets under the old names, they can then be used to establish new volume groups with dataset name groups representing another subset of the new convention. Migration can then be done in small, easy steps.
Most likely your installation already has rules concerning the use of tape devices by test jobs. These may be codified in some standards manual; or an informal set of rules, sometimes enforced by operators when there are not enough tape devices to go around. Whatever the rules, you should give some thought as to how you want to implement this OS/EM function. Remember, this function is intended primarily as a means to enforce your installation's standards concerning tape usage by test jobs. The wrong MAXTAPE value applied to a production job class would certainly not win you any friends in your operations group.
Also remember that tape devices are counted as allocation proceeds; therefore, jobs may cancel that did not cancel before (due to the job getting the devices, and possibly forcing other production jobs to wait until the devices are deallocated). You should give thought to running this function in WARN mode so that violations will be apparent to users before their jobs start canceling.
Determine which users, if any, will be allowed to submit operating system and JES2 commands in JCL. The simplest approach would be to severely limit this ability, say to a few system programmers, and RACF define resources COMMAND.* and JES2.$* only; and only permit the appropriate userids. However, if you have other requirements, just ensure that the appropriate resource definitions are in place before invoking this function.
Many OS/EM optional functions may be applied on a job class basis. This means that your installation should have a well-defined set of rules for job class usage. Any rules you develop should account for the following:
However, you should have at least one class reserved for those production jobs that consume excessive resources and single-thread such jobs through this class. We also recommend that you reserve one production class for those jobs that absolutely need to be executed when they are submitted. Such jobs would be the SMF dump job; and, if your CICS journal is on disk, the job that dumps a full disk journal to tape.
Some of the optional OS/EM control functions allow you to check that a specified job class is valid for the job. These classes must be defined to your security system using the classname FACILITY (or IBMFAC for CA-TOPSECRET) and resource JOBCLASS.x where x is the desired class. If the resource is not defined, OS/EM will by default allow access to the resource, so no Job will fail.
The optional OS/EM IEFUSI function is applied based on the weight assigned to each selection criteria type: program name, job class or job name. Before applying storage limits, determine, at the very least, your installation's use of job classes. If, for example, you start CICS as a job, you would not want to specify the CICS job class with the wrong storage limits. In this case, it would be better to specify DFHSIP as a program name and assign it to a REGION keyword with the appropriate limits.
When using SMF exit IEFU83, including the OS/EM extended function Catalog Account Control, it is possible that SVC dumps will be produced for S71A abends. These abends are normally supressed by the Catalog Address Space where they occur, but when CAS is called by IEFU83 a dump may be produced as OS/EM's SMF Controller may detect the abend. The same problem may be encountered without OS/EM as the SMF ESTAE routine IEEMB830 would then detect the abend.
IBM recommends that you set a SLIP trap in IEASLP00 in SYS1.PARMLIB to suppress the dump. An example for ABEND71A is:
SLIP SET,C=71A,ID=X71A,A=NODUMP,END
This information is documentated in IBM APAR OW13864.
To use the OS/EM support of the ISPF installation-wide exits, you must have set the EXITS keyword on the ISPMTAIL macro to YES, or by using the ISPCCONF command to change the ISPDFLTS setting 'Enable ISPF Exits'.
For detailed instructions, refer to the ISPF Planning and Customizing manual, section Tailoring ISPF Defaults.
Also be sure that you do not have a version of ISPEXITS available in a STEPLIB in any ISPF logon procedure, otherwise ISPEXITS will be loaded from the STEPLIB and not from the OS/EM load library. Any exit (and associated data area) coded in your ISPEXITS module must be defined to OS/EM via the Basic Exits function.
OS/EM is distributed as a pre-built SMP/E environment. The installation process is performed through an ISPF dialogue that guides the user to:
Additional installation steps involve setting up system environment and other related subsystems (e.g. RACF, DFSMShsm) to support OS/EM operation.
Some changes to the system PARMLIB will be required to enable OS/EM operation.
This section identifies the system requirements for installing and running OS/EM.
OS/EM is distributed via CD. This CD contains a binary distribution file named OSM0600.DIST.TERSE. As the name implies, the data is in the 'TERSED' format using the TRSMAIN utility. Users who do not have the TRSMAIN utility installed on their system can obtain it from the IBM Technical Support website:
http://techsupport.services.ibm.com/390/trsmain.html
Download the distribution file into a sequential dataset with the following attributes:
RECFM=FB,LRECL=1024,BLKSIZE=6144,SPACE=(CYL,(30,5))
The distribution dataset contains a pre-built SMP/E environment which is loaded into the pre-allocated datasets. An ISPF dialogue is provided to guide the user through the installation process (this is similar to a ServerPac installation procedure). Follow these instructions carefully to avoid errors when attepting to load the SMP/E environment.
The Installation Library contains the ISPF dialogue and JCL skeletons that are used to define and load all the OS/EM datasets. Extract the Installation Library using the following JCL:
//jobname JOB (acct info),'name',CLASS=A,MSGCLASS=X //* //UNPKDIST EXEC PGM=TRSMAIN,PARM=UNPACK //SYSPRINT DD SYSOUT=* //INFILE DD DSN=osem.dist.dataset,DISP=OLD //OUTFILE DD DSN=&&PDS,DISP=(NEW,PASS), // UNIT=SYSDA,SPACE=(CYL,(15,30,15),RLSE) //* //EXTRPREP EXEC PGM=TRSMAIN,PARM=UNPACK //SYSPRINT DD SYSOUT=* //INFILE DD DSN=&&PDS(PREP),DISP=(OLD,DELETE) //OUTFILE DD DSN=hlq.OSEM.PREP,DISP=(,CATLG,DELETE), // UNIT=SYSDA,SPACE=(27920,(20,15,15),RLSE), // VOL=SER=SYS000
Execute the Installation Dialog by entering the following TSO command:
ex 'hlq.OSEM.PREP(OS$DISK)' 'hlq.OSEM.PREP'
Ensure that dataset names specified in the above command is the same that was used in installation step 1.
The following menu will be displayed:
Figure 1. OS/EM Installation Menu
|
The pre-built OS/EM SMP/E environment is loaded by executing the selection items in the main menu in sequence.
Figure 2. OS/EM Installation Variables
|
Notes:
Subsequent installation steps will submit jobs. For each job that will be submitted, the following panel will be displayed:
Figure 3. OS/EM Installation Job Submission
|
Alter the JOB statement to meet your installation's standards and then select option 1 to submit the job. You may browse or edit the JCL prior to submission using options 2 and 3.
Important - If your installation uses multiple JES systems with different release or maintenance levels, the JES offset table must be generated on each of these systems.
Once all installation steps have been completed, terminate the dialogue by pressing PF3.
Many of the OS/EM optional functions such as the Job Class Checking, Account Number Checking, DDNAME Checking, JCL parameter checking, MVS Operating System and JES2 commands are controlled by appropriate definitions to your installation's security system (RACF, CA-TOPSECRET, or CA-ACF2). If you intend to use these functions, the proper definitions must be in place before OS/EM can enforce the use of these resources. If resource checking (RACROUTE) for a particular resource is requested by OS/EM and the resource is not defined to the installation's security system, OS/EM will by default allow the use of the requested resource if using RACF, or disallow the use of the requested resource if using ACF2.
All such definitions are done by establishing the proper resources within the class FACILITY (CA-TOPSECRET users will use class IBMFAC). Job class resources take the form JOBCLASS.x where x is the desired jobclass. Users would then be permitted to the proper jobclass. For example, if JOBCLASSCHECKING is in effect, and resource JOBCLASS.A is defined, users would have to be permitted to this resource before they could submit jobs to JOBCLASS A. READ authority is sufficient.
MVS Operating system and JES2 command submittal authority is also defined within class FACILITY (or IBMFAC). The resource takes the form COMMAND.cmd for operating system commands, and JES2.$cmd for JES2 commands.
For operating system commands, cmd is the long form of the command. For example, COMMAND.MOUNT would be specified as the resource name for establishing authority to issue MVS MOUNT commands (do not code COMMAND.M).
The commands $VS, $ADD and $TRACE must be fully designated; all other commands must be a single letter. The proper resource designation for $A for example would be JES2.$A, a generic resource for JES2 commands would be JES2.$*, this covers all JES2 commands.
To permit the user to issue any JES2 command, define the resource as JES2.* and permit the user to this resource. Read authority is sufficient.
Finally, use of the OS$CNTL command can be controlled via your security system. Again, the class is FACILITY|IBMFAC and the resource is OS$CNTL.sysid.function, where sysid is the four character SMF id of your system, and function is either ALLOC, CODE, DASD, HSM, ISPF, JES2, JES3, POOL, QUERY, RACF, RELOAD, SMF, SVC, or TSO. READ access is sufficient.
Note: The resource OS$CNTL.sysid.RACF must be defined before any RACF commands may be issued. Protection of other commands is optional.
OS/EM runs as a MVS subsystem. Therefore, the subsystem name must be defined. Edit your SYS1.PARMLIB member IEFSSNxx to add OSEM as the subsystem name. The member IEFSSN60 in the OS/EM SAMPLIB can be copied into your current IEFSSN member in SYS1.PARMLIB or copy IEFSSN60 into SYS1.PARMLIB as member IEFSSNOS and update the IEASYS member parameter SSN=(00,OS).
Notes:
SUBSYS SUBNAME(OSEM)
INITRTN(OS$IPL)
INITPARM('subs,MSG=x,SVC=nnn,SEC=yyyy,CLASS=zzzzzzzz,SMF=xx')
,SMF=(xx,yyy)')
,SMF=(,yyy)')
OSEM is the sub-system name, OS$IPL is the execution module that establishes the OS/EM environment.
The additional entries are the initialization parameters that are
The INITPARM string is passed to the subsystem initialization routine. This string contains the following parameters:
subs | The OS/EM Job Entry Subsystem to control
|
x | The message support required during OS/EM Sub-system initialization
|
nnn | The SVC number you want OS/EM to use with JES3 only. If you omit this parameter (SVC=nnn), as in the example, OS/EM starts scanning for an available SVC number and will use the first available number. The OS/EM scan starts at SVC number 255 and works backwards. |
yyyy | Defines the security system installed at your installation. You must code this operand, along with the CLASS parameter, if you intend to use any of the OS/EM functions that depend on security system definitions.
|
zzzzzzzz | Resource class for authorization checking |
xx | Suffix of SMFPRM member to be invoked after OS$IPL executes |
yyy | SMF number to use for audit records. Note: See SMF Record Format in the appendix for the format of these SMF records. |
The OSEM procedure is automatically invoked by the OS/EM subsystem initialization. This procedure initializes the OS/EM environment.
The SAMPLIB member OSEM contains a sample procedure. Copy this member into a PROCLIB pointed to by your Master Scheduler JCL and update it to reflect your dataset naming.
//OSEM PROC //OS$INIT EXEC PGM=OS$INIT,TIME=(0,15) //SYSTSPRT DD DISP=OLD,DSN=xhlq.OSEM.IPL.REPORT //SYSMDUMP DD DISP=OLD,DSN=xhlq.OSEM.DUMP //SYSTSIN DD DSN=xhlq.OSEM.PARMLIB(TIME),DISP=SHR // DD DSN=xhlq.OSEM.PARMLIB(CODEINIT),DISP=SHR // DD DSN=xhlq.OSEM.PARMLIB(JES2INIT),DISP=SHR // DD DSN=xhlq.OSEM.PARMLIB(JES3INIT),DISP=SHR // DD DSN=xhlq.OSEM.PARMLIB(MVSINIT),DISP=SHR // DD DSN=xhlq.OSEM.PARMLIB(DASDINIT),DISP=SHR // DD DSN=xhlq.OSEM.PARMLIB(DSNINIT),DISP=SHR // DD DSN=xhlq.OSEM.PARMLIB(HSMINIT),DISP=SHR // DD DSN=xhlq.OSEM.PARMLIB(JCLINIT),DISP=SHR // DD DSN=xhlq.OSEM.PARMLIB(JOBINIT),DISP=SHR // DD DSN=xhlq.OSEM.PARMLIB(JOBRINIT),DISP=SHR // DD DSN=xhlq.OSEM.PARMLIB(MISCINIT),DISP=SHR // DD DSN=xhlq.OSEM.PARMLIB(PREFINIT),DISP=SHR // DD DSN=xhlq.OSEM.PARMLIB(VOLINIT),DISP=SHR // DD DSN=xhlq.OSEM.PARMLIB(POOLINIT),DISP=SHR // DD DSN=xhlq.OSEM.PARMLIB(RACFINIT),DISP=SHR // DD DSN=xhlq.OSEM.PARMLIB(RSTRINIT),DISP=SHR // DD DSN=xhlq.OSEM.PARMLIB(SVCINIT),DISP=SHR // DD DSN=xhlq.OSEM.PARMLIB(TIMEINIT),DISP=SHR // DD DSN=xhlq.OSEM.PARMLIB(TPSHINIT),DISP=SHR // DD DSN=xhlq.OSEM.PARMLIB(QUERY),DISP=SHR //*
Ensure that 'xhlq' is set to the datset name high-level qualifier for the OS/EM executable datasets.
In this example, the SYSTSIN DD statement is a concatenation that points to the initialization members that build the OS/EM environment. This is the way in which initialization members are built by the ISPF interface.
Since OSEM runs as a started task, you must define OSEM to your security system giving it SYS1 authority. Otherwise OS/EM initialization will fail.
Perform one of the following procedures:
Notes:
Perform one of the following procedures:
Notes:
Note: The OS/EM CLIST library is shipped with LRECL=80 and RECFM=FB. Only CLIST libraries with like characteristics can be concatenated. If your CLIST libraries are RECFM=VB, it is recommended that you use the sample CLIST ICQSMC00 to copy these CLISTS to a RECFM=VB CLIST dataset. ICQSMC00 is shipped in the IBM library ICQ.ICQSAMP as a part of TSO/E.
Since you will use the ISPF interface on a regular basis, you should place an entry for the interface on an ISPF menu, preferably a menu that is not widely available to your regular ISPF users.
If you use O as the selection letter, the entry in the menu's )PROC section would be:
O,'CMD(OS$START) NOCHECK'
You will also need to add the following line at the end of the menu's )PROC section to allow users to go directly to an OS/EM sub-menu.
&NXOPT = .TRAIL
This procedure will build the initial OS/EM PARMLIB and ISPF Table library entries for your environment:
This process may take several minutes. When complete, the OS/EM Tables and Initialization members will be initialized.
Notes:
If this is a new installation, go to step 13.
The Upgrade function parses a Query Report of your current OS/EM environment to determine which exits and/or optional features you are using and stores that information in the OS/EM Version 6.0 PARMLIB and ISPF Table library.
Perform the following procedure to upgrade to OS/EM Version 6.0:
OR
The upgrade process may take several minutes. When complete, the OS/EM settings from the current environment or the saved Query Report will be migrated to the OS/EM 6.0 tables.
Notes:
Users upgrading from a prior release of OS/EM should skip to Step 15 because Step 12 copies the existing authorization codes into the new tables.
See Authorization Code, Definition and Use in the OS/EM User Guide for complete instructions.
Users upgrading from a prior release of OS/EM should skip to Step 15 because Step 12 creates the initialization member.
If you are only installing the HSM Optimizer Reports go to step 22.
See the OS/EM User Guide for complete instructions.
The OS/EM AUTOINSTALL feature (new to OS/EM Version 6.0) will process the JES2 initialization parameters and automatically place the defined user exits under OS/EM control. Therefore, there is nothing that a new user must do to implement existing JES2 exits in OS/EM.
However, since OS/EM provides centralized management of all common user exits, it makes more sense to explicitly define the user exits to OS/EM. These exits can be defined to OS/EM before or after the initial IPLs with OS/EM 6.0.
The OS/EM processing rules for JES2 exits are:
A suggested migration strategy from JES2 PARM definitions to OS/EM is:
If you are using the JES2 Pre-Initialization Exit (EXIT0) to control the start of the JES2 Initialization process, it must be Link Edited as a separate Load Module with a name other than HASPXIT0, and additional Exit Entry Points (such as EXIT19 or EXIT24, for example) should not be included. These should be assembled and Link Edited into a separate Load Module (or Modules) of their own and additionally defined to OS/EM, as appropriate.
Beginning with OS/390 Version 2 Release 4, IBM has provided a compatibility and migration aid in the form of a user Exit 5 routine. Without OS/EM, this exit is invoked automatically if you do not specify your own Exit 5. Since OS/EM enables Exit 5 this user exit will not be automatically invoked. To ensure that this exit continues to be available, you must define it to the OS/EM Basic Exits Function. The module name of this exit is HASX05C with an entry point name of HASX5CTR. Because this exit is not MVS re-entrant, you will need to code KEY: 1 on the OS/EM entry panel.
Prior versions of OS/EM required users to define OS/EM JES2 the interface module and the user exit points in the JES2 initialization parms. The OS/EM AUTOINSTALL feature (new to OS/EM Version 6.0) automatically adds the OS/EM JES2 Interface for all of the user exit points.
Users who are upgrading to OS/EM 6.0 must remove the OS/EM LOADMOD and EXIT(nnn) definitions from the JES2 initialization parms before IPLing with OSEM 6.0:
LOADMOD(OS$J2ITF) STORAGE=CSA EXIT(001) ROUTINE=EXIT1,ENABLE,TRACE=NO * * * EXIT(nnn) ROUTINE=EXITnnn,ENABLE,TRACE=NO
Important:
Failure to remove these definitions will cause OS/EM to attempt to dynamically define these exits during JES2 initialization. These definitions will fail (load module not found) and error messages will be issued, but JES2 and OS/EM initialization will continue normally.
Make the following changes to the system PARMLIB:
OS/EM Version 6 introduces significant architectural changes that affect how it is configured to OS/390 & z/OS.
Note: If the EXIT ADD statements are not removed, message CSV431I will be issued at IPL time for each entry point (Module Not Found). This will not prevent OS/EM from initializing successfully.
This step may be skipped during an upgrade of OS/EM, however you should review your ARCCMDxx member to be sure all DFHSM exits are specified.
In order to activate the HSM Optimizer functions the DFHSM ARCCMDxx parm member must be updated to enable all the DFHSM exits.
SETSYS EXITON(AD BD BE CB CD CR ED IN MD MM) SETSYS EXITON(MV M2 RD RP SA SD SK TD TE TV)
This step may be skipped during an upgrade of OS/EM, however you should review your SMFPRMxx member to be sure all SMF exits are enabled. The EXITS parameter should be specified on both the SYS and SUBSYS keywords, as the following example shows:
SYS(NOTYPE(16:19,99),EXITS(IEFACTRT,IEFUAV,IEFUJI,IEFUJP,IEFUJV,
IEFUSI,IEFUSO,IEFUTL,IEFU29,IEFU83,IEFU84,IEFU85),
INTERVAL(003030),NODETAIL)
SUBSYS(STC,EXITS(IEFACTRT,IEFUAV,IEFUJI,IEFUJP,IEFUJV,IEFUSI,
IEFUSO,IEFUTL,IEFU29,IEFU83,IEFU84,IEFU85))
This step may be skipped during an upgrade.
RACF provides three types of password authentication:
Prior to RACF release 2.1 the default authentication method was the masking algorithm. Beginning with RACF release 2.1, a two-step method of checking is the default, where RACF uses both the masking algorithm and the DES algorithm.
You must control the type of authentication used via OS/EM if you are running RACF 2.1 or above.
Note: For more information on using the ISPF Facility MVS Basic Exit Support, see the OS/EM User Guide. For more information regarding RACF Password Authentication, refer to the RACF System Programmer's Guide.
IPL the system. OS/EM will initialize with the parameters you placed in the parmlib members pointed to by the OSEM procedure.
Use the ISPF interface at any time to modify processing options and/or user exits, or to build initialization members that your installation requires.
Refer to the OS/EM Version 6.0 Users Guide initializing and creating HSM Optimizer Reports.
OS/EM is installed and maintained with SMP/E. Maintenance is distributed in the form of individual PTFs and Cumulative Service. This maintenance is applied using the standard SMP/E RECEIVE / APPLY / ACCEPT process.
In order to implement the maintenance, the affected library members must be copied from the target libraries to the executable libraries. If the maintenance affects a large number of members it may be more prudent to simply copy all of the target libraries to their executable counterparts:
PTFs that require an IPL will be indicated through the SMP/E hold data. Users should receive the HOLDDATA as well as the maintenance and the HOLDATA must not be bypassed when performing the initial APPLY.
When applying maintenance that does not require an IPL, the following procedure is recommended after the executable libraries have been updated.
Any time you apply maintenance to your JES system, you must remember to reassemble the OS/EM Offset Table. This is done by selecting option 6 in the Installation Dialogue that was provided with the OS/EM distribution. Refer to installation step 2 in the OS/EM Installation Guide.
After the JES offset table is generated, it will need to copied from the OS/EM target LINKLIB into the executable LINKLIB.
Whenever you install a new version of JES2, and this release will operate as a secondary JES subsystem, you MUST use the ISPF interface and update the JES2 version number. Select option 6 Set JES Name on the Primary Option Menu and specify the version of JES you will be using. Once this is updated, select option 8 Build Initialization Member and select the following items:
Note: This process should be done before you IPL with your new JES2 system or unpredictable results may occur requiring another IPL or a restart of JES2.
Note: This process is only relevant for secondary JES2 subsystems. The JES2 release information, if specified, is ignored for the primary JES subsystem and the release information is determined from the JES2 system during OS/EM initialization.
The success of this manual depends solely on its usefulness to you. To ensure such usefulness, we solicit your comments concerning the clarity, accuracy, completeness, and organization of this manual. Please enter your comments below and mail this form to the address on the front page of this manual. If you wish a reply, give your name, company, and mailing address. We would also appreciate an indication of your occupation and how you use this manual.
Please rate this manual on the following points: