Come to think of it, I think customizing CSC's MHC s/w was the 1st time
I ever fought this fight.
Before that, I had always programmed under a standard that demanded a
READU before a WRITE. And every READU needed a LOCKED clause.
cds
On 10/24/2011 6:57 PM, Paul Wilson wrote:
That little company called CSC does/did not use readu's - they put login id in
field 1 and used that for a 'locking' situation.
________________________________
From: "Woodward, Bob"<[email protected]>
To: U2 Users List<[email protected]>
Sent: Monday, October 24, 2011 7:06 PM
Subject: Re: [U2] [UV] LIST.READU EVERY's "waiters" when there are writes w/o
explicit readu.
Oh I agree! I was just thinking round-robin that if we're going to talk
about adding a LOCKED clause to the WRITE statement, matching the
structure of READU, then we ought to have a WRITEU, too. Didn't say I
liked the idea....
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Mecki
Foerthmann
Sent: Monday, October 24, 2011 3:30 PM
To: [email protected]
Subject: Re: [U2] [UV] LIST.READU EVERY's "waiters" when there are
writes w/o explicit readu.
Now why would anybody want to use a WRITE without a READU?
I can possibly understand that somebody would want to do it with a
WRITEV (i.e writing a flag on a record) but WRITE?
And WRITE totally ignoring locking would be outright stupid.
On 24/10/2011 22:28, Woodward, Bob wrote:
I would think that because you are not trying to obtain the lock in a
WRITE statement, it would not be classified as a waiter. True, it's
waiting because of the lock but by not trying to obtain the lock, it's
only waiting for the blockage to clear. If it were to be classified
as
a waiter then I would expect to see a LOCKED clause on the WRITE
statement like there is on the READU. For that matter, I'd expect to
see a WRITEU command as well and the standard WRITE to completely
ignore
locking.
Just my guess, though.
BobW
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Charles
Stevenson
Sent: Monday, October 24, 2011 2:12 PM
To: U2 Users List
Subject: [U2] [UV] LIST.READU EVERY's "waiters" when there are writes
w/o explicit readu.
UV 10.2.10 on Windows is behaving differently from what I recall.
Are my expectations out of line?
Suppose Session A holds a readu lock; and Session B attempts a WRITE
to
same record withOUT!!! 1st explicitly getting the readu lock.
Session B waits for Session A to release the lock before writing the
record.
While Session B is waiting, does it show up as a "waiter" in
LIST.READU
EVERY?
I expected so, but it doesn't.
Session A Session B
_____________________________ ___________________
1A. ED VOC DUMMY
(this sets the readu lock.)
2A. (stay in editor) 2B. run this:
01: OPEN 'VOC' TO F ELSE
STOPM
'nope'
02: ***READU REC FROM F, 'DUMMY'
ELSE NULL
03: WRITE '' TO F, 'DUMMY'
3A. Within ED:
XEQ LIST.READU EVERY
If I UN-comment line 2, LIST.READU EVERY shows something like this:
Active Read Waiters: Owner Waiter
Device.... Inode.... Userno Userno
746117947 232860913 6116 3396
But when I comment out line 2, LIST.READU is silent.
I have not yet explored what the deadlock daemon does.
TIA,
cds
P.S. Yes, yes, "Bad Form", "Legacy Software", 20 min wait is
configurable, . . . we can talk later.
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
