System Parameters
'SH' Share Handle and Buffers
  The Share Handle functionality is a +PxPlus Exclusive
Description The SH parameter controls the sharing of operating system handles (the logical connection between your application and a data file) and data buffers whenever the same file is opened more than once.

When the 'SH' system parameter is enabled during the file open process, the system will compare pathnames of the file being opened with those of other currently open VLR/FLR files. If the same file is already opened, the system will internally share that connection and all associated file buffers.

Files that are opened for LOCK or files opened in one instance for Read/Write and another for Read only will not be shared.
* Note * The 'SH' parameter only works with VLR or FLR files, not EFF files.
Advantages The 'SH' system parameter can be used to increase system performance in cases where the same file is opened more than once. It avoids the OS overheads associated with opening the file and by sharing buffers allows the system to access the data quicker.

There are many instances where the same file is opened more than once in most applications. For example, a typical maintenance program will open a master file and often provide access to a generic query facility to lookup record IDs. Usually this means that the master file will be opened once by the maintenance program and once by the query.

The following sample program can be used to see the difference that sharing handles and buffers can make.

0010 BEGIN
0020 LET SV_SH=PRM('SH')
0030 FOR SH=0 TO 1
0040 SET_PARAM 'SH'=SH
0050 PRINT TBL(SH,'BLACK','BLUE'),"'SH'=",STR(SH)
0060 RANDOMIZE 1.235
0070 ERASE "testfile",ERR=*NEXT
0080 LET RIO=TCB(50),WIO=TCB(51)
0090 KEYED "testfile",6
0100 OPEN (1)"testfile"
0110 OPEN (2)"testfile"
0120 OPEN (3)"testfile"
0130 OPEN (4)"testfile"
0140 LET X=TMR(0)
0150 LET WR=0,RD=0,DEL=0,OP=0
0160 FOR I=1 TO 200000
0170 LET FL=1+RND(4)
0180 LET N=RND(100)
0190 IF N=99 THEN CLOSE (FL); OPEN (FL)"testfile"; OP++; CONTINUE
0200 LET K$=STR(RND(1000):"000")+STR(RND(1000):"000")
0210 IF N<50 THEN WR++; WRITE (FL,KEY=K$)K$,WR,NUM(K$)+WR; CONTINUE
0220 READ (FL,KEY=K$,DOM=*CONTINUE)K,S,V
0230 IF K<>NUM(K$) OR V<>K+S THEN ESCAPE
0240 IF N<80 THEN RD++; CONTINUE
0250 REMOVE (FL,KEY=K$)
0260 DEL++
0270 NEXT
0280 CLOSE (*)
0290 LET RIO=TCB(50)-RIO,WIO=TCB(51)-WIO
0300 PRINT "Writes=",@(15),WR
0310 PRINT "Reads=",@(15),RD
0320 PRINT "Removes=",@(15),DEL
0330 PRINT "Reopens=",@(15),OP
0340 PRINT "Phys Rd=",@(15),RIO
0350 PRINT "Phys Wr=",@(15),WIO
0360 PRINT "Seconds=",@(15),TMR(1)
0370 NEXT SH
0380 SET_PARAM 'SH'=SV_SH
0390 PRINT 'RM',
0400 END
* Notice * While the 'SH' parameter can be used in most instances to improve system performance, if a file is renamed while open, there is a possibility that the logic might fail.

For example, assuming the parameter is on and your application issued:

OPEN ( 10 ) "/myapp/data/company_1/file1"

If the directory 'company_1' was then renamed to 'company_xx' and a new file1 was created:

RENAME "/myapp/data/company_1","company_xx"
DIRECTORY "/myapp/data/company_1"
SERIAL "/myapp/data/company_1/file1"

Now, if your application issued another open to the same pathname, as in:

OPEN ( 100 ) "/myapp/data/company_1/file1"

The system will incorrectly assume that this is the same as the original file1 opened on channel 10. The net effect is that channel 100 will be actually pointing to what is now "/myapp/data/company_xx/file1" not "/myapp/data/company_1/file1".

Without the 'SH' parameter enabled, the system would have correctly opened the new file1.

The possibilities of this occurring are very very low and most applications will never encounter this situation.
Default Off. By default