1 Bayshore Advisor, Autumn 2005

Transcription

1

2 1

3 2

4 3 Critical Recent IBM APARs for zos, DB2 and CICS z/os The recovery routine within module IXCL1RS did not properly handle the error. This affects any data center using any type of couple data set. OA09993 (DFSMS for z/os 1.5 and 1.6) Increasing SMS Space Usage in Subpool 230. SMS message buffers containing message IGD17239I are not freed after the SSSA11 EOV synchonization function has completed. The SMS space usage in subpool 230 gradually increases until the address space runs out of space. This is due to SMS not freeing the message cell pools created for the message. FUCNTIONLOSS. OA10351 (z/os 1.4 and higher) WAIT0A2 RSN09C Due to Improper Recovery in IXCL1RS After VSM Error. A WAIT0A2 RSN9C error may occur following a VSM abend while building a channel program for a read request for a couple data set. An unexpected error during the GETMAIN of a CCW buffer by IXCL1IOP results in an abend S00C-124 and then a wait WAIT0A2-9C. 0A10761 (z/os 1.4 and higher) PAV Alias Movement does not occur on some devices if the system has been IPLed for at least 50 days. On systems with WLM Dynamic Alias management enabled, some devices may not be receiving additional PAV alias even though there is significant queue delay. This problem can occur anytime after the RRPATOD field wraps, which is approximately 50 days and 21 hours after an IPL. SMP type 99 trace records 996 or 988 will show the device is a candidate for additional aliases, but the move is stopped because SRM believes the one minute time limit between alias moves has not yet expired. A local fix for the device is to vary it online and then offline. This will reset the time of the last alias move and allow SRM to add aliases for the device. FUNCTIONLOSS. OA10881 (z/os 1.4 and higher) Message IXL008I on D/T 2084 attempting to gain connectivity after a CF Model Number change. The z990 and z890 processors have the ability to upgrade their CPU models concurrently. This causes the model number in the hardware node descriptor to change. A coupling facility running on one of these processors where the model number changed due to a capacity upgrade will not be able to re-connect due to a node desciptor comparison failure. This will cause z/os to issue

5 4 MSGIXL008I indicating that the coupling facility links have been invalidated. This problem will affect users who are running in a Parallel Sysplex configuration with one or more coupling facilities residing on z990 (2084) or z890 (2064) processors. Flagged as IPL, FUNCTIONLOSS, PERVASIVE SYSPLXDS. OA11161 (z/os ) When Multiple ROUTE *ALLs are issued the Responses are Delayed. When issuing multiple multisystem ROUTE commands, the second and subsequent commands are delayed. Message IEE421I may be received to indicate that no response was received from some systems. When the command response of the routed command is issued there is a POST to indicate to the ROUTE processor that at least one message has been issued by this system for the command. The POST only occurs on the system where the ROUTE command was issued. The other systems are waiting for the ROUTTIME to expire before continuing. The other systems are waiting for the ROUTTIME to expire before continuing. A local fix is to issue ROUTE commands with a T=0 parameter. This affects all users running in a sysplex that issue multiple multi-system ROUTE commands at the same time. FUNCTIONLOSS SYSPLXDS. OA11307 (z/os 1.4 and higher) Allocation Slowdown Due to loop in IEFAB482. Slow performance may occur during tape allocation processing when a job allocates a large number of tape devices combined with a large volume count request on one or more of those devices. This happens because the allocation routines generate an excessive number of CTRACE records in some allocation situations. A local fix is to reduce the volume count specified. PERFORMANCE, PERVASIVE. OA11432 (DFSMS for z/os 1.3 and higher) Master Catalog Volume left reserved after Import of User Catalog. After an IMPORT of a user catalog is performed, an ENQ for the SYSIGGV2 resource may be left outstanding. This can affect subsequent operations because it is the resource name used for the Master Catalog. During the process of moving a catalog from one volume to another via the EXPORT TEMPORARY and IMPORT, the volume containing the master catalog of the host system was left reserved after the IMPORT completed. The volume also contained master catalogs for other systems in the data center and the outstanding reserve on the volume prevented access from the other systems resulting in errors IOS071I START PENDING and IOS431I DEVICE RESERVED on those systems. FUNCTIONLOSS, PERFORMANCE. OA09649 (z/os 1.4 and higher) An installation may find fewer CPUs online after system initialization than in the prior IPL. During system initialization, module IEEVCPUT configures processors as needed to achieve the initial number of configured CPUs as defined for the logical partition. A mechanism is needed to bypass this processing. This APAR adds a new PRESCPU parameter for the IEASYSx member of SYS1.PARMLIB. Support is also provided to recognized this parameter and to cause IEEVCPUT to bring logically online all CPUs (and only those CPUs) that appear as physically online, when PRESCPU is coded. ATTENTION, NEW FUNCTION. The following RedAlert was issued on 26 July. (RedAlerts point you to especially important APARs and are kept to a minimum - the last one was in February.) You can sign up for RedAlert s at com/server/redalerts.

6 5 Users of Hierarchical File System (HFS) on z/os 1.4 through 1.7 "Users of Hierarchical File System (HFS) on z/os 1.4 through 1.7 may experience a hang with HFS holding the MOUNT latch and/or a VFS latch after a Cancel of a HFS Directory Search operation. Please see OA11041 for details. The only possible recovery action is to IPL. Please install the applicable PTF for DFSMS releases 1G0, 1H0, or 1J0 to prevent the problem." DB2 OA03194 can cause DB2 to hang or have severe performance degradation. OA03194 changes the limit for the number of SRBs that XES schedules for an exploiter address space. The new limit is one less than the number of processors active in MVS. This change can negatively impact DB2 IRLM notify and contention exits, which can cause DB2 to hang. Review OA12848 for a more detailed explanation and a workaround. APAR II10817 This is an information APAR that documents problems in storage leaks in DB2. It lists the DB2 R610 R710 R810 and IRLM R101 and R220 storage usage errors. These problems can cause DB2 outages and should be checked on a regular basis. CICS CICS 2.2 PQ90873: DB2 REQUEST UNDER THE L8 TCB, AND SUBSEQUENT ABEND CAUSE THE L8 TCB TO BE USED INSTEAD OF QR, THIS LEADS TO A SET LOGON HOLD CICS hangs. From an MVS perspective, the QR TCB is in an 0A01 wait out of DFHDSDS3. CICS 2.3 PQ90873: DB2 REQUEST UNDER THE L8 TCB, AND SUBSEQUENT ABEND CAUSE THE L8 TCB TO BE USED INSTEAD OF QR, THIS LEADS TO A SET LOGON HOLD CICS hangs. From an MVS perspective, the QR TCB is in an 0A01 wait out of DFHDSDS3. PQ88234: DFHSM0133 CICS SHORT ON STORAGE ABOVE 16M LINE. ECDSA SUBPOOL USXDPOOL USA_XMTRAN_SPTOKEN DFHUSXM USXM DFHICP START Storage creep in ECDSA, ophaned storage left by DFHICP.

7 6 IBM Recent Statements of Direction These are the published IBM statements of direction for z/os 1.7. The following Statements of Direction apply to releases beyond z/os 1.7. The zseries File System(zFS) will become the strategic file system for z/os UNIX files. Although HFS(Hierarchical File System) data sets will still be supported, those functions have been stabilized. This means that future enhancements and features will be added for zfs data sets, but probably not for HFS datasets. Support for the ISAM access method will be removed. Attempts to open an ISAM data set will cause an open failure. JES2 will no longer support compatibility mode which allowed JES2 to operate using a z/os 1.2 format checkpoint data set. This was designed so that users could start JES2 with an older format of the checkpoint data set and then enter the JES2 activate command to dynamically convert it to the newer format. If you have not already done this, then you will need to issue the $ACTIVATE command before migrating to z/os 1.7 or you will need to use the spool offload/reload functions to transfer jobs and output to the new JES2 system. Support will be dropped for VSAM attributes IMBED, REPLICATE, and KEYRANGE. These attributes currently provide worse performance and waste space and they should be removed as soon as possible. After z/os 1.7 the Integrated Security Services element will no longer include the Firewall Technology component. The following functions will be dropped: FTP Proxy services Socks V4 services Network Address Translation RealAudio support. Some of these functions are being replaced by improved functions in the Communications Server component. Support will be dropped for the JOBCAT and STEPCAT JCL DD statements. Any job that attempts to use these statements to access private catalogs will be failed. A feature is available in z/os 1.5 and z/os 1.6 that will allow you to detect the use of these statements, and to even cause these jobs to fail if you choose. The OS/390 V2.10 C/C++ compiler will no longer be supported. Starting with z/os 1.2 both this compiler and the ISO C/C++ compiler has been provided. But the OS/390 V2.10 C/C++ compiler was only intended as a migration aid to the ISO C/C++ compiler, and so it will not be supported after z/os 1.6 Support for 1 byte Console IDs and external interfaces supporting migration console IDs will be dropped. This will cause errors if you try to use a 1 byte Console ID in an operation command or with the WTO, WTOR, and MCSOPER macros. Programs that were compiled with the older versions of these macros will continue to work, although errors will occur the next time you try to compile them without changing the macro format. After z/os 1.7 support will be dropped from the z/os communications server for ASSORTEDPARMS statement in the configuration profile block definition KEEPALIVEOPTIONS statement in the configuration profile block definition. PAGTSNMP subagent. Defining Enterprise Extender Tranmission Groups (TG) will multiple service Access Point (SAP) addresses. AnyNet definitions. After z/os 1.7, all support will be dropped for console messages with 1 byte console IDs. The entire list of the IBM Statement of Direction is available at

8 7 Featured Article SYSDA and the use of ESOTERIC names and EDT By Martha Hall, Bayshore Senior Consultant This article will discuss the use of Esoteric names for device allocation and how to generate them using the EDT (Eligible Device Table). The UNIT parameter in the JCL identifies the device or type of device on which a dataset will be allocated. You can use an Esoteric name or a Generic name or a device number in order to map the allocation to a volume or a pool of volumes. Historically, in the west, before SMS we have used Esoteric names to specify pools of DASD for allocation. We should first define several terms. A Generic name is a name generated by MVS when it finds devices that have similar characteristics. An example is In your JCL you would code UNIT=3390. An Esoteric name is a logical name given to a group of devices that can include devices of different Generic device types. This means that I could have an Esoteric name that contained 3380 and 3390 devices. All of the devices specified to an Esoteric name must however be of the same device class, with one exception. You can, in fact, have an Esoteric group that contains both DASD and TAPE classes. So we can see that Esoteric names are installation defined grouping of IO devices. Devices belong to one of the following classes: CTC adapters DASD devices Display devices Tape devices Unit record devices like printers Communication devices Since it is sometimes desirable to segregate groups of devices or pools as they are commonly called, Western data centers will usually use an Esoteric name rather than a unit name or a generic name for allocation. As an example I could have a pool or Esoteric called IMSTST which is an Esoteric group name for three 3390 devices (device numbers 284, 394, 494). I could have another pool called IMSDEV that contains five 3390 devices (device numbers 183, 283, 383, 583, and 583). In my JCL, I can then specify UNIT=IMSDEV or UNIT=IMSTST as my job requires. This will separate the data allocations for IMSTST and IMSDEV. I could also have JES2 exits to enforce these allocations, which is also commonly done in the west. SYSDA is a commonly used Esoteric name and is frequently used in JCL delivered by both IBM and third-party vendors. It is therefore recommended that you define your complete DASD pool as SYSDA. This will avoid potential JCL or dynamic allocation errors when using vendor supplied routines. The following chart clarifies the definitions: The eligible device table (EDT) is an installation-defined and named list of the I/O devices that are eligible for allocation. The Esoteric names and the associated pools or ranges of

9 8 DASD are defined in this table. The EDT specification is contained with the Operating System Configuration in the HCD or Hardware Configuration Definition. The EDT is a list of devices and the associated Esoteric name for each range of devices. In order to view the EDT for a particular Operating System Configuration in the HCD, you select the Operating System and then you will see the Actions on Selected Operating Systems panel. The panel ID is CBDPOSFX. Select Option 5 to work with EDTs. From this panel you can add a new EDT by using the PF11 key to add a new EDT (CBDPED10). After creating the EDT identifier and specifying the MVS Configuration ID, press enter to display the EDT list panel (CBDPEDF0). From the EDT list panel, select the ID of the new EDT you have created and you will see the Actions on selected EDTs panel. (CBDPEDFX). From this panel, select Item 4 Work with Esoterics and press the enter key. You should see the Esoteric list panel (CBDPESF0). Use PF11 to add a new Esoteric. Next you will see the ADD Esoteric panel. Enter the Esoteric name that you wish to add. In our example we will use IMSTST as our Esoteric name. Specify NO for VIO eligible, and null/blank for Token name and hit enter. At this point the Esoteric name has been defined, and now you can associate a specific volume or volumes with that Esoteric name. Under the Operating System you are working on, select the device you wish to include in the group. From the device definition panel (CBDPDVOS), hit enter and you should see the Define device parameters and features panel (CBDPDV13). Hit enter and you should be taken to the Assign/Unassign Device to Esoteric panel (CBDPDV16). In this panel, add the EDT ID.ESOTERIC name for example 0M.IMSTST assigned YES. If you do not want to assign a group of devices, you can limit the range by specifying a starting number and the number of devices. If you omit the number of devices, then 1 is assumed. Using HCD, you define EDT information in an IODF. At IPL or dynamic configuration, information in the IODF and UIMs is used to build the EDT. When you create the LOADxx member, you specify an IODF statement to identify the I/O configuration definition for IPL. The IODF statement contains the name of the production IODF and identifier of the EDT and operating system configuration that is used to IPL the system. The IODF identified becomes the active IODF for the system. An example of this statement in the LOADxx member follows: IODF 0M y xx hiqualif configid In this example the new EDT member we created is suffix 0M. We put the new EDT member suffix in columns 31 and 32. If you do not specify an EDT member, the default is 00. Some additional notes are needed to clarify what value is being used as your default unit. For installations using SMS, use ISMF. First chose option 8 and then chose option 1 Display the Base Configuration. You can see a default unit. This can easily be changed if you chose a new value by using Option 3 Alter. Then perform a Validate and then an Activate and you have a new default value. An SMS value will take precedence over some of the values coded in the ALLOCxx member of Parmlib. So obviously, the other place where the default unit might be specified is the ALLOCxx member of Parmlib. You may see a UNIT value here. The default value for UNIT in the ALLOCxx member of Parmlib is SYSALLDA.

10 9 Featured Article Are Your MVS & JES2 Commands Safe? By James Smith, Bayshore senior consultant z/os and JES commands (console commands is a common term) are used to control system operations in a z/os environment. When these commands are not secure and are wrongly used then disaster can strike. System operators are normally responsible for entering system commands. This is their primary responsibility. However, often other members of the system support staff need access to monitoring commands. Who has access to these commands in your installation? Many of these commands are sensitive and potentially disruptive: Some of the sensitive operations functions that can be performed include: halt the system place processor, real storage, and channel paths offline cancel jobs, mount requests and TSO sessions terminate critical network connections Some of the sensitive functions that can be performed which impact security include: Using an unauthorized version of the PROGxx parameter member which allow different APF libraries to be defined to the system. You can now sneak modules into an authorized state. It s like letting a known virus loose on your PC. Dynamically change SMF parameters delete potential system audit records. set a SLIP which can be used to disclose a password stop the system log All of the above functions expose the integrity of your system. In the early years of MVS, console commands could only be issued through one of the MVS consoles, which were directly connected to the system. The MVS console allows MVS and JES commands to be executed without requiring a user to logon to the system. Starting with MVS release 3.1.3, console operators can be required to logon to the MVS consoles by specifying the LOGON(REQUIRED) parameter within the CONSOLxx PARMLIB member. This is a common practice in the west, but not in China. Should you reconsider your position on this matter? Be warned however that the system console does not timeout after a specified period of inactivity. Therefore, unless each operator logs off the MVS console after each time they issue a console command, operators will share the same ID. This would not provide any accountability for each operator's individual actions. Also the identity of the user issuing the command is not tagged in the SYSLOG when the message is written. However, enabling the logon security for MVS console would at least allow an installation to restrict those console commands which are not the function of a system operator. Other MVS facilities and system software products which provide for the issuance of console commands include: Batch Submission JES2 allows jobs to issue MVS and JES commands through the various submission facilities, which include internal reader, card readers, STC readers, and TSO readers. Each of these facilities is assigned parameters which either allow or not allow JES and MVS commands (i.e., system commands) to be defined for execution within specific jobs being submitted. Do you need to have MVS commands imbedded in JCL? If not then you should set COMMAND= IGNORE in the JES2 JOBCLASS definition to prevent unauthorized use. System Display and Search Facility (SDSF)

11 10 SDSF is an IBM product which interfaces with the MVS spool and provides a tool for analyzing and controlling JES2. SDSF, which is executed from a TSO session allows users (i.e., besides operators) to control the manner in which jobs are executed and printed and alleviates the tasks required to be performed by the operator. SDSF has the ability to issue any MVS command except for those commands that are restricted to the master MVS console, such as CONFIG, CONTROL, DUMP, FORCE, TRACE, and VARY. It is critical to implement RACF security within SDSF, but this is not yet a common practice in China. Traditionally SDSF is customized to restrict who can issue commands, which can control JES2 resources, and who can look at sensitive output. There is a wealth of security functions available in SDSF and we feel they should be used to protect the availability of your system. Protecting your MVS and JES2 commands now may save you from a disaster in the future. Security Access Facility (SAF) Use the SAF interface to restrict access to MVS and JES commands. This is achieved via the OPERCMDS Resource Class to define the individual MVS and JES commands which are to be protected. Console commands can be protected and individuals permitted access at the commands first operand using masking characters. Also, security can be administered at the complete command level with all of its operands. Controlling Operator Commands To control the use of operator commands, create profiles in the appropriate RACF classes that enable RACF command authorization. The specific RACF classes that you must activate depend on the input source that you want to protect. The following table lists the RACF classes that must be activated for each input source. Example of Controlling Who Can Issue MVS Commands The following example shows how to use the OPERCMDS class to control who can display and cancel jobs in your installation. Suppose you want to let anyone display jobs but you want to restrict the task of cancelling jobs to a group of MVS operators. All of the MVS operators you want to authorize have RACF-defined user IDs connected to a group called OPERGRP. According to z/os MVS Planning: Operations, to authorize a user to issue the MVS DISPLAY JOBS command, you must give the user READ access to a resource named MVS.DISPLAY.JOB in the OPERCMDS class. To authorize a user to issue the MVS CANCEL command for all jobs, you must give the user UPDATE access to a resource named MVS.CANCEL.JOB. ** In the OPERCMDS class. To grant these authorizations, enter: SETROPTS GENERIC(OPERCMDS) REFRESH RDEFINE OPERCMDS MVS.DISPLAY.JOB UACC(READ) RDEFINE OPERCMDS MVS.CANCEL.JOB.** UACC(NONE) PERMIT MVS.CANCEL.JOB.** CLASS(OPERCMDS) ID(OPERGRP) ACCESS(UPDATE) SETROPTS CLASSACT(OPERCMDS) SETROPTS RACLIST(OPERCMDS) REFRESH SETROPTS GENERIC(OPERCMDS) REFRESH Now, anyone can display a job, but only the operators in OPERGRP can cancel a job We would like to see that data centers use the functions your system provides to protect YOUR resources.

12 11 IBM z/os Software Product End of Service Dates Version and Withdrawn from Service Announce Date Availability Date Release Marketing Discontinued /07/ /09/ /09* 2008/09* /08/ /09/ /09/ /09* /02/ /03/ /09/ /03/31* /08/ /09/ /09/ /03/ /02/ /03/ /09/ /03/ /09/ /10/ /03/ /10/ /10/ /03/ /06/ /03/31 *Indicates IBM Projected date. Actual end of marketing or end of service date has not been announced yet. IBM DB2 Software Product End of Service Dates Version and End of Marketing End of Service OS/Platform Program ID Release date date 8 z/os 5625-DB2 * * 7 OS/390, z/os 5675-DB2 * * 6 OS/ DB2 2002/06/ /06/05 5 OS/ DB2 2001/12/ /12/31 4 MVS/ESA 5695-DB2 2000/12/ /12/31 3 MVS 5685-DB2 2000/02/ /01/31 *Indicates IBM Projected date. Actual end of marketing or end of service date has not been announced yet. IBM CICS Software Product End of Service Dates Product Name Version/Release Availability End of Service Date Date CICS Transaction Server for OS/390 V /09/ /04/30 CICS Transaction Server for z/os V /01/25 * CICS Transaction Server for z/os V /12/19 * CICS Transaction Server for z/os V /03/25 * *Indicates IBM Projected date. Actual end of marketing or end of service date has not been announced yet. Version/ Release IBM IMS Software Product End of Service Dates OS/Platform Program ID General Availability Date End Of Marketing Date End of Service Date 6.1 MVS/ESA /12/ /09/ /09/ OS/ B /09/ /09/ /11/ OS/390, z/os 5655-J /10/27 * * 8.1 OS/390, z/os 5655-C /09/02 * * *Indicates IBM Projected date. Actual end of marketing or end of service date has not been announced yet.

13 12 New IBM Redbooks SG DFSMSrmm Installation and Implementation Primer SG Technical Introduction IBM eserver zseries 800 SG Effective zseries Performance Monitoring Using Resource Measurement Facility (RMF) SG IBM System z9 109 Technical Introduction SG z/os V1R6 DFSMS Technical Guide The URL for the redbooks is Draft Redbooks SG z/os Basics (Formal Publication 09/2005) New IBM Washington System Center Technical Flashes FLASH10369 Setting OSA SNA Parameters for Best Performance; what SNA parameters should be used when you are configuring the OSA Express and OSA Express2 facilities. This flash gives several recommendations to improve performance. For the Washington Systems Center flashes, the address is: Bayshore Consulting & Services Co., Ltd Rm 209, Zhongchen Building, No.1, Lize Zhong Er Lu, Chaoyang District, Beijing, China, Tel: (010) Fax: (010)

14 13