I was at a client with a d3/nt on xp box today; they have
a handfull of smallish files and one 256mb file in their
e:\ directory. I could do select dos:e: ok,
but select dos:e: with a0 # "disk0.d3v"
or just doing list dos:e: a0
went in to major overflow usage.

On reflection maybe I should have tried c:e:/ or nt:e:/
instead of that dos: handler...

Oh, and I couldn't remember at first which option letter you use
to logoff another port that is hung doing !del foofile
or whatever, but once I got it by trial and error I put a memo
in line 17 of the dm,md, reset-user catalog entry; probably
against the rules, but so far no bad effects seen...

On May 24, 11:03*pm, "Frank Winans" <fwin... (AT) sbcglobal (DOT) net> wrote:
Could have something to do with the fact that native OS files are not
hashed thus must be scanned.
BobJ

"Robert Joslyn" <bobjoslynalt (AT) gmail (DOT) com> wrote


Well they are nasty on a several scores;
--even the item ids may contain chars that d3 considers problems,
such as spaces, quotes, backslashes
--they may be executables and hence bear char(255) which sabotages
further internal d3 processing
--if user requested that d3 treat them as escaped binary then d3 needs
to paw through the whole body if user is refers to SIZE since the
escaping mechanism if not considered would wrongly pad the SIZE
It seems you are safe to do LIST ONLY or SORT ONLY on native os
side files but any mention of any attribute, or of SIZE, or of even A0 in
your tcl may require impractically large set-runaway-limit settings if
large
(as in over tens of megabytes) windows files are present. Pity, that.

On May 25, 11:17*pm, "Frank Winans" <fwin... (AT) sbcglobal (DOT) net> wrote:
This is because the entire item is being read .... in your case 256Mb!

In terms of special characters & further processing (if you actually
WANT to process an EXE!!) you could use the BIN: driver .... and D3
doesn't mind ID's that "contain spaces", quotes or backslashes ....
though windows may kark on some of these!

"Ross Ferris" wrote
I stand corrected; file names won't normally be a problem, and I realized
after I punched "Send" that windows cmd.exe won't accept most (any?)
of that in file names. {Although technically _anything_ can be found in a
damaged directory entry, or as part of a copy protection scheme, but
I dunno, it may get filtered out of instead of being shown as query
results.}

On May 26, 5:53*pm, "Frank Winans" <fwin... (AT) sbcglobal (DOT) net> wrote:
OR......

via the OSFI you CAN write files out with "bad" characters in them,
that are then impossible (AFAIK) to remove using the tools from the
host OS, and the only way they can be removed (maybe!!) is via the OSFI

"Frank Winans" wrote:
When I was still at PS/RD I filed an action item related to this, and
the issue was addressed to some extent. The problem was specifically
that operations on filename/itemIDs would retrieve the entire item
even if no data/attributes was required - it was a waste of effort.
That action item was against D3/*nix. Maybe it's time for the matter
to be revisited for Windows, should anyone here care to follow-up.

Frank, what release is that site running? If it's 7.1 or early 7.2
then I'd say this is something that was fixed a decade ago and the
matter can be dropped.

Ross is right that using AQL on OSFI files will retrieve the entire
file/item. It will then convert system delimiters per the OSFI driver
setting, CRLF=AM, etc. Every item that gets pulled into the VME will
consume linked frame space, then release it. It's very resource
intensive for large file/items.

One solution "might" be to do this:

select e: not "disk0.d3v"

While that should translate to "with a0 not disk0.d3v", the
optimization from the above mentioned action item might bypass AQL
processing and give you a limited set of file/item IDs for another
query.

BTW, note that I'm not using dos:e:. You probably already have a "E"
driver in your HOSTS file which defines that as a DOS resource, so the
DOS: is redundant, and may increase processing time. If you don't
have "E" in HOSTS, you can create one using other driver items as a
model.

OSFI is so powerful, yet so under-used, and the fact that TL doesn't
exploit the power doesn't help D3 positioning at all. *sigh*

D3/NT 7.5.4 -- was current release 2.0 years ago...

I wish TL well, and if they don't think this is in their own best interest
to look into, I'm unwilling to nag them on it. That said, I'm relieved
to have posted this here and find it is a known limitation, not just
poor technique on my part... I'll know better next time not to show
off to the customer in this area, though.

Haven't gotten back there to try the select dos:e:/ not "disk0.d3v"
form, yet...

Frank

"Tony Gravagno" wrote

Unless someone says it's a problem, TL probably won't take initiative
to say it is. My opinion on the matter is that a query should only be
run on a database, which is a structured set of data. OSFI works well
if the OS file system contains data similar to what you'd find in any
hashed file. If you query a file system with large binaries and/or
unstructured data, you sort of get what you're asking for - which is
that the system will try its best to process whatever you throw at it.
While all of us would hope that the system knows what we want to do in
a case like this, I don't think this is a technical problem for a MV
vendor to solve. YMMV

"Frank Winans" wrote: