----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
I believe that you may need to also do a LNKLST DELETE of the OEM#T
library before you do the LNKLST ADD statements. I'm assuming the OEM#T
library is in the current LNKLST so it would be copied to the new one.
Just doing the LNKLST ADD statements will end up with 2 copies of OEM#T
in the LNKLST concatenation.
Rex
APF ADD DSNAME(OEM#T.CAI.CAILIB) SMS
And:
LNKLST DEFINE NAME(LNKLST01) COPYFROM(CURRENT)
LNKLST ACTIVATE NAME(LNKLST01)
Thanks in advance...
----------------------------------------------------------------------
Dave Gibney
Information Technology Services
Washington State University
Thanks,
George Rodriguez
Specialist II - IT Solutions
Application Support / Quality Assurance
PX - 47652
(561) 357-7652 (office)
(561) 707-3496 (mobile)
School District of Palm Beach County
3348 Forest Hill Blvd.
Room B-332
West Palm Beach, FL. 33406-5869
Florida's Only A-Rated Urban District For Five Consecutive Years
----------------------------------------------------------
--------------Palm Beach County Schools---------------------
Rated "A" by the Florida Department of Education 2005-2009
-----Home of Florida's first LEED Gold Certified School-----
-----------http://www.palmbeachschools.org-------------
The District of Palm Beach County is an Equal Education Opportunity
Provider and Employer. Under Florida law, e-mail addresses are
public records. If you do not want your e-mail address released in
response to a public records request, do not send electronic mail
to this entity. Instead, contact this office by phone or in
writing.
----------------------------------------------------------------------
BTW, after you "copy from current" you can delete the old one and
add the new one. ASsuming there are no other duplicate modules
in the LNKLST, the order you specify those delete / add statements
don't matter nor will it affect performance if the ADDed library
goes to the end (which it will by default).
In addition to BEFORE and AFTER, there is also ATTOP.
Why not read the fine manual. You can fine the init and tuning reference here:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/IEA2BK51
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
>Since the beginning of dynamic LNKLST - OS/390 R3 (seems like a
>life time ago).
>
>BTW, after you "copy from current" you can delete the old one and
>add the new one. ASsuming there are no other duplicate modules
>in the LNKLST, the order you specify those delete / add statements
>don't matter nor will it affect performance if the ADDed library
>goes to the end (which it will by default).
>
>In addition to BEFORE and AFTER, there is also ATTOP.
>
>Why not read the fine manual. You can fine the init and tuning reference here:
>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/IEA2BK51
>
And if you did, you would see I shouldn't have mentioned "BEFORE". There
is no such animal. (obviously you can accomplish the same thing with
AFTER and a different library name).
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
----------------------------------------------------------------------
Sorry about that, I spoke before I looked. I knew I could do it :)
No one mentioned one little thing about the APF part:
>APF ADD DSNAME(OEM#P.CAI.EZT.R6M4.CAILIB) SMS (this one
>in front )
>APF ADD DSNAME(OEM#T.CAI.CAILIB) SMS
Specifically the words "this one in front".
The order of APF statements is largely irrelevant.
Either a potential data set is somewhere in the APF list or it does not.
It is not a concatenation for which order can matter.
Peter Relson
z/OS Core Technology Design
>This is a how to question. In the SYS1.PARMLIB(PROG00) member I have an
>existing library that I really need to delete but I can't. Instead I want
>to add a new entry in front of the one that's there now.
For new address spaces the earlier replies should have told you what you
need. If you want to update the link list for existing address spaces, you
risk a crash.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
1. Create temporary LNKLST set using SET PROG=CT
a. Create temporary LNKLST set from current one ("source" LNKLST set)
b. Force everyone to use temp LNKLST set.
c. Delete source LNKLST set.
4. Update PROGxx member that created the "source" LNKLST (the one used by
IPL). We have separate PROGxx members for LNKLST, APF, & EXIT.
5. Re-create updated LNKLST with SET PROG=xx.
6. Switch back to updated LNKLST set using SET PROG=DT
a. Force everyone to use updated LNKLST set.
b. Delete temporary LNKLST set.
7. Cycle LLA to pickup new library names.
What I like about my process is that my update tend to automatically persist
across the next IPL
I have not thoroughly tested my procedure to ensure that it handles every
theoretical situation, but so far it has never failed me in over 10 years of
use.
Excerpt from my LINKLIST doc:
=========================================================================
To dynamically change LNKLST, perform the following steps:
1. Display defined linklist sets using console command:
DISPLAY PROG,LINKLIST,NAMES
CSV472I hh.mm.ss LNKLST DISPLAY
LNKLST SET LNKLST SET LNKLST SET LNKLST SET
LNKLST
LNKLST is should be the only LNKLST SET. Any others would be due to
some manual action, probably an error or incomplete process which
should investigated.
2. Display current linklist set name and data sets using console
command: DISPLAY PROG,LINKLIST
CSV470I 11.38.13 LNKLST DISPLAY
LNKLST SET LNKLST LNKAUTH=LNKLST
ENTRY APF VOLUME DSNAME
1 A R160H1 SYS1.LINKLIB
2 A R160H1 SYS1.MIGLIB
2 A R160H1 SYS1.MIGLIB
3 A R160H1 SYS1.CSSLIB
4 A W4S101 SYS2.WEB4.LINKLIB.ZOS16
5 SYS113 SYS2.MVS1.CICSTS.SDFHLINK
6 A SYS103 SYS2.MVS1.DSNHELP.SEOYLOAD
...
3. Backup and update the normal PROGnL member as needed.
4. Create temporary linklist by issuing console command: SET PROG=CT
The commands in PROGCT will:
a. Copy the standard linklist (must be named LNKLST), to new
linklist named TEMP.
b. Activate temporary linklist.
c. Update all jobs to use the temporary linklist.
d. Delete standard linklist, LNKLST, so that it can be redefined in
the next step.
* e. You MUST wait for the IEE536I PROG VALUE CT NOW IN EFFECT
message.
5. Activate updated linklist, PROGnL, by issuing console command:
SET PROG=nL
The PROGnL member that you updated should:
a. Redefine the standard linklist named LNKLST.
b. Activate it.
* c. You MUST wait for the IEE536I PROG VALUE xL NOW IN EFFECT
message.
6. Delete temporary linklist by issuing console command: SET PROG=DT
The commands in PROGDT will:
a. Update all jobs to use updated linklist, LNKLST.
b. Delete temporary linklist.
* c. You MUST wait for the IEE536I PROG VALUE DT NOW IN EFFECT
message.
7. Cycle LLA to pickup new LNKLST allocations (MODIFY LLA,REFRESH only
picks up directory updates and NOT library name changes).
STOP LLA
START LLA,SUB=MSTR
=========================================================================
Member PROGCT
/* This member moves LNKLST into TEMP linklist */
LNKLST Define Name(TEMP) copyfrom(LNKLST)
LNKLST Activate Name(TEMP)
LNKLST Update Job(*)
LNKLST Undefine Name(LNKLST)
Member PROGDT
/* This member deletes TEMP linklist */
LNKLST Update Job(*)
LNKLST Undefine Name(TEMP)
1. Create temporary LNKLST set using SET PROG=CT
a. Create temporary LNKLST set from current one ("source" LNKLST set)
b. Force everyone to use temp LNKLST set.
c. Delete source LNKLST set.
2. Update PROGxx member that created the "source" LNKLST (the one used by
IPL). We have separate PROGxx members for LNKLST, APF, & EXIT.
3. Re-create updated LNKLST with SET PROG=xx.
4. Switch back to updated LNKLST set using SET PROG=DT
a. Force everyone to use updated LNKLST set.
b. Delete temporary LNKLST set.
5. Cycle LLA to pickup new library names.
----------------------------------------------------------------------
>Many years ago, I wrote down my process to dynamically update LINKLIST.
>It uses the command "LNKLST Update Job(*)" which may not be
>appropriate in your environment (i.e., read the manual and test it
You can never adequately test LNKLST UPDATE JOB(*). It has been my
experience that it usually works with no problems. Indeed, I have used it
many times and never yet had a problem, but there is a reason that the
manual cautions against using it, and that it is known that it *can* cause
errors. I would never use it on a production system. Your procedure does
it twice, doubling the risk.
>in your environment). The basic logic is:
>
>1. Create temporary LNKLST set using SET PROG=CT
> a. Create temporary LNKLST set from current one ("source" LNKLST set)
> b. Force everyone to use temp LNKLST set.
> c. Delete source LNKLST set.
>2. Update PROGxx member that created the "source" LNKLST (the one used by
>IPL). We have separate PROGxx members for LNKLST, APF, & EXIT.
>3. Re-create updated LNKLST with SET PROG=xx.
>4. Switch back to updated LNKLST set using SET PROG=DT
> a. Force everyone to use updated LNKLST set.
> b. Delete temporary LNKLST set.
>5. Cycle LLA to pickup new library names.
I'm pretty sure that cycling LLA is not needed. When the new LNKLST set is
activated, LLA automatically manages all the data sets in the new LNKLST.
If you have removed libraries from LNKLST and ensured that no address space
still needs those libraries, you might want to remove them from LLA
management, though.
--
Tom Marchant
It would nice if z/OS would let you rename an active LNKLST set or let you
create new versions kind of like GDGs.
Correct, cycling LLA is usually not needed. The only case that I've found
were is seems to be needed is when moving a library already in linklist to a
new volume without renaming that data set (For example, when enlarging a
data set which requires it to be moved to a new volume with more space). LLA
seems to have problem with recognizing that the volser changed and the
allocation to the old volume remains.
I wish IBM would enumerate the conditions which could cause a crash, rather
than blindly say use at your own risk. It obvious that if you have an
application that does own BLDL against linklist, any change to linklist
could be problem. I would like to know what other situations might be
problematic.
Thanks for posting the warning.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of Tom Marchant
Sent: Thursday, January 07, 2010 12:25 PM
To: IBM-...@bama.ua.edu
Subject: Re: LNKLST & APF Help
You can't rename an existing LNKLST set, but you can create your new LNKLST
set with a new name. I see that you name yours LNKLST. You have 16
characters available for the name. Surely you could come up with a new name
to indicate that it is the new version.
>
>Correct, cycling LLA is usually not needed. The only case that I've found
>were is seems to be needed is when moving a library already in linklist to a
>new volume without renaming that data set (For example, when enlarging a
>data set which requires it to be moved to a new volume with more space). LLA
>seems to have problem with recognizing that the volser changed and the
>allocation to the old volume remains.
You should *never* move an active LNKLST data set. The manual gives a
lengthy description of how to proceed when this kind of action is needed.
>
>I wish IBM would enumerate the conditions which could cause a crash, rather
>than blindly say use at your own risk.
IIRC, any time a module is being loaded from LNKLST, the LOAD could fail,
depending upon the timing of the UPDATE and the LOAD. To enumerate all of
the possible failures in IBM code that could occur if a LOAD fails would
likely be a very long list.
We never actually *move* an active linklist dataset. Technically, it would
be a copy. We would update the catalog to point to the new copy. Later after
no one is using the original would it finally be deleted.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of Tom Marchant
Sent: Thursday, January 07, 2010 3:18 PM
To: IBM-...@bama.ua.edu
Subject: Re: LNKLST & APF Help
>I admit it, I'm lazy. I don't like having to track the current LNKLST set
>name (we only IPL production 2 to 4 times a year as needed). I would like to
>use the same LNKLST set name that is in my PROGxx member that I used during
>the IPL. It could work similar to GDGs. I would backup and make my changes
>to our PROGxx member (member name never changes, so no update is required to
>IEASYSxx), do a T PROG=xx (that checks and implements my changes and I'm
>fairly sure that the next IPL will succeed). The new LNKLST set would be
>named LNKLST (or whatever name we were using), the previous one would be
>renamed to LNKLSTnn, such that LNKLST1 would be oldest, LNKLST2 would be
>next oldest, etc.
Why do you need to track the current LNKLST set name?
You could get the same effect if every time you updated your PROGxx you
changed the name of the LNKLST by incrementing the nn or even by including
the date of the change as part of the name, e.g. LNKLSTyymmdd. That could
simplify your procedure by requiring only one change.
Thanks,
George Rodriguez
Specialist II - IT Solutions
Application Support / Quality Assurance
PX - 47652
(561) 357-7652 (office)
(561) 707-3496 (mobile)
School District of Palm Beach County
3348 Forest Hill Blvd.
Room B-332
West Palm Beach, FL. 33406-5869
Florida's Only A-Rated Urban District For Five Consecutive Years
--
Tom Marchant
----------------------------------------------------------
--------------Palm Beach County Schools---------------------
Rated "A" by the Florida Department of Education 2005-2009
-----Home of Florida's first LEED Gold Certified School-----
-----------http://www.palmbeachschools.org-------------
The District of Palm Beach County is an Equal Education Opportunity
Provider and Employer. Under Florida law, e-mail addresses are
public records. If you do not want your e-mail address released in
response to a public records request, do not send electronic mail
to this entity. Instead, contact this office by phone or in
writing.
----------------------------------------------------------------------
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of Tom Marchant
Sent: Friday, January 08, 2010 8:25 AM
To: IBM-...@bama.ua.edu
Subject: Re: LNKLST & APF Help
We have lost our ICC console connectivity and we are getting below error
while trying to connect again.
V 6E1,CONSOLE
IEE936I CONSOLE SD0112 INITIALIZATION ERROR - RC:01 - 3277-2 IS
ASSUMED
D C,U=(06E1),L=Z
IEE889I 16.12.43 CONSOLE DISPLAY 637
MSG: CURR=1 LIM=5000 RPLY:CURR=13 LIM=500 SYS=SD01 PFK=X0
CONSOLE ID --------------- SPECIFICATIONS ---------------
SD0112 21 COND=A AUTH=MASTER NBUF=1
06E1 AREA=Z MFORM=T,J
SD01 DEL=RD RTME=1/4 RNUM=5 SEG=10 CON=N
USE=FC LEVEL=ALL PFKTAB=PFKTAB1
ROUTCDE=ALL
LOGON=OPTIONAL
CMDSYS=SD01
MSCOPE=SD01
MONITOR=JOBNAMES
ALTGRP=SD012
IEE501I CONSOLE SD0112 FAILED, REASON=IOER . ALL ALTERNATES
UNAVAILABLE, CONSOLE IS NOT SWITCHED
We have tried switching the console but no luck and all the console
devices giving the same problem.
SWITCH CN=(SD0100)
IEE686I SWITCH COMMAND REJECTED, SD0112 NO ALTERNATES FOUND
SWITCH CN=(SD0112)
Regards,
Chokalingam Thangavelu
Wipro Limited (Company Regn No in UK FC 019088)
Address: Level 2, West wing, 3 Sheldon Square, London W2 6PS, United Kingdom. Tel +44 20 7432 8500 Fax: +44 20 7286 5703
VAT Number: 563 1947 27
(Branch of Wipro Limited (Incorporated in India at Bangalore with limited liability vide Reg no L99999KA1945PLC02800 with Registrar of Companies at Bangalore, India. Authorized share capital Rs 3550 mn))
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
Hi,
<snippage>
"Check the specification for RNUM, SEG or AREA in the CONSOLxx parmlib
member for incorrect values."
This is what LookAt gave for IEE936I. It is also what I suspect -- your
CONSOLxx (00, 01, what ever) has either been changed or deleted.
Regards,
Steve Thompson
-- Opinions expressed by this poster may not reflect those of poster's
employer --
We are getting the below error while connecting the console thru IBM
PCOM.
PCSTLNET013 - an unknown error occurs during device type negotiation.
Regards,
Chokalingam Thangavelu
TWUL Project
Thames Water IS
In Partnership with Wipro Technologies
Mobile: 07515520914
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
Behalf Of Thompson, Steve
Sent: Monday, January 18, 2010 4:36 PM
To: IBM-...@bama.ua.edu
Hi,
<snippage>
Regards,
Steve Thompson
Wipro Limited (Company Regn No in UK FC 019088)
Address: Level 2, West wing, 3 Sheldon Square, London W2 6PS, United Kingdom. Tel +44 20 7432 8500 Fax: +44 20 7286 5703
VAT Number: 563 1947 27
(Branch of Wipro Limited (Incorporated in India at Bangalore with limited liability vide Reg no L99999KA1945PLC02800 with Registrar of Companies at Bangalore, India. Authorized share capital Rs 3550 mn))
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
----------------------------------------------------------------------
I believe there is a TRACE function for the LU session.
Check that 06E1 is online and that the LU name is still valid, this LU
names should match that in your HMC ICC config.
Are any other ICC terminal working ?
Hi,
Hi,
<snippage>
Regards,
Steve Thompson
This e-mail message and any attachments transmitted with it are confidential and are intended solely for the use of its authorized recipient(s). If you are not an intended or authorized recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the information contained in this e-mail is prohibited. If you have received this message in error or are not authorized to receive it, please immediately notify the sender and delete the original message and all copies of it from your computer.
>PCSTLNET013 - an unknown error occurs during device type negotiation.
I suspect this is the key problem[1] and that the problem you see all derive
from not having a connection in place.
In principle it is unfortunate that there is no online PCOMM manual with an
explanation of the PCSTLNET013 error message. In practice the explanation,
which was presented in the IBMTCP-L thread from October 2005 to which
Dave Cox directed you in a private e-mail which fortunately you appended to
your later post, added nothing. Here it is anyhow to back up my bald
statement:
<quote>
------------------------------------------------------------------------
PCSTLNET013
An unknown error occurred during DEVICE-TYPE negotiation. Make sure the
Telnet3270 parameters are correct. This connection cannot be established.
Explanation: TN3270E protocol only. An unknown error occurred during DEVICE-
TYPE negotiation.
User Response: Make sure the correct LU name is specified in the Telnet3270
advanced customization window.
------------------------------------------------------------------------
</quote>
Note that the "negotiation" to which this message refers is described in RFC
2355 and that there are some very helpful examples in the RFC in Section 13.4.
I am not at all a specialist in using the OSA ICC but I very much expect that
the IEE936I (RC:01) and IEE501I error messages indicate that there is no
TN3270 connection in place - which takes us back to the PCSTLNET013 error
message.
Perhaps someone who is using an OSA ICC can verify this.
Your problem with so-called[2] "LU name" may be that the ICC considers that
the ICC so-called[2] "session" associated with the "LU name" is still "in use". It
may be that an inactivity time-out needs to happen before the "session"
becomes free again.
Clearly this "session"/"LU name" was working. Does it work again if you wait for
a few minutes? Go and get a coffee!
If you continue to have a problem - or you would like to adjust your
customisation so that you can more quickly re-establish the console
connection, you may like to post the parameters you have used with
ICC "session" associated with console SD0112, address 06E1 - assuming that's
the way you have defined the ICC. If you have adopted another approach,
you may like to describe what it is. Note that the parameters to which I am
referring are those described under the section title "OSA-ICC server
configuration" in Chapter 2, "Pre-install" of the "OSA-Express Integrated
Console Controller Implementation Guide" redbook, SG24-6364-01.
Chris Mason
[1] And you'll see I am using a word you seem to have eschewed in your
Subject text. According to my understanding of the Queen's English, you have
a *problem* not a mealy-mouthed "issue"! Of course, if I tried to correct this
misuse every time I found it - especially in the lists to which I subscribe where
most threads start off with the description of a *problem* described as
an "issue", I would very quickly wear out my fingers. Thus I restrict myself to
sounding off only in those threads where I try to have something - else -
useful to say.
[2] "So-called" because "LU" is an SNA concept and, when using your TN3270E
connection to be a z/OS console, SNA (VTAM) is not involved.
Similarly "session" is the incorrect word in the ICC customisation for what
should be described as the TN3270E *connection* between a TN3270E client
(PCOMM in your case) and the TN3270E server, the ICC.
Incorrect use of "LU" and "session" can cause confusion in the case the ICC is
used to connect to VTAM and thus the communication does pass into an SNA
environment where the terms "LU" and "session" are (a) different from the ICC
environment and (b) correctly used terms.
----------------------------------------------------------------------