|
OK - here's the thing; All the sub-programs/binding/stuff makes 1) Bigger Code (more memory) 2) Bound Code 3) Slightly easier to understand - since we're making our own functions... 4) Slower Code (from second hand tests.... So nobody yell @ me...) The memory saving dynamically linked "CALL" W/O *INLR takes 200ms (old number?) to load into memory ONCE- then it's there until it shut's down. Polite programmers have written "when I send you a '1' here - you shut down all nice like" that Joe is talking about, but honestly - when the people signed off, the same thing happened anyway.. Does anyone have current benchmarks about this? Andrew Borts / Webmaster Seta Corporation 6400 East Rogers Circle Boca Raton, FL 33499 E-mail: Andrewb@setacorporation.com Corporate web site http://www.setacorporation.com E-Commerce web site http://www.palmbeachjewelry.com http://www.myfreeitems.com Voice: 561-994-2660 Ext. 2211 / Fax: 561-997-0774 -----Original Message----- From: Joe Pluta [mailto:joepluta@PlutaBrothers.com] Sent: Friday, December 28, 2001 2:32 PM To: rpg400-l@midrange.com Subject: RPG ILE and *INLR AGH! I DIDN'T CHANGE THE STUPID HEADER! I apologize. > -----Original Message----- > From: rpg400-l-admin@midrange.com [mailto:rpg400-l-admin@midrange.com]On > Behalf Of Joe Pluta > Sent: Friday, December 28, 2001 1:30 PM > To: rpg400-l@midrange.com > Subject: RE: Official language of midrange.com (was RE: SQL) > > > Here's a question: in good old RPG III, I often used the technique of > calling a program repeatedly without setting on LR. I usually > had a control > program that, at the end of its processing, then called each of the > subprograms and told them to shut down. Each subprogram then seton LR and > ended. > > This was excellent for performance, and at the same time cleaned up the > subprograms between calls to the control program. > > In my move to RPG ILE, I'm wondering how to handle this. I'd > like to change > the called programs to bound calls (CALLB), and then bind them > all in. If I > do a CALLB to a program, what are the effects of *INLR? > > 1. If the called program does not set on LR, I assume that > subsequent calls > do not go through the initialization, just like in the old OPM CALL > situation. > > 2. If the calling program sets on LR and then ends, does this in > effect set > LR on in all the called programs, clearing them from the PAG? > That is, the > next time I call the control program and it in turn does a CALLB to the > subprogram, does the subprogram go through initialization again? > > 3. If I set on LR in a called program and it returns, does that in effect > set on LR in the calling program? > > Just wondering. I'm going to do some tests to confirm all the > above, but I > wondered if anyone else had run into this and could provide some insight. > > Joe > > _______________________________________________ > This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list > To post a message email: RPG400-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l > or email: RPG400-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/rpg400-l. _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l or email: RPG400-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.
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.