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



Charles, thanks for your feedback. I move source with RDi and compile on
each system. I have a common SET OPTION copy member. The only changes to
the funky source is to comment out references to columns not in the funky
system's tables. I use a standard build routine to guard against this sort
of problem (how's that working for me?). I have more than 1,700 programs
using commitment control and they run fine.

My customer is at V7R4 and my local system is V7R5. A missing PTF
certainly is a possibility but records remaining locked after a COMMIT
seems like a non-trivial issue. I will check on their PTF status; they
IMPL'ed over the weekend and the only reason they do is to apply PTF's.

I'm going back to compile listings and DSPPGM, find out what I've missed,
and then get the sjambok out of the closet.

--reeve


EXEC SQL
SET OPTION ALWCPYDTA = *OPTIMIZE,
CLOSQLCSR = *ENDMOD,
COMMIT = *CHG,
DATFMT = *ISO,
EXTIND = *YES,
TIMFMT = *ISO;

On Tue, Jul 30, 2024 at 1:25 PM Charles Wilt <charles.wilt@xxxxxxxxx> wrote:

1) One system has a PTF the other doesn't
2) You're not running the same program.

For #2, how is the program being moved between systems? SAVRSTOBJ, or did
you copy the source and compile it on each system separately,

If as I suspect the latter is the case, check to see that both programs
were created with the same options
CRTSQLRPGI COMMIT(...) CLOSQLCSR(...) in particular.

Might consider using SET OPTION in the program source to ensure they get
created the same.

Charles


On Tue, Jul 30, 2024 at 1:00 PM Reeve <rfritchman@xxxxxxxxx> wrote:

After using *CHG commitment control at the job level, using a cursor "FOR
UPDATE" to fetch and update a single record, and then using SQL COMMIT,
DSPRCDLCK shows the record is in "STATUS=HELD LOCK TYPE=READ" status.

The same very simple CRUD program running on another system (V7R5) in the
same (I think) environment shows the record as being fully unlocked.
Both
programs run in a named activation group and there's no funny stuff going
on.

The differing behaviors is what's getting me. Why won't the system give
me
back my record?

Thanks,
Reeve
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.


--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.



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.