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



The question you will need to look at is whether you want to open and close
the file every time that you call the service program. There are three
strategies I can think of.

1. Open and Close every time. This works but is expensive.
2. Add logic that says If Not %Open(<Table Name>) and open if not. Then code
another subprocedure to call at the end to close the files.
3. Use SQL to access the tables. Code the modules to use CLOSQLCSR(*ENDMOD).
SQL has a lazy load feature. When you close the cursor, it leaves the tabler
open. If you leave the module with *ENDMOD then the table is still open but
if anything needs it it will release it. I think this is the optimal for
service program. Always access tables via SQL and let the OS manage the
table.

MOO.


On Mon, Jul 12, 2010 at 2:27 PM, <Blake.Moorcroft@xxxxxxxxxx> wrote:

Hello Charles...

So if I'm reading your comments correctly, we should be able to deal with
developer concerns by ensuring that files opened in the service program
are always under programmer control for open and close (make it a
development policy) and that will take care of the issue that was brought
up. Files currently are not constructed with SHARE(*YES).

Have a good day.


Blake Moorcroft
Developer - Corporate
Russell A. Farrow Limited
1980 Ambassador Drive, PO Box 333, Windsor, Ontario N9C 3R4
Bus: 519-966-3003 ext. 566, Fax: 519-966-9870
blake.moorcroft@xxxxxxxxxx




Charles Wilt <charles.wilt@xxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
07/12/2010 04:01 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: Service program - file usage and closure






One correction:

A file without USROPN in a service program will be implicitly opened
when the first procedure in the module is called. It will not be
implicitly closed until the activation group ends. *LR has no effect
on files used by modules of a service program.

Unless the files is defined or overridden with SHARE(*YES) each
module, irregardless of rather the module is in a *PGM or a *SRVPGM,
will have it's own open data path.

HTH,
Charles


On Mon, Jul 12, 2010 at 3:16 PM, <Blake.Moorcroft@xxxxxxxxxx> wrote:
Hello all...

We're trying to put together a set of procedures to be called as service
programs for the first time and as would be expected, we've got our
first
quandry.

My understanding of service programs (and please correct me if I'm
wrong),
is that because the modules have the "nomain" option, that files that
are
originally opened when the procedure is called must be subsequently
closed, either by the "close" command or the LR indicator and that if
this
is not done then the file can be opened repeatedly each time the
procedure
is called.

The question that has arisen is that in one case a program is being
adjusted to use a service program. This service program, for examples
sake, will open File A and retrieve some company reference data and pass
it back to the program that wanted it. The service program is used in a
number of different programs, but one of these programs also calls File
A
for different reasons and does not have any kind of programmer
controlled
open or close logic on it - the file opens when the program starts and
closes when it ends (LR=*on). The developer is asking what would happen
if the service program, which has opened File A, then forces a file
close.
My assumption is that it would only close the file instance that the
procedure opened, and not file instance that was originally opened in
the
calling program.

Any help would be appreciated.

Have a good day.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.




This electronic message contains information from Russell A. Farrow
Limited, Russell A. Farrow (U.S.) Inc., canadaplus.com or RAF Express
Inc., that may be confidential or privileged. The information in this
electronic message is only for the use of the intended recipient.
Inappropriate disclosure, copying, distribution or other use of the
contents of this electronic message is strictly prohibited. If you have
received this electronic transmission in error, please notify the sender
immediately by return e-mail. Thank you.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



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.