Flash compiled code

#21

Hi Art
Obviously a happy man. I have had two great days, the first was when we
were able to offer R83, maintenance costs plummetted and the second was when
we threw out the last Unix box with the same result.
The 2gb no longer applies I believe. However I moved to FSI with all the NT
file safety features as soon as it came out. That has been magic even when
some clown pulls the plug out all is recovered. Linux support in the bush -
forget it. However that is where I have clients. Of course some young tyro
can still screw things by installing patches without shutting down D3 - only
ever happened once - D3 was updated and all the accounts were there just
fine thanks to the FSI and NT. Funnily enough someone rebooted a SCO box on
us and nobody was ever able to fully recover it. All the experts were flown
in at great expense without result!!
The V8 machinery sounds pretty good to me and so long as good "x" support is
available why not go for it.
Peter McMurray

"art" <artmartz (AT) triad (DOT) rr.com> wrote

Quote:

Peter McMurray wrote:
Hi Art
Aint life grand. :-) We could make a great team, you do all the "X"
sites
and I'll do the others.
Peter McMurray

I guess I should elaborate a little, I don't like D3/NT because a) It
runs on Windows, and b) fsi is a kludge, necessary because the D3/NT vme
is limited to 2gb. And like most kludges, it is temperamental and prone
to breakage. I ran d3/nt on winXP on my development system (a Toshiba
laptop (100gb, nice screen)) and its predecessors, for several years, so
I have a little experience with d3/nt. One of the happiest days of my
business life was when I discovered I could run d3/linux on the Mandriva
linux side of the dual boot laptop. Now I rarely boot the windows side.
BTW, our main production system runs on RH ES4 on dual Xeon Intel.
Art

#22

On Mar 23, 9:56 am, "Jeffrey Kaufman" <jkauf... (AT) keydata (DOT) us> wrote:

Quote:

3) Debugger for non-flashed programs:
a) The debugger gets lost and cannot display the line it is executing (when
C is used) if the called subroutine is cataloged in a different file than
the calling program. An action was created.

Unless I am reading this wrong, I've always thought that to be less of
a "bug" and more of a "limitation of the feature".

In the olden days, you had to always tell the debugger specifically
where the source code is using the "Z" command. In later versions of
the debugger, they made it figure out where the source code is (or at
least try to) and it gets it right most of the time. But, when it
calls a subroutine cataloged in another file, that "feature" doesn't
properly track down the source code for you. So, you can just use the
"Z" command to pull in the source code the old-fashioned way.

*Z [FILENAME] [ITEMNAME]

Luke Bucklin
Sierra Bravo Corporation
http://www.sierra-bravo.com

#23

On Apr 26, 12:50 am, art <artma... (AT) triad (DOT) rr.com> wrote:

Quote:

Peter McMurray wrote:
Hi Art
Aint life grand. :-) We could make a great team, you do all the "X" sites
and I'll do the others.
Peter McMurray

I guess I should elaborate a little, I don't like D3/NT because a) It
runs on Windows, and b) fsi is a kludge, necessary because the D3/NT vme
is limited to 2gb. And like most kludges, it is temperamental and prone
to breakage. I ran d3/nt on winXP on my development system (a Toshiba
laptop (100gb, nice screen)) and its predecessors, for several years, so
I have a little experience with d3/nt. One of the happiest days of my
business life was when I discovered I could run d3/linux on the Mandriva
linux side of the dual boot laptop. Now I rarely boot the windows side.
BTW, our main production system runs on RH ES4 on dual Xeon Intel.
Art

Alternatively, you could also run D3/Linux on a virtual PC on the
windows platform (or visa-versa I suppose if you used VMware).
Performance has some "interesting" characteristics - it's
significantly faster to run out I/O THRASH routines on a virtual D3/
Linux machine under XP than it is to run D3/NT natively. Ditto with
big brother (Virtual Server) - best of both worlds on a single piece
of tin :-)

#24

Excalibur wrote:
snip....

Quote:

Funnily enough someone rebooted a SCO box on
us and nobody was ever able to fully recover it. All the experts were flown
in at great expense without result!!

A SCO box. Well, if that's the source of your unix opinions, it all
makes a little more sense.

Art

#25

art wrote:

Quote:

Excalibur wrote:
snip....

Funnily enough someone rebooted a SCO box on
us and nobody was ever able to fully recover it. All the experts were
flown
in at great expense without result!!

A SCO box. Well, if that's the source of your unix opinions, it all
makes a little more sense.

Art

There is of course the marvelous quote by Linus Torvalds in 2004
regarding SCO:

"Some of you may have heard of this crazy company called SCO (aka
'Smoking Crack Organization') who seem to have a hard time believing
that open source works better than their five engineers do.

For full text/context: http://www.wired.com/techbiz/media/news/2004/05/63574

--
Allen Egerton
aegerton at pobox dot com

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Flash compiled code

comp.databases.pick comp.databases.pick

Re: Flash compiled code - update - 04-25-2007 , 05:49 PM

Re: Flash compiled code - update - 04-25-2007 , 10:07 PM

Re: Flash compiled code - update - 04-26-2007 , 02:34 AM

Re: Flash compiled code - update - 04-26-2007 , 07:48 PM

Re: Flash compiled code - update - 04-26-2007 , 07:58 PM