(Paragraphs below were written at different times and not intended for
any one person, but I think it's all relevant to this thread. Sorry
if the comments seem slighly disjointed.)

For details about what requires a path vs a simple file reference,
check D3 Ref v7.5, look for "path" which will show many topics, and
focus on "full path". If that info isn't clear enough, contact your
vendor.

I don't pretend to be an expert on the FSI. Mark is much more
informed on this than I am. I suggest someone petition RD for one of
their user group weekends to explain exactly what the FSI is and how
it works, or maybe a Webex, or Spectrum presentation, etc. That said,
I've personally found the "canned" explanations of the FSI to be too
dry and not enough "applied science" for my taste. It's usually RD
Engineering guys that get stuck explaining this stuff and, well,
they're engineers and don't always speak in terms normal human beings
can understand. The fact that it takes an engineer to explain the FSI
should be a hint to Marketing. Here is my brief and feeble attempt...

The FSI is a service that accepts requests for functionality. It's
not just another place to store data. The FSI is intended to operate
as a network file system where any server can provide data and
business rules for a domain. This is sort of like an environment
where every file you access may be local, or it may be a Samba or NFS
share to some other system on the LAN/WAN. Compare that to the
traditional blob where everything is always in one place.

The traditional VME assumes that the current 'context' is the current
account - in the VME there is no such thing as another context. FSI
file operations and business rule modules (BASIC object code) can be
invoked from places other than BASIC where there is no context, so the
context needs to be explicitly stated.

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. The FSI is a concept that
has never been fully implemented, documented, or utilized. 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, but they're spending
so much time patching the VME areas (no doubt a required effort) that
they never seem to get to the point where they can do a clean cutoff.

Most people know that RD recommends that all accounts should be in the
FSI, but they don't know why, so everyone puts their stuff into the
FSI and then expects it to work just like the VME. 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
have to laugh, years ago at PS/RD we did have employees in all
departments complaining internally that a lot of this crap didn't work
- all of those people were fired in corporate downsizing, and anyone
left just keeps their mouth shut. Similarly, most people who use D3
tend to expect it to behave just like R83. If it doesn't work as
expected they migrate to jBASE or U2 or go to Oracle or SQL Server.
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".

I do see where a requirement for pathing can be troublesome. I've
mentioned a number of times in this forum that I don't use triggers,
indexes, or the D3 Class Library - all of these require full pathing
for file references. Like many other people, my answer is to just not
use the features. 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 your responsibility if it's
important to you.

<Broken record mode on>
- I'll say one last time that I'm surprised that people are getting
all huffy and critical of syntax that hasn't changed in at least 8
years. It's been working, no one has made a stink about it in all
this time. Haven't I been asking people for years to run betas, read
the release notes, and report issues? If this were happening we
wouldn't have a thread 8+ years later complaining about how things
work.
- Report your issues to your vendor as a business issue because
(supposedly) you will incur undue expense and burden to use the
software because of the implementation. If they don't respond in a
satisfactory way, get a new vendor.
- Please do not confuse my presentation of information with any form
of support, approval, or justification. I'm just telling you the way
things work. Explanation does not imply advocacy.
- My suggestion to get a new vendor if you aren't satisfied is also no
reflection on RD. I'd say the same thing if someone complained that
pry-off bottle caps were a hassle for their favorite beer (and now
would be a bad time to complain about that too).
</>

T

"dzigray" wrote:

Hey again, Tony!
I know that in the below you were often sharing others' views
rather than your own; and in that spirit my remarks (and occasional
sarcasms) are meant especially for the "source" rather than the
messenger. Thanks for voicing them.

Tony Gravagno wrote:

result of having a "session established" (via IPL, TCP/ip connections,
batch processes, executes, etc.)

characterization. Eg. as per above, the VME also performs process
execution & process management based upon external/internal requests.

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.

contents are not directly addressable are seen as "blobs".

while you have limited (or are defending) the FSI as allowing
"multiple contexts" via merely seeing each file-open that utilizes
an "absolute"-path as being unique contexts - you have to remember,
the VME has both: absolute & relative!

is being unmanaged.)

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).

As a footnote, it would have seemed prudent and more powerful that any
mechanism for mounting a pick file system (independent of assigning an
account's context) should have allowed "managing the mounting" to
establish an "initial logical-view context" for the mounting: be it
at a "mds,,", or "account", or file, or item-level. For
example to allow mounting of single/multiple accounts, explicitly or by
default - and while respecting certain file system security from
within pick as well as allowing a powerful mechanism to exclude certain
files "from view" when a process does not have read/write
privileges (versus otherwise resulting in a non-trappable security
violation.)

line, without stumbling into each side with erroneous assumptions and
artificial limitations.

Also, most modern file systems and their associated API allow for both
'absolute' and 'relative' contexts to be established, along
with providing appropriate syntaxes & methods for altering/designating
such - namely by supporting the equivalent of an abstract
session-object from which to interface through and establish/maintain
context.

The FSI is a concept that

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.

Fix'em & stop creat'n 'em!

brighter than the old stuff so the new coders orphan the old code.


Unquestionably, at a certain layer it should! It does not! -- hence
predictable abstention.




People are forgiving, but resist change when there is no perceived
justification or benefit to them to overcome the required work/learning
curve! Likewise, most people would gladly learn to drive a new sports
car even if it had a different feel to it!

Change for change sake, seldom goes over easy - especially when
"upward compatibility" has been overlooked with no good reason.
There is a threshold as to what is acceptable. It ain't some aloof
standards/expectations, but instead "new bugs" and lack of
"upward compatibility". Too much license has been taken with the
latter, and people just want off the merry-go-round! Who can blame
them!

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!



time you end a thought by dumping the responsibility for fix'en the
problem back into the hands of the users, you give the vendor an out.
RD needs to take the responsibility here. (Fire some people! )




some people! People don't want to change, only that their issues go
away!

little collateral goes a long ways!



< I'd say the same thing if someone complained that

On 22 Aug 2006 15:16:15 -0700, "dzigray" <google (AT) bridge2 (DOT) com> wrote:


Well Said !!


Dave