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



Chuck,

The only reason that I noticed that the file was open, even though all
programs had ended, was because I was trying to replace it for another test.
That might be the only time when leaving it open would be an issue?

Maybe just habit, but I usually define my program-defined files with USROPN
and make sure at the end of the program that these files are closed. Kind
of weird because, when I wrote Cobol eons ago, I used to hate having to Open
and Close my own files. .-)

Jerry C. Adams
IBM i Programmer/Analyst
No good deed shall go unpunished. -Dorothy Parker
--
A&K Wholesale
Murfreesboro, TN
615-867-5070


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of CRPence
Sent: Tuesday, May 01, 2012 6:57 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: File Still Open

On 30 Apr 2012 09:19, Jerry C. Adams wrote:
First, V5R1.

I have an SQLRPGLE program that uses embedded SQL to update multiple
records (potentially, anyway) in a master file. I build a string based
upon the user's options and then use EXECUTE IMMEDIATE :sqlstring.
The master file is referenced only in the sqlstring; i.e., it is not
defined in the F-specs. The string is:
UPDATE TSTQS36F/"A.IVMAST"
SET impidx = 'X ' , imprcd = ' '
WHERE impidx = 'CONW' AND imprcd = ' '

I never noticed before that, when the program ends, the master file is
still open when I run DSPJOB option 14. Is this normal, some keyword I
need to add to the UPDATE string, or something else to be sure the
file is closed?


The feature of the database SQL called "parameter marker conversion"
can make that statement reusable, for which a pseudo-closed cursor may be
the effect. If the effectively identical statement [only difference being
the literals] was performed more than once, then the second time the
statement\file was only pseudo-closed to reduce the overhead for the
presumed-to-occur next open; i.e. the effect would be normal. So instead of
asking how to make sure the file is closed, consider instead [of trying to
defeat this attempt by the SQL to improve the performance of the next open],
just why would the file _need_ to be closed? Is there some problem that is
caused by the file being left in that manner?
To be clear, an actual problem, not merely perceived; as in, not just
because a file is left open after calling this other function\program, where
in this case, the SQL is the other function\program. That is to suggest, if
there are no problems that arise from the file being left open, then is
there really any need to ensure the file is closed.

Regards, Chuck
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-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.