2 bayshore advisor, issue no. 3, march 1 · worldwide many customers are already installing z/os...

2 Bayshore Advisor, Issue No. 3, March 1st, 2006

2


3

News: z/OS Announcements Well it looks as if the Year 2007 is set to be a busy year with so many releases of z/OS reaching ‘end of service’. The following tables provide the announcement, general availability, end of marketing, and end of service dates for z/OS releases as announced by IBM.

z/OS Program Number VRM Announced Available Marketing

Withdrawn Service

Discontinued5694-A01 1.07.0 2005/07/27 2005/09/30 2006/09* 2008/09*

5694-A01 1.06.0 2004/08/10 2004/09/24 2005/10/24 2007/09*

5694-A01 1.05.0 2004/02/10 2004/03/26 2004/09/09 2007/03/31*

5694-A01 1.04.0 2002/08/13 2002/09/27 2004/09/09 2007/03/31

5694-A01 1.03.0 2002/02/19 2002/03/29 2002/09/12 2005/03/31

5694-A01 1.02.0 2001/09/11 2001/01/26 2002/03/14 2004/10/31

5694-A01 1.01.0 2000/10/03 2001/03/20 2001/10/11 2004/03/31

* Indicates anticipated date. Actual end of marketing or end of service dates yet to be announced.

Worldwide many customers are already installing z/OS V1.7 whilst others are planning for z/OS V1.8 (yet to be announced). We encourage you to move to z/OS V1.7 now! If you're on z/OS V1.4, z/OS V1.7 is the last release you can migrate to in a single step. If you are interested in migrating to z/OS V1.7 and need more information then please contact us and we can help you plan for the future.


Opening Up The Mainframe By Eric Knorr

redictions in the 90s that we'd soon see the last of the mainframes were

quite clearly way off and, far from their demise, today's estimates indicate that - 40 years on - mainframes host most business transactions and enterprise data, writes Eric Knorr. IBM, which now enjoys a virtual monopoly on big iron, sold $US6.8 billion's worth in 2003, a year that saw sales of IBM zSeries mainframes (whose top-end models go by the nickname T-Rex) jump 33 percent. Why do dinosaurs thrive even when their MIPS, memory, and storage cost magnitudes more than those of Unix or Windows servers? Decades of capital investment, monumental reliability, and mind-blowing switching costs are the usual explanations. But the most compelling reason of all is mainframe applications, most written in COBOL or PL/I, have amassed enormous business value. Brian Safron, program manager of enterprise transformation at IBM, likes to talk about the "incredible depth of business knowledge" embedded in mainframe applications. "When you try to reproduce [on another platform] an application that has captured 10 or 15 or

even five years of business logic ... you're going to go through several years of pain just to get the [new] application back up to the point where it was," Safron says. “Rather than retire big iron, enterprises seem more intent than ever on disseminating the core business value that Safron extols to a wider audience -- and a wave of new legacy integration technologies has arrived to do just that. Today, as companies draw up plans for SOAs (service-oriented architectures) that treat applications as reusable services, mainframes promise to play a central role. But the key is in selecting the right integration tools for exposing mainframe-derived services. That selection is no easy task, according to Jake Freivald, marketing director at integration software provider iWay. "Most vendors have a particular view of things because they do a certain type of thing really well and they don't do the other things very well. And that's a real problem," Freivald warns. "People don't understand the range of options that are open to them due to vendor hype." Going through the front door One of the least-hyped options is also the quickest and easiest to implement: deploying

software that emulates a 3270 mainframe terminal and rolls mainframe apps into Web apps. The most primitive variant, where the software scrapes 3270 green screens and pops them into the browser, has been around since the mid-90s. But new tools from companies such as WRQ and NetManage are taking this approach to a new level. Benoit Lheureux, a Gartner research director, notes that the terminal emulation approach is mostly foolproof. "It doesn't matter how old the application is," Lheureux says. "If there's a 3270 stream, you can tap into it and use it for input and output." In addition, he says, it's non intrusive: mainframe personnel don't need to be involved in development, and all the business rules baked into the mainframe application that protect the database remain in effect. The downsides are performance limitations and "brittleness" -- if a mainframe app changes without warning, any apps that depend on the 3270 connection break. WRQ's Verastream product is an example of how sophisticated the terminal-emulation approach can get. Robert Vettor, senior business technologist at Raytheon, says he used Verastream to consolidate "a fairly ugly mainframe screen set that was about 25 years old" into a Web app that tracked arriving

4


5

shipments inside the company. Previously, users needed to wade through about 20 green screens. Now, "The users stay on one page the whole time," Vettor says. To avoid security risks, with each user session, the Verastream server fires off generic log-ons that provide access to only those screens necessary for the tracking app. Vettor particularly likes being able to publish the app as a Web service on the Verastream server. Although one developer could easily build the front end of the tracking app on Microsoft's .Net, another could build a Java app to consume the same Web service. In other words, Vettor has brought a simple mainframe function into Raytheon's emerging SOA, enabling the tracking application to roll out across the entire company in the coming months. "It worked out for us politically," Vettor says of the project. "It was a quicker way to get it done than trying to work through the mainframe group." At a health insurance provider, director of presentation application systems Bry Curry recounts a similar experience using NetManage's Web-to-Host emulation product. Customer service reps running PCs needed a quick way to access mainframe data about health plan members when they called. A CRM system was considered, but that would have required migrating member data to the CRM database, creating two data stores rather than one. "We have 30 years of systems that are very efficient and are basically mission-critical systems," Curry says. "Why would we dump that data to

Web servers and replicate all the business rules?" Instead, Curry chose NetManage Web-to-Host to re-arrange mainframe screens into a pleasant, browser-based app. "I think what distinguishes this application from many others is while it's very sophisticated, 90 percent of what we did was navigation logic, not business logic," Curry, who was able to deploy six months after design approval, says. That development cycle included a bit of mainframe developer time to tweak application performance, because calling up customer records within five to 10 seconds was critical. But the result was a working app that satisfied almost everyone. Talking to the transaction layer Although terminal emulation solutions may go as far as exposing 3270 streams as Web services, they're primarily designed for human interaction through a browser. Communication between mainframe and other server-side applications requires integration at the API level. Mainframes are basically huge transaction engines, so other apps typically integrate with legacy CICS (Customer Information Control System) or IMS/TM (Information Management System/Transaction Monitor) transaction processing applications. Lheureux sees a clear trend among enterprises toward transaction-level legacy integration. "When there's an opportunity to actually use an API ... rather than doing screen-scraping, they'll do that in a

heartbeat," he says. "The mainframe is being surrounded by all these J2EE and Windows and Linux servers, so there are many new opportunities to come in through an adapter and get a higher-performance interface." Major middleware players -- BEA Systems, IBM, Iona Technologies, SeeBeyond Technology, Software AG, Sonic Software, Tibco Software, Vitria Technology, and WebMethods -- have long claimed to offer interoperability with mainframe transaction systems. But most obtain their legacy application adapters through partnerships with such specialized vendors as Attunity, DataDirect, iWay, or Neon. Application adapters typically have two halves: one that runs on a J2EE or Windows server and one that runs on the mainframe to handle the "nasty business of accessing stuff on the back end", as Lheureux puts it. Today, most application adapters are bi-directional. "Everybody thinks in terms mostly of something happening in the external world coming into the mainframe" and triggering a transaction, Lheureux says. But mainframes also need the ability to push events out to other enterprise systems. For example, when someone enters an order into the mainframe via a 3270 terminal interface, an ERP package running on a Unix box can be updated immediately rather than waiting for a batch update. Before the latest bi-directional application adapters arrived, the only product available to provide this two-way functionality was IBM's MQSeries middleware. But iWay's Freivald warns that


6

too many customers assume that legacy integration is done just because they have MQSeries running on the mainframe. "It's a failure to understand the nature of the problem," Freivald says. "At a minimum, once you connect to the mainframe, you're still going to need something that gets the information off the message queue, talks to the application, handles any errors, reformats the data, and puts it back in the queue. Having messaging middleware (such as MQSeries) is not nearly enough." Productive legacy application integration, he argues, requires configurable, bi-directional application adapters. IBM sells its own CICS Transaction Gateway, a JCA (Java Connector Architecture) adapter for connecting mainframes with J2EE application servers. The beauty of using adapters to bridge mainframes and application servers, says IBM's Safron, is that enterprises can "keep the functionality with all that inherent subtlety that was captured, keep those business rules intact, but play in an object-oriented world." But to fully reap the benefits of connecting Java and mainframe apps, Safron says, customers may need to rewrite the COBOL code. Rather than calling it with connectors, the COBOL code can be seamlessly incorporated into the workflow with Java applications. "You're going to make changes that are appropriate to that traditional code that will make it the most ready to be part of a true e-business, on-demand workflow, still using the CICS or IMS

runtime engine." This involves refactoring COBOL apps so they can be addressed by Java components as discrete pieces of business functionality. Safron calls this a "mixed-workload" environment and says that IBM is working on a new development framework. Meanwhile, developers can run IBM's WebSphere Studio Asset Analyzer for Multiplatforms to help determine how "e-business ready" a COBOL or PL/I application is and to determine whether rewriting it and isolating its business components are worth the effort. Digging into databases Few businesses have the resources or the inclination to invest in refactoring COBOL code. In fact, it's fairly common for organizations to avoid the complexity of legacy application integration entirely and instead go straight to the mainframe database using a database adapter. Going direct to the database, however, raises the spectre of potential database corruption. "The risk of coming in at the data layer is that you're bypassing application logic," Gartner's Lheureux says. "And that's a real risk to the degree that, at the end of the day, the application logic is the keeper of the truth." No surprise, then, that "integration" with mainframe databases tends to be read-only -- typically ETL (extraction, transformation, and loading) operations that copy huge chunks out of the mainframe database for such applications as data mining.

"Data-level integration is easiest on applications that are not that complex," iWay's Freivald says, provided a database adapter can insulate developers from having to understand the variations among mainframe databases. "The more a developer has to know about those different interfaces ... the harder it is to be productive," he says. "DB2 is very good and standard. But VSAM (Virtual Storage Access Method) files are a completely different set of calls that you can only do if you're a COBOL programmer, basically." Good middleware, Freivald says, should rationalize those different data structures into a familiar form, such as SQL or XML. Of course, the mainframe guys monitor such interactions very carefully. For example, Lheureux says, "I don't think any serious designer would think about slamming a purchase order into an order entry system by going straight to the database." Freivald recounts a horror story at one company where business analysts were allowed to make changes to the database. The company was never able to repair the damage and was forced to outsource its entire mainframe operation. Inviting mainframes to the party No contradiction exists between guarding mainframe database integrity and making mainframe power more available to the enterprise at large. In fact, most analysts say that the trend is to expose mainframe applications and data stores as a set of services in a SOA. The most


7

intriguing scenario takes advantage of the mainframe's power as a huge transaction engine to generate events that affect other systems in the enterprise. Bill Ruh, chief technology officer and senior vice president at Software AG, cites Delta Air Lines as an example of an organization with an event-driven, mainframe-intensive environment (known as the Delta Nervous System). "When a plane has a maintenance delay, there are a bunch of

things that happen as result," Ruh says. One event triggers others across the nervous system. As mainframes push more events onto enterprise service buses, Ruh believes that one result will be a next-generation SOA that extends beyond the current messaging model. "It's going to be an event-driven model, where a transaction comes in or data comes out and some event triggers that," Ruh says. "The world is moving toward real time."

At its heart, the mainframe has always been a real-time transaction engine. Whether the network talks to big iron via terminal emulation, application integration middleware, or database connectors, the real legacy may be that mainframes have a greater effect on distributed computing than Web apps and SOAs will have on those durable, refrigerator-sized boxes.

Don’t Outsource Your Thinking Mainframe Viability In 10 Years?

here will the mainframe be in 10 years? If z/OS is your lifeline,

your risk assessment should adequately consider this point. Since one of my clients estimates it would take them eight years to migrate from zSeries to another platform, they recently engaged me to analyze mainframe viability through 2015. Mainframe viability has been questioned for years because certain things have been shrinking, such as the number of customers, people with mainframe skills, and number

of ISVs. But a viability analysis must contrast this with strong vital signs such as the technology advantages over alleged alternatives and growing customer dependencies on z/OS. The biggest threat would be if IBM decided to pull the plug on the mainframe, but that’s extremely unlikely for a product that’s so well-positioned for the future. Let me explain. Today we see signs that the utility computing movement is gaining traction. The primary goal for a utility is for users and application developers to access whatever info they

need and get computing capacity wherever they need it without having to know the physical location of the resources involved. Since an IT utility is where heterogeneous resources will be organized and managed as pools of resources, then application longevity through infrastructure “rust out” will no longer be a concern because virtualization also allows applications to be de-coupled from the physical limitations that once threatened their longevity. Infrastructure simplification through increased consolidation and centralization of scattered


servers is mandatory to minimize cost. Clusters, blades, and multiprocessor Servers are the hardware benefactors of these trends. Those who are weary and wary of self-destructing, virus-infested PCs will eagerly embrace an affordable and service-oriented computing utility that’s self-optimizing, self-healing, self-protecting, and self-configuring. Over the next 10 years, the mainframe, specifically the new System z9-109 family, will continue to leverage its extensive virtualization architecture combined with a number of very sophisticated hardware optimization techniques to provide significant economies of scale. In 2015, expect the majority of the world’s largest IT organizations to still be leveraging z/OS with its security, availability, and so on, supplemented with z/VM and Linux virtual servers as the hub of their computing utility. Though mainframe customers have several areas of legitimate concern, none of the mainframe’s pain points are life-threatening. The top three complaints are high cost, a shrinking skills base, and lack of applications. Customers indeed pay a premium price to use the industry’s premier server. IBM’s pricing model is broken, especially for software. Sub-capacity pricing and specialty application processors (e.g., zAAP) are certainly two steps in the right direction. Yes, some ISVs charge outrageous license fees

and many small-to-medium-size businesses will find mainframe entry costs prohibitively high, but the utility model will lessen these pain points, too. Emerging utilities will discover that when people costs are accurately assessed, the mainframe offers the lowest cost per user, similar to how jumbo jets become economical when passenger loads are high. It’s no secret that people with mainframe skills are a shrinking population. For example, one shop with 60 people in their mainframe group will lose half to retirement during the next five years. IBM is also responding to long term, skills-building concerns by signing up more than 200 professors and 150 universities worldwide to equip students with mainframe skills, and simplifying many of its operations tasks through its Health Checker and use of newly acquired Candle technology. OK, but for the last four decades the IT vendors and customers have relied on their own training programs to produce mainframe skills, and this will continue. Since IBM’s “WebSphere everywhere” strategy encompasses z/OS, any apps written to the J2EE standard can also run on the mainframe. This has the potential to alleviate concerns that application development takes too long on z/OS, and allows application deployment on the platform that best matches quality of service needs. Longer term, look for IBM to

make z/OS available on every developer’s desktop, which will increase mainframe awareness among application architects. For the past 10 years, the mainframe has suffered from a poor image among the misinformed, and it’s an unknown among the uninformed. z/OS and the new System z9-109 have the right ingredients for a computing utility, and partitioning is the secret sauce. I predict that IBM will eventually increase awareness beyond the mainframe community of all these advantages, and by 2015 the mainframe will be celebrating 51 years of unparalled accomplishment. Grace and peace. About the Author Bill Carico is president of ACTS, a consulting and software firm. He specializes in IT strategic planning and technology forecasting. He is a sought-after speaker who lectures worldwide on a number of IT and management topics. He is an open source evangelist who runs his software business using Linux on the mainframe (hosted by Infocrossing). His technical specialty areas include Enterprise Architecture, operating system internals and diagnostics, system performance, multi-processor design, automated operations, and server consolidation.

8


9

Featured Article I

ICF Catalogs and Usage By Martha Hall, Bayshore Senior Consultant

n ICF Catalog is made up of two

separate components. Each

has a specific function and design. The first component is the BCS or the Basic Catalog Structure. The second component is the VVDS or the VSAM Volume Data Sets. Each ICF Catalog is made up of a BCS and one or more VVDS. Next we will describe the structure of each of these components. BCS: Basic Catalog Structure Characteristics: A BCS is a VSAM KSDS. The contents of the BCS contain all the information needed to find a dataset. It has the catalog entries for VSAM and non-VSAM datasets whether on tape or on DASD. A BCS can be a master catalog or a user catalog. A master catalog will contain different types of entries than the user catalog. The master catalog should contain definitions for non-VSAM system datasets, user catalog connector records, alias records, and VSAM system datasets such as Page datasets. The user catalog can contain Cluster sphere records, path records, alternate index records, truename records, non-VSAM

records and GDG sphere records. Each of these types of datasets will have a unique record identifier. For VSAM datasets, the BCS will point to the VVR in the VVDS. This is described below in the VVDS section. For non-VSAM datasets, the BCS will point to the VTOC Format 1 DSCB. This is true for SMS datasets as well. This is described below in the VTOC section. VVDS: VSAM Volume Data Set A VVDS is a VSAM ESDS. It contains information about VSAM datasets that reside on the same pack as the VVDS as well as SMS information for non-VSAM datasets. The information included in a record includes dataset attributes; high allocated RBA (Relative Byte Address), high used RBA, and AMDSB (Access Method Data Statistics Block). The VVDS is normally accessed directly using the Relative Byte Address. The VVDS records do not have keys, but rather use component names. Types of records contained in the VVDS include the VSAM volume record (VVR), Non-VSAM volume record (NVR), which are created by SMS, and other

control records which are not discussed in this article. Each of these records will also have a unique type code. The VVDS will generally have a name format such as SYS1.VVDS.Vvolser. The default allocation value is 10 tracks. This is always too small and should be at least one cylinder to avoid secondary extents and performance issues. There should be a VVDS on each volume that contains a VSAM dataset, or any volume that is SMS managed. VTOC: Volume Table of Contents The VTOC contains allocation and extent information for a volume. It is used to find available space for a new allocation and to find Non-VSAM datasets. The VTOC is made up of records known as DSCB (Data Set Control Blocks). Different types of DSCBs provide different functions. There are up to six (6) different types of DSCBs. The format 4 DSCB anchors the VTOC and is pointed to by the UCB for the volume. It contains information describing the volume itself, including the volume characteristics such as the number of cylinders, tracks per cylinder, and track size.


10

The format 1 DSCB contains the dataset name, the DCB characteristics, the number of extents allocated to the dataset, information describing up to three dataset extents, as well as other relevant dataset information. The format 1 DSCB will also contain pointers to other types of DSCBs as appropriate. Catalog Allocation Tips: The allocation for Catalogs should always be allocated in Cylinder allocations. This will give you the maximum CA allocation of 1 cylinder. The secondary allocation should always be greater than 1 cylinder in order to prevent every CA split requiring another extent. The Data CISIZE is recommended to be 4KB and the Index CISIZE should be specified, not defaulted to. The Index CISIZE should be allocated as 1KB or more. String numbers should correspond to the number of systems accessing the catalog or at least three (3). BUFNI and BUFND should be specified rather than BUFFERSPACE. If the BCS is sharable, then use SHR (3 4). This is the default. If the BCS is not sharable then SHR (3 3) should be specified. Catalog Utilities: IBM provides IDCAMS utilities to perform problem determination on catalogs should problems occur. JCL is provided below.

The command “EXAMINE INDEXTEST’ will ensure that sequential and key direct access is accurate. The command “EXAMINE DATASET” will read all the data CI’s to ensure structure integrity. //STEP1 EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * EXAMINE NAME (CATALOG.UCAT.USCS) INDEXTEST DATATEST /* The command “DIAGNOSE ICFCATALOG” will check integrity within each BCS record. //STEP1 EXEC PGM=IDCAMS //INCAT DD DISP=SHR,DSN=CATALOG.UCAT.USCS //SYSPRINT DD SYSOUT=* //SYSIN DD * DIAGNOSE ICFCAT INFILE(INCAT) /* The command “DIAGNOSE VVDS” can be used to perform a VVDS Integrity check within each VVDS record. //STEP1 EXEC PGM=IDCAMS //VVIN DD DISP=SHR,DSN=SYS1.VVDS.VUSC001 //SYSPRINT DD SYSOUT=* //SYSIN DD * DIAGNOSE VVDS INFILE(VVIN) LIST /* In order to check that the entries in a catalog are consistent with those in one VVDS, use the “DIAGNOSE ICFCATALOG” command with the comparison entry. //STEP1 EXEC PGM=IDCAMS //VVIN DD DISP=SHR,DSN=SYS1.VVDS.VUSC001 //SYSPRINT DD SYSOUT=* //SYSIN DD * DIAGNOSE ICFCAT INDATASET(CATALOG.UCAT.USCS) COMPAREDD(VVIN) /* The next command will validate a VVDS against a catalog

//DD1 DD DISP=SHR,DSN=SYS1.VVDS.VUSC001 //SYSIN DD * DIAGNOSE VVDS - INFILE(DD1) - COMPAREDS(CATALOG.UCAT.USCS) Catalog Backups: Always run EXAMINE with INDEXTEST before any Catalog Backup. Normally all catalogs are backed up at least once a day. For critical catalogs, you may want to back them up more frequently. Less volatile catalogs can be backed up on a less frequent basis. It is important to make sure that all catalogs are backed up in accordance with their importance to your system. You should also make sure that the catalog backups complete successfully. JCL is provided below: //STEP1 EXEC PGM=IDCAMS //OUTCAT DD DSN=BACKUP.CATALOG.USCS,DISP=(NEW,CATLG), // SPACE=(CYL,(20,5)),UNIT=SYSDA //SYSPRINT DD SYSOUT=* //SYSIN DD * EXPORT CATALOG.UCAT.USCS OUTFILE(OUTCAT) TEMPORARY /* Catalog Recovery: Catalogs can be recovered/restored with IDCAMS IMPORT (after having been Exported). Because of the dynamic nature of catalogs, this process is useful only when a backup has been taken relatively soon before the recovery. JCL:


11

//STEP1 EXEC PGM=IDCAMS //INCAT DD DSN=BACKUP.CATALOG.USCS,DISP=(OLD,KEEP) //SYSPRINT DD SYSOUT=* //SYSIN DD * IMPORT INFILE(INCAT) OUTDATASET(CATALOG.UCAT.USCS) - ALIAS /* Catalog Forward Recovery: This is an IBM field developed program written by Vern Allison. It uses SMF records to fill in dataset activity written between the time of the backup and the restore. These SMF records are fed into the ICFRU program. It requires SMF Record types 61, 65, and 66. These are the dataset define, delete, and alter SMF records. This product will be incorporated into DFSMS 1.7. It uses a BCS EXPORT of a BCS and the SMF records as input and creates a new

EXPORT backup which can then be used as input to IDCAMS IMPORT to rebuild the catalog. If you do not have a product to do forward recovery, it is more difficult to bring the catalog up to date. One way is to use IDCAMS DECOLLECT to search for uncaptioned datasets. Once you have the list of those datasets, it’s a case of converting these to IDCAMS statements to recover the catalog. The JCL would look like:

New tape datasets can be found by scanning the Syslogs for IEC501A M uuuu,PRIVAT,SL,COMP,dataset.name, then you can use IEFBR14 job to catalog the file. Catalog Reorganization: A catalog can be backed up and recovered to rebuild the data and index components, remove CA and CI splits, and reduce extents. This reorganization needs to be done only when the catalog has expanded into a large number of extents, or there has been a large amount of delete activity on the catalog. EXPORT followed by IMPORT can be used to reorganize the catalog.

DELETE dataset.name NOSCRATCH---for orphan catalog entries DEFINE CLUSTER NAME (dataset.name) VOLUME(volser) RECATALOG---for uncataloged VSAM files DEFINE NONVSAM NAME (dataset.name) VOLUME(volser) RECATALOG---for uncataloged non-VSAM files


12

Featured Article II

IBM’s Latest Health Checker By Martha Hall, Bayshore Senior Consultant Introduction: The IBM Health Checker is an invaluable tool that should be run on every SYSPLEX on a regular basis. It is designed to improve your system’s availability. The exceptions that it produces as output are created to help you evaluate potential availability impact and take action. The program will read the systems various configuration files, and produce reports that identify possible problems based on accepted IBM recommendations that are contraindicated on your system, and the suggested steps to take to correct the problem. The IBM Health Checker has been available as a free, unsupported tool that can be downloaded from the IBM Web site since February of 2003. It was a batch job that produced exception messages and reports about the configuration status of the SYSPLEX. It provided no online panel displays. Now a new and better version of the z/OS Health Checker is available. The new version of the Health Checker is a formal product offering from IBM and it has been integrated into in the z/OS 1.7 BCP. This version is also available for z/OS 1.4, 1.5, and 1.6 as a web deliverable. The product is now

SMP/e installable, as base FMID HCS7720. Basic Health Checker Concepts: The new Health Checker basically consists of two parts:

• The framework • The checks

The framework allows the user to run checks for each system component supported. This framework is a common and open interface. These checks can be written by IBM, ISV (Independent Software Vendors), and users. The checks are code that look at settings and definitions scanning for potential problems. These include:

• Changes in settings or configuration values that occur dynamically over the life of an IPL.

• Checks that look for changes in these values should run periodically to keep the installation aware of changes.

• Threshold levels approaching the upper limits, especially those that might occur gradually or insidiously.

• Single points of failure in a configuration.

• Unhealthy combinations of configurations or values that an installation might not think to check.

At this time checks are available for: Consoles, Contents Supervisor, RRS, XCF/XES, GRS, SDUMP, Security Server, RSM, VSM, and z/OS UNIX System Services. These checks are provided by each individual IBM component. Installation and Customization Basics: The installation and setup of the Health Checker involves nine (9) Steps. JCL to run these steps is provided in SYS1.SAMPLIB once the support has been installed for the Health Checker. Detailed information is provided in the IBM Health Checker for z/OS User’s Guide SA22-7994-02. In addition a program directory is available: IBM Health Checker for z/OS V1R4.0-V1R6.0 and z/OS.e V1R4.0-V1R6.0 Program Directory (GI11-2856-00). The installation steps are as follows:


13

1. Satisfy the software requirements for IBM Health Checker for z/OS by applying PTFS listed in the PSP bucket; PSP HCHECKER, subset HXS7720.

2. Allocate the

HZSPDATA data set to save check data between restarts:

Jobname=HZSAPPCP 3. Set up the HZSPRINT

utility Jobname=HZSPRINT 4. Define log streams to

keep a record of the check output, as needed. Plan for and set up the log streams. You may have one log stream per system or one log stream for multiple systems. The log stream name(s) must begin with HZS.

5. Create security

definitions. These definitions are similar to other started tasks. There are two new security classes provided for the security definitions; they are XFACILIT and GXFACILI. For versions of ZOS prior to R7 APAR OA10774 will provide this support.

6. Set up customization

and security for SDSF. Support for the IBM Health Checker for z/OS in IBM Health Checker for z/OS Small Programming Enhancement in z/OS

SDSF Operation and Customization. You can use the new CK panel in SDSF to manage the checks. The SDSF support is supplied in APAR PK00561 for z/OS R4, R5, and R6. It is integrated into z/OS R7. You can also see z/OS V1R7.0 SDSF Operation and Customization (SA22-7670-08) for further information.

7. Create HZSPRMxx

from the HZSPRM00 parmlib member as required. This member can initially run without change. Then after you evaluate the output you can decide whether you need to make changes for your configuration.

8. Start IBM Health

Checker for z/OS. Copy the SAMPLIB member HZSPROC into your PROCLIB. Note that although there is a jobcard it is a started task. It is done like this so that messages to JESLOG will be suppressed. Change the proc as necessary for the dataset names that you created

9. Obtain checks for IBM

Health Checker for z/OS. Checks for the IBM Health Checker for z/OS are delivered both as an integrated part of a z/OS release or as PTFs. Many new and updated checks

will be distributed as PTFs. When looking in the PSP bucket, look for the HCHECKER upgrade name. The subset name for the Framework component is HZS7720, and the subset name for the Checks component is CHECKS. To list the checks that have been provided in PTF format, you can use the Enhanced Preventive Service Planning Tool, available at: http://techsupport.services.ibm.com/390/psp_main.html .

Evaluating the Output: Exception messages are the most important check output. Not only do they identify potential problems, but they also include suggestions on how to fix the problem. If a check finds an exception to a suggested value, or another potential problem, the check issues an exception message. The exception message might be accompanied by supporting information in report format. For an exception message, the system issues a WTO with just the message text by default. The system issues both the message text and details to the message buffer. The messages explain what the best practice is (showing the IBM values, and any user overrides), explain what could happen if the exception persists, and finally what the action is to correct it.


When you get an exception, it will be written to the Message buffer and then you can view it via SDSF, HZSPRINT or in the log stream. In addition, a WTO message will be written by default. The format is HZS message number then component message ID.

It is very important that you resolve exception messages, so that when checks run at their specified intervals, they will report only exceptions that require attention. Otherwise, your IBM Health Checker for z/OS output may contain a mixture of messages that you regularly ignore and those

reflecting a new potential problem. This might make it more likely that you could miss a key exception message. Running the IBM Health Checker is an excellent way to ensure availability and reliability for your z/OS system.

Bayshore Consulting & Services Co., Ltd Rm 209, Zhongchen Building, No.1, Lize Zhong Er Lu,

Chaoyang District, Beijing, China, 100102 Tel: (010) 6439-1733 Fax: (010) 6439-1582

http://www.bayss.com

14

http://www.bayss.com/


15

2 bayshore advisor, issue no. 3, march 1 · worldwide many customers are already installing z/os...

Documents