P. 1


|Views: 6|Likes:
Published by Yashwanth Royal
detail veiw of flpa
detail veiw of flpa

More info:

Categories:Types, Presentations
Published by: Yashwanth Royal on Oct 02, 2013
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less






System libraries for the link pack area (LPA) The LPA is part of an address space's common area storage, and is divided into pageable, fixed, and modified sections: • Libraries specified in SYS1.LPALIB, the LPALSTxx, or PROGxx parmlib members are loaded into pageable LPA (PLPA). These libraries contain modules for 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. • IEAFIXxx members specify the modules loaded into fixed LPA (FLPA). This area should be used only for modules that significantly increase performance when they are fixed rather than pageable. The best candidates for the FLPA are modules that are infrequently used, but are needed for fast response. Modules placed in FLPA are always in central storage. • IEALPAxx members specify the modules loaded into modified LPA (MLPA). The MLPA is used to contain reenterable routines from APF-authorized libraries that are to be part of the pageable extension to the link pack area during the current IPL. Note that the MLPA exists only for the duration of an IPL.

Link pack area (LPA) modules are loaded in common storage, and shared by all address spaces in the system. Because these modules are reentrant and are not selfmodifying, each can be used by a number of tasks in any number of address spaces at the same time. Modules placed anywhere in the LPA are always in virtual storage. To prevent their pages from being stolen, LPA modules must be referenced very often. When a page in LPA (other than in FLPA) is not continually referenced by multiple address spaces, it tends to be stolen.


Authorizing access with the MVS library lookaside (LLA) facility
If you are using the library lookaside (LLA) facility of MVS, you can control a program's ability to use the LLACOPY macro. Authorize the CICS region's userid in one of the following ways: • It must have UPDATE authority to the data set that contains the LLA module. • It must have UPDATE authority in the FACILITY class to the resource CSVLLA. datasetname, where datasetname is the name of the library that contains the LLA module. For example: • RDEFINE FACILITY CSVLLA.datasetname UACC(NONE) NOTIFY PERMIT CSVLLA.datasetname CLASS(FACILITY) ID(....) ACCESS(UPDATE) Modules loaded by CICS® from the DFHRPL libraries may be managed by the MVS™ LLA (library lookaside) facility. LLA is designed to minimize disk I/O by keeping load modules in a VLF (virtual lookaside facility) dataspace and keeping a version of the library directory in its own address space.

For this reason it is possible to see I/O against a program library even when it is managed by LLA. it results in a BLDL with physical I/O against the DCB specified. It is likely that staging some modules from the LNKLST could have more effect than staging modules from the CICS libraries. both may increase the DASD activity significantly. This is due to LLA’s observation of the load activity and its decisions about which modules to stage (keep) in the VLF dataspace. A value too small can cause excessive movement of that VLF object class. However.LLA manages modules (system or application) whose library names you have put in the appropriate CSVLLA member in SYS1. a value too large can cause excessive paging. it bypasses the LLA directory processing. that DASD utilization actually decreases. storage cost. LLA also manages the system LNKLST. While this activity . In addition to any USER-defined CICS DFHRPL libraries. but determines from LLA whether the program is already in VLF or must be fetched from DASD. Improved transaction response time Better DASD utilization. The use of LLA to manage a very busy DFHRPL library can show two distinct benefits: 1. Either a build linklist (BLDL) macro or a LLACOPY macro is issued to return the directory information to pass to the load request. See the z/OS MVS Initialization and Tuning Guide manual for information on LLA and VLF parameters. For more information about the FREEZE and NOFREEZE options. 2. There are two optional parameters in this member that affect the management of specified libraries: FREEZE Tells the system always to use the copy of the directory that is maintained in the LLA address space. contentions. the sum of bytes from the working set of modules is greater than the MAXVIRT parameter for the LLA class of VLF objects. You can increase this value by changing it in the COFVLF member in SYS1. as throughput increases. The LLACOPY macro is used to update the LLA-managed directory entry for a module or a list of modules. If the directory information does not match that which is stored within LLA.PARMLIB. that is. Another contributing factor for continued I/O is the system becoming "MAXVIRT constrained". see the z/OS MVS Initialization and Tuning Guide. LLA attempts to select those modules whose staging gives the best reductions in response time. and an optional user-defined quantity. It is possible. If a module which is LLA managed has an LLACOPY issued against it. LLA makes decisions on what is staged to VLF only after observing the fetch activity in the system for a certain period. Effects of LLACOPY CICS can use one of two methods for locating modules in the DFHRPL concatenation. When CICS issues a LOAD and specifies the directory entry (DE). Which macro is issued is dependant upon the LLACOPY system initialization parameter and the reason for the locate of the module. NOFREEZE Tells the system always to search the directory that resides in DASD storage. FREEZE and NOFREEZE are only relevant when LLACOPY is not used. the LLA tables are then updated. LLA does not automatically stage all members that are fetched.PARMLIB. keeping both subsystems synchronized.

Note that it is not advisable to use a NOCONNECT option when invoking the BLDL macro because the DFHRPL concatenated data set may contain partitioned data set extended (PDSE) data sets. the default. . the information returned will be from the LLA copy of the directory. # For more information about the LLACOPY system initialization parameter. This could mean an out of date version of a module is loaded #upon its first use. When a BLDL is issued against an LLA managed module. BLDL does not require the SYSZLLA1. It will not necessarily result in physical I/O to the data set and may therefore be out of step with the actual data set. each #time the RPL data set is searched for a module.update is held. A BLDL macro is issued at all #other times.takes place an ENQ for the resource SYSZLLA1. # If you code LLACOPY=NO. This ensures #that CICS always obtains the latest copy of any LLA-managed modules. if one exists. PDSE can contain more function than PDS. This is then unavailable to any other LLACOPY request on the same MVS system and therefore another LLACOPY request is delayed until the ENQ is released. CICS never issues an LLACOPY macro. but CICS may not recognise some of this function. CICS issues a LLACOPY macro each #time a module is located from the RPL data set. There #is a small chance of delay because of a failure to obtain an ENQ while another #LLACOPY completes and there is some extra pathlength involved in maintaining #the LLA tables. PDSE also use more virtual storage . CICS issues the LLACOPY macro when loading a module #as a result of a NEWCOPY or PHASEIN request. The BLDL macro also returns the directory information. but the latest version would be used after a NEWCOPY or #PHASEIN.1. Version 7.update ENQ and is therefore less prone to being delayed by BLDLs on the same MVS system. a BLDL is issued. Instead. #see the CICS System APF Debug Tool for z/OS. # If #you code LLACOPY=NEWCOPY. Customization Guide Setting up the APF-authorized non-link list data sets This section describes where to place certain Coverage Utility load modules so that the correct people have access to them. ### The SIT Parameter LLACOPY # If you code LLACOPY=YES. This is done either on the #first ACQUIRE or on any subsequent NEWCOPY or PHASEIN requests.

3. 4. The APF-authorized data set does not need to be in the link list. You can add the code in the following example to the RACF profile: RDEFINE PROGRAM(EQACUOIN) NOTIFY(notify) UACC(NONE) + DATA('RACF profile for Coverage Utility monitor') + ADDMEM('authlib'/'volser'/PADCHK) OWNER(owner)) RDEFINE PROGRAM(EQACUOSV) NOTIFY(notify) UACC(NONE) + DATA('RACF profile for Coverage Utility monitor') + ADDMEM('authlib'/'volser'/PADCHK) OWNER(owner) SETROPTS WHEN(PROGRAM) REFRESH .  EQACUOCM (monitor interface)  EQACU9M0 (monitor messages)  EQACU9M1 (monitor messages)  EQACU9M2 (monitor messages and only if the Japanese feature is installed)  EQACU9M3 (monitor messages and only if the Korean feature is installed) 2. you must create RACF profiles to prevent access to these load modules. The APF-authorized data set must not be in the link list.SEQAEXEC data set and set the INST_Auth_SEQAMOD variable to the name of the data set from step 1 that contains EQACUOCM. 1. Copy4 the following load modules into an APF-authorized data set that only system programmers can access: o EQACUOIN (SVC installer) o EQACUOSV (SVCs) Creating RACF profiles If you place Coverage Utility load modules that must not be accessible to all users in an APF-authorized data set that is accessible to all users.Placing Coverage Utility load modules in an APF-authorized data set accessible to all users Certain Coverage Utility load modules must be placed in an APF-authorized data set that is accessible to all your users. Placing Coverage Utility load modules in an APF-authorized data set not accessible to general users Certain Coverage Utility load modules must be placed in an APF-authorized data set that is accessible only to system programmers.SEQAAUTH data set as APF-authorized. do one of the following alternatives: • • Mark the hlq. o Do not mark the hlq. o Create Resource Access Control Facility (RACF) profiles to restrict access to these load modules. To place the load modules in an APF-authorized data set. Copy4 the following load modules to an APF-authorized data set that all users can access.SEQAMOD accessible to all users by using one of the following alternatives: o Mark the hlq.PARMLIB data set.SEQAAUTH data set as APF-authorized1 and do one of the following: o Limit access to only system programmers.SEQAMOD data set as APF-authorized. Do not mark the hlq. Edit the EQASTART member of the hlq. Issue the PARMLIB UPDATE(xx) command from TSO or IPL your system. Make the load modules in hlq.SEQAMOD data set as APF-authorized1 and make it accessible to all users by creating a Resource Access Control Facility (RACF(R)) profile. Add the EQACUOCM program to the AUTHPGM entry in the member IKJTSOxx of the SYS1.

authlib Name of the APF-authorized data set that contains volser Volume serial of authlib data set or owner TSO user ID or RACF group name of the person or persons that own this profile. EQACUOIN and EQACUOSV.PERMIT EQACUOIN CLASS(PROGRAM) ID(id) ACCESS(READ) PERMIT EQACUOSV CLASS(PROGRAM) ID(id) ACCESS(READ) SETROPTS WHEN(PROGRAM) REFRESH The above code restricts access to EQACUOIN and EQACUOSV by granting read access to only id. ****** to specify the current SYSRES volume. The following list describes the operands used in this example: notify TSO user ID of the person who is notified of a RACF access failure. id TSO user ID or RACF group name of the person or persons who have the ability to install the SVCs. .

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->