Re: Variable file name in rpg /or cl -- RPG400-L

Another plus, one that might be significant to a smaller shop with a small
or older machine, for the USROPN option is that you can control the opening
of a file.  There is alot of overhead involved with the opening and closing
of a file.  You can look at the conditions and if it is not needed at that
time, there will be no file overhead if you do not open it...


----- Original Message -----
From: Jim Langston <jimlangston@conexfreight.com>
To: <RPG400-L@midrange.com>
Sent: Friday, October 13, 2000 1:14 PM
Subject: Re: Variable file name in rpg /or cl


> This is a good question, and one I have contemplated myself.  Why do an
> override in CL instead of using USROPN in an RPG program?  There are a
> few reasons I can think of.
>
> 1. Easier to maintain.  Easier to find the CL program and see the OVRDBF
and change it
>    then to find the same thing in an RPG program (finding the USROPN,
tracking the
>    point in the program where the OPEN opcode is used, finding out where
QCMDEXC
>    is called and then finding out what parameters are passed, then finding
out where
>    the variable is set, and if the variable is being passed, finding out
where it is
>    being passed from, etc..  A lot faster in CL to find the OVRDBF and
then finding
>    the variable if used and where it's set or passed.
>
> 2. Segregation of logic.  Now I have a CL calling the RPG.  If I decide
for test
>    purposes, or a different company or subdivision, to use a different
file set, I can
>    change the CL program and still have it call the RPG program.  I am
separating
>    Input from Program logic.  If I do it in the RPG I will have to either
copy the
>    program, then have 2 programs to maintain much harder than maintaining
2 CLs,
>    or change the program logic to reflect 2 possible sets of files.
>
> Okay, there are also reasons I can think to use USROPN instead of CL.
>
> 1. Integration of system.  Use the USROPN and CALL QCMDEXC but move the
QCMDEXC into
>    a directory.  Have the directory look at the logic as to which set of
files to open
>    from however it wants to, it is now transparent to the RPG program
(just as the CL
>    then RPG was).  Again, easier to maintain as now I don't have to worry
at all in the
>    RPG program which set of files I am opening, I just have to work on the
program logic.
>    The library can be as complicated or simple as I need and desire.  In
fact, it now
>    becomes a simple matter ot give the RPG program to a junior programmer
to maintain, and
>    have the programmer/analyst maintain the library in all its complexity.
>
> 2. Less overhead and files to maintain.  Now I just have the RPG program
to maintain, and
>    now 2 or more separate files.  Using either method I should be using a
binding directory
>    anyway, so that doesn't really become an issue.
>
> In conclusion, in a smaller shop, or maintaining an older system, or stand
alone programs,
> I would use the OVRDBF in CL.  In a new package or rewriting a system, use
the USROPN and
> move the which file logic to the binding directory (okay, what is the
official term for a set
> of programs put into a directory to be linked at run time?  On PCs this
would be a Library.).
>
> Just my $0.02.
>
> Regards,
>
> Jim Langston
>
> A smart man learns from his own mistakes.  A wise man learns from the
mistakes of others.
>
> rob@dekko.com wrote:
> >
> > Lots of good suggestions pouring in on this.  I go with the OVRDBF.  My
> > only suggestion is why write two programs - an RPG and a CL?  Use the
> > USROPN keyword on your F spec.  Use CALL QCMDEXC, (or the alternatives),
to
> > OVRDBF the file from within the RPG program.  Then use the OPEN opcode
to
> > open the file.  When you are done, use the CLOSE op code.  I've really
cut
> > back on CL.  In fact if you use the alternatives to QCMDEXC you get the
> > error return code.  Which I think is easier to handle than a MONMSG.
> >
> > For example, which is more thorough:
> > MONMSG CPF000 GOTO(ERROR)
> > GOTO NOERROR:
> > ERROR:  /* Find out which error code we actually got and then process
> > accordingly */
> >
> > - or -
> > eval    error=runthis(cmd)
> > Select
> > when error=*blanks
> > when error='CPF....'
> > ...
> > when error='CPF,,,,'
> > ...
> > other
> > ....
> > endsl
> >
> >
> >                     Quazy
> >                     <quazy@SoftHome.n        To:
rpg400-l@midrange.com
> >                     et>                      cc:
> >                     Sent by:                 Subject:     Variable file
name in rpg /or cl
> >                     owner-rpg400-l@mi
> >                     drange.com
> >
> >
> >                     10/13/00 09:18 AM
> >                     Please respond to
> >                     RPG400-L
> >
> >
> >
> > I need to have a cl program pass a variable to either a rpg or cl
program.
> >
> > This variable is the file name that the program needs to read from.
> >
> > Any suggestions on how to do this???
> >
> > Thanks
> >
> > Chris
> +---
> | 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
+---