Re: LPA Module Size 80MB impact on system?
No one has pointed out that it is impossible to place an 80mb module into PLPA / MLPA / FLPA. A PDS supports load modules of only 16MB, contrasted with a PDSE. You cannot get something from a PDSE into PLPA / MLPA / FLPA. You *can* get something from a PDSE into dynamic LPA. Therefore if you want it to be in LPA you must use dynamic LPA. Peter Relson z/OS Core Technology Design -- 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
Re: LPA Module Size 80MB impact on system?
On 23 Aug 2007 04:33:21 -0700, in bit.listserv.ibm-main you wrote: No one has pointed out that it is impossible to place an 80mb module into PLPA / MLPA / FLPA. A PDS supports load modules of only 16MB, contrasted with a PDSE. You cannot get something from a PDSE into PLPA / MLPA / FLPA. You *can* get something from a PDSE into dynamic LPA. This is one of my beefs with IBM design of new function. PDSE was meant to supplant PDS yet it isn't considered a basic data type processable at IPL. It is like not being able to use SNA local 327x devices for consoles because you needed VTAM up. It was a royal pain to have to have non-SNA controllers because of this deficient design. It goes right along with not doing FBA so we are locked into the arcane and space wasteful 3390 space management which is VSAM surly (On a 57K track you can only get 48K of VSAM clusters if the CI size is a multiple of 4K). Therefore if you want it to be in LPA you must use dynamic LPA. Peter Relson z/OS Core Technology Design -- 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
Re: LPA Module Size 80MB impact on system?
Oh, one more thing is that programs in the LPA are treated as APF-authorized, with all the caveats that entails. Isn't it treated as being loaded from APF authorized library? -- Peter Hunkeler Credti Suisse -- 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
Re: LPA Module Size 80MB impact on system?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Hunkeler Peter (KIUK 3) Oh, one more thing is that programs in the LPA are treated as APF-authorized, with all the caveats that entails. Isn't it treated as being loaded from APF authorized library? If that's the precise text from the manual, then I'd have to argue that it's grammatically incorrect: It should say having been where it says being. :-) Regardless, unless I misunderstand authorization, if an authorized caller were to invoke that module after it was loaded into the LPA, the module would be able to perform functions requiring authorization, even lacking AC(1). -jc- -- 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
Re: LPA Module Size 80MB impact on system?
On 8/22/07, Chase, John [EMAIL PROTECTED] wrote: Regardless, unless I misunderstand authorization, if an authorized caller were to invoke that module after it was loaded into the LPA, the module would be able to perform functions requiring authorization, even lacking AC(1). Interesting. From my little knowledge, there are (only?) two places where AC(1) matters: 1. EXEC PGM=XXX If the module is from a APF lib and with AC(1), JSCBAUTH will be set on which means the whole job step will run in APF-authorization status. 2. ATTACH RSAPF=YES The same logic is used to reset JSCBAUTH. Before doing this, JSCBAUTH needs to be set off if it's already on. And the caller must be in supervisor state or system key. As for the above example, since the module is in LPA which means it'll be treated as having been loaded from an APF lib, it can be invoked by an APF-authorized job step. Unless it's invoked via ATTACH RSAPF=YES, AC code doesn't matter. However, is the module in LPA also treated as having AC(1)? I'm not sure. And it makes me think of another question: After a module is loaded into JPA, is the information of this copy (whether it's from an APF lib and its AC code) stored in some system control blocks? My guess is yes. If the module is RENT, the same copy will be reused. So the info must be stored somewhere. -- Best Regards, Johnny Luo -- 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
Re: LPA Module Size 80MB impact on system?
On Tue, 21 Aug 2007 08:36:07 -0500, Mark S. House [EMAIL PROTECTED] wrote: Looking for recommendations on adding an 80 megabyte load module to the LPA. What are the negatives. The reason we would like to do this is that one of our application programs that use this module can be used by 1 to 10 jobs running at the same time. Our thought is that by making this module resident, we would only have one copy of the load module in core for up to 10 jobs. Any thoughts would be appreciated. Thanks. Greetings, What problem are you trying to solve? When many of these jobs are running, do you run low on real or virtual storage? Does paging become unacceptable? Is this affecting SLAs? z/OS was built to handle this type of thing. The main issue that I see is the initial load of each 80MB module into user storage; once that is done, the system will trim the working set and you will basically only have in real storage what pages you have recently accessed. Is this vendor supplied code? If so, what are their recommendations? If you end up putting it in common storage, there are audit concerns and change control issues. Cheers... Michael -- 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
Re: LPA Module Size 80MB impact on system?
John, This has been discussed before, but AC(1) on a load module is ONLY checked when the program in question is attached by the initiator as a job step task. In that case, if AC(1), and loaded from an APF authorized library (which requires that ALL libraries concatenated to the STEPLIB DD be in the APF list), then the JSCBAUTH bit will be set. The reason that modules in LPA are considered to have been loaded from an APF authorized library is because if the JSCBAUTH bit is set for a job step, all program fetches MUST come from an APF authorized library, or the request will be abended with a SYSTEM 306 code. If the LPA wasn't considered loaded from an APF authorized library, then no authorized job step could execute code in the LPA. Any program that is not explicitly designed to be executed as a jobstep program should NOT be linked with AC(1), as there is the chance of an integrity exposure. Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chase, John Sent: Wednesday, August 22, 2007 7:24 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: LPA Module Size 80MB impact on system? snip Regardless, unless I misunderstand authorization, if an authorized caller were to invoke that module after it was loaded into the LPA, the module would be able to perform functions requiring authorization, even lacking AC(1). -jc- -- 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
Re: LPA Module Size 80MB impact on system?
Johnny, Your knowledge is pretty much correct. In answer to your question about attributes of a module after it is loaded into storage, they are maintained in the LPDE (Link Pack Directory Entry) for the module. However, even though the LPDE contains a RENT indicator (as it is basically a specialized CDE), if the module is in the LPA, only one copy, loaded into KEY 0 storage, will be used, so if the program must be reentrant, or problems could (or will) occur. Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Johnny Luo Sent: Wednesday, August 22, 2007 8:16 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: LPA Module Size 80MB impact on system? Interesting. From my little knowledge, there are (only?) two places where AC(1) matters: 1. EXEC PGM=XXX If the module is from a APF lib and with AC(1), JSCBAUTH will be set on which means the whole job step will run in APF-authorization status. 2. ATTACH RSAPF=YES The same logic is used to reset JSCBAUTH. Before doing this, JSCBAUTH needs to be set off if it's already on. And the caller must be in supervisor state or system key. As for the above example, since the module is in LPA which means it'll be treated as having been loaded from an APF lib, it can be invoked by an APF-authorized job step. Unless it's invoked via ATTACH RSAPF=YES, AC code doesn't matter. However, is the module in LPA also treated as having AC(1)? I'm not sure. And it makes me think of another question: After a module is loaded into JPA, is the information of this copy (whether it's from an APF lib and its AC code) stored in some system control blocks? My guess is yes. If the module is RENT, the same copy will be reused. So the info must be stored somewhere. -- Best Regards, Johnny Luo -- 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
Re: LPA Module Size 80MB impact on system?
Thanks for the answer, Wayne. I remember that if a module comes from an APF lib and with RENT attribute, it'll be loaded into SP 252 of JPA. Since SP 252 is key 0, a modification to itself may fail unless you're in key 0. However, as far as LPA is concerned, is it protected using another mechanism? So even you're running in key 0, you still cannot modify LPA. So the module in LPA should be also refreshable. On 8/22/07, Wayne Driscoll [EMAIL PROTECTED] wrote: Johnny, Your knowledge is pretty much correct. In answer to your question about attributes of a module after it is loaded into storage, they are maintained in the LPDE (Link Pack Directory Entry) for the module. However, even though the LPDE contains a RENT indicator (as it is basically a specialized CDE), if the module is in the LPA, only one copy, loaded into KEY 0 storage, will be used, so if the program must be reentrant, or problems could (or will) occur. Wayne Driscoll -- 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
Re: LPA Module Size 80MB impact on system?
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Johnny Luo Sent: Wednesday, August 22, 2007 9:27 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: LPA Module Size 80MB impact on system? Thanks for the answer, Wayne. I remember that if a module comes from an APF lib and with RENT attribute, it'll be loaded into SP 252 of JPA. Since SP 252 is key 0, a modification to itself may fail unless you're in key 0. However, as far as LPA is concerned, is it protected using another mechanism? So even you're running in key 0, you still cannot modify LPA. So the module in LPA should be also refreshable. SNIP As best as my memory is working this morning, going back to hardware days: The protection for LPA is that it is written once (LPA PAGE DS) and then fetched as needed. So, if a page gets corrupted, which in this case would show that the page frame has been written to, the page is flushed and re-read from the LPA page data set. This also allows the system to recover from a memory parity error (where the page frame gets marked as unusable). This last being a trick that I wonder if the M/S systems have learned yet (oh, they don't have ECC dual parity memory)? Later, Steve Thompson Opinions expressed are those of the poster and not necessarily those of poster's employer. -- This e-mail message is intended only for the addressee(s) and contains information that may be confidential and/or privileged material. If you are not the intended recipient please notify the sender by reply e-mail immediately. Use, disclosure or reproduction of any information in this e-mail by anyone other than the intended recipient(s) is strictly prohibited. Sterling Commerce is not liable for any loss or damage arising in any way from transmission of the message or use of its attachments. This email may contain links to third party web sites. Sterling Commerce is not responsible for the content or privacy policies of such other sites and the existence of a link in this email does not imply an endorsement of the linked web site or the goods or services offered therein. -- 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
Re: LPA Module Size 80MB impact on system?
Steve, Thanks. As for M/S, I'm sure they haven't because two days ago I got a blue screen on my Thinkpad T60 running Windows XP and the message said a memory parity error occurred :) On 8/22/07, Thompson, Steve [EMAIL PROTECTED] wrote: This last being a trick that I wonder if the M/S systems have learned yet (oh, they don't have ECC dual parity memory)? Later, Steve Thompson -- Best Regards, Johnny Luo -- 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
Re: LPA Module Size 80MB impact on system?
On Wed, 22 Aug 2007 08:56:12 -0500, Michael Cleary wrote: z/OS was built to handle this type of thing. The main issue that I see is the initial load of each 80MB module into user storage; once that is done, the system will trim the working set and you will basically only have in real storage what pages you have recently accessed. It transpired in these pages a while ago that nowadays even the initial load is deferred until the pages are actually accessed. But if multiple address spaces have overlapping working sets there is a saving if those pages can be shared. -- gil -- 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
Re: LPA Module Size 80MB impact on system?
Isn't it treated as being loaded from APF authorized library? If that's the precise text from the manual, then I'd have to argue that it's grammatically incorrect: It should say having been where it says being. :-) It's not from a manual, it's from me, with all the mistakes in spelling (well I think there are none in this case) and grammar :-) Here is the text from one manual: In addition, any module in the link pack area will be treated by the system as though it came from an APF-authorized library. Regardless, unless I misunderstand authorization, if an authorized caller were to invoke that module after it was loaded into the LPA, the module would be able to perform functions requiring authorization, even lacking AC(1). How did the authorized caller become authorized? Because the program has been link edited with AC(1), is running as job step program and was loaded from an APF authorized library, right? It can then only load/link... modules which also come (or came) from an APF authorized library. The AC() of these modules is not of interest. Since the subprogram runs under the same TCB, it is running APF authorized, too. But the same subprogram cannot do anything for which authorization is needed in the same constellation if the job step program was not running authorized. Calling a program from LPA as job step program does not automatically run it authorized, only if it also has the AC(1). My understanding. Not sure this matches 100% what you wrote. -- Peter Hunkeler Credit Suisse -- 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
Re: LPA Module Size 80MB impact on system?
In a message dated 8/22/2007 9:27:33 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: However, as far as LPA is concerned, is it protected using another mechanism? So even you're running in key 0, you still cannot modify LPA. LPA modules are stored in page-protected storage. This means that when running in key 0 you still cannot normally alter the page(s) in which your program resides. There are, of course, ways around this limitation, but you have to go out of your way to do it. Bill Fairchild Plainfield, IL ** Get a sneak peek of the all-new AOL at http://discover.aol.com/memed/aolcom30tour -- 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
Re: LPA Module Size 80MB impact on system?
---snip- Really? Who do you think used overlays? It was SOP for application programmers where I came from when running in MVT. Debugging isn't particularly an issue. Of course, the Linkage Editor can't resolve an external reference to a module that is in a different leg. -unsnip Leave us not forget that the OS/360 FORTRAN-H compiler was overlaid into 5 regions! SMP and IEBCOPY were overlays until MVS/XA hit the street! -- 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
Re: LPA Module Size 80MB impact on system?
Really? Who do you think used overlays? It was SOP for application programmers where I came from when running in MVT. To quote the Monkees: That was then; this is now. - Too busy driving to stop for gas! -- 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
Re: LPA Module Size 80MB impact on system?
In a message dated 8/22/2007 5:03:07 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: 5 regions! SMP and IEBCOPY were overlays until MVS/XA hit the street! Right. Many Blue utilities used OVERLAY to keep them 'artificially small'. LKED, IDCAMS, and numerous others required adjustments to exits and initiator parms. I remember a SHARE presentations but don't remember the author. ** Get a sneak peek of the all-new AOL at http://discover.aol.com/memed/aolcom30tour -- 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
Re: LPA Module Size 80MB impact on system?
On Tue, 21 Aug 2007 08:36:07 -0500, Mark S. House wrote: Looking for recommendations on adding an 80 megabyte load module to the LPA. What are the negatives. The reason we would like to do this is that one of our application programs that use this module can be used by 1 to 10 jobs running at the same time. Our thought is that by making this module resident, we would only have one copy of the load module in core for up to 10 jobs. Any thoughts would be appreciated. Thanks. Hmmm. That would use 4% of below-the-bar CSA. Just 25 such and you run out. Are any shops impacting this constraint nowadays? Is there hope for above-the-bar LPA someday? -- gil -- 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
Re: LPA Module Size 80MB impact on system?
Two questions/comments: 1. Is the module AMODE 31 RMODE 31? If not, you are taking a sugnificant chunk of below the line storage. Is it worth it? If it is AMODE/RMODE 31, then you should be OK. 2. Is the module truly reentrant? If not, then it doesn't belong in LPA. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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
Re: LPA Module Size 80MB impact on system?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark S. House Looking for recommendations on adding an 80 megabyte load module to the LPA. What are the negatives. The reason we would like to do this is that one of our application programs that use this module can be used by 1 to 10 jobs running at the same time. Our thought is that by making this module resident, we would only have one copy of the load module in core for up to 10 jobs. Any thoughts would be appreciated. Thanks. Only downside I can think of is the loss of 80MB private area above the line for all address spaces. -jc- -- 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
Re: LPA Module Size 80MB impact on system?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark S. House Looking for recommendations on adding an 80 megabyte load module to the LPA. What are the negatives. The reason we would like to do this is that one of our application programs that use this module can be used by 1 to 10 jobs running at the same time. Our thought is that by making this module resident, we would only have one copy of the load module in core for up to 10 jobs. Any thoughts would be appreciated. Thanks. Only downside I can think of is the loss of 80MB private area above the line for all address spaces. Oh, one more thing is that programs in the LPA are treated as APF-authorized, with all the caveats that entails. -jc- -- 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
Re: LPA Module Size 80MB impact on system?
On Tue, 21 Aug 2007 08:36:07 -0500, Mark S. House [EMAIL PROTECTED] wrote: Looking for recommendations on adding an 80 megabyte load module to the LPA. What are the negatives. The reason we would like to do this is that one of our application programs that use this module can be used by 1 to 10 jobs running at the same time. Our thought is that by making this module resident, we would only have one copy of the load module in core for up to 10 jobs. Any thoughts would be appreciated. Thanks. I assume the module is reentrant. ( and 31 bit! :-) ) The only negative I can see is your loss of 80M of EPVT. Considering most shops have between 1600M-1800M, I don't see that as being a problem. But I have seen some large requirements for EPVT so only you can answer that question for your shop (ISTR 1600M needed to start an SAP instance on z/OS for an SAP upgrade and some large requirements for WebSphere). Sounds like a good idea to me. Especially if you are storage constrained at all. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: LPA Module Size 80MB impact on system?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Veilleux, Jon L Two questions/comments: 1. Is the module AMODE 31 RMODE 31? If not, you are taking a sugnificant chunk of below the line storage. Yeah, like 500% of what exists down there. :-) If it is AMODE/RMODE 31, then you should be OK. 2. Is the module truly reentrant? If not, then it doesn't belong in LPA. A point I missed earlier -jc- -- 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
Re: LPA Module Size 80MB impact on system?
John Chase said: Yeah, like 500% of what exists down there. :-) Right...DUH. I slept through that one Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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
Re: LPA Module Size 80MB impact on system?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Veilleux, Jon L John Chase said: Yeah, like 500% of what exists down there. :-) Right...DUH. I slept through that one Well, in retrospect, I suppose it could use overlays. -jc- -- 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
Re: LPA Module Size 80MB impact on system?
John Chase said: Well, in retrospect, I suppose it could use overlays. OH GOD! I hope not! I don't think that there are many application programmers that have even heard of overlay programs, let alone code one and the corresponding binder statements, correctly. Not to mention trying to debug one! Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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
Re: LPA Module Size 80MB impact on system?
Veilleux, Jon L wrote: John Chase said: Yeah, like 500% of what exists down there. :-) Right...DUH. I slept through that one Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 I was typing the same information into a response but realized the error of my ways before I sent it. :-) --- Pound pastrami, can kraut, six bagels -- bring home for Emma. Isaac Edward Leibowitz (Saint Leibowitz) A Canticle for Leibowitz -- 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
Re: LPA Module Size 80MB impact on system?
On Tue, 21 Aug 2007 08:36:07 -0500, Mark S. House wrote: Looking for recommendations on adding an 80 megabyte load module to the LPA. What are the negatives. The reason we would like to do this is that one of our application programs that use this module can be used by 1 to 10 jobs running at the same time. Our thought is that by making this module resident, we would only have one copy of the load module in core for up to 10 jobs. Any thoughts would be appreciated. Thanks. Another consideration might be how often the module needs to change. If it needs to be updated often it might be a hassle for you. Also, each time you update it, you take another chunk of ECSA. You'll need procedures to delete the old copy when it is inactive. IIRC, you can't delete the copy that is in PLPA. -- Tom Marchant -- 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
Re: LPA Module Size 80MB impact on system?
Tom Marchant said: Another consideration might be how often the module needs to change. If it needs to be updated often it might be a hassle for you. Also, each time you update it, you take another chunk of ECSA. You'll need procedures to delete the old copy when it is inactive. IIRC, you can't delete the copy that is in PLPA. If you are using Dynamic LPA you can delete and reload the module fairly easily (depending on your change control procedures). If you are using PLPA you are stuck without an IPL. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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
Re: LPA Module Size 80MB impact on system?
On Tue, 21 Aug 2007 10:52:52 -0400, Veilleux, Jon L wrote: John Chase said: Well, in retrospect, I suppose it could use overlays. Not in LPA. OH GOD! I hope not! I don't think that there are many application programmers that have even heard of overlay programs, let alone code one and the corresponding binder statements, correctly. Not to mention trying to debug one! Really? Who do you think used overlays? It was SOP for application programmers where I came from when running in MVT. Debugging isn't particularly an issue. Of course, the Linkage Editor can't resolve an external reference to a module that is in a different leg. -- Tom Marchant -- 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
Re: LPA Module Size 80MB impact on system?
On Tue, 21 Aug 2007 11:05:13 -0400, Veilleux, Jon L wrote: If you are using Dynamic LPA you can delete and reload the module fairly easily You can delete the module only when you know that no one is using it. If you are using PLPA you are stuck without an IPL. You can't delete the PLPA copy, but you can still put an updated copy in dynamic LPA. It will be used for new requests. -- Tom Marchant -- 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
Re: LPA Module Size 80MB impact on system?
Amen to that Jon. The last time I played with an overlay was when I had a large module to run in VS1. It was not a pretty picture but you did learn the Linkage editor. Bill From: Veilleux, Jon L [EMAIL PROTECTED] Reply-To: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To: IBM-MAIN@BAMA.UA.EDU Subject: Re: LPA Module Size 80MB impact on system? Date: Tue, 21 Aug 2007 10:52:52 -0400 John Chase said: Well, in retrospect, I suppose it could use overlays. OH GOD! I hope not! I don't think that there are many application programmers that have even heard of overlay programs, let alone code one and the corresponding binder statements, correctly. Not to mention trying to debug one! Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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 _ Tease your brain--play Clink! Win cool prizes! http://club.live.com/clink.aspx?icid=clink_hotmailtextlink2 -- 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
Re: LPA Module Size 80MB impact on system?
Tom Marchant said: Really? Who do you think used overlays? It was SOP for application programmers where I came from when running in MVT. Debugging isn't particularly an issue. Of course, the Linkage Editor can't resolve an external reference to a module that is in a different leg. Tom, you're talking about folks who were familiar with writing programs when virtual storage was very limited. MVT has been gone for a long time. I know there are probably a few silver backs who could still structure and write an overlay program, but I would be willing to bet that the majority of today's application folks never even heard of overlay although it would be a good history lesson for an assembler class. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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
Re: LPA Module Size 80MB impact on system?
On Tue, 21 Aug 2007 12:48:10 -0400, Veilleux, Jon L wrote: Tom, you're talking about folks who were familiar with writing programs when virtual storage was very limited. MVT has been gone for a long time. Agreed. There is little, if any, need for overlay structures these days. I was taking exception to your statement that application programmers wouldn't be able to design one. I know there are probably a few silver backs who could still structure and write an overlay program, but I would be willing to bet that the majority of today's application folks never even heard of overlay Again I agree. Likewise system folks. although it would be a good history lesson for an assembler class. Assembler? Not really. Most of the overlay structures that we built were primarily COBOL, with the occasional Assembler subroutine. There's no need for assembler in an overlay structure. -- Tom Marchant -- 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
Re: LPA Module Size 80MB impact on system?
On Aug 21, 2007, at 9:52 AM, Veilleux, Jon L wrote: John Chase said: Well, in retrospect, I suppose it could use overlays. OH GOD! I hope not! I don't think that there are many application programmers that have even heard of overlay programs, let alone code one and the corresponding binder statements, correctly. Not to mention trying to debug one! My memory is iffy on this but IIRC overlays in LPA are verbotten. Ed -- 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
