|
Oh... teehee! I misunderstood then. :) Whew... Brad > -----Original Message----- > From: Richard Jackson [mailto:richardjackson@richardjackson.net] > Sent: Tuesday, August 22, 2000 8:11 PM > To: RPG400-L@midrange.com > Subject: RE: Creating a service program > > > I'm not arguing with you, I'm agreeing with you. *ALL hurts > by preventing > the service program from being a black box - or, at least, > making it harder. > I must have expressed it badly, sorry. > > Case 2 is the "doesn't matter" case because there aren't many > programs and > they aren't in a product so you don't have to ship anything. > It's just your > own little app. If it is your own _big_ app then it isn't > case 2 any more. > > Were you in those meetings in 93 when we hammered on the ILE > people about > updating service programs? They weren't going to let us > update a service > program at all - we would have been forced to recreate > everything to bind in > a new signature. I worked at JDE at the time. If we had > changed a service > program, we would have had to reship the entire product. > That would have > been several thousand programs. It took weeks to convince > them to build in > "update service program" technology. > > Richard Jackson > mailto:richardjackson@richardjackson.net > http://www.richardjacksonltd.com > Voice: 1 (303) 808-8058 > Fax: 1 (303) 663-4325 > > -----Original Message----- > From: owner-rpg400-l@midrange.com > [mailto:owner-rpg400-l@midrange.com]On > Behalf Of Stone, Brad V (TC) > Sent: Tuesday, August 22, 2000 3:18 PM > To: 'RPG400-L@midrange.com' > Subject: RE: Creating a service program > > > Let's see here... :) > > > -----Original Message----- > > From: Richard Jackson [mailto:richardjackson@richardjackson.net] > > Sent: Tuesday, August 22, 2000 3:53 PM > > To: RPG400-L@midrange.com > > Subject: RE: Creating a service program > > > > > > "*all" depends on why you are creating the service program. > > > > Case 1: many application programs will use one or more > > routines in a service > > program. > > > > Case 2: a few application programs were modularized and use > a service > > program. > > > > In case 2, *all is fine. If case 2 is a product, when you > ship a new > > program set, there is no pain associated with sending new > > service programs > > either. If case 2 isn't a product. If you change the > > service program, you > > can recompile the program set and it only takes extra compile time. > > What about issuing service packs to fix problems? What if > the problem is > with the service program? What if you add a couple new > procedures? Why > send out all three programs and the service program when all > you need to > send out is the service program? > > It only takes compile time? It also takes bandwidth for all the other > objects (programs/service programs/modules) that you need to send out > because of the change. Instead you could use binder language > and only send > out the service program. That's the whole point behind > signatures. I don't > care what the scenario, it will change and it will always be > easier to send > one object than 2 or 3 or 10. > > > > --snip #1 because it's what I already said and INHO applies to all ILE > systems developement--- > > > Brad, if your advise is followed, the inside of the service > program is > > controllable without forcing a recompile. That is why it is > > a good idea - > > the service program becomes a "black box" and that is very good for > > maintenance. > > I don't quite follow what you mean here. As long as the io > parms and the > signature stay the same, I shouldn't need to send out > anything more than > just the service program. > > Example, I have a subroutine that returns centered text. > It's in production > being used by many programs. Now, I find out I did it wrong > and need to > change the "guts" of it (no i/o parms, though). I change it, > recreate the > service program, and send that and only that out. Simple... > wonderful, and > easy. > > And if I use signatures, then all I have to send out is the > service program > and any programs that use the new subprocedures withing. > > Again that's the point of ILE. *ALL removes this. > > Brad > +--- > | 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-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.