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


  • Subject: Re: closing shared files
  • From: "James W. Kilgore" <qappdsn@xxxxxxxxxxxxx>
  • Date: Tue, 17 Oct 2000 21:36:47 -0700
  • Organization: Progressive Data Systems, Inc.

Len,

This has to be one of the most perverse concepts ever contrived!

IMHO, do a CHGPF and change the file to SHARE(*YES) and run a CL program at sign
on that does a full open on each file.  That way even if the program returns 
with
LR on, you still have a full shared ODP.  ILE activation groups may need
additional work.

The alternative is to change the FOP to test the file feedback for an ODP and if
none, do a full open and forget this array value, prone to error, bogus flag.

Len Lester wrote:

> I'm having a problem with shared open data paths...
>
> The company standard is SHARE(*YES) on all files.  Most programs do not
> SETON *INLR when ending.  There is a file opener program (FOP) by which
> programs are called.  The program to be run is a parameter to the FOP.
>
> There is a database of programs and files which contains the files used by a
> program and the programs called by a program.  Each file and program has a
> number betweeen 1 and 9999.  The FOP contains two size 9999 by 1 byte arrays
> for programs and files.  When a file or program is opened, it's byte is set
> to 'X' in the array so a second open is not attempted.
>
> When the FOP is called it will open all files for the program and any
> programs called by the program and so on and then call the program.  The
> files are all opened for *ALL (IOUD) by the opener.  So if program A uses
> file F as input only and then calls program B to update file F, the file is
> open for update and program B will work.
>
> Most programs can call an inquiry.  Files used by the inquiries are not
> opened by the FOP before it calls the program.  However, the inquiry
> programs are called using the FOP. So, in program B above, if the user wants
> his inquiry program C, the files it uses are opened for *ALL by the FOP.
> The user may return to the menu and select an option to update one of the
> files the inquiry program used.  That file will already be open for *ALL so
> the update can take place.
>
> THE PROBLEM is with a program which sets on LR.  When this program ends, any
> files opened by the inquiry process are closed.  The tables in the FOP are
> not changed so it doesn't attempt to open these files again.  If these files
> are opened, they are opened by the application programs and may be input
> only.  If an update is later attempted, it will bomb.
>
> MY QUESTIONS are:
> A.  Is this new?  Program FOP opens files and calles program A which calls
> program B which calls FOP which opens more files and calls program C.  Then
> these program end.  Program A ends with LR *ON.  The files opened by the
> second invocation of FOP or by program C are closed.  I don't think it used
> to be this way.
>
> B. Is there a way to keep those files open?
>

+---
| 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 thread ...

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.