× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: Creating a service program
  • From: "Stone, Brad V (TC)" <bvstone@xxxxxxxxxxxxxx>
  • Date: Wed, 23 Aug 2000 09:12:27 -0500

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 thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.