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



Thanks for all your help.

What if 2 procs in the same service pgm use the same file. If both of the
procs are invoked by the calling pgm, will the 2nd proc recognize that the
common file was already opened by the 1st (if %open)? If so, won't there
be a problem if the 2nd proc closes that file while the 1st, thinking it's
open, tries to access it again? The net of it is, I guess, are the file
opens scoped to the module (*srvpgm) or to the interior procs that opened
them?

Arthur J. Marino
Southern Container Corporation
(631) 297 - 2276



"Murphy, Mark" <MurphyM@xxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
03/19/2008 03:05 PM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
"RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
cc

Subject
RE: RPG-ILE Service Pgm and Opening/Closing Files






I think you are a little confused. A procedure can only use a file
definition from it's own module.
So if program A opens file A, then calls proc B which resides in some
service program, proc B cannot
access file A unless it first opens file A for itself, or its module.

File opens in service programs are a bit strange. If you code a bunch of
F specs in a module without
UsrOpn, and bind that module into a service program. The first proc you
call in that module will open
all the files defined to the module. If you have three procedures in
different modules, all accessing
the same file (you will have the same F spec in each module), then if you
call each of those three
procs in turn, and look at your file opens, you will have three opens for
the same file.

I like to group my database IO functions in modules based on the file they
are accessing. For
example, all of my data IO for file A will reside in one module. That way
I only ever get one open
for file A. I am not rigorous about this though. Functions for
processing through a group of records
can loose their proper state when placed in the same module with other
functions accessing the same
file, so I tend to put these in a module by themselves.

I also like to control my opens and closes for these things, so I will
usually code the F specs with
UsrOpn, and use %open() to decide whether to open a file when a procedure
needs it. I also typically
code a CloseFiles() proc to close all open files in the module. This must
be coded for each module.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of
Arthur.Marino@xxxxxxxxxxxxxxxx
Sent: Wednesday, March 19, 2008 2:45 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: RPG-ILE Service Pgm and Opening/Closing Files

I thought I was properly taking care of opening and closing files in my
service programs by using a globally-defined flag to record whether the
service program needed to open a given file. Then, when the service pgm
proc was invoked at end-of-job in the main program, it would close only
those files that it had opened (not any that were already open when it was

initially invoked).

Today, I was testing a program that opened a file before the service pgm
proc was initially invoked. In debug, I was surprised to see that the proc

decided that this file was NOT open, so it opened it. When I looked at my
job's open files, I saw the open file twice. And both were in the same
Activation Group (QILE).

Since I'm apparently wrong about file opens/closes in a service program,
can someone enlighten me? Thank you.

Arthur J. Marino
Southern Container Corporation
(631) 297 - 2276

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.