Checking users and using SHR

Information and discussion about the BR Wiki.

Moderators: Susan Smith, admin, Gabriel

Post Reply
gtisdale
Posts: 218
Joined: Sun Jun 07, 2009 7:54 am
Location: Concord, Massachusetts
Contact:

Checking users and using SHR

Post by gtisdale »

I previously posted a message regarding checking on users using a program that reads NOCLOSE files that my menu program sets for each user. In that email I erroneously stated that the user NOCLOSE LOCAL file (that is a file with the name LOCAL[session]) was opened NOSHR. Some of the information that I subsequently included was therefore erroneous. The WORKMENU program opens the LOCAL files SHR not NOSHR.

This allows the administrator to change the permissions of any user while the user is still logged on to the system. The program that I posted opens the LOCAL files INPUT and reads REC(1) to get the user name, then closes the LOCAL file and attempts to reopen it NOSHR OUTIN. If the file is in use by the user it cannot be opened NOSHR OUTIN because the user already has the OUTIN permission and another OUTIN that is NOSHR is a violation of rights. Consequently, the second open fails and we know the user and session is active.

This raises the subject of SHARES in open statements. My recollection was wrong and with GORDON's assistance I have refreshed my rememberer. The way it works is as follows:

SHR allows other sessions to open the file and read records.
SHR with OUTIN will lock a specific record if it is read until a rewrite occurs, at which point the record is released
If the READ statement includes a RELEASE then the record is not locked. It is not that it is locked and immediately released, no locking occurs. This allows for faster processing

NOSHR locks the file and does not allow others to open the file

SHRI which I thought was obsolete is NOT obsolete. SHRI allows a file to be shared by others, but only if they open the file as INPUT

If a file is opened as INPUT all records can be read, even locked records.

Try running the following program
Line 75 errors wioth a timeout on locked record

Change line 50 back to shr and add RELEASE to line 55
The program runs

Try changing line 50 to SHRI
Line 70 errors with a file sharing error

Change line 70 to INPUT
The program runs

00010 OPEN #1: "name=xxx,replace,recl=100",INTERNAL,OUTIN,RELATIVE
00020 WRITE #1,USING 'form c': "XXX"
00030 CLOSE #1:
00040 !
00050 OPEN #1: "name=xxx, shr",INTERNAL,OUTIN,RELATIVE
00055 READ #1:
00060 OPEN #2: "name=xxx,shr",INTERNAL,INPUT,RELATIVE
00065 READ #2:
00070 OPEN #3: "name=xxx,shr",INTERNAL,OUTIN,RELATIVE
00075 READ #3:
00080 PAUSE
GomezL
Posts: 258
Joined: Wed Apr 29, 2009 5:51 am
Contact:

READ, RELEASE:

Post by GomezL »

00010 OPEN #1: "name=xxx,replace,recl=100",INTERNAL,OUTIN,RELATIVE
00020 WRITE #1,USING 'form c': "XXX"
00030 CLOSE #1:
00040 !
00050 OPEN #1: "name=xxx, shr",INTERNAL,OUTIN,RELATIVE
00055 READ #1:
00060 OPEN #2: "name=xxx,shr",INTERNAL,INPUT,RELATIVE
00065 READ #2:
00070 OPEN #3: "name=xxx,shr",INTERNAL,OUTIN,RELATIVE
00075 READ #3,RELEASE:
00080 PAUSE

If you add a "Read,Release" to line 75, then you will not receive an error 61!
GomezL
Posts: 258
Joined: Wed Apr 29, 2009 5:51 am
Contact:

OPTION 14

Post by GomezL »

00005 EXECUTE "CONFIG OPTION 14 ON"
00010 OPEN #1: "name=xxx,replace,recl=100",INTERNAL,OUTIN,RELATIVE
00020 WRITE #1,USING 'form c': "XXX"
00030 CLOSE #1:
00040 !
00050 OPEN #1: "name=xxx, shr",INTERNAL,OUTIN,RELATIVE
00055 READ #1:
00060 OPEN #2: "name=xxx,shr",INTERNAL,INPUT,RELATIVE
00065 READ #2:
00070 OPEN #3: "name=xxx,shr",INTERNAL,OUTIN,RELATIVE
00075 READ #3:
00080 PAUSE


Another record locking bahavior, OPTION 14 ON will allow the same program to lock the same record twice without generating an error 61. Generally this is a terrible idea, but older versions of BR did allow this behavior.
Post Reply