Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)
W dniu 2014-12-16 o 22:11, J O Skip Robinson pisze: My complaints focus on those HCs that don't really make sense any more. For example, in 1984 it would have been a cogent warning that the Product X master file and its backup/alternate are located behind the same DASD control unit. If you lost the control unit, you'd lose both copies. In 2014 with array technology, there is no longer a physical control unit. You have a big box with hundreds of logical volumes. If you lose the whole box, you're in a world of hurt so egregious that the demise of a master file is just noise. Yet I get constant warnings about a configuration oversight for which there is no feasible remedy. Sure I can turn the HC off, but shouldn't common sense (and a bit of extra coding) turn it off for me? introduction Well, I'm not going to invent some check which can be senseless for me but reasonable for you. Sometimes the check itself can check whether configuration is applicable, in some other cases it is up to administrator to decide. /introduction Now, Health Checker has its own configuration member in parmlib, you can easily (and dynamically of course) disable unneeded checks. Theoretical example: on system ABC I have one library with more1 extent on LNKLST. I'm aware of it, I cannot change it now, the planned outage will be in March, so I don't want to be warned about it verey 4 hours. Regards -- Radoslaw Skorupka Lodz, Poland --- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)
we've run into health checks that are not compatible with what we believe are reasonable settings Whenever any HC creator interacts with the HC team it is always suggested to them that they provide a parameter by which the customer can indicate the value to check for, because even though something might be recommended it might not meet the business needs of some customers, and those customers want a way to indicate check for the state I need, to help make sure that no one accidentally changes it even to the state that would normally be recommended. For those sort of cases, we really want customers to tune the check, not deactivate/delete it. For example, the GRS mode check can be tuned to check for STAR or RING. If the checks that you refer to do not have such parameterization, requesting it would be a great first step. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)
Try to avoid making HC sending so much informational/advisory/recommendational/etc. stuff, that nobody pays attention anymore. Can you be more specific? What stuff do you feel HC is advising/recommending that nobody pays attention to? Many clean up their systems specifically so that they are in accordance with the recommendations so that any new exception is unexpected and therefore warrants attention. Do you not agree with the recommendations that are in the books? Which ones? HC rarely advises/recommends on its own; typically it is helping you to get to the position recommended in the books. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)
Peter, we've run into health checks that are not compatible with what we believe are reasonable settings. Some we've turned off, others we didn't want to turn off, but had to add steps to some of our processes to deal with them (steps that we feel hinder rather than help). If you're interested in details, see PMRs 52015,082,000 (XCF_CF_STR_PREFLIST) and 91965 (USS_CLIENT_MOUNTS ) (the 2nd one is pretty old, not sure if it is still in the system, plus it was before they renumbered our branch, so it's likely ,800,000). Bart -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Tuesday, December 16, 2014 7:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC) Try to avoid making HC sending so much informational/advisory/recommendational/etc. stuff, that nobody pays attention anymore. Can you be more specific? What stuff do you feel HC is advising/recommending that nobody pays attention to? Many clean up their systems specifically so that they are in accordance with the recommendations so that any new exception is unexpected and therefore warrants attention. Do you not agree with the recommendations that are in the books? Which ones? HC rarely advises/recommends on its own; typically it is helping you to get to the position recommended in the books. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)
This issue can be looked at in two very different ways. A balance must certainly be struck, but I suspect that if some few indiividual HCs do not annoy some few users the wrong balance has in fact been struck. Turn off those that annoy you, but do so iff you are sure that you have understood the (inapplicable to your shop) rationale for them. My own experience strongly suggests that HC recommendations are too often ignored by the ignorant, that inattention to them is much more problematic than is time wasted on marginal ones. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)
My complaints focus on those HCs that don't really make sense any more. For example, in 1984 it would have been a cogent warning that the Product X master file and its backup/alternate are located behind the same DASD control unit. If you lost the control unit, you'd lose both copies. In 2014 with array technology, there is no longer a physical control unit. You have a big box with hundreds of logical volumes. If you lose the whole box, you're in a world of hurt so egregious that the demise of a master file is just noise. Yet I get constant warnings about a configuration oversight for which there is no feasible remedy. Sure I can turn the HC off, but shouldn't common sense (and a bit of extra coding) turn it off for me? . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Tuesday, December 16, 2014 6:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC) This issue can be looked at in two very different ways. A balance must certainly be struck, but I suspect that if some few indiividual HCs do not annoy some few users the wrong balance has in fact been struck. Turn off those that annoy you, but do so iff you are sure that you have understood the (inapplicable to your shop) rationale for them. My own experience strongly suggests that HC recommendations are too often ignored by the ignorant, that inattention to them is much more problematic than is time wasted on marginal ones. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)
I agree, there is nothing unhealthy about LNKLSTxx. Try to avoid making HC sending so much informational/advisory/recommandational/etc. stuff, that nobody pays attention anymore. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of J O Skip Robinson Sent: Friday, December 12, 2014 5:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC) A health check would be overkill not worth the blood, sweat, and tears. Just cite the need for PROGxx in the new function description. Good enough. Focus on higher value. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Thursday, December 11, 2014 7:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC) I still see sites using LNKLSTxx, but I don't see sites using IEAAPFxx anymore. As far as why, if it ain't broke, don't fix it. A statement from IBM that LNKLSTxx is deprecated could incentivize the switch. Can you write a health check to encourage conversion from LNKLSTxx to PROGxx? We're unlikely ever to get rid of LNKLSTxx fully (for the most part, the support is just there and does no harm and requires no updates). We could write a health check, but that would have to follow or accompany a recommendation, and might not be worth the effort. If you're not utilizing the dynamic capabilities, for most cases, there is no benefit to moving from LNKLSTxx to PROGxx (other then prettier syntax). The new function I'm looking into will be the first such case that comes to mind where it will be beneficial. So there will be an incentive for those wanting the new function. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)
A health check would be overkill not worth the blood, sweat, and tears. Just cite the need for PROGxx in the new function description. Good enough. Focus on higher value. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Thursday, December 11, 2014 7:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC) I still see sites using LNKLSTxx, but I don't see sites using IEAAPFxx anymore. As far as why, if it ain't broke, don't fix it. A statement from IBM that LNKLSTxx is deprecated could incentivize the switch. Can you write a health check to encourage conversion from LNKLSTxx to PROGxx? We're unlikely ever to get rid of LNKLSTxx fully (for the most part, the support is just there and does no harm and requires no updates). We could write a health check, but that would have to follow or accompany a recommendation, and might not be worth the effort. If you're not utilizing the dynamic capabilities, for most cases, there is no benefit to moving from LNKLSTxx to PROGxx (other then prettier syntax). The new function I'm looking into will be the first such case that comes to mind where it will be beneficial. So there will be an incentive for those wanting the new function. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)
On Dec 12, 2014, at 12:10 AM, Chase, John wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Ed Gould Sent: Thursday, December 11, 2014 11:42 PM On Dec 11, 2014, at 7:11 AM, Peter Relson wrote: Curiosity/Impact questions PROGxx has existed for almost 25 years, and support within there for dynamic LNKLST for almost 20 years. We're looking at some new work for which we likely won't change the LNKLSTxx path, thus requiring use of PROGxx for defining the LNKLST in order to use the new functionality. Peter: Yes we use the old linklst member(s) Trying to teach the new people about the new format is lets say less than fruitful. The old format is prefect as it is and IMO no changes to existing format would be welcome. I thought you retired a millennium ago. John: I still do consulting on the side(gratis) to non profits. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)
Curiosity/Impact questions PROGxx has existed for almost 25 years, and support within there for dynamic LNKLST for almost 20 years. We're looking at some new work for which we likely won't change the LNKLSTxx path, thus requiring use of PROGxx for defining the LNKLST in order to use the new functionality. So, -- are folks still using LNKLSTxx -- why? (this could include lack of need to change) -- if you are using it, do you have concerns with changing? -- are you aware of the CSVLNKPR exec (in samplib) that exists to create a PROGxx member from a LNKLSTxx member? The default for APF processing has never changed from static table (there's a dynamic format operation to make it dynamic, but it's best if that is identified during IPL to avoid wasting space). Are folks using a dynamically format APF list? (i.e., the APF FORMAT(DYNAMIC) statement in PROGxx, or SETPROG APF,FORMAT=DYNAMIC)? When we implemented dynamic APF, there were a few IBM and ISV products that needed to be enhanced to accommodate it, so we could not unconditionally change to dynamic format. I hope that all such problems have long ago been resolved, but we have still left control in the hands of the customer. Note that you can switch to dynamic after IPL, but it is a bit better to have identified during IPL that the format is dynamic if you have no problem areas remaining that require the static format. Thanks. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)
-- are (we) still using LNKLSTxx - No. Are (we) using a dynamically format APF list? - Yes. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: 11 December, 2014 14:12 To: IBM-MAIN@LISTSERV.UA.EDU Subject: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC) Curiosity/Impact questions PROGxx has existed for almost 25 years, and support within there for dynamic LNKLST for almost 20 years. We're looking at some new work for which we likely won't change the LNKLSTxx path, thus requiring use of PROGxx for defining the LNKLST in order to use the new functionality. So, -- are folks still using LNKLSTxx -- why? (this could include lack of need to change) -- if you are using it, do you have concerns with changing? -- are you aware of the CSVLNKPR exec (in samplib) that exists to create a PROGxx member from a LNKLSTxx member? The default for APF processing has never changed from static table (there's a dynamic format operation to make it dynamic, but it's best if that is identified during IPL to avoid wasting space). Are folks using a dynamically format APF list? (i.e., the APF FORMAT(DYNAMIC) statement in PROGxx, or SETPROG APF,FORMAT=DYNAMIC)? When we implemented dynamic APF, there were a few IBM and ISV products that needed to be enhanced to accommodate it, so we could not unconditionally change to dynamic format. I hope that all such problems have long ago been resolved, but we have still left control in the hands of the customer. Note that you can switch to dynamic after IPL, but it is a bit better to have identified during IPL that the format is dynamic if you have no problem areas remaining that require the static format. Thanks. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)
Peter Relson wrote: PROGxx has existed for almost 25 years, and support within there for dynamic LNKLST for almost 20 years. Too long. Haha ;-D We're looking at some new work for which we likely won't change the LNKLSTxx path, thus requiring use of PROGxx for defining the LNKLST in order to use the new functionality. So, -- are folks still using LNKLSTxx Not us. (After I have looked one last time in our IEASYSxx members. -- are you aware of the CSVLNKPR exec (in samplib) that exists to create a PROGxx member from a LNKLSTxx member? Yes, but never used that. The default for APF processing has never changed from static table (there's a dynamic format operation to make it dynamic, but it's best if that is identified during IPL to avoid wasting space). Are folks using a dynamically format APF list? (i.e., the APF FORMAT(DYNAMIC) statement in PROGxx, or SETPROG APF,FORMAT=DYNAMIC)? Yes. I'm also thinking of 'LNKLST ACTIVATE NAME(SYSNAME)' in PROGxx beside APF FORMAT(DYNAMIC). In fact we use in IEASYSxx this PROG=(A0,A1,L0,L1), keywords are as follow: Sysplex wide APF, LPAR unique APF, Sysplex wide LNK, LPAR unique LNK. So, just one nice PROG with all and everything nicely lined up. I hope that all such problems have long ago been resolved, but we have still left control in the hands of the customer. Do what you did for BPX.DEFAULT.USER, ISAM and COBOL statements. You just say you will support old feature x until z/OS future release while you have new feature z from z/OS past release. Make a official statement of direction that you will drop LNKLST=xx in a future release. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)
APF format Dynamic, LNKLSTxx - not in use (for at least 10 years) HTH, snip PROGxx has existed for almost 25 years, and support within there for dynamic LNKLST for almost 20 years. We're looking at some new work for which we likely won't change the LNKLSTxx path, thus requiring use of PROGxx for defining the LNKLST in order to use the new functionality. So, -- are folks still using LNKLSTxx -- why? (this could include lack of need to change) -- if you are using it, do you have concerns with changing? -- are you aware of the CSVLNKPR exec (in samplib) that exists to create a PROGxx member from a LNKLSTxx member? The default for APF processing has never changed from static table (there's a dynamic format operation to make it dynamic, but it's best if that is identified during IPL to avoid wasting space). Are folks using a dynamically format APF list? (i.e., the APF FORMAT(DYNAMIC) statement in PROGxx, or SETPROG APF,FORMAT=DYNAMIC)? When we implemented dynamic APF, there were a few IBM and ISV products that needed to be enhanced to accommodate it, so we could not unconditionally change to dynamic format. I hope that all such problems have long ago been resolved, but we have still left control in the hands of the customer. Note that you can switch to dynamic after IPL, but it is a bit better to have identified during IPL that the format is dynamic if you have no problem areas remaining that require the static format. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)
Peter, We don't use the LNKLSTxx any longer. We do use Dynamic APF list through the PROGxx member. Roy -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Thursday, December 11, 2014 8:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC) Curiosity/Impact questions PROGxx has existed for almost 25 years, and support within there for dynamic LNKLST for almost 20 years. We're looking at some new work for which we likely won't change the LNKLSTxx path, thus requiring use of PROGxx for defining the LNKLST in order to use the new functionality. So, -- are folks still using LNKLSTxx -- why? (this could include lack of need to change) -- if you are using it, do you have concerns with changing? -- are you aware of the CSVLNKPR exec (in samplib) that exists to create a PROGxx member from a LNKLSTxx member? The default for APF processing has never changed from static table (there's a dynamic format operation to make it dynamic, but it's best if that is identified during IPL to avoid wasting space). Are folks using a dynamically format APF list? (i.e., the APF FORMAT(DYNAMIC) statement in PROGxx, or SETPROG APF,FORMAT=DYNAMIC)? When we implemented dynamic APF, there were a few IBM and ISV products that needed to be enhanced to accommodate it, so we could not unconditionally change to dynamic format. I hope that all such problems have long ago been resolved, but we have still left control in the hands of the customer. Note that you can switch to dynamic after IPL, but it is a bit better to have identified during IPL that the format is dynamic if you have no problem areas remaining that require the static format. Thanks. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail, including attachments, is intended for the exclusive use of the addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any dissemination, use, distribution or copying is strictly prohibited. If you have received this e-mail in error, please notify me via return e-mail and permanently delete the original and destroy all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)
W dniu 2014-12-11 o 14:11, Peter Relson pisze: Curiosity/Impact questions [...] Do you really expect a reason except plain reluctance to change? -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2014 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.696.052 zote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)
are folks still using LNKLSTxx? Nope Dana -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)
On 12/11/2014 8:12 AM, Peter Relson wrote: Curiosity/Impact questions PROGxx has existed for almost 25 years, and support within there for dynamic LNKLST for almost 20 years. We're looking at some new work for which we likely won't change the LNKLSTxx path, thus requiring use of PROGxx for defining the LNKLST in order to use the new functionality. So, -- are folks still using LNKLSTxx -- why? (this could include lack of need to change) -- if you are using it, do you have concerns with changing? -- are you aware of the CSVLNKPR exec (in samplib) that exists to create a PROGxx member from a LNKLSTxx member? The default for APF processing has never changed from static table (there's a dynamic format operation to make it dynamic, but it's best if that is identified during IPL to avoid wasting space). Are folks using a dynamically format APF list? (i.e., the APF FORMAT(DYNAMIC) statement in PROGxx, or SETPROG APF,FORMAT=DYNAMIC)? When we implemented dynamic APF, there were a few IBM and ISV products that needed to be enhanced to accommodate it, so we could not unconditionally change to dynamic format. I hope that all such problems have long ago been resolved, but we have still left control in the hands of the customer. Note that you can switch to dynamic after IPL, but it is a bit better to have identified during IPL that the format is dynamic if you have no problem areas remaining that require the static format. Thanks. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Peter, I still see sites using LNKLSTxx, but I don't see sites using IEAAPFxx anymore. As far as why, if it ain't broke, don't fix it. A statement from IBM that LNKLSTxx is deprecated could incentivize the switch. Can you write a health check to encourage conversion from LNKLSTxx to PROGxx? Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)
I still see sites using LNKLSTxx, but I don't see sites using IEAAPFxx anymore. As far as why, if it ain't broke, don't fix it. A statement from IBM that LNKLSTxx is deprecated could incentivize the switch. Can you write a health check to encourage conversion from LNKLSTxx to PROGxx? We're unlikely ever to get rid of LNKLSTxx fully (for the most part, the support is just there and does no harm and requires no updates). We could write a health check, but that would have to follow or accompany a recommendation, and might not be worth the effort. If you're not utilizing the dynamic capabilities, for most cases, there is no benefit to moving from LNKLSTxx to PROGxx (other then prettier syntax). The new function I'm looking into will be the first such case that comes to mind where it will be beneficial. So there will be an incentive for those wanting the new function. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)
On Dec 11, 2014, at 7:11 AM, Peter Relson wrote: Curiosity/Impact questions PROGxx has existed for almost 25 years, and support within there for dynamic LNKLST for almost 20 years. We're looking at some new work for which we likely won't change the LNKLSTxx path, thus requiring use of PROGxx for defining the LNKLST in order to use the new functionality. Peter: Yes we use the old linklst member(s) Trying to teach the new people about the new format is lets say less than fruitful. The old format is prefect as it is and IMO no changes to existing format would be welcome. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
