Resource measurement facility in a multiple operating system complex

Abstract

A reporter facility for reporting data from a sysplex with a plurality of operating system images. The reporter facility comprises one or more data sets in the operating system images containing the reportable data. A first data server is provided in a first one of the operating system images and one or more second data servers are provided in the operating system images with the data sets containing reportable data. The second data servers on receipt of a request issued by the first data server collect the reportable data from the data sets and pass it through the connections to the first data server, which then passes it to the reporter facility. In one embodiment of the invention the data sets include data relating to the use and load of resources within the sysplex.

Claims

What is claimed is:

1. In a sysplex having a plurality of operating system images, a reporter facility for reporting data from said sysplex, and one or more data groups in the operating system images containing reportable data, apparatus for providing said reportable data to said reporter facility, comprising:

a first data server in a first one of said operating system images;

one or more additional data servers in one or more of said operating system images with said data groups containing reportable data;

means in said first data server for sending a request to collect reportable data to one or more of said additional data servers, said request containing search criteria specifying said data:

means in said additional data servers responsive to the receipt of a request from said first data server to collect reportable data for collecting the reportable data from said data groups matching said search criteria and returning said reportable data to said first data server; and

means in said first data server for passing said returned reportable data to said reporter facility.

2. The apparatus of claim 1 comprising a plurality of data groups in each operating system image, said request to collect reportable data indicating in which of said data groups said reportable data is present.

3. The apparatus of claim 1 wherein said first data server creates an answer area into which the reportable data is stored.

4. The apparatus of claim 1 wherein said reporter facility comprises a monitoring facility for monitoring the resources in said sysplex, said data groups including data relating to the use and load of resources within said sysplex.

5. A method for reporting data in a sysplex with a plurality of operating system images comprising the steps of:

sending from a first one of said operating system images a request for collecting reportable data to other ones of said operating system images, said request containing search criteria specifying said data;

in response to the receipt of said request from said first one of said operating system images, collecting the reportable data in said other ones of said operating system images matching said search criteria and returning said reportable data to said first one of said operating system images; and

storing said returned reportable data in an answer area in said first one of said operating system images.

6. A method for reporting data in a sysplex with a plurality of operating system images comprising the steps of:

sending from a first one of said operating system images a request with search criteria for establishing in which ones of said operating system images reportable data is present;

in response to the receipt of said request from said first one of said operating system images, matching said search criteria with said reportable data in said operating system images and returning an image list of operating system images in which said reportable data is present to said first one of said operating system images;

using said Image list for sending from said first one of said operating system images to the listed operating system images a request for collecting the reportable data in said listed operating system images;

in response to the receipt of said latter request from said first one of said operating system images, collecting said reportable data in said listed ones of said operating system images and returning said reportable data from said listed ones of the operating system images to said first one of said operating system images; and

storing said returned reportable data in an answer area in said first one of said operating system images.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates to a sysplex with a plurality of operating system images connected through connections comprising a reporter facility for reporting data from the sysplex. The reporter facility has in-storage buffers and data sets in the operating system images containing the reportable data.

2. Description of the Related Art

With the ever-increasing need for computing power, a general trend is observable away from massive monolithic single-processor computers towards systems in which a large number of smaller processors are connected together and co-operate with each other in the processing of jobs. These so-called "sysplex" environments are characterised in that each of the processors within the environment runs its own operating system, i.e. each processor has its own operating system image. A central server processor provides a single synchronised timing signal across all the operating systems.

The IBM Corporation currently offers a sysplex in which a maximum of eight MVS images are connected together using the MVS Cross System Coupling Facility. This is described in the article "Use of XCF to facilitate Communication among Independent Processes", IBM Technical Disclosure Bulletin, vol. 3, no. 11, April 1991, pp. 357-359. In the future, it is desired to increase substantially the number of operating system images. By adding to the number of operating system images, one can ensure that the sysplex is continuously available since the impact of planned system outages or system failures is either eliminated or restricted to a small group of end users. The performance of a sysplex with a larger number of operating system images is improved and indeed allows for incremental growth--as a user needs more computing power, he or she needs to only add a further image rather than upgrading the whole of the installation.

With the increase in the number of images, a need arises to increase the systems management of the operation of the images, in particular to monitor the performance of each of the operating system images and to measure the load on the peripheral devices attached to the sysplex. By monitoring the workload of each image in the sysplex, one can ensure that the system as a whole functions in an optimal manner.

Various prior art devices for monitoring the performance of a computer system are known. The IBM Corporation offers for MVS-based systems the so-called Resource Measurement Facility (RMF) which measures and reports on the performance and availability of a customer's system. RMF issues reports about performance problems as they occur so that installation engineers can take action on the problems before they become critical. In addition, RMF can provide information about long-term system measurements to allow the user to tune the system and to provide for more capacity if needed. General Information about RMF is to be found in IBM Manual No. GC28-1028. A user's guide for RMF is available and has the number GC28-1058. Both these publications are incorporated herein by reference.

Similar programs are provided by Candle, Legent, Landmark and other companies.

In the IBM Technical Disclosure Bulletin, vol. 33, no. 4, September 1990, pp. 79-83, a "Computer System Performance Monitor" is described which improves the capability of a computer system to monitor its own performance. The monitor offers a defined set of performance-related function which analyze the performance of the system. This is achieved either directly by the system software or by means of an optional hardware monitoring processor via a defined interface.

Whilst these programs are fine tools for monitoring the performance of single image systems, they are unable to cope with the sore complicated requirements of monitoring multiple image systems such as a sysplex mentioned above.

Known from the prior art are a number of methods for monitoring the performance of a processor in a distributed data environment. For example, the article in the IBM Technical Disclosure Bulletin, vol. 34, no. 6, November 1991, pp. 387-389 entitled a "Method for Workload Performance Measurement" discloses a method which provides underlying system capabilities that enable the measurement of workloads and consists of a variety and combination of user and system work activities.

The article entitled "Large System Performance Monitor" in the IBM Technical Disclosure Bulletin, vol. 24, no. 3, August 1991, pp. 1416-1419 teaches a monitor to analyze the activities of the system resources in order to determine and understand their utilisation. The monitor described is able to do this without interfering with or degrading the performance of the system being monitored.

U.S. Pat. No. 5,119,493 (Janis et al) teaches a method for maintaining a selective document history log within a data processing system having multiple resource objects which are accessible by a plurality of users within the system. The history log is created and associated with each resource object for which documentation of selected activities is desired. A list of activities is created and is utilised to filter all activities which take place with respect to a particular resource object. Using this method it is possible to record only those activities which are of interest and thus memory space is efficiently used.

U.S. Pat. No. 5,109,486 (Seymour) teaches a requesting manager which sends a message to its local configuration processor requesting notices of status changed in a general or particular resource or node. The configuration manager establishes a record in its status monitoring file containing the information from the requesting processes messages. From this information, the performance of the system may be analyzed.

WO-A-93/00632 (ICL Data AB) teaches a method and system for monitoring and changing the operation of a computer system consisting of a plurality of computers connected in the form of a local area network. The system includes at least one event report generator in each executable program whose execution should be monitored, an event processing machine for processing events which are reported by an event report generator. An interface is provided for transferring an event reported by an event report generator to an event processing machine. From this machine information relating to the performance of the system may be obtained.

These prior art systems all have the disadvantage that they report events to the central monitoring program every time an event occurs at the resource or in the program which is being monitored. This leads to large amounts of message traffic throughout the network which is inefficient and, more seriously, can hinder the execution of computer jobs.

SUMMARY OF THE INVENTION

These disadvantages are solved according to the invention by a first data server in a first one of the operating system images, one or more second data servers in the operating system images with the in-storage buffers or data sets containing reportable data, whereby when the sysplex is in operation the second data servers on receipt of a request collect the reportable data from the data sets and pass it through the connections to the first data server which then passes it to the reporter facility.

This has the advantage over the prior art that the reportable data is only passed to the first one of the operating system images when it is requested. Thus the continual data traffic is avoided and data can be requested at times at which the load on the sysplex and, in particular, on the connections between the operating system images is low. The reduction in data traffic allows a much more efficient use of the connections between the operating system images.

The reporter facility can have two types of data sets in each operating system image and the requests to collect the reportable data indicate in which one of the data sets the reportable data is present.

In a further embodiment of the invention, the reporter facility includes an answer area created by the first data server into which the reportable data is stored. This allows the efficient recovery of the reportable data when it is to be processed. Storing the data on an external medium, for example, would slow down the processing of the data by a reporter processor.

The reporter facility finds particular application in a monitoring facility for monitoring the resources in a sysplex in which the data sets include data relating to the use and load of resources within the sysplex.

By monitoring the resources of the sysplex, one is able to determine the use of and the load on the resources and, as a result, adjust the work being done by each of the resources. This is particularly important in the sysplex with multiple operating system images since the processing of a program may be held up whilst it is being executed in one of the operating system images whilst other images are standing idle.

The invention also comprises a method for reporting data in a sysplex with a plurality of operating system images comprising the following steps: a first step of sending from a first one of the operating system images a request for the reportable data to other ones of the operating system images, a second step of collecting the reportable data in the other ones of the operating system images, a third step of returning the reportable data to the first one of the operating system images, a fourth step of storing the reportable data in an answer area created in the first one of the operating system images.

In a further embodiment of the invention, the method has the following steps: a first step of sending from a first one of the operating system images a request with search criteria for establishing in which ones of the operating system images the reportable data is present, a second step of matching the search criteria with the reportable data in the operating system images, a third step of returning an image list of operating system images in which the reportable data is present to the first one of the operating system images, a fourth step of using the image list for sending to the operating system images a request for collecting the reportable data in the operating system images, a fifth step of returning the reportable data to the first one of the operating system images, a sixth step of storing the reportable data in an answer area created in the first one of the operating system images.

The use of the reporter facility is not confined to an application within a resource monitoring facility. It can also find application in any sysplex in which data has to be collected and collated by one of the operating system images from the other ones of the operating system images.

DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an overview of the sysplex without the RMF Sysplex Data Server.

FIG. 2A shows an overview of the first measurement facility address space (RMF Address Space).

FIG. 2B shows an overview of the second measurement facility address space (RMFGAT Address Space).

FIG. 3A shows an example of the format of SMF data records.

FIG. 3B shows an example of the structure of the header for SMF data records.

FIG. 4 shows an overview of the sysplex with the sysplex data server of the current invention.

FIG. 5A shows the format of the CALL ERBDSQRY GUPI.

FIG. 5B shows the format of the smf.sub.-- record.sub.-- type.sub.-- list parameter.

FIG. 5C shows the format of the smf.sub.-- system.sub.-- name.sub.-- list parameter.

FIG. 6A shows the format of the common header returned from the GUPIs.

FIG. 6B shows the answer area created by the ERBDSQRY GUPI when the request.sub.-- type parameter has the value SMF.

FIG. 6C shows the answer area created by the ERBDSQRY GUPI when the request.sub.-- type parameter has the value RMF.

FIG. 6D shows the format of the RMF product section of the SMF record.

FIG. 7A shows the format of the CALL ERBDSREC GUPI.

FIG. 7B shows the format of the rmf.sub.-- record.sub.-- token.sub.-- list parameter.

FIG. 8 shows the data section header answer area created on return from the ERBDSREC GUPI.

FIG. 9 shows the format of the CALL ERB3XDRS GUPI.

FIG. 10 shows the format of the data section header of the answer area created on return from the ERB3XDRS GUPI.

FIG. 11 is a flow chart showing the call of the ERBDSQRY GUPI.

FIG. 12 is a flow chart showing the call of the ERBDSREC GUPI.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 shows an overview of a sysplex 10 containing a measurement facility. The sysplex 10 has a plurality of operating system images 20a, 20b, 20c, 20d. In FIG. 1 only four operating system images are shown for clarity. More images may be added and, in the preferred embodiment, thirty-two images are present. Reference signs on the FIG. 1 are also provided only for one of the images 20a. This is also for clarity, the corresponding elements in the other images 20b, 20c and 20d perform the same functions as those in the image 20a.

Each of the images 20 has an address space in which are placed application programs (not shown) or parts of application programs and a first measurement facility address space 30, termed the RMF address space, and a second measurement facility address space 50, termed the RMFGAT address space. The preferred embodiment of the invention has two measurement facility address spaces 30, 50. It would be possible to incorporate the functions present in both the first measurement facility address space 30 and the second measurement facility address space 50 into a single measurement facility address space.

Within the first measurement facility address space 30, a first plurality of in-storage buffers 40, termed SMF data, is provided. The functioning of these in-storage buffers 40 will be explained in more detail below.

In the second measurement facility address space 50, a second plurality of in-storage buffers 60, termed Monitor III data, is provided. The second plurality of in-storage buffers 60 stores the so-called Monitor III records which allow the continuous monitoring of system data and allow the solution of temporary performance problems. The role of the second plurality of in-storage buffers 60 will be explained in more detail below.

The first plurality of in-storage buffers 40 and the second plurality of in-storage buffers 60 can be stored in memory from whence they may be passed to the measurement facility address spaces in other images as will be explained later. A first data set 70 is connected to the first measurement facility address space 30 and a second data set 80 is connected to the second measurement facility address space 50. The SMF data is passed to both the first in-storage buffer 40 and the first data set 70 at the same time if both are present. Similarly the Monitor III data is passed to both the second in-storage buffer 60 and the second data set 80 at the same time if both are present. The data sets 70, 80 and in-storage buffers 40, 60 are collectively referred to as data groups.

The sysplex 10 incorporates two analysis programs for evaluating the data stored in either of the first in-storage buffer 40 or the second in-storage buffer 60. A measurement facility processor 110 (the RMF Post Processor) collects the data from the direct access storage devices 70, merges it onto a single storage device 90 and sorts it as required. The sorted data is also stored on a storage device 100. Although the storage devices 90 and 100 are shown as two single storage devices in FIG. 1, in practice they are two different areas of the same storage device. The measurement facility processor 110 uses the merged and sorted data to display information about the performance of the sysplex 10.

The measurement facility reporter 120 (the RMF Monitor III reporter) collects the data from the direct access storage devices 80 and allows a real time analysis of the performance of the sysplex 10.

FIG. 2A shows an overview of the first measurement facility address space 30 with the first plurality of in-storage buffers 40.

The first plurality of in-storage buffers 40 stores the so-called system management facilities (SMF) records which allow an analysis of the long term system workload and resource utilisation. The SMF data gathering routines 32 obtain information about the system and pass this information to the first in-storage buffers 40 and the first data set 70.

It is the responsibility of the owner of the sysplex 10 to decide what information is to be stored and what records are to be gathered. Factors to be taken into account when making this decision are:

What records must the SMF data gathering routines 32 produce to give the sysplex owner the information required?

Are programs running which produce large amounts of SMF records, for example data base programs?

What is the impact of the system configuration on the operation of the sysplex 10?

How much contention on each of the operating system images 20 is there for the resources that the SMF data gathering routines 32 require?

FIG. 3a shows an example of the format of SMF data records 310 as the stored in the first plurality of data buffers 40. The SMF data record 310 consists of an SMF record header 320 which is in this case eighteen or twenty-four bytes long and information 330 which can be up to 32756 bytes in length. The exact length of the SMF record 310 is indicated in the SMF record header 320 as will be described later. The structure of the information 330 is variable and is specified by the user of the SMF records 310.

The fixed structure of the SMF record header 320 is shown in FIG. 3B. The first field in the SMF record header 320 is called SMFxLEN and is two bytes in length. It indicates the total length of the SMF record 310 including the SMF record header 320 and the information parts 330 of the SMF record 310. The next field is called SMFxSEG and is used if the SMF data spans more than one SMF record 310, i.e. if the data that is to be recorded is more than 32,756 bytes in length. If the SMF data does not span more than one SMF record 310, then the two bytes in the SMFxSEG field are both set to hexadecimal zero. The SMFxLEN and the SMFxSEG fields together form a four byte record descriptor called the record descriptor word (RDW).

The next field in the SMF record 310 is the SMFxFLG which indicates the operating system in which the SMF records were generated. It is one byte in length. For example, if the byte is set to 3, it indicates an MVS/SP Version 4 operating system. If set to 4, it indicates that the operating system is MVS/ESA and if set to 5 that the operating system is MVS/XA. The values 0, 1 and 2 are reserved for other purposes.

The SMFxRTY field is one byte in length and can take the values 0 to FF (hexadecimal). It indicates the type of SMF record 310 being generated. In the preferred embodiment of the invention, the record types 0 to 127 (decimal) are reserved for use by the IBM operating system images. In particular, record types 70-79 are used by the resource measurement facility as described herein. The record types 128-255 are free for use by applications programs.

The SMFxTME field is four bytes in length and indicates the time elapsed since midnight in hundredths of a second since the SMF record 310 was created. The SMFxDTE field is also four bytes in length and indicates the date on which the SMF record 310 was created.

Finally, the SMFxSID field indicates the identification number of the system or of the operating system image 20 on which the SMF record 310 was created.

In another version of the SMF record 310, further fields are provided to record the subsystem identification (SMFxSSI--four bytes in length) of the subsystem on which the SMF record was created and also the subtype of the record (SMFxSTY). This gives a SMF record header 320 which is 24 bytes in length.

It will be observed that the names of the field all have a small x in the fourth position. The value of x indicates the type of SMF record. X can take a value from 0 to 255. In the preferred embodiment of the invention, x has a value between 70 and 79.

As mentioned above, SMF data gathering routines 32 are supplied on each image 20. These SMF data gathering routines 32 pass the information which the owner of the system has specified in the form of records to a data buffer 40 and thence fill each of the data sets in the buffer 40 one at a time. When one of these data sets becomes full, the SMF data gathering routines 32 search for an empty data set within the first measurement facility address space 30. Whilst one data set is being filled with SMF records, SMF dump routines are used to write the data out of the full ones of the first plurality of data sets onto the storage space reserved on the direct access storage device 70.

The structure of the second measurement facility address space 50 is shown in FIG. 2B. It includes not only the second plurality of in-storage buffers 60 mentioned above but also a data gatherer 55 which collects the system data, formats it into samples and stores the data in the in-storage buffers 60 or data sets 80.

The data gatherer 55 is started by a command which has the following options:

CYCLE(nnnn)

This specifies the length of time in milliseconds for which the system data is cycled.

DATASET (suboptions)

This controls the recording to the VSAM data sets. The suboptions control the saving of the data from the

MINTIME (nnn)

This specifies the length of a time interval in seconds. At the end of this time interval, the data gatherer 55 combines all samples gathered into a set of samples which can then be summarised and reported by the measurement facility reporter 120. The exact structure of the set of samples depends on the type of data collected.

FIG. 4 shows an overview of the sysplex 10 with a sysplex data server 170. For ease of identification, the reference signs used in FIG. 4 refer to the same elements of the sysplex 10 as those used in FIG. 1. Within the first measurement facility address space 30 in addition to the modules shown in FIG. 1, a sysplex data server 170 is provided.

The sysplex data server 170 has access as is shown on FIG. 4 to the SMF record data stored in the buffers 40 shown in FIG. 2A and also to the buffers 60 provided in the second measurement facility address space 50 as shown in FIG. 2B. The sysplex data server 170 is identical in each of the operating system images 20a-d and is joined through connections 410 shown on FIG. 4 to all of the other sysplex data servers 170 in the other operating system images 20a-d. The sysplex data server 170 is always active in the first measurement facility address space 30 when the resource measurement facility is running in the operating system image 20.

The sysplex data server 170 is able to process all types of data which is used by the resource measurement facility, in particular it is able to use the SMF data and the Monitor III data. It supplies a series of General Use Programming Interface (GUPI) services which may be invoked either by the RMF reporter sessions themselves, e.g. the measurement facility reporter 120, or by authorised applications programs.

FIG. 4 also shows a user address space 150 in the operating system image 20b which is connected to the sysplex data server 170 in the first measurement facility address space of the operating system image. The user address space 150 incorporates an applications program 160 which is authorised to use the GUPI services provided by the sysplex data server 170. Applications program 160 constitutes a reporter facility for reporting data from the sysplex 10.

The sysplex data server 170 provides the following GUPIs: ERBDSQRY--RMF Query Available Sysplex SMF data service, ERBDSREC--RMF Request Sysplex SMF Record Data Service and ERB3XDRS--RMF Monitor III Sysplex Data Retrieval Service.

The ERBDSQRY GUPI is used to request a directory of SMF record data available in the data sets 40 or sets of samples in the data sets 60 on each operating system image 20 in the sysplex 10. The CALL statement for ERBDSQRY is written as shown in FIG. 5A.

The parameters supplied to the ERBDSQRY have the following values:

ANSWER.sub.-- AREA.sub.-- ADDR

Specifies the address in the memory where the sysplex data server 170 returns the requested information. The area can be either in the user address space 150 or in a public address and data space. The parameter answer.sub.-- area.sub.-- addr is defined as a pointer variable of length 4.

ANSWER.sub.-- AREA.sub.-- ALET

Specifies the access list entry table (ALET) of the answer area specified by the answer.sub.-- area.sub.-- addr parameter. If the answer area resides in the user address space 150, the value of the answer.sub.-- area.sub.-- alet must be 0. The parameter answer.sub.-- area.sub.-- alet is defined as an unsigned integer variable of length 4.

ANSWER.sub.-- AREA.sub.-- LENGTH

Specifies the length of the answer area whose address is given in the answer.sub.-- area.sub.-- addr parameter. If not enough space is provided the sysplex data server 170 informs the calling applications program 160 about how much space should have been provided, as memory space addressed by the answer.sub.-- area.sub.-- addr parameter must contain the length needed for the complete data. The answer.sub.-- area.sub.-- length is defined as an unsigned integer variable of length 4.

REQUEST.sub.-- TYPE

Specifies the ERBDSQRY function code and may take one of the following values:

    ______________________________________
    SMF  Request information about SMF records 310 of any type and
         subtype. Information will be returned about all SMF records 310
         where the SMF time information (the point in time specified in the
         date and time fields from the SMF record header 320) is contained
         in the time interval specified in the start.sub.-- time and
         end.sub.-- time parameters (see below).
    RMF  Request information about SMF records 310 of any RMF type and
         subtype. Information will be returned about all SMF records 310
         where the projected RMF measurement interval end time (specified
         in the RMF product section) is contained in the time interval
         specified in the start.sub.-- time and end.sub.-- time parameters
         (see below).
    ______________________________________

    ______________________________________
    INCLUDE The list of SMF record types provided on the
            smf.sub.-- record.sub.-- type.sub.-- list parameter is an
            inclusion list, i.e.
            information is requested for the listed SMF record types.
    EXCLUDE The list of SMF record types provided on the
            smf.sub.-- record.sub.-- type.sub.-- list parameter is an
            exclusion list, e.g.
            information is requested for all but the listed SMF record
            types.
    ALL     The list of SMF record types provided on the
            smf.sub.-- record.sub.-- type.sub.-- list parameter is ignored,
            e.g.
            information is requested for all SMF record types.
    ______________________________________

    ______________________________________
    INCLUDE The list of images 20 provided on the
            smf.sub.-- system.sub.-- name.sub.-- list parameter is an
            inclusion list, i.e.
            information is requested for systems with the listed
            operating system images 20.
    EXCLUDE The list of SMF system names provided on the
            smf.sub.-- system.sub.-- name.sub.-- list parameter is an
            exclusion list, e.g.
            information is requested for all systems in the sysplex
            excluding the operating system images 20 with the listed
            names.
    ALL     The list of operating system image names provided on the
            smf.sub.-- system.sub.-- name.sub.-- list parameter is ignored,
            e.g.
            information is requested for all systems in the sysplex
    ______________________________________
            10.

    ______________________________________
    `DSQA` for the ERBDSQRY GUPI common header
    `DSRA` for the ERBDSREC GUPI common header
    `XDRH` for the ERB3XDRS GUPI common header
    VER 608
           Version of the common header 601 (initially set to 1).
    LEN 610
           Total length of the returned data.
    TLN 612
           Total length of the answer area 600 needed to contain all the
           requested data.
    PLX 615
           Name of the operating system image 20 on which the calling
           applications program 160 using the GUPI is running.
    SOF 618
           Offset from the header to the first system list entry SNM.
    SLN 620
           Length of one system list entry (i.e. length of SNM, SID,
           RMF fields).
    SNO 622
           Number of system list entries (SNM, SID, RMF).
    DOF 625
           Offset from the header 601 to the first data section. For the
           detailed layout, refer to the individual data section
           explanations below.
    DLN 628
           Length of one data section. For a variable length data section,
           this field is zero. In this case, the length is stored in an
           individual data section header.
    DNO 630
           Number of returned data sections.
    system list
           contains one entry per operating system image 20 in the
           sysplex 10:
    SNMn       8-character system name for the operating system
               image 20.
    SIDn       4-character SMF system ID. If RMF is not active on
               this system, this field contains hex zeros.
    RMFn       32-bit RMF status indicator, in which:
               Bit 1 indicates the status of the RMF address
               space 30 on this system (`1`B = active)
               Bit 2 indicates the status of the RMF Data Buffer
               40 for SMF data on this system (`1`B = active)
               Bit 3 indicates the status of the RMF Monitor III
               address space 50 on this system (`1`B = active)
               Bits 4 to 32 are reserved
    ______________________________________

    ______________________________________
    RLn     Length of this SMF record 310 data entry (including the
            data header 810)
    RCn     Return code for the request of this SMF record:
    0         Data returned. SMF record data 850 follows the data
              header 810.
    4         Data not returned. Timeout occurred before the SMF
              record was received from remote operating system
              image 20.
    8         Data not returned. Record token RMFTOKn does not
              correspond to an existing SMF record on an operating
              system image 20 in the sysplex 10.
    RECTOKn
    ______________________________________

    ______________________________________
    DEL 1002
            Length of this data section
    RTN 1003
            Data retrieval return code
    RSN 1004
            Data retrieval RSN
    DGV 1005
            Data gatherer version in the format `VRM`
    DSG 1008
            System name of the operating system image 20 where the
            data gatherer is running
    MNT 1010
            Data gatherer MINTIME option
    SAM 1012
            Actual number of samples for the returned data
    RNG 1015
            Actual range length (in seconds)
    BEG     Actual range start time (in the sorted time format
            YYYYMMDDHHMMSS)
    END     Actual range end time (in the sorted time format
            YYYYMMDDHHMMSS)
    DRC 1031
            Data reducation exit completion code
    Fields labelled with a "*" are reserved.
    ______________________________________

• Inventors
  Koenig, Dieter;
• Assignee
  International Business Machines Corporation (Armonk, NY)
• Published
  Jul-13-1999
• Current US Classes:
  718/100
• Application #
  847765
• International Classes
  G06F 011/34
• Field of Search
  395/670 395/200.3 395/200.31 395/200.33 395/200.49 395/674 395/704
• Examiner
  Trammell; James P.
• Agent
  Kinnaman, Jr.; W. A.
• US Patent References:
  4633387
  4740910
  5053950
  5115505
  5202989
  5218713