On 2/5/2018 1:49 PM, Craig Richards wrote:
I've always created modules separately and then created either programs or
service programs. Partly this was from the early days when I was trying to
help people understand that one source member does not necessarily = one
program or service program.

In the past 20 or so years, I've predominantly built systems that are
one source member = one object. Whether *PGM or *SRVPGM. For
simplicity's sake.

But now I'm trying to simplify things for my client who has no change
control and not so much technical resource, hence my ponderings on if I
could set up ( as much as possible ) single compile commands and specify as
much as I could internally in the program.

With one member per object, that's easy. PDM 14 for all *PGM objects,
and CALL MKCUSTSRV, etc for service programs. Service programs are
special because architecturally, they ARE special.

Programs get a /copy for the H-specifications which include the
company-standard BNDDIR(), ACTGRP(), etc. If you want, service programs
can get a different /copy for their H-specifications. In a simple shop,
it would be surprising to find that there were many service programs, so
this 'specialness' isn't much of a burden.

For those reading along: the goal here is simplicity. More complex
scenarios will benefit from a more sophisticated architecture.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.