Re: Service Program Limitations

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

www.partner400.com
www.SystemiDeveloper.com

On May 24, 2019, at 4:38 AM, D*B <dieter.bender@xxxxxxxxxxxx> wrote:

<Jon>
Organize based on functionality and try to avoid the silliness of one module one SP.
</Jon>

I dont' see any silliness in avoiding binding by copy. There are good reasons not using bind by copy.
What do you mean by organized on functionality? putting all read functions in one and all write functions in another? I prefer to use an object oriented aproach, organizing by the object procedures are working with (e.g. put all functions together handling a streamfile or putting all together, dealing with an article...). From a technical perspective: put together procedures sharing statefull data.

D*B
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com