I will be out of the office starting 17/12/2004 and will not return until
20/12/2004.
I will respond to your message when I return.
IMPORTANT NOTICE : The information in this email is confidential and may also
be
From: [EMAIL PROTECTED]
I'm not sure how different they are - they hadn't been
changed in a while.
The windows version is a simple setup.exe install.
Here are some hints for installing on Linux:
http://www.pickwiki.com/cgi-bin/wiki.pl?Redhat8UD6PEInstallInfo
--
Wendy Smoak
---
From: Brutzman, Bill [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, December 17, 2004 10:56 AM
Subject: [U2] Data Corruption
There lives a new record in our OP table that shows up as INVISIBLE from a
TCL prompt.
snip
Suggestions would be appreciated.
If your OP table isn't too large,
UniData? UniVerse? Version? I can supply some hints if UniData.
Wally Terhune
Manager - U2 Advanced Technical Services
IBM DB2 Information Management Software
Tel: 303.294.4866 Fax: 303.294.4832
[EMAIL PROTECTED]
www.ibm.com/software/data/u2/support - Open, Query, Update, Search -
Can you select it? If you can select it then you can do a tcl delete on it.
I've had to get rid of null records this way.
SELECT A.FILE =
1 ITEM SELECTED
DELETE A.FILE
Test this first make sure I have the commands right. I am always paranoid using
the delete command.
Thanks,
Marilyn
The problem is on our UniVerse v8.3.3 HP-UX box.
--Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Wally Terhune
Sent: Friday, December 17, 2004 11:24 AM
To: [EMAIL PROTECTED]
Subject: Re: [U2] Data Corruption
UniData? UniVerse? Version? I can supply
This might be the long way but something like;
SELECT OP WITH @ID GT 'SOMEVALUE TO SELECT ALL BUT THE BAD REC' TO A
SELECT OP TO B
GET.LIST A TO 1
GET.LIST B TO 2
MERGE.LIST 2 DIFF 1 TO 0
SAVE.LIST C ;* should be just the bad record here
GET.LIST C
COPY FROM OP TO HOLD OVW DELETING
Anthony
We have a NULL save list that we do a get-list and then edit with (if the key
is null).
If it's not actually null and there aren't too many records you could just ED
OP * and go through them all until you find it.
Of course, this assumes that there is no actual corruption of the file. In UD
Edit the record and delete it.
To be able to edit the record sselect the file first.
this is how I do it
Hope this help
Les
-Original Message-
From: Brutzman, Bill [mailto:[EMAIL PROTECTED]
Sent: 17 December 2004 15:56
To: '[EMAIL PROTECTED]'
Subject: [U2] Data Corruption
There lives
You might try SELECT OP WITH @ID=' ', followed by a DELETE. If that
don't work then try SELECT OP WITH @ID'~', followed by a DELETE. That
gets rid of all keys with a leading character outside the printable
ASCII set, and may get rid of your mysterious record.
Allen Egerton wrote:
From:
Brutzman, Bill
There lives a new record in our OP table that shows up as
INVISIBLE from a TCL prompt.
Is it just a null key? Does:
:SELECT FILE.NAME WITH NO @ID
return anything?
The only way I've been able to delete items with weird keys is to get
them into a select list. Sometimes
Every once in a while on the old PICK systems I would run into a record with
a value mark in the ID. You couldn't just edit or delete it so what I'd do
is to select the record and with it as the only item in the list I could
then delete it.
These days, my users sometimes end up with a null ID in
You might try doing a SSELECT OP and the ED OP to see if the bad one comes
up or then do a SELECT OP BY-DSND @ID and an ED OP to see if it is at the
other end of the spectrum. If all of that fails do a SSELECT OP with a
SAVE.LIST JUNK then EDIT.LIST JUNK and so searching.
hth
Tom Dodds
[EMAIL
Victory...Wendy's fix nailed it...
SELECT OP WITH NO @ID
DELETE OP
Thanks to all those who responded.
--Bill
---
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/
As another option to try, write a program that uses the BASIC SELECT
statement, not the TCL SELECT. This way the program will step through
the group, grabbing each record ID one by one. After the READNEXT, test
for a key length not equal zero. This will handle a null key condition.
Next, do a
Bob Woodward [EMAIL PROTECTED] wrote:
As another option to try, write a program that uses the BASIC SELECT
statement, not the TCL SELECT. This way the program will step through the
group, grabbing each record ID one by one. After the READNEXT, test for a key
length not equal zero. This will
Here's a puzzler: what is it that causes the ELSE clause to be executed in a
WRITESEQ block when the only apparent change is the content of the data to
be written. I've included a section of code below followed by the output
from two subsequent calls. In the first, the code executes the THEN
How big exactly is the block of data you're trying to write? There is
no limit to each WRITESEQ (that I am aware of) but OS file size
limitations do apply.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dana Baron
Sent: Friday, December 17, 2004 11:11
Hi Dana,
Well, you're setting OK_TO_CONTINUE but never checking it...
Maybe something there.
Allen
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Dana Baron
Sent: Friday, December 17, 2004 10:11
To: U2-Users (E-mail)
Subject: [U2] [UD]WRITESEQ
Good day!
We created a duplicate account of our live system. The new account has
our programs and data files. We have a problem with the way programs are
executed.
Programs with $INCLUDE work fine. Programs with INCLUDE bomb out!We are
clueless as to what's going on.
My understanding
Hi Kevin,
Thanks for the reply. The data to be written is not very big. Its shown
below. It is HEX data, don't know if that makes a difference. This has been
working fine but suddenly its not, but only for one type of message, and I
don't know what changed. These are the messages that I'm writing
I've written some pretty big records/files with writeseq that I don't think
you're coming anywhere close to.
I use the else to notify me in case the system (writeseq append) isn't at the
end of the file where I think it should be.
Help says that: ELSE executes if the WRITESEQ is not
Could this be something like the difference between $INCLUDE and $INSERT ?
As I recall, $INCLUDE takes a pathname, whereas $INSERT takes a DIR name and
a record ID
$INCLUDE /u/source/somefile
vs.
$INSERT SOURCE somefile
(Where SOURCE is a DIR pointer in the VOC file pointing to /u/source)
If
As long as there is a valid file/id names. My point is that unless you are
checking OK_TO_CONTINUE you'll never know if maybe the filename is in a
write protected status or some other normally unforeseeable condition.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
I will be out of the office starting 17/12/2004 and will not return until
20/12/2004.
I will respond to your message when I return.
IMPORTANT NOTICE : The information in this email is confidential and may also
be
I will be out of the office starting 12/16/2004 and will not return until
01/03/2005.
Please contact Tricia Shelly x 6531 in my absence.
---
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/
Is BASICTYPE set the same on both? UD supports 4 different parsers: U,
P, R or M. From the ECL prompt, BASICTYPE by itself will tell
you which flavor the account is set to.
If that's OK, I'd compare the UDT.OPTIONS settings. From the ECL prompt,
UDT.OPTIONS by itself will display them all for
-Original Message-
Yes. same VOC same login.All UDT.OPTIONS the same.
Funny thing is that the new account has been working for weeks. Today, for
no reason it decided that it need the $INCLUDE.
--
Ah, but that's just it ... It wasn't for no reason. What's
I seem to remember on Unidata that you could also change the basictype 'on the
fly' in the individual program. Could it be the changing of the basictype in
the program(s) was added or removed?
Thanks,
Marilyn A. Hilb
Value Part, Inc
Direct: 847-918-6099
Fax: 847-367-1892
[EMAIL PROTECTED]
Right I agree with Allen that you should maybe check whether the OPEN was
successful. If it was NOT when the file SHOULD exist then you have some
problem. Perhaps the file is not getting released by some process and so is
not in an available state to be re-opened ?
It might be a timing
30 matches
Mail list logo
