Re: Alternate UI to RPG

[Dan <dan27649@xxxxxxxxx>]

I've done this a handful of times, including once just recently.  In my
recent case, it was a dreadful, monolithic, heavily modified monstrosity
for which no one could reverse engineer into a working specification.  You
know, because the original specs were long gone or perhaps never even
existed, but it was universally understood that the program works as
"expected".  In our case, I cloned the original program source, made the
display file USROPN, and put the OPEN, EXFMT, READ, WRITE for all of the
display file's record formats in a subroutine that is never called, which
allowed all of the field definitions from the display file to be defined in
the program, and commented out all of the OPEN, EXFMT, READ, WRITE ops
related to the display file in the working logic.

I created a clone instead of modifying the original program because I was
told that we didn't have enough time to do regression testing on the
interactive part of it.  (Yeah, but apparently, we have plenty of time to
spend twice as much time making a logic modification in the future.  Like,
when pigs fly.)

It's a quick and dirty method but, honestly, the "quick" probably doesn't
happen until you've got a few iterations of this under your belt.

If the source code could have been refactored into a specification document
within a reasonable timeframe, I would have advocated for a refactoring
that would separate the UI and move the business logic into a service
program.

- Dan

On Wed, Oct 3, 2018 at 3:13 PM Richard Schoen <
Richard.Schoen@xxxxxxxxxxxxxxx> wrote:

> I don't do a lot of re-purposing of 5250 specific apps, but I have an
> interesting option you could consider depending on complexity.
>
> I did this once as an example for a customer on re-purposing an existing
> display file app without carving out the logic into a separate program.
>
> Take your existing 5250 interactive app and change it to pass parms in and
> out of it. One controlling parm would be B/I for batch-web or interactive.
>
> In the case of the (I)nteractive parm, assume running from interactive
> 5250 session and use standard display file logic.
>
> In the case of the (B)atch-web parm, use the parms to drive input to the
> program and possibly output of return data as well. In this case you would
> make the open and write format statements conditioned so they only happen
> when "I" is passed.
>
> Now you have a program that can be called like a logic module or used as a
> 5250 interactive program without having to carve the logic into a second
> program.
>
> You just add a little complexity to the display file and parm handling.
>
> Just an idea if you don't want to maintain logic in 2 places, although
> there are always service programs or copy books for that part of it.