|
Bill, I'm sure they work every time. But how much effort is spent locating and modifying every instance of that subroutine if the requirement changes? I've been there, that's why I've spent the better part of a year honing my ILE skills. And within the last 2 months, the effort I put in has paid off numerous times. Just a for instance; I had to create a series of reports that output certain aspects of our inventory. There were a total of 12 reports based on different sorts, groupings and includes. One aspect was the quantity for which there were open orders. I could have written a subroutine that read the open order detail file and accumulated the quantities. And I could have dropped that routine into every program that used it and it would have worked. But what I did was write a sub-procedure to retrieve the quantity and return it. And then put it into a service program. And added the service program to a binding directory which I used when compiling the reporting programs' output modules. Seems like allot more work than to write one subroutine and drop or /copy it into the programs. But,after a months analysis, our planning people decided that they didn't want to see open transfers in the quantities. Now the beauty of ILE. I changed the sub-procedure to filter out open transfers, recompiled the module, updated the service program and viola, I'm back learning Java again. (That's another list's story). This is a very simple example and just my 2 cents. Mark Mark Walter Sr. Programmer/Analyst Hanover Wire Cloth a div of CCX, Inc. mwalter@hanoverwire.com http://www.hanoverwire.com 717.637.3795 Ext.3040 "Bill Bynum" <bill.bynum@nucorcoldfin To: <RPG400-L@midrange.com> ishsc.com> cc: Sent by: Subject: RE: ILE Propoganda owner-rpg400-l@midrange. com 06/21/01 01:29 PM Please respond to RPG400-L In my MANY years of programming,(mind you that MANY constitutes a level much higher than Jr. programmer) every subroutine written in programs that are currently being used in a production environment have been previously tested(i.e. old code that is NOT broken). Granted, you may have to tweak the code(i.e. change indicator references, etc.) but it puts the code right in front of you rather than relying on a hardcopy, and/or an additional session, swapping back and forth from one to the other. Talking about being realistic, when you are dealing with RPGII, RPGIII, RPG400, and RPGLE in one environment, and you know that there is a subroutine or a piece of code that is being used in an RPGII program that would help you in an RPG400 program, you better believe that I will go and copy that code and drop it into the new program. And the nice thing about it, it works every time. Bill -----Original Message----- From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On Behalf Of Buck Calabro Sent: Thursday, June 21, 2001 12:15 PM To: RPG400-L@midrange.com Subject: RE: ILE Propoganda >It seems to me that if it is code that has been >previously written in another program, the >simplest and quickest way would be to copy >and paste that part of the code to the new >program. Let's face it, for most every project >you are working on there is a deadline I can't tell you the number of times I've heard various junior programmers say something similar. How about a more realistic scenario? "copy and paste that part of the code" versus o Locate the code. It's everywhere, so decide which version is closest. o Copy and insert the code. o Change the field names to fit the new code into the existing program. o Check the indicators to be sure there's no overlap. o Doing I/O? Check that we won't disturb the file pointers. o Manipulating text? Change the array size/field lengths to match the new requirements. o Manipulating numbers? Change the field sizes to match the new requirements. o Got work fields? Don't want to miss them. o Test the new code to see if it works. o Test the old code to see that it isn't broken. Integrating at the "copy the source code" level takes more than simply copying lines of text. If it truly WERE that simple, wouldn't most of your code be /COPY statements? 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 +--- +--- | 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.
midrange.com
