×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 19/05/2009, at 3:57 PM, Birgitta Hauser wrote:
I just like to know how you handle it and why.
I group by function so I have a service program for each collection of
related stuff:
o Strings
o Dates/Times/Timestamps
o Data queues
o Financial
o Maths
o Messages
o Objects
o Security
o STDIO
o Storage
o UIM
o User spaces
o Work management
o Conversion
o Miscellaneous
etc.
Each service program is usually made up of a single module with many
procedures but if I need to split the procedures (due to appropriate
language or cleanliness) then I'll build a service program from
multiple modules.
I would never use a single giant service program with everything in it.
a) It will take ages to activate
b) It seems unclean
c) It's messy to replace
d) Your own points are valid
Similarly, I would never have a gazillion small service programs
simply because it seems messy during binding (even though a binding
directory will remove most of these issues). I suspect that activating
many small service programs will also show a performance penalty.
Activating one huge one certainly does. I know of a software vendor
who ran into this problem. They had a cross-platform application that
used a single DLL. They converted this to a single service program and
program start time took minutes. This was a HUGE service program so is
an unusual situation but still shows the problem exists and is worth
considering.
Seems to me the desired approach is a middle ground and splitting
service programs by functional area is a good as any. In an
application environment there will be common functions and then
functions specific to particular areas of the application (e.g., GL,
AP, AR, OE, etc.). I would split these up too.
Doing this allows the developer to bind to only those service programs
that contain functions actually used which helps with "where-used"
analysis. It also minimises activation time to only those things
actually (or mostly) used.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
