OVRDBF question

OVRDBF question

Post by Drew Dekreo » Sat, 12 Jul 2003 01:43:35



Can I change an override in a cl and have it affect the calling cl? How?
simplied sample
pgma:
  ovrdbf input tofile(a) mbr(one)
  call pgmb
  ..process file input..
  dltovr input
  end

pgmb:
   ovrdbf input tofile(b) mbr(two)
   end

I thought I needed to use ovrscope(*job) and/or secure(*yes), but it
doesn't seem to work (based on putting a dspovr in pgma).

 
 
 

OVRDBF question

Post by Will » Sat, 12 Jul 2003 10:02:47


share(*yes)


Quote:> Can I change an override in a cl and have it affect the calling cl? How?
> simplied sample
> pgma:
>   ovrdbf input tofile(a) mbr(one)
>   call pgmb
>   ..process file input..
>   dltovr input
>   end

> pgmb:
>    ovrdbf input tofile(b) mbr(two)
>    end

> I thought I needed to use ovrscope(*job) and/or secure(*yes), but it
> doesn't seem to work (based on putting a dspovr in pgma).


 
 
 

OVRDBF question

Post by Ken » Sat, 12 Jul 2003 13:22:57


Hi Drew -

On Thu, 10 Jul 2003 08:43:35 -0800, Drew Dekreon


>Can I change an override in a cl and have it affect the calling cl? How?
>simplied sample
 <snip>
>I thought I needed to use ovrscope(*job) and/or secure(*yes), but it
>doesn't seem to work (based on putting a dspovr in pgma).

There are two ways to accomplish what you want:

1. Put ovrscope(*job) on both overrides.  Then the second override
will totally replace the first override.  In this case if you delete
the second override, there is no override left.

2. Leave pgma as is.  In pgmb do:
   ovrdbf a tofile(b) mbr(two) ovrscope(*job)
   Notice that you override file a to b, not file input to b.
   In this situation both overrides exist.
   If you dltover a lvl(*job), the override for file input
     to file a mbr one will still exist.

Ken
http://www.ke9nr.net/
Opinions expressed are my own and do not necessarily represent the views of my employer or anyone in their right mind.

 
 
 

OVRDBF question

Post by Drew Dekreo » Sun, 13 Jul 2003 02:01:11


Nope, that doesn't seem to work.
I tried share(*yes) in a, but not b, b not a, a & b - none worked.
I even tried all the variations as clle instead of clp. No luck.

> share(*yes)



>>Can I change an override in a cl and have it affect the calling cl? How?
>>simplied sample
>>pgma:
>>  ovrdbf input tofile(a) mbr(one)
>>  call pgmb
>>  ..process file input..
>>  dltovr input
>>  end

>>pgmb:
>>   ovrdbf input tofile(b) mbr(two)
>>   end

>>I thought I needed to use ovrscope(*job) and/or secure(*yes), but it
>>doesn't seem to work (based on putting a dspovr in pgma).

 
 
 

OVRDBF question

Post by Will » Sun, 13 Jul 2003 03:10:48


sorry Drew - I completely misunderstood the question. Think Ken got the
answer you're looking for.

cheers


> Nope, that doesn't seem to work.
> I tried share(*yes) in a, but not b, b not a, a & b - none worked.
> I even tried all the variations as clle instead of clp. No luck.


> > share(*yes)



> >>Can I change an override in a cl and have it affect the calling cl? How?
> >>simplied sample
> >>pgma:
> >>  ovrdbf input tofile(a) mbr(one)
> >>  call pgmb
> >>  ..process file input..
> >>  dltovr input
> >>  end

> >>pgmb:
> >>   ovrdbf input tofile(b) mbr(two)
> >>   end

> >>I thought I needed to use ovrscope(*job) and/or secure(*yes), but it
> >>doesn't seem to work (based on putting a dspovr in pgma).

 
 
 

OVRDBF question

Post by Drew Dekreo » Sun, 13 Jul 2003 03:18:51


Good stuff:
ovrscope(*job) works, but it requires modifying the dltovr in pgma to
lvl(*job), or I end up with an ovrdbf active after pgma ends. I also
have to modify all the pgma's to have their initial ovrdbf input to
specify ovrscope(), and I was hoping for a clean, single-line modification.

I'm interested in the second alternative - but there's a problem: in
order for it to work, I need to know what file INPUT is pointing to (I
think the Retrieve File Override Information (QDMRTVFO) API will give me
that information) and set an override on it. This means that when the
program finishes, I'll have a *job scope override outstanding for the
file that INPUT was originally overridden to. So, in pgma I'll have an
apparently inexplicable dltovr file(a) lvl(*job), with no ovrdbf
referring to (a) previously..


> Hi Drew -

> On Thu, 10 Jul 2003 08:43:35 -0800, Drew Dekreon

>>Can I change an override in a cl and have it affect the calling cl? How?
>>simplied sample

>  <snip>

>>I thought I needed to use ovrscope(*job) and/or secure(*yes), but it
>>doesn't seem to work (based on putting a dspovr in pgma).

> There are two ways to accomplish what you want:

> 1. Put ovrscope(*job) on both overrides.  Then the second override
> will totally replace the first override.  In this case if you delete
> the second override, there is no override left.

> 2. Leave pgma as is.  In pgmb do:
>    ovrdbf a tofile(b) mbr(two) ovrscope(*job)
>    Notice that you override file a to b, not file input to b.
>    In this situation both overrides exist.
>    If you dltover a lvl(*job), the override for file input
>      to file a mbr one will still exist.

> Ken
> http://www.ke9nr.net/
> Opinions expressed are my own and do not necessarily represent the views of my employer or anyone in their right mind.

 
 
 

OVRDBF question

Post by Ken » Sun, 13 Jul 2003 05:41:57


Hi Drew -

On Fri, 11 Jul 2003 10:18:51 -0800, Drew Dekreon


>I'm interested in the second alternative - but there's a problem: in
>order for it to work, I need to know what file INPUT is pointing to (I
>think the Retrieve File Override Information (QDMRTVFO) API will give me
>that information) and set an override on it. This means that when the
>program finishes, I'll have a *job scope override outstanding for the
>file that INPUT was originally overridden to. So, in pgma I'll have an
>apparently inexplicable dltovr file(a) lvl(*job), with no ovrdbf
>referring to (a) previously..

You could have two calls to pgmb, one to create the job level override
and another to delete it.  pgma could pass in the name of the file
that is overriding to.

But ...
I guess my main question is, why are you doing this at all?
Why can't pgma just issue the proper override?
If pgma doesn't know what file and member, why can't pgma call pgmb
and pgmb just pass back the names for pgma to issue the proper
override?

Ken
http://www.ke9nr.net/
Opinions expressed are my own and do not necessarily represent the views of my employer or anyone in their right mind.

 
 
 

OVRDBF question

Post by Drew Dekreo » Sun, 13 Jul 2003 08:24:45


Well, this is all related to ftp:
we have scripted, batch ftp processes that transfer files. The problem
is that some of them require the result file to be named yymm.txt or
<somestring>yy.txt.
I create a command and some programs to duplicate the script,


Our generic cl has ovrdbfs for input & output, runs ftp, then calls a
program to evaluate the output & sets an error. I wanted to be able to
just plop this script markup command into the middle of the existing cl,
just after the ovr for input & before the ftp command.
This requires changing the target of INPUT.
Using *job on INPUT basically finishes it up so it works.. it just
doesn't look as clean as I'd prefer.

> Hi Drew -

> On Fri, 11 Jul 2003 10:18:51 -0800, Drew Dekreon

>>I'm interested in the second alternative - but there's a problem: in
>>order for it to work, I need to know what file INPUT is pointing to (I
>>think the Retrieve File Override Information (QDMRTVFO) API will give me
>>that information) and set an override on it. This means that when the
>>program finishes, I'll have a *job scope override outstanding for the
>>file that INPUT was originally overridden to. So, in pgma I'll have an
>>apparently inexplicable dltovr file(a) lvl(*job), with no ovrdbf
>>referring to (a) previously..

> You could have two calls to pgmb, one to create the job level override
> and another to delete it.  pgma could pass in the name of the file
> that is overriding to.

> But ...
> I guess my main question is, why are you doing this at all?
> Why can't pgma just issue the proper override?
> If pgma doesn't know what file and member, why can't pgma call pgmb
> and pgmb just pass back the names for pgma to issue the proper
> override?

> Ken
> http://www.ke9nr.net/
> Opinions expressed are my own and do not necessarily represent the views of my employer or anyone in their right mind.

 
 
 

OVRDBF question

Post by Ken » Sun, 13 Jul 2003 10:56:10


Hi Drew -

On Fri, 11 Jul 2003 15:24:45 -0800, Drew Dekreon


>Our generic cl has ovrdbfs for input & output, runs ftp, then calls a
>program to evaluate the output & sets an error. I wanted to be able to
>just plop this script markup command into the middle of the existing cl,
>just after the ovr for input & before the ftp command.
>This requires changing the target of INPUT.

I do a similiar thing with FTP, but I don't use your method.

I copy the specified script to a file in QTEMP that always has the
same file and member name, then do whatever needs to be done to that
copy, then override INPUT to that copy.  It totally avoids the kind of
problems that you are encountering.

Ken
http://www.ke9nr.net/
Opinions expressed are my own and do not necessarily represent the views of my employer or anyone in their right mind.

 
 
 

OVRDBF question

Post by Drew Dekreo » Wed, 16 Jul 2003 08:13:21


We already have scripts for most of our ftp work, so I was trying to get
a simple retrofit going.
Actually, it works pretty well. Besides add the new ftpscript command,
only the ovrdbf/dltovr for file input has to be modified to include *job.
We're going to try some testing this week..

> Hi Drew -

> On Fri, 11 Jul 2003 15:24:45 -0800, Drew Dekreon

>>Our generic cl has ovrdbfs for input & output, runs ftp, then calls a
>>program to evaluate the output & sets an error. I wanted to be able to
>>just plop this script markup command into the middle of the existing cl,
>>just after the ovr for input & before the ftp command.
>>This requires changing the target of INPUT.

> I do a similiar thing with FTP, but I don't use your method.

> I copy the specified script to a file in QTEMP that always has the
> same file and member name, then do whatever needs to be done to that
> copy, then override INPUT to that copy.  It totally avoids the kind of
> problems that you are encountering.

> Ken
> http://www.ke9nr.net/
> Opinions expressed are my own and do not necessarily represent the views of my employer or anyone in their right mind.

 
 
 

1. ovrdbf question

Hello all,

I have been reading in the groups about the various problems with
performance and files on the 400.

I have not been able to find anything specific so here is my post. I
have a client who is experiancing performance degradation.

One of the programs I was looking into is called from a CL, prior to
this call a OVRDBF with (*yes) is specified for the mainfile in this
RPG program. The RPG program is a subfile and when pageup or pagedown
are pressed, the system kind of stalls. Now the file being accessed
has 3 logicals built over it.

The program dynamically depending on the function key pressed
overrides the same logical that was overridden to share *no or share
*yes depending on the condition.

I believe this to be the cause of the performance problems but am not
sure. Why would anyone want to ovrdbf *no?

Thanks in advance.
Rob

2. FAQ: Sendmail 8.8.x / 8.9.x Anti-Relay

3. OVRDBF and DSPFD question

4. Database Connectivity

5. OVRDBF to override the output file

6. NAT using modem

7. Accessing different members in SQL/400 without OVRDBF

8. Rescue!

9. SQL Triggers and OVRDBF SHARE(*YES) (SE07594)

10. Sequential Record Blocking on OVRDBF command

11. NBRRCDS or SEQONLY in OVRDBF?

12. Reading LF within RPG with OVRDBF

13. OVRDBF