Re: Service Program Limitations

<Jon>
Dieter I love the way you mis-interpret what I said and then argue against yourself like this.

I said "one module one SP" - I have no problems with binding a module by copy and never said I did. If the relationship is one-to-one (i.e the bound module is only ever used by one program) then it makes sense. What I object to is the idea that you make life "simpler" by having a one module = one SP approach - and THAT was what I said.

By function I meant organizational function. Others had said the same thing so I was short handing. One SP for accounting specific routines, one for product specific, whatever. If you like to think of it in an object oriented model that works fine for me.


Jon Paris
</Jon>

Jon,

maybe we are not too far away from each other, ....
but!!!

you where talking about silliness of the aproach of one module one srvpgm, maybe I'm understanding it the way, that there might be situations to decide to seperate some functions to multiple modules, binding them afterwards to one SRVPGM, but what I've seen are big samples of modules, applications, having SRVPGM1 and SRVPGM2, having no internal relations between the implemented functions. (BTW: I've seen too applications designed by the paradigm of one procedure = one module = one SRVPGM - thats really silly). What I'm trying is, to give some guidelines as a starting point and IMHO one module = one SRVPGM is the tipical case and you must have some arguments to bind multiple modules by copy. Most important argument would be deployment (important for the OS SRVPGMS).

Regarding OO versus functional design, tout le mond is distinguishing design between OO and functional aproach by looking at the first level: grouping by what you are doing is functional and grouping by object is OO - here we got some consens.

D*B