× 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 file in question is accessed via SQL exclusively,
That's the reason! Ending a program with *INLR will only close files
accessed with native I/O.
SQL tries to keep the ODP open as long as possible, since a FULL OPEN is
10-20 times more time consuming than a PSEUDO OPEN (where only the data in
the ODP is refreshed).
When compiling your program with the option CLOSQLCSR = *ENDMOD
(alternatively you can include a SET OPTION statement in your source code)
then all ODPs get deleted when the program/module is ended.
Next time you'll call the program again a FULL OPEN must be performed for
each SQL Statement.
When compiling your program with the option CLOSQLCSR = *ENDACTGRP (which is
the default) the ODPs (if reusable) stay open until the activation group in
which the program runs is reclaimed.
So a FULL OPEN for each SQL Statement has only to be performed the at the
first call otherwise a PSEUDO OPEN is performed (which is as said before
much faster).
When running the program in its own activation group it might be better to
reclaim the activation group when needed, instead of performing FULL OPENS
with each program call.

It is up to you to decide what you want. Getting the files closed (ODPs
deleted) or getting a better performance.

Mit freundlichen Grüßen / Best regards

Birgitta Hauser


"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
?Train people well enough so they can leave, treat them well enough so they
don't want to.? (Richard Branson)


-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Therrien, Paul via MIDRANGE-L
Sent: Mittwoch, 29. Dezember 2021 22:16
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Cc: Therrien, Paul <ptherrien@xxxxxxxxxxx>; David Gibbs <david@xxxxxxxxxxxx>
Subject: RE: QRWTSRVR job with open files - how to close?

The file in question is accessed via SQL exclusively, but there are a bunch
of other files also open in the QRWTSRVR job that may or may not be accessed
by SQL.
I'm reasonably certain that some of these files are only accessed via RLA in
RPG programs.


-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of David
Gibbs via MIDRANGE-L
Sent: Wednesday, December 29, 2021 3:42 PM
To: Therrien, Paul via MIDRANGE-L <midrange-l@xxxxxxxxxxxxxxxxxx>
Cc: David Gibbs <david@xxxxxxxxxxxx>
Subject: Re: QRWTSRVR job with open files - how to close?

On 12/29/21 1:07 PM, Therrien, Paul via MIDRANGE-L wrote:
We have QRWTSRVR jobs running on our system that are invoked from
another IBM I. A stored proc on the source system will call a CL
program on the target system. The target cl will call an RPG
program(s) that run and set on *INLR and return. Which would close
files and unlock files - I would hope. And the CL program also ends.
However, when I look at the QRWTSRVR job, that is currently sitting
idle, I see dozens of open files.

How is the RPG program accessing the database? RLA (chain, read etc) or
SQL?

If SQL, maybe it's a pseudo closed cursor? I ran into that recently with
the database host server jobs.

https://www.ibm.com/support/pages/pseudo-closed-cursor-faq

david


--
I'm riding in the American Diabetes Association's Tour de Cure to raise
money for diabetes research, education, advocacy, and awareness. You can
make a tax-deductible donation to my ride by visiting
https://mideml.diabetessucks.net.

You can see where my donations come from by visiting my interactive donation
map ... https://mideml.diabetessucks.net/map (it's a geeky thing).
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com

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

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.