|
Yes, I agree. One of the issues I had been having trouble with was conflicting parms from application to application. Sometimes dates were alpha, sometimes numeric. Sometimes the customer number was 7/0, other times 15/5. The parms were usually consistent, but not always. Another issue was the looking up of the same information over and over in a single application. In any event, times have changed and Scott's points are right on. It is time to change, too. --------------------------------- Booth Martin http://www.martinvt.com --------------------------------- -------Original Message------- From: RPG programming on the AS400 / iSeries Date: 10/27/05 15:53:15 To: RPG programming on the AS400 / iSeries Subject: Re: Passing Parms Question - whether you change the number of parameters or the component of a single parameter, surely ALL programs that call the single/multiple parameter program MAY need to be retrofitted for the change - depending upon what that change is? In other words, some analysis will need to be done either way. Alan Shore NBTY, Inc (631) 244-2000 ext. 5019 AShore@xxxxxxxx Scott Klement <rpg400-l@scottkl ement.com> To Sent by: RPG programming on the AS400 / rpg400-l-bounces@ iSeries <rpg400-l@xxxxxxxxxxxx> midrange.com cc Subject 10/27/2005 04:16 Re: Passing Parms PM Please respond to RPG programming on the AS400 / iSeries <rpg400-l@midrang e.com> > Isn't this a lot easier than tracking down all the programs that would need > lines of code changed, too? Why not make the recompiles unnecesary? Wouldn't that be less/easier maintenance? I suppose you enjoy mass-recompiles? Suppose you have 50 computers to deploy the changed program on. Now you have to find out, on each computer, which programs call the one you've changed, and you have to recompile/replace them all. And this all has to be done while nobody is using any of them. Isn't that a lot of work? What if those computers aren't all under your control. What if you sell software to (for example) cleanse an address. The client has written software that calls your program from their own code. Now you change/add a parameter to your program, and you have to ship out a new copy to every customer, along with a new copy of the file that the ext data structure is based on, and get every customer to recompile all of their programs that call yours. Because of this, people will resist installing the update. They'll put it off. In the mean time, you have to support bugs in the new version AND the old one because the customers need time to make the changeover. You could've eliminated all of this simply by making it so that the calling programs DON'T NEED TO BE RECOMPILED. And that's much easier to do with single parameters than it is with data structures. Furthermore, since single parameters are all independent of one another, you can lessen the impact of changes so that it affects fewer people if you use single parameters. I realize that not all of the things I've listed here apply to everyone who writes programs -- but you haven't listed a single reason why data structures work better. Indeed, your only argument so far was for using externally defined fields for parameters! That can be done with single parameters as well as data structures. You still haven't told me why data structures are easier to maintain! How do they make maintenance easier? The advantage to data structures is that you can group fields together when they belong to a "set" of fields. For that, data structures are brilliant. It's exactly what they're intended for. But simply passing all parameters as data structures as a rule of thumb doesn't make any sense to me. > I ought to say this: as with so many things, there is no single right > solution. creating a data structure for one parm in a standalone > application would seem silly. Using the data structure is just one more > bullet in the programmer's gun belt, imho. The question is: if he uses that bullet, will he shoot himself in the foot? -- 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.
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.