|
You can use the old call mechanism and for things that are not calling each other more than a few times it probably makes the most sense to do this. However look at procedures this way. A problem is best solved by breaking it up into sub problems and then examining each sub problem and breaking it down etc... This is called functional decomposition. What is the benefit to this? Well by breaking a problem into smaller chunks it is much easier to test in all possible ways. Once you have a given chunk of code that works (even handling rotten input/output) you should not have to examine this code again. The only thing that is important then is the interface to the function, it's name and purpose. The internal workings should be a black box (you should not need to know how it does it's work only that it does). Sub procedures are the only way you can have local variables in RPG. Local variables are invisible to the rest of the program at large and therefore can not be violated by any normal means ( the AS/400 makes it even harder to trash local variables than most other systems and even on other systems it is usually not a trivial matter to figure out how to corrupt locals). IMHO Sub procedures should do ONE thing and do it VERY WELL. They should have a well defined interface, that meaning they rely totally on their parameters and not on Global variables or their uglier cousins *IMPORT variables. (At least most of the time :-) They should be well documented in the /COPY member. Ideally they should be available in both Service Program (Generally preferred) and Module form. So if you have a batch program that needs to perform a certain function for each record you surely do not want to do an external call for this due to the overhead. The only solution prior to ILE RPG was to copy the code to do that work into your program and then you have multiple versions of the same code spread all over the place... Very bad!!! For example how many ways have you seen in home brew and vendor apps of working with dates??? How many times have you seen the same code or similar code copied over and over in a multitude of programs? How many times have you accidentally changed a variable that "shouldn't have mattered" and found out that the earth came to a screeching halt? Sub procedures and their local variables can help to dramatically reduce this problem!!! Oh and for everyone who is reading this if you can find a good academic definition of Structured Programming Methodology I would love to have a source other than my own memory to quote from... For some reason people do not think I am the be all, end all as far as answers go :-) I hope this helps Eric ______________________________________________ Eric N. Wilson President Doulos Software & Computer Services 2913 N Alder St. Tacoma WA 98407 ----- Original Message ----- From: <rbrightman@amclog.com> To: <RPG400-L@midrange.com> Sent: Friday, April 07, 2000 11:37 AM Subject: Re: 'ILE RPG' or 'RPG IV' . What's the difference!!! > > > If its true that ILE was meant to reuse specific code in multiple programs, then > is reminds me of why IBM gave us printer files (prtf). These were intended to be > used in multiple programs also. But I have never used the same printer file in > two or more programs because each program requires a different report. Only a > few routines would need to be modularized usually. So whats the benefit of ILE? > Why can't we still use the old 'call' ? > > > +--- > | 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-2025 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.