Archive for category MVS

EREP Selection Parameters

The following parameters are used to select the records for EREP to use:

Parameter Description
CPU=({nnnnnn|Xnnnnn|XXnnnn}

.model [, ...])

  • Processor serial and machine type numbers.
  • Use only the records associated with this particular processor.
  • nnnnnn – the six-digit hexadecimal CPU ID number. It defines a single processor in an n-way central processor complex.
  • Xnnnnn – the processor identifier. You may wish to use this form if you want to select all the records for an n-way central processor complex, single image or physically partitioned, without having to specify all the processor addresses individually. For example: 012345, 112345, 212345.
  • XXnnnn – the processor identifier. You may wish to use this form if you want to select all the records for a logical partitioned (PR/SM ™ LPAR) central processor complex, whether single image or physically partitioned
  • model – the four-digit decimal processor model number.
CPUCUA=(serial.{cua|cuX}

[,serial.{cua|cuX}]…)

  • Processor serial number and channel unit address.
  • Use only the records associated with this channel unit attached to this processor.
  • serial – the six-digit hexadecimal CPU serial number.
  • cua – a unique three- or four-digit hexadecimal channel or unit address.
  • cuX – two or three hexadecimal digits followed by an X to denote the range of device addresses with those digits ending in 0 through F.
CUA=({[N]addr|[N]addr-[N]addr}[, ...])
  • Channel unit address or number.
  • Use only the records associated with this particular channel unit address or channel unit number.
  • addr - a three- or four-digit hexadecimal address or group of addresses. The format of the address may be nnXX, nnnX, or nnnn (for example: 01XX, 038X, or 049C). nnXX means that EREP processes all controller or unit addresses on channel nn; nnnX means that EREP processes all unit addresses on channel or control unit nnn. Important: The channel identifier can be one or two digits.
  • addr-addr – a range of contiguous hexadecimal addresses, which may include more than one channel and control unit. The lower address must appear first in the expression. An X in the lower address represents a 0; in the upper address it represents an F.
  • N – indicates not; it excludes CUAs from the report. NnnXX means that EREP processes all controller or unit addresses not on channel nn; NnnnX means that EREP processes all unit addresses not on channel or control unit nnn.
DATE=({yyddd[,yyddd] | yyddd[-yyddd]})
  • Use only the records created during this date range.
  • yyddd – the year yy and the Julian day ddd. The first yyddd is the year and day when the date range begins; the second yyddd is the ending year and day. The second date is optional; you can select records from a single date as well as from a range of dates. To select a single date, code only one yyddd.
DEV=(type | Ntype[,type | Ntype]…)
  • Device Type.
  • Use only the records associated with this particular device type; or, conversely, do not use the records associated with this device type.
  • type – a  four character field: either a specific device type (3340, 3420) or the representation of a class of devices (33XX, 34XX).
  • N – indicates not; excludes a device type from the report.
DEVSER=(serial[,serial]…)
  • Device serial number.
  • Use only the OBR records associated with this tape device serial number. (Use only for the THRESHOLD report and only with the 3410, 3420, and 8809 tape OBR records.)
  • serial – a six-digit decimal device serial number from the service data.
ERRORID=(seqno[,cpuid,asid,

hh,mm,ss,t])

  • Error identifier.
  • Use only the MCH and MVS software records containing this particular error identifier.
  • seqno – a 5-digit decimal error identifier from an MCH record or an MVS software (SFT) record.
  • cpuid – a 2-digit hexadecimal processor (CPU) identifier.
  • asid – a 4-digit hexadecimal address space identifier.
  • hh – a 2-digit decimal value representing the hour.
  • mm – a 2-digit decimal value representing the minute.
  • ss – a 2-digit decimal value representing the second.
  • t – a single decimal digit indicating tenths of the second.
LIA | LIBADR=address
  • Line interface [base] address.
  • Use only the 3705, 3720, 3725 or 3745 communication controller records containing this line interface address.
  • address – a four-digit hexadecimal line interface base address.
MOD=(model[,model]…)
  • Processor model.
  • Use only the records containing this processor machine type (number).
  • model – a three- or four-digit decimal processor model number.
MODE={370 | 370XA | ALL}
  • 370 or 370XA
  • Use only the records created in this operating mode.
  • 370 – means 370 mode only.
  • 370/XA – means 370XA and 370/ESA modes only.
  • ALL – means 370, 370XA and 370/ESA modes.
SYMCDE={nnnn | nnnX | nnXX | nXXX}
  • Fault symptom code.
  • Use only the 33XX DASD records containing this particular fault symptom code.
  • n – is a hexadecimal digit.
TERMN=name
  • Terminal name.
  • Use only the VTAM or TCAM OBR records containing this terminal name.
  • name – the valid one-to-eight character alphanumeric name assigned to a particular terminal.
TIME=({hhmm,hhmm | hhmm-hhmm})
  • Use only the records created during this time range.
  • hhmm – is a valid time period, hours and minutes.
TYPE=code[code]...
  • Record type.
  • Use only the records of the specified types.
  • Each code is one of the following:

A - A1 through AF records

B - B1 through BF records

C - CCH/CRW/SLH: Channel check/channel report word/subchannel logout records

D - DDR: Dynamic device reconfiguration records

E - System termination (EOD): End of day and other terminating events

F - F0 through FF records

H - MIH: Missing interrupt records

I - System initialization (IPL): Initial program load

M - MCH: Machine check records

O - OBR: Outboard records; unit checks

S - Software (SFT): System abends and other software events

T - MDR (formerly TPR): Miscellaneous data records

X - C0 through CF records

Y - D0 through DF records

Z - E0 through EF records

VOLID=(volser[,volser]...)
  • Volume serial number.
  • Use only the 33XX DASD or 34XX tape records containing this volume serial number.
  • volser - A valid volume identifier (or serial number) that can be from one-to-six alphanumeric characters long.

No Comments

List the Information from the Logrec Data Set

Next are a few examples of Jobs to list information from the Logrec Data Set:

1. Detail Edit Report

This job generates detail edits and summaries of all software and operational records:

//EREPRPT1 JOB,MSGLEVEL=(1,1),MSGCLASS=X,NOTIFY=&SYSUID
//REPORT1   EXEC  PGM=IFCEREP1,PARM='CARD'
//ACCIN     DD  DSN=MVS.LOGREC.HISTORY,DISP=SHR
//DIRECTWK  DD  UNIT=SYSDA,
//              SPACE=(CYL,5,,CONTIG)
//EREPPT    DD  SYSOUT=A,DCB=BLKSIZE=133
//TOURIST   DD  SYSOUT=A,DCB=BLKSIZE=133
//SYSIN     DD  *
PRINT=PS
TYPE=SIE
HIST
ACC=N
ENDPARM
/*

2. Event History Report

The following is a two-step job. The first step prints an event history report for all Logrec data set records. The second step formats each software, IPL, and EOD record individually.

This Job can be a very useful tool to the problem solver because it prints the records in the same sequence they were recorded and therefore shows an interaction between hardware error records and software error records.

//EREPRPT2 JOB,MSGLEVEL=(1,1),MSGCLASS=X,NOTIFY=&SYSUID
//* -------------------------------
//* - STEP 1 ----------------------
//* -------------------------------
//*
//EREPA EXEC PGM=IFCEREP1,PARM='EVENT=Y,ACC=N',REGION=256K
//SERLOG DD DSN=SYS1.LOGREC,DISP=SHR
//TOURIST DD SYSOUT=A
//EREPPT DD SYSOUT=A,DCB=BLKSIZE=133
//SYSIN  DD DUMMY
//*
//* -------------------------------
//* - STEP 2 ----------------------
//* -------------------------------
//*
//EREPB EXEC PGM=IFCEREP1,PARM='TYPE=SIE,PRINT=PS,ACC=N',
//   REGION=256K
//SERLOG DD DSN=SYS1.LOGREC,DISP=SHR
//TOURIST DD SYSOUT=A
//EREPPT DD SYSOUT=A,DCB=BLKSIZE=133
//SYSIN  DD DUMMY
/*

3. Detail Summary Report

This job generates detail summaries of all I/O errors:

//EREPRPT3 JOB,MSGLEVEL=(1,1),MSGCLASS=X,NOTIFY=&SYSUID
//REPORT3  EXEC  PGM=IFCEREP1,PARM='CARD'
//ACCIN    DD DSN=MVS.LOGREC.HISTORY,DISP=(OLD,PASS)
//DIRECTWK DD UNIT=3390,
//            SPACE=(CYL,5,,CONTIG)
//EREPPT   DD SYSOUT=A,DCB=BLKSIZE=133
//TOURIST  DD SYSOUT=A,DCB=BLKSIZE=133
//SYSIN    DD  *
PRINT=SU
TYPE=DOTH
DEV=(N34XX,N3704,N3705,N3720,N3725,N3745)
HIST
ACC=N
ENDPARM

For more information regarding the parameters and control statements used in these jobs check the following links:

  • EREP Report Parameters
  • EREP Selection Parameters
  • EREP Processing Parameters
  • EREP Control Statements

No Comments

EREP Report Parameters

The following parameters are used to request reports from EREP:

Parameter Description
EVENT=Y or N
  • Produces a three-part event history report that lists errors in chronological order.
  • Shows how often errors occur and in what order.
  • Used to establish a pattern and identify problems.
  • No is the default value.
PRINT= AL | DR | NO | PS | PT | SD | SU
  • Produces a series of detail edit or summary reports, or both, for the selected record types.
  • The number of reports depends on the input and selection parameters.
  • AL – requests all the detail (PRINT) reports: detail edits of the records, detail
  • summaries, and, if applicable, data reduction reports.
  • DR – requests only data reduction reports.
  • NO – requests that no reports be generated at all.
  • PS – requests both detail edit and detail summary reports.
  • PT – requests only detail edit reports.
  • SD – requests detail summaries and data reduction reports. It’s the default value.
  • SU – requests only detail summary reports.
SYSEXN=Y or N
  • Produces a system exception report series covering processors, channels, DASD, optical, and tape subsystems.
  • No is the default value.
SYSUM=Y or N
  • Produces a condensed two-part system summary report of all errors for the principal system elements:CPU, channels, storage, SCP, and the I/O subsystem.
  • No is the default value
THRESHOLD=(xxx,yyy)
  • Produces a summary of a 3410, 3420, and 8809 tape subsystem, including media statistics and permanent errors that exceed the limits set on the parameter.
  • xxx – The one-to-three digit decimal (leading zeros not required) threshold value for temporary read errors. Maximum value is 255.
  • yyy – The one-to-three digit decimal (leading zeros not required) threshold value for temporary write errors. Maximum value is 255.
TRENDS=Y or N
  • Produces a two-part trends report that presents error records logged for the various system elements during a maximum of 30 days.
  • This report presents the errors in chronological order by Julian date.
  • No is the default value.

No Comments

Create a History Data Set from the Logrec Data Set

By creating a history file and then running all the reports against that file, the Systems Programmer ensures that all of the reports are using the same set of records.

//LOGRECHS JOB CLASS=A,MSGLEVEL=(1,1),MSGCLASS=X,NOTIFY=&SYSUID
//*------------------------------------------------------------------
//* COPIES SYS1.LOGREC TO HISTORY FILE MVS.LOGREC.HISTORY
//*------------------------------------------------------------------
//HISTORY EXEC PGM=IFCEREP1,REGION=1024K,
// PARM='ACC,ZERO=N'
//SERLOG DD DISP=(OLD,KEEP),DSN=SYS1.LOGREC
//ACCDEV DD DISP=(NEW,PASS),DSN=MVS.LOGREC.HISTORY,
// UNIT=3390,SPACE=(CYL,(2,2)),
// DCB=(RECFM=VB,BLKSIZE=6144)
//DIRECTWK DD DISP=(NEW,DELETE),UNIT=3390,SPACE=(CYL,2,,CONTIG)
//EREPPT DD SYSOUT=A,DCB=BLKSIZE=133
//TOURIST DD SYSOUT=A,DCB=BLKSIZE=133
//SYSIN DD DUMMY
/*

No Comments

How to clear and re-initialize the Logrec Data Set SYS1.LOGREC

It’s not uncommon for the SYS1.LOGREC dataset to fill up. Although you should dump the content of the SYS1.LOGREC to DASD or Tape to keep that information for future use (if you need to analyse a problem), you sometimes may simply wish to clear all its content and re-initialize it. The solution is to run IFCDIP00.


//IFCDIP00 JOB CLASS=A,MSGLEVEL=(1,1),MSGCLASS=X,NOTIFY=&SYSUID
//********************************************************************
//* CLEAR AND INITIALIZE HARDWARE EVENT RECORDER DATASET             *
//********************************************************************
//IFCDIP00 EXEC PGM=IFCDIP00
//SERERDS  DD  DSN=SYS1.LOGREC,DISP=OLD,
//             VOL=SER=MVSRES,
//             UNIT=3390

In this example we will clear and re-initialize the content of SYS1.LOGREC located on volume MVSRES.

No Comments

Defining a Logrec Log Stream

First of all and before defining a Logrec log stream, the Systems Programmer should make sure that the system in question was IPLed with a Logrec data set initialized by IFCDIP00. If this is not the case, you cannot change the Logrec recording medium from LOGSTREAM to DATASET using the SETLOGRC command and therefore you’ll have to IPL the system in order to be able to use the Logrec log stream you’ve defined.

To use the Logrec log stream, the Systems Programmer must first set up the system to use system logger functions. IBM recommends that you use a coupling facility log stream for LOGREC so that you can merge data from multiple systems in a sysplex.

On a single system sysplex (monoplex) the system can also use a DASD only log stream (which is single system in scope). However, this is not recommended for a multi-system sysplex because since we can only have one Logrec log stream per sysplex, this would mean that if using a DASD only Logrec log stream, only one system of the sysplex would be able to access it. Therefore for a multi-system sysplex it is advisable to use a LOGSTREAM Logrec log stream.

JCL:

// IXCMIAPU JOB CLASS=A,MSGLEVEL=(1,1),MSGCLASS=X,NOTIFY=&SYSUID
//DEFINE   EXEC PGM=IXCMIAPU
//SYSPRINT DD   SYSOUT=A
//SYSIN    DD   *
DATA TYPE (LOGR)
DEFINE STRUCTURE NAME(LOGRECSTRUCTURE)
LOGSNUM(1)
AVGBUFSIZE(4068)
MAXBUFSIZE(4068)
DEFINE LOGSTREAM NAME(SYS1.SYSPLEX.LOGREC)
STRUCTNAME(LOGRECSTRUCTURE)
/*

MAXBUFSIZE must be at least 4068 because logrec writes records in one page blocks. Specify SMS storage group, storage, data and management classes such that when one data set is full, another is allocated. Allocate as much space as is allocated for all the logrec data sets on the systems in the sysplex before migrating to a Logrec log stream.

To start using the Logrec log stream either specify LOGREC=LOGSTREAM in the IEASYSxx parmlib member or, after IPLing with LOGREC=dsname, use the SETLOGRC command to change the Logrec recording medium to a Logrec log stream. Bear in mind though that if you IPL the system with LOGREC=LOGSTREAM, you cannot use the SETLOGRC command to change the Logrec recording medium to a Logrec data set.

Important!

Now you have the Logrec log streams defined and ready, and you have even set up the system to start using them. Are you done with your tasks? The answer is no! You still need to update the EREP jobs that your system uses to start using the Logrec log stream. To do this the Systems Programmer will have to go through the JCL and:

  • Change the SERLOG DD DSN=SYS1.LOGREC statement associated with a Logrec data set to an ACCIN DD DSN=SYS1.SYSPLEX.LOGREC statement, with corresponding SUBSYS parameters, to associate EREP with the logrec log stream.
  • Identify the input as a history data set. Leave the output to a history data set as currently recommended, because all subsequent steps should already use the history data set as input. (Note: using a Logrec log stream as input for multiple steps is not recommended because each subsequent step processes more records than the prior, causing numbers and data in successive reports not to match).
  • Subsequent EREP report steps that normally process history data sets no longer need to concatenate one history data set per system.

No Comments

How to define the Logrec Data Set SYS1.LOGREC

If you want to define a Logrec Data Set, you must first allocate it and then initialize it.

//IFCDIP00 JOB CLASS=A,MSGLEVEL=(1,1),MSGCLASS=X,NOTIFY=&SYSUID
//*------------------------------------------------------------------
//*  CREATE A NEW LOGREC DATASET AND INITIALIZE IT
//*------------------------------------------------------------------
//IFCDIP00 EXEC PGM=IFCDIP00
//SERERDS  DD  DSN=SYS1.LOGREC,DISP=(,CATLG),
//         VOL=SER=MVSRES,UNIT=3390,SPACE=(CYL,3,,CONTIG)
/*

In this example we create and initialize Logrec Data Set SYS1.LOGREC located on volume MVSRES.

Note: the newly allocated Logrec data set will not be used until you initialize it and IPL the system on which it is to be used.

No Comments

The Logrec

Every system is prone for problems and errors and mainframe is no exception. On a mainframe system whenever a hardware failure, selected software errors, and selected system conditions occurs, the system records information about the error in the Logrec data set or the Logrec log stream.

As a Systems Programmer you can choose whether the system will record the Logrec error records in a Logrec data set or in a coupling facility Logrec log stream.

Normally, when a system is not in a sysplex, you can opt to use a Logrec data set. You can choose to use this type of recording by initializing the logrec data set before IPLing the system that will use it.

If however, your systems are on a sysplex you should opt to use a coupling facility Logrec log stream. This does not mean that you can not use a logrec data set for each of the systems that are part of the sysplex. This solution simply makes your life much easier. By using the coupling facility Logrec log stream on a sysplex you eliminate the following:

• Running IFCDIP00 to initialize multiple logrec data sets
• Handling full or emergency data set conditions
• Scheduling the daily offload of logrec data sets
• Concatenating multiple history data sets
• Archiving logrec records

To be able to visualize the content of the Logrec the Systems Programmer will need to create Reports by using the EREP (Environmental Record, Editing, and Printing program). The EREP allows the Systems Programmer to:

• To print reports about the system records
• To determine the history of the system
• To learn about a particular error

No Comments

Logrec Data Set considerations

These are some considerations regarding the Logrec Data Set:

1. You must initialize the Logrec data set before IPLing the system that will use it.

2. To initialize or reinitialize the Logrec data set, use the service aid program IFCDIP00.

3. To clear a full Logrec data set, use EREP. IFCDIP00 creates a header record and a time stamp record for the Logrec data set.

4. The logrec data set is an unmovable data set. If you attempt to move it after IPL using a program, such as a defragmentation program, your system will experience difficulty both reading from and writing to the data set.

No Comments

How the system starts and manages batch jobs

Batch processing is the most fundamental function of z/OS. Many batch jobs are run in parallel and JCL is used to control the operation of each job. Correct use of JCL parameters (especially the DISP parameter in DD statements) allows parallel, asynchronous execution of jobs that may need access to the same data sets.

The job entry subsystem (JES) helps z/OS receive jobs, schedule them for processing, and determine how job output is processed.

An initiator is a system program that processes JCL, sets up the necessary environment in an address space, and runs a batch job in the same address space. Multiple initiators (each in an address space) permit the parallel execution of batch jobs.

One goal of an operating system is to process work while making the best use of system resources. To achieve this goal, resource management is needed during key phases to do the following:

-    Before job processing, reserve input and output resources for jobs.

-    During job processing, manage spooled SYSIN and SYSOUT data.

-    After job processing, free all resources used by the completed jobs, making the resources available to other jobs.

z/OS shares with the Job Entry Subsystem (JES) the management of jobs and resources. JES receives jobs into the system, schedules them for processing by z/OS, and controls their output processing. JES is the manager of the jobs waiting in a queue. It manages the priority of the jobs and their associated input data and output results. The initiator uses the statements in the JCL records to specify the resources required of each individual job after it is released (dispatched) by JES.

During the life of a job, both JES and the z/OS base control program control different phases of the overall processing. Jobs are managed in queues: Jobs that are waiting to run (conversion queue), currently running (execution queue), waiting for their output to be produced (output queue), having their output produced (hard-copy queue), and waiting to be purged from the system (purge queue).

No Comments