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



Interesting.
Buck I tried one more time and I noticed that one of the spooled files (the
one I need to get held of!) was moved under user QTMHHTTP and others are
still under QTMHHTP1!

My code now flows like this:

RPG/CGI
CL1 (OVRPRTF SPLFOWN(*JOB),   CALL CL2,  DLTOVR(*PRTF) )
CL2/RPG
CL3/RPG
…
CLn (there is OVRPRTF too)
RPG (here we generate reports)

I think reports that are still under QTMHHTP1 have OVRPRTF with
SECURE(*YES).
I think I will have to read May issue of NEWS/400, as suggested by Gary
Guthrie.


Bruce

-----Original Message-----
From: Buck Calabro <Buck.Calabro@commsoft.net>
To: RPG400-L@midrange.com <RPG400-L@midrange.com>
Date: Thursday, April 26, 2001 1:07 PM
Subject: RE: RTVJOBA in CGI question


>Bruce, I'm not sure I understand.  OVRPRTF works from the inside out.
>
>RPG 1
>  OVRPRTF SPLFOWN(*YES)
>  CLP 1
>    OVRPRTF FORMTYPE(INVOICE)
>    RPG 2
>      Print invoice - This will have FORMTYPE(INVOICE) SPLFOWN(*JOB)
>
>The innermost override (CLP 1) is superceded (overriden by) the one in
RPG1.
>This pertains to overrides issued in the same job.  Overrides in job A
never
>affect any other jobs, so
>
>RPG 1
>  OVRPRTF SPLFOWN(*YES)
>  SBMJOB CLP 1
>    OVRPRTF FORMTYPE(INVOICE)
>    RPG 2
>      Print invoice - This will have FORMTYPE(INVOICE) only
>
>RPG 1 runs in JOB A, whilst CLP 1 and RPG 2 run in job B because of the
>SBMJOB.
>
>Overrides are designed specifically this way, so that you can modify the
>inner CL's behaviour without changing the CL program.
>
>I hope that helps some.
>
>Buck
>
>> -----Original Message-----
>> From: Bruce Jin
>> Sent: Thursday, April 26, 2001 11:42 AM
>> To: RPG400-L@midrange.com
>> Subject: Re: RTVJOBA in CGI question
>>
>> Thanks Buck for the info.
>> It looks like OVRPRTF is not cumulative and I can't use OVRPRTF before I
>> call the CL that generates the report. I have to think about something to
>> change the report CL directly without impacting its normal function.
>>
>> Bruce
>+---
>| 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
>+---

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


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.