 | |
#1
 
| |||
| |||
|
Who has the lock? -
11-07-2011
, 02:55 PM
#2
| |||
| |||
|
|
I actually have to ctrl-\ and END to even get the results to the screen. There are hundreds of the same entry with no PIB# to reference. Any idea what caused this or how to fix it short of a restart?? |
In general, when you see output from a verb that doesn't look right,
see if you can get to the source of the code to diagnose the problem
on your own:
CT MD verb
(Or use ED, UP, WED, or any tool you wish)
If that's a program, in D3NT chances are high that the program will
eventually call to a NT equivalent.
Case in point ... The list-locks verb on D3NT calls to nt_list-ilocks,
the source for which is found in dm,bp.
In that program you'll see that the data for locks comes from an
undocumented function called %ListItemLocks().
You'll also see that it checks for known type values to display the
lock type. If the lock type is unknown it sets it to null, which is
what you're seeing in your report. Try displaying that lock type,
rather than nulling it out, to see what it is. It's possible that in
D3 7.5.7 there is a different lock type and this utility was never
updated to display it.
Later in the code you'll see that the buffer consists of one attribute
per lock, where specific values and subvalues of each attribute
provide the data displayed. I'm wondering if you have item IDs that
have a value or subvalue mark. This would cause the results you're
seeing. Increase the display for the item ID so that you can see the
whole ID. Change Buffer<i,3> "L#19 " to Buffer<i,3> "L#50 " and
change your term type to display 132 characters if required. You can
also open a temp file and write Buffer, then edit the item to see if
there are system delimiters where they shouldn't be.
To find bad items in your invdet file, use the program on my freeware
page listed as "Find Bad Characters":
nospam.pleaseNebula-RnD.com/freeware/
As a long shot, the code puts the results into a buffer that is 51200
bytes. I don't know if this is valid but you could try increasing
that significantly to accommodate more of the lock data. That code is
supposed to loop to read all lock data, but it could be breaking after
the first execution, causing an infinite loop which you then need to
break to exit. If I were you I'd follow what I said above, dump the
output into an item, save the item on every loop, and check what's at
the bottom of that item when it goes into its infinite loop. (Careful
not to let it run away with disk.)
So - If your data is good then something is up with %ListItemLocks()
and you'll need TL to diagnose that for you. Forums are a good place
to trade notes about how to use a system, but when something internal
starts to look weird, the most expedient path to resolution is through
official support providers like your VAR or TL. I'm guessing with the
above info you may not need them for this one.
HTH
T
#3
| |||
| |||
|
|
ck wrote: I actually have to ctrl-\ and END to even get the results to the screen. There are hundreds of the same entry with no PIB# to reference. Any idea what caused this or how to fix it short of a restart?? In general, when you see output from a verb that doesn't look right, see if you can get to the source of the code to diagnose the problem on your own: * CT MD verb (Or use ED, UP, WED, or any tool you wish) If that's a program, in D3NT chances are high that the program will eventually call to a NT equivalent. Case in point ... The list-locks verb on D3NT calls to nt_list-ilocks, the source for which is found in dm,bp. In that program you'll see that the data for locks comes from an undocumented function called %ListItemLocks(). You'll also see that it checks for known type values to display the lock type. *If the lock type is unknown it sets it to null, which is what you're seeing in your report. *Try displaying that lock type, rather than nulling it out, to see what it is. *It's possible that in D3 7.5.7 there is a different lock type and this utility was never updated to display it. Later in the code you'll see that the buffer consists of one attribute per lock, where specific values and subvalues of each attribute provide the data displayed. *I'm wondering if you have item IDs that have a value or subvalue mark. *This would cause the results you're seeing. *Increase the display for the item ID so that you can see the whole ID. *Change Buffer<i,3> "L#19 " to Buffer<i,3> "L#50 " and change your term type to display 132 characters if required. * You can also open a temp file and write Buffer, then edit the item to see if there are system delimiters where they shouldn't be. To find bad items in your invdet file, use the program on my freeware page listed as "Find Bad Characters": nospam.pleaseNebula-RnD.com/freeware/ As a long shot, the code puts the results into a buffer that is 51200 bytes. *I don't know if this is valid but you could try increasing that significantly to accommodate more of the lock data. *That code is supposed to loop to read all lock data, but it could be breaking after the first execution, causing an infinite loop which you then need to break to exit. *If I were you I'd follow what I said above, dump the output into an item, save the item on every loop, and check what's at the bottom of that item when it goes into its infinite loop. *(Careful not to let it run away with disk.) So - If your data is good then something is up with %ListItemLocks() and you'll need TL to diagnose that for you. *Forums are a good place to trade notes about how to use a system, but when something internal starts to look weird, the most expedient path to resolution is through official support providers like your VAR or TL. *I'm guessing with the above info you may not need them for this one. HTH T |
However, I am cautious. The problem does seem to be coming from the
nt_list-ilocks command. If I run the command from TCL I get the
infinite list. I have contacted our VAR and will try to work with them
to get this sorted out. Thanks for the info and for reminding me how
little I really know about PICK <g>
Chris
#4
| |||
| |||
|
|
D3/NT - Version 7.5.7.NT I use the list-locks command so I can see who is holding things up by not getting out of items. Lately there appears to be a file locked: FSI Filename * * * *PIB# *Lvl *Type *Item-id * * * * * * Token djan4,jobs,jobs * * * *3 * *1 *VME * 101/6314 * * ** * *91298144 djan4,labor-file,la * *2 * *1 *VME * 1707*16014*1 * * **135996364 djan4,invdet,invdet * * * * * * * * *101/6307-1-J-J-J-J- 166926680 djan4,invdet,invdet * * * * * * * * *101/6307-1-J-J-J-J- 166927180 djan4,invdet,invdet * * * * * * * * *101/6307-1-J-J-J-J- 166927680 djan4,invdet,invdet * * * * * * * * *101/6307-1-J-J-J-J- 166928180 djan4,invdet,invdet * * * * * * * * *101/6307-1-J-J-J-J- 166928680 I actually have to ctrl-\ and END to even get the results to the screen. There are hundreds of the same entry with no PIB# to reference. Any idea what caused this or how to fix it short of a restart?? TIA Chris |
locks on the records of this file.
Write a short loop routine the tries to lock each record and track
which ones are locked or will not lock. Then compare the list to the
output of the list-locks verb.
This will tell you if it's a error with the list-locks verb or
something else wrong with the locks on the file. You would want to
know this because if you DO have unreleased lock, you probably have a
code issue in one of your programs that will need to be sought out and
corrected.
SJJ
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.