× 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.



Again strictly my opinion and may not be the best practise, but I think of
*SRVPGM as *LIB.  Yes, an OS/400 library object.  I put all my payroll
specific procedures in one service program.  I put all my utility procedures
(like number to words, centre text, trig functions) in utility service
programs.  I segregate them according to function.  I am highly likely to
need date handling and text manipulation in the same mainline, so all those
functions are in a single SP.  I only rarely need sockets functions, so they
live in their own SP.  It's a convenience thing more than anything else.

This all matches OPM behaviour pretty closely.  Separate library for each
application and a single library (or small number of them) for cross
application needs.  No scheme will be perfect.  Sometimes a P/R procedure is
just the thing for some G/L program.  Since I have but one single binding
directory that holds all service programs, the compiler goes out and binds
the right service program for me.  I see less maintenance rather than more.

As for 'one module, one service program,' I say that it depends entirely on
the application.  Often, it makes sense to have global status variables,
buffers and so on.  If I put all my procedures in a single module, then all
have access to those variables.  But sometimes I need more localised
'global' storage, and then I put those procedures in their own module.  But
more often than not, one module per service program works just fine.
  --buck


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.