RE: Creating a service program

You're stirring up some little gray cells that have been sleeping
comfortably (and dying off) for many years.  I'll try to get this right but
don't shoot me if it doesn't match the recollections of some other people.

Binder language was in the original specification but I think that
signatures were not part of binder language.

There was no update service program in the original spec.  The plan was to
recreate service programs (and regenerate the signature) then recompile all
the programs that used the service program.  This part is a little fuzzy,
keep reading.

I have a vague recollection: the expectation was that service programs were
expected to change about as often as physical files so copying the service
program signature into all the programs that used it was as safe and static
as binding the programs to the database.

When designing this part of ILE, the IBM developers didn't recognize that,
as software developers in our own right, we had large and complex
applications with PTF processes of our own.  They thought that we just
shipped new releases.  When we told them that a JDE release contained about
8,000 to 10,000 program objects and copy books and that a product release
consisted of more than 10 million lines of code (all pieces), they were
stunned.  They had no idea that our apps were that large.  There were other
vendors with similar-sized products and similar-sized problems.  This
revelation forced them to reconsider how we would architect and support
service programs.  I think that it also gave them a list of the choices that
IBM might select from when they went to use service programs in the future.

When we made it clear that service programs would be a keystone in new
architectures and that they would break and have to be enhanced and repaired
frequently, the IBM people thought up the fairly complex signature
management scheme that we have today.

Export(*all) wasn't the only choice, the service program could have private
functions.  But any change in the interface for an exported function would
cause all affected programs to be recompiled.  I don't recall this next bit
specifically but I have a vague recollection that the program signature was
not function by function, there was one signature for the entire list of
exported functions.

We also whined about having to ship these huge things with a 1,000 functions
in them over 14.4 and 28.8 and 9.6 and 4.8 circuits and asked for some way
to replace just one failing function in a huge service program.  Some of us
supported customers in places where 4.8 was the best you could do.  We were
all looking forward to shipping software on CD-ROMs.

I'm pretty sure that, at the time, some of use didn't completely understand
the signature solution (I recall feeling nervous about the complexity of it
all) and we weren't told very much about the implementations.  If it didn't
work out very well from your point of view, we did our best and I think that
it turned out okay - I don't feel too badly about it.

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 Simon Coulter
Sent: Wednesday, August 23, 2000 5:53 PM
To: RPG400-L@midrange.com
Subject: Re: Creating a service program


"
Hello Richard,

You wrote:
>In JDE code, date conversions, numeric conversions, and several other
>routines are used everywhere - in every program.  If those routines were in
>a service program and that service program was compiled to export all
>procedures and a new routine was added to that program, at the time every
>service program would have had a signature and that signature would have
>changed with the new routine and JDE would been forced to reship every
>program on the system.  We thought that it might have been too difficult to
>statically determine intricate call stacks between about 2,000 mainline and
>subprograms plus another thousand RPG subroutines presently in copy books.

Ahh! Now I understand.  But that problem is all to do with EXPORT(*ALL) and
nothing to
do with 'updating the service program' which I took to mean via the
UPDSRVPGM command --
which existed internally and I recall wasn't going to be exposed.  Do you
really mean
that binder source wasn't planned and therefore the signature would change
anytime the
service program interface changed (new procs, new parms, etc) because
EXPORT(*ALL) was
the only choice?  That seems remarkably short-sighted and unlikely.

>If the machine helped, we were more comfortable.  So we fought for a way to
>update a service program and ship just the changed service program and
>effected modules.  Participating in these meetings gave me a great deal of
>respect for the IBM people that make far-reaching architecture decisions
all
>the time.

And so it should .... :)  For the most part, Rochester does a bloody good
job.  It's the
idiots in Armonk (and White Plains) we have to wack about bit ....

Regards,
Simon Coulter.

«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
«» FlyByNight Software         AS/400 Technical Specialists       «»
«» Eclipse the competition - run your business on an IBM AS/400.  «»
«»                                                                «»
«» Phone: +61 3 9419 0175      Mobile: +61 0411 091 400           «»
«» Fax:   +61 3 9419 0175      mailto: shc@flybynight.com.au      «»
«»                                                                «»
«» Windoze should not be open at Warp speed.                      «»
«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
+---
| 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
+---