RE: Creating a service program

["Richard Jackson" <richardjackson@xxxxxxxxxxxxxxxxxx>]

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
+---