***Cross-posted on IBM-MAIN and ASSEMBLER lists ***
From a recent post on IBM-MAIN from Bruce Black [bbl...@FDRINNOVATION.COM]:
>Whenever a 256 byte area currently in I-cache is modified, >it is transfered to D-cache. But if instructions in that >area are executed, it must be flushed from the D-cache to >L2 cache, and re-fetched into I-cache, which causes a >serious execution penalty. If they repeated on the same >location, it has to go back to D-cache and all over again.
Assuming this is at least fairly accurate...
Previous IBM CPU's didn't have such a penalty for code that resides in close proximity to the data it modifies. Any CPU architecture change is bound to favor different programming techniques -- but wasn't this seen (by IBM architects) as a potential MAJOR performance change? Small routines that otherwise have NO reason to keep data areas separate from code, or programs that dynamically build/modify code will perform WORSE on z/900 than on previous hardware. A likely place for such code is in the heart of parameter-driven number crunching.
This kinda gets back to the old "where's the instruction timings" whine we occasionally engage in, because those timings were accompanied by an overview of factors that affect timing.
The z/Architecture Principles of Operation does not mention any details of what disrupts the cache, and thus reduces CPU performance. Such model-dependent trivia isn't in PoOPs... but how is a coder to learn of things like this? I'll gladly RTFM if one exists.
-jcf
__________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
IBM has been telling people not to mix code and data since the 360 days, due to pipeline invalidation causing performance loss.
As to publishing instruction timings, yeah, I'd like to see them do that. But don't be surprised if the timing manual for one model is thicker than the new PoOps; it's been a long time since such things were simple. Even the old 370 line had all sorts of special cases in the timing information.
> -----Original Message----- > From: John Ford [SMTP:z...@YAHOO.COM] > Sent: Tuesday, February 13, 2001 3:04 PM
> Previous IBM CPU's didn't have such a penalty for code that > resides in close proximity to the data it modifies. Any CPU > architecture change is bound to favor different programming > techniques -- but wasn't this seen (by IBM architects) as a > potential MAJOR performance change? Small routines that > otherwise have NO reason to keep data areas separate from > code, or programs that dynamically build/modify code will > perform WORSE on z/900 than on previous hardware. A likely > place for such code is in the heart of parameter-driven > number crunching.
> This kinda gets back to the old "where's the instruction > timings" whine we occasionally engage in, because those > timings were accompanied by an overview of factors that > affect timing.
> The z/Architecture Principles of Operation does not mention > any details of what disrupts the cache, and thus reduces > CPU performance. Such model-dependent trivia isn't in > PoOPs... but how is a coder to learn of things like this? > I'll gladly RTFM if one exists.
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
----------------<snip>------------------ As to publishing instruction timings, yeah, I'd like to see them do that. But don't be surprised if the timing manual for one model is thicker than the new PoOps; it's been a long time since such things were simple. Even the old 370 line had all sorts of special cases in the timing information. ---------------<unsnip>------------------- So did the S/360; even the formulas for length-dependant instructions were different between the different models. :-)
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
I'm talking about complexity within a single model. The timing formulae for the S/360 models were generally simpler than those for S/370 models, although the 85, 91, 95 and 195 were probably just as bad.
Shmuel (Seymour J.) Metz
> -----Original Message----- > From: Rick Fochtman [SMTP:Rick.Focht...@BOTCC.COM] > Sent: Tuesday, February 13, 2001 3:40 PM
> So did the S/360; even the formulas for length-dependant instructions were > different between the different models. :-)
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
The Devil is in the details. The paging on the PDP-11 was not very sophisticated. I don't think that copy-on-read was an option until Unix was running on Motorola 680x0 and Vaxen processors.
I've played the game of using R13 as a combined base and save area pointer also, but not in the last few decades.
IBM was telling us to keep code and data separate in the early 70's; I consider that adequate notice, especially for software vendors.
> Some models of PDP11 have a memory management system so that they > can address more than 64k (bytes). Some OS used this, possibly > including putting instructions and data in different places.
> Most non-reentrant assembly and even fortran S/3x0 programs that > I knew had static data areas in the program CSECT. This includes > save areas. I think it was mentioned not so long ago in this > group, the trick of putting the save area near the top of the CSECT > so that R13 can be used for the base register.
> Back at least to PL/I (F) static data had its own CSECT, > and most data areas, including save areas, were dynamically allocated.
> I don't know LE at all, but I suspect it does even more with its > memory allocation.
> I believe that it is more modern programming techniques that > tend to keep code and data apart, more than just unix.
> It does seem that more notice of this might have been nice. Still, > I don't expect too many people to run Fortran G on their z/ machine.
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> IBM has been telling people not to mix code and data > since the 360 days, due > to pipeline invalidation causing performance loss.
Not directed at you (Seymour) in particular, but where/how does one hear these things from IBM? I remember reading in some Performance Guide(s) about separating code and data back when paging was a major concern, but I've not seen (that I remember!) a manual that discusses CPU performance at the level of detail of instruction pipelines. I'm not saying they don't exist... I'd just like to know what/where they are.
-jcf
__________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
The magic word is "Functional Specifications". But I haven't seen anything since the 3168 that had timing information.
Shmuel (Seymour J.) Metz
> -----Original Message----- > From: John Ford [SMTP:z...@YAHOO.COM] > Sent: Tuesday, February 13, 2001 5:19 PM
> Not directed at you (Seymour) in particular, but where/how > does one hear these things from IBM? I remember reading in > some Performance Guide(s) about separating code and data > back when paging was a major concern, but I've not seen > (that I remember!) a manual that discusses CPU performance > at the level of detail of instruction pipelines. I'm not > saying they don't exist... I'd just like to know what/where > they are.
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Previous IBM CPU's didn't have such a penalty for code that > resides in close proximity to the data it modifies.
<snip>
This is FUD as far as I am concerned. I suggest you have facts before making a broad statement like this.
Different processors in the past have frequently had penalties for having code and data in close proximity. The cost/impact for doing so varies on the general processor design, and is required to for conformance to the complex rules imposed on the architecture for store into stream imposed by the 360 architecture.
I've seen programs that ran slower than expected on a G5/G6 due store into stream and the fact that the cache size changed. I've seen similar issues on the 9021 when it's instruction pipeline was disrupted.
These effects are not limited to IBM designed processors. This is one of the reasons that makes MIPS meaningless. Greg
Greg Dyck z/OS Core Technology Design
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
You are right that there is a lot of FUD in this, however I think that a lot of this could be taken away if IBM was to publish the types of issues that are heavily related to the performance of the processor. Especially now that S/390 (or z/Arch) has entered the open world of Linux, where it is not just a selected few (that have access to this type of material anyway) who write compilers etc. I believe that this information was available in the distant past, and there is no obvious reason why it shouldn't again.
On Tue, 13 Feb 2001 20:12:07 -0500, Greg Dyck <g...@US.IBM.COM> wrote: >> Previous IBM CPU's didn't have such a penalty for code that >> resides in close proximity to the data it modifies. ><snip>
>This is FUD as far as I am concerned. I suggest you have facts before >making a broad statement like this.
>Different processors in the past have frequently had penalties for >having code and data in close proximity. The cost/impact for doing so >varies on the general processor design, and is required to for >conformance to the complex rules imposed on the architecture for store >into stream imposed by the 360 architecture.
>I've seen programs that ran slower than expected on a G5/G6 due store >into stream and the fact that the cache size changed. I've seen similar >issues on the 9021 when it's instruction pipeline was disrupted.
>These effects are not limited to IBM designed processors. This is one >of the reasons that makes MIPS meaningless. >Greg
>Greg Dyck >z/OS Core Technology Design
>---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>These effects are not limited to IBM designed processors. This is one >of the reasons that makes MIPS meaningless. >Greg
Greg,
You had some good points in your reply.
Just to bring everybody up to speed .. could you continue on with this "thread" and list out some more reasons why MIPS is misleading.
Thanks,
Ed
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> > Previous IBM CPU's didn't have such a penalty for code > that resides in close proximity to the data it modifies. > <snip>
> This is FUD as far as I am concerned. I suggest you have > facts before making a broad statement like this.
My apologies for any FUD. When I wrote "...such a penalty...", perhaps I should have said "...as much of a penalty...". But you're right, I may have jumped too far in my conclusions that I based on a couple posts here and on "Cheryl's List #50" at http://www.watsonwalker.com/clist50.html.
I don't have a G6 and a z900 at my disposal to run my own benchmarks, so I don't have facts. [Even if I DID, how would I know WHAT my code was doing wrong?] The few Functional Characteristics manuals I've read in recent years don't say much about things that disrupt instruction cache/pipeline operation, so I rely on "word of mouth" [via Internet in this case] to learn such things.
I return to my orginal question: Such model-dependent trivia isn't in PoOPs [or Functional Characteristics]... but how is a coder to learn of things like this?
I ask this with an honest desire to know the answer, not to riducule or otherwise abuse IBM. And certainly not to spread FUD.
-jcf
__________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
The bad news on this one is that there is ZERO external information available on this subject. IBM may have such information internally (probably does) but its not externalized. There are all kinds of reasons why IBM would choose not to publish that information, not least of which is that it would be obsolete the minute the (electronic) ink was dry on it.
In any case, I'm not aware of any other vendor that publishes detailed instruction timings and cache behavior models. I think IBM is right to keep timings internal. OTOH I think it wouldn't hurt them to make available some basic machine architecture information... (thinking) but wait, they do. If you subscribe to the IBM Journal of Research and Development, they publish a wonderful (dense) description of every new machine family (including mainframes) at about the time the new machines show up. You can usually get a subscription through your IBM branch office.
If you don't have access to the JoR&D, your options are really limited. Sooooooooo..... where does one "go" to learn about the implications (old hat in the risc world btw) of split I and D caches? Most people who know anything about this subject either (a) currently work in the field, or a closely related one, or (b) they learn about it in college.
People who fall in category (a) would be H/W designers primarily and folks (like Greg et. al.) directly involved in the OS design, which is necessarily closely related to the H/W. People who fall in category (b) might actually become people in category (a) when they grow up, but most don't. I am fortunate enough to have spent a portion of my life in category (a) (my mis-spent youth).
If you really want to get a good primer on this sort of thing without suffering through college hours again, I strongly recommend you cruise on over to AMAZON and order yourself a copy of "Computer Architecture, A Quantitative Approach" by John Hennessy and David Patterson. It's not cheap, but it IS the bible for H/W weenies.
One thing you can be sure of... while IBM terminology may vary from other vendors, IBM cpus obey the same physics as every other cpu implemented in similar technology, e.g. if you compare CMOS with CMOS and avoid comparing CMOS with ECL. Their IBM examples are very dated, but the rest of the book is wonderful. It will give you a solid feel for why H/W designers make otherise mysterious design choices like separating the I-stream and the D-stream.
After you've spent a few cozy beverage-hours with Hennessy & Patterson, you should be able to read the IBM Journal articles again (or for the first time) and they will make a whole lot more sense.
Chris
>-----Original Message----- >From: John Ford [mailto:z...@YAHOO.COM] >I return to my orginal question: >Such model-dependent trivia isn't in PoOPs [or Functional >Characteristics]... but how is a coder to learn of things >like this?
>I ask this with an honest desire to know the answer, not to >riducule or otherwise abuse IBM. And certainly not to >spread FUD.
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> -----Original Message----- > From: Craddock, Chris [SMTP:Chris_Cradd...@BMC.COM] > Sent: Wednesday, February 14, 2001 9:59 AM > To: IBM-M...@BAMA.UA.EDU > Subject: Re: z/Architecture I-cache
<snip> > basic machine architecture information... (thinking) but wait, they do. If > you subscribe to the IBM Journal of Research and Development, they publish > a > wonderful (dense) description of every new machine family (including > mainframes) at about the time the new machines show up. You can usually > get > a subscription through your IBM branch office.
<snip>
> Chris
The "IBM Journal of Research and Development" as well as "IBM Systems Journal" appear to be available on the web at: http://www.research.ibm.com/journal/. I don't know if these are the current hardcopy or if this site is delayed.
---------------------------------------------------------------------- John McKown HealthAxis
All opinions are my own and are not the opinions of my employer.
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
<JMck...@HEALTHAXIS.COM> writes: >> -----Original Message----- >> From: Craddock, Chris [SMTP:Chris_Cradd...@BMC.COM] >> Sent: Wednesday, February 14, 2001 9:59 AM >> To: IBM-M...@BAMA.UA.EDU >> Subject: Re: z/Architecture I-cache
> <snip> >> basic machine architecture information... (thinking) but wait, they do. If >> you subscribe to the IBM Journal of Research and Development, they publish >> a >> wonderful (dense) description of every new machine family (including >> mainframes) at about the time the new machines show up. You can usually >> get >> a subscription through your IBM branch office.
> <snip>
>> Chris
>The "IBM Journal of Research and Development" as well as "IBM Systems >Journal" appear to be available on the web at: >http://www.research.ibm.com/journal/. I don't know if these are the current >hardcopy or if this site is delayed.
----- Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web ----- http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups NewsOne.Net prohibits users from posting spam. If this or other posts made through NewsOne.Net violate posting guidelines, email ab...@newsone.net
Think I've got my browser set to www.almaden.ibm.com It's got JRD and other current topics linked in. Edward(Ed) J. Finnell, III Enterprise Systems/Proj. Mgr. url:www.ua.edu
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Now I'm happy to admit I haven't done the pre-req reading, however the last time I tried to fathom one of these "dense" articles, I gave up when I hit a formula that was longer than what I consider a reasonable paragraph should be. About page 2 I seem to recall .....
-----Original Message----- From: Craddock, Chris [mailto:Chris_Cradd...@BMC.COM]
<snip> ..
If you subscribe to the IBM Journal of Research and Development, they publish a wonderful (dense) description of every new machine family (including mainframes) at about the time the new machines show up.
********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager of QR.
This message has been swept by MIMESweeper for the presence of computer viruses. No warranty is given that this message upon its receipt is virus free and no liability is accepted by the sender in this respect.
This email is a message only; does not constitute advice and should not be relied upon as such. **********************************************************************
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
----- Original Message ----- From: "Craddock, Chris" <Chris_Cradd...@BMC.COM>
Newsgroups: bit.listserv.ibm-main To: <IBM-M...@BAMA.UA.EDU> Sent: Wednesday, February 14, 2001 10:58 AM Subject: Re: z/Architecture I-cache <SNIP>
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Shane - you probably didn't spend enough "beverage hours" on it. You'll notice I didn't specify what kind of beverage you needed ;o)
While I've still got my soap-box out, this situation should cast a dark cloud of terror over you folks out there who still write non-reentrant code. That's precisely the kind of code that's going to drive the z-boxes nuts.
So if you haven't made the switch to reentrant code (whether in your asm code, or your compiled code) -NOW- is the time to get that out of the way. Non-reentrant code is going to run like a dog on a 2064 when compared with the same code implemented reentrantly.
Chris
>-----Original Message----- >From: Ginnane, Shane [mailto:Shane.Ginn...@QR.COM.AU] >Now I'm happy to admit I haven't done the pre-req reading, >however the last >time I tried to fathom one of these "dense" articles, I gave >up when I hit a >formula that was longer than what I consider a reasonable >paragraph should >be. >About page 2 I seem to recall .....
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Oh, wow, does that means that I need to get rid of all my in-line save areas? OUCH! I use them so that R13 can be used as a base register. Well, I need to rewrite using the new relative instructions anyway so that I don't need to worry as much about code base registers. OOPS, that means I need to upgrade HLASM so that it recognizes the new opcodes. OOOHHHH, my head hurts <grin>.
Of course, like Seymour, I'm on old hardware and not likely to be upgraded anytime soon.
---------------------------------------------------------------------- John McKown HealthAxis
All opinions are my own and are not the opinions of my employer.
> -----Original Message----- > From: Craddock, Chris [SMTP:Chris_Cradd...@BMC.COM] > Sent: Wednesday, February 14, 2001 6:51 PM > To: IBM-M...@BAMA.UA.EDU > Subject: Re: z/Architecture I-cache
> Shane - you probably didn't spend enough "beverage hours" on it. You'll > notice I didn't specify what kind of beverage you needed ;o)
> While I've still got my soap-box out, this situation should cast a dark > cloud of terror over you folks out there who still write non-reentrant > code. > That's precisely the kind of code that's going to drive the z-boxes nuts.
> So if you haven't made the switch to reentrant code (whether in your asm > code, or your compiled code) -NOW- is the time to get that out of the way. > Non-reentrant code is going to run like a dog on a 2064 when compared with > the same code implemented reentrantly.
> Chris
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
On Thursday, February 15, 2001 8:41 AM, McKown, John wrote: > Oh, wow, does that means that I need to get rid of all my in-line save > areas? OUCH!
Not to mention all the IBM-supplied services that address the parmlist with BAL R1,*+4+length_of_parmlist.
-jc-
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
You meant that you're not already using MACRF=(E,xxx) or an equivalent for everything?
Shmuel (Seymour J.) Metz
> -----Original Message----- > From: Chase, John [SMTP:jch...@USSCO.COM] > Sent: Thursday, February 15, 2001 9:46 AM
> Not to mention all the IBM-supplied services that address the parmlist > with > BAL R1,*+4+length_of_parmlist.
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
At 14 Feb 2001 16:50:46 -0800, Chris Craddock wrote:
>While I've still got my soap-box out, this situation should cast a >dark cloud of terror over you folks out there who still write >non-reentrant code. That's precisely the kind of code that's going to >drive the z-boxes nuts.
I believe that writing reentrant code may not always save your bacon on this issue...
Let's assume a block of AMODE31 reentrant code that's loaded in 31-bit storage. This code has GETMAIN'd a block of 24-bit data storage. The program logic requires a small bit of code that lives in 24-bit storage. So the program copies a model of the code segment from it's 31-bit storage to a location in the 24-bit data block. The program then invokes the code fragment from its target location in the 24-bit data block. I'll bet this could cause the type of cache issue that we've been discussing. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
If you build it once and use it many times, you will only hit the over head once. Now if you build this generated code, and you build it non-reentrant where ,let's say, you have a save/work area at the end of it, then you will hit the problem.
A cache line can exist in both the I-cache and the D-cache but only as long as the D-cache line is not modified. All those constants that you have in your reentrant programs do not cause a problem because they do not get changed. (Another reason to group all the constants and LTORGs together is that you will have fewer duplicated cache lines.)
John McKowen, and all the others that have a bunch of non-reentrant code, really should think about converting them sooner, rather than latter, to reentrant.
Another thing that is aggravating this problem a little is that the cache line length for the z-Series is 256 bytes, where before it was 128 bytes. It is probably a small grain of salt in the wound, but it is one more grain.
Chris Blaicher
BMC Software, Inc. Austin Research Labs 10415 Morado Circle Austin, TX 78759 512/340-6154
BMC Software, Inc. makes no representations or promises regarding the reliability, completeness, or accuracy of the information provided in this discussion; all readers agree not to rely on or take any action against BMC Software in response to this information.
> -----Original Message----- > From: Eric Chevalier [mailto:blackbird_...@HOTMAIL.COM] > Sent: Thursday, February 15, 2001 12:03 PM > To: IBM-M...@BAMA.UA.EDU > Subject: Re: z/Architecture I-cache <snip> > Let's assume a block of AMODE31 reentrant code that's loaded in 31-bit > storage. This code has GETMAIN'd a block of 24-bit data storage. The > program logic requires a small bit of code that lives in > 24-bit storage. So > the program copies a model of the code segment from it's > 31-bit storage to a > location in the 24-bit data block. The program then invokes the code > fragment from its target location in the 24-bit data block. > I'll bet this > could cause the type of cache issue that we've been discussing. > _________________________________________________________________
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> -----Original Message----- > From: Blaicher, Chris [SMTP:Chris_Blaic...@BMC.COM] > Sent: Thursday, February 15, 2001 12:55 PM > To: IBM-M...@BAMA.UA.EDU > Subject: Re: z/Architecture I-cache
<snip>
> John McKowen, and all the others that have a bunch of non-reentrant code, > really should think about converting them sooner, rather than latter, to > reentrant.
I would like to do that. However, there is a "problem". I have responsibility (I didn't design it!) for a general purpose asm subroutine which is called literally 1000s (maybe close to 10,000!) times every time this one program is run. If I were to make this routine truly reentrant by dynamically acquiring a save area, the execution time would be horrendous! What the program does is load the data from a VSAM file into 31 bit memory. The records are variable length. The program reads the records into memory, creating an in-memory array of pointers to each record. When a "get by key" request is given from the calling program, this routine does a binary search of the array to find the key requested. In my opinion, this program should be eliminated, but it is a MAJOR subroutine in many COBOL programs. Telling applications to change these program is simply not an option. I guess that I could minimize this "problem" by only using the save area on the "load the file" call. The rest of the calls do not require a save area since the program does not use any system facilities (it's really just a simply binary search routine which builds its own table from the VSAM file when first called).
<snip>
> Chris Blaicher
> BMC Software, Inc.
---------------------------------------------------------------------- John McKown HealthAxis
All opinions are my own and are not the opinions of my employer.
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
|
