RE: [U2] [UD] DISABLE.INDEX from BASIC

2005-08-25 Thread Kevin King
Nope.  Tried it with a couple different sessions and no change in
behavior. 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, August 24, 2005 8:22 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] [UD] DISABLE.INDEX from BASIC

In a message dated 8/24/05 3:59:23 PM Pacific Daylight Time,
[EMAIL PROTECTED] writes:

  I'll UPDATE.INDEX and do the LIST.INDEX again and  it says the
same thing again.  

Try logging off that session, then back on and try it again.
It might work now.  Maybe it holds an old pointer with the outdated
info.
Will
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] [UD] DISABLE.INDEX from BASIC

2005-08-25 Thread colin.alfke
What does the L_filename look like? It stores all of the records written
to the file while the index was disabled. Perhaps a permission issue on
it?

Is the file in use while you are doing this? The disable.index won't
come into effect on a file until it is closed in basic - perhaps that's
also true of enable.index. Perhaps a trigger on the file is keeping it
open.

The basic command INDICES() may also provide some more info/clues.

At this stage you may have to remove the index and rebuild it.

Sorry, not much help. Once I found the disable.index caused the entire
record to be written to the log each time it was updated I realized it
was not going to work for us. There was a problem with the udtsort.exe
and indexes - but I think that might have been an earlier version.

Colin Alfke
Calgary, AB

-Original Message-
From: Kevin King

Is there a BASIC equivalent to the DISABLE.INDEX TCL command 
on Unidata 5.2?
 
I have a weird situation at a client site now where I'll do a 
LIST.INDEX on a particular file and it'll say Enabled, 
Indices require updating, I'll UPDATE.INDEX and do the 
LIST.INDEX again and it says the same thing again.  I've 
searched through ever scrap of code I can find to see if 
there's a program writing to this file that is turning off the 
automatic updates or writing somehow without the index update, 
and I can't find DISABLE.INDEX or ENABLE.INDEX anywhere in code.
 
Any ideas?
 
-Kevin
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


Re: [U2] [UD] DISABLE.INDEX from BASIC

2005-08-25 Thread FFT2001
In a message dated 8/25/2005 6:09:05 AM Pacific Standard Time,  
[EMAIL PROTECTED] writes:

Nope.  Tried it with a couple different sessions and no change  in
behavior. 


delete index then create it again?
Maybe the index is screwy from some craziness in the past.
Will
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] [UD] DISABLE.INDEX from BASIC

2005-08-25 Thread colin.alfke
No problems. What about putting a wrapper around the disable.index
command to log how it's being run?

What about ODBC access to the account? I'm not sure what it can do to
the index but

Colin Alfke
Calgary, AB

-Original Message-
From: Kevin King

No triggers, thanks.  But you may have hit on something.  What 
if someone disabled the index, then a program opened the file, 
the index was enabled, but the program still has that file 
open and thinks the index is still disabled?  That might 
explain a great deal.

I have removed the index and rebuilt it - several times.  I've 
deleted the X item from AIX and started the whole deal all 
over.  No change.

Today, the DISABLE.INDEX command is temporarily MIA.  This is 
to rule out someone manually entering this command.  And now we watch.

Thanks for the ideas.  I appreciate the feedback.

-Kevin
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] [UD] DISABLE.INDEX from BASIC

2005-08-25 Thread Kevin King
I'm considering the wrapper idea, but I figure it's easier to put it
under an arcane name for a day or so just to watch.  And I've
confirmed no ODBC access to this particular file. 

So far so good.  Couple of hours now and no problems.  Perhaps it was
that DISABLE.INDEX and then the file got opened by BASIC - SB+ BASIC
at that, so you know those file buffers may have stayed open like
forever...

-K

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, August 25, 2005 8:08 AM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] [UD] DISABLE.INDEX from BASIC

No problems. What about putting a wrapper around the disable.index
command to log how it's being run?

What about ODBC access to the account? I'm not sure what it can do to
the index but
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] [UD] DISABLE.INDEX from BASIC

2005-08-25 Thread Kevin King
No triggers, thanks.  But you may have hit on something.  What if
someone disabled the index, then a program opened the file, the index
was enabled, but the program still has that file open and thinks the
index is still disabled?  That might explain a great deal.

I have removed the index and rebuilt it - several times.  I've deleted
the X item from AIX and started the whole deal all over.  No change.

Today, the DISABLE.INDEX command is temporarily MIA.  This is to rule
out someone manually entering this command.  And now we watch.

Thanks for the ideas.  I appreciate the feedback.

-Kevin
[EMAIL PROTECTED]
http://www.PrecisOnline.com

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, August 25, 2005 6:59 AM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] [UD] DISABLE.INDEX from BASIC

What does the L_filename look like? It stores all of the records
written to the file while the index was disabled. Perhaps a permission
issue on it?

Is the file in use while you are doing this? The disable.index won't
come into effect on a file until it is closed in basic - perhaps
that's also true of enable.index. Perhaps a trigger on the file is
keeping it open.

The basic command INDICES() may also provide some more info/clues.

At this stage you may have to remove the index and rebuild it.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] [UD] DISABLE.INDEX from BASIC

2005-08-25 Thread Kevin King
Okay, it's definitely NOT DISABLE.INDEX.  The problem has occurred
again, but with a slightly different manifestation.

LIST.INDEX shows the indexes are enabled, built, and no updates
pending.  However, when I select the file using that indexed field, I
get nothing.  If I disable the index and execute the exact same select
statement, I get 28 records.

Here's the selection statement, and yes, it's Prelude:

SELECT BIN.QUEUE WITH BTREE_DEFAULT = 001!002!O]

Again, this is UD 5.2 on AIX, and DISABLE.INDEX isn't even around as a
verb from TCL.

-Kevin
[EMAIL PROTECTED]
http://www.PrecisOnline.com
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] [UD] DISABLE.INDEX from BASIC

2005-08-25 Thread Kevin King
Sorry dude, been there, done that, bought the shirt.  I've done this
exact sequence dozens of times and the problem persists. 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Baakkonen,
Rodney
Sent: Thursday, August 25, 2005 11:00 AM
To: 'u2-users@listserver.u2ug.org'
Subject: RE: [U2] [UD] DISABLE.INDEX from BASIC

IT sounds like it is time to do a 'DELETE.INDEX', 'CREATE.INDEX',
'BUILD.INDEX'. There must be something out of sync and you may never
figure out the why. We have had indexes that produced different
results when using 'REQUIRE.INDEX' and 'NO.INDEX'. The only way to go
forward was to rebuild.
We now have a database of our Unidata indexes and a program to do this
rebuild if the need arises. - Rod

-Original Message-
From: Kevin King [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 25, 2005 11:12 AM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] [UD] DISABLE.INDEX from BASIC


Okay, it's definitely NOT DISABLE.INDEX.  The problem has occurred
again, but with a slightly different manifestation.

LIST.INDEX shows the indexes are enabled, built, and no updates
pending.  However, when I select the file using that indexed field, I
get nothing.  If I disable the index and execute the exact same select
statement, I get 28 records.

Here's the selection statement, and yes, it's Prelude:

SELECT BIN.QUEUE WITH BTREE_DEFAULT = 001!002!O]

Again, this is UD 5.2 on AIX, and DISABLE.INDEX isn't even around as a
verb from TCL.

-Kevin
[EMAIL PROTECTED]
http://www.PrecisOnline.com
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.14/79 - Release Date:
8/22/2005
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] [UD] DISABLE.INDEX from BASIC

2005-08-25 Thread Kevin King
Okay, here's some specifics about the problem I'm experiencing:

Alternate Key Index Details for File BIN.QUEUEPage   1

 

File..  BIN.QUEUE

Alternate key length..  35

Node/Block size...  4K

OV blocks.  1 (0 in use, 0 overflowed)

Indices...  1 (0 D-type)

Index updates.  Enabled, No updates pending

 

Index-Name..  F-type K-type Built Empties Dups In-DICT S/M
F-no/VF-expr 
BTREE_DEFAULT V  TxtYes   Yes Yes  Yes M
OCONV(@ID,G0!5 
   )

---

Keys in this file look like this:

---

LIST BIN.QUEUE 11:49:34 AUG 25 2005 1

BIN.QUEUE.

 

001!001!O!13738!AAL2C!AAL2C

001!001!C!13591!XL2C!XL2C

001!001!C!13591!XM2A!XM2A

001!001!C!13591!XN3C!XN3C

001!001!C!13591!XO3A!XO3A

001!001!C!13591!XP2B!XP2B

001!001!C!13591!XP4C!XP4C


---

Therefore, given that BTREE_DEFAULT is OCONV(@ID,G0!5) these two
SELECT statements should return the exact same results:

---

:SELECT BIN.QUEUE WITH BTREE_DEFAULT = 001!001]

 

671 records selected to list 0.

 

CLEARSELECT

 

:SELECT BIN.QUEUE WITH @ID = 001!001]


638 records selected to list 0.


---

And as you can see, they return different things.

And immediately after this test and a subsequent CLEARSELECT: 

---

Alternate Key Index Details for File BIN.QUEUEPage   1

 

File..  BIN.QUEUE

Alternate key length..  35

Node/Block size...  4K

OV blocks.  1 (0 in use, 0 overflowed)

Indices...  1 (0 D-type)

Index updates.  Enabled, No updates pending

 

Index-Name..  F-type K-type Built Empties Dups In-DICT S/M
F-no/VF-expr 
BTREE_DEFAULT V  TxtYes   Yes Yes  Yes M
OCONV(@ID,G0!5 
   )

---

Note the Enabled, No updates pending.  Then following a BUILD.INDEX
BIN.QUEUE ALL:

---

:BUILD.INDEX BIN.QUEUE ALL

 

One * represents 1000 records

 

Building BTREE_DEFAULT ...

 

 671 record(s) processed.


:SELECT BIN.QUEUE WITH @ID = 001!001]

 

 

642 records selected to list 0.

 

CLEARSELECT

 

:SELECT BIN.QUEUE WITH BTREE_DEFAULT = 001!001]

 

642 records selected to list 0.

 




And though it was corrected via the BUILD.INDEX, it won't last.
Here's what's sitting @ AIX:

$ ls -l *BIN.QUEUE

-rwxrwxrwx   1 root ud   278528 Aug 25 11:55 BIN.QUEUE

-rwxrwxrwx   1 root ud49152 Aug 24 13:01 D_BIN.QUEUE

-rwxrwxrwx   1 root ud   110592 Aug 25 11:54 X_BIN.QUEUE

$

Though I didn't illustrate it, there was no L_ item prior to the
BUILD.INDEX.  And unfortunately I can't change the programming to
factor out this index due to the way the vendor application has been
programmed.  Getting this index to be reliable seems to be the only
solution.

Also there are no triggers on this file.

Help?

P.S. Are there any logs available in Unidata that might illustrate
some faults in the indexing processor?

-K
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] [UD] DISABLE.INDEX from BASIC

2005-08-25 Thread Baakkonen, Rodney
To the point where the actual file holding the indexes was deleted and
created (X_ or idx)?

-Original Message-
From: Kevin King [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 25, 2005 1:41 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] [UD] DISABLE.INDEX from BASIC


Sorry dude, been there, done that, bought the shirt.  I've done this
exact sequence dozens of times and the problem persists. 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Baakkonen,
Rodney
Sent: Thursday, August 25, 2005 11:00 AM
To: 'u2-users@listserver.u2ug.org'
Subject: RE: [U2] [UD] DISABLE.INDEX from BASIC

IT sounds like it is time to do a 'DELETE.INDEX', 'CREATE.INDEX',
'BUILD.INDEX'. There must be something out of sync and you may never
figure out the why. We have had indexes that produced different
results when using 'REQUIRE.INDEX' and 'NO.INDEX'. The only way to go
forward was to rebuild.
We now have a database of our Unidata indexes and a program to do this
rebuild if the need arises. - Rod

-Original Message-
From: Kevin King [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 25, 2005 11:12 AM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] [UD] DISABLE.INDEX from BASIC


Okay, it's definitely NOT DISABLE.INDEX.  The problem has occurred
again, but with a slightly different manifestation.

LIST.INDEX shows the indexes are enabled, built, and no updates
pending.  However, when I select the file using that indexed field, I
get nothing.  If I disable the index and execute the exact same select
statement, I get 28 records.

Here's the selection statement, and yes, it's Prelude:

SELECT BIN.QUEUE WITH BTREE_DEFAULT = 001!002!O]

Again, this is UD 5.2 on AIX, and DISABLE.INDEX isn't even around as a
verb from TCL.

-Kevin
[EMAIL PROTECTED]
http://www.PrecisOnline.com
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.14/79 - Release Date:
8/22/2005
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] [UD] DISABLE.INDEX from BASIC

2005-08-25 Thread Kevin King
Deleted via DELETE.INDEX, removed via rm, and verified via ls. 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Baakkonen,
Rodney
Sent: Thursday, August 25, 2005 1:20 PM
To: 'u2-users@listserver.u2ug.org'
Subject: RE: [U2] [UD] DISABLE.INDEX from BASIC

To the point where the actual file holding the indexes was deleted and
created (X_ or idx)?
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] [UD] DISABLE.INDEX from BASIC

2005-08-25 Thread colin.alfke
That's precisely how it presented to us. If it was built on an earlier
version it would update OK - but as soon as we rebuilt it just wasn't
right.

Other ideas:

Check the *log files in @udthome/bin. Likely udt.log, udt.errlog, not
sure if 5.2 had udtsort.log?

Make sure you have enough space in /tmp (@udttmp) as the index needs it.
Usually you get an error though if it runs out of space.

If the rebuild didn't work when everyone was off (and you made sure it
was deleted at the Aix level) then you could delete the index (make sure
it's gone) copy all of the records out of the file. Re-create the index,
copy all of the records back in.

I did notice that it looks like the index is defined as a M though it
looks like it should be an S. Try re-saving the dict item in SB+, make
sure 6 of the UD dictionary is S and then delete and re-create the
index - while everyone is off.

Good luck

Colin Alfke
Calgary, AB

-Original Message-
From: Kevin King

I've tried rebuilding the index both while the users are 
logged on, and when the users are logged off, and the problem 
persists.  We've even rebooted.  I've recommended to the 
client they need to contact the vendor (which is their only 
path to IBM) so we'll see where that gets us.  What's weird is 
that this worked just fine until a few days ago.  I rebuilt 
the index via BUILD.INDEX and trouble started. 
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] [UD] DISABLE.INDEX from BASIC

2005-08-25 Thread Kevin King
I've tried both the M and S.  I only left it M when I saw this index
working perfectly on another site using this same software.

Going spelunking for logs now.  Thanks.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, August 25, 2005 2:03 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] [UD] DISABLE.INDEX from BASIC

That's precisely how it presented to us. If it was built on an earlier
version it would update OK - but as soon as we rebuilt it just wasn't
right.

Other ideas:

Check the *log files in @udthome/bin. Likely udt.log, udt.errlog, not
sure if 5.2 had udtsort.log?

Make sure you have enough space in /tmp (@udttmp) as the index needs
it.
Usually you get an error though if it runs out of space.

If the rebuild didn't work when everyone was off (and you made sure it
was deleted at the Aix level) then you could delete the index (make
sure it's gone) copy all of the records out of the file. Re-create the
index, copy all of the records back in.

I did notice that it looks like the index is defined as a M though
it looks like it should be an S. Try re-saving the dict item in SB+,
make sure 6 of the UD dictionary is S and then delete and
re-create the index - while everyone is off.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] [UD] DISABLE.INDEX from BASIC

2005-08-25 Thread Kevin King
Nothing of consequence in the logs.  No udtsort.log, but I looked
through everything else matching *log. 

90% free on /tmp as reported by df.

And now it's stopped.  It did this yesterday also; stopped in the
afternoon and then came back at about 10am this morning.  Man, this is
some weird kung fu.

-K
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, August 25, 2005 2:03 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] [UD] DISABLE.INDEX from BASIC

Check the *log files in @udthome/bin. Likely udt.log, udt.errlog, not
sure if 5.2 had udtsort.log?

Make sure you have enough space in /tmp (@udttmp) as the index needs
it.
Usually you get an error though if it runs out of space.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] [UD] DISABLE.INDEX from BASIC

2005-08-25 Thread Kevin King
Thanks, but the index - for whatever reason - is on the first 5 of 6
! delimited fields in the key. 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Baakkonen,
Rodney
Sent: Thursday, August 25, 2005 2:55 PM
To: 'u2-users@listserver.u2ug.org'
Subject: RE: [U2] [UD] DISABLE.INDEX from BASIC

I guess I am going to have to pay more attention to this thread. So it
has to be data related if it can be rebuilt over and over. One thought
is that you have some control characters in the data to throw the
indexes for a loop. Not always easy to find. We actually found a
record today in a Unidata file with a CHAR(255) in it. I don't think
an index would like that. But you may have already covered that too.
We have about 1200 files indexed and never gotten to this point with
an index problem. I will be interested to see what you find. Good
luck. Rod

-Original Message-
From: Kevin King [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 25, 2005 2:58 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] [UD] DISABLE.INDEX from BASIC


Deleted via DELETE.INDEX, removed via rm, and verified via ls. 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Baakkonen,
Rodney
Sent: Thursday, August 25, 2005 1:20 PM
To: 'u2-users@listserver.u2ug.org'
Subject: RE: [U2] [UD] DISABLE.INDEX from BASIC

To the point where the actual file holding the indexes was deleted and
created (X_ or idx)?
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.14/79 - Release Date:
8/22/2005
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


[U2] [UD] DISABLE.INDEX from BASIC

2005-08-24 Thread Kevin King
Is there a BASIC equivalent to the DISABLE.INDEX TCL command on
Unidata 5.2?
 
I have a weird situation at a client site now where I'll do a
LIST.INDEX on a particular file and it'll say Enabled, Indices
require updating, I'll UPDATE.INDEX and do the LIST.INDEX again and
it says the same thing again.  I've searched through ever scrap of
code I can find to see if there's a program writing to this file that
is turning off the automatic updates or writing somehow without the
index update, and I can't find DISABLE.INDEX or ENABLE.INDEX anywhere
in code.
 
Any ideas?
 
-Kevin
[EMAIL PROTECTED]
http://www.PrecisOnline.com
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


Re: [U2] [UD] DISABLE.INDEX from BASIC

2005-08-24 Thread FFT2001
In a message dated 8/24/05 3:59:23 PM Pacific Daylight Time, 
[EMAIL PROTECTED] writes:

  I'll UPDATE.INDEX and do the LIST.INDEX again and
 it says the same thing again.  

Try logging off that session, then back on and try it again.
It might work now.  Maybe it holds an old pointer with the outdated info.
Will
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/