Re:No SHRUPD but still file locked--->changing S36 options

File 'deadlock' situations were common on the S36, and all the parameters in 
the world will not change the functional 
shortcomings in the 36EE or M36 environments.

        What you must do to avoid these scenarios in the 36 environment, is , 
for Files opened for update, 
        on every random read of the file, build your own 'unlock' procedure, 
which simply does a random read on the file 
        based on a non existent key.
        ......
        What would typically happen, and this was an Achilles heel in the /36 , 
was one operator would open a 
        Customer master for update, say customer 001, (walk away for a coffee), 
while another operator would
        key in the same customer for another function.
        Both processes would 'lock' up.
        It was a rare occurrence, but depending on the activity going on at the 
time, could be a huge headache..
        Of course, clearing up one problem, now introduces other problems of 
data integrity, etc....
        The inherent intelligence in the Operating systems since the /36 days, 
has been vastly improved.

I personally don't believe for a minute that checking off an option to share 
files in this environment works.
and it can be tested, to wit, you already checked of shared files using CHGS36!.
 

Ken Shields