f



Re: How many files can you have in a VMS directory without performance problems? performance problems? performance problems? problems? performance problems? performance problems? problems? perfo

   First, does anyone know why Info-VAX goes nuts on subjects from time
to time?  (Or is the trouble elsewhere?)

From: JF Mezei <jfmezei.spamnot@teksavvy.com>

> DELETE Z*.*;*
> DELETE Y*.*;*
> ...
> DELETE A*.*;*
> 
> (followed by the numbers).

   This scheme may be a bit obsolete.  See:

      http://h71000.www7.hp.com/doc/731FINAL/4506/4506pro_014.html#index_x_890

I quote:

[...]

5.2.3.1.2 Extended Character Set

In addition, OpenVMS V7.2 on Alpha systems and ODS-5 disks includes
support for the use of file names, and subdirectory and root
subdirectory names, that include all possible 8-bit characters,
excluding values 00 through 1F (hexadecimal) and excluding the following
characters:

        < > : / \ | ? * "

OpenVMS 7.3-1 on Alpha systems and ODS--5 disks includes enhanced
support for the use of file names, and subdirectory and root
subdirectory names. It supports all possible 8-bit characters, excluding
only the following two characters: ? *

Note that the character set includes both the ISO Latin-1 C1 character
set (hexadecimal 80 - 9F) as well as graphical and other characters
between 9F and FF. This allows the entire ISO Latin-1 character set
(with the exclusions noted above). In addition, there is support for
names that include any of the defined 16-bit Unicode characters (except
for the character exclusions noted above).

[...]

   Even ignoring the Unicode problem, perhaps a loop would be worthwhile
now.

------------------------------------------------------------------------

   Steven M. Schweda               (+1) 651-699-9818
   382 South Warwick Street        sms@antinode-org
   Saint Paul  MN  55105-2547
0
sms (1038)
8/17/2005 8:11:05 PM
comp.os.vms 21904 articles. 1 followers. Post Follow

6 Replies
3476 Views

Similar Articles

[PageSpeed] 38

"Steven M. Schweda" wrote:
> > DELETE Z*.*;*
> > DELETE Y*.*;*

>    This scheme may be a bit obsolete.  See:

> 5.2.3.1.2 Extended Character Set

> excluding values 00 through 1F (hexadecimal) and excluding the following
> characters:
> 
>         < > : / \ | ? * "

> subdirectory names. It supports all possible 8-bit characters, excluding
> only the following two characters: ? *


Hum, this is starting to look like north american telephone number problems.

It used to be that the second digit of a number would determine if an
area code was supplied or not. Area codes had either 0 or 1 as second
digit, and telephone number never had them. Then, they decided to ditch
this system in order to reclaim many possible telephone number and
extend area codes (to allose for 888, 877 etc).

If [ and ] are  valid characters for file names, how doees the file
system know if

	[chocolate]cake.dat

If the file "[chocolate]cake.dat" located in the current directory, or
is it the file cake.dat which is located in the chocolate directory ?

And since : is now allowed, how about:

CAKE:[chocolate]mousse.dat
0
8/17/2005 8:52:17 PM
In article <4303A36F.55D58659@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes:
> 
> 	[chocolate]cake.dat
> 
> If the file "[chocolate]cake.dat" located in the current directory, or
> is it the file cake.dat which is located in the chocolate directory ?
> 
> And since : is now allowed, how about:
> 
> CAKE:[chocolate]mousse.dat

   These are easy.  See the guide to extended file naming for those
   few characters which are not allowed.  Care to take a first two
   guesses?

0
koehler2 (8314)
8/17/2005 9:10:02 PM
Steven M. Schweda wrote:
>    First, does anyone know why Info-VAX goes nuts on subjects from time
> to time?  (Or is the trouble elsewhere?)

Elsewhere.  Info-VAX does not rewrite the subject.

Mark Berryman
Info-VAX admin
0
mark363 (126)
8/17/2005 10:46:39 PM
"Bob Koehler" <koehler@eisner.nospam.encompasserve.org> wrote in message
news:ej0YGr1dpsuo@eisner.encompasserve.org...
> In article <4303A36F.55D58659@teksavvy.com>, JF Mezei
<jfmezei.spamnot@teksavvy.com> writes:
> >
> > [chocolate]cake.dat
> >
> > If the file "[chocolate]cake.dat" located in the current directory, or
> > is it the file cake.dat which is located in the chocolate directory ?
> >
> > And since : is now allowed, how about:
> >
> > CAKE:[chocolate]mousse.dat
>
>    These are easy.  See the guide to extended file naming for those
>    few characters which are not allowed.  Care to take a first two
>    guesses?
>

Hmmm.  I'll close my eyes and type ^



0
fred.nospam (540)
8/17/2005 11:54:59 PM
FredK wrote:
> > > CAKE:[chocolate]mousse.dat
> >
> >    These are easy.  See the guide to extended file naming for those
> >    few characters which are not allowed.  Care to take a first two
> >    guesses?
> >
> 
> Hmmm.  I'll close my eyes and type ^


The doctumation at:

says otherwise:

##
In addition, OpenVMS V7.2 on Alpha systems and ODS-5 disks includes
support for the use of file names, and subdirectory and root
subdirectory  names, that include all possible 8-bit characters,
excluding values 00 through 1F (hexadecimal) and excluding the following
characters: 


            < > : / \ | ? * "

 OpenVMS 7.3-1 on Alpha systems and ODS--5 disks includes enhanced
support for the use of file names, and subdirectory and root
subdirectory names. It supports all possible 8-bit characters, excluding
only the following two characters:

		 ? * 

##


So �  isn't in the list of forbidden characters.

I understand how, once the file system knows which part of a
specification is what part, it knows how to encode special characters
(using the �)

But what logic is used by f$parse to determine that [ and/or ] should be
considered part of the filename and "escaped" or whether it points to
the directory portion of the specicication entered by the user ?
0
8/18/2005 1:26:07 AM
In article <4303E38E.BC700038@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes:
> 
> But what logic is used by f$parse to determine that [ and/or ] should be
> considered part of the filename and "escaped" or whether it points to
> the directory portion of the specicication entered by the user ?

   [ ] are parsed as directory delimiters unless ^ is to escape them
   when they are entered.

   Other characters can be entered without the ^ and will be parsed
   according to appropriate rules, such as . within names, but are
   displayed with ^:

   $ create ^[.a
   Exit
   $ create [.a
   %DCL-W-DIRECT, invalid directory syntax - check brackets and other delimiters
   \[.a\
   $ create a.a.a
   Exit
   $dir .a

  Directory USER1:[KOEHLER]

   a^.a.a;1            ^[.a;1

   Total of 2 files.

0
koehler2 (8314)
8/18/2005 1:00:29 PM
Reply: