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



Joe,

In our shop we had the same problem when we started moving from subprograms
to service programs. Since we cannot redo all our programs at once, the
service programs must be able detect whether the file as already been opened
in the activation group by a program lower on the call stack. If it has, the
service program cannot close it or it will be closed to all the programs in
the activation group. We stumbled across this technique:
1. set all files in the service program module(s) to USROPN.
2. If %OPEN reports the file as open, use the file as if the module had
opened it.
3. If %OPEN reports the file as closed:
   a. Open the file;
   b. Set a locally defined named indicator *ON (perhaps CloseXxxxxx);
   c. When the subprocedure is done with the file, check the indicator;
   d. Only close the file if the indicator is on.

It would be better to control the opening of the file in other programs in
the activation group, but we do not have the resources to do that right now.
This has worked for us in our mixed-style environment.

HTH,
Roger Mackie

-----Original Message-----
From: Joe Pluta [mailto:joepluta@PlutaBrothers.com]
Sent: Monday, October 14, 2002 14:10
To: rpg400-l@midrange.com
Subject: RE: Procedures are FUN!

<SNIP>
I started out by getting "File already open or in error"
(CPF4132) in the *INIT of the subprogram.  Next, I tried making the files
USROPN, and opening them once in the subprocedure based on a static
variable.  Still errors in the subprogram call.  I finally went so far as to
check to see if the file was open using the %open BIF, and then if not
attempting to open the file, but when I come through the mainline, I get
CPF4132.

<SNIP>


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.