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


  • Subject: Re: Submit Job with OVRPRTF
  • From: Scott Klement <klemscot@xxxxxxxxxxxx>
  • Date: Wed, 14 Jun 2000 00:37:25 -0500 (CDT)


Hi there,

On Tue, 13 Jun 2000, hartawan reksodiputro wrote:

> Hello everybody,
> 
> I have a CL that will submit a call to RPG program. But before that I need 
> to override the PRTF. The problem is that the result is not effected by the 
> OVRPRTF, but when I try to change SBMJOB to just CALL interactively it 
> worked. Then I use OVRSCOPE(*JOB) for the OVRPRTF command, still the same 
> result. Any suggestions?

The Submit Job (SBMJOB) command creates a completely new job on the
system.  Overrides from one job can't affect overrides in a  different
job.  (And rightly so!  I'd be a HUGE mess not to mention a terrible
security risk to allow one job to set overrides for another job...
debugging would be nearly impossible!)

> I try to put the OVRPRTF inside the RPG program, I got the same result.

This sounds like its a step in the right direction.  The trick to doing an
override within the RPG program, however, is to make sure that your print
file is "USROPN" ("or UC if you're using Antique RPG")

Something like this:

FMYPRINT   O    E             PRINTER USROPN

D Cmd             PR                  ExtPgm('QCMDEXC')
D   Command                    200A   Const
D   Length                      15P 5 Const

C                   callp     Cmd('OVRPRTF FILE(MYPRINT) DEV(PRT01)' +
C                             ' SECURE(*YES) OVRSCOPE(*ACTGRPDFN)':200)

c                   open      MYPRINT

     .......  rest of program goes here  ........

c                   close     MYPRINT

c                   callp     Cmd('DLTOVR FILE(MYPRINT)':200)



Another (less elegant, in my opinion) method of doing this would be to
make the CL program act differently if its running in batch vs. running
interactively.  The interactive portion would handle everything up to the
SBMJOB, and the batch portion would handle everything afterwards.

PGM                     PARM(&PARM1 &PARM2)

             DCL        VAR(&JOBTYPE) TYPE(*CHAR) LEN(1)
             DCL        VAR(&PARM1) TYPE(*CHAR) LEN(10)
             DCL        VAR(&PARM2) TYPE(*CHAR) LEN(10)
             /* PLUS WHATEVER ELSE WE NEED TO DECLARE */

             RTVJOBA    TYPE(&JOBTYPE)




/* THIS HAPPENS WHEN THIS PROGRAM IS RUN INTERACTIVELY:      */

             IF (&JOBTYPE *EQ '1') DO

                  /* DO WHATEVER ELSE WE NEED TO DO INTERACTIVELY,   +
                       HERE...                                      */

                  /* replace "SELF" with whatever this pgm is called */
                  SBMJOB CMD(CALL PGM(SELF) PARM(&PARM1 &PARM2)) +
                          JOBQ(QBATCH)
                  RETURN

             ENDDO



/* THIS HAPPENS WHEN THIS PROGRAM IS RUNNING IN BATCH:       */

             OVRPRTF FILE(MYPRINT) DEV(&PARM1) SECURE(*YES) +
                     OVRSCOPE(*ACTGRPDFN)

             CALL       PGM(MYRPGPGM) PARM(&PARM2)

             DLTOVR FILE(MYPRINT)

ENDPGM


Of course, this assumes that the CL program is running in the same
activation group as the RPG...  if it is not, you may have to tweak it
appropriately.   This wont be a problem when the override is in the 
RPG (its always running in the same activation group as itself...)

Hope That Helps!


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

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.