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
Checking users and using SHR
Moderators: Susan Smith, admin, Gabriel
READ, RELEASE:
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!
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!
OPTION 14
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.
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.