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



Blake,

I never bother with USROPN or closing files in a module. If I truly
need to ensure that files get closed, then I'd reclaim the activation
group. Otherwise, for performance reasons, just leave the files open.
ILE gives you the option to do just as you suggest, but I don't see the
need to take on all the overhead... Judicious use of ACTGRP(*NEW) with
service programs as *CALLER allows you to ensure that these service
programs do not leave resources tied up, but either way, it's just
another standards choice.

JMO,
-Eric DeLong

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Blake.Moorcroft@xxxxxxxxxx
Sent: Monday, July 12, 2010 3:28 PM
To: Midrange Systems Technical Discussion
Subject: Re: Service program - file usage and closure

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.

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.