UNIT 1 : EVOLUTION OF MVS …………………. …………. 2

PCP(PRIMARY CONTROL PROGRAM)…………………… 3

MULTIPROGRAMMING……………………………………… 4

HASP(HOUSTON AUTOMATIC SPOOLING PRIORITY……. 5

SYSTEM/370 OR OS/VS………………………………………. 6

MVS (MULTIPLE VIRTUAL STORAGE) ………………….. 7

MVS/XA(MVS EXTENDED ARCHITECTURE)…………….. 8

MVS/ESA ( MBS ENTERPRISE SYSTEM ARCHITECTURE)…. 9

UNIT 1: EVOLUTION OF MVS  OVERVIEW:         PCP (Primary Control Program)

       MFT (Multiprogramming with a Fixed number of Tasks)

       MVT (Multiprogramming with Variable number of Tasks)

       HASP (Houston Automatic Spooling Priority)

       ASP (Attached Support Processor)        SYSTEM/370 OR OS/VS

       MVS (Multiple Virtual Storage)

       MVS/XA (MVS Extended Architecture) 

PCP (PRIMARY CONTROL PROGRAM) 

       The IBM‘s first release of OS version is the PCP in the year 1965.

       PCP is the primary control program. It is the primer system and had limited capabilities.          It offered no multiprogramming, no priority scheduling and no input or output spooling facilities.          It was an unreliable system, which “crashed” with regular and predictable frequency.          The JCL used by PCP is the same as what we use today. It became obsolete in the year 1969. 

MULTIPROGRAMMING

MFT Multiprogramming with fixed number of tasks. It was a small improvement in PCP, which offered limited multiprogramming. 

MVT Multiprogramming with variable number of tasks. It is the first reliable system with a comprehensive set of features and was the predecessor of MVS. Both MFT and MVT provided limited spooling capability.

HASP (HOUSTON AUTOMATIC SPOOLING PRIORITY)

HASP A team of IBM employees developed a package, which is superimposed on MFT or MVT, and provides good spooling capabilities. It was called Houston Automatic Spooling Priority. It was made available free to MFT/MVT and soon became popular.   ASP IBM developed another package for MVT that would allow several mainframes to work together under one operating system in a master/slave relationship. This was called ASP-Attached Support Processor. 

SYSTEM/370 OR OS/VS  Continuation of system/360 series, but with virtual storage capabilities and supporting new hardware VS1 and VS2 called virtual storage 1 and 2.  VS1 was basically an MFT system in a virtual environment. VS2 has two versions, the SVS (Single Virtual Storage) and MVS (Multiple Virtual Storage).

MVS (MULTIPLE VIRTUAL STORAGE)     From internal standpoint SVS was a “virtual” MVT and MVS was entirely different. External standpoint both worked like MVT.        In the mid 1970s all versions except VS1 and MVS became obsolete and VS1 became obsolete in 1987 leaving only MVS.HASP and ASP migrated to MVS under the names of JES2 (Job Entry Subsystem 2) and JES3 (Job Entry Subsystem 3).

       MVS provided greater reliability, integrity and performance when compared to the other older versions.     The greater drawback of MVS was the limited availability of virtual storage of 16MB.This was inadequate for large systems like CICS, other databases.

MVS/XA (MVS EXTENDED ARCHITECTURE)  IBM released a new version of MVS, which had a storage availability of 2GB and increased the maximum number of channels and devices. This version is called the MVS/Extended Architecture or MVS/XA.

MVS/ESA (MVS ENTERPRISE SYSTEM ARCHITECTURE)  IBM announced MVS/ESA in the year 1988.It had increased the user to a large amount of storage of 16 terabyte. It offers modern open client/server solutions, object technology, and network connectivity.

UNIT 2 UNIT 2: CONCEPT OF VIRTUAL STORAGE…………………………… 3 CPC…………………………………………………………………………….. 4 UNIPROCESSOR……………………………………………………………... 5 MULTI PROCESSING……………………………………………………….. 6 MULTIPROCESSORS(Under Single OS)……………………………………. 7 MULTIPROCESSORS(Under Different OS)……………………………….. 8 MULTI PROGRAMMING……………………………………………………. 9 CENTRAL STORAGE………………………………………………………… 10 VIRTUAL STORAGE…………………………………………………………. 11 NEED FOR VIRTUAL STORAGE …………………………………………… 12 PAGING…………………………………………………………………………. 13 REGISTER……………………………………………………………………… 14 CONCEPT OF STORAGE KEY………………………………………………. 15 REFERENCE BIT AND CHANGE BIT………………………………………. 16

UNIT 2: CONCEPT OF VIRTUAL STORAGE (Contd.)

THRESHOLD QUEUES……………………………………………. 17 PAGE STEALING ………………………………………………….. 18 PAGE OUT…………………………………………………………… 19 PAGE FAULT………………………………………………………… 20 PAGE IN……………………………………………………………….. 21 SWAPPING…………………………………………………………… 22 SWAP OUT…………………………………………………………… 23 WORK SET…………………………………………………………… 24 DAT (Dynamic Address Translation)……………………………….. 25 DAT (Dynamic Address Translation) contd.……………………….. 26 ADDRESS SPACE…………………………………………………… 27 DATA SPACE………………………………………………………… 28 HIPERSPACES………………………………………………………. 29

UNIT 2: CONCEPT OF VIRTUAL STORAGE  

       CPC        UNIPROCESSOR        MULTIPROCESSING        MULTIPROCESSOR (UNDER SINGLE OS)        MULTIPROCESSOR (UNDER DIFFERENT OS)        MULTIPROGRAMMING        CENTRAL STORAGE        VIRTUAL STORAGE        NEED FOR VIRTUAL STORAGE        PAGING        REGISTER        CONCEPT OF STORAGE KEY        REFERENCE BIT AND CHANGE BIT        THRESHOLD QUEUE        PAGE STEALING        PAGE OUT        PAGE FAULT        PAGE IN        SWAPING        SWAP OUT        WORK SET        SWAP IN

CPC

The Central Processor Complex (CPC) consists of the central processor and channel subsystems and the storage as the hardware and the system application programs, user programs and other tools as the software. The primary program executing on the system is the Operating System (OS).

UNIPROCESSOR

CENTRAL PROCESSOR

OPERATING SYSTEM

STORAGE

CHANNEL SUBSYSTEM

Notes:  The CPC processing only one instruction at a time is called uniprocessor system. The OS manages the instructions to be performed and the resources required by the program. Thus having only a single copy of the OS operating system running under single processor is called a uniprocessor. Though it is simple, no backups can be taken in case of system failure.

MULTI PROCESSING

CENTRAL STORAGE

CPU CPU

SYSTEM

USER 3

SYSTEM

SYSTEM

USER 2

SYSTEM

SYSTEM

USER 1

SYSTEM

Notes:   Under one operating system multiple processors can be connected so that simultaneous processes take place, the processors share the central storage and I/O configuration.

MULTIPROCESSORS (UNDER SINGLE OS)

OPERATING SYSTEM

STORAGE

CHANNEL SUBSYSTEM

CP CP CP CP

Notes: By connecting more than one CPC to the system multiple processing Of instructions can be made possible. In case of failure of one CP the work May be assigned to the other CP. A multiprocessor system running on only a Single copy of OS image is referred to as non-partitionable multiprocessor

MULTIPROCESSORS (UNDER DIFFERENT OS)

Single Image Mode Physically Partitioned Mode

OPERATING SYSTEM

STORAGE

CHANNEL SUBSYSTEM

CP CP CP CP

STORAGE

CSS

CP CP CP CP

OS OS

STORAGE

CSS

Notes: The processor can be physically partitioned and is of two types, Single Image Mode that run under single OS and Physically Partitioned Mode Where processor and other resources are divided to run different operating System copies.

MULTI PROGRAMMING

CENTRAL

STORAGE

SYSTEM

USER1

USER2

USER3

SYSTEM

CPU

Notes: With multi programming, multiple programs have to reside in the central storage. When one program is waiting for I/O operation to complete, the system can interrupt that program, store the information about the program so that the next ready to Execute program gets executed. Once the I/O operation is over, the interrupted

Program gets executed from the point it got interrupted.

 

CENTRAL STORAGE

Z

X

Y

Notes:  The processor storage where the instruction and data it references must reside, for the instruction to be processed is called the central storage. It is divided in to separate areas called the frames of 4K bytes and each area is identified by a unique address space. Faster access and better performance but the available central storage is very limited.

CENTRAL STORAGE VIRTUAL STORAGE

Z

X

Y

X Y Z

Notes:  Virtual storage is the range of addresses available for the users, where the programs that have capacity, more than the central storage can reside. It is divided in to equal areas of 4K called PAGES.  The SVS (Single Virtual Storage) is the first virtual storage that was available to the users. For 24 bit addressing 16 Mega byte addresses is available.   The MVS (Multiple Virtual Storage) was introduced, where each user was given a 16 Mega byte address space.

NEED FOR VIRTUAL STORAGE 

In order to reduce the burden on the central storage, virtual storage was introduced. At the time of execution of program, it is enough if the instruction to be performed and the data it references is residing in the central storage. The entire program need not occupy the central storage.  The user programs first enter the virtual storage and get mapped to 4K pages of contiguous storage. 

PAGING

XY

Z

A X

C

Y

B

X Y Z

A B C

AUXILIARY STORAGE

16M

CENTRAL STORAGE VIRTUAL STORAGE 0

Notes: At the time of execution the pages from the virtual storage is transferred to the central storage frame and the inactive pages from central storage frame is put back to the Auxiliary storage slot or Expanded storage frame. This process of moving the pages into and out of central storage is called Paging.

REGISTER  There are          16 GPRs (General Purpose Registers) available.        16 Access Registers available.        16 Control Registers available.        PSW (Program Status Register)

Notes: The GPRs are used for arithmetic operations as accumulators and used as base and index registers to fetch data from the virtual storage.  The Access Registers are used to access data from other address spaces like data space.  The Control Registers are used by the system to provide information to system facilities such as DAT.  The PSW is a special register, which controls the sequence of execution of instructions, determines the state of CPU.

CONCEPT OF STORAGE KEY

PSW

ACCESS-CONTROL BITSFETCH-PROTECTION BIT

Notes:

In order to ensure data integrity each central storage frame is associated with storage protect key. At the time of execution of the instruction, the instruction pointed by the PSW should match with the storage key of the frame. Otherwise protection exception occurs which causes abnormal termination of program. The common area that gives access to the MVS system has different storage key from application program so that no changes can be made to the MVS modules

REFERENCE BIT AND CHANGE BIT

Notes:  The Reference bit and the Change bit are used to by MVS for determining LRU (Least Recently Used) management of central storage. The reference bit is set ON when a page is referenced and a change bit is set ON when a change is made in the page. The MVS periodically checks the status of these two bits. MVS also turns the bits OFF appropriately.

ACCESS-CONTROL BITSFETCH-PROTECTION BITREFERENCE BITCHANGE BIT

THRESHOLD QUEUES Notes:  The central storage maintains a queue of frames in order to ensure that a frame is available at the time of allocation. Hence a threshold of frames are reserved for the purpose. When the actually available frames falls below this number, page stealing takes place and when it goes above the threshold the stealing is stopped.

AN AVAILABLE FRAME QUEUE SHORTAGE

STEAL

STOP

THRESHOLD

PAGE STEALING  It is the process of monitoring the central storage periodically and placing the least recently used page in the available frame queue. The SRM (System Resource Manager) checks the reference bit and maintains a record of how long a page has not been referenced and sets the reference bit to OFF after a certain amount of time. Theses least recently used frames are more prone to be stolen. When a frame with change bit is ON, then it should be saved.

PAGE OUT

Notes: The least referenced pages are thus sent to the expanded storage or auxiliary storage in order to maintain the threshold value of available frame queue. This process of transferring the page from the central storage is called the Page Out

MYPROG

MYPROG

PAGE FAULT When a page is stolen its entry in the page table is marked invalid. A page fault occurs When DAT tries to convert a virtual address to real address to reference the stolen page.

PAGE IN

Notes: When a page fault occurs, an available central storage frame is allocated for the requested page and DAT has the capability to bring the page to the central storage from the expanded storage or the auxiliary storage.

MYPROG

SWAPPING Notes: Swapping is the movement of address spaces from and to the central storage depending on the current load on the system. SWAP-OUT AN ADDRESS SPACE SWAP-IN AN ADDRESS SPACE

 

SWAP OUT

Swap out is the movement of the address space from the central storage to the expanded storage or auxiliary storage. If a user is waiting for input or output for a long duration then the SRM (System Resource Manager) takes out the address space from central storage frame.

THE SET OF PAGES THAT ARE ACTIVE OR RECENTLY REFERENCED

MYPROG

WORK SET  It is a subset of pages associated with a particular address space, which are recently referenced and the associated segment and page tables of the page is recorded. This is established to re-establish the address space at latter time.  Swap In:  Swap in is the movement of address space in to the central storage using the work set.

DAT (DYNAMIC ADDRESS TRANSLATION) SEGMENT PAGE DISPLACEMENT NUMBER NUMBER WITHIN PAGE

0 0 2 0 A D 4 0

SEGMENT PAGE

TABLE TABLE

DAT (DYNAMIC ADDRESS TRANSLATION) Cont..          To execute in central storage, a program’s virtual addresses must be translated in to real address at the tine the instructions are executed. This translation accomplished by the Dynamic Address Translation (DAT) hardware.

      DAT uses the left-most 11 bits of the virtual address to calculate an Index in to the segment table. The entry at that offset contains the real Address of the beginning of the page table for that segment.

       Then, DAT uses the next 8 bits of the virtual address to calculate an In to the page table. The entry at that offset contains the real address of The central storage frames that currently holds the page.

      Finally, DAT combines the real address of the central storage frame with the displacement provided by the right-most 12 bits of the virtual address. The result is a real address referring to a byte of central storage.

       Each address space has its own segment table, and DAT needs to know which segment table to use to begin the translation process. Each processor has a segment Table Origin Register (STOR) that is used to point to the segment table for a particular address space.

ADDRESS SPACE

MYPROG

COMMON

2GB

16 MB

     A 2-gigabyte range of virtual address is called an address space. An address space is provides the capability for a program to address up to 2 GB of virtual storage. An address space represents a user in the system.

    Frames of central storage will be occupied by pages from many different address spaces.

    The address space provides the addressing structure that will be used by programs mapped into that address space. The address space addresses are virtual addresses.    As the program executes, the virtual addresses will be converted to real addresses.

    The system area called the common area maps the executable MVS code and the control blocks and work areas needed by all address spaces in the system. The common area is mapped around the 16 MB line.

    MYPROG will be mapped into an address space and will probably use only a small part of the 2- gigabyte addressing range.

   My address space has addressability to MVS system functions, such as the nucleus and the link pack areas that are mapped in the common area of every address space.

DATA SPACE          Data spaces can be viewed as extensions to address spaces.

       A data space is owned by an address space but may be accessed by multiple address spaces

.      Programs mapped in to address spaces reference and change the data in data spaces.

     Virtual storage pages associated with a data space are “backed” by central, expanded and auxiliary storage. They are managed by VSM (Virtual Storage Manager), RSM (Real Storage Manager) and ASM (Auxiliary Storage Manager) in the same manner as address space pages.

     The size data space, specified when it is created, may be as small as 4 KB or as large as 2 GB.      The entire addressing range in a data space is available for data; there is no common system area.      A data space may be defined as being accessible by only one address space or accessible by multiple address spaces. 

HIPERSPACES

      The purpose of Hiperspaces (High Performance spaces) is to provide a mechanism that allows application to explicitly use expanded storage as a substitute for I/O operations.

     Unlike a data space, a Hiperspace is not “backed” by central storage. It is normally “backed”

by expanded storage, although low-usage pages may overflow to auxiliary storage.

      Unlike data in a data space, data in a Hiperspace is not referenced directly. It must be moved to an address space for manipulation similar to the way that data transfer takes place for I/O operations. However, there is no I/O operation – the data simply moves between central storage and expanded storage.       Applications may consider using a hiperspace as a fast-response repository for application data. Once the data has been staged in to expanded storage, subsequent requests no longer require I/O operations to the database.       VSAM provides the capability to use a Hiperspace to hold large numbers of VSAM buffers to reduce DASD I/O for repeated retrieval of data. This capability of VSAM can be easily activated through the most recent releases of CICS and IMS or through a facility known as Batch LSR (Local Shared Resources).

        An application may also eliminate I/O operations associated with work or scratch data sets by using Hiperspaces as temporary storage to replace DASD work files. DFSORT Release 11 provides a Hipersorting capability by using a Hiperspace instead of or in addition to intermediate DASD work files.

UNIT 3:

UNIT 3: INITIALIZATION …………………………………………………………… … 4 INITIALIZATION ……………………………………………………………………… …5 INITIALIZATION STEPS…………………………………………………………………6 SYSTEMS DATASETS …………………………………………………………………….7 SYSTEMS LIBRARYORGANIZATION……………………………………………..… ..8 SYSRES VOLUME (SYSTEM RESIDENCE) ……………………………………………9 SYS1.NUCLEUS ………………………………………………………………………..… .10 ADDITIONAL SYSTEM LIBRARIES ….…………………………………………..……11 INPUT OUTPUT DEFINITION FILES DATASET (IODF)…………………………… 12 SYS1.PARMLIB…………………………………………………………………………….13 SYS1.PARMLIB(LOADxx) ……………………………………………………………….14 HARDWARE REQIREMENT …………………………………………………………….15 INITIALIZATION PROCESS ……………………………………………………………..16 THE INITIAL PROGRAM LOAD ………………………………………………………..17 NUCLEUS SELECTION …………………………………………………………………..18 LOADXX AND IODF LOCATION ……………………………………………………… 19 MESSAGE SUPPRESSION ………………………………………………………………..20 NUCLEUS IDENTIFIER …………………………………………………………………..21 LOADING THE NUCLEUS………………………………………………………………. 22 NUCLISTxx …………………………………………………………………………………23 MASTER CATALOG LOCATION ……………………………………………………….24

OPERATOR PROMPT(MASTER CATALOG)…………………………………… 25 SYS1.PARMLIB………………………………………………………………………. 26 IEASYSnn…………………………………………………………………………… 27 OPERATOR ………………………………………………………………………… 28 THE FIRST ADDRESS SPACE…………………………………………………… 29 THE LINK PACK AREA ………………………………………………………….. 30 THE LINK PACK AREA (CONTD) ……………………………………………… 31 CSA AND SQA BOUNDARIES ……………………………………………………. 32 MASTER SCHEDULER …………………………………………………………… 33 SYSTEM ADDRESS SPACES …………………………………………………… 34 START COMMAND ………………………………………………………………. 35 SYS1.PROCLIB …………………………………………………………………… 36 SYS1.PROCLIB (CONTD.) ………………………………………………………. 37 LIBRARY LookASIDE(LLA) ……………………………………………………. 38 VIRTUAL LOOKASIDE FACILITY …………………………………………… 39

UNIT 3: INITIALIZATION         INITIALIZATION

       INITIALIZATION STEPS

       SYSTEM DATASETS

       SYSTEM LIBRARY ORGANIZATION

       SYSRES VOLUME (SYSTEM RESIDENCE)        SYS1.NUCLEUS        ADDITIONAL SYSTEM LIBRARIES        INPUT OUTPUT DEFINITION FILES DATASET (IODF)

INITIALIZATION   System initialization is the process by which the OS loads the system Code from the selected library in to the central storage. This process defines the OS to system. The system requires initializing

       After generating a new system       After changes have been made to the system

       After a system failure

INITIALIZATION STEPS         System library requirements         Hardware requirements

        The initialization process

        Starting system address spaces

        Starting other address spaces 

SYSTEM DATASETS  The system data sets are members of PDS. The exceptions are           Master catalogs the page and swaps datasets SYS1.MANnn, and the IODF, which are VSAM datasets.

        SYS1.LOGTEC, SYS1.DUMPnn that are sequential datasets.

SYSTEM LIBRARY ORGANIZATION

A

BC

A

B

C

DIRECTORY

MEMBER

Most of the system datasets are members in partitioned organization, referred to as libraries. The data area of a partitioned data set is composed of one or more sequential sub areas called members, a DIRECTORY entry points to the beginning of each member.  The members of system libraries are programs, procedures, parameters, commands, and tables used during the execution of the system.

SYSRES VOLUME (SYSTEM RESIDENCE)

SYS1.NUCLEUSCODE

SYS1.SVCLIBERROR RECOVERY ROUTINE

IPLTEXT OR IPL PROGRAM

IPL Stands for Initial Program Load. The operator must identify the unit address of the system residence volume (SYSRES) to the system during system initialization. The SYSRES volume contains special data sets required by the initialization process.

SYS1.NUCLEUS 

It contains 1.     At least one IEANC 0n member, which is the resident portion of the control program. 2.     A pointer to the Master Catalog. 3.     A pointer to an Alternate Master Catalog. 4.     The Nucleus Initialization Program (NIP).

ADDITIONAL SYSTEM LIBRARIES

SYS1.LPALIB

SYS1.LINKLIB

SYS1.PARMLIB

Notes: During the IPL processes the OS loads system coeds into storage from different system libraries. SYS1.LPALIB is the Link Pack Area Library that contains Pageable system routines. The link pack library that contains re-entrant code such as access method, supervisor routines, JES routines and user-written routines. SYS1.LINKLIB is the Link Library that contains loadable system routines such as utility programs, assembler, linkage editor, service aids and device support modules. SYS1.PARMLIB is the parameter library that contains system parameters such as IBM supplied and installation

created system parameters.

INPUT OUTPUT DEFINITION FILES DATASET (IODF)

       I/O Definition file contains

       I/O configuration

       Dynamic device allocation information        Esoteric names

       Initialization console information

Notes: The IODF Dataset is a VSAM dataset, which contains the hardware and software I/O configuration information. The IODF dataset is created using hardware configuration definition facility (HCD) and is used when creating input to IOCP program and during initialization of OS/390 operating system. 

SYS1.PARMLIB       The system programmer tailors the members of the PARMLIB dataset. IEASYSnn, which contains values, that specifies the sizes of system areas, W hich are built at IPL time.

       It also contains pointers to other members of SYS1.PARMLIB COMMNDnn which contains commands that will be automatically issued at the end of the initialization process.

        CONSOLnn which defines the console configuration including the master console alternate console, and up to 98 secondary consoles.

 

SYS1.PARMLIB (LOADxx)

LOADxx is required to IPL the system. The statements in the LOADxx member select  1.     The I/O configuration 2.     The nucleus based on the suffix of the ID specified on the NUCLEUS statement. 3.     The master catalog specified in the SYSCAT statement. 4. The IEASYSxx member based on the SYSPARM statement.

PARMLIB

LOADxx

MVSCPIODF

NUCLEUS

SYSCAT SYSPARM

HARDWARE REQUIREMENT 

    The hardware has its own built-in console, which is used to start the IPL process and manage other aspects of the hardware.           The installation must identify another terminal to be used as the OS console. OS will communicate with the operator through this console. 

INITIALIZATION PROCESS  STARTING MVS         INITIALIZATION PROCESS         STARTING SYSTEM ADDRESS SPACES

       STARTING OTHER ADDRESS SPACES

Notes:  The initialization process starts with the loading of the IPL text and the nucleus, which also contains the Nucleus Initialization Program (NIP). NIP creates the common area in central storage. The creation of the common system area is done by locating the master catalog and other system data sets and then initializing OS/390 using the information in SYS1.PARMLIB. The next step is to build the first address space and create the other system address spaces.

THE INITIAL PROGRAM LOAD          LOAD NUCLEUS        LOCATE MASTER CATALOG AND OTHER SYSTEM DATA SETS

       INITIALIZE MVS USING SYS1.PARMLIB

       BUILD FIRST ADDRESS SPACE

       CREATEOTHER SYSTEM ADDRESS SPACES

Notes:  The initialization process starts with the loading of the PL text and the nucleus, which also contains the Nucleus Initialization Program (NIP). NIP creates the common area in central storage. The creation of the common system area is done by locating the master catalog and other system data and then initializing OS/390 using the information in SYS1.PARMLIB. The next step is to build the first address space and create the other system address spaces.

 

NUCLEUS SELECTION

SYSCTL

A= Initialize SCP

1Load Unit ADDR 2502Load PARM.DDDDxxsn3Initialize SCP

B= Standalone DumpAuto store Status = On

1Load Unit ADDR2Initiate SADMP

Command === A3

Notes:

  The operator supplies the following information to the hardware. A1 – Address of the system residence volume A2 – Load parameter information A3 – Begin system Initialization.  A system control Program (SCP) is an IBM – supplied program that is fundamental to the operation of the system. It interfaces with program products, user programs, and hardware.  The SYSRES volume must be entered to locate the IPL text. The load parameter information identifies the volume the Input Output Definition File (IODF) is located on, the LOADxx member of SYS1.PARMLIB to be used, and information about message suppression during initialization.

 

LOADXX AND IODF LOCATION

Hlev. LODF

LOAD41IODF

DDDD XX SN

025041

OPERATOR TO IDENTIFY PARMLIB DEVICE AND LOADXX

0250

The LOAD PARM field of the SYSCTL frame contains  DDDD= Address of the device that contains SYS1. PARMLIB and the IODF.  XX – Suffix of the LOADxx member in SYS1.PARMLIB. S - Message suppression N - Suffix of the IEANUCxx member is SYS1.NUCLEUS.  The first four characters identify the volume that contains the IODF. The next tow identifies the suffix of the load member. If the LOADxx member is located in the SYSn.IPLPARM data set it must be located on that volume also. It may be located in SYS1.PARMLIB.

MESSAGE SUPPRESSION

Display MessagePrompt

Display MessageUse load xx

SUPPRESSMESSAGES

USE LOADxx

The S field is the Initialization Message suppression Indicator (IMSI) that is used to minimize operator involvement.

Notes:  The S field is used to indicate whether to suppress messages and prompts that would normally be sent to the operator. These messages are recorded in the hard-copy log and time stamped. The operator will be prompted for the master catalog and system parameters only if the data is missing form LOADxx. Coding A or P enables the operator to override the master catalog and system parameters specifications in LOADxx. The recommendation is to use a blank for P as a general practice and an A for Debugging.

NUCLEUS IDENTIFIER

• Nucleus identifier: the N field is the alternate nucleus indicator. • The N field is used to indicate whether an alternate nucleus is to be selected. • If blank, IEANUC01 is loaded unless nucleus statement of LOADxx specifies.

• If the value is 1 to 9, then it is used as the suffix and it overrides the LOADxx specification

LOADING THE NUCLEUS

IEANUC01

OTHER

MODULES

IEANS001

IEANS002

IEANC250

NUCLEUS(NIP)

Notes:

  The IPL program loads the selected members of the SYS1.NUCLEUS. Once the resident code (IEANUCnn) and the other code identified in the NUCLIST member of the SYS1.PARMLIB have been loaded the result is called the OS NUCLEUS. The nucleus initialization program (NIP) resides in SYS1.NUCLEUS and receives control from IPL program. This IPL program will inurn select the proper members from the SYS1.NUCLEUS and create the NUCLEUS .The members used will depend on the suffix specified for the nucleus in either the LOAD PARM or LOADxx, and the NUCLIST member of SYS1.PARMLIB. Only one copy of the resident nucleus code is required (IEANUC01). The I/O configuration from the IODF is loaded in to the System Queue Area (SQA).

NUCLSTxx

• The NUCLSTxx member of SYS1.PARMLIB or SYSn, IPLPARM identifies modules in SYS1.NUCLEUS that are to be included in the nucleus when the system is IPLed.

• The NUCLSTxx member identifies modules that are to be included in the nucleus when the system is IPLed. The NUCLSTxx member is identified through the NUCLST statement in LOADxx.

• The NUCLSTxx member must reside in the dataset as LOADxx (SYS1.PARMLIB or SYSN.IPLPARM).

MASTER CATALOG LOCATION • The master catalog contains pointers to system datasets, page and swap data sets and user catalogs.

• The alternate master catalog is a backup for the master catalog. In multi system environment the master catalog may be shared.

• The SYSCAT keyword in the LOADxx member identifies the Master Catalog.

OPERATOR PROMPT (MASTER CATALOG) The specify master catalog message is generated by the Nucleus Initialization Program (NIP). The operator specifies whether the master catalog or the alternate master catalog should be used

during this initialization. If the master catalog is identified in LoADxx and message suppression is active the operator may not be prompted to specify master a\catalog.

MVS CONSOLE 

SYSTEM-SPECIFY MASTER CATALOG

OPERATOR-ENTER FOR DEFAULT MASTER CATALOG

XX-AND ENTER FOR ALTERNATE MASTER CATALOG

SYS1.PARMLIB  SYS1.PARMLIB is a partitioned data set that contains members that NIP uses to tailor the system to an installation’s unique requirements. The SYS1.PARMLIB data set is a PDS that is used to customize OS system at IPL time.

IEASYSnn    The IEASYSnn members of SYS1.PARMLIB provide tow types of information

System values such as the size of virtual storage areas, which will be mapped out during system initialization.

Pointers to other members of SYS1.PARMLIB, which will be, referenced during system initialization.

The IEASYSxx member specifies the installation’s customization information and members to be used during the IPL process. Such things as how much additional area should be set aside for SQA or CSA, what the maximum number of users will be, and what suffix of COMMND member to use.

IEASYS00 has to be left to its default value and IEASTSxx member has to be created to override the information in IEASYS00.

OPERATOR PROMPT The following members of SYS1.PARMLIB and their associated parameters were read in the sequence: IEASYS00 MAXUSER=36,CON=00 IEASYS01 CMD (00,01), CON=01 IEASYS02 CMD=02, MAXUSER=100 The operator can override any parameter. The active IEASYSxx member can be specified in the LOADxx member of SYS1PARMLIB. If message suppression is active, the operator may not be prompted to specify system parameters. IEASYSxx is used to create the initial address space in the system. The first address space will be the template for all other address spaces created. MVS CONSOLE

SYSTEM-SPECIFY SYSTEM PARAMETERS

OPERATOR-SYSP=(01,02)

Notes: The following members of SYS1.PARMLIB and their associated parameters were read in the sequence: IEASYS00 MAXUSER=36,CON=00 IEASYS01 CMD (00,01), CON=01 IEASYS02 CMD=02, MAXUSER=100 The operator can override any parameter. The active IEASYSxx member can be specified in the LOADxx member of SYS1PARMLIB. If message suppression is active, the operator may not be prompted to specify system parameters. IEASYSxx is used to create the initial address space in the system. The first address space will be the template for all other address spaces created.

THE FIRST ADDRESS SPACE

GENERAL VIRTUAL STORAGE LAYOUT

SYSTEM CODE AND

DATA AREAS

PRIVATE EXTENDED

COMMON

PRIVATE EXTENDED

2GB

16MB

Notes: The Nucleus Initialization Program (NIP) is responsible for building the first address space. The virtual address space is two GB of virtual storage divided in to private and common areas. The private area is Unique to every use

and can contain the user program and data. The common area is shared by every user and contains the system code and data areas. This is the first and only time the common areas of virtual storage are built.

THE LINK PACK AREA

PRIVATE

LINK PACK AREAS

NUCLEUS

LINK PACK AREAS

PRIVATE

SYS1.LPALIB

C

O

M

M

O

N

THE LINK PACK AREA (Cont..)

·     All modules in SYS1.LPALIB or any system library concatenated to SYS1.LPALIB are loaded in to the Link Pack Area (LPA).

·      The Link Pack Area may be divided in to three areas: The Fixed Link Pack Area (FLPA) The Modifies Link Pack Area (MLPA) The Pageable Link Pack Area (PLPA).

·        The NIP uses information from IEASYSxx to identify which members from SYS1.PARMLIB to use in creating the LPA.

·       The LPALSTnn member of SYS1.PARMLIB contains the names of program libraries that the system will concatenate to SYS1.LPALIB.   ·         The modules in SYS1.LPALIB and the concatenated libraries are loaded in to link pack area of common at initialization time.

·         The PLPA will be created at IPL time from the modules located in SYS1.LPALIB and the concatenated libraries when a COLD START is specified.

·        MLPA and FLPA will be created when either a COLDMWARM or QUICK start is specified. The programmer may specify a list of modules to be placed in FLPA in the IEAFIXxx member of SYS1.PARMLIB. The programmer may specify a list of modules to be placed in MLPA in the IEALPAxx member of SYS1.PARMLIB. SYS1.LPALIB contains reentrant code such as access methods, system routines, Job Entry Subsystem (JES) routines, and terminal routines for TSO users.

CSA AND SQA BOUNDARIES

PRIVATE

CSA

LPAs

SQA

NUCLEUS

SQA

LPAs

CSA

PRIVATE

SYSTEM AND USER WORK AREAS

SYSTEM TABLES CONTROL BLOCK

Notes:   The sizes of the Common Service Area (CSA) and the System Queue Area (SQA) are fixed at initialization time during the creation of the common area. The spaces left in the address space after the common areas are created are the private areas.

The NIP checks IEASYSxx to determine the sizes of the Common Service Area (CSA) and the System Queue Area (SQA). These areas of common are fixed in size at initialization time. Once the common area has been created in storage, both central and virtual storage, the remaining portions of the two GB address space become the private areas.

MASTER SCHEDULER

  PRIVATE

COMMON

AREAS

PRIVATE

ADDRESS

SPACE

CREATE

ROUTINES

AND

MASTER

TRACE

TABLE

Notes:  The Master Scheduler address space is the first address space created. The Address Space Create routines create all other address spaces. The Master Trace Table is a series of buffers used to trace OS console messages. The Master Scheduler address space creates routines handle creation of all other address spaces. The address space deletion routines handle deletion of all address spaces when required. The Master Trace table buffer is also contained in the private area of the Master Scheduler address space and is used to record all of the messages, responses and commands that are sent to and from OS console. 

SYTEM ADDRESS SPACES

 • System address spaces are address spaces that contain executable system code in the private area. They were created to provide Virtual Storage Constraint Relief (VSCR).

• These are the system address spaces that will be built either automatically or through START command during OS system initialization.

• System address spaces were created to reduce virtual storage shortages below the 16 MB line. They provide VSCR by expanding the system horizontally instead of vertically with code from the common areas. • The System Address Spaces are Master Scheduler, CAS etc. 

 

START COMMAND

INITIALIZATION PROCESS

STARTIEACMD00

COMMNDxx

SYS1.PARMLIB

Notes:  The address spaces not created automatically must be started by a START command. Address spaces that are created with a START command are called Started Task Address Spaces. The IEACMD00 member of SYS1.PARMLIB contains system-related start commands such as a command to start the Library Lookaside address space. The COMMNDnn member contains user-related start commands such as a command to start DB2 or CICS.The operator may also issue START commands.   

SYS1.PROCLIB

JES2

ADDRESS

SPACE

S JES2

JES2 PROCLLA PROCVTAM PROC

HASJES20

SYS1.PROCLIB

PGM LIBRARY

SYS1.PROCLIB  //JES2 PROC //IEFPROC EXEC PGM= HASJES20 //PARMLIB DD DSN=SYS1.PARMLIB  

SYS1.PROCLIB (Cont..)

The START command identifies a procedure in SYS1.PROCLIN that will be used during the creation of this address space.

When the start command is issued the system searches SYS1.PROCLIB for the procedure name indicated on the start command.

The procedure contains JCL that will identify the program to execute in the private area of the address space created by the master scheduler.  

LIBRARY LookAside (LLA)

LLA contains the directory entries of SYS1.LINKLIB the libraries named in the LNKLSTxx member of SYS1.PARMLIB and user specified libraries listed in the PARMLIB member CSVLLAxx.

Owns a data space, which may contain program load module. 

VIRTUAL LOOKASIDE FACILITY

• The Virtual Lookaside Facility (VLF) provides a set of services that allow programs to store data objects in data spaces managed by VLF routines.

• These objects are retrieved from the data space and placed in the user’s address space, as they are needed.  

 

 

UNIT4

INTEGRATED CATALOG FACILITY TYPES OF CATALOG

INTEGRATED CATALOG FACILITY CATALOG STRUCTURE

INTEGRATED CATALOG FACILITY CATALOG STRUCTURE (Cont…)

ADVANTAGES OF ICF

ADVANTAGES OF ICF (Cont…)

THE MASTER CATALOG FACILITY

CONTENTS OF THE MASTER CATALOG

CONTENTS OF THE MASTER CATALOG (Cont…)

             

Contents(Contd.)

THE MASTER CATALOG DURING SYSTEM

ALTERNATE MASTER CATALOG

ALTERNATE MASTER CATALOG (Cont…)

PRINTING A CATALOG OR VVDS

LISTING A VOLUME TABLE OF CONTENTS (VTOC)

DELETING CATALOG ENTRIES

UNIT 4.INTEGRATED CATALOG FACILITY  

A catalog is a data set which contains information about other data sets.   It provides users with the ability to locate a data set by name, without

knowing where the data set resides.

By cataloging data sets, the user will need to know less about       the storage setup.

   Thus, data can be moved from one device to another, without requiring a change in JCL DD statements which refer to an existing data set.

Cataloging data sets also simplifies backup and recovery procedures.

Catalogs are the central information point for VSAM data sets.

All VSAM data sets must be cataloged.

In addition, all SMS-managed data sets must be cataloged.

TYPES OF CATALOG

DFSMS/MVS provides three types of catalogs

1. Integrated catalog facility catalogs. 2. VSAM catalogs 3. Operating system control volumes (OS CVOLs).

   Notes:

The integrated catalog facility should satisfy all cataloging needs. Any type of data set or object can be cataloged in an integrated catalog facility catalog. Functions provided for VSAM catalogs and OS CVOLs are for compatibility only. Many advanced MVS/DFP functions require the use of integrated catalog facility catalogs for example, the Storage Management Subsystem. 

INTEGRATED CATALOG FACILITY CATALOG STRUCTURE  An integrated catalog facility catalog consists of two separate kinds of data sets:  1. Basic Catalog Structure (BCS) 2. VSAM volume data set (VVDS).   The BCS can be considered the catalog, whereas the VVDS can be considered an extension of the volume table of contents (VTOC).  The basic catalog structure is a VSAM key-sequenced data set. It uses the data set name of entries to store and retrieve data set information.

For VSAM data sets, the BCS contains volume, security, ownership, and association information.

For non-VSAM data sets, the BCS contains volume, ownership, and association information.  The VSAM volume data set is a VSAM entry-sequenced data set.

ICF CATALOG STRUCTURE(Contd.)  A VVDS resides on every volume that contains a VSAM or SMS-managed

data set cataloged in an integrated catalog facility catalog.

It contains the data set characteristics, extent information, and the volume-related information of the VSAM data sets cataloged in the BCS.

If Storage Management Subsystem (SMS) is used, the VVDS also contains data set characteristics and volume-related information for the Non-VSAM, SMS-managed data sets on the volume.  The Volume Table of Contents and the VTOC index are system data sets which maintain extent and allocation information for a volume.

The VTOC is used to find empty space for new allocations and to locate non-VSAM data sets.

ICF CATALOG STRUCTURE(Contd.) For all VSAM data sets, and for SMS-managed non-VSAM data sets, the VTOC is used to obtain information not kept in the VVDS.  VVDS records for VSAM data sets are called “VSAM volume records” (VVRs). Those for SMS-managed non-VSAM data sets are called “non-VSAM volume records” (NVRs). If a non-VSAM data set spans volumes, its NVR is in the VVDS of the data set's first volume. Since a BCS is a VSAM data set, it also has a VVR in the VVDS.  Every integrated catalog facility catalog consists of one BCS and one or more VVDSs. A BCS does not “own” a VVDS: more than one BCS can have entries for a single VVDS. Every VVDS which is connected to a BCS has an entry in the BCS.  For example,   Figure below shows a possible relationship between two BCSs and three VVDSs on three disk volumes. “BCS.A” has entries for data sets residing on each of the three volumes. “BCS.C” has entries for data sets residing on volumes B and C.

Since each volume has data sets cataloged in an integrated catalog facility catalog, each volume contains a VVDS.

ICF CATALOG STRUCTURE(Contd.)

BCS.A resides on volume A with VVDS.A. Both the VVDS and the BCS have entries for each other. All three VVDSs are cataloged in BCS.A. BCS.C, residing on volume C, contains entries for VVDS.C and VVDS.B. Notice that a VVDS has entries for all VSAM and SMS-managed data sets on its volume, whereas a BCS can have entries for data sets residing on any volume.

ICF CATALOG STRUCTURE(Contd.)

VVDS.A (BCS.A) DS1BCS.A (VVDS.A) (VVDS.C) (VVDS.B) (DS1) (DS2) (DS4)

DS1

VVDS.B (DS2) (DS3)

DS2

DS3

VVDS.C (BCS.C) (DS4) (DS5)BCS.C (VVDS.C) (VVDS.B) (DS5) (DS3)

DS4

DS5

ICF CATALOG STRUCTURE(Contd.)

Figure illustrates how data set entries are contained in both the VVDS and the BCS. Information about a data set is also contained in the VTOC of the volume on which the data set resides, even if the data set is cataloged.

To successfully perform all possible operations on a cataloged data set using the catalog, all three elements, the VVDS, BCS, and VTOC, must be synchronized. That is, any equivalent information contained in the BCS and VVDS entries for the data set,and the VTOC DSCB for the data set, must be the same. This is normally done automatically.

However, if the catalog components, and the VTOC, become unsynchronized, A configuration of integrated catalog facility catalogs depends on a master catalog.A master catalog has the same structure as any other integrated catalog facility2 DFSMS/MVS V1R4 Managing Catalogs.

What makes it a master catalog is that all BCSs are cataloged in it, aswell as certain data sets called “system data sets” (for instance, SYS1.LINKLIB and other “SYS1” data sets).

ADVANTAGES OF ICF 

The integrated catalog facility offers significant advantages over OS CVOLs and VSAM catalogs.

Although OS CVOLs and VSAM catalogs are still supported in the DFSMS/MVS environment, integrated catalog facility catalogs offer superior performance, capability, usability, and maintainability.  Performance 

       Integrated catalog facility catalogs can be updated faster than VSAM catalogs or OS CVOLs.         The catalog information that requires the most frequent updates is physically located in the VVDS on the same volume as the data sets, allowing faster access.

         A catalog request is expedited because fewer I/O operations are        needed. Related entries, such as a cluster and its alternate index, are processed together.

ADVANTAGES OF ICF (Contd..)

Capability          The VSAM catalog concept of catalog ownership of a volume does not apply to integrated

catalog facility catalogs.

         An integrated catalog facility catalog can have data sets cataloged on any number of volumes.       The BCS can have as many as 123 extents on one volume. One volume can have multiple

integrated catalog facility catalogs on it.

      All the necessary control information is recorded in the VVDS residing on that volume.

ADVANTAGES OF ICF (Contd..)

Usability        When defining an integrated catalog facility catalog, you have more control because you can

specify parameters that cannot be specified in a VSAM catalog.         With the commands provided, you can reorganize catalogs, move catalogs to devices

of different types, merge two catalogs into one, split one catalog into two or more catalogs, share catalogs, and create portable copies.

         Data sets cataloged in an integrated catalog facility catalog are similar to

VSAM unique data sets; therefore, no VSAM data spaces are necessary.      Significant space savings for generation data groups are achieved in the integrated catalog facility catalog by reusing space when an old generation is deleted and

by using an improved method of recording generation data groups.  

Maintainability       Maintainability is improved by simpler backup and recovery procedures and use of

the DIAGNOSE and EXAMINE commands.

THE MASTER CATALOG  

     There is no structural difference between a master catalog and a user catalog. What makes a master catalog different is how it is used, and what data sets

are cataloged in it.        Each system has one active master catalog. The master catalog does not have to

reside on the system residence volume.  

For performance, recovery, and reliability, integrated catalog facility catalogs are used.

CONTENTS OF THE MASTER CATALOG 

    The master catalog for a system must contain entries for all user catalogs,and their aliases, which the system uses.

       The only other data sets which you should catalog in the master catalog are the

system, or “SYS1,” data sets.        These data sets must be cataloged in the master catalog for proper system initialization.  

Figure shows the content and connections of a master catalog. 

VTOCVVDS

SYS1.ICFCAT.A1 (datasets) (VVDSs)

SYS1.PARMLIB

User data

VTOC and VVDS

SYS1.MASTER.ICFCAT (SYS1.ICFCAT.A1) (User1) cat alias (User2) cat alias (SYS1.ICFCAT.A2) (User3) cat alias

SYS1.PARMLIB(other sys1 datasets)(other BCSs and VVDSs)(other cat aliases)

user data

VTOCVVDS

SYS1.ICFCAT.A1 (datasets) (VVDSs)

User data and system data

CONTENTS OF THE MASTER CATALOG (Cont..)

     If the installation has multiple, interconnected systems, the master catalogs

of each system can be connected to the master catalogs of each of the other systems.        A master catalog on one system is a user catalog on the other systems.       The SMS complexes can be combined into a single SMS complex and eliminate

additional control data sets.        If SMS is not used, as many systems as is supported can be connected by the channel.

RACF and appropriate alias naming conventions can prevent users on one system from cataloging data sets in the master catalog of another system.

CONTENTS OF THE MASTER CATALOG (Cont..)

For ease of backup and recovery of the master catalog, no user data sets should be cataloged in the master catalog.

        If you deny update to the master catalog for most of your users, there is typically

no update activity for the master catalog.        This makes the master catalog ideal for in-storage catalog (ISC) caching, and a

poor candidate for the catalog data space cache.       Each system has its own master catalog. You identify the master catalog in

the SYSCAT xx member of SYS1.NUCLEUS, or the LOAD xx member of SYS1.PARMLIB. (See “Identifying the Master Catalog and Initial Configuration

(SYSCATxx)” on page 32, and “Bypassing SYSCATxx with LOADxx” on page 34 for more information.)

THE MASTER CATALOG DURING SYSTEM INITIALIZATION 

During a system initialization, the master catalog is read so that system data sets and catalogs can be located.        Their catalog entries are placed in the in-storage catalog cache as they are read.

Catalog aliases are also read during system initialization, but they are placed in an alias table separate from the in-storage catalog.

 The master catalog only contains entries for system data sets, catalogs, and catalog aliases, the entire master catalog is in main storage by the completion of the system initialization.

ALTERNATE MASTER CATALOG  

        Since, the master catalog is vital to the functioning of an MVS system, you should create an alternate master catalog which can be used in a system initial program load (IPL) if the regular master catalog becomes damaged.

       At minimum, an alternate master catalog contains entries for the system

data sets necessary to IPL the system. After IPL, the original master catalog can be repaired or recovered, and the system can again be IPLed with the newly recovered master catalog.

       The simplest procedure for creating an alternate master catalog is to use the

access method services REPRO command to copy the master catalog into a defined new master catalog.

 

ALTERNATE MASTER CATALOG (Contd..)

The newly defined catalog should then be used as the master catalog, and the old master should be used as the alternate master.

       The alternate master should be defined on a different volume than the volume of the

original master: otherwise, if the original master's volume is damaged, both the original master and the alternate master are unavailable.

       The alternate master then has entries for the same data sets defined in the original master.

After the alternate is created, changes to the entries for the system data sets are only reflected in the master catalog which is in use.

  If the system is IPLed with the new master, changes are not reflected in the old master (now the alternate master).

For example,

ALTERNATE MASTER CATALOG (Contd..)

If a system data set is moved to a different volume, update the alternate master by recreating it or re-cataloging the data set. After defining the new master and copying the original master into it, create a SYSCAT xx member in SYS1.NUCLEUS to identify the alternate master.

       To use the alternate master catalog, specify at IPL time the two-character identifier of

the SYSCAT xx member which contains the entry identifying the alternate master catalog.        You can also define the alternate master in a LOAD xx member in SYS1.PARMLIB.

If SYSCATLG member has to be maintained as the member identifying your current master catalog, and the SYSCATLG member points to the old master catalog, copy the member to a different SYSCAT xx member.

 Then update the SYSCATLG member to point to the catalog you just created.

PRINTING A CATALOG OR VVDS         You can print the contents of a BCS or VVDS with the PRINT command, but the only

circumstance where it might be useful is when you need to determine which catalogs are connected to a VVDS.

       This might be necessary to determine which BCSs to specify in a DIAGNOSE command,

or when you are recovering a volume, the names of the first 36 BCSs connected to a VVDS are in the first record of the VVDS.

       If you print this record using the DUMP format, you can read the names of the BCSs in

the character format portion of the dump.

The following step can be used to print the first record of a VVDS. Since VVDSs are not normally found by catalog searches, use the INFILE parameter to specify a DD statement defining the VVDS.

PRINTING A CATALOG OR VVDS(Contd..)

//PRNTVVDS EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=A

//VVDS DD DSN=SYS1.VVDS.VSPOOL1,DISP=SHR, // UNIT=SYSDA,VOL=SER=SPOOL1,AMP=AMORG //SYSIN DD *

PRINT INFILE(VVDS) COUNT(1) /*

A catalog or VVDS can also be printed using DFSMSdss

LISTING A VOLUME TABLE OF CONTENTS (VTOC)  

The most convenient and flexible way to generate a data set list from a VTOC is to use the data set application of ISMF. With ISMF, you can generate a list of data sets based on many different filtering criteria, and execute commands against the data sets listed. You can also save the lists.

       The VTOCLIST line operator can also be used to generate a VTOC listing for a

data set in the IEHLIST format. For more information about using ISMF, see DFSMS/MVS Using ISMF.

       If you want to use batch processing to get a VTOC listing, you can use the

IEHLIST utility. The listing can be formatted or dumped in hexadecimal.

For more information, see DFSMS/MVS Utilities. 

DELETING CATALOG ENTRIES

       Use the access method services DELETE command to delete catalogs,

cataloged data sets, objects, tape library entries, and tape volume entries. With this command, you can delete anything you can define or create withaccess method services.

       Since access method services cannot change the library manager inventory

in an automated tape library, ISMF should be used for normal tape library ALTER, CREATE, and DELETE functions. DELETE can also be used for deleting erroneous records from BCSs, VVDSs, and VTOCs.

UNIT5: JOB ENTRY SUBSYSTEM.

JOB ENTRY SUBSYSTEM (Cont..).

HOW JES2 FITS INTO THE MVS SYSTEM.

HOW JES2 FITS INTO THE MVS SYSTEM(Cont..).

RELATIONSHIP OF JES TO JCL AND SUBMITTTED JOBS.

RELATIONSHIP OF JES TO JCL AND SUBMITTTED JOBS(Cont..).

JES FUNCTIONS.

JES2 COMPARED TO JES3.

INTERACTING WITH JES.

JES2 DATASET CONTROL.

SPOOL DATASETS AND SPOOLING.

MAINTAINING INTEGRITY.

MAINTAINING INTEGRITY(Cont…).

PHASES OF JOB PROCESSING.

INPUT PHASE.

CONVERSION PHASE.

PROCESSING PHASE.

PROCESSING PHASE(Cont….).

OUTPUT PHASE.

HARD-COPY PHASE.

PURGE PHASE.

JES2 CAPABILITIES AND FUNCTIONS.

GETTING WORK OUT OF PHASE.

UNIT 5: JOB ENTRY SUBSYSTEM

WHAT IS A JES?

MVS uses a job entry subsystem (JES) to receive jobs into the operating system, schedule them for processing by MVS, and to control their output processing.

JES2 is descended from HASP (Houston automatic spooling priority). HASP is defined as: a computer program that provides supplementary job management,data management, and task management functions such as: scheduling, control of job flow, and spooling.

HASP remains within JES2 as the prefix of most module names and the prefix of all messages sent by JES2 to the operator.

JES2 (job entry subsystem 2) is a functional extension of the HASP II program that receives jobs into the system and processes all output data produced by the job. So, what does all that mean? Simply stated, JES2 is that component of MVS that provides the necessary functions to get jobs into, and output out of, the MVS system.

JOB ENTRY SUBSYSTEM(Cont…)

It is designed to provide efficient spooling, scheduling, and managementFacilities for the MVS operating system.

 But, why MVS needs a JES. Basically, by separating job processing into a number of tasks, MVS operates more efficiently. At any point in time, the computer system resources are busy processing the tasks for individual jobs, while other tasks are waiting for those resources to become available.

 In its most simple view, MVS divides the management of jobs and resources between the JES and the base control program of MVS. In this manner, JES2 manages jobs before and after running the program; the base control program manages them during processing.

 JES3, in contrast, manages jobs throughout the entire process cycle (before, during, and after running the programs).

HOW JES2 FITS INTP THE MVS SYSTEM

MVS

INPUT DEVICE

JES2 BCP

OUTPUT DEVICES

HOW JES2 FITS INTO THE MVS SYSTEM(Cont..)

During the life of a job, both JES2 and the base control program of MVS control different phases of the overall processing. Generally speaking,

a job goes through the following phases:

INPUTCONVERSIONPOROCESSINGOUTPUTPRINT/PUNCH(HARDCOPY)PURGE

Except for processing, all the job phases are controlled by JES2.

RELATIONSHIP OF JES TO JCL AND SUBMITTED JOBS

JES2 initialization statements give the system programmer a single point of control to define an installation's policies regarding the degree of control users have over their jobs.

For example,

consider the confusion an installation would experience if users were allowed to define their own job classes and priorities. Very likely, all users would define all there jobs as top priority, resulting in no effective priority classifications at all.

Although a user can use job control language (JCL) options to define a priority, a JES2 initialization statement (defined by the system programmer) determines whether JES2 acknowledges that priority.

This same type of control (validation of user specification and provision for a default) extends to many JCL definitions.

RELATIONSHIP OF JES TO JCL AND SUBMITTED JOBS (Cont..)

For example,

• JES2 can specify the maximum time a particular job is allowed to run, the storage a job may consume, the number of copies of output a job can print, and the type of paper (form) on which the output prints.

• An installation has the ability to allow its users to override system and JES2 specifications at three distinct levels (user-specified JCL, installation-specified JCL, and JCL defaults).

The following list shows the hierarchy of control, from highest priority to lowest priority, of user JCL, JCL defaults, and JES2 defaults:

1. JCL specification on a user job.The user JCL overrides:

2. JCL default, which MVS uses if there is no user definition or the user specification is disallowed. The JCL default overrides:

3. JES2 default, which MVS uses if:         No JCL default exists         The user specification is disallowed or undefined         The JCL default definition is not supported.      Note that the user can override the JCL defaults and the JCL defaults can override the JES2 specifications, but the ability to override is either permitted or disallowed by specifications that only the system programmer can control.     This structure thereby puts the system control in the hands of the system programmer, not the individual user who is submitting the job. JES2 becomes the base for input and output specifications that can then be overridden, as allowed by your installation, through the JCL and job submitter 

JES FUNCTIONS  To manage job input/output responsibilities for MVS, JES2 controls a number of functional areas, all of which you can customize to your installation's need. Some of the major functional areas and processing capabilities are:          Getting work into and out of MVS (input/output control)

        Maximizing efficiency through job selection and scheduling

        Offloading work and backing up system workload

        Supporting advanced function printers (AFPs)

        Running multiple copies of JES2

        System security.

JES2 COMPARED TO JES3 

      IBM provides two JESs from which to choose: JES2 and JES3.      In an installation that has only one processor (computer), JES2 and JES3 perform similar functions.That is, they read jobs into the system, convert them to internal machine-readable form, select them for processing, process their output, and purge them from the system However, for an installation that has more than one processor in a configuration,there are noticeable differences in how JES2 exercises independent control over

its job processing functions.       That is, within the configuration, each JES2 processor controls its own job input, job scheduling, and job output processing. In contrast, JES3 exercises centralized control over its processing functions through a single global JES3 processor.      This global processor provides all job selection, scheduling, and device allocation functions for all the other JES3 systems. The centralized control that JES3 exercises provides: increased job scheduling control, deadline scheduling capabilities, and increased control by providing its own device allocation.      To gain a more complete understanding of the functional differences between JES2 and JES3, refer to OS/390 JES2 Initialization and Tuning Guide and OS/390 JES3 Initialization and Tuning Guide.  

INTERACTING WITH JES     No large data processing system or subsystem can continually operate independently of system programmer or operator intervention.       A two-way communication mechanism between the operator and JES2 is required. Based on system workload and device requirements, JES2 must communicate its status to the operator and/or system programmer.        JES2 issues messages to communicate job and device status, problem situations, system resource constraint situations, and performance status. Through commands, you can request current status and through the use of various tools you can obtain further information to diagnose and correct problem and system failure situations.  

JES2 DATA SET CONTROL 

       JES2 maintains copies of its data sets that contain job and output queues (that is, lists of jobs to be processed by MVS) on direct access storage devices (DASD). 

       Future work is added to these queues and JES2 selects work for processing from them. These data sets and queues must remain current and accurate to maintain system integrity and performance.  

SPOOL DATA SETS AND SPOOLING 

Simultaneous peripheral operations online (spool). Spooling is a process by which the system manipulates its work. This includes:      Using storage on direct access storage devices (DASD) as a buffer storage to reduce processing delays when transferring data between peripheral equipment and a program to be run.     Reading and writing input and output streams on an intermediate device for later processing or output.      Performing an operation such as printing while the computer is busy with other work.·         Spool also refers to the direct access device that contains the spool data sets.

Notes: Spooling is critical to maintain performance in the MVS-JES2 environment. As noted previously, spooling provides simultaneous processing and a temporary storage area for work that is not yet completed. Once JES2 reads a job into the system, JES2 writes the job, its JCL, its control statements, and its data to a spool data set until further processing can occur.

MAINTAINING INTEGRITY

    Errors can occur while processing jobs and data. Some of these errors can result in the halting of all system activity. Other errors can result in the loss of jobs or the invalidation of jobs and data.

    If such errors occur, it is preferable to stop JES2 in such a way that allows processing to be restarted with minimal loss of jobs and data. The checkpoint data set, checkpointing, and the checkpoint reconfiguration dialog all help to make this possible.

    Checkpoint data set is the general term used to describe the checkpoint data set that JES2 maintains on either DASD or a coupling facility. The checkpoint data set (regardless of whether it resides on a coupling facility structure or a DASD volume) contains a backup copy of the job and output queues, which contain information about what work is yet to be processed and how far along that work has progressed.

    Similar to the spool data sets, the checkpoint data set is commonly accessible by all members of the multiple-processor (multi-access) spool complex, but only one member will have control (access) of the checkpoint data set at any one time. Furthermore, the checkpoint data set provides communication among all members of the configuration about jobs and the output from those jobs.

MAINTAINING INTEGRITY(Cont….)         JES2 periodically updates the checkpoint data set by copying the changed information from the in-storage copy to the checkpoint data set copy that resides on either a coupling facility structure or on DASD.          Information in the checkpoint data set is critical to JES2 for normal processing as well as in the event that a JES2 or system failure occurs.           Checkpointing is the concept of keeping a copy of the checkpoint data set that contains essential workload information on either a coupling facility structure or a DASD volume. This copy is updated from the in-storage copy of the checkpoint as each JES2 member of a multi-access spool updates the in-storage checkpoint data set. Checkpointing allows JES2 to be stopped and then restarted with little or no loss of job or data integrity.          The checkpoint reconfiguration dialog is a dynamic means by which the current checkpoint configuration can be changed (for example, adding a checkpoint device or moving the checkpoint data set to a different device). It is possible to enter the checkpoint reconfiguration dialog to continue processing without necessitating a JES2 restart. This process increases system availability.

PHASES OF JOB PROCESSING  The base control program and JES2 share responsibility in the MVS system. JES2 is responsible for job entry (input), the base control program for device allocation and actual job running, and finally JES2 for job exit (output).

JCL & SYSIN

HARD COPY QUEUE

SYSIN

INPUT CONVERSION

PROCESSING OUTPUT HARDCOPY

PURGE

JOB

SYSOUT

NON-PRINT OR PUNCH OUTPUT

OUTPUT QUEUE

CONVERSION QUEUE

PURGE QUEUE

PROCESSING QUEUE

SPOOL DISK

SYSOUT

PHASES OF JOB PROCESSING(Contd.)

The job queues contain jobs:

       Waiting to run - conversion queue     Currently running - execution queue     Waiting for their output to be produced - output queue     Having their output produced - hard-copy (print/punch) queue    Waiting to be purged from the system (following completion of all processing) -purge

queue.

INPUT PHASE     JES2 accepts jobs (in the form of an input stream) from input devices such as card readers, remote terminals, or other programs. Input streams can also come from other nodes in a job entry network and from internal readers.      An internal reader is a program that other programs can use to submit jobs, control statements, and commands to JES2. Any job running in MVS can use an internal reader to pass an input stream to JES2, and JES2 can receive multiple jobs simultaneously through multiple internal readers.     MVS uses internal readers, allocated during system initialization, to pass to JES2 the job control language (JCL) for started tasks, START and MOUNT commands, and TSO LOGON requests      The system programmer defines internal readers used to process all batch jobs other than STCs and TSO requests. JES2 initialization statements define these Internal readers which JES2 also allocates during its initialization processing. The internal readers for batch jobs can be used for STCs and TSO requests, if not processing jobs.

INPUT PHASE(Contd.)

   As JES2 reads the input stream, it assigns a job identifier to each job and places each job's JCL, optional JES2 control statements, and SYSIN data onto DASD data sets called spool data sets. JES2 then selects jobs from the spool data sets for processing and subsequent running.

CONVERSION PHASE       JES2 uses a converter program to analyze each job's JCL statements. The converter takes the job's JCL, merges it with JCL from a procedure library (such as SYS1.PROCLIB), and converts the composite JCL into converter/interpreter text that both JES2 and the job scheduler functions of MVS can recognize.       JES2 then stores the converter/interpreter text on the spool data set. If JES2 detects any JCL errors, JES2 issues messages, and the job is queued for output processing rather than run. If there are no errors, JES2 queues the job for execution. JES2 supports multiple converters; therefore, jobs may not always be processed in a first-in-first-out (FIFO) order.

PROCESSING PHASE     In the processing phase, JES2 responds to requests for jobs from the MVS initiators. JES2 selects from a job queue, jobs that are waiting to run and sends them to MVS.

   By recognizing the current processing phase of all jobs on the job queue, JES2 can manage the flow of jobs through the system. JES2 Job Scheduling: To process the jobs on the job queue, JES2 communicates with an initiator.      An initiator is a system program that starts a job to allow it to compete for system resources with other jobs that are already running. Initiators are controlled by JES2 or by the MVS work load manager (WLM).     JES2 initiators are started by the operator or by JES2 automatically when the system initializes. The initiators select jobs based on the job class(es) that are assigned to the initiator and the priority of the queued jobs. The installation associates each initiator with one or more job classes in a way to encourage the efficient use of available system resources.    WLM initiators are started by the system automatically based on the performance goals, relative importance of the batch workload, and the capacity of the system to do more work. The initiators select jobs based on their service class and the order they were made available for execution.

PROCESSING PHASE (Cont…)  ·  After JES2 selects a job and passes it to the initiator, the initiator invokes the interpreter to

build control blocks from the converter/interpreter text that the converter created for the job.  ·  The initiator then allocates the resources specified in the JCL for the first step of the

job. This allocation ensures that the devices are available before the job step starts running. The initiator then starts the program requested in the JCL EXEC statement.

  ·        Priority Aging: When all initiators are busy, throughput of certain jobs might fall below normal expectations. To help in these situations, JES2 uses the additional scheduling function of priority aging. Priority aging can help ensure that jobs that have been waiting to run have a chance of being selected to run before those jobs that just entered the system. By using priority aging, an installation can increase the priority of a waiting job.

 ·        The longer the job waits, the higher its priority becomes, upto a limit, and the greater its chances of being selected to run.JES2-Base Control Program Interaction: JES2 and the base control program communicate constantly to control system processing. The communication mechanism, known as the subsystem interface, allows MVS to request services of JES2.

  For example, ·        A requestor can ask JES2 to find a job, do message or command processing, or open

(access) a SYSIN or SYSOUT data set. Further,the base control program notifies JES2 of events such as messages, operator commands, the end of a job, or the end of a task.

 

OUTPUT PHASE  

·        JES2 controls all SYSOUT processing. SYSOUT is system-produced output; that is, all output produced by, or for, a job.

  ·      This output includes system messages that must be printed, as well as data sets requested by

the user that must be printed or punched. After a job finishes, JES2 analyzes the characteristics of the job's output in terms of its output class and device setup

requirements; then JES2 groups data sets with similar characteristics. JES2 queues the output for print or punch processing.

HARD-COPY PHASE 

·    JES2 selects output for processing from the output queues by output class, route code, priority, and other criteria. The output queue can have output that is to be processedl locally or output to be processed at a remote location (either an RJE workstation or another node). JES2 handles each of these situations in different ways.

  Local Output:·     When output is to be processed at a local or remotely-attached output device, JES2 uses these local and remotely-attached output devices to produce a job's output. JES2 queues a job's print and punch data sets on the output queue for the local and remote output devices. The active devices, that are attached locally or through RJE connections, select the output data sets with characteristics that best match their selection criteria.

  Network Job Entry Output:·   Job output passing through to another JES2 node resides on the network output queue. JES2 selects a job's output from the network output queue for transmission to another node based upon the priority and the desirability of reaching the output-processing node over the available transmission line. After the receiving node signals that it has accepted total responsibility for the output, the transmitting JES2 node releases the resources used to represent the output.

 ·    After processing all the output for a particular job, JES2 puts the job on the purge queue.

PURGE PHASE 

·        When all processing for a job completes, JES2 releases the spool space assigned to the job, making the space available for allocation to subsequent jobs.

 ·        JES2 then issues a message to the operator indicating that the job has been purged

from the system. 

JES2 CAPABILITIES AND FUNCTIONS ·       JES2 (in conjunction with VTAM) is the link between the Time Sharing

Options/Extensions (TSO/E) user and MVS. As such, it is very externally oriented. That is, it is visible to the data processing personnel and provides the ability to specify and tailor many installation-specific functions through JES2 initialization statements and JES2 commands. 

·   These statements and commands are analogous to the knobs, buttons, and handles with which you control a machine. You set them, knowing what response the machine will provide, but you need not be concerned with how the button sets the gears and belts in motion.

·    This section provides an overview of the following major functions JES2 provides to manage its job input/output responsibilities for MVS; all of which are under system programmer control.  

·      Getting work out of MVS 

·      Selecting work to maximize efficiency 

·      Offloading work and backing up the system 

·      Supporting advanced function printers 

·      Providing security. 

·      All are discussed in greater depth in OS/390 JES2 Initialization and Tuning Guide.

GETTING WORK OUT OF MVS ·     As the central point of control over the job output (or exit) function, JES2 controls output devices: local and remote printers, punches, and card readers. You can use JES2 initialization statements to define each device.  

·     All are directly under JES2's control with the exception of those printers that operate under the Print Services Facility (PSF). These printers provide all-points-addressable capabilities, and although defined by JES2, are driven by PSF.  

·     PSF thereby assumes the processing overhead that JES2 typically performs to support printer operation.  

·     Printed and punched output can be routed to a variety of devices in multiple locations. The control JES2 exercises over its printers ranges from the job output classes and job names from which the printer can select work to such specifications such as the forms on which the

output is printed.  

·     This control allows the system programmer to establish the job output environment most efficiently without causing unnecessary printer backlog or operator intervention. 

·     Through JES2, the installation defines the job input classes, reader specifications, and output device specifications. As a result, JES2 is the central point of control over both the job entry and job exit phases of data processing.

UNIT 6: WORKING WITH I/O AND DATA.

DEFINING THE I/O CONFIGURATION.

MAJOR I/O COMPONENTS

MAJOR I/O COMPONENTS(Cont…)

DEFINING THE I/O CONFIGURATION

IOCP INPUT

IOCP PROCESS

SELECTING AN IOCDS

POWER ON RESET-1

POWER ON RESET -2

I/O CONFIGURATION DATA FOR MVS

I/O CONFIGURATION DATA FOR MVS(Cont…)

HCD OR MVSCP OUTPUT

THE FLOW OF AN I/O OPERATION

HARDWARE AND SOFTWAE I/O COMPONENTS

FUNCTIONS OF THE ACCESS METHODS

THE CHANNEL PROGRAM

ACCESS METHOD PASSES CONTROL TO IOS

IOS DETERMINES IF DEVICE IS AVAILABLE

CHANNEL SUBSYSTEM STARTS I/O

SIGNAL IOS THAT I/O IS COMPLETE

MOVE LOGICAL RECORD TO USER PROGRAM

LOCATING DATA

LOCATING A DATASET – WHICH VOLUME ?

MASTER AND USER CATALOGS

USING ALIASES

ORDER OF SEARCHING CATALOGS

CATALOG ADDRESS SPACE

LOCATING A DATASET ON AVOLUME

INDEXED VTOC STRUCTURE

CREATING A NEW DATASET

ALLOCATING NEW DASD DATASETS

DETERMINING WHICH VOLUME

DETERMINING WHICH VOLUME(Cont…

ALLOCATING SPACE ON THE VOLUME

DEFINING A NEW DATASET

INPUT TO SMS

STORAGE GROUPS

UNIT 6: WORKING WITH I/O AND DATA   DEFINING THE I/O CONFIGURATION   THE FLOW OF AN I/O OPERATION       LOCATING VOLUMES AND DATA SETS       CREATING NEW DATA SETS

DEFINING THE I/O CONFIGURATION

MAJOR I/O COMPONENTS DEFINING THE I/O CONFIGURATION

IOCP INPUT

IOCP PROCESS

SELECTING AN IOCDS

POWER ON RESET

I/O CONFIGURATION DATA FOR MVS

HCD OR MVSCP OUTPUT

THE LOAD PARAMETER

MAJOR I/O COMPONENTS

CHANNELSUBSYSTEM

CONTROL UNIT CONTROL UNIT

DEVICE

CHANNEL PATH

MAJOR I/O COMPONENTS (Cont….)

MVS constantly performs some I/O operations in order to move data between central storage and I/O devices such as a tape, disk,

printer or terminal. The major I/O components are:

I/O devices include such equipment as printers, magnetic-tape units, direct-access-storage devices (DASD), displays, keyboards, communications controllers, teleprocessing devices and sensor-based equipment

In all cases, I/O device operation is regulated by a control unit that provides the logical buffering capabilities necessary to operate the

associated I/O DEVICE.

MAJOR I/O COMPONENTS (Cont….)

The channel subsystem directs the flow of information between I/O devices and central storage. It relieves CPUs of the task of

communicating directly with I/O devices and permits data processing to proceed concurrently with I/O processing.

I/O devices are attached through control units to the channel subsystem through channel paths. Control units may be attached to the channel subsystem by one more than one channel path and an I/O device may be attached to more than one control unit.

DEFINING THE I/O CONFIGURATION

IOCP

IOCDS

CHANNEL SUBSYSTEM

HCD

IODFSYS1. NUCLEUS

MVSCP

MVS

SYSTEM INITIALIZATION

Notes:

The I/O Configuration Program (IOCP) is used to define the configuration of the I/O devices to the hardware—the channel subsystem. The output of the IOCP is the I/O Configuration Data Sets (IOCDS).The MVS Configuration Program (MVSCP) is used to define the configuration of the I/O devices to the MVS software. The output of MVSCP includes the IOSUCBxx member of the SYS1.NUCLEUS data set.

Beginning with MVS/ESA Hardware Configuration Definition (HCD) is available as an alternative to MVSCP processing. HCD is used to define the I/O configuration through interactive panels at a TSO terminal. The output to HCD is an I/O Definition File(IODF) that provides the configuration information for MVS and also provides the input to IOCP

IOCP INPUT

CHANNELSUBSYSTEM

CONTROL UNIT

CONTROL UNIT

DEVICE

CHANNEL PATH

CONTROL UNIT DEFINITION

I/O DEVICE DEFINITION

Notes: 

The input to the IOCP generation process is a series of statements usually prepared by a system programmer. The IOCP definition includes:

Channel paths on the processor complex (CHPID macro).

Control units attached to the channel paths (CNTLUNIT macro).

I/O devices assigned to the control units (IODEVICE macro).

IOCP PROCESS

CARD / TAPE / DISK

IOCP STATEMENTS

IOCP

IODF

IOCP REPORTS

(IOCDS)A0A1A2A3

Notes:

The input to the IOCP process is either a series of IOCP statements created independently or else as provided by the I/O Definition File (IODF).

Reports are produced to indicate any error conditions and to provide an analysis of the configuration data

The output of the IOCP program is an I/O Configuration Data Set (IOCDS). Multiple IOCDS datasets may be created to define different I/O configuration situations.

The operator selects an IOCDS to activate a particular configuration.

SELECTING AN IOCDS

SYSTEM CONSOLE

IOCDS ManagementA= IOCDS NameTypeStatusx0A0PROD0310BASICWrite Protected x1A1NEW00501BASICWrite Protectedx2A2TEST0001BASICWrite Protectedx3A3LPAR0310LPARWrite ProtectedC= ACTION1Select for POR2Write Protect3Release Write Protect4Select Config Frame

Notes:

The operator can select an IOCDS using the IOCDS management frame on the system console.

In this example C1 ahs been keyed to indicate “select for POR”. Then A2 will be entered to indicate the IOCDS named “PROD0392”.

Selection of a new IOCDS requires a Power-On-Reset(POR) to bring in the new configuration.

After the POR, MVS will have to be IPLed.

Beginning with MVS/ESA, its is possible to change and activated the I/O configuration without a POR and IPL using Dynamic Reconfiguration Management.

POWER ON RESET – 1 SYSTEM CONSOLE

Notes: 

Another frame on the system console the configuration frame is used to complete the activation of a new I/O configuration.Selecting A2 on the CONFIG frame initiates the Power-On-Reset action

A= ACTION 1Release 2Power on Reset3Maximum Installed4Select IOCDS ManagementB= CP MODE1Not Used2ESA/390 tm3LPAR

POWER ON RESET – 2

Notes:

At Power-On-Reset time, the information from the IOCDS is leaded in to a portion of central storage called the Hardware System Area (HAS).The HAS is addressable by the hardware and is isolated from the rest of central storage that MVS will use

(IOCDS)A0

A1

A2

A3

HAS

CENTRAL STORAGE

I/O CONFIGURATION DATA FOR MVS

DEVICE DESCRIPTIONS.

    DEVICE NUMBER       TYPE AND MODEL       FEATURES

DEVICE GROUPS.       FOR ALLOCATION       FOR VIO

NIP CONSOLES.

I/O CONFIGURATION DATA FOR MVS (Cont….)

All of the devices in the system are defined to MVS either interactively with the Hardware Configuration Definition (HCD) facility or else with IODEVICE macros processed by the MVS Configuration Program (MVSCP).

The definitions provide MVS with device descriptions tat MVS will use to determine how to communicate with the device. For example the data will be formatted differently for a track on a DASD device than for a screen on an operator console.

The definitions are also used at IPL time to provide information about what device support modules need to be included in the MVS system.

I/O CONFIGURATION DATA FOR MVS (Cont….)

The devices will also be defined as belonging to one or more groups. This produces an Eligible Device Table that is used during device allocation for new data sets.

Also one or more consoles are identified as eligible for MVS to use during the system initialization process—Nucleus Initialization Program (NIP) consoles

HCD OR MVSCP OUTPUT 

IODF

IOSUCBxx

IOSIITxx

IEANCTxx

IEFEDTxx

Notes:        The output of the MVSCP program consists of members of the

SYS1.NUCLEUS data set.

      IOSUCBxx contains one UCB per device. The UCB is the MVS internal representation of the device.

      IOSIITxx defines the device support modules that are necessary to support this I/O configuration. These device support modules will be included in the nucleus at initialization time.

      IEANCTxx defines the I/O devices that NIP may use as consoles during initialization.

      IEFEDTxx contains the Eligible Device Tables, which group devices for allocation.

      The output of HCD is the I/O Definition File (IODF). It contains the same kinds of information as the members of SYS1.NUCLEUS mentioned above.

THE FLOW OF AN I/O OPERATION

HARDWARE AND SOFTWARE I/O COMPONENTS 

        FUNCTIONS OF THE ACCESS METHOD    THE CHANNEL PROGRAM      ACCESS METHOD PASSES CONTROL TO IOS      IOS DETERMINES IF DEVICE IS AVAILABLE        CHANNEL SUBSYSTEM STARTS I/O       SIGNAL IOS THAT I/O IS COMPLETE 

MOVE LOGICAL RECORD TO USER PROGRAM

HARDWARE AND SOFTWARE I/O COMPONENTS

MVS

ACCESS METHOD

USER PROGRAM

IOS

CHANNELSUBSYSTEM

CU

SOFTWARE

HARDWARE

Notes:

User program interfaces to an I/O operation through an access method such as the Queued Sequential Access Method (QSAM) or the Virtual storage Access Method (VSAM).

The access method interfaces with the I/O Supervisor (IOS) component of MVS, which issues an I/O request to the channel subsystem.

The channel subsystem transfers the data to or from the device.

FUNCTIONS OF THE ACCESS METHOD

ACCESS M ETHOD

U PS GE MR

ACQUIRE I/O BUFFERS BUILD CHANNEL PGM BUILD CONTROL BLOCKS IVOKE IOS

Notes…

The data set organization and processing method are usually described in the program. When the user program issues an I/O request, the user program branches to the access method.       

The access methods are located in the Link Pack Area which is part of the common area if virtual storage. A single copy of the access method may be used by many users (address spaces) at a time.

        Here are some of the things that an access method will do. QSAM is used for this example

1. Provide I/O buffers within the program’s address space. 2.Build the channel program, which describes the I/O operation to the channel subsystem. 3. Build control blocks containing information about the I/O request. 4. Pass control to IOS.5. Issue a WAIT macro to suspend processing of the program’s task until the

I/O operation is completed.

THE CHANNEL PROGRAM

 

      The instructions that direct the control unit and device are called channel commands. A series of channel commands make up a channel program.

Channel commands provide information such as the address of the data areaand the number of bytes of data to be transferred

Some examples of channel commands are SEEK, SETSECTOR, SEARCH and READ

ACCESS METHOD

USERPGM

I/O BUFFERS

CHANNEL PROGRAM DATA

WHERE IS DATA?HOW MUCH DATA?DIRECTION OF DATA FLOW?

ACCESS METHOD PASSES CONTROL TO IOS

DRIVER IOS

ACCESS METHOD

U PS GE M R

CHANNEL PROGRAM

I/O BUFFER

Notes

  There are many different types of I/O operations going on in the MVS system, but all of them are funneled through the I/O Supervisor which functions as a traffic cop.

        Some access methods use different data structures and different control blocks to represent an I/O request. Therefore, the access methods pass control to IOS through I/O driver, which standardizes the I/O request to IOS.

        In our QSAM example the driver fixes the I/O buffers and the channel program in central storage so that they will be available during the time that the channel subsystem is processing the I/O request.

        The driver translates the address in the channel program from virtual to real.

The channel subsystem uses real address to transfer data into and out of central storage locations.

     The driver then passes the I/O request to IOS.

IOS DETERMINES IF DEVICE IS AVAILABLE

IOS is the interface between the system components (software) and the channel subsystem (hardware)

. IOS checks to see if the requested device is active with a previous I/O request. If the device is active, IOS holds the current request on a queue for that device. If the device is active, IOS issues a Start Subchannel (SSCH) instruction to the channel subsystem to start the I/O request.

DRIVER IOS

ACCESS METHOD

U PS GE M R

CHANNEL PROGRAM

I/O BUFFER

IS DEVICE AVAILABLE?

START QUEUE

CHANNEL SUBSYSTEM STARTS I/O

·       

SSCH

C SH UA BN SN YE SL T E M

CTL UNIT

CTL UNIT

CHANNEL PATH

CHANNEL SUBSYSTEM STARTS I/O(Cont…)

Notes..

There will often be multiple channel paths to a single device. The channel subsystem is responsible for selecting the best path for data transfer between the

device and central storage.

A path consists of the channel path, a control unit, the head-of-string, and the device.

The channel subsystem does extensive monitoring of I/O events. It measures the time that an I/O request is queued in a channel prior to beginning the channel program; the actual time required on the channel path (connect time); and the disconnect time. These times are passed to IOS and are accumulated and

reported by the Resource Measurement Facility (RMF).

SIGNAL IOS THAT I/O IS COMPLETE

DRIVER IOS

ACCESS METHOD

CHANNELSUBSYSTEM

INTERRUPT

SIGNAL IOS THAT I/O IS COMPLETE(Cont…)

Notes

       The execution if the channel program transfers data between the specified storage location on the device and the specified buffer in central storage.

        At the completion of the data transfer, the channel subsystem must signal MVS that the data has been transferred. This is done with an I/O interrupt.

       If there are I/O requests for the same device, IOS will start another I/O operation to that device.

I/O interrupts can also be caused by the channel subsystem when error conditions occur. If the interrupt is due to error, IOS performs error recovery processing

MOVE LOGICAL RECORD TO USER PROGRAM

Notes

As a result of the interrupt, IOS returns control to the I/O driver. The I/O driver marks the program’s task ready-to-execute. When the program’s task is the highest priority unit of work in the system, it will be dispatched. At that time the access method code will transfer the data from the access method’s I/O buffers into the user program’s data area and return control to the program.

DRIVER IOS

ACCESS METHOD

U PS GE MR

DATA

LOCATING DATA

Determining which volume?

CATALOG

VTOC INDEXED VTOCVVDS

Determining where on volume?

LOCATING DATA(Cont..)

Notes:

        MVS determines the physical location of data sets in two-steps:

1.     The first step is to determine which volume the data is located on. The MVS catalog will be used to determine the volume information unless the user provides that information in a JCL statement.

2.     The second step is to determine where the data is located in the volume. This occurs when the user opens the data set. Directories on the volume such as the Volume Table of Contents (VTOC), the indexed VTOC, or the VSAM Volume Data Set (VVDS) are used to locate the data set.

LOCATING A DATA SET – WHICH VOLUME?

Notes For an uncataloged data set, the JCL must include the data set name, the disposition and appropriate unit type

and volume information.    

For a cataloged data set, the JCL needs to include only the data set name and disposition. The data set name will direct MVS to the appropriate catalog

 

PAY.D1

CATALOG

PAY.D2

UNCATALOGED// DD DSN=PAY.D1 DISP=OLD UNIT=3380 VOL=SER=M

CATALOGED// DD DSN=PAY.D2 DISP=OLD

MASTER AND USER CATALOGS

Notes    Typically, the master catalog contains only system-related entries such as pointers to system data sets (such as SYS1.PARMLIB and SYS1.LINKLIB) and pointers to the next level of catalogs – user catalogs.         

Multiple user catalogs contain pointer to all of the other data sets.

 

MASTER CATALOG USER

CATALOG

SYSTEM DATASETS

USER DATASETS

USER DATASETS

USING ALIASES

·        To provide a convenient method for organizing and referencing catalog

entries, aliases are used.

An alias is an alternate name for a user catalog. For example, “PAY” is an alias for the user catalog UCAT.

Alias names are defined in the master catalog and are directly related to the real name of the user catalog by the name of the data set of some portion of the name

ALIAS-PAYUCAT1ALIAS-DEPT1ALIA-DEPT2UCAT2SYS1.LINKLIBSYS1.PARMLIB

PAY.D1

DEPT1.VAC

PAY.D1PAY.D2

DEPT1.VACDEPT2.VAC

UCAT1

UCAT2

USING ALIASES(Cont…)

Notes

To provide a convenient method for organizing and referencing catalog entries, aliases are used.

An alias is an alternate name for a user catalog. For example, “PAY” is an alias for the user catalog UCAT1.

Alias names are defined in the master catalog and are directly related to the real name of the user catalog by the name of the data set of some portion of the name

For example, UCAT1 is the real name of the catalog, which has an alias of PAY. The high level qualifier (HLQ) in the data set name normally matches an alias for the user catalog where the data set will be cataloged. For example, PAY.ABC is cataloged in UCAT1 since it has a high level qualifier of PAY.

ORDER OF SEARCHING CATALOGS

Notes

The order on which the catalogs are searched to find a data set is 1. Any user catalog specifically identified by a JOBCAT or STEPCAT JCL statement is searched. 2. The master catalog is searched for a match between the high level qualifier of the data set name and either the alias name or the exact name of the user catalog.3. The master catalog is searched for the fully qualified name of the data set.

//STEPCAT //JOBCAT

IS HQL IN MASTER CATALOG?

DATA SET NAME IN USER CATALOG

DATA SET NAME IN MASTER CATALOG

YES

NO

ORDER OF SEARCHING CATALOGS(Cont…)

Notes

The catalog management modules and control blocks were located in the common area in previous releases of MVS. Now they are located in the private area of a system address space called the Catalog Address Space (CAS).

All catalog requests access CAS via cross memory services.

LOCATING A DATA SET ON A VOLUME

VOLUME LABEL FREE SPACE

VTOC

VVDS

DATA

FREE SPACE

LOCATING A DATA SET ON A VOLUME(Cont…)

Notes

All volumes contain a volume label and a Volume Table of Contents (VTOC).

The volume label is made up of a volume serial number (VOLSER) and a pointer to the VTOC. A VOLSER is used to identify each volume in the system.

The VTOC describes all of the space on the volume. This includes both free space and the space occupied by data sets.

The VSAM Volume Data Set (VVDS) is a component of an ICF catalog. The VVDS describes both the VSAM data sets and the SMS-managed non-VSAM data sets on the volume.

A device must be initialized by the Device Support Facility (ICKDSF) before it can be used by MVS. The initialization process creates the volume label and the VTOC on the volume.

ICKDSF can also be used for media maintenance (i.e. direct and correct data checks on the volume).

INDEXED VTOC STRUCTURE

VOLUME LABEL FREE SPACE

VTOC INDEX

VTOC

VVDS

DATA

FREE SPACE

FREE SPACE MAP POINTERS TO VTOC DATA SET ENTRIESLIST OF EMPTY VTOC ENTRIES

INDEXED VTOC STRUCTURE(Cont…)

Notes

A volume may be initialized with an indexed VTOC.

The indexed VTOC provides improved performance, primarily when MVS is allocating new data sets.

There is one index entry per data set on the volume. The index entry points directly to the data set entry in the VTOC.

All volumes managed by SMS must have an indexed VTOC.

CREATING A NEW DATA SET

ALLOCATING NEW DASD DATASET

DETERMINING WHICH VOLUME

ALLOCATING SPACE ON THE VOLUME

DEFINING A NEW DATA SET

INPUT TO SMS

STORAGE GROUPS

ALLOCATING NEW DASD DATA SETS

// DD3 DD DSN=PAY.D3,// DISP=(NEW, CATLG),// UNIT=DEPT1,// SPACE=(CYL,(5,1)),// DCB=(BLKSIZE=800),// LABEL=EXPDT=92001

Notes

The user may request that the data set be allocated on a specific device with the UNIT = and VOL = SER = or VOL= REF = parameters in the JCL

Alternatively, the user may include only the UNIT= parameter in the JCL and let MVS choose the volume on which the data set will be allocated.

DETERMINING WHICH VOLUME

ELIGIBLE DEVICE TABLE

VOLUME ATTRIBUTE LIST

SYSTEM RESOURCE MANAGER

MVS ALLOCATION

DETERMINING WHICH VOLUME (Cont…)

If this is a non-specific allocation (no VOL=SER= or VOL=REF= specified), MVS allocation routines use a combination routines use a combination of JCL, the Eligible Device Table, and the Volume Attribute List to determine which device should be allocated for a new data set.

The system programmer creates Eligible Device Table by providing UNITNAME macros as input to MVSCP. The UNIT= parameter specified in the JCL checked against the Eligible Device Table to determine which volumes are eligible for allocation to this request.

The system programmer also defines volume attributes for the DASD devices via the VATLSTxx member of SYS1.PARMLIBN. Volumes can be designated as PRIVATE, PUBLIC, or STORAGE. Only volumes that match the characteristics of the request will be eligible for allocation.

The list of candidate volumes is then passed to SRM. SRM selects the optimum volumes.

ALLOCATING SPACE ON THE VOLUME

VOLUME LABEL FREE SPACE

VTOC INDEX

VTOC

VVDS

DATA

FREESPACE

DASDM

ALLOCATING A SPACE ON THE VOLUME(Cont..)

Notes:

Direct Access Device Space Management (DASDM) controls the allocation of space on a volume.

DASDM uses the VTOC to locate space on a volume. When DASDM allocates space on a volume, it updates the VTOC to point to the new data set located on that volume.

When DASDM deletes a data set from a volume, it updates the VTOC to remove the dataset pointer and to add pointers to the additional free space.

DEFINING A NEW DATA SET

STORAGE MANAGEMENT SUBSYSTEM

MVS/ESA

DEFINING A NEW DATA SET(Cont…)

Notes:        During allocation, the Storage Management Subsystem makes many

decisions about the new data set that were previously made by the end user through JCL. As a result, the JCL to allocate a new data set is much simpler in an SMS environment.

        SMS makes its decisions about the new data set based on input from the storage administrator.

        SMS chooses the volume for allocation based on the space, availability, and performance requirements of the data set.

        DASDM is still responsible for deciding where to place the data set on the chosen volume in

an SMS environment.

INPUT TO SMS

// DS3 DD DSN=PAY.D3// DISP=(NEW,CATLG)

STORAGE MANAGEMENT. SUBSYSTEM

DATA CLASSES

STORAGE CLASSES

MANAGEMENT CLASSES

STORAGE GROUPS

DATA

DEVICES

INPUT TO SMS (Cont…)

Notes       The storage administrator or system programmer defines Data Classes

(DC), Storage Classes (SC), Management Classes (MC), and Storage Groups (SG) to SMS.

        SMS uses these class definitions to assign attributes to a new data set.

        Data Class – What is the format of the data?

        Storage Class – What are the data’s performance and availability requirements?

        Management Class – When should the data set be migrated? Backed up?

        Storage Group – What are the characteristics of the data on each device?

STORAGE GROUPS

SGPRIM SGLARGE

SGTEMP SGDABASE

STORAGE GROUPS(Cont…)

Notes       The DASD volumes in the installation are divided in to storage groups

based on the category of data that will reside on the volumes with in the volumes within a storage group.

        SMS will assign a storage group to the new data set through an ACS routine. The new data set will be allocated on a volume from its assigned storage group.

All volumes in a storage group must have the same device geometry (same bytes per track and tracks per cylinder), but all volumes within a storage group might no have the exact same characteristics (cache vs. non-cache devices, dual-copy feature).

UNIT 7: MVS SUBSYSTEM

SUBSYTEM

INTRODUCING RACF (RESOURCE CONTROL ACCESS FACILITY)

INTRODUCING RACF (RESOURCE CONTROL ACCESS FACILITY)(Cont…)

INTRODUCING RACF (RESOURCE CONTROL ACCESS FACILITY) )(Cont…)

FUNCTIONS OF RACF

CICS(CUSTOMER INFORMATION CONTROL SYSTEM)

OPERTING ENVIRONMENT OF CICS

DB2(DATABASE2)

INTRODUCTION TO TSO

UNIT 7: MVS SUBSYSTEM

OVERVIEW:       SUBSYSTEM      

INTRODUCING RACF    

FUNCTIONS OF RACF      

CUSTOMER INFORMATION CONTROL SYSTEM      

OPERATING ENVIRONMENT OF CICS      

DB2      

OPERATING ENVIRONMENT OF DB2      

INTRODUCTION TO TSO

JES (JOB ENTRY SUBSYSTEM

SUBSYSTEM       A Sub-system is a set of modules running under the control of MVS

      Each Sub-system performs a definite set of functions, which MVS designates to it.

A Sub-system acquires at least one Address Space to execute

If MVS and its subsystem are to work together, communication of some sort must be established between them. The means of communication between MVS and any of its subsystem is via Subsystem Interface (SSI)

Notes:A Sub-system can be thought as an extension to MVS. All the functionalities performed by the basic Sub-systems should be performed by MVS also. But, since MVS is itself a program, there is a limitation to its size. Therefore, some of the core functionalities of MVS are seperated and grouped together into a Sub-system

INTRODUCING RACF (RESOURCE CONTROL ACCESS FACILITY)

Figure: RACF and Its Relationship to the Operating System

USER REQUEST

2

RESOURCE

MANAGER RACF 6

RACF ROUTE INTERFACE

RACF 4 DATABASE OR IN-STORAGE DATA

INTRODUCING RACF (RESOURCE CONTROL ACCESS FACILITY)(Cont…)

      A user requests access to a resource using a resource manager (for example, TSO/E).

     The resource manager issues a RACF request to see if the user can access the resource.

     RACF refers to the RACF database or in-storage data and......checks the appropriate resource profile.

     Based on the information in the profile...RACF passes the status of the request to the resource manager.

The resource manager grants (or denies) the request

INTRODUCING RACF (RESOURCE CONTROL ACCESS FACILITY)(Cont…)

During authorization checking, RACF checks the resource profile to ensure that the resource can be accessed in the way requested and that you have the proper authorization to access the resource.

     The necessary user-resource requirements must match before RACF grants the access request to a protected resource.

 Figure illustrates a conceptual model of how RACF checks profiles to ensure who (in a user profile) is accessing what and how (in a resource profile).

INTRODUCING RACF (Cont….)

REQUEST FOR A RESOURCE REQUEST FOR A RESOURCE

IS GRANTED BECAUSE THE IS DENIED SINCE THE RQUESTREQUEST LINE INTERSECTS DOES NOT INTERSECT ALL BOXES.

The “boxes” refer to the installation-assigned attributes and authorities for usersand resources that determine which users can access which resources in whatmanner

PROTECTED RESOURCE

USER AND GROUP

ACCESS AUTHORITY

PROTECTED RESOURCE

USER AND GROUP

ACCESS AUTHORITY

FUNCTIONS OF RACF

RACF protects resources by granting access only to authorized users of the protected resources. To accomplish this, RACF gives you the ability to:

      ·  Identify and authenticate users·  Authorize users to access the protected resources·  Log and report various attempts of unauthorized access to protected

resources·  Control the means of access to resources·  Allow applications to use the RACF macros

 RACF retains information about the users, resources, and access authorities inprofiles on the RACF database and refers to the profiles when deciding which

users should be permitted access to protected system resources. .

CICS (CUSTOMER INFORMATION CONTROL SYSTEM)

CICS stands for Customer Information & Control Systems. 

It is a Database / Data Communication (DB / DC) system developed by IBM.

 It is also termed as Online Transaction Processing (OLTP) system.

 It acts as a Application / Transaction Server.

 It acts as a interface b/w the application program & the Operating system.

 The primary objective of CICS is to provide the control & service functions of the DB / DC system as a package.

 CICS is not a DB / DC unless the applications accompany it, because CICS provides only the control environment for the DB / DC system.

 CICS is an interface between the application program and the Operating System.

OPERATING ENVIRONMENT OF CICS

Other Systems

Data Storage

Operating System (MVS/ESA)

DatabaseAccess

Method(DL/I,DB2)

(

Data AccessMethod(VSAM

,BDAM)

Telecommunication Access Method

(VTAM,TCAM,BTAM)

Terminals

CICS/MVS System Services Data Data CommunicationHandling Monitoring Functions FunctionsFunctions Application Program Services

CICS Application Programs[COBOL,PL/1,Assembler…..]

DB2 (DATABASE 2)

        DB2 is an abbreviation for IBM Database 2. DB2 is a subsystem of the MVS operating system.

 It is a system that allows the MVS users to build, access and

maintain Relational databases using a well known language knownas SQL (Structured Query Language).

 It is a relational database system that contains system and user tables.

OPERATING ENVIRONMENT OF DB2

DB2 Structure

CICS IMS/DC

IMS/DB

TSO

Distributed Data Facility

Database Services

System Services

Locking Services User

DataBSDS

Active Logs

Active Logs

DirectoryCatalog

INTRODUCTION TO TSO 

TSO stands for Time Sharing Option that was introduced as an optional feature of MVS that provided time sharing capabilities.

 It allows users to share computer time and resources. But now TSO is not an

optional feature, instead it is an integral part of MVS and provides the primary interactive support for MVS.

 MVS handles each TSO user in the same way as it handles batch jobs. Therefore each TSO user has a unique address space for running programs.

When a TSO user logs on to TSO, MVS initiates a terminal session using JCL that’s unique to that user.

This JCL includes DD statement that allocates terminal session. It can even specify a command that is automatically executed whenever the user logs on to TSO.

JES (JOB ENTRY SUBSYSTEM)

JES is a job entry subsystem that can be used with MVS. It performs functions such as

Reading user job steam (JCL and SYSIN data) in to an MVS system.Assisting MVS in selecting and initiating jobs

Printing or punching the SYSOUT data created by user jobs.

The main purpose of JES is to remove constrains of limited unit record device speed and availability from user job processing, enhancing efficiency in job processing and device operation.

JES takes advantage of the MVS subsystem interface (SSI) executing in its own system address space, processing the user jobs in a multi programming fashion.

JES must have been initialized prior to any job execution. Starting JES is normally part of the system initialization process.