Decided to use LSR pool 1 and LSR pool 2 each dedicated to our own specific VSAM datasets that we used with Solve Operations.
We noticed that SH LSR commands are reporting 0 in the Buffer Found column and 0.00% in the FOUND column for these LSR pools.

For example:

N15A30 ACTIVE LSR POOL 0 STATISTICS 
N15A31 KEYLEN: 255 STRNO: 220 FIXIOB: NO FIXBFR: NO STRMAX: 9 ACTIVE: 11 
N15A32 SIZE COUNT P. READS BUF FOUND UIW NUIW %FOUND HS-COUNT 
N15A33 2048 100 3817 56575872 67229 0 99.99 
N15A33 4096 200 409512 32526003 1792 0 98.75 
N15A33 4608 50 0 0 0 0 0.00 
N15A33 8192 200 132830 10852366 36290 0 98.79 
N15A33 10240 20 0 0 0 0 0.00 
N15A33 16384 40 312158 161094 108814 0 34.03 
N15A33 28672 6 79845 18736345 143323 6790 99.57 
N15A30 ACTIVE LSR POOL 1 STATISTICS 
N15A31 KEYLEN: 255 STRNO: 255 FIXIOB: NO FIXBFR: NO STRMAX: 1 ACTIVE: 1 
N15A32 SIZE COUNT P. READS BUF FOUND UIW NUIW %FOUND HS-COUNT 
N15A33 2048 100 0 0 0 0 0.00 
N15A33 4096 200 111 0 1 0 0.00 
N15A33 8192 60 0 0 0 0 0.00 
N15A33 10240 20 0 0 0 0 0.00 
N15A33 16384 100 99 0 4 0 0.00 
N15A33 28672 10 0 0 0 0 0.00 
N15A30 ACTIVE LSR POOL 2 STATISTICS 
N15A31 KEYLEN: 255 STRNO: 255 FIXIOB: NO FIXBFR: NO STRMAX: 10 ACTIVE: 1 
N15A32 SIZE COUNT P. READS BUF FOUND UIW NUIW %FOUND HS-COUNT 
N15A33 2048 100 0 0 0 0 0.00 
N15A33 4096 200 430166 0 0 0 0.00 
N15A33 8192 60 0 0 0 0 0.00 
N15A33 10240 20 0 0 0 0 0.00 
N15A33 16384 100 215109 0 35614 0 0.00 
N15A33 28672 10 0 0 0 0 0.00 
N11907 *END* 

Release: SLFTS.00200-12.2-SOLVE:FTS
Component:

From the display of the SHOW LSR command, the results are correct with the two VSAM files being physical reads….. BUF FOUND is 0 , so %FOUND will be 0.00.  The data is sourced direct from VSAM control blocks. The lack of cache hits does indicate that LSR is not useful. 
Recommend looking at the VSAM file's SHAREOPTIONS and CISZs. For instance when using SHR(4,3) the data set can be fully shared by any number of users, and buffers used for direct processing are refreshed for each request.