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.
Setting up Virtual Hosts on WampServer
Posted by Rui Miguel Feio in Tech - Web Development, WAMP on January 30, 2011
If you’re a web developer you know how fantastic WampServer is in allowing you to have Apache, MySQL and PHP server locally under Windows. This allows you to test all your websites locally before you upload them into the “real” server.
Now, the problem is that by default if you have two sites (site1 and site2) locally, it’s always a pain having to browse them by using “http://localhost/site1/index.php” as a URL.
The best way is always to make the URL shorter and for this WampServer allows you to create Virtual Hosts. The general idea of Virtual Hosts is
that you can use something like “http://site1″ or “http://site2″ instead of having to use the complete URL.
Here’s how you do it:
1. Edit the “hosts” file on your windows system (usually located at c:\WINDOWS\system32\drivers\etc\)
2. Add the following to the end of the hosts file:
127.0.0.1 site1
127.0.0.1 site2
This tells your computer that any url with a value of ‘site1′ or ‘site2′ should be routed to 127.0.0.1 or more commonly refered to as localhost.
3. Save your changes.
4. Now go to “C:\wamp\bin\apache\Apache2.2.17\conf” and edit file “httpd.conf”
5. Search for “httpd-vhosts.conf”
6. Remove the “#” from the beginning of the line “Include conf/extra/httpd-vhosts.conf”
7. Now go to “C:\wamp\bin\apache\Apache2.2.17\conf\extra” and edit file “httpd-vhosts.conf”
8. Add the following lines to the end of this file:
9. Click on the WampServer icon
10. Select “Restart All Services”
And that’s it! From now on you only have to use “http://site1″ and “http://site2″ as URLs for your 2 local websites.
Notes:
- These instructions may not work for older versions of WampServer.
- On Windows 7 you will need to edit the “hosts” file running Notepad as Administrator.
Change the www root directory on WampServer
Posted by Rui Miguel Feio in Tech - Web Development, WAMP on January 30, 2011
If you do not wish to use “c:/wamp/www/” as your DocumentRoot you simply have to perform the following steps:
1. Click on the WampServer icon
2. Select Apache > httpd.conf
3. Search for “DocumentRoot”
4. Change the path to whatever you wish to be the new Document root directory (make sure to use a forward slash instead of a back slash)
5. Search once again for “DocumentRoot”
6. You will find something like: “”
7. Once again change the path to whatever you wish to be the new Document root directory (make sure to use a forward slash instead of a back slash)
8. Save your changes
9. Click on the WampServer icon
10. Select option “Restart All Services”
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).
System IPL Sequence
Posted by Rui Miguel Feio in MVS, Tech - Mainframe on December 6, 2010
The initialization process begins when the System Programmer or Operator selects the LOAD function at the Hardware Management Console (HMC).
To successfully IPL z/OS, the system programmer needs to supply the following information:
- The device address of the IPL volume
- The LOADxx member that contains pointers to system parameters
- The IODF data set that contains the configuration information
- The device address of the IODF volume
z/OS locates all usable central storage that is online and available, and begins creating the various system areas.
Not all disks attached to a CPU have loadable code on them. A disk that does is generally referred to as an ″IPLable″ disk, and more specifically as the SYSRES volume.
IPLable disks contain a bootstrap module at cylinder 0 track 0. At IPL, this bootstrap is loaded into storage at real address zero and control is passed to it. The bootstrap then reads the IPL control program IEAIPL00 (also known as IPL text) and passes control to it. This in turn starts the more complex task of loading the operating system and executing it.
After the bootstrap is loaded and control is passed to IEAIPL00, IEAIPL00 prepares an environment suitable for starting the programs and modules that make up the operating system, as follows:
1. It clears central storage to zeros before defining storage areas for the master scheduler.
2. It locates the SYS1.NUCLEUS data set on the SYSRES volume and loads a series of programs from it known as IPL Resource Initialization Modules (IRIMs).
3. These IRIMs begin creating the normal operating system environment of control blocks and subsystems.
IPL Resource Initialization Modules (IRIMs)
Some of the more significant tasks performed by the IRIMs are as follows:
- Read the LOADPARM information entered on the hardware console at the time the IPL command was executed.
- Search the volume specified in the LOADPARM member for the IODF data set. IRIM will first attempt to locate LOADxx in SYS0.IPLPARM. If this is unsuccessful, it will look for SYS1.IPLPARM, and so on, up to and including SYS9.IPLPARM. If at this point it still has not been located, the search continues in SYS1.PARMLIB. (If LOADxx cannot be located, the system loads a wait state.)
- If a LOADxx member is found, open and read information including the nucleus suffix (unless overridden in LOADPARM), the Master Catalog name, and the suffix of the IEASYSxx member to be used.
- Load the operating system’s Nucleus.
- Initialize virtual storage in the Master Scheduler address space for the System Queue Area (SQA), the Extended SQA (ESQA), the Local SQA (LSQA), and the Prefixed Save Area (PSA). At the end of the IPL sequence, the PSA will replace IEAIPL00 at real storage location zero, where it will then stay.
- Initialize real storage management, including the segment table for the master scheduler, segment table entries for common storage areas, and the page frame table.
The last of the IRIMs then loads the first part of the Nucleus Initialization Program (NIP), which invokes the Resource Initialization Modules (RIMs), one of the earliest of which starts up communications with the NIP console defined in the IODF.
Nucleus Initialization Program (NIP)
During the NIP stage, the system might prompt the system programmer or operator to provide system parameters that control the operation of z/OS. The system also issues informational messages about the stages of the initialization process. IEASYSnn, a member of PARMLIB, contains parameters and pointers that control the direction that the IPL takes. The system programmer or operator may alter these parameters as necessary.
IEASYSnn, a member of PARMLIB, contains parameters and pointers that control the direction that the IPL takes.
The system continues the initialization process, interpreting and acting on the system parameters that were specified. NIP carries out the following major initialization functions:
- Expands the SQA and the extended SQA by the amounts specified on the SQA system parameter.
- Creates the pageable link pack area (PLPA) and the extended PLPA for a cold start IPL; resets tables to match an existing PLPA and extended PLPA for a quick start or a warm start IPL.
- Loads modules into the fixed link pack area (FLPA) or the extended FLPA. Note that NIP carries out this function only if the FIX system parameter is specified.
- Loads modules into the modified link pack area (MLPA) and the extended MLPA. Note that NIP carries out this function only if the MLPA system parameter is specified.
- Allocates virtual storage for the common service area (CSA) and the extended CSA. The amount of storage allocated depends on the values specified on the CSA system parameter at IPL.
- Page-protects the NUCMAP, PLPA and extended PLPA, MLPA and extended MLPA, FLPA and extended FLPA, and portions of the nucleus. An installation can override page protection of the MLPA and FLPA by specifying NOPROT on the MLPA and FIX system parameters.
Address space creation and subsystem initialization
In addition to initializing system areas, z/OS establishes system component address spaces. It establishes an address space for the Master Scheduler and other system address spaces for various subsystems and system components. Some of the component address spaces are: *MASTER*, ALLOCAS, APPC, CATALOG, and so on.
The Master Scheduler address space is the first system component address space to be created (ASID=1). Then, the Master Scheduler may start the primary job entry subsystem (JES2 or JES3). On many production systems, JES is not started immediately; instead, an automation package starts all tasks in a controlled sequence.
Then other defined subsystems are started. All subsystems are defined in the PARMLIB library, in member IEFSSNxx. These subsystems are secondary subsystems.
The private areas are available only to that address space, but common areas are available to all.
After the system is initialized and the job entry subsystem is active, the installation can submit jobs for processing by using the START, LOGON, or MOUNT command. When a job is activated through START (for batch jobs), LOGON (for time-sharing jobs), or MOUNT, a new address space is allocated.
VTOC (Volume Table of Contents)
Posted by Rui Miguel Feio in Glossary, MVS, Storage, Tech - Mainframe on December 2, 2010
z/OS uses a Catalog and a Volume Table of Contents (VTOC) on each DASD to manage the storage and placement of data sets
The VTOC lists the data sets that reside on its volume, along with information about the location and size of each data set, and other data set attributes.
A standard z/OS utility program, ICKDSF, is used to create the label and VTOC. When a disk volume is initialized with ICKDSF, the owner can specify the location and size of the VTOC. The size can be quite variable, ranging from a few tracks to perhaps 100 tracks, depending on the expected use of the volume. More data sets on the disk volume require more space in the VTOC.
The VTOC also has entries for all the free space on the volume. Allocating space for a data set causes system routines to examine the free space records, update them, and create a new VTOC entry.
Data sets are always an integral number of tracks (or cylinders) and start at the beginning of a track (or cylinder).
You can also create a VTOC with an index. The VTOC index is actually a data set with the name SYS1.VTOCIX.volser, which has entries arranged alphabetically by data set name with pointers to the VTOC entries. It also has bitmaps of the free space on the volume.
A VTOC index allows the user to find the data set much faster.
What is a Catalog?
Posted by Rui Miguel Feio in Glossary, MVS, Tech - Mainframe on December 1, 2010
A catalog describes data set attributes and indicates the volumes on which a data set is located.
When a data set is cataloged, it can be referred to by name without the user needing to specify where the data set is stored. Data sets can be cataloged, uncataloged, or recataloged. All system-managed DASD data sets are cataloged automatically in a catalog.
Cataloging of data sets on magnetic tape is not required, but doing so can simplify users’ jobs.
In z/OS, the Master Catalog and User Catalogs store the locations of data sets. Both disk and tape data sets can be cataloged. To find a data set that you have requested, z/OS must know three pieces of information:
- Data set name
- Volume name
- Unit (the volume device type, such as a 3390 disk or 3590 tape)
You can specify all three values on ISPF panels or in JCL. However, the unit device type and the volume are often not relevant to an end user or application program. A system catalog is used to store and retrieve UNIT and VOLUME location of a data set. In its most basic form, a catalog can provide the unit device type and volume name for any data set that is cataloged. A system catalog provides a simple look-up function. With this facility the user need only provide a data set name.
Master Catalog and User Catalog
A z/OS system always has at least one Master Catalog. If it has a single catalog, this catalog would be the Master Catalog and the location entries for all data sets would be stored in it. A single catalog, however, would be neither efficient nor flexible, so a typical z/OS system uses a master catalog and numerous User Catalogs connected to it.
A User Catalog stores the name and location of a data set (dsn/volume/unit). The master catalog usually stores only a data set High-Level Qualifier (HLQ) with the name of the user catalog, which contains the location of all data sets prefixed by this HLQ. The HLQ is called an alias.
As a general rule, all user data sets in a z/OS installation are cataloged. Uncataloged data sets are rarely needed and their use is often related to recovery problems or installation of new software. Data sets created through ISPF are automatically cataloged.
Follow Me!