Hey,
George S. asked for input about how good a development platform UD on a
Sun Sparc is.
I like that platform myself. I would think its a little better,
economically, than say an RS6000 these days, but I haven't compared of
late. I would for sure take UniData or UniVerse on Solaris before I
deployed on wIndoze, much more stable (is it NOT(PC) to say
this?)[...sorry for the dbl pun.] Perhaps, if a windoze shop is more
familiar with NT style admin and printing and not wanting to learn *nix
tools for this, UV on Win is a good fit, if it will make them consider
an MV db.
What does anyone else have to say?
I know Pick Professionals in St Louis use the Solaris platform quite a
bit, although now also a certified MS shop. They might be contacted
www.pickpro.com for their take on the question (no royalties rec'd for
plug.)
-Baker
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bob Woodward
Sent: Thursday, September 14, 2006 10:39 AM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] Debugging a program using distributed files causes
core dump
How about a bad data record? If I was the one running this, I'd be
putting in a number of DISPLAY statements at key points, like a before
and after message on statements like WRITEs or CALLs. Probably on
READs, too, ensuring you show the record key in the before message.
Then let it rip! If you put the displays in correctly, you should be
able to pin down where in your program you're hitting your bump in the
road. I use things like POINT 1, KEY=xxx and POINT 1, EXIT You
just increment the 1 for each pair. Be sure to keep in mind when you
complete a loop that you may not get to your EXIT message.
BobW
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brenda Price
Sent: Thursday, September 14, 2006 7:13 AM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] Debugging a program using distributed files causes
core dump
This happens in 2 different programs. Straight compile and local
catalog, no options with DEBUG statements embedded in the code. Then
the program is executed, processing stops when it hits the debug, I step
through the program until I get to where I want to it continue and hit C
to continue. Sometimes it is am immediate dump, sometimes a few seconds
later. If I am only working with a small list of items, then it does
not happen. If I have selected the whole file it does. I do not use
RAID to run the program. In one program the indices are turned off when
I am debugging it. The other program just reads the records in the file
and does calculations on the data as it is verifying the conversion
data.
The first program builds the data in the DF files, reads and writes.
The second does a sort select of one of the files, then readnext loops.
Brenda
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, September 13, 2006 8:18 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] Debugging a program using distributed files causes
core dump
Does the process continue through a program where the source file
is
pointing to the object file ... like the DF algorithm ... the
debugger
could maybe be trying to display or traverse binary where it
expects
source? Or through a program compiled with source symbols
suppressed
or raid suppression on or source code removed?? Just some
random
thoughts.
Stuart Boydell
---
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/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
