RE: Locks and STRISDB

I believe because ISDB is doing a read lock.  That is, it is opening for
read, not for write.  CODE is doing a read/write lock.  It is opening for
reading and writing.

If a program tries to open a file for reading only, it can do that even if
another program has it open for reading and writing.  Then there is the
exclusive lock, if a program has a file opened for exclusive lock, no other
program can open that file at all, not even for reading.

SEU is going to try to open it for reading and writing, can't be done, since
another program already has it open for writing.  Then ISDB tries to open it
for reading, no problem.  Now, you try to save in code400, at this point it
looks like Code400 is doing an exclusive lock to make sure no other program
has this file open, which is where it fails.  You close the ISDB read lock,
then it can open it exclusively and write to it.

Ahhh, the joys of multi user file I/O :)

Regards,

Jim Langston

-----Original Message-----
From: Phil Groschwitz [mailto:sublime78ska@yahoo.com]

All,

I opened a source member on the host with CODE.  It's
locked, can't open it with SEU.

I then started STRISDB on the pgm.  Runs.  I made a
change to the source, but when I click save I get a
message that the source member is locked.  Once I end
isdb, I can save it.

My question is: How did STRISDB get a lock if CODE
already had a lock?

Phil