Re: RPG Display program and processing

[Anton Gombkötö <Gombkoetoe@xxxxxxxxxx>]

You're welcome!

You could avoid the second CL by USROPN the printer file and issue the 
OVRPRTF prior to opening the printer file by means of QCMDEXC.

The pain isn't as big when you know that the default length for numeric 
parameter passing is packed 15,5! Maybe you did a typo, but you wrote 15,2 
in your mail!

So a

SBMJOB (CALL PGM(RPG) PARM(4711 4712))

works if you have a program like this

H
FQSYSPRT   O    F  132        PRINTER
D NumParm1        S             15P 5
D NumParm2        S             15P 5
C     *ENTRY        PLIST
C                   PARM                    NumParm1
C                   PARM                    NumParm2
C                   EXCEPT
C                   EVAL      *INLR = *ON
OQSYSPRT   E
O                       NumParm1      J
O                       NumParm2      J

(you can copy & paste this code, i tried it! :-)

0000000000.02000 Euro  :-)




At 08:05 25.07.00 -0700, you wrote:
>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
>+---

Mit freundlichen Grüssen / Best regards

Anton Gombkötö
mailto:Gombkoetoe@ASsoft.com

AS Software GmbH
http://www.assoft.com

Jedleseer Strasse 3
A-1210  Wien

Tel: +43 1 278 15 01-0
Fax:+43 1 278 15 01-22

+---
| 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
+---