|
That is a great response. Rob Berendt ================== A smart person learns from their mistakes, but a wise person learns from OTHER peoples mistakes. Buck Calabro <Buck.Calabro@com To: RPG400-L@midrange.com msoft.net> cc: Sent by: Subject: RE: ILE Propoganda owner-rpg400-l@mi drange.com 06/21/2001 08:38 AM Please respond to RPG400-L > His comment, "It sounds awfully complicated, so why not just create > a program and call the program? In a word, Performance. It is much more expensive to CALL a program than to CALLP a procedure. Look at all the cool stuff OS/400 does when you CALL a program (I'll probably miss some stuff): o If CALL *LIBL/PGM, search each library in the library list for PGM o Validate authority to PGM o Page PGM into main store o Create static storage areas if they don't exist yet o Create automatic storage areas o Open files o Search *LIBL/OVRDBF for each file o Validate authority to each file o Begin execution The S/38 performance whizzes used to eliminate the time to find/open/validate each file by using shared ODPs. The "main" program would open every file used in the application and specified OVRDBF xxx SHARE(*YES). The cost to open the file became a one time affair, because every subsequent open became a "pseudo open." Another performance kick was to RETURN instead of SETON LR. By leaving the program in the invocation stack, subsequent CALLs didn't have to initialise the various buffers and variables; the values are left over from the previous CALL. These techniques were not widely used; probably the majority of programmers thought them too complicated because the code to do this work is scattered among the various programs in the application; you can't see all the logic in one source member. As if I could understand my RPG program without looking at the CL and OVRxxx anyway. Oops. Sorry for the rant. Since every other platform had static binding, IBM added that to our bag of tools: ILE. If your man wants to use dynamic CALLs, have him do a benchmark and see the reason ILE is superior, performance-wise. We could always have "libraries" of programs to do work for us; INTCALC to do interest calculations, DATEPGM to handle dates, STRINGPGM to manipulate strings, etc. Because of performance issues, we simply haven't. That means the darned code is scattered among the various "mainline" programs instead of reused from a central repository. With good performance, we'll finally start building up reusable service programs that the other programmers can use without having to worry about integrating and testing the function every time it's reused. Buck +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +--- +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
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.