RE: ILE philosophy

["Brunk, Kevin" <Kevin.Brunk@xxxxxxxxxxxx>]

Makes you wonder why, when IBM introduced the ILE concept and implementation, 
they didn't introduce some sophisticated management tools for it, so that the 
technical details of your hierarchy would be managed (or at least aided) by the 
system.  Imagine a future where someone has taken the ILE concept to it's 
ultimate and has thousands of functions, modules, service program to manage.  
Having that managed by a computer aided tool would be helpful...having that 
tool be part of the operating system would really be innovative!

==KB

-----Original Message-----
From: rpg400-l-admin@midrange.com [mailto:rpg400-l-admin@midrange.com]On
Behalf Of Rich Duzenbury
Sent: Thursday, September 19, 2002 11:54 PM
To: rpg400-l@midrange.com; rpg400-l@midrange.com
Subject: RE: ILE philosophy


At 10:26 AM 9/19/02, Buck Calabro wrote:
> >Is the service program approach really
> >the bees knees?
>
>Yes, yes, a thousand times yes!

Boy, you really sound convincing. I gave it a try and I'm still not sure
about this.  Here is where I came up short:

In my mind, I imagine ILE to be a four tiered hierarchy:

Binding Directory (one or many) has
         Service Program (one or many) has
                 Module (one or many) has
                         Function (one or many)

I realize that more arrangements can be made than this, but this seems
principally how I can see it working.

Right now, my biggest issue with the whole deal comes down to managing the
service programs.  Say I create a new module, I've got to recreate the
service program that it should reside in.  I've got to update my binder
language source first - by hand it would appear.  Then CRTSRVPGM -- and I
have to retype all of it's constituent module names.  If there are 100
modules, yuck.  I'm sure to forget one.

If I just update a module, I have to UPDSRVPGM - provided I didn't change
the interface to any routines.  I don't see a great way to automate the
process -- it would be easy to break.

A 'make' utility might go a long way towards making the system work
efficiently.  Although I don't think a regular make utility (as I'm used to
seeing them on other platforms) could effectively deal with updating the
binder language source -- at least out of the box.

Are you manually managing the binder language source?  What, if any, tools
are there to help?

Thank you.

Regards,
Rich