Re: FSI Indices with translates the answer

Dave:

One of the main reasons Pick Systems / Raining Data has been spiraling
downward in this market is their Windows implementation. It was slow to
market, riddled with bugs, almost completely unusable for a large number of
sites (for many years), and, to this day, is not fixed.

As Tony pointed out, there were a number of people inside PS/RD who pointed
this out but RD management saw fit to let them all go. For the most part,
those who stayed with RD (D3NT) learned to "work around" the various
implementation issues; which RD was never, and still isn't, grateful for.
:-)

Some additional comments below...

"dzigray" <google@xxxxxxxxxxx> wrote in message ...

The FSI is intended to operate
as a network file system where any server can provide data and
business rules for a domain.

First, most network file systems allow absolute and relative
addressing. Simply look at the FOPEN() command syntax (STDIO C++); the
file open can be both absolute/relative (based upon the current
directory of the file system that one is within, and different vehicles
allow the directory context to be changed.) Second, maintaining an
external-interface SHOULD not force its interface onto the underlying
layers -- nor is there a need to! (i challenge someone demonstrate
otherwise; however, if you want to chase this... present a full
use-case.)

Finally, it would have been trivial to add an NFS-interface directly to
the VME and make it mountable, but for some reason RD hasn't picked up
on this.

Pathing is required in one of the U2 dbms products...there are no "Q"
pointers. Even their login and logto context is always within the dbms
"home" directory. Move an account outside this "home" directory and one has
to reference the context with the "complete" path.

I'm not attempting to justify D3's FSI implementation. I'm just pointing
out there are other MV vendors who need to have this kind of scrutiny
pointed toward them.

Perhaps part of the convoluted design problem originated in that too
many things "terminology/goal-wise" have been associated with this
thing, termed "FSI". Within "FSI" (and without limiting/ranking all
its goals) there are several distinctly separate (non-competing) goals
that must be dealt with SEPARATELY: (1) an externally mountable
file-system-interface, that makes pick data structures transparent to
the outside world (and this SHOULD be for BOTH the
FSI-native-hosting-mapped files and VME-mapped files)(and again,
supporting absolute & relative addressing); (2) allowing stand-alone,
locally-scheduled pickbasic processes (ie. scheduled directly by
windows and external to the VME scheduling, also having their workspace
external to the VME.) (3) such stand-alone pickbasic executables should
have the capability of accessing ALL pick structures & features
transparently: especially supporting-and-conforming to all pick
syntaxes; and CERTAINLY, allow external native O/S
file/object-accesses, too, but via either their own explicit functions
such as FOPEN() -or- via expanded pick-open file syntax (eg. "dos:").
Although, personally I believe the original syntax extension by
embedding a prefix to the name was an architectural design error and
one which should have instead been hidden as "q"-pointer (eg.
"DOS^Q^dos:^^^^^^L^10", etc.) Amongst other capabilities, limiting
things like a dos-file-access solely through an m/dict would have
allowed account-level security over the dos file accesses (down to a
discrete dos file).

Again, there are other MV dbms products that have virtually no security
built in. All security is maintained by the O/S and the O/S administrators.
This certainly seems unusual considering:

1) MV applications embed the dbms with them and thus need application level
security, and
2) MV vendors should provide that functionality required by "ALL" users.

i.e. if all users need security it should be built in. If all users need
job scheduling it should be built in. If all users need a FOLD function it
should be built in. And on and on and on.

Sure, it would be helpful if accounts used in traditional ways
provided a context so that pathing wouldn't be required - when we
reference NFS mounted paths or Samba shares we don't change the syntax
of an fopen or similar statements because the underlying file system
is supposed to make this all transparent.

Whenever you build an interface, you should respect both sides of the
line, without stumbling into each side with erroneous assumptions and
artificial limitations.

As has been noted elsewhere, Microsoft has taught engineers how to "lower
the bar". Relational databases have shown us how to exist with an
artificial (certainly not logical) view of data and their relationships and
to segregate developers from the database. OOP programming has shown us how
to create so many levels of abstraction that the object, so to speak, of our
programming efforts have become unintelligible.

RD has
been so mired in other product issues that it hasn't plugged the
usability holes that people are discussing now. The answer to many
requests and questions for many years has been that issues will be
easier to manage once everything is in the FSI,

Nah.. stop there. That is a cop-out programmers use when they are
winging a design on the fly, and especially do not wish to subject it
prematurely to review. It's okay to have a sandbox to play in, but
going from there to a formal project (let alone production) should
require greater steps.

It seems to be the best excuse they have. :-)

In a way D3 is two
products in one and a migration from VME to FSI can be as traumatic as
a minor migration to another MV DBMS - which is exactly what we're
seeing in this thread.

This is a Marketing issue but anyone that
approaches the topic does so purely from a technical perspective, so I
don't believe Marketing or Sales recognize this as a major problem.

I disagree... it's a management issue; fire some people! :)

They did. Maybe the current state of the product tells us they fired the
"wrong" people. Oh well, when you fire anyone who points out problems
(causes trouble) or fire those whose nametag on the wall was hit by a dart
one can't expect the best results afterwards. :-)

The pool of people who complain to RD about these things has to be so
small that it's not enough to justify real change - and without change
the user base just gets smaller. This is a dynamic that I've been
trying to explain to them (and you guys) for years - another one that
people just don't "get".

If the perception is that RD has already given up, based upon its
resources/commitment levels, then why should end users expect to have
to continue to beat the door down? Nobody's home! Okay, on the
other hand, they still have talent to correct this... but will they?
Knock..knock!

You know how this works...remove those that speak and eventually one has
quiet. :-)

RD is well aware of the differences between coding
requirements for the VME and FSI but no one has yet made this into a
business case to evoke change.
That's not the case... RD just needs to fire some more people! :)

Firing everyone is not the solution. This refrain mostly covers up the lack
of competence in management. I know that when I fire someone it reflects on
my lack of judgement when I hired them, or when I managed their training, or
when I gave them their 90 day review, etc, etc, etc.

Don't misunderstand me, sometimes even I need a whack! :-)

If they don't respond in a satisfactory way, get a new vendor.
Boy, that'll really get them mad! You know the answer here... fire
some people! People don't want to change, only that their issues go
away!

I suspect the general comments from Tony are pretty accurate. If one
doesn't like the vendor move to another. Those vendors who want feedback
from their customers, and implement changes are the most successful.

RD has their forums. They can get feedback there. U2 has the U2 group.
One suspects IBM gets this information somehow. The other MV vendors have
their own methods. So it's not impossible.

We all get frustrated when our good intentions (and suggestions) are ignored
for no other reason than the vendor is smarter (or at least thinks so) than
we are. But this seems to be the world we're living in and enough people
find this to be an acceptable alternative to working to fix and improve the
products and services we use.

Bill


.

Relevant Pages

  • [UNIX] Buffer Overflow in ISO9660 File System Component of Linux Kernel
    ... Get your security news from a reliable source. ... The Linux kernel performs no length checking on ... symbolic links stored on an ISO9660 file system, ... In order to exploit this vulnerability, an attacker must be able to mount ...
    (Securiteam)
  • Re: For the AdaOS folks
    ... A mall with one or two doors on the outside to be ... > only makes sense to choke the security at a minimal number ... > that exist within the file system. ... While it is not the entire answer to network ...
    (comp.lang.ada)
  • Re: Linux security
    ... that is in Windows NT-based systems out of the box. ... Why do you want that fine level of control? ... level of control over security?" ... a file system is a different beast altogether. ...
    (Ubuntu)
  • Problems after converting FAT32 to NTFS on a Windows XP SP 2 system
    ... I inherited a Windows XP system with SP2 and FAT32 file system. ... decided to convert the file system to NTFS to use the granular security ... I have also verified that the Logical Disk Manager service is set to ...
    (microsoft.public.windowsxp.help_and_support)
  • "Consulta".
    ... Deseo consultar como atacho una unidad de cinta externa SUNStorEdge DDS-4, ... esto a un servidor SUN FIRE 280. ... File system. ...
    (Debian-User)