mvs
Post on 22-Oct-2014
90 Views
Preview:
TRANSCRIPT
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
X
Y
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
MVSCP
IODFNUCLEUS
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
LOAD41
IODF
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
START
IEACMD00
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 facility
2 DFSMS/MVS V1R4 Managing Catalogs.
What makes it a master catalog is that all BCSs are cataloged in it, as
well 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 with
access 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 management
Facilities 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:
INPUT
CONVERSION
POROCESSING
OUTPUT
PRINT/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, up
to 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 area
and 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 RQUEST
REQUEST 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 in
profiles 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 known
as 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.
top related