|
If I can add my 2p to this.. One thing that we have noticed is that when developing using subprocedures you end up with a lot less bugs coming out in testing. My feeling is that this is because you are coding smaller discrete blocks of code to perform simple functions. It is protected from the rest of the program by having local scope so no other section can inadvertently change it's data... .. and to reiterate the point others have made about modules - we do not allow modules to be re-used in more than one program or service program object. Stu PS. Having done your ILE course a few years ago Brian, it is still the single best technical course I have ever been on. -----Original Message----- From: Brian Parkins [mailto:PARKIB@xxxxxxxxxx] Sent: Thursday 23 October 2003 16:15 To: RPG programming on the AS400 / iSeries Subject: RE: Benefits of Sub-procedures I get asked this question all the time by students on my ILE courses. My take on this is that (static) procedure calls do _not_ replace (dynamic) program calls - they _complement_ them. The Dynamic Call (CALL and CALLP/EXTPGM) we've used since the S/38 is in fact a WONDERFUL facility. The late bind provides simplicity and flexibility - with a relatively small performance overhead. So, program calls are A Good Thing - just as valuable as they ever have been. On the other hand, Subprocedures provide a much better alternative to Subroutines. Many of the advantages have already been highlighted, (local variables, parameter passing, automatic storage allocation + recursion, more rigorous call interface, expression call, etc.). To my mind, the big advantage of Subprocedures is the ability to "share" code, (through a Service Program). A Subroutine can be shared (proliferated) through the use of /COPY - but results in a significant maintenance burden. In contrast, a Subprocedure can be packaged into Service Programs and shared in a similar manner to a program object. Service Programs act as a "function repository" - a means of building and sharing your own built-in functions without the proliferation problems of /COPY. Now, if Subroutines (and /COPY) are _not_ used in an organisation, the argument for the modularity/reuse which ILE supports becomes a little more difficult. Hope this helps. Brian Parkins _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l. If you are not the intended recipient, please notify the sender by return email and then delete the message from your computer. The Skandia UK Group reserves the right to monitor e-mail communications through its networks. No contract may be concluded on behalf of the Skandia UK Group by email. Skandia Life Assurance (Holdings) Limited Skandia Life Assurance Company Limited Skandia MultiFUNDS Limited, Skandia Investment Management Limited. Registered Nos: 1606702, 1363932, 1680071, 4227837, England Registered Office: Skandia House, Portland Terrace, Southampton SO14 7EJ, United Kingdom Royal Skandia Life Assurance Limited Registered No : 24916 Isle of Man Registered Office: Skandia House, King Edward Road, Onchan, Isle of Man IM99 1NU, British Isles Skandia Life Assurance Company Limited, Skandia MultiFUNDS Limited, Skandia Investment Management Limited and Royal Skandia Life Assurance Limited are authorised and regulated by the Financial Services Authority for UK investment business. Internet: www.skandia.co.uk
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.