Failing READU lock

#1

Good afternoon,

My company recently upgraded our 3rd party software to a Windows 2003
server running D3 PICK. We have about 60 users so we are not the
biggest PICK users in the universe.

Here is my issue:

Most everything updated on our system logs a note in our accounts. The
routine that adds these notes uses the following code to use a
sequential key to add the records:

040 RETRY.READ:
041 READU MSTITEM FROM MASTR1, "NOTEKEY" LOCKED
042 LOCK.CNT += 1
043 SLEEP 1
044 GOTO RETRY.READ
045 END ELSE
046 MSTITEM = ''
047 END
048 MSTITEM<2>=MSTITEM<2>+1
049 WRITE MSTITEM ON MASTR1, "NOTEKEY"
050 RELEASE MASTR1, "NOTEKEY"

The problem is simple-we end up with records being overwritten when
usage gets the least bit heavy. I put some tracing steps in the
routine and found the same key is being used by seperate processes
when updating. All I can figure is that both processes are trying to
lock the record at the same time and both end up with access to the
record creating duplicate keys.

Any ideas/suggestions/discussion on this would be greatly appreciated!

Thanks,

Walt

#2

opus600 (AT) comcast (DOT) net ha scritto:

Quote:

Good afternoon,

My company recently upgraded our 3rd party software to a Windows 2003
server running D3 PICK. We have about 60 users so we are not the
biggest PICK users in the universe.

Here is my issue:

Most everything updated on our system logs a note in our accounts. The
routine that adds these notes uses the following code to use a
sequential key to add the records:

040 RETRY.READ:
041 READU MSTITEM FROM MASTR1, "NOTEKEY" LOCKED
042 LOCK.CNT += 1
043 SLEEP 1
044 GOTO RETRY.READ
045 END ELSE
046 MSTITEM = ''
047 END
048 MSTITEM<2>=MSTITEM<2>+1
049 WRITE MSTITEM ON MASTR1, "NOTEKEY"
050 RELEASE MASTR1, "NOTEKEY"

The problem is simple-we end up with records being overwritten when
usage gets the least bit heavy. I put some tracing steps in the
routine and found the same key is being used by seperate processes
when updating. All I can figure is that both processes are trying to
lock the record at the same time and both end up with access to the
record creating duplicate keys.

Any ideas/suggestions/discussion on this would be greatly appreciated!

Thanks,

Walt

the code seems ok to me...>
line 050 is not necessary...

Regards,
Stefano

#3

opus600 (AT) comcast (DOT) net wrote:

Quote:

Good afternoon,

My company recently upgraded our 3rd party software to a
Windows 2003 server running D3 PICK. We have about 60 users so
we are not the biggest PICK users in the universe.

Here is my issue:

Most everything updated on our system logs a note in our
accounts. The routine that adds these notes uses the following
code to use a sequential key to add the records:

040 RETRY.READ:
041 READU MSTITEM FROM MASTR1, "NOTEKEY" LOCKED
042 LOCK.CNT += 1
043 SLEEP 1
044 GOTO RETRY.READ
045 END ELSE
046 MSTITEM = ''
047 END
048 MSTITEM<2>=MSTITEM<2>+1
049 WRITE MSTITEM ON MASTR1, "NOTEKEY"
050 RELEASE MASTR1, "NOTEKEY"

The problem is simple-we end up with records being overwritten
when usage gets the least bit heavy. I put some tracing steps
in the routine and found the same key is being used by
seperate processes when updating. All I can figure is that
both processes are trying to lock the record at the same time
and both end up with access to the record creating duplicate
keys.

Any ideas/suggestions/discussion on this would be greatly
appreciated!

Something broken in the internals of the MASTR1 file? I don't
know about D3, but you could try running the appropriate repair
facility on the file. It might be something like "FIX_FILE
MASTR1" or "RESIZE MASTR1 * *".

John

#4

On Apr 17, 12:10 pm, stefano <stef... (AT) friuldata (DOT) it> wrote:

Quote:

opus... (AT) comcast (DOT) net ha scritto:

Good afternoon,

My company recently upgraded our 3rd party software to a Windows 2003
server running D3 PICK. We have about 60 users so we are not the
biggest PICK users in the universe.

Here is my issue:

Most everything updated on our system logs a note in our accounts. The
routine that adds these notes uses the following code to use a
sequential key to add the records:

040 RETRY.READ:
041 READU MSTITEM FROM MASTR1, "NOTEKEY" LOCKED
042 LOCK.CNT += 1
043 SLEEP 1
044 GOTO RETRY.READ
045 END ELSE
046 MSTITEM = ''
047 END
048 MSTITEM<2>=MSTITEM<2>+1
049 WRITE MSTITEM ON MASTR1, "NOTEKEY"
050 RELEASE MASTR1, "NOTEKEY"

The problem is simple-we end up with records being overwritten when
usage gets the least bit heavy. I put some tracing steps in the
routine and found the same key is being used by seperate processes
when updating. All I can figure is that both processes are trying to
lock the record at the same time and both end up with access to the
record creating duplicate keys.

Any ideas/suggestions/discussion on this would be greatly appreciated!

Thanks,

Walt

the code seems ok to me...
line 050 is not necessary...

Regards,
Stefano

I don't know about D3/Windows but my version of D3/Linux the code
could be pared down to:

040 RETRY.READ:
041 READU MSTITEM FROM MASTR1, "NOTEKEY"
042 MSTITEM<2>=MSTITEM<2>+1
043 WRITE MSTITEM ON MASTR1, "NOTEKEY"

On D3/linux, if the item is not read (on file), and there is no
clause, a null item is created. And why sleep for a second? Let the
record locking system handle things. Processes will wait their turn
until they are able to read and assert their own lock.

And as long as the variable 'LOCK.CNT' is not required else where in
the code then don't increment it.

Regards,

Dale

#5

On Apr 17, 3:39 pm, Dale <dale_bened... (AT) flightcraft (DOT) ca> wrote:

Quote:

On Apr 17, 12:10 pm, stefano <stef... (AT) friuldata (DOT) it> wrote:

opus... (AT) comcast (DOT) net ha scritto:

Good afternoon,

My company recently upgraded our 3rd party software to a Windows 2003
server running D3 PICK. We have about 60 users so we are not the
biggest PICK users in the universe.

Here is my issue:

Most everything updated on our system logs a note in our accounts. The
routine that adds these notes uses the following code to use a
sequential key to add the records:

040 RETRY.READ:
041 READU MSTITEM FROM MASTR1, "NOTEKEY" LOCKED
042 LOCK.CNT += 1
043 SLEEP 1
044 GOTO RETRY.READ
045 END ELSE
046 MSTITEM = ''
047 END
048 MSTITEM<2>=MSTITEM<2>+1
049 WRITE MSTITEM ON MASTR1, "NOTEKEY"
050 RELEASE MASTR1, "NOTEKEY"

The problem is simple-we end up with records being overwritten when
usage gets the least bit heavy. I put some tracing steps in the
routine and found the same key is being used by seperate processes
when updating. All I can figure is that both processes are trying to
lock the record at the same time and both end up with access to the
record creating duplicate keys.

Any ideas/suggestions/discussion on this would be greatly appreciated!

Thanks,

Walt

the code seems ok to me...
line 050 is not necessary...

Regards,
Stefano

I don't know about D3/Windows but my version of D3/Linux the code
could be pared down to:

040 RETRY.READ:
041 READU MSTITEM FROM MASTR1, "NOTEKEY"
042 MSTITEM<2>=MSTITEM<2>+1
043 WRITE MSTITEM ON MASTR1, "NOTEKEY"

On D3/linux, if the item is not read (on file), and there is no
clause, a null item is created. And why sleep for a second? Let the
record locking system handle things. Processes will wait their turn
until they are able to read and assert their own lock.

And as long as the variable 'LOCK.CNT' is not required else where in
the code then don't increment it.

Regards,

Dale- Hide quoted text -

- Show quoted text -

The item would never be null unless the record gets zapped so no null
clause should be needed. (I actually did not write most of the code
and noticed this same problem. But, it should never happen so leaving
it out didn't seem that important to me.)

The sleep was to correct a hang we kept having when the lock was
overloaded. Without the sleep, multiple ports would end up "hung" in
the lock. Again, part of the issue here is why the lock doesn't just
keep looping until it is released. The system acts like 2 or more
ports all have the record read and are trying to write at the same
time.

Actually the LOCK.CNT is used later as part of my tracking to give me
an idea of how many times the lock actually works. Surprisingly, it
rarely increments so it appears the lock fails quite a bit.

I will check the integrity of the file, but we did a full restore of
the system about 2 weeks ago and nothing changed. The problem was
there before and after the save/restore.

Any further suggestions would be greatly appreciated.

Thanks,

Walt

#6

Opus600 wrote:

Quote:

I will check the integrity of the file, but we did a full
restore of the system about 2 weeks ago and nothing changed.
The problem was there before and after the save/restore.

Usual causes of internal file GFEs (group format errors, AKA
"gone for ever") are power failures, and the restoration of
backups that were done while updates were in progress.

Having seen them, I'd wager on it being your problem.

John

#7

On Apr 18, 4:34 am, opus... (AT) comcast (DOT) net wrote:

Quote:

Good afternoon,

My company recently upgraded our 3rd party software to a Windows 2003
server running D3 PICK. We have about 60 users so we are not the
biggest PICK users in the universe.

Here is my issue:

Most everything updated on our system logs a note in our accounts. The
routine that adds these notes uses the following code to use a
sequential key to add the records:

040 RETRY.READ:
041 READU MSTITEM FROM MASTR1, "NOTEKEY" LOCKED
042 LOCK.CNT += 1
043 SLEEP 1
044 GOTO RETRY.READ
045 END ELSE
046 MSTITEM = ''
047 END
048 MSTITEM<2>=MSTITEM<2>+1
049 WRITE MSTITEM ON MASTR1, "NOTEKEY"
050 RELEASE MASTR1, "NOTEKEY"

The problem is simple-we end up with records being overwritten when
usage gets the least bit heavy. I put some tracing steps in the
routine and found the same key is being used by seperate processes
when updating. All I can figure is that both processes are trying to
lock the record at the same time and both end up with access to the
record creating duplicate keys.

Any ideas/suggestions/discussion on this would be greatly appreciated!

Thanks,

Walt

What version of D3? Did it get updated at the same time?

Code looks fine .... if you are after a "quick fix", simply replace
the whole thing with SYSTEM(19)

If you want to track down where "bad code" is buried within system
(debt collection?) put a callx on the file - I assume once written
notations are not changed, so when you find an overwrite situation,
throw a message/exception.

Equally though, I assume this was obviously working AOK prior to the
upgrade, so "something changed"

HTH

Ross Ferris
Stamina Software
Visage > Better by Design !

#8

Hi
I have always written the code as follows
059 201.2 * WRITE FILE 1
049 READU CONREC FROM CONF,CONKEY LOCKED
050 A.ITEM = CONKEY;GOSUB 200
051 IF A.LOCK = 0 THEN GOTO 201.11
052 END THEN
053 NULL
054 END ELSE
055 RELEASE CONF,CONKEY
056 A.ERR = CONKEY:A.ERROR(13):A.FILNAM(A.FILCNT)
057 END
058 RETURN
059 201.2 * WRITE FILE 1
060 WRITE CONREC ON CONF,CONKEY
061 RETURN
* Main Line
117 GOSUB 201.11;* Read The Next Key
118 IF A.ERR NE NOVAL THEN A.ERR = NOVAL;CONREC = 1
119 AUDITKEY = CONREC
120 CONREC += 1
121 GOSUB 201.2;* Write The Next Key To Release

You can see that there is a subtle difference in the handling of the locked
clause. It is so long since I did it I can't remember the reason but there
definitely would be one. I suspect that it was because LOCKED needed an END
THEN
Peter McMurray

<opus600 (AT) comcast (DOT) net> wrote

Quote:

Good afternoon,

My company recently upgraded our 3rd party software to a Windows 2003
server running D3 PICK. We have about 60 users so we are not the
biggest PICK users in the universe.

Here is my issue:

Most everything updated on our system logs a note in our accounts. The
routine that adds these notes uses the following code to use a
sequential key to add the records:

040 RETRY.READ:
041 READU MSTITEM FROM MASTR1, "NOTEKEY" LOCKED
042 LOCK.CNT += 1
043 SLEEP 1
044 GOTO RETRY.READ
045 END ELSE
046 MSTITEM = ''
047 END
048 MSTITEM<2>=MSTITEM<2>+1
049 WRITE MSTITEM ON MASTR1, "NOTEKEY"
050 RELEASE MASTR1, "NOTEKEY"

The problem is simple-we end up with records being overwritten when
usage gets the least bit heavy. I put some tracing steps in the
routine and found the same key is being used by seperate processes
when updating. All I can figure is that both processes are trying to
lock the record at the same time and both end up with access to the
record creating duplicate keys.

Any ideas/suggestions/discussion on this would be greatly appreciated!

Thanks,

Walt

#9

I'm can be lazy. Add the port to the key and
the problem should go away. I know it could add
other issues. but a G*1 (if '*' is the delimiter)
added to the dictionary and field function should
make the issue go away.

Patrick, <;=)

P.S. Tony is not going to like this one.

opus600 (AT) comcast (DOT) net wrote:

Quote:

Good afternoon,

My company recently upgraded our 3rd party software to a Windows 2003
server running D3 PICK. We have about 60 users so we are not the
biggest PICK users in the universe.

Here is my issue:

Most everything updated on our system logs a note in our accounts. The
routine that adds these notes uses the following code to use a
sequential key to add the records:

040 RETRY.READ:
041 READU MSTITEM FROM MASTR1, "NOTEKEY" LOCKED
042 LOCK.CNT += 1
043 SLEEP 1
044 GOTO RETRY.READ
045 END ELSE
046 MSTITEM = ''
047 END
048 MSTITEM<2>=MSTITEM<2>+1
049 WRITE MSTITEM ON MASTR1, "NOTEKEY"
050 RELEASE MASTR1, "NOTEKEY"

The problem is simple-we end up with records being overwritten when
usage gets the least bit heavy. I put some tracing steps in the
routine and found the same key is being used by seperate processes
when updating. All I can figure is that both processes are trying to
lock the record at the same time and both end up with access to the
record creating duplicate keys.

Any ideas/suggestions/discussion on this would be greatly appreciated!

Thanks,

Walt

#10

The code you showed us seems perfectly appropriate for what you are trying
to do

Which release of D3/NT?

Try this:

WRITEU MSTITEM ON MASTR1,"HOTEKEY"
RQM
RELEASE MASTR1,"NOTEKEY"

There seems to be a timing issue, if EVERY program uses this same routine to
get a note key and two or more are getting the same number. That would
indicate that the lock was not holding long enough for the group to be
updated before the next read attempts to get it.

As someone else pointed out, the regular WRITE will clear the lock,
supposedly AFTER the group has been shifted. The WRITEU will update the
record without clearing the lock. Then, after another time slice, release
the lock manually.

I'd also suggest a quick FIND of the TCL-STACK file to make sure someone
hasn't discovered the CLEAR-LOCKS command and found their stuff works
faster if they use it a lot.

READU is one of those things that has worked since day 1. I find it hard to
believe it's broken at this late date. Is the file an FSI file or VME? It
seems to me that there was a different between "local" and "remote" locks.

Mark Brown

Quote:

opus600 (AT) comcast (DOT) net wrote:
Good afternoon,

My company recently upgraded our 3rd party software to a Windows 2003
server running D3 PICK. We have about 60 users so we are not the
biggest PICK users in the universe.

Here is my issue:

Most everything updated on our system logs a note in our accounts. The
routine that adds these notes uses the following code to use a
sequential key to add the records:

040 RETRY.READ:
041 READU MSTITEM FROM MASTR1, "NOTEKEY" LOCKED
042 LOCK.CNT += 1
043 SLEEP 1
044 GOTO RETRY.READ
045 END ELSE
046 MSTITEM = ''
047 END
048 MSTITEM<2>=MSTITEM<2>+1
049 WRITE MSTITEM ON MASTR1, "NOTEKEY"
050 RELEASE MASTR1, "NOTEKEY"

The problem is simple-we end up with records being overwritten when
usage gets the least bit heavy. I put some tracing steps in the
routine and found the same key is being used by seperate processes
when updating. All I can figure is that both processes are trying to
lock the record at the same time and both end up with access to the
record creating duplicate keys.

Any ideas/suggestions/discussion on this would be greatly appreciated!

Thanks,

Walt