Rui Miguel Feio » Tech – Mainframe

Linklist

Rui Miguel Feio — Wed, 08 Sep 2010 18:16:41 +0000

Linklist is used to improve the performance of program management and mechanisms utilized to locate and fetch Load modules, such as LLA and VLF.
Linklist is a group of system and a user-defined Load library that is a continuation of SYS1.LINKLIB and also indicates the search order the system uses for programs.
Can have PDS and PDS/E libraries in its concatenation.
The data sets are concatenated in the order in which they appear in the Linklist, and the system creates a Data Extent Block (DEB) describing the data sets concatenated to SYS1.LINKLIB and their extents.
By default Linklist begins with:
- SYS1.LINKLIB
- SYS1.MIGLIB
- SYS1.CSSLIB
The linklist concatenation can be defined in PARMLIB members PROGxx or LNKLSTxx.

Notes:

When determining which data sets LLA and VLF are to manage, try to limit the choices to production Load libraries that are rarely changed. This avoids a refresh of LLA or VLF operations.

Virtual Lookaside Facility (VLF)

Rui Miguel Feio — Sat, 04 Sep 2010 17:29:52 +0000

VLF keeps objects (for example Load modules) in Virtual Storage in order to save I/O operations that would load such objects.
Designed primarily to improve performance by retrieving the most currently used objects from Virtual Storage rather then performing repetitive I/O operations from DASD.
VLF can be configured by using PARMLIB member COFVLFxx.

Examples of some VLF exploiters:

LLA (for Load modules)
TSO (for REXX and CLIST procedures)
CAS – Catalog Address Spaces (for User Catalog entries)
RACF records from its database

Library Lookaside (LLA)

Rui Miguel Feio — Sat, 04 Sep 2010 17:13:51 +0000

It’s a program management z/OS component that keeps in Virtual Storage Directory entries from Load module libraries, thereby speeding up the fetch of a Load module.
LLA improves the performance of Load Module Directory searching on the system.
LLA can be a user of VLF facilities to keep copies of Load modules in VLF data spaces.
LLA manages Linklist libraries by default.
Code CSVLLAxx Parmlib member to include, modify or remove libraries.
Specify LLA with SUB=MSTR to prevent LLA from failing if JES2 fails.
Because LLA manages Linklist libraries by default, we only need to determine which non-Linklist libraries LLA is to manage.
If we don’t want LLA to manage particular Linklist libraries, we must explicitly remove such libraries from LLA management by using the CSVLLAxx Parmlib member.
When used with VLF, LLA reduces the I/O required to fetch Load modules from DASD.

Note:

SUB=MSTR indicates that the MASTER Subsystem will be the subsystem that will process the task.

What is a VTAM major node?

Rui Miguel Feio — Sat, 04 Sep 2010 17:06:50 +0000

A major node is a list of parameters that define a specific type of network device or group of related devices that VTAM can address.

To define the attachment of any device or set of devices to VTAM, you need to code a major node member in the VTAMLST data set.

Useful VTAM commands

Rui Miguel Feio — Sat, 04 Sep 2010 17:03:16 +0000

1. Display commands

D NET,VTAMOPTS	Display VTAM options, including SUBAREA Number, NETID, SSCPNAME, SSCPID
D NET,BFRUSE	Display information about VTAM¢s virtual storage and buffer pool usage
D NET,APPLS	Display the applications (APPLIDS) that VTAM knows about
D NET,PATHTAB	Display the status of communications PATHs between subareas in the VTAM network
D NET,MAJNODES	Display details about major nodes
D NET,ID=…	Display information about the specified VTAM resource
D NET,ID=…,E	Display more information about the specified VTAM resource

2. Vary commands

V NET,ACT,ID=…	Activate the specified resource
V NET,INACT,ID=…	Deactivate the specified resource
V NET,INACT,ID=…,I	Immediately deactivate the specified resource
V NET,INACT,ID=…,F	Force-deactivate the specified resource
V NET,ACQ,ID=…	Acquire the specified resource (NCP or non-switched PU) without activating it – used during network recovery whereby this VTAM can take ownership of another VTAM¢s resource

3. Modify commands

F NET,TNSTAT,CNSL=YES	Activate the VTAM tuning statistics display and output to the console
F NET,NOTNSTAT	Deactivate the VTAM tuning statistics display
F NET,TRACE,…	Initiate or Modify VTAM tracing
F NET,NOTRACE,…	Terminate VTAM tracing

4. Halt commands

Z NET	Terminate VTAM processing normally
Z NET,QUICK	Terminate VTAM processing immediately without waiting for normal termination of existing sessions – should only be used when normal termination does not complete successfully
Z NET,CANCEL	Abends VTAM – should only be used when both Z NET and Z NET,QUICK are unsuccessful

Modified Link Pack Area (MLPA)

Rui Miguel Feio — Fri, 03 Sep 2010 23:47:56 +0000

It’s defined in SYS1.PARMLIB(IEALPAxx).
Can be used to contain reenterable load modules from APF-Authorized libraries that are to be part of the pageable extension to the Link Pack Area (LPA) during the current IPL.
Can only have PDS files. PDS/Es are not allowed.
LPA modules that have been replaced through IEALPAxx are not physically removed from the PLPA or from the PLPA directory. They are however, logically replaced, because when one of them is requested, MLPA is searched first and then the system does not examine the LPA directory that contains the name of the replaced module.
The system searches FLPA before MLPA for a particular module and selects the module from MLPA only if the module is not also in the FLPA.
You may use IEALPAxx to temporarily add or replace SVC or ERP routines. Another possible application would be the testing of replacement LPA modules that have been altered by PTFs.
Modules with an RMODE of 24 are placed in the MLPA, while those with an RMODE of ANY are placed in the extended MLPA.

Fixed Link Pack Area (FLPA)

Rui Miguel Feio — Fri, 03 Sep 2010 23:46:37 +0000

It’s defined in SYS1.PARMLIB(IEAFIXxx).
It’s a non-pageale area of storage.
It’s loaded at IPL time from IEAFIXxx.
The data sets in its concatenation must be in the Master Catalog.
The Load modules must be kept in Fixed Storage Frames, ie, they cannot be paged out.
This area should be used only for Load modules that should not allow page faults because of integrity considerations.
Modules must be reenterant and refreshable.
The advantage of using the FLPA is the reduction in the Central Storage available for paging old jobs and starting new jobs.
Any library that includes modules for the FLPA must be a PDS. We cannot use PDS/Es in the LPALST concatenation.
Because Fixed modules are not paged, we can save I/O time and paging overhead by placing moderately used modules into FLPA.
The price for this performance improvement is the reduction in Storage available for paging old jobs and starting new jobs.
Modules with an RMODE of 24 are placed in the FLPA, while those with an RMODE of ANY are placed in the extended FLPA.

Content:

Load modules from LPALST concatenation, the LNKLST concatenation, SYS1.MIGLIB, and SYS1.SVCLIB can be included in the FLPA.

Notes:

Pages referenced frequently tend to remain in Central Storage even if they are not Fixed.

Pageable Link Pack Area (PLPA)

Rui Miguel Feio — Fri, 03 Sep 2010 23:44:40 +0000

It’s defined in SYS1.PARMLIB(LPALSTxx).
It’s an area of Common Storage that is loaded at IPL time.
This area contains SVC routines, access methods, and other READ-ONLY System Programs, along with any READ-ONLY reenterable user programs selected by an installation that can be shared among users of the system.
There cannot be PDS/E data sets in the LPALST concatenation.
Modules must be reenterant and executable.
Programs in the PLPA are shared among users of the system.
It is desirable to place all frequently used refreshable SYS1.LINKLIB and SYS1.CMDLIB modules in the PLPA.
ASM maintains records that have pointers to the PLPA and Extended PLPA pages in the PLPA data set.
During quick-start or warm-start IPLs, the system uses the pointers to locate the PLPA and Extended PLPA pages. The system then rebuilds the PLPA and Extended PLPA page tables, and uses them for the current IPL.
If CLPA is specified during the IPL, a Cold start is then performed. The PLPA storage is deleted and made available for system paging use. A new PLPA and Extended PLPA are then loaded, and pointers to the PLPA and Extended PLPA pages are recorded in the PLPA page data set.
The LPALST concatenation can have up to 255 extents. If you specify more data sets than the concatenation can contain, the system truncates the LPALST concatenation and issues messages that indicate which data sets were not included in the concatenation.

Contents:

PLPA and Extended PLPA contain all the members of SYS1.LPALIB and any other libraries that are specified in the active LPALSTxx.
The modules must be refreshable.
Load modules with RMODE 24 are placed in the PLPA (below the “line”), while those with RMODE of any are placed in the Extended PLPA (above the “line”).
If one or more LPALSTxx members exist, and the system can open the specified data sets successfully, the system uses the LPALST concatenation to build the PLPA (during Cold starts and IPLs that include the CLPA option). Otherwise the system builds the PLPA from only those modules named in the SYS1.LPALIB.

Link Pack Area (LPA)

Rui Miguel Feio — Fri, 03 Sep 2010 23:42:35 +0000

It’s a common Virtual Storage Area.
It’s non-getmainable.
It’s built at IPL time by loading Load modules contained in SYS1.LPALIB and its concatenations.
There are 2 LPAs: one above “the line” (16MB) and the other below depending on the residence mode of the load module.
Because the Load modules are in the Common Area they are shared by all address spaces in the system.
Modules have to be re-entrant, ie, modules that can be executed concurrently by several tasks but which cannot be modified.
Modules in LPA reside in Virtual Storage.
By placing module data sets in LPA, you can obtain improved MVS system performance.
LPA consists of:
- PLPA – Pageable Link Pack Area (defined in SYS1.PARMLIB(LPALSTxx))
- FLPA – Fixed Link Pack Area (defined in SYS1.PARMLIB(IEAFIXxx))
- MLPA – Modified Link Pack Area (defined in SYS1.PARMLIB(IEALPAxx))

Display all the Storage Groups

Rui Miguel Feio — Fri, 03 Sep 2010 16:52:43 +0000

To display all the Storage Groups of the currently active SMS configuration, we use the command:

D SMS,SG(ALL)

Example:

D SMS,SG(ALL)

IGD002I 15:24:57 DISPLAY SMS 749

STORGRP TYPE SYSTEM= 1 SGTSTVL POOL + SGDB2VL POOL + DUMMY DUMMY . SGOVRFL POOL * SGTAPE TAPE + ***************************** LEGEND ***************************** . THE STORAGE GROUP OR VOLUME IS NOT DEFINED TO THE SYSTEM + THE STORAGE GROUP OR VOLUME IS ENABLED - THE STORAGE GROUP OR VOLUME IS DISABLED * THE STORAGE GROUP OR VOLUME IS QUIESCED D THE STORAGE GROUP OR VOLUME IS DISABLED FOR NEW ALLOCATIONS ONLY Q THE STORAGE GROUP OR VOLUME IS QUIESCED FOR NEW ALLOCATIONS ONLY > THE VOLSER IN UCB IS DIFFERENT FROM THE VOLSER IN CONFIGURATION SYSTEM 1 = SYST