Re: Silly linklist dataset question

APF processing uses the real data set name. Thus an entry that is for an alias is basically useless. Health Check CSV_APF_EXISTS reports DS is alias with the explanation: The data set name is an alias of another data set. An APF list entry that has the alias of a data set rather than the real

Re: Silly linklist dataset question

Thanks Brian for the sanity check, I'm going to assume the APF entry was added because my predecessor was not sure, so added it to be safe, this is now causing headaches for audit issues. removing the entry will check off an audit to-do for me Carmen On 4/29/2022 2:31 AM, Brian Westerman

Re: Silly linklist dataset question

The alias name is not valid to z/OS processing for APF. It's in the manual somewhere. The alias name is jsut a catalog construct, it doesn't physically exist on DISK anywhere. Brian -- For IBM-MAIN subscribe / signoff /

Re: Silly linklist dataset question

-Original Message- From: IBM Mainframe Discussion List On Behalf Of Carmen Vitullo Sent: Thursday, April 28, 2022 10:28 AM To:IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Silly linklist dataset question [EXTERNAL EMAIL] DO NOT CLICK links or attachments unless you recognize the sender and know

Re: Silly linklist dataset question

t; To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Silly linklist dataset question > > [EXTERNAL EMAIL] DO NOT CLICK links or attachments unless you recognize > the sender and know the content is safe. > > not to bring an old subject back from the dead, I have a somewhat > related question.

Re: Silly linklist dataset question

not to bring an old subject back from the dead, I have a somewhat related question. some background; for many years my predecessor has been create alias pointers for 'TCPIP.V2R2.SEZALINK' 'V3R1.SEZALINK' and some other variations of the name that IBM in its infinite wisdom changed many

Re: Silly linklist dataset question

Mark J wrote: Datasets in our linklist are APF authorized via LINKAUTH=LNKLST. Is there any differences on how program fetch behaves if a dataset in the linklist is also APF authorized in PROGxx as far as modules being fetched from the linklist? To the specific question: "no". When

Re: Silly linklist dataset question

There was a very recent discussion here (3/31/2022) with a response from Peter Relson of IBM that clarified the separation of LINKAUTH=LNKLST, PROGxx, and JOBLIB/STEPLIB.  My understanding from that and prior discussions is that the short answer is "No, as long as the module is actually

Re: Dynamic LINKLIST impact

Tom, I envision this a something that could be done at the fetch services routine level while preserving the user interface, so that LOAD LINK end users are not affected.  The awareness of which library DCB is actually being used  for the fetch I/O and whether LNKLIST is ieven nvolved is surely

Re: Dynamic LINKLIST impact

On Fri, 19 Jul 2019 10:47:14 -0500, Joel C. Ewing wrote: >The manner >in which services and address spaces were allowed to use LNKLST DCBs >should have been much better constrained so that those system processes >using a LNKLST DCB for any extended time were required to "register" >their active

Re: Dynamic LINKLIST impact

Peter, I understand that you are coming from a much deeper understanding of the current internals of z/OS than the rest of us and from the standpoint of what would be practical to implement, but what you are basically saying is that the current design of LNKLST is flawed and difficult to adapt for

How does HPE non-stop prev. Tandem do it was Re: Dynamic LINKLIST impact

[Default] On 19 Jul 2019 04:46:06 -0700, in bit.listserv.ibm-main rel...@us.ibm.com (Peter Relson) wrote: In looking at the below discussion, I am brought back to the question as to how HPE non-stop (started out as Tandem) manage the update process to avoid a shutdown. Even though it is UNIX

Re: Dynamic LINKLIST impact

If so, perhaps DELAY=255 should be the default. If not, why ever use it? That would never be done. This delays the completion of the command. It is not up to IBM to decide how long a customer can tolerate that. What is being deferred, in particular, is the closing of the old DCB and the

Re: Dynamic LINKLIST impact

The descriptions I find for the UPDATE DELAY=nn parameter are rather terse.  It only claims to delay "closing and unallocating LNKLST data sets that are no longer in use", which sounds like it shouldn't reduce the exposure unless the "no  longer in use" determination is inaccurate.  Does the

Re: Dynamic LINKLIST impact

Is it recommended to do a dynamic LINKLIST during a peak production hours ? Will there be any impact to the system during that time as we stop LLA as well. I agree with all the responses. The real answer depends on what the OP means by "do a dynamic LINKLIST". If it means only "define and

Re: Dynamic LINKLIST impact

It should be safe as long as you don't do UPDATE. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Peter Sent: Wednesday, July 17, 2019 4:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Dynamic

Re: Dynamic LINKLIST impact

On Wed, 17 Jul 2019 09:28:57 -0500, Elardus Engelbrecht wrote: >I was also lucky, but when we do a LNKLST UPDATE, we rather do it after hours >if we simply cannot do a IPL. If you simply cannot IPL, can you justify LNKLST UPDATE, knowing that it might cause you to have to IPL? I will admit

Re: Dynamic LINKLIST impact

Joel C. Ewing wrote: >Have things changed?   There has been considerable discussion on Dynamic >LNKLIST in the past on this list.   Yes, I remember those discussions. >Basically "ACTIVATE" was always safe, provided it is OK that newly started >address spaces use the new LNKLST and old

Re: Dynamic LINKLIST impact

On 7/17/19 4:08 AM, Elardus Engelbrecht wrote: > Peter wrote: > >> Is it recommended to do a dynamic LINKLIST during a peak production hours ? > Rather not, but this is not my dog. > > >> Will there be any impact to the system during that time as we stop LLA as >> well. > Why do you want to stop

Re: Dynamic LINKLIST impact

Peter wrote: >Is it recommended to do a dynamic LINKLIST during a peak production hours ? Rather not, but this is not my dog. >Will there be any impact to the system during that time as we stop LLA as well. Why do you want to stop it? What are you trying to solve? Why not rebuild a new

Re: The Linklist

>By system command as well as well... >SETPROG LNKLST,TEST,NAME=,MODNAME= Or the CSVDYNL REQUEST=TEST macro. I would guess that the ISR stuff only works against the current LNKLST set. Peter Relson z/OS Core Technology Design

Re: The Linklist

On Wed, 3 Feb 2016 09:08:35 -0500, Peter Relson wrote: >I would guess that the ISR stuff only works against the current LNKLST >set. By current, it's the set that was active when you logged on, not necessarily the currently active set. Side comment: PARMLIB and APF are

Re: The Linklist

TSO ISRDDN LOAD >>> LOADED FROM . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: The Linklist

I do DDLIST, then the LP command, this adds linklist and LPA to the display concatenations, then MEM command will search both. Dana On Tue, 2 Feb 2016 11:33:41 -0600, Doug Henry wrote: >On Tue, 2 Feb 2016 09:06:34 -0800, Ed Jaffe

Re: The Linklist

On 2/2/2016 9:33 AM, Doug Henry wrote: When I do a DDLIST like Ed suggests I just get " Current Data Set Allocations " with Actions: B E V M F C I Q". I tried this both on our z/OS V2R1 and z/OS V2R2 systems. That's exactly what you're supposed to get. Then you continue with the additional

Re: The Linklist

On Tue, 2 Feb 2016 11:33:41 -0600, Doug Henry wrote: >When I do a DDLIST like Ed suggests I just get " Current Data Set Allocations >" with Actions: B E V M F C I Q". >I tried this both on our z/OS V2R1 and z/OS V2R2 systems. Did you then enter the LNK or LP command? -- Tom Marchant

Re: The Linklist

Did I miss something or did someone already mention ISRFIND? Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Doug Henry Sent: Tuesday, February 02, 2016 12:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: The Linklist On Tue, 2

Re: The Linklist

Hello, I didn't think I'd be mentioning SDSFAUX twice in one day! I know other folks have mentioned other ways, but with the new SDSFAUX function SPE (and associated new panels) you can find any member on a listed concatenation (link, lpa, apf, parm), with the SRCH memname on the panel...

Re: The Linklist

Worked like a champion Thanks -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, February 1, 2016 7:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: The Linklist RSO ISRDDN and use LINKLIST on the COMMAND

Re: The Linklist

When you get closed WAD yes. Ed On Feb 1, 2016, at 11:10 PM, Paul Gilmartin wrote: On Mon, 1 Feb 2016 22:57:24 -0600, Ed Gould wrote: Sounds like a SHARE requirement to me. ??? Fixing a bug shouldn't be a SHARE requirement; it should be an SR. On Feb 1, 2016, at 10:24 PM, Paul

Re: The Linklist

rna WALLE > Sent: Tuesday, February 2, 2016 07:24 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [Bulk] Re: The Linklist > > Hello, > I didn't think I'd be mentioning SDSFAUX twice in one day! > > I know other folks have mentioned other ways, but with the new SDSFAUX > fun

Re: The Linklist

On Tue, 2 Feb 2016 09:06:34 -0800, Ed Jaffe wrote: I find both of your responses don't work on my system. Like Skip we have StarTool and I use findmod a lot. I also have have the free pds command installed on systems where StarTool is not licensed and there findmod

Re: The Linklist

9:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: The Linklist Sorry, TSO ISRDDN from any ISPF Panel. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lizette Koehler > Sent: Monday, February 01, 2016 8:11

Re: The Linklist

Never mind - MEM member-name -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex Sent: Tuesday, February 02, 2016 8:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: The Linklist On a related note, is there some way of talking

Re: The Linklist

RSO ISRDDN and use LINKLIST on the COMMAND LINE Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Steve Beaver > Sent: Monday, February 01, 2016 7:51 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: The Linklist > > Can

Re: The Linklist

TSO ISRFIND as well... On Feb 2, 2016 06:10, "Paul Gilmartin" < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 1 Feb 2016 22:57:24 -0600, Ed Gould wrote: > > >Sounds like a SHARE requirement to me. > > > ??? Fixing a bug shouldn't be a SHARE requirement; it should be an SR. > >

Re: The Linklist

By system command as well as well... SETPROG LNKLST,TEST,NAME=,MODNAME= Ant. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lucas Rosalen Sent: Tuesday, 2 February 2016 4:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: The Linklist

Re: The Linklist

On Mon, 1 Feb 2016 22:59:12 -0500, Paul Strauss <...@US.IBM.COM> wrote: > >I use ISRDDN daily. > But beware! ISRDDN can give incorrect results when a mixed concatenation of PDS(E) and UNIX directories is allocated. I reported this long ago and got WAD; they said it's just for "testing". Does

Re: The Linklist

Sounds like a SHARE requirement to me. Ed On Feb 1, 2016, at 10:24 PM, Paul Gilmartin wrote: On Mon, 1 Feb 2016 22:59:12 -0500, Paul Strauss <...@US.IBM.COM> wrote: I use ISRDDN daily. But beware! ISRDDN can give incorrect results when a mixed concatenation of PDS(E) and UNIX

Re: The Linklist

On Mon, 1 Feb 2016 22:57:24 -0600, Ed Gould wrote: >Sounds like a SHARE requirement to me. > ??? Fixing a bug shouldn't be a SHARE requirement; it should be an SR. >On Feb 1, 2016, at 10:24 PM, Paul Gilmartin wrote: > >> Does anyone in IBM care? -- gil

Re: The Linklist

Sorry, TSO ISRDDN from any ISPF Panel. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lizette Koehler > Sent: Monday, February 01, 2016 8:11 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: The Linkli

Re: RES: Linklist load during IPL message

. -Mensagem original- De: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Em nome de Jake anderson Enviada em: segunda-feira, 6 de outubro de 2014 12:56 Para: IBM-MAIN@LISTSERV.UA.EDU Assunto: Re: Linklist load during IPL message I did D PROG,LNKLST and ISRDDN and i see

Re: Old Linklist set use after new set activation

The OP's scenario is likely incomplete and/or in some way inaccurate. If you restart a task that has no bearing on anything. If you start a new address space, or start a new job in an initiator, that new work unit will be using the now-current LNKLST. Peter Relson z/OS Core Technology Design

Re: Old Linklist set use after new set activation.

After a lead from someone on the CICS-L listserv and doing some research, it appears the z/OS guy may have needed to, but did not do, an LLA REFRESH after doing the ACTIVATE commands. -- For IBM-MAIN subscribe / signoff /

Re: Old Linklist set use after new set activation.

On Wed, 24 Jul 2013 14:14:19 -0500, Howard Whitehead wrote: After a lead from someone on the CICS-L listserv and doing some research, it appears the z/OS guy may have needed to, but did not do, an LLA REFRESH after doing the ACTIVATE commands. No. LNKLST ACTIVATE updates LLA. I suspect