Re: RPG Display program and processing

Hmm... Okay, very good point.  This is the method I will use in the future,
then, and in fact have used on this one.

The final application has 2 CLs, 1 Display file and one RPG.  The initial
CL calls the display file and checks for F3 or F12.  If not F3 or F12 it
SBMJOB's the second CL.  The Second CL does an OVRPRTF and
calls the RPG program (which is why I needed 2 CLs and not just one).

The one pain is the first CL converts the two numeric fields to alpha and
then passes them to the second CL.  The second CL passes the numbers
as characters, as there's the imfamous 15,2 problem with passing numbers
between CL and RPG.  All in all, though, I like the solution and is one I
have done in the past.  If we later decide on a different interface (HTTP,
Client/Server, whatever) all we need to do is change the first CL which is
a very small program.

Thanks for all the tips.

Regards,

Jim Langston

Anton Gombkötö wrote:

> Jim,
>
> of course you could open the display file only when in interactive mode.
>
> But that's becoming an old fashioned method *now*.
>
> You should separate the user interface (your display with the parameters)
> and the processing (your report).
>
> Later on you might want to implement e.g. a web interface for your report,
> then you'll leave the report as it is and just write a second program to
> call the report.
>
> Breaking up a big problem into smaller ones has some other advantages, too.

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---