Archive for category Tech – Mainframe
Modified Link Pack Area (MLPA) considerations
Posted by Rui Miguel Feio in MVS, Tech - Mainframe on September 4th, 2010
- 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) considerations
Posted by Rui Miguel Feio in MVS, Tech - Mainframe on September 4th, 2010
- 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) considerations
Posted by Rui Miguel Feio in MVS, Tech - Mainframe on September 4th, 2010
- 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) considerations
Posted by Rui Miguel Feio in MVS on September 4th, 2010
- 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:
Display all the Storage Groups
Posted by Rui Miguel Feio in Storage, Tech - Mainframe on September 3rd, 2010
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
Display the status of a storage group
Posted by Rui Miguel Feio in Storage, Tech - Mainframe on September 2nd, 2010
If you come across the need to check the status of a storage group then you can use the MVS command:
D SMS,SG(storage_group)
For example:
storage group name: STGTSTVL
RESPONSE=SYST
IGD002I 15:17:43 DISPLAY SMS 939
STORGRP TYPE SYSTEM= 1
SGTSTVL POOL +
***************************** 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
If you would like to list the volumes that are part of the Storage Group, you would then issue the command:
D SMS,SG(SGTSTVL),LISTVOL
IGD002I 15:20:50 DISPLAY SMS 737
STORGRP TYPE SYSTEM= 1
SGTSTVL POOL +
VOLUME UNIT SYSTEM= 1 STORGRP NAME
TST001 5B22 + SGTSTVL
TST002 5B23 + SGTSTVL
TST003 5B24 + SGTSTVL
***************************** 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
Display system connectivity of the tape and optical libraries
Posted by Rui Miguel Feio in Storage, Tech - Mainframe on September 2nd, 2010
If you wish to display which libraries are connected to your system you can use the MVS command:
D SMS,LIB(ALL)
Example:
D SMS,LIB(ALL)
RESPONSE=SYST
IGD002I 15:10:50 DISPLAY SMS 869
LIBRARY CLASS SYSTEM= 1
TSTATL1 TAPE +
***************************** LEGEND *****************************
. THE LIBRARY IS NOT DEFINED TO THE SYSTEM
+ THE LIBRARY IS ONLINE
- THE LIBRARY IS OFFLINE
P THE LIBRARY IS PENDING OFFLINE
SYSTEM 1 = SYST
We can see in this example that we have a tape library online on system SYST called TSTATL1. If we wish to obtain more details regarding this library we issue the command:
D SMS,LIB(TSTATL1),DETAIL
CBR1110I OAM library status: 563
TAPE LIB DEVICE TOT ONL AVL TOTAL EMPTY SCRTCH ON OP
LIBRARY TYP TYPE DRV DRV DRV SLOTS SLOTS VOLS
TSTATL1 AL 3584-L22 16 4 4 1060 187 148 Y Y
----------------------------------------------------------------------
MEDIA SCRATCH SCRATCH SCRATCH
TYPE COUNT THRESHOLD CATEGORY
MEDIA5 148 50 0005
----------------------------------------------------------------------
LIBRARY ID: A0669
OPERATIONAL STATE: AUTOMATED
ERROR CATEGORY SCRATCH COUNT: 9
----------------------------------------------------------------------
Convenience I/O station installed.
Convenience I/O station in Input mode.
Convenience I/O station Empty.
Bulk input/output not configured.
How to check if a volume is SMS-managed
Posted by Rui Miguel Feio in Storage, Tech - Mainframe on September 2nd, 2010
One of the ways (and probably the easiest) to check if a volume is SMS-managed is by using the MVS command:
D SMS,VOL(volser)
Here’s an example:
volume: TST001
Command:
D SMS,VOL(TST001)
The result would be:
RESPONSE=SYST
IGD002I 09:52:24 DISPLAY SMS 382
VOLUME UNIT SYSTEM= 1 STORGRP NAME
TST001 5B22 + SGTSTVL
***************************** 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
As we can see from the display, volume TST001 has the unit address 5B22 and is part of the Storage Group SGTSTVL, meaning it’s SMS managed.
Move a dataset that is in Linklist to a different volume
Posted by Rui Miguel Feio in MVS on August 27th, 2009
Sometimes we come across the need of moving to a different volume a dataset that is in Linklist.
We must remember that moving a dataset does not change the list of datasets defined to the current concatenation in any way – the dataset name remains the same -. The system will continue to use the current Linklist set as is and will not rebuild the concatenation.
To make a change to any dataset (ex: move) that is part of an active linklist set, you have to first remove it from the linklist set. When it is no longer part of an active concatenation, then you can modify it as you like and then add it back in.
So, in order to move a Linklisted dataset to a different volume you would have to:
1. Define a new linklist set without the dataset you wish to recatalog.
2. Activate/implement it.
3. Move your dataset.
4. Define a linklist set with the dataset you’ve moved.
5. Activate/implement this new set.
Here’s an example of the commands you would use:
1. P LLA
2. SETPROG LNKLST,UNALLOCATE
3. Create a PROGT1 containing the LINKLIST members EXCEPT the one we want to move and rename LNKLST0x to LNKLST0x + 1
4. SET PROG=T1
5. SETPROG LNKLST,UPDATE,JOBNAME=*
6. Move the dataset into a different volume.
7. Create a PROGT2 containing the LINKLIST members INCLUDING the one we’ve moved to a different volume and increment the LNKLSTxx value (LNKLST0x + 1).
8. SET PROG=T2
9. S LLA,SUB=MSTR
10. SETPROG LNKLST,ALLOCATE
11. SETPROG LNKLST,UPDATE,JOBNAME=*
Here’s a practical example:
Current Linklist set: LNKLST00
Dataset name: SYS2.MOVE.EXAMPLE
Original volume: TST001
Destination volume: TST002
Current PROGxx: PROGT0
Commands:
- P LLA
- SETPROG LNKLST,UNALLOCATE
- Create a PROGT1 containing all the LINKLIST datasets with the exception of SYS2.MOVE.EXAMPLE, and rename all instances of LNKLST00 to LNKLST01.
- SET PROG=T1
- SETPROG LNKLST,UPDATE,JOBNAME=*
- Move dataset SYS2.MOVE.EXAMPLE from volume TST001 to volume TST002.
- Create a PROGT2 containing all the LINKLIST datasets including SYS2.MOVE.EXAMPLES and rename all instances of LNKLST01 to LNKLST02.
- SET PROG=T2
- S LLA,SUB=MSTR
- SETPROG LNKLST,ALLOCATE
- SETPROG LNKLST,UPDATE,JOBNAME=*
Linklist update – Why we need to stop LLA and unallocate the LNKLST
Posted by Rui Miguel Feio in MVS on August 26th, 2009
A couple of months ago I’ve written a post on how to dynamically update the Linklist but some questions have been risen on why we need to stop the LLA and unallocate the Linklist.
Each Linklist dataset has an ENQ from both XCFAS and LLA. An ENQ on a LNKLST dataset prevents that dataset from being altered as long as it is a member of an active LNKLST. So, in order to be able to make changes to the active Linklist you first need to remove those ENQs.
To be able to remove the LLA ENQs you need to stop the LLA. The only impact that stopping the LLA has in the system is loss of performance until you re-start the LLA.
As per the XCFAS ENQs to remove them you need to issue the SETPROG LNKLST UNALLOCATE command. Unallocate indicates that you want to undo all existing allocations obtained while processing active LNKLST sets.
Once you remove the ENQs you are then able to change the Linklist. Now, bear in mind that although you have removed the ENQs the modules are still in Linklist. No abend will come out of this.
Once you are finished with the Linklist changes, you then restart the LLA and ALLOCATE the Linklist.
The UPDATE command indicates that the system is to update an address space so that a specified job or jobs associated with that space can use the current LNKLST set. If the job is using another LNKLST set when the current LNKLST set is activated, it will continue to use the original LNKLST set until it completes operations. When the job completes and restarts, it then uses the datasets defined in the new currently active LNKLST set.