Interesting comparison of SQL and RLA on the same file name in in different libraries

MYPGM reads MYFILE (in LIB1) with RLA then SQL and returns with INLR off.


DSPJOB shows 2 open access paths for LIB1/MYFILE



ADDLIBLE LIB2 (containing a copy of MYFILE)

CALL MYPGM

DSPJOB now shows

1 open access path for LIB1/MYFILE

1 open access path for LIB2/MYFILE

For me it was obvious that the first file remained open but I was
surprised that the send OAP indicated the new file, and that the
original lock had been released.

I often used to notice after execution of a program using embedded SQL that
a file would remain locked, the file being opened in the DFTACTGRP.
In our shop, users can change the library list to switch to and from a test
environment.I used to think that using embedded SQL would therefore be
problematic (with the danger of reading the wrong file). However, the test
above shows that it would only be the case if using RLA and the file didn't
close at the end of the program. This was important for me, as in my last
RPG shop, they used CRTPGM with ILE modules and never understood why INLR
and RCLRSC were not working, the files all remaining open. Obviously this
would be a big problem if one tried to switch between the test and the
production environments as they do in my shop today. Luckily for them they
are still programming in RPGIII.

Sorry if I was teaching you to suck eggs :-) I would love to know more if
anyone can enlighten me.