Re: A design philosophy question -- RPG400-L

Joe

As the subsequent posts show, there is no certain answer to your problem but I
can tell you what has worked well for me.

I chose what might be considered a 5th option, a single display file shared by
multiple programs.

Rather than have one large program that handles all display formats, I have a
main program (A) that opens the single display file at startup and this remains
open.  Program A only handles some of the screen formats in the display file
(e.g. those that might be considered "standard", such as headers and trailers).
It has no access to data.

Progam A calls another program (B) that normally handles business logic and
database access.  Most of the business/application  logic is stored in the
database. Programs A & B remain called throughout an operating session.  They
are used by all users for all applications.

Program B calls EXIT programs that handle different display formats but these
are in the same display file.  The DSPF is defined with SHARE(*YES) and
RSTDSP(*YES), so that there is no constant opening and closing of display files.

The name of an exit program to be called at a particular point in an application
can be deduced from the database and the dynamic call uses a variable for the
program name.  Thus new exit programs can be created without changing either of
the main programs (A & B).  The exit programs can be small, with single display
formats, or large with many formats, as suits the developer.

All programs use a standard inter program interface and the same, large,
parameters are passed to all exit programs.

Program A can, if desired, be used to write out standard information (e.g.
headers and trailers) whilst exit programs write data entry screens or
sub-files/lists etc. so that one screen usually has multiple formats written by
two or more programs.  The exit programs can do all screen handling if required
(an option is set in the database relevant to the application and the place -
other values for the same option can be set elsewhere).

Alternatively, using another database option, an exit program can format a
record and pass it back via program B to program A using standard parameters.
Program A can combine it with other data passed by the same or other exit
programs and write out subfiles or lists.  Thus Progam A can handle all display
formats but not update formats. Program A inserts 5250 attributes into the
datastream as required. The "subfile" area of the screen is one field of "n"
lines by 80 columns  (e.g. 800 bytes) and program A can start a new line for
each separate record to be displayed or wrap them dynamically in the space
available, or allow windowing using F19 & F20.  Subfiles are also dynamically
created and there are no DDS subfiles defined.

When a browser is used (hopefully for inquiry only!). program A inserts HTML
(created dynamically) into the datastream.  When a printed report is required,
program A inserts PCL into the datastream.  There is only one printer file, used
by all applications.  Options in the database determine the format of the
report.

As a general rule, data retrieved by program B is passed as a parameter to an
exit program which writes screen formats to allow users to update the data.  The
exit program passes it back to program B which updates the database (without
needing to understand its format).

Alternatively the exit program can do all the database work, and the same, or
another, exit program can display the update formats as the data accessed is
passed via program B using parameters.  Program B does not need to understand
the format of records accessed.

A built in mechanism handles multiple panel displays.  Although these will
appear seamless to users, they may be written, in part or in whole, by different
programs. If screen 1 is written by exit program 1 and screen 2 by exit program
2, no coding is required in either program about the screen(s) written by the
other programs  This mechanism would readily handle your order entry example
(and could be expanded to retrieve price based on customer or market type,
and/or on date, etc.).  Commitment control boundaries are set in the database.

I created this Object0-Oriented architecture in 1980 after reading an IBM
System/38 manual for CPF version 1 that stated that best performance was
achieved with a few large programs and with shared opens of files.

Dynamic calls are very fast.  On a model 4 System /38 the average response time
for all interactive jobs over 12 months was 1.0 seconds.  On a B10 AS/400, the
normal response times, using journalling and commitment control, were about 0.3
seconds.  A B10 is very slow by today's standards.  I often get continuous
response times of under 0.1 seconds on a 150 with only 64MB.

When ILE came along, I spent some time wondering whether I could improve on
this, but after some tests, I decided that I could not.  I was brought up on the
System /360 with "link editing", and thought that the dynamic calls of the
System /38 were a great step forward. I still think this so I have no service
programs (although I know how to write them), no bound calls, etc..

Although this architecture may be unusual (and therefore perhaps not easy to
understand), it is extremely simple.  Programs A & B are together under 3Mb and
two exit programs (which I would suggest) for your Order Entry  example would
together be under 2Mb.  Since there are so few program calls and so few file
opens, disk arms are freed up for handlling user data and performance benefits
as a result.

If I once had problems with displaying formats, this was in the early days of
System /38 and long since cured and forgotten.  I do use PUTOVR etc..

I hope this helps.

Its some months since we were last in touch directly and I hope that all is well
with you.



Best wishes


Rob Dixon

http://www.erros.co.uk


Joe Pluta wrote:

> How would you design a complex multi-panel display?
>
> Let's take, for example, an order entry display.  There's a screen for the
> ship-to information, a screen for notes, a screen for order header
> information, a screen for order detail, a screen for shipment detail.
>
> It seems to me there are a number of possibilities:
>
> 1. One really big display file handles by one really big program
> 2. Separate programs, each with its own display file, run by a driver
> program
> 3. Separate modules, each with its own display file, called using bound
> calls from a driver program
> 4. Separate modules, each with its own display file, in a service program,
> called from a driver program
>
> Option one is bad, for all the reasons we've come to know and hate over the
> years - maintenance, modularity, and so on.  So that leaves the other
> options.  What are the opros and cons of having a display file in a module?
> And what are the tradeoffs between having such a module bound or in a
> service program?
>
> I'm not looking for a definitive "right" answer here; my guess is that "it
> depends".  But I'd like to have a little discussion on the matter.  I guess
> that's becase I'm at option two today, and very comfortable with it, but I
> know that I'd get at least one benefit from a bound approach: fewer objects
> to manage, especially in the production environment.  That goes away a
> little if I move to a service program approach, but then maintenance is a
> bit easier.
>
> So, please, I'd be interested to hear what you think.  Any comments about AG
> usage in this scenario would be appreciated as well.
>
> Joe
>
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.