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



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.


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.