RE: Subprocedure Question

If your objective is to achieve a MVC design model then you could implement
some form of Scott's final suggestion.  However, you said that your
objective was to enable file changes w/o recompiles.  This is relatively
easy to achieve, and requires no service programs, binder language or
significant program changes.  Most file changes involve adding a field.
They should all be this way.  Never change field lengths and attributes.
Want a longer Customer Name?  Add a new field to the end of the file.  No
PF's should be directly used by programs.  They should all refer to LF's.
The LF's should always have all their fields explicitly defined in their
DDS (as opposed to inheriting whatever is in the PF by not specifying any
fields at all).  This is a fairly easy state to acheve (especially when
compared to the service program approach).  Having done this, you can now
make a change to your PF, issue the CHGPF command, and your PF has the new
field.  Your LF's format level ID's are unchanged so there are no programs
to recompile and no level checks.  Now you can phase in use fo the new
field at  whatever pace suits you.  Create new LF's which reference the new
field and cut over to using them.  The new LF's will share existing access
paths (unless you need a new path) so there is no real downside.  I have
used this technique to good effect for a long time.  Use this method and
you will never need to create another extension file, nor need to add dummy
fields to your files for future use.

Thanks, Dave

David Keck
NBTY, Inc
Phone (631) 200-5809
DavidKeck@xxxxxxxx




> Thank you everyone.  This information is very helpful.  I am thinking of
> using service program to gain the ability to make changes without having
> to recompile.

It's very difficult (if not impossible) to make it possible to make
changes without a recompile.  What if you make a field bigger that's used
in a subfile?  or on a report?  or on a screen?  or is moved to work
variables?

To do it right, you'd have to go back and change these reports, screens,
work variables, etc.  You'd have to shift other fields around to make
space for the expanded field size.

How are you going to do all of this without a recompile?

It's true that you might be able to avoid recompiles when adding a brand
new field, however.


> But Paul's warning about potential file sharing conflicts concerns me.
> Is there a way to avoid these conflicts and still use service program?

Sure, you just have to have a separate copy of the service program for
each program that needs to be active at the same time. Or, you'll have to
write your programs so that they don't rely on the file pointer to be in a
particular position.

> I know we are going to run into a problem where I have two programs
> reading the same file and in the same application.

A sure-fire way to solve this would be to access the files through the
Ropen(), Rlocate(), Rreadk, Rupdate(), etc APIs so that you can have
multiple instances of them open at once.

Though, frankly, I think you're creating a nightmare for yourself by doing
things this way.  Don't "echo' the RPG CHAIN, READ, WRITE, etc opcodes, it
gains you very little!  Instead, write a "Business Model" service program,
and keep with the MVC design.