Archive for category MVS
EREP Selection Parameters
Posted by Rui Miguel Feio in MVS, Tech - Mainframe on February 9, 2011
The following parameters are used to select the records for EREP to use:
| Parameter | Description |
| CPU=({nnnnnn|Xnnnnn|XXnnnn}
.model [, ...]) |
|
| CPUCUA=(serial.{cua|cuX}
[,serial.{cua|cuX}]…) |
|
| CUA=({[N]addr|[N]addr-[N]addr}[, ...]) |
|
| DATE=({yyddd[,yyddd] | yyddd[-yyddd]}) |
|
| DEV=(type | Ntype[,type | Ntype]…) |
|
| DEVSER=(serial[,serial]…) |
|
| ERRORID=(seqno[,cpuid,asid,
hh,mm,ss,t]) |
|
| LIA | LIBADR=address |
|
| MOD=(model[,model]…) |
|
| MODE={370 | 370XA | ALL} |
|
| SYMCDE={nnnn | nnnX | nnXX | nXXX} |
|
| TERMN=name |
|
| TIME=({hhmm,hhmm | hhmm-hhmm}) |
|
| TYPE=code[code]... |
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]...) |
|
List the Information from the Logrec Data Set
Posted by Rui Miguel Feio in JCL, MVS, Tech - Mainframe on February 8, 2011
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
EREP Report Parameters
Posted by Rui Miguel Feio in MVS, Tech - Mainframe on February 8, 2011
The following parameters are used to request reports from EREP:
| Parameter | Description |
| EVENT=Y or N |
|
| PRINT= AL | DR | NO | PS | PT | SD | SU |
|
| SYSEXN=Y or N |
|
| SYSUM=Y or N |
|
| THRESHOLD=(xxx,yyy) |
|
| TRENDS=Y or N |
|
Create a History Data Set from the Logrec Data Set
Posted by Rui Miguel Feio in JCL, MVS, Tech - Mainframe on February 3, 2011
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
/*
How to clear and re-initialize the Logrec Data Set SYS1.LOGREC
Posted by Rui Miguel Feio in JCL, MVS, Tech - Mainframe on February 3, 2011
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.
Defining a Logrec Log Stream
Posted by Rui Miguel Feio in JCL, MVS, Tech - Mainframe on January 31, 2011
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.
How to define the Logrec Data Set SYS1.LOGREC
Posted by Rui Miguel Feio in JCL, MVS, Tech - Mainframe on January 31, 2011
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.
The Logrec
Posted by Rui Miguel Feio in MVS, Tech - Mainframe on January 29, 2011
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
Logrec Data Set considerations
Posted by Rui Miguel Feio in MVS, Tech - Mainframe on January 29, 2011
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.
How the system starts and manages batch jobs
Posted by Rui Miguel Feio in JES, MVS, Tech - Mainframe on December 11, 2010
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).
Follow Me!