Tedd Scofield wrote:
Attribute 9 and 10 have been swapped. I imagine that could cause problems.

Luke

I really hate it when I do that!

Thanks much Luke, that was the problem.

Not knowing squat about SB+. but couldn't you just do a compile (ow to
compile the core SB+ stuff ?

On most sites we set it to zero to "disable" the feature ..... that
said, in the past month one of our support guys did a LOGOFF of a
pocess and recalimed 1Gb of disk space :-)

Still, I think our users would "freak" if they were presented with this
question

Ross Ferris wrote:
Indeed, but I'm always a little leery of some of the Flash-related
incompatibilities. You can work around 'em if you have source code, but
you're pretty well boned if they crop up in code for which you have no
source.

In any case, I'd be scared spitless at the prospecy Flashing the entire
body of a large and (thinking of one client in particular) ramshackle
app, and SB just adds to the fear factor.

Luke

Ross Ferris wrote:
Sounds like a good call. How often is this message actually valid
anyway? Probably only when runnng a new, untested program.

Luke

Ross Ferris wrote:

I think it's worthwhile having it set on D3/NT systems, since most user
data is in the FSI and the VME is comparatively small - only being used
for workspace, holdfiles, etc.

I would much rather hit the runaway limit than run out of VME space on
these systems. :-)


--
Kevin Powick

I dunno guys, I get leary of simply disabling system warnings unless I
know that they're useless (like an un-tuned syschk).

For Linux, consider that the frame size is now double what it used to
be, 4k, so rather than a default of 7000x2k=14MB the warning now
displays at 7000x4k=28MB. For the average site, if you have ANY
process consuming 28MB of overflow without doing a disk write, then
something is up! Unless you are truly dealing with a file with over
1-2 million records (with a key in excess of 14 characters), then
there is little chance you're going to see the warning on a simple
select with the default setting. Rather than turning off the limit,
based on the new frame size I would even recommend smaller sites turn
it down to about 3000! (3000x4k=12M ... should be plenty!)

So what trips the limit? It's massive disk activity with no disk
writes. Yes, while not a preferred behavior it seems reasonable that
a large \execute "select...\ or especially a SSelect will trip this.
However - if you're doing a SSelect on a file that massive then maybe
you should be working with indices rather than sselecting the entire
file. I know there are subtleties here, but massive Selects and
SSelects are operations on smaller files. If you find you're tripping
massive limits then maybe that's a warning to review your architecture
- especially for performance.

In a larger site, I agree that it's a pain to tune the limit up or
down based on which file is being selected, and it may be easier to
just turn it off, but again I get uptight about such things.

Luke is right that it's "usually" only systems in development that
will runaway with overflow, but other things can trip it too:
- An error in upgrade or patch code may generate runaways. Do you
trust RD so much that you're sure they won't introduce a bug that will
chew up your (your clients'!) disk space?
- Some error by a user or bogus data from a trading partner in an FTP
routine or EDI might result in an infinite loop. Sure you can code
against such things, but how many of you really code against your
trading partners suddenly sending you 10 million orders over the
weekend?

I'm not firmly on either side of the fence here, just advising against
blatent action that may cause problems down the line.

T


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

Tony Gravagno wrote:

Agreed, unfortunately, indexes on D3/NT have a history of unreliability.

The good news is that we offload a lot of D3 data to a MySQL data
warehouse that makes creating modern reporting facilities a dream.

--
Kevin Powick