|
midrange.com
Here's something to chew on...
Does USROPN affect blocking?
Rob Berendt
==================
Remember the Cole!
"Mike Silvers"
<msilvers@hbs-inc To: <RPG400-L@midrange.com>
.com> cc:
Sent by: Subject: Re: Variable file
name in rpg /or cl
owner-rpg400-l@mi
drange.com
10/13/00 01:45 PM
Please respond to
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
+---
+---
| 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 mailing list archive is Copyright 1997-2025 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.
