COBOL (STANDARD=V3) RRL+NLK -> NQL file status returned

[EdgarZamora]

Hello colleagues. I want to implement No Query Locking on our system (via SET RMS/QUERY=DISA/SYS) and the applications group wants confirmation on what file status codes could be returned on successful READ statements (which were previously 00, 02, and 90) (which I think equates to RMS$_SUC, RMS$_OK_RLK, and RMS$_OK_RRL but I'm not sure of this). I think the return code will be 00 now but I can't find any confirmation in the docs. Can someone confirm this and/or point me to any documentation that will confirm this? I've looked in the COBOL reference manual and the Guide to File Applications states that RMS$_OK_RLK or RMS$_OK_RRL will no longer be returned, but it doesn't explicitly say that RMS$_SUC will be returned. Thanks in advance for any suggestions or pointers!

[Hein van den Heuvel · Accepted solution]

It will return an unconditional success.
"00" in Cobol, RMS$_SUC (65537) in C.

Hein.

[Hein van den Heuvel]

Also... don't just believe it. Try it!

Note... OK_RLK is a little harder to get.

Sample run and program used below.

Hein.

$ set rms/query_lock=enable
$ mcr sys$Login:ok_rrl sys$login:y.idx
record 22,1
NQL ___ status = 10001
RRL ___ status = 18029
RRL NLK status = 18029
___ NLK status = 182AA
___ ___ status = 182AA

$ set rms/query_lock=disable
$ mcr sys$Login:ok_rrl sys$login:y.idx
record 22,1
NQL ___ status = 10001
RRL ___ status = 18029
RRL NLK status = 10001
___ NLK status = 182AA
___ ___ status = 182AA



$ type ok_rrl.c
#include
#include
#include
#define MAXRECSIZ 32767
int SYS$OPEN(), SYS$CONNECT(), SYS$GET(), SYS$REWIND();
main (int argc, char *argv[])
{
struct FAB fab;
struct RAB rab;
char recbuf[MAXRECSIZ+1];
int i, stat;
fab = cc$rms_fab;
rab = cc$rms_rab;
fab.fab$b_shr = FAB$M_MSE | FAB$M_UPD;
fab.fab$b_fac = FAB$M_GET | FAB$M_UPD;
fab.fab$l_fna = argv[1];
fab.fab$b_fns = strlen( argv[1] );
stat = SYS$OPEN ( &fab );
if (!(stat&1)) return stat;
rab.rab$l_fab = &fab;
rab.rab$l_ubf = recbuf;
rab.rab$w_usz = MAXRECSIZ;
stat = SYS$CONNECT ( &rab );
if (!(stat&1)) return stat;
stat = SYS$GET ( &rab ); // lock record

rab.rab$w_isi = 0; // new context
stat = SYS$CONNECT ( &rab );

rab.rab$v_nql = 1;
stat = SYS$GET ( &rab ); // no query lock first to get RFA for sure
printf ("record %d,%d\n", rab.rab$l_rfa0, rab.rab$w_rfa4);
printf ("NQL ___ status = %X\n", stat);
rab.rab$v_nql = 0;

rab.rab$v_rrl = 1;
SYS$REWIND( &rab );
stat = SYS$GET ( &rab );
printf ("RRL ___ status = %X\n", stat);

rab.rab$v_nlk = 1;
SYS$REWIND( &rab );
stat = SYS$GET ( &rab );
printf ("RRL NLK status = %X\n", stat);

rab.rab$v_rrl = 0;
SYS$REWIND( &rab );
stat = SYS$GET ( &rab );
printf ("___ NLK status = %X\n", stat);

rab.rab$v_nlk = 0;
SYS$REWIND( &rab );
stat = SYS$GET ( &rab ); // no options
printf ("___ ___ status = %X\n", stat);
}

[EdgarZamora]

I thought NQL would only affect the READ REGARDLESS but it's also affecting the READ ALLOWING NO OTHERS statements. These used to return 92 (Record locked by another user (record not available) but are now returning 00 (e.g. I have program 1 do a READ ALLOWING NO OTHERS on a record, and program 2 do a READ ALLOWING NO OTHERS on the same record and it succeeds.) This has changed the behavior of our COBOL programs. I'm checking my testing to make sure.

[EdgarZamora]

I've verified my test programs are working correctly. Hein, is this the correct behavior for NQL - that even READ ALLOWING NO OTHERS would allow successful?

[Hein van den Heuvel]

Yes that is correct.

With NQL active RMS will only take out bucket locks (temporarely) to make sure it has an up-to-date copy of the block holding the data record.
There is NO record locking.

Typically this is ok.
Here is how I see it...
Let's say the process using NQL needs to display customer name and address on the screen. 'Obviously' it does not matter whether the current balance for that customer is being updated. IMHO it even does not really matter if the address is being updated.
Had the program asked a millisecond earlier, it would have had the (now) stale record in its buffer and displayed, possibly for a long time, while already no longer being up to date also.
No biggie.
Now if you are also about to update that balnce, then you had better lock it properly and read the actual value before updating!

Hein.

[EdgarZamora]

"Now if you are also about to update that balnce, then you had better lock it properly and read the actual value before updating!"

I'm sorry if I'm being dense... but... how then would I lock it properly? I would have done a READ ALLOWING NO OTHERS (to lock it properly) then REWRITE to update the record.

Also, Applications' response to me:

"Well, his last sentence is the issue â once you turn this on system wide there appears to be no possible way to lock a record.

Or am I missing it?

At least no way in Cobol.

I hope he understood the question â we are not trying to lock the record so that someone doing a regardless-of-lock would be blocked. We want someone doing a allowing-no-others to block someone else doing a allowing-no-others."

[Hein van den Heuvel]

>> how then would I lock it properly?

Just open for IO and READ.

>> I would have done a READ ALLOWING NO OTHERS (to lock it properly) then REWRITE to update the record.

Correct.

>> Also, Applications' response to me:
>> "Well, his last sentence is the issue â  once you turn this on system wide there appears to be no possible way to lock a record.

>> Or am I missing it?

They completely missed the fact that the RMS process/system flag is ONLY looked at when "READ REGARDLESS" is in effect.

There is ZERO, NO, ZILCH worry needed about loosing locking. You would only loose lock status information for processes which are not supposed to care too much... thye asked "READ REGARDLESS"

>> We want someone doing a allowing-no-others to block someone else doing a allowing-no-others."

NO impact.
Only impact is on the error status for RAAD REGARDLESS, which already blows through the allowin no others.

Hein.

[EdgarZamora]

Sorry we had a slight misunderstanding before. It's all good now. I wrote a very simple test program and NQL worked as advertised. Looked at the test programs from applications and found a problem with it. Thanks Hein your the best!