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
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
> Opinions expressed are my own and do not necessarily represent the views of my employer or anyone in their right mind.