Platform portable support of heir. file systems

Platform portable support of heir. file systems

[Paul Whittington]

I was just working on one of our support packages that interfaces to the
host OS to do file I/O and can't find any support in the Ada Annex set for
a portable way of accessing heir. file systems.  I need things like
"MakeDirectory", "RemoveDirectory", etc.  

Am I missing something, or is it the case that there is no Ada Annex
covering this very common need?

If there is no Annex support, is the ARA working on some kind of industry
agreement about such things?

TTFN Paul

Re: Platform portable support of heir. file systems

[Larry Kilgallen]

In article <01bbec7f$453edcd0$24af1486@pc-phw>, "Paul Whittington" <paul@sage.inel.gov> writes:
> I was just working on one of our support packages that interfaces to the
> host OS to do file I/O and can't find any support in the Ada Annex set for
> a portable way of accessing heir. file systems.  I need things like
> "MakeDirectory", "RemoveDirectory", etc.  

On VMS:

	Directories can only be nested 8 deep or so if you want
	the files they contain to be backed up.

	Directories cannot be removed until all their contents
	are removed, regardless of how much privilege you have.

	Directories are always created with nobody having delete
	permission, regardless of what the caller specifies (this
	is independent of the previous rule).

	Directories have a "version limit" attribute which
	would logically be set by a creator to get a desired
	behaviour, even if only to override the default for
	the default of inheriting from the parent.

	The directory from which you read might be different from
	the directory to which you write, given identical specifications,
	if the device specified is a rooted directory rather than a
	real device.  (Come to think of it, Unix users creating a
	directory don't even specify the device separately, do they>?)

I am certain that other operating systems have quirks as well,
especially when one gets into permissible name lengths and
character sets (which are _not_ necessarily the same as for files).

A common package for directory manipulation would not seem to be
very "portable" if the rules differ on each operating system.

Larry Kilgallen

Re: Platform portable support of heir. file systems

[Tarjei T. Jensen]

Larry Kilgallen wrote:
> 
> On VMS:
> 
>         Directories can only be nested 8 deep or so if you want
>         the files they contain to be backed up.
> 
>         Directories cannot be removed until all their contents
>         are removed, regardless of how much privilege you have.
> 
>         Directories are always created with nobody having delete
>         permission, regardless of what the caller specifies (this
>         is independent of the previous rule).
> 
>         Directories have a "version limit" attribute which
>         would logically be set by a creator to get a desired
>         behaviour, even if only to override the default for
>         the default of inheriting from the parent.
> 
>         The directory from which you read might be different from
>         the directory to which you write, given identical
specifications,
>         if the device specified is a rooted directory rather than
a
>         real device.  (Come to think of it, Unix users creating a
>         directory don't even specify the device separately, do
they>?)
> 
> I am certain that other operating systems have quirks as well,
> especially when one gets into permissible name lengths and
> character sets (which are _not_ necessarily the same as for
files).
> 
> A common package for directory manipulation would not seem to be
> very "portable" if the rules differ on each operating system.


Don't be silly!
Exactly this behaviour would be very nice to encapsulate. Much of
what
you think is VMS specific is specific to other operating systems.

Regardless of what is the underlying operating system it is a
general
requirement for some file maintenance primitives. That is why they
appear
in the standard C library. If C programmers think these things
important
then I'm pretty confident that Ada programmers want the same
facilities.

It is trivial to construct a set of primitives that easily can cope
with
file systems of the most common operating systems (I have a paper
somewhere around here on this theme). The point is not to capture all
the
fine points, but enough to keep the programmers comfortable.

Greetings,

Re: Platform portable support of heir. file systems

[Larry Kilgallen]

In article <32B8508F.2B7D@online.no>, "Tarjei T. Jensen" <tarjei@online.no> writes:

> somewhere around here on this theme). The point is not to capture all
> the fine points, but enough to keep the programmers comfortable.

My choice of Ada is to drive the errors to compile-time (on my machine)
rather than run-time (on my customer's machine).  If a program I write
in Ada cannot deal with a directory structure created from some other
language, that is a defect.  To the extent that a common package hides
from me the differences between operating systems, it may assist me in
adding defects to my programs.  Quite frankly, I can do well enough on
my own, thank you :-).

Larry Kilgallen

Re: Platform portable support of heir. file systems

[Robert Dewar]

Interesting, I guess I must be silly too, since I tend to agree with
ken on this. Tarjei says

"It is trivial to construct a set of primitives that easily can cope
with
file systems of the most common operating systems (I have a paper
somewhere around here on this theme). The point is not to capture all
the
fine points, but enough to keep the programmers comfortable."


Hmm trivial is always a word I find dubious.

Will your set of primitives cover mainframe IBM systems (certainly
one of the most common operating systems around). How about some of
the other systems used in the information systems world, how about
real time systems with very limited file systems.

Ah! perhaps you meant Unix-like systems when you said common operating
systems, that could be it .....

Once you restrict yourself to Unix-like systems, it seems to be that
the Posix interfaces are quite appropriate.

Re: Platform portable support of heir. file systems

[Tarjei T. Jensen]

Robert Dewar wrote:
> 
> Will your set of primitives cover mainframe IBM systems (certainly
> one of the most common operating systems around). How about some
of
> the other systems used in the information systems world, how about
> real time systems with very limited file systems.

IBM mainframes have disks and directories if my memory serves me
right. The main difference is that the number of levels in the file
hiarchy is one (or was it two). One could simulate more levels, but it might
not be worth the effort.

Greetings,

-- 
// Tarjei T. Jensen 
//    tarjei@online.no || voice +47 51 62 85 58
//   Support you local rescue centre: GET LOST!

Re: Platform portable support of heir. file systems

[Larry Kilgallen]

In article <32BC1A02.3DAA@online.no>, "Tarjei T. Jensen" <tarjei@online.no> writes:

> IBM mainframes have disks and directories if my memory serves me
> right. The main difference is that the number of levels in the file
> hiarchy is one (or was it two). One could simulate more levels, but it might
> not be worth the effort.

If that is the mapping you would propose for DASD,
how would you handle partitioned data sets ?

Also note that a lot of existing MVS data is quite dependent
upon the hardware support for variable length disk records.
This seems quite at odds  with the "stream of bytes" view
someone advocated earlier in this thread.

Even though we might all _wish_ there was an easy answer,
wishing does not make it so.  Posix provides an approach
for those running under Unix-emulating subsystems, including
MVS Open Edition, but it does not provide transparent access
to the bulk of existing data on non-Unix systems. I do not
mean to slight the Posix committee(s), some tasks are just
too hard.

Larry Kilgallen

Re: Platform portable support of heir. file systems

[Tarjei T. Jensen]

Larry Kilgallen wrote:
> Also note that a lot of existing MVS data is quite dependent
> upon the hardware support for variable length disk records.
> This seems quite at odds  with the "stream of bytes" view
> someone advocated earlier in this thread.

I have said nothing yet of the datastream. However I think it would be
reasonable for Ada to support the concept of variable sized records on
architectures that have special support for it (IBM systems, VMS - there
must be more of them). However that should not be at the expense of
removing the existing support for "stream of byte". I think it would be
a good idea for those vendors who sell Ada implementations and their
customers to try to hammer out an annex that cover their needs.

> Even though we might all _wish_ there was an easy answer,
> wishing does not make it so.  Posix provides an approach
> for those running under Unix-emulating subsystems, including
> MVS Open Edition, but it does not provide transparent access
> to the bulk of existing data on non-Unix systems. I do not
> mean to slight the Posix committee(s), some tasks are just
> too hard.

I think one should concentrate on one thing at a time. e.g. navigation
and simple file system maintenance. A standard way of navigating and
being able to reason about a file system is a big plus if you have to
keep a piece of software running on several architectures. Once this has
been done one can start to worry about other things. The point is to not
try to cover everything at once. Divide and conquer!

Greetings,


-- 
// Tarjei T. Jensen 
//    tarjei@online.no || voice +47 51 62 85 58
//   Support you local rescue centre: GET LOST!

Re: Platform portable support of heir. file systems

[Robert Dewar]

Larry said

"Even though we might all _wish_ there was an easy answer,
wishing does not make it so.  Posix provides an approach
for those running under Unix-emulating subsystems, including
MVS Open Edition, but it does not provide transparent access
to the bulk of existing data on non-Unix systems. I do not
mean to slight the Posix committee(s), some tasks are just
too hard."


Actually, I think the Posix approach is just fine. Note that you do not
have to "emulate Unix" to be Posix compliant, just provide a set of
interfaces (which by the way is certainly not full Unix in any case).

Manufacturers then make the choice of whether to try to be compliant
with this standard or not. 

So using this apporach you meet half way at an abstract set of 
interfaces representing a desired set of functionalities. If it is
possble to map an OS to this interface, then you do so, rather than
trying to make the top level abstraction handle direcly the quirks
of every possible operating system.

Re: Platform portable support of heir. file systems

[Larry Kilgallen]

s In article <dewar.851276907@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Larry said
> 
> "Even though we might all _wish_ there was an easy answer,
> wishing does not make it so.  Posix provides an approach
> for those running under Unix-emulating subsystems, including
> MVS Open Edition, but it does not provide transparent access
> to the bulk of existing data on non-Unix systems. I do not
> mean to slight the Posix committee(s), some tasks are just
> too hard."
> 
> 
> Actually, I think the Posix approach is just fine. Note that you do not
> have to "emulate Unix" to be Posix compliant, just provide a set of
> interfaces (which by the way is certainly not full Unix in any case).
> 
> Manufacturers then make the choice of whether to try to be compliant
> with this standard or not. 

By "emulate Unix", I meant that portion of Unix which must be emulated
to comply with the Posix standards.  Restricting this to a very narrow
area of file name cases (for purposes of discussion), manufacturers of
non-Unix operating systems tend to add a separate file system emulation
in order to be able to support case-sensitive filenames.

In general (VMS Posix, MVS Open Edition) the full Posix user has a
separate little universe for storing and retrieving files, but does
_not_ have the ability to access other files stored according to the
traditions of the operating system in this fashion.  There may be
special utilities to do so, but they are not at all standard between
manufacturers.

This separate-but-compliant approach will work for some application
purposes, but by no means all.  (Consider a program to read all the
traditional files on a system and check for some special trait.)

> So using this apporach you meet half way at an abstract set of 
> interfaces representing a desired set of functionalities. If it is
> possble to map an OS to this interface, then you do so, rather than
> trying to make the top level abstraction handle direcly the quirks
> of every possible operating system.

Yes, and the Posix approach handles some cases well.  I do not
believe going further with a generalized approach would be fruitful.
Those who need os-specific access (including me) will just have to do
os-specific coding.

Larry Kilgallen

Re: Platform portable support of heir. file systems

[Robert Dewar]

"IBM mainframes have disks and directories if my memory serves me
right. The main difference is that the number of levels in the file
hiarchy is one (or was it two). One could simulate more levels, but it might
not be worth the effort."


your memory serves you wrong ..... there is no file hierarchy in this
sense ..

Re: Platform portable support of heir. file systems

[Michael F Brenner]

Paul Whittington said:
> I was just working on one of our support packages that interfaces to the
> host OS to do file I/O and can't find any support in the Ada Annex set for
> a portable way of accessing heir. file systems.  I need things like
> "MakeDirectory", "RemoveDirectory", etc.

Larry Kilgallen said:
> On VMS:
>       Directories can only be nested 8 deep or so if you want
>       the files they contain to be backed up.
        ... (and other limitations)
> I am certain that other operating systems have quirks as well,
> especially when one gets into permissible name lengths and
> character sets (which are _not_ necessarily the same as for files).
> A common package for directory manipulation would not seem to be
> very "portable" if the rules differ on each operating system.

Yes there are differences in the limitations of heirarchical file systems.
That does NOT lead me to the conclusion that we should not standardize
a common subset. When a url, server name, drive name, directory name,
filename, or query exceeds the permissions, number of levels, name length,
character set, or permissible operations, then raise one of the exceptions
url_could_not_be_created, url_could_not_be_located, url_could_not_be_read, 
url_could_not_be_written, url_could_not_be_deleted, 
url_could_not_be_made_the_default_directory, or 
url_is_too_complicated_for_the_target_system.

Mike Brenner says:
IMO we should standardize a set of machine independent operations on
URLs that are equally applicable to all major operating systems, yet
raise the correct exceptions when, for example, someone puts spaces
in the middle of a filename on a system that prohibits unquoted spaces,
such as during ftp to Windows NT or Macintoshes. The facts (VMS has
generational datasets while NT does not, various systems have different
limitations, DOS is limited to 8.3 characters, devices are handled
differently, and quotation characters are incompatible: double quotes
versus backslash versus single quotes) do not prevent standardization 
of a URL object that will handle the common aspects of file systems. 

The following is a strawman proposal to start discussion of such
a standard visible part, (whose body would be implemented using 
existing Ada-95 facilities, annexes, and interfaces). 

package url_control is

  subtype urls is string;

  -- Example of a URL:
  --
  -- http://email:port/disk:file1/file2/.../filen#anchor?arg1?arg2?...?argk
  --
  -- @ Separators (://, :, /, #, ?)
  -- @ Words (protocol, email, port, disk, file, anchor, arg)
  -- @ Nonquoted words may contain alphanumerics, ~, _, !, @, -, and periods
  -- @ Quoted words may contain anything, doubling the quotes

  procedure url_break_apart (url: urls;
                             protocol_start:  out natural;
                             protocol_finish: out natural;
                             internet_start:  out natural;
                             internet_finish: out natural;
                             port_start:      out natural;
                             port_finish:     out natural;
                             disk_start:      out natural;
                             disk_finish:     out natural;
                             file_start:      out natural;
                             file_finish:     out natural;
                             anchor_start:    out natural;
                             anchor_finish:   out natural;
                             args_start:      out natural;
                             args_finish:     out natural);

  procedure directory_changeto    (name: urls);
  procedure directory_create      (name: urls);
  function  directory_current      return urls;
  procedure directory_remove      (name: urls);
  function  directory_get_first   (pattern: urls) return urls;
  function  directory_get_next     return urls;
  function  directory_temp         return urls;

  type systems is (default_system,
                   compatible_system,
                   fruit_system,
                   open_system,
                   vegetable_system);

  procedure set_system (system: systems); 
  function system return systems;

  function end_of_line_string    (system: systems := default_system)
                                  return string;


  function file_name_separator   (system: systems := default_system)
                                  return character;

    -- File name separator might be a period or slash depending on
    -- the operating system.

  function environment (variable: string) return string;
  procedure set_environment (variable: string; value: string);

  procedure delete (url: urls);
  procedure rename (old_url, new_url: urls);

  procedure low_level_display_without_loading_text_io (message: string);

end url_control;

with url_control;
package net_control is

  -- Send and receive files, messages, or queries across the net. 

  procedure transfer (source, destination: url_control.urls);
end net_control;

Mike Brenner mikeb@mitre.org

Re: Platform portable support of heir. file systems

[Larry Kilgallen]

In article <59b6ea$522@top.mitre.org>, mfb@mbunix.mitre.org (Michael F Brenner) writes:

> IMO we should standardize a set of machine independent operations on
> URLs that are equally applicable to all major operating systems, yet
> raise the correct exceptions when, for example, someone puts spaces
> in the middle of a filename on a system that prohibits unquoted spaces,
> such as during ftp to Windows NT or Macintoshes. The facts (VMS has
> generational datasets while NT does not, various systems have different
> limitations, DOS is limited to 8.3 characters, devices are handled
> differently, and quotation characters are incompatible: double quotes
> versus backslash versus single quotes) do not prevent standardization 
> of a URL object that will handle the common aspects of file systems. 
> 
> The following is a strawman proposal to start discussion of such
> a standard visible part, (whose body would be implemented using 
> existing Ada-95 facilities, annexes, and interfaces). 

OK with me, but someone else may kick us off c.l.a due to bandwidth
consumption.

> package url_control is

The letters "url" already have a meaning as "universal resource locator"
in HTTP, and although on some Unix systems they may correspond to a
file system structure that is by no means required in the HTTP world.
The only requirement is that retrieval of information "works" according
to the HTTP rules.

Thus, I feel overloading the term "url" with something which _does_
correspond to real OS files is a bad idea.

>   function  directory_get_first   (pattern: urls) return urls;
>   function  directory_get_next     return urls;

"Next" using the last pattern used ?  In what context ?  How does one
distinguish one directory search from another (comparing the contents
of two directories, for instance)?

>   function  directory_temp         return urls;

Unique to this thread or just to this executable program ?
Shouldn't there be a matching call to delete it ?
(Purists would say creating it in the first place is not an
acceptable side-effect for a function.)

>   type systems is (default_system,
>                    compatible_system,
>                    fruit_system,
>                    open_system,
>                    vegetable_system);
> 
>   procedure set_system (system: systems); 
>   function system return systems;

Hmmm:

	if system = dos_system
	then
	        set_system (mvs_system);
	end if;

>   function end_of_line_string    (system: systems := default_system)
>                                   return string;

Since the "url" is an Ada string, I presume this must refer to some
sort of separator within a file.  That is a very Unix (or is it C?)
chauvenist approach.  By default, VMS files have no such element,
and I would doubt that MVS files do either.  A record is a record,
delimited by out-of-band mechanisms private to the operating system.

>   function file_name_separator   (system: systems := default_system)
>                                   return character;
> 
>     -- File name separator might be a period or slash depending on
>     -- the operating system.

Ok, but I don't see "directory start" or "directory end" characters,
([,],<,> on VMS but always matched) such as:

    DISK$QUENTIN_73:<LARRY.ADA_STUFF.DISCUSSIONS.FILES>PROPOSAL.TXT;24
or
    $213$DUA7:[ADA$PREDEFINED_ROOT.SYSCOMMON.SYSLIB.][ADALIB]$STANDARD_.ADC;1

>   function environment (variable: string) return string;
>   procedure set_environment (variable: string; value: string);

Your Unix is showing :-). Presuming the goal is to deal with things
which affect file access, on VMS that would be "logical names",
so expanding those routines to support VMS semantics without
introducing VMS terminology, how about:

	type level is (innermost, inner, outer, outermost);

	function environment (
	                variable : in String;
	                variable_index : in Natural;
	                case_sensitive : in Boolean;
	                environment_table : in String;
	                environment_table_level : in level ) return string;

	procedure set_environment (
	                variable : in string;
	                value : <this really needs to be an array-of-strings>;
                        environment_table : in String;
                        environment_table_level : in level;
	                copy_on_spawn : in Boolean;
	                susceptible_to_outer_level_alias : in Boolean;
	                conceal_contents : in Boolean;
	                terminate_recursive_translation : in Boolean);

Larry Kilgallen

Re: Platform portable support of heir. file systems

[Michael F Brenner]

>> package url_control is
>The letters "url" already have a meaning as "universal resource locator"
>in HTTP

The url_control package is using url as universal resource locator, but
is not restricted to being used by http. For example, it is often used 
for ftp. In addition, it contains a filename, and with certain portions
of the url blank, it IS a filename. Thus this package is used both on
a local computer and across the net. In other words, the word url is 
not being overloaded. It Already has the meaning of being a filename.


>> function directory_get_first (pattern: urls) return urls;
>> function directory_get_next   return urls;
> "Next" using the last pattern used ?  In what context ?  How does one
> distinguish one directory search from another (comparing the contents
> of two directories, for instance)?

Sorry, my telepathy did not transmit through well enough. This is a good
argument for finding a way to put more semantic information into
visible parts before Ada-2005 is created. You only have to give the pattern
once. Get_first and get_next are like an interator which continues until
the url returned is the null string, which means there are no more 
entries in the current directory which match the pattern. This is the way
DOS provides access to the directories to avoid data structures that
force you to read the entire directory into memory at one time so 
something like an object-oriented iterator would be useable, but at the
expense of a large amount of wasted RAM.

>>   function directory_temp return urls;
> Unique to this thread or just to this executable program ?
> Shouldn't there be a matching call to delete it ?

Again, sorry for the missing semantic information. In DOS the temporary
directory, where the users may create subdirectories which will be 
deleted by the disk manager, say, every Friday, is called \TMP. In Un*x,
the temporary directory is called /tmp. The string \TMP, /tmp, or 
[SYS001.tmp] would be returned by function directory_temp. What would
be created and deleted would be subdirectories underneath the temporary
directories.

         if system = dos_system
        then
                set_system (unix_system);
        end if;

Code like this would make sense in writing an application like
dos2unix. If we are in DOS (which uses carriage return-line feed) 
and we wish to convert the file to Un*x (which uses line feed only),
then we would set_system, so the next file_instantiation.put_line
would append the Un*x end_of_line_string to the end of the line 
instead of the DOS end_of_line_string. 


>> function end_of_line_string (system: systems := default_system)
>>                              return string;
>Since the "url" is an Ada string, I presume this must refer to some
>sort of separator within a file.  That is a very Unix (or is it C?)
>chauvenist approach.  By default, VMS files have no such element,
>and I would doubt that MVS files do either.  A record is a record,
>delimited by out-of-band mechanisms private to the operating system.

I used and respected VMS for years with the exception of a component
called the Record Manager. The Record Manager does not deal with files
as arrays of characters; IMO this is a design flaw of the Record Manager.
When I used DEC Ada it took quite a bit of effort to bypass the Record
Manager, using Starlet channel programs, interfaces to assembler, and other
tricks which should not have been necessary, in order to see the files 
as arrays of characters. 

Because so many Defense contracts used vaxen (11-780s or LSI-22s),
text_io was made to follow the Record Manager, instead of the idea
that a file is just and array of bytes. IMO, this is very serious
design flaw of text_io, a flaw which irks most newcomers to the 
language the first time they try to do random access on a text file
or rewind standard_input. There is no valid theoretical reason for
denying ordinary operations on files just because Record Manager
denied them. The packages that import url_control should support
files which act like an array of characters, which is the default
for operating systems that are DOS, NT, or Posix-compatible; if they
support the Record Manager, that should be In Addition To, not instead
of the array of characters operations. Is this Un*x- or DOS-chauvenistic?
No, to follow the Record Manager would be chavenistic, because I am
not restricting any of the Record Manager operations, but it is a great
inconvenience to restric file users to Record Manager operations.

> I don't see "directory start" or "directory end" characters,
VMS requires square brackets around directory names, and that could
be accomplished automatically whenever an operation was done with
system equal to VMS, which would make the separator a period, and 
automatically add the square brackets. Externally, the square brackets
would not necessarily be stored in a url, because transmitting it
across the net would not always work (for example, certain Un*x 
shells would have problems). 

> Your Unix is showing :-).
Yes, but it is identical in un*x, DOS, NT, etc. Again, the only outlier is
VMS. And VMS is now Posix compliant and is capable of running Posix shells
at user request. Yes, I realize that this argument can be turned around,
and DOS can run a VMS shell, so yes, absolutely yes, my Unix is showing,
and I am demonstrating a preference for a syntax that satisfies me on
almost all operating system shells, rather than all shells.


>> function environment (variable: string) return string;
>> procedure set_environment (variable: string; value: string);
> Your Unix is showing :-). Presuming the goal is to deal with things
> which affect file access, on VMS that would be "logical names",

People have remarked that environment variables work differently on VMS
and Unix and DOS. I think this is wrong, because only DOS actually has
environment variables. Unix has the capability of running a shell that
has environment variables which are more powerful than DOS environmental
variables, but most Unix shells do not give the programmer this capability.
In all operating systems, there is a way to give the programmer a
machine independent capability to set global environmental variables,
using a shared file and an application (object, TSR, process, or whatever)
that manages that shared file. The question is not how we are going to
spell the capability in each operating system. The question is how will
we provide the programmer with a machine independent capability of 
sending messages to the other programs in the machine. Stating that 
something called environmental variables works differently in VMS is
not solving the problem. The set_environment and environment together
define the interface for a machine independent facility that should be
provided. How we provide it is a separate (but important) question.

You suggested environment_table and environment_table_levels as 
interfaces are interesting. What do the levels mean?

mikeb@mitre.org

Re: Platform portable support of heir. file systems

[Larry Kilgallen]

By the way, I agree with another poster's sentiment "If you want
Portable, use Posix".  There have been committees hashing out the
Posix specifications for years, and it seems infeasible to reinvent
the wheel in comp.lang.ada. Nonetheless:

In article <59c7sd$osh@top.mitre.org>, mfb@mbunix.mitre.org (Michael F Brenner) writes:
>>> package url_control is
>>The letters "url" already have a meaning as "universal resource locator"
>>in HTTP
> 
> The url_control package is using url as universal resource locator, but
> is not restricted to being used by http. For example, it is often used 
> for ftp. In addition, it contains a filename, and with certain portions
> of the url blank, it IS a filename. Thus this package is used both on
> a local computer and across the net. In other words, the word url is 
> not being overloaded. It Already has the meaning of being a filename.

No, that is just the point.  It "looks like" a filename for certain
operating systems, but it need not be implemented that way.  If one
were to specify that this Ada package used that URL syntax, then
there could be two different files with identical URLs, depending on
whether one used http or this new package.

>>> function directory_get_first (pattern: urls) return urls;
>>> function directory_get_next   return urls;
>> "Next" using the last pattern used ?  In what context ?  How does one
>> distinguish one directory search from another (comparing the contents
>> of two directories, for instance)?
> 
> Sorry, my telepathy did not transmit through well enough. This is a good
> argument for finding a way to put more semantic information into
> visible parts before Ada-2005 is created. You only have to give the pattern
> once. Get_first and get_next are like an interator which continues until
> the url returned is the null string, which means there are no more 

	stash_into (a, directory_get_first ("directory_a"));
	stash_into (b, directory_get_first ("directory_b"));

Now how do I tell directory_get_next which of those two simultaneously
active directory iterations I want ?

> entries in the current directory which match the pattern. This is the way
> DOS provides access to the directories to avoid data structures that
> force you to read the entire directory into memory at one time so 
> something like an object-oriented iterator would be useable, but at the
> expense of a large amount of wasted RAM.

I can understand that DOS programmers might not bother with separate
contexts simultaneously active, but Ada covers a wider range of operating
systems than DOS.

>>>   function directory_temp return urls;
>> Unique to this thread or just to this executable program ?
>> Shouldn't there be a matching call to delete it ?
> 
> Again, sorry for the missing semantic information. In DOS the temporary
> directory, where the users may create subdirectories which will be 
> deleted by the disk manager, say, every Friday, is called \TMP. In Un*x,

And what if two copies of my program should need such a facility at
the same time?  Why make the individual programmer fight over the
uniqueness issues, which are, after all, highly OS-dependent ?

>>> function end_of_line_string (system: systems := default_system)
>>>                              return string;
>>Since the "url" is an Ada string, I presume this must refer to some
>>sort of separator within a file.  That is a very Unix (or is it C?)
>>chauvenist approach.  By default, VMS files have no such element,
>>and I would doubt that MVS files do either.  A record is a record,
>>delimited by out-of-band mechanisms private to the operating system.
> 
> I used and respected VMS for years with the exception of a component
> called the Record Manager. The Record Manager does not deal with files
> as arrays of characters; IMO this is a design flaw of the Record Manager.

In the opinion of others, it is an advantage.  It is particularly
an advantage in the minds of those who prefer VMS to Unix. Saying
(implicitly) to programmers that "we are going to stuff restrictions
of some other operating system down your throat" while trying to
impress them with Ada is not a winning posture.

>> Your Unix is showing :-).
> Yes, but it is identical in un*x, DOS, NT, etc. Again, the only outlier is
> VMS.

I think MVS and OS/400 are likewise not following your Unix model,
and Microsoft _pretends_ to have invented the world by putting
slashes in the other direction :-).  As for Macintosh, well one
could view the data fork as a stream of bytes, but the resource
fork is something entirely different, with capabilities richer
than VMS and on the file level even richer than OS/400.

>      And VMS is now Posix compliant and is capable of running Posix shells
> at user request.

And Ada is capable of calling Posix services at programmer request :-).

> In all operating systems, there is a way to give the programmer a
> machine independent capability to set global environmental variables,
> using a shared file and an application (object, TSR, process, or whatever)
> that manages that shared file. The question is not how we are going to
> spell the capability in each operating system. The question is how will
> we provide the programmer with a machine independent capability of 
> sending messages to the other programs in the machine. Stating that 
> something called environmental variables works differently in VMS is
> not solving the problem. The set_environment and environment together
> define the interface for a machine independent facility that should be
> provided. How we provide it is a separate (but important) question.

I believe, rather, that it is crucial to support communications with
non-Ada programs as well.

> You suggested environment_table and environment_table_levels as 
> interfaces are interesting. What do the levels mean?

I think that is _way_ beyond the scope of comp.language.ada, but
suffice it to say that the VMS logical name mechanism is _much_
more complex than what would be supported by the simple sequence
you proposed.  Operating systems are different, and that is a fact
of life.  Posix shells have been provided on Windows NT, VMS, MVS,
etc., but most Ada programmers do not have the luxury of saying to
a would-be user of their work "Yes, I can write that in Ada, so
long as users all run in the Posix environment."  As an example,
I would point to the use of the C programming language on VMS,
which is almost always done _outside_ the Posix environment,
calling real VMS system services, etc.  If the C bandwagon
(image of wagon rattling downhill out of control, with contents
falling out) cannot change VMS culture (despite heavy use),
Ada will not either.

Larry Kilgallen

Re: Platform portable support of heir. file systems

[Robert A Duff]

In article <1996Dec19.164901.1@eisner>,
Larry Kilgallen <kilgallen@eisner.decus.org> wrote:
>	stash_into (a, directory_get_first ("directory_a"));
>	stash_into (b, directory_get_first ("directory_b"));
>
>Now how do I tell directory_get_next which of those two simultaneously
>active directory iterations I want ?

And don't forget that Ada has tasks.

- Bob

Re: Platform portable support of heir. file systems

[David J. Fiander]

kilgallen@eisner.decus.org (Larry Kilgallen) writes:

> In general (VMS Posix, MVS Open Edition) the full Posix user has a
> separate little universe for storing and retrieving files, but does
> _not_ have the ability to access other files stored according to the
> traditions of the operating system in this fashion.  There may be
> special utilities to do so, but they are not at all standard between
> manufacturers.

In particular, OpenEdition MVS has been branded by the X/Open
group as Unix.  It passes all the tests associated with
demostrating conformance to the Single Unix Specification.

Oh yeah, and OS/390 Unix also allows any application (OS/390 or
POSIX) to access the files in the "other" filesystem relatively
simply.

- David, who's spent more time in Poughkeepsie than he'd prefer

Re: Platform portable support of heir. file systems

[Robert Dewar]

Paul asked

"I was just working on one of our support packages that interfaces to the
host OS to do file I/O and can't find any support in the Ada Annex set for
a portable way of accessing heir. file systems.  I need things like
"MakeDirectory", "RemoveDirectory", etc.

Am I missing something, or is it the case that there is no Ada Annex
covering this very common need?

If there is no Annex support, is the ARA working on some kind of industry
agreement about such things?
"



This is obviously operating system dependent, and not something that one
would expect in an OS independent language definition (as a point of
comparison, ANSI C does not support these operations either).

So you expect to find these operations supported in standard libraries.
In the case of Ada 95, there are two possibilities. You can either use
a standard Posix interface if one is available, or you can call the
C library routines directly using appropriate Import pragmas. Either
approach will lead to well defined, portable code.

Re: Platform portable support of heir. file systems

[Robert I. Eachus]

In article <01bbec7f$453edcd0$24af1486@pc-phw> "Paul Whittington" <paul@sage.inel.gov> writes:

  > I was just working on one of our support packages that interfaces to the
  > host OS to do file I/O and can't find any support in the Ada Annex set for
  > a portable way of accessing heir. file systems.  I need things like
  > "MakeDirectory", "RemoveDirectory", etc.  

  > Am I missing something, or is it the case that there is no Ada Annex
  > covering this very common need?

  > If there is no Annex support, is the ARA working on some kind of industry
  > agreement about such things?

  There is a standard interface for such things: P1003.5 the POSIX Ada
Binding.  Not all OSes can support it, but it would be
counterproductive to have another "standard."

  On the other hand complete standard Ada bindings to APIs are a very
good idea, but don't belong in the Ada standard since they are OS
specific.  There exist good thin Ada bindings to most standard
operating systems.  Programs which use those thin bindings in
instead of the POSIX binding are of course less portable.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...