Check it out. SSELECT on this particular file results in no items selected.

:COUNT MY-FILE
[407] 27 items counted out of 27 items.

:SELECT MY-FILE
[404] 27 items selected out of 27 items.

:SSELECT MY-FILE
[401] no items present.

Doesn't happen on all files. Actually, this is the first time I've
ever seen it happen.

If I copy the items in this file to another file, the other file works
fine. I then cleared MY-FILE, copied the items back, and still had the
same problem with MY-FILE.

I deleted and re-created MY-FILE, then copied the items back into it.
All was well.

System Release Information
==========================
D3 Release Version 7.5.5.NT

Implementation. . . . . . NT
Software Serial Number. . *****
System ID Number . . . . *****
Release . . . . . . . . . D3
Windows Information . . . WindowsNT;pick0;5.2.3790;;5.2

Notice:
------
No DATA ABS assigned to process

--
Kevin Powick

This can happen in any D3 release, where the file comes from a prior
release or another system where the hashing algorithm is different.

Count faithfully counts items.
Select faithfully reads whatever is there.

SSelect gets the item IDs and then tries to validate that list against
the existing file. But if an ID isn't hashed properly, the read will
fail even if the item exists "somewhere" in the file.

Yes, save/restore of the file should work because the items get
re-hashed into new, proper locations.

T


Kevin Powick wrote:

On 2010-12-03 23:44:25 -0500, Tony Gravagno <nospam (AT) nospam (DOT) invalid> said:

How would a file come from a prior release without getting re-hashed
upon creation/load into a current release?

Regardless, this is not the case with the file in question. It's been
around and working fine for a long time. No idea why it suddenly
developed this glitch. Having never run into this before, ever, I
thought it might be release related.

--
Kevin Powick

"Kevin Powick" wrote
'disables the "fast" restore'

I'm guessing part of what it suppresses is some sort of hash-list provided
on tape by the file-save.

I plan to use (F _from_now_on_ whenever I restore into d3/nt from any
tape made on d3/linux.

I can see how this flag would be needed when coming
from a different frame-size release of d3/nt, too.

If you write a program to detect_and_correct this situation on all your files
each night, you'll have the problem that delete-file / create-file operations
are 'cached' somewhat until you log off, in D3/NT.

I wonder if you could work around that by
stacking up a list of work to do in an item and then
issuing a command
LOGON 101, demon-guy, demon-please, DM, dm-hello
101 is a pick port number that exists but is not logged on right now,
demon-please is the password to that demon-guy USERS account,
DM is the mds account you want the userid DEMON-GUY to run in,
dm-hello is the password for the mds account DM

The item demon-guys-md,md, "demon-guy" would be a macro or proc
that invokes the command to process that list of work to do.

Maybe you could set up a pick port in a spare telnet window
on system console, but leave it at the logon prompt, so you can view any
messages that result {adjust the 101 to whatever pick port that window is on.}

....Or even a background job might be 'detached' enough to end that caching...

On 2010-12-04 16:38:22 -0500, Tony Gravagno <nospam (AT) nospam (DOT) invalid> said:

Umm, what administrative error do you suggest I committed? I had a
system working fine for years that, without explanation, developed some
type of hashing problem on a single file. A problem that I have never
encountered in Pick/D3 in over 20 years of using the product.

--
Kevin Powick

On Dec 5, 2:44*pm, Kevin Powick <nos... (AT) spamless (DOT) com> wrote:
Kevin,

Is the file indexed? Wondering if the index got clobbered .... could
just be a case of recreating the index (SSelect probably uses the
[possibly corrupt] index ... I'm guessing the same bad result with
SORT)

On 2010-12-05 17:53:07 -0500, Ross Ferris <rossf (AT) stamina (DOT) com.au> said:

No.

--
Kevin Powick

Kevin Powick <nospam (AT) spamless (DOT) com> wrote:

I'm not trying to point any fingers, bud. I'm just saying to Frank or
whomever that this isn't a reason to go to the vendor for some new
utility.

"Something" caused the items to hash improperly. I've seen this
before and it's almost always when data is imported somehow, or maybe
when someone creates a funky pointer into the file space. If it was a
server error, you can deal with it. If it was an operational error,
you can deal with it. You may call the vendor or you may not. My
point was that this wasn't a reason to ask the vendor to write new
software, we can deal with the problem without them. Addressing the
cause needs to be done "elsewhere".

Backing away quietly...
T

I have seen this "mis-hashed" problem on all platforms, going back to
R83, Mentor, GA, as well as Universe and D3. However, I don't think
that's the problem here:

If this was a mis-hashing issue, then the above should have fixed it.
Since clearing the file didn't fix it, but deleting and re-creating
the file did, I think the problem might be related to case-sensitivity
and how the D-pointer of the file was set up (e.g. DS?) I would have
liked to see the results of

:select my-file
....which would list the "missing" item-ids as "[202] 'xxx' not on
file" messages.

/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

I've seen D3/NT do enough "funky" things all by itself .... ESPECIALLY
in the FSI.

I know LOT'S of people have no problem with D3/NT/Windows .... but I'm
not one of them! If it wasn't for the stability of D3/Linux we would
have hit the wall years ago dealing with the issues --> must be
something to do with the way we write code and features we (try to)
use :-)