Jerry

You'll get the latest information regarding setting up the IPL process these
days from other contributors. It's a few years now since I dabbled with
IPLing MVS.

However there's one form of words that you use which worries me and
indicates you may have a false concept of what CLPA does. The words are
"CLPA enabled" and you use them in this post and you original post.

"CLPA" is defined in summary in "z/OS V1R8.0 MVS Initialization and Tuning
Reference" as follows:

<quote>

CLPA - Causes NIP to load the link pack area with the modules contained in
the LPALST concatenation. Also, CLPA purges VIO data set pages that were
used in the previously initialized system. Thus, CLPA implies CVIO.

</quote>

NIP = nucleus initialisation program (or process)

"CLPA" is defined in detail in "z/OS V1R8.0 MVS Initialization and Tuning
Reference" as follows:

<quote>

CLPA

(See also the MLPA parameter for temporary additions to the LPA, and the
CVIO parameter for the deletion of VIO data sets.)

This parameter causes NIP to load the LPA with all modules contained in the
LPALST concatenation. Modules listed in the specified LPA pack list member
(IEAPAKxx) are packed together, preferably in one-page groups. (See
description of IEAPAKxx.) Modules not in the pack list are loaded in size
order, large modules first, then smaller modules to fill unused space.

PLPA pages are written to auxiliary storage. Only one set of PLPA pages can
exist in paging space. Modules in the LPALST concatenation must be
reenterable and refreshable because the system uses the processor's page
protection facility, which enforces read-only access to each PLPA page.

CLPA should be specified after the installation has modified a data set in
the LPALST concatenation and wants to reload the PLPA with new or changed
modules.

Note: CLPA also implies CVIO, so that VIO data set pages on local page data
sets are automatically purged. (See the description of CVIO for further
information.)

The CLPA parameter is not needed at the first IPL. NIP detects the cold
start condition internally, noting that the PLPA has not been loaded.

If CLPA is not specified, NIP tries to find a usable PLPA in the existing
page data sets. If NIP is successful, a quick start or a warm start occurs,
and the auxiliary storage manager (ASM) obtains the records that specify
where the PLPA pages reside on auxiliary storage. It then reestablishes the
previous set of PLPA pages. The old PLPA may be reused for any number of
system initializations, if CLPA is not specified. However, page data sets
that contain the last used set of PLPA pages must be mounted. If they are
not, the operator is asked to mount them. If the operator bypasses mounting,
ASM initialization requests a different page data set and forces a "cold"
start. NIP then reestablishes the PLPA as it does when CLPA is specified. In
this cold start, both the previously established PLPA and existing VIO data
set pages are logically deleted from paging space.

The fixed LPA and the modified LPA, however, are not automatically reused in
a quick start or a warm start. They must be respecified. Existing VIO data
set pages on local page data sets are retained in a warm start, unless the
CVIO or CLPA parameter is forced. Such pages are not retained in a quick
start or a cold start. (See the description of the CVIO parameter.)

If CLPA is specified and a set of PLPA pages already exists on a paging data
set, NIP frees the existing PLPA and updates the appropriate records to
reflect the new PLPA pages on auxiliary storage. NIP loads the LPA from the
LPALST concatenation, as previously described.

IBM suggests that you have an IEASYSxx member that does not specify CLPA.
This permits you to load the initial program without rebuilding the PLPA if
it is not possible to access your LPA data sets.

</quote>

I have always thought that "CLPA" stands for "create link pack area" but I
could be wrong, either way, that's effectively what it does.

You'll note the recommendation *not* to have CLPA permanently specified in
your IEASYSxx member.

After a change to the "LPALST concatenation", CLPA need be specified for one
IPL and one IPL only. There is no concept of a system (or environment)
having been "CLPA enabled". The only operation that is "CLPA enabled" is the
IPL process. Once the IPL is complete there is no difference between a
system where CLPA was specified in IEASYSxx and one where it was not.

At least that's the way it was when I last played with these things and I
see no change in the text I just pasted from the manuals.

Chris Mason

----- Original Message ----- 
From: "Jerry Ragland" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: <IBM-MAIN@BAMA.UA.EDU>
Sent: Wednesday, 08 November, 2006 6:18 PM
Subject: Re: IPL with CLPA


Thanks for the reply Rex.

Yes, IEASYSAW is the member used during the IPL. From the logs -

"*IEA247I USING IEASYSAW FOR z/OS 01.04.00 HBB7707"

IEASYSAW contents -

CLOCK=00,                     SELECT CLOCK00
CLPA,
CMB=(UNITR,COMM,GRAPH,CHRDR), ADDITIONAL CMB ENTRIES
.
.
.
LPA=DB,                       SELECT LPALST00
MAXUSER=250,                  SYS TASKS PLUS INITS PLUS TSOUSERS
MLPA=DI,                      DI FOR IMS

in IEASYSAW LPA is given as DB. In the LPALSTDB file the **.SDFHLPA is added
correctly.

LPALSTDB file -

.
.
SYS1.SICELPA,
SYS1.CICSTS31.CICS.SDFHLPA(DSK32E),
CICSTS22.CICS.SDFHLPA(S4CIC1),
.
.

from the replies I understand that specifying CLPA parameter in IEASYSAW
will automatically enable CLPA during IPL and all the **.SDFHLPA members
will be added to the LPA area. In that case my environment is CLPA enabled.

Is there a way to check the contents of LPA area?
Is there any other reason for the modules not included in the LPA area?

-Jerry.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to