Good Day - A client is running D3 7,1 on 'Suse Linux Enterprise Server
8'.
When compiling a program using option (o - for FlashBasic, The
compiler give the following error:

[820] Creating FlashBASIC Object ( Level 0 ) ...
[821] FlashBASIC Compilation Error: Phase 1, Code 127
[B100]*Line 0: Compilation aborted; no object code produced.

How do I resolve this?
Btw - the program compiles fine without the FlashBasic option.

Regards
Marc

1) I'm not sure if this is the issue but... Make sure the user under
which D3 is running has permissions to write to the host OS. The
flash compiler needs to write object code into /tmp or some
subdirectory thereof. For example, you can get into D3 from shell
after logging in to root using "d3 -l". Try compiling. If that works
then there is a permissions issue with whatever lower-privilege user
is being used by the developer, maybe user 'pick' which is the
default.
2) Get your client on a more recent DBMS. They could be struggling
with a decade old problem that was solved long ago.
3) Get your client on a supported OS. I know we were experimenting
with SuSE and other distros back then but I think the only official
distros were RH and another one that was based on RH.

HTH
T

Marc DuBois <marc (AT) appliedlogic (DOT) co.za> wrote:

On Jan 26, 8:26*pm, Tony Gravagno <tony_grava... (AT) nospam (DOT) invalid>
wrote:
Tony
Thank you for the advice.
I have a job on my hands - the client sounds like he was traumatized
by the problems he had with the initial installation.

Regards
Marc

On Jan 27, 8:38*am, Marc DuBois <m... (AT) appliedlogic (DOT) co.za> wrote:

I didn't think D3 was certified over Suse, so library locations are
likely to be different as well. To overcome the "permissions" issues
TG has flagged, we tend to run D3 as the "root" user.

Is this a "new" installation on this platform ( traumatized
client?!?). There is a lot to be said for using supported
platforms .... AND current releases (7.5 or 9.0 sounds good to me!)

Ross Ferris wrote:
Other DBMS platforms advertise tight security, restricting DBMS, OS,
and network activity to whatever is afforded by OS-level user
permissions. Somehow D3 admins think it's OK to run as root but
admins on other platforms wouldn't be caught dead with that kind of
exposure. Honestly I've never heard of a D3 site that has had a
problem because of this. Nevertheless, consensus these days seems to
be that running as root is a very bad idea. I'd even guess some sites
have migrated from D3 because they were under the impression that
running with full permissions was a requirement of an insecure
platform, when that's simply not the case.

T

Our users never get to a linux prompt (or a TCL prompt for that
matter), so we haven't been "that" worried about these security
aspects, and we have passed external audits for large publicly listed
companies without any problems (apart from disaster recovery, which
spurred our Visage.DRS development) either. Perhaps things are
different on your side of the Pacific .... or maybe we are just
lucky ?!?

Ross Ferris wrote:

I think you're lucky through obscurity. If auditors don't know
anything about MV (and they don't read this forum) then chances are
good that they won't know about the glaring hole in your security.

Quoting from my previous post, I really can sit on both sides of the
fence on this one: "Honestly I've never heard of a D3 site that has
had a problem because of this. Nevertheless, consensus these days
seems to be that running as root is a very bad idea."

Perhaps we can agree that security for your clients is adequate given
their situation, but also that passing a security audit doesn't
necessarily mean your client's environments are secure.

Regards,
T