|
Thanks for your comments, Simon. I was starting to wonder what had happened to all the ILE proponents out there. A couple of interesting results came up when I reworked all the internal modules (contained in the 15 meg program) to a state where they could be called dynamically as separate programs. First, I ended up with 12 compiled programs that totaled up to only 13.6 megs. I had to rearrange a few things that had previously been handled as exports/imports between the modules into a datastructure passed by a pointer. I guess this is where the savings came from. Then, just for kicks, I recompiled all the modules back into the single program again, and the new program came out to only 12.2 megs. With Debug at *NONE and Optimize at *FULL. it reduces on down to 4.3 meg. At least I got it under IBM's largest one :-). Further tinkering here probably won't gain that much more. I still have over 500K in static storage to deal with though, so I think I need to put more effort on reducing that side of things, now. As a combined program, I assume each user will get all 500k allocated to them each time they call the program. If I use the 12 program model, only 4 programs would always be called and the other 8 would be called less frequently (this fits the 80/20 rule fairly well). If the first user (or some user) has all 12 programs active, will each additional user that calls, say, the first program only get only the variables associated with the first program or all 500k? Another question: The initial call to this system is to a cl program that runs in *CALLER and saves everything (libr lists, lda, etc) about the caller's environment and then calls this program(s) which run in their own named activation group. On termination, the cl reclaims that activation group and restores the caller's original environment. If a second user, in another job, is using the program code reentrantly (is that a word?), what will happen when the first user's job tries to kill the activation group. Will the rclactgrp command be ignored because some other job is using the code? I guess I don't understand the relationship between the program code in an activation group, which is part of a job, and the other user's use of that same code in memory. Does each user's activation group only contain pointers to the code and not the code itself? If so, I guess blowing away one activation group would not effect another user's activation group that is using the same code. Is this the way it works? When I broke up the one program into 12 separately compiled programs, I gave them each their own activation group name with the thought that I could reclaim the lesser used ones when the user was finished with it and, thereby, keep the total size down. Do you think this is still a good idea? Thanks for your help. ************************************************************************************************************************************************************************************************************ This message originates from Lincare Holdings Inc. It contains information which maybe confidential or privileged and is intended only for the individual or entity named above. It is prohibited for anyone else to disclose, copy, distribute or use the contents of this message. All personal messages express views solely of the sender, which are not to be attributed to Lincare Holdings Inc., and may not be copied or distributed without this disclaimer. If you received this message in error, please notify us immediately at MailAdmin@lincare.com or (800) 284-2006. ************************************************************************************************************************************************************************************************************
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.