This is G o o g l e's cache of http://www.lp.se/ftp/mailinglists/FREE-VMS.1998-07.
G o o g l e's cache is the snapshot that we took of the page as we crawled the web.
The page may have changed since that time. Click here for the current page without highlighting.
Google is not affiliated with the authors of this page nor responsible for its content. |
| These search terms have been highlighted: | levitte | programming |
|
|
Archive-Date: Thu, 2 Jul 1998 15:59:51 +0200
MIME-Version: 1.0
Date: Wed, 1 Jul 1998 14:21:29 -0500
Message-ID: <00067362.1870@advocatehealth.com>
From: David.Dachtera@advocatehealth.com (David Dachtera)
Reply-To: Free-VMS@lp.se
Subject: Re[2]: Mailing List postings....
To: Free-VMS@lp.se
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Folks,
Found this in DejaNews. Doesn't speak well of the FreeVMS
project, but not sure whether/how to respond...
Subject: Re: Streams and Linux
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: 1998/06/29
Message-ID: <m0yqesJ-000aOnC@the-village.bc.nu>
Newsgroups: muc.lists.linux-kernel
(I cut out whole bunches of irrelevant stuff)
>> "compatibility" is important too. If the only issue
>>in the "linux
>> kernel" project is performance, why bother making it
>>look anything
>> like Unix at all? Certainly there are better
>>operating system models
>Because Unix on the whole is a good working API that
>people understand
>and have software for. The FreeVMS project picked what
>may be a better
>API for somethings but basically seems to have died.
Thought you'd want to know...
David J. Dachtera
================================================================================
Archive-Date: Thu, 2 Jul 1998 23:12:16 +0200
Date: Thu, 2 Jul 1998 17:09:10 -0400
Message-ID: <199807022109.RAA30060@harvey.cyclic.com>
From: Jim Kingdon <kingdonc@cyclic.com>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
In-Reply-To: <00067362.1870@advocatehealth.com> (David.Dachtera@advocatehealth.com)
Subject: Re: Mailing List postings....
References: <00067362.1870@advocatehealth.com>
> > Doesn't speak well of the FreeVMS project
>
> The FreeVMS project picked what may be a better API for somethings
> but basically seems to have died.
Actually, I think it is a good sign that we are being mentioned at
all.
I guess my own take on it is "FreeVMS didn't die; it never came to
life". If anyone would like to breath some more life into it, I'd be
very glad to be shown wrong on its "non-living" status....
================================================================================
Archive-Date: Fri, 3 Jul 1998 00:05:17 +0200
Date: Fri, 3 Jul 1998 00:03:00 +0200
Message-ID: <1074-Fri03Jul1998000300+0200-levitte@lp.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
In-Reply-To: <199807022109.RAA30060@harvey.cyclic.com> (message from Jim Kingdon on Thu, 2 Jul 1998 17:09:10 -0400)
Subject: Re: Mailing List postings....
MIME-Version: 1.0
Content-Type: Text/Plain; Charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
I guess my own take on it is "FreeVMS didn't die; it never came to
life". If anyone would like to breath some more life into it, I'd be
very glad to be shown wrong on its "non-living" status....
I want to blow some life into it, and a few of my friends as well. Not
with the same mind-blowing entusiasm, though, we've learned enough from
the first time around.
There are a couple of reasons my enthusiasm almost disappeared:
- personal.
- the fact that everyone (or at least a whole bunch) thought I'd be
some kind of Linus Thorvald, that would produce a kernel completely
on my own, which was never my intent.
- the fact that everyone waited for everyone. Some wanted to see a
kernel before they'd do anything, others (like me) wanted to see some
VMS programs developped so the kernel could be somewhat well tested
when it came to be.
I've seen a BACKUP clone being developped (a very good initiative!), and
got some library development initiative which never showed off,
unfortunately. The exception was a partly developped STR$ clone.
I'm currently restarting. First thing is to read a good book about Mach
(thanks, Assar, for lending it to me), which I'm currently doing.
Ah, uhmmm, Glen Everhart, are you still on this list? I recall some
talks about getting the old Digital effort, how did that go?
Well, guys, I can only say one thing: the SolarMoon (was that the name?)
announcement shook me awake. in any case, I don't mind if they do some
work. If I understand everything right, they want to make a PC-specific
thing, possibly Linux-based? I think I can see cooperation opportunities
rather than competition.
Comments? (except for the vaporware shouts, that is :-))
--
R Levitte, Levitte Programming; Spannv. 38, I; S-168 35 Bromma; SWEDEN
Tel: +46-8-26 52 47; Cel: +46-708-20 09 64; No fax right now
PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65
Check http://richard.levitte.org/ for my public key. bastard@bofh.se
"price, performance, quality. Choose any two you like"
================================================================================
Archive-Date: Fri, 3 Jul 1998 15:28:46 +0200
Message-ID: <359CEA23.FEEF620D@campus.com>
Date: Fri, 03 Jul 1998 09:26:46 -0500
From: "Andrew C. Stoffel" <acs@campus.com>
Reply-To: Free-VMS@lp.se
MIME-Version: 1.0
To: Free-VMS@lp.se
Subject: Re: Mailing List postings....
References: <1074-Fri03Jul1998000300+0200-levitte@lp.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Richard Levitte - VMS Whacker wrote:
> There are a couple of reasons my enthusiasm almost disappeared:
> - the fact that everyone (or at least a whole bunch) thought I'd be
> some kind of Linus Thorvald, that would produce a kernel completely
> on my own, which was never my intent.
In the past, a lot of time was spent on this list discussing WHERE FreeVMS
should be "rooted", in Mach, Linux, or something "fresh"/"new" but I don't
recall any conclusion to that discussion. Linus Thorvald already had
a model to start with (Minix) when he began & a lot of other people had
a large investment in that same model (Myself included) so there was
already a "development community" of sorts when Linux began. We don't need a
Linus Thorvald but we do need SOMEONE as some sort of focal point of
this effort. What kind of focal point ? It looks like that should be part of
this discussion :-)....
> I'm currently restarting. First thing is to read a good book about Mach
> (thanks, Assar, for lending it to me), which I'm currently doing.
Can you pass along that book information to the rest of us ? If nothing else
a "support organization" for this effort could be developed. Those of
us who don't have the skill/time to do actual "development" of this
can help in other ways if we can follow along and understand why things
are being done a certain way..
> Comments? (except for the vaporware shouts, that is :-))
Hmmm.... I don't consider myself to be skilled enough to do a LOT
of direct work on this. (My line of work involves VMS but mostly from
the systems/hardware management area... but I am willing to help out
where I can.
-Andy-
--
------------------------------------------------------------------------
Andy Stoffel Consultant voice: (603) 536-1882
acs@campus.com Campus America fax: (603) 536-####
================================================================================
Archive-Date: Fri, 3 Jul 1998 16:22:32 +0200
Date: Fri, 3 Jul 1998 16:22:27 +0200
Message-ID: <3544-Fri03Jul1998162227+0200-levitte@lp.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
In-Reply-To: <359CEA23.FEEF620D@campus.com> (acs@campus.com)
Subject: Re: Mailing List postings....
MIME-Version: 1.0
Content-Type: Text/Plain; Charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
From: "Andrew C. Stoffel" <acs@campus.com>
Richard Levitte - VMS Whacker wrote:
> There are a couple of reasons my enthusiasm almost disappeared:
> - the fact that everyone (or at least a whole bunch) thought I'd be
> some kind of Linus Thorvald, that would produce a kernel completely
> on my own, which was never my intent.
In the past, a lot of time was spent on this list discussing WHERE
FreeVMS should be "rooted", in Mach, Linux, or something "fresh"/"new"
but I don't recall any conclusion to that discussion.
I have always, and still intend to base Free-VMS on Mach. If someone
wants to do something based on Linux, he or she is free to do so. Some
may see a weakness in that, but I don't. Two parallell projects like
that can actually cooperate, because there will be a bunch of common
points (such as, most libraries will be common, as well as quite a bunch
of user-level programs).
Linus Thorvald already had a model to start with (Minix) when he began
My comment was more about the fact that Linus create Linux *alone*. I do
not think I have the capacity to do the same with a VMS kernel, and would
rather see a cooperation between a bunch of knowledged people (I *do*
believe I have the capacity to be part of such a group). Was that the
wrong approach? Perhaps I should have started something small, and just
thrown that out to the world and hope something would build around it...
> I'm currently restarting. First thing is to read a good book about Mach
> (thanks, Assar, for lending it to me), which I'm currently doing.
Can you pass along that book information to the rest of us ?
"Programming in Mach". You can look in http://www.free-vms.org/docs/ for
info on documents and books to read. I just now inserted the ISBN number
as well.
If nothing else a "support organization" for this effort could be
developed. Those of us who don't have the skill/time to do actual
"development" of this can help in other ways if we can follow along
and understand why things are being done a certain way..
Someone else suggested a kind of mentoring system, so some people could
code, and sometimes be mentored by people who are more knowledged, but do
not have the time...
> Comments? (except for the vaporware shouts, that is :-))
Hmmm.... I don't consider myself to be skilled enough to do a LOT
of direct work on this.
Can you program? In that case, you're qualified enough to at least hack
together one or two programs. 'cause after all, it's not just a kernel
this is about. There are libraries to write (LIB$, STR$, MTH$, and so
on), and there are all kinds of programs to write (how to you expect to
do something as simple as COPY?). So coding should be a primary concern.
I'm going to spend time on Free-VMS during the weekend. watch the task
list then.
--
R Levitte, Levitte Programming; Spannv. 38, I; S-168 35 Bromma; SWEDEN
Tel: +46-8-26 52 47; Cel: +46-708-20 09 64; No fax right now
PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65
Check http://richard.levitte.org/ for my public key. bastard@bofh.se
"price, performance, quality. Choose any two you like"
================================================================================
Archive-Date: Sat, 4 Jul 1998 21:28:55 +0200
Date: Sat, 4 Jul 1998 12:28:29 -0700 (PDT)
Message-ID: <2.2.16.19980704144217.255789b8@earthlink.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Free-VMS@lp.se
From: "David J. Dachtera" <djesys@earthlink.net>
Reply-To: Free-VMS@lp.se
Subject: FreeVMS Projects...
Folks,
Like many others, I do not consider myself as having the necessary skills
for system programming. I don't know any variant of C, or enough assembler
(any CPU) to be of much help. The bulk of my strength is in system
management and system management automation. I do also have some 3GL
background in manipulating ANSI labelled tapes without RMS's assistance,
including converting 8mm to multi-volume 9-track (labelled and unlabelled)
and converting ASCII to EBCDIC.
Still, if I may, I'd like to suggest an item that I think should receive
some priority consideration - the CLI$ routines. I should think that these
would be essential to any command-line utilities, including the existing
VMSBACKUP effort. This seems to be the horse that must precede the cart for
many, if not all, of the command-line utilities, including DCL itself.
Just my 2-cents worth. I've got LOTS of DCL code (system startup, software
installation, etc.) ideas that I can contribute once DCL for FreeVMS makes
its debut. See my OpenVMS Page at http://home.earthlink.net/~djesys/vms/ or
my VMS Freeware page (link from the VMS page) or Hobbyist Page (link from
the VMS page).
David J. Dachtera
================================================================================
Archive-Date: Mon, 6 Jul 1998 01:22:23 +0200
Date: Sun, 5 Jul 1998 19:22:51 -0400
Message-ID: <199807052322.TAA07350@harvey.cyclic.com>
From: Jim Kingdon <kingdonc@cyclic.com>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
In-Reply-To: <3544-Fri03Jul1998162227+0200-levitte@lp.se> (message from Richard Levitte - VMS Whacker on Fri, 3 Jul 1998 16:22:27 +0200)
Subject: Re: Mailing List postings....
References: <3544-Fri03Jul1998162227+0200-levitte@lp.se>
> If someone wants to do something based on Linux, he or she is free to
> do so. Some may see a weakness in that, but I don't. Two parallel
> projects like that can actually cooperate
Totally agreed. We have had enough ideological discussions in the
past, and we need less of that and more "rough consensus and running
code" (IMHO, of course).
> My comment was more about the fact that Linus create Linux *alone*. I do
> not think I have the capacity to do the same with a VMS kernel, and would
> rather see a cooperation between a bunch of knowledged people (I *do*
> believe I have the capacity to be part of such a group). Was that the
> wrong approach?
Well, I will say that it is very hard to use the cooperation approach
until you have something that people can download and start playing
with. Alan Cox mentioned this in his recent paper about porting linux
to the Macintosh, Eric Raymond says this in his Bazaar paper, and that
matches my own impressions from other projects I've observed.
So I don't really expect FreeVMS will go anywhere until someone locks
themselves in a room and comes out with something which other people
can actually run and do something interesting with. I'd probably vote
for a DCL clone (could be as simple as figuring out how to build
BOSS), but what I'd pick is kind of moot since I obviously am not
finding time to spend significant time on this.
Sorry if this is a depressing assessment :-(.
================================================================================
Archive-Date: Tue, 7 Jul 1998 01:40:26 +0200
Date: Tue, 07 Jul 1998 09:43:58 +1000
From: "Scott Hamilton, +61-2-9950 1693, NSW Dept Education and Training" <SHAMILTON1@dev.develop1.tafensw.edu.au>
Reply-To: Free-VMS@lp.se
Subject: Re: FreeVMS Project - Future?
To: Free-VMS@lp.se
Message-ID: <01IZ451IR44I013NH3@hmgwy1.isd.tafensw.edu.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Even if there is no code, documentation on which people can
code I believe could assist greatly. Everytime I think of
this project it brings up more questions that I can write down
but I guess with some documentation (what data structures look
like, what kernal-type routines will be available etc, etc...)
people don't have to wait for someone to spend time coding, they
can just read to doc's....
Just take SYS$ASSIGN as an example, think of what is needed
for someone to code up SYS$ASSIGN/EXE$ASSIGN, PCB, DDB, UCB
,CCB etc etc etc, how do you find your PCB what process
quota's will be enforced, how do you allocate a piece of non-paged
pool???
Just my 2c worth
Scott, Esq.
-------------------------------------------------------------------------------
"I can't stand this proliferation of paperwork. It's useless to fight
the forms. You've got to kill the people producing them."
-- Vladimir Kabaidze, 64, General Director of Ivanovo Machine Building Works
================================================================================
Archive-Date: Tue, 7 Jul 1998 14:14:44 +0200
Message-ID: <1.5.4.16.19980705212436.3d87c618@gate1.tomatoweb.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Free-VMS@lp.se
From: John David Galt <jdg@tomatoweb.com>
Reply-To: Free-VMS@lp.se
Subject: Re: Mailing List postings....
Date: Sun, 5 Jul 1998 21:24:04 -0700
>> My comment was more about the fact that Linus create Linux *alone*. I do
>> not think I have the capacity to do the same with a VMS kernel, and would
>> rather see a cooperation between a bunch of knowledged people (I *do*
>> believe I have the capacity to be part of such a group). Was that the
>> wrong approach?
>Well, I will say that it is very hard to use the cooperation approach
>until you have something that people can download and start playing
>with. Alan Cox mentioned this in his recent paper about porting linux
>to the Macintosh, Eric Raymond says this in his Bazaar paper, and that
>matches my own impressions from other projects I've observed.
>
>So I don't really expect FreeVMS will go anywhere until someone locks
>themselves in a room and comes out with something which other people
>can actually run and do something interesting with. I'd probably vote
>for a DCL clone (could be as simple as figuring out how to build
>BOSS), but what I'd pick is kind of moot since I obviously am not
>finding time to spend significant time on this.
If there had been only Linux, and no related efforts to draw upon, I doubt it
would be released even now. Not to denigrate Torvalds' accomplishment, but
GNU prepared the way and is an important part of the final product.
Similarly, I think there is a lot of VMS that can and should be implemented
on its own, without an actual kernel. Not only subroutine libraries and
utilities such as BACKUP, but such things as a DCL "shell" that would run on
Unix or DOS would be very helpful. (I have wanted this for a long time; it
would be good for letting unfamiliar folks "try out" the VMS environment, as
well as letting those of us who already like it use it, in places where VMS
is considered politically incorrect.)
John David Galt
================================================================================
Archive-Date: Tue, 7 Jul 1998 15:54:09 +0200
Date: Tue, 7 Jul 1998 09:54:18 -0400
Message-ID: <199807071354.JAA01209@harvey.cyclic.com>
From: Jim Kingdon <kingdonc@cyclic.com>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
In-Reply-To: <1.5.4.16.19980705212436.3d87c618@gate1.tomatoweb.com> (message from John David Galt on Sun, 5 Jul 1998 21:24:04 -0700)
Subject: Re: Mailing List postings....
References: <1.5.4.16.19980705212436.3d87c618@gate1.tomatoweb.com>
> If there had been only Linux, and no related efforts to draw upon, I doubt it
> would be released even now. Not to denigrate Torvalds' accomplishment, but
> GNU prepared the way and is an important part of the final product.
Well, both Torvalds and GNU made a practice of releasing parts of the
"final product" well before anything was "finished". The first
release of most of the GNU programs was pretty buggy (and explicitly
advertised as "beta test"); the first release of the linux kernel was
even less useful. I think we are agreed that such early releases are
desirable, and that it is a Good Thing to quickly get to a state where
someone besides the original author might be able to download and run
_something_.
Your suggestion of a DCL clone for Unix or DOS is one good project.
Please download microDCL and play with it. It is probably a dead end
but it already exists and is very easy to install (it is for DOS). If
you want something more ambitious take a look at BOSS and see whether
you can make progress on building it (picking up where I left off).
Other possible projects would be enhanced versions of VMS utilities,
for use on VMS. For example, I wish I had an equivalent to "rm -rf"
(DELETE/TREE or whatever we'd call it). Others might disagree with
this specific example, but the point is that surely there is _some_
aspect of _some_ VMS utility that could be improved.
================================================================================
Archive-Date: Tue, 7 Jul 1998 16:06:53 +0200
Message-ID: <032001bda9b0$b0b9b260$fbfe21c0@theo.progis.de>
Reply-To: Free-VMS@lp.se
From: "Klaus Kaempf" <kkaempf@rmi.de>
To: <free-vms@lp.se>
Subject: Re: Mailing List postings....
Date: Tue, 7 Jul 1998 16:02:29 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
>
>Similarly, I think there is a lot of VMS that can and should be implemented
>on its own, without an actual kernel. Not only subroutine libraries and
>utilities such as BACKUP, but such things as a DCL "shell" that would run on
>Unix or DOS would be very helpful.
Right. Even more complicated things as the RMS filesystem can be implemented
(although not fully) without a kernel. All one needs is a
(C/Bliss/Fortran/whatever) Compiler and a system with raw disk access (like
linux).
Most of the other tools just need any kind of filesystem, provided the tool <->
system interface is coded cleanly and can be switched to the 'real' FreeVMS
later.
I'd like to see a cvs server with the code already contributed (include files,
dcl, string library,
documentation drafts, etc.) and a consensus about the development environment.
Klaus
---
Klaus Kaempf kkaempf@rmi.de
Jakobstr. 181
D-52064 Aachen Yes, my email account changed.
================================================================================
Archive-Date: Tue, 7 Jul 1998 16:09:36 +0200
Date: Tue, 7 Jul 1998 16:09:24 +0200
Message-ID: <9765-Tue07Jul1998160924+0200-levitte@lp.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
In-Reply-To: <199807071354.JAA01209@harvey.cyclic.com> (message from Jim Kingdon on Tue, 7 Jul 1998 09:54:18 -0400)
Subject: Re: Mailing List postings....
MIME-Version: 1.0
Content-Type: Text/Plain; Charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
From: Jim Kingdon <kingdonc@cyclic.com>
If you want something more ambitious take a look at BOSS and see
whether you can make progress on building it (picking up where I left
off).
I intend to look at BOSS, since it also contains a bunch of library
routines, and especially CDU and the CLI$ routines.
For example, I wish I had an equivalent to "rm -rf" (DELETE/TREE or
whatever we'd call it). Others might disagree with this specific
example, but the point is that surely there is _some_ aspect of _some_
VMS utility that could be improved.
There are absolutelly places where improvement is in place. The removal
of a directory tree is on my wishlist as well (but there's no need for an
extra qualifier, just more intelligent handling of the directory tree
:-)). *thinks* hmm, I think I that somewhere among my sources... time
to dig that up, I guess...
--
R Levitte, Levitte Programming; Spannv. 38, I; S-168 35 Bromma; SWEDEN
Tel: +46-8-26 52 47; Cel: +46-708-20 09 64; No fax right now
PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65
Check http://richard.levitte.org/ for my public key. bastard@bofh.se
"price, performance, quality. Choose any two you like"
================================================================================
Archive-Date: Tue, 7 Jul 1998 16:26:37 +0200
Date: Tue, 7 Jul 1998 16:23:04 +0200
Message-ID: <1176-Tue07Jul1998162304+0200-levitte@lp.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
In-Reply-To: <032001bda9b0$b0b9b260$fbfe21c0@theo.progis.de> (kkaempf@rmi.de)
Subject: Re: Mailing List postings....
MIME-Version: 1.0
Content-Type: Text/Plain; Charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
From: "Klaus Kaempf" <kkaempf@rmi.de>
I'd like to see a cvs server with the code already contributed
(include files, dcl, string library, documentation drafts, etc.) and a
consensus about the development environment.
I have a CVS server with a lot of available space (at stacken.kth.se). I
use it for the development tree of FISH already. I have however
experienced locking problems with it, perhaps you or Jim can help
diagnose it?
Once that prolem is removed, I see no problem with starting to use it
right away.
--
R Levitte, Levitte Programming; Spannv. 38, I; S-168 35 Bromma; SWEDEN
Tel: +46-8-26 52 47; Cel: +46-708-20 09 64; No fax right now
PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65
Check http://richard.levitte.org/ for my public key. bastard@bofh.se
"price, performance, quality. Choose any two you like"
================================================================================
Archive-Date: Tue, 7 Jul 1998 17:35:10 +0200
Date: Tue, 7 Jul 1998 11:35:22 -0400
Message-ID: <199807071535.LAA02690@harvey.cyclic.com>
From: Jim Kingdon <kingdonc@cyclic.com>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
In-Reply-To: <032001bda9b0$b0b9b260$fbfe21c0@theo.progis.de> (kkaempf@rmi.de)
Subject: Re: Mailing List postings....
References: <032001bda9b0$b0b9b260$fbfe21c0@theo.progis.de>
> I'd like to see a cvs server with the code already contributed
> (include files, dcl, string library, documentation drafts, etc.)
There is a CVS server with some of it at
http://www.cyclic.com/cgi-bin/cvsweb/kingdon
However, it sounds like the CVS server at stacken.kth.se would be a
better choice for being an "official" CVS server. I'd be glad to try
to help you with locking problems, Richard, just send email with
details of the problem.
> a consensus about the development environment.
Oh, gosh, I think I'd rather try to develop that in an evolutionary
way _after_ we have more code. I mean, we could easily spin our
wheels for quite a while and not accomplish much. For now I would say
something vague like "should be easy to download and build a package"
and leave the rest to letting package maintainers borrow good ideas
from each other.
================================================================================
Archive-Date: Tue, 7 Jul 1998 18:08:54 +0200
Date: Tue, 7 Jul 1998 18:08:44 +0200
Message-ID: <7348-Tue07Jul1998180844+0200-levitte@lp.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
In-Reply-To: <199807071535.LAA02690@harvey.cyclic.com> (message from Jim Kingdon on Tue, 7 Jul 1998 11:35:22 -0400)
Subject: Re: Mailing List postings....
MIME-Version: 1.0
Content-Type: Text/Plain; Charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
I'd be glad to try to help you with locking problems, Richard, just
send email with details of the problem.
I'll take that privately with you.
> a consensus about the development environment.
Oh, gosh, I think I'd rather try to develop that in an evolutionary
way _after_ we have more code. I mean, we could easily spin our
wheels for quite a while and not accomplish much. For now I would say
something vague like "should be easy to download and build a package"
and leave the rest to letting package maintainers borrow good ideas
from each other.
I agree completelly. "Talk is good, but code is better", says a friend
of mine. He's quite right :-).
--
R Levitte, Levitte Programming; Spannv. 38, I; S-168 35 Bromma; SWEDEN
Tel: +46-8-26 52 47; Cel: +46-708-20 09 64; No fax right now
PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65
Check http://richard.levitte.org/ for my public key. bastard@bofh.se
"price, performance, quality. Choose any two you like"
================================================================================
Archive-Date: Tue, 7 Jul 1998 19:10:04 +0200
From: Bill/Carolyn Pechter <pechter@shell.monmouth.com>
Reply-To: Free-VMS@lp.se
Message-ID: <199807071709.NAA21080@shell.monmouth.com>
Subject: PC-VMS
To: free-vms@lp.se
Date: Tue, 7 Jul 1998 13:09:52 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
A long time ago I promised to dig this up and make it available.
I've got the book but came up empty on the disks. I'm still digging through
5 1/4 floppy piles without luck. If I find it I'll be glad to donate them
to the FreeVMS effort in some way.
The docs are quite interesting. Is there anyone who knows what
became of the Wendin folks?
Bill
+---------------------------------------------------------------------------+
| Bill and/or Carolyn Pechter | pechter@shell.monmouth.com |
| Bill Gates is a Persian cat and a monocle away from being a James Bond |
| villain." -- Dennis Miller |
+---------------------------------------------------------------------------+
================================================================================
Archive-Date: Tue, 7 Jul 1998 19:41:32 +0200
Message-ID: <4FD6422BE942D111908D00805F3158DF04158654@red-msg-52.dns.microsoft.com>
From: Chris Kaler <ckaler@microsoft.com>
Reply-To: Free-VMS@lp.se
To: "'Free-VMS@lp.se'" <Free-VMS@lp.se>
Subject: RE: Mailing List postings....
Date: Tue, 7 Jul 1998 10:41:13 -0700
Your suggestion of a DCL clone for Unix or DOS is one good project.
Please download microDCL and play with it. It is probably a dead end
but it already exists and is very easy to install (it is for DOS). If
you want something more ambitious take a look at BOSS and see whether
you can make progress on building it (picking up where I left off).
CK> Although not free, the best one I have seen is from BBS (Boston Business
CK> Services). They have a DCL and EDT clone for PCs. It is really quite
CK> nice. As well, there is NuTPU. These can be great sources of ideas.
================================================================================
Archive-Date: Tue, 7 Jul 1998 19:57:49 +0200
Date: Tue, 7 Jul 98 10:57:30 PDT
From: pvhp@forte.com (Peter Prymmer)
Reply-To: Free-VMS@lp.se
Message-ID: <9807071757.AA22759@forte.com>
To: Free-VMS@lp.se, jdg@tomatoweb.com
Subject: Re: DCL on other platforms (was Mailing List postings....)
John David Galt wrote:
> Similarly, I think there is a lot of VMS that can and should be implemented
> on its own, without an actual kernel. Not only subroutine libraries and
> utilities such as BACKUP, but such things as a DCL "shell" that would run on
> Unix or DOS would be very helpful. (I have wanted this for a long time; it
> would be good for letting unfamiliar folks "try out" the VMS environment, as
> well as letting those of us who already like it use it, in places where VMS
> is considered politically incorrect.)
There is microDCL (and apparently BOSS? <<-- I don't know much about it could
someone comment?). In the commercial realm (a few hundred dollars or so)
there is Acceler8 and at least one other DCL clone expressly for NT that
were shown at last Fall's DECUS in Anaheim. I recall that one could support
logical names and f$trnlnm() and the other did not (though the one that did did
not appear to support multiple tables). I am sorry but I cannot
locate any URLs at this time. When I did a search at altavista adverts from
DEC/Compaq came up indicating that they were working on such things for NT
too.
Peter Prymmer
================================================================================
Archive-Date: Tue, 7 Jul 1998 20:36:53 +0200
Date: Tue, 7 Jul 98 11:36:34 PDT
From: pvhp@forte.com (Peter Prymmer)
Reply-To: Free-VMS@lp.se
Message-ID: <9807071836.AA26560@forte.com>
To: Free-VMS@lp.se, kingdonc@cyclic.com, levitte@lp.se
Subject: rm -rf equiv (was Re: Mailing List postings....)
Richard Levitte wrote to Jim Kingdon:
> For example, I wish I had an equivalent to "rm -rf" (DELETE/TREE or
> whatever we'd call it). Others might disagree with this specific
> example, but the point is that surely there is _some_ aspect of _some_
> VMS utility that could be improved.
To get "rm -rf" on VMS now one can modify the recursive descent parsers
in DCL to do DELETE. Alternatively, one can use perl in this fashion:
$ type rmtree.com
$ perl -"MFile::Path" -e "@d=map(VMS::Filespec::unixify($_),@ARGV);rmtree(\@d,0,0)" 'p1
where the usage is:
@rmtree DEV:[ROOT.SDIR]
and everything from DEV:[ROOT.SDIR..] on down will be deleted including
DEV:[ROOT]SDIR.DIR;1, but everything else in DEV:[ROOT] will stay.
BTW, I do think that a /TREE qualifier (or similar) to DELETE would be cool.
> There are absolutelly places where improvement is in place. The removal
> of a directory tree is on my wishlist as well (but there's no need for an
> extra qualifier, just more intelligent handling of the directory tree
> :-)). *thinks* hmm, I think I that somewhere among my sources... time
> to dig that up, I guess...
In my opinion the two problems with VMS are:
1) 8 dir depth limit (now gone in the RMS that comes with 7.2?)
2) inconsistent I/O redirection in DCL (somewhat ameliorated by
DCLcomplete and/or PIPE)
Allegedly, DOS and its heirs learned '>', '>>', '|' et al. from Microsoft's
early foray into SCO Xenix. But VMS never learned: some verbs take /OUT, some
take /LIST, and some don't take anything. E.g. the only way that I know how*
to redirect the output of SHOW SYMBOL * is to do a SET HOST 0/LOG beforehand
(which in turn requires a network up and running). *:if you know of some
other trick I would love to hear about it.
Unfortunately coming up with a new .CLD for everthing that you'd want to
re-direct would entail a great deal of work. Hence having it built into the
shell at the outset would be a good thing I'd think (assuming folks agree that
it is good :-).
Peter Prymmer
================================================================================
Archive-Date: Tue, 7 Jul 1998 20:53:07 +0200
Message-ID: <35A27BCD.CD6FC788@campus.com>
Date: Tue, 07 Jul 1998 14:49:42 -0500
From: "Andrew C. Stoffel" <acs@campus.com>
Reply-To: Free-VMS@lp.se
MIME-Version: 1.0
To: Free-VMS@lp.se
Subject: Re: DCL on other platforms (was Mailing List postings....)
References: <9807071757.AA22759@forte.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Peter Prymmer wrote:
> In the commercial realm (a few hundred dollars or so)
> there is Acceler8 and at least one other DCL clone expressly for NT that
> were shown at last Fall's DECUS in Anaheim.
Not sure if this is the one you're talking about but check out XLNT:
http://www.advsyscon.com/products/xlnt/
It's been a while since I checked it out so I'm not sure/don't recall
how good of an example of a DCL clone it is.... & it's NOT free....
-Andy-
--
------------------------------------------------------------------------
Andy Stoffel Consultant voice: (603) 536-1882
acs@campus.com Campus America fax: (603) 536-####
================================================================================
Archive-Date: Tue, 7 Jul 1998 20:54:25 +0200
Message-ID: <4FD6422BE942D111908D00805F3158DF0415865A@red-msg-52.dns.microsoft.com>
From: Chris Kaler <ckaler@microsoft.com>
Reply-To: Free-VMS@lp.se
To: "'Free-VMS@lp.se'" <Free-VMS@lp.se>
Subject: RE: rm -rf equiv (was Re: Mailing List postings....)
Date: Tue, 7 Jul 1998 11:53:52 -0700
To get "rm -rf" on VMS now one can modify the recursive descent
parsers
in DCL to do DELETE. Alternatively, one can use perl in this
fashion:
CK> Actually it does do it today, it just has a "bug". DELETE [...]*.*;*
will
CK> do a recursive delete, it just tries to delete a directory before it has
CK> deleted the contents. That is a fairly straightforward thing to fix.
CK> However, there are likely DCL scripts that rely on the behavior... so
how
CK> do you change in a compatible way? Do you care?
In my opinion the two problems with VMS are:
1) 8 dir depth limit (now gone in the RMS that comes with 7.2?)
CK> I doubt if it is *really* fixed. I know they were planning some work
CK> to make it better for backup and PC connectivity, but the problem is
that
CK> the RMS data structures have a fixed structure for 8 levels.
2) inconsistent I/O redirection in DCL (somewhat ameliorated by
DCLcomplete and/or PIPE)
Allegedly, DOS and its heirs learned '>', '>>', '|' et al. from
Microsoft's
early foray into SCO Xenix. But VMS never learned: some verbs take
/OUT, some
take /LIST, and some don't take anything. E.g. the only way that I
know how*
to redirect the output of SHOW SYMBOL * is to do a SET HOST 0/LOG
beforehand
(which in turn requires a network up and running). *:if you know of
some
other trick I would love to hear about it.
CK> The problem is that DEC must maintain backward compatibility. So you
would
CK> need to invent a new qualifier as well as supporting the old ones. I
suspect
CK> you would need to do the same for anything you write as you want to be
able
CK> to re-use all those DCL scripts you have laying around.
Unfortunately coming up with a new .CLD for everthing that you'd
want to
re-direct would entail a great deal of work. Hence having it built
into the
shell at the outset would be a good thing I'd think (assuming folks
agree that
it is good :-).
CK> Exactly -- that's why I built the PIPE command. It was a way of making
CK> it work in a backwardly compatible way. :-)
================================================================================
Archive-Date: Tue, 7 Jul 1998 21:05:34 +0200
MIME-Version: 1.0
Date: Tue, 7 Jul 1998 14:03:52 -0500
Message-ID: <00068D17.1870@advocatehealth.com>
From: David.Dachtera@advocatehealth.com (David Dachtera)
Reply-To: Free-VMS@lp.se
Subject: Re[2]: DCL on other platforms (was Mailing List postings....
To: Free-VMS@lp.se
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Peter,
Try:
http://www.accelr8.com/
or
http://www.sector7.com/
These two sources have a (more or less) complete VMS-like
environment for UN*X.
http://www.advsyscon.com/products/xlnt/
For XLNT (eXtended command Language for NT and
windows/95). There is some documentation available in PDF
form at
http://www.advsyscon.com/products/xlnt/pdfdoc.html
XLNT is a DCL-like command language for Win/NT and Win/95
with (MANY!) Windows-specific extensions.
I wouldn't be surprised if |C|o|m|p|a|q| is negotiating
to buy this product. Knowing |D|E|C| however, they're
probably doing their own. (So, shouldn't PC-VMS be the
next logical step?)
David J. Dachtera
djesys.nospam at earthlink.net
______________________________ Reply Separator _________________________________
Subject: Re: DCL on other platforms (was Mailing List postings....)
Author: Free-VMS@lp.se at PO_EXTERNET
Date: 7/7/98 12:57 PM
John David Galt wrote:
> Similarly, I think there is a lot of VMS that can and should be implemented
> on its own, without an actual kernel. Not only subroutine libraries and
> utilities such as BACKUP, but such things as a DCL "shell" that would run on
> Unix or DOS would be very helpful. (I have wanted this for a long time; it
> would be good for letting unfamiliar folks "try out" the VMS environment, as
> well as letting those of us who already like it use it, in places where VMS
> is considered politically incorrect.)
There is microDCL (and apparently BOSS? <<-- I don't know much about it could
someone comment?). In the commercial realm (a few hundred dollars or so)
there is Acceler8 and at least one other DCL clone expressly for NT that
were shown at last Fall's DECUS in Anaheim. I recall that one could support
logical names and f$trnlnm() and the other did not (though the one that did did
not appear to support multiple tables). I am sorry but I cannot
locate any URLs at this time. When I did a search at altavista adverts from
DEC/Compaq came up indicating that they were working on such things for NT
too.
Peter Prymmer
================================================================================
Archive-Date: Tue, 7 Jul 1998 21:06:02 +0200
MIME-Version: 1.0
Date: Tue, 7 Jul 1998 14:09:01 -0500
Message-ID: <00068D19.1870@advocatehealth.com>
From: David.Dachtera@advocatehealth.com (David Dachtera)
Reply-To: Free-VMS@lp.se
Subject: Re: SolarMoon.org (FYI)
To: Free-VMS@lp.se
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Folks,
The following display documents my efforts to locate
solarmoon.org...
EHSSRV::DDACHTERA$ MULT NSLO
Default Server: corpIPman.corp.advocatehealth.com
Address: 134.73.19.10
> WWW.SOLARMOON.ORG
Server: corpIPman.corp.advocatehealth.com
Address: 134.73.19.10
*** Request to corpIPman.corp.advocatehealth.com
timed-out
> set type=any
> www.solarmoon.org
Server: corpIPman.corp.advocatehealth.com
Address: 134.73.19.10
*** Request to corpIPman.corp.advocatehealth.com
timed-out
> solarmoon.org
Server: corpIPman.corp.advocatehealth.com
Address: 134.73.19.10
Non-authoritative answer:
solarmoon.org nameserver = NS2.ILO.NET
solarmoon.org nameserver = NS1.ILO.NET
Authoritative answers can be found from:
solarmoon.org nameserver = NS2.ILO.NET
solarmoon.org nameserver = NS1.ILO.NET
NS2.ILO.NET internet address = 206.135.200.3
NS1.ILO.NET internet address = 209.100.132.175
> server ns1.ilo.net
Default Server: ns1.ilo.net
Address: 209.100.132.175
> ls -d solarmoon.org
*** Can't list domain solarmoon.org: Unspecified errorut
> server ns2.ilo.net
*** Can't find address for server ns2.ilo.net: Timed out
> Exit
David J. Dachtera
djesys.nospam at earthlink.net
================================================================================
Archive-Date: Tue, 7 Jul 1998 21:06:18 +0200
MIME-Version: 1.0
Date: Tue, 7 Jul 1998 14:06:57 -0500
Message-ID: <00068D18.1870@advocatehealth.com>
From: David.Dachtera@advocatehealth.com (David Dachtera)
Reply-To: Free-VMS@lp.se
Subject: Re[2]: FreeVMS Project - Future?
To: Free-VMS@lp.se
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Folks,
Another idea ocurred to me this morning, and I wanted to
pass it along in the hope that it might be useful.
I want to suggest that all 3GLs for FreeVMS be C
transpilers (that word may be someone's trademark - check
it out). That way, existing software can more easily be
ported from OpenVMS to FreeVMS(, BSD, etc.).
I thought since GCC and GAS are already around, it might
make sense. There's even G77 - a Fortran-to-C transpiler,
and some others. I know there's a BTRAN out there;
however, the author admits that it's incomplete.
I've read in this mailing list that BLISS-to-C might be
kinda hairy.
Accelr8 (www.accelr8.com) and Sector7 (www.sector7.com)
already have commercial transpiler products as well as
VMS-like environment suites for commercial UN*X. Don't
know what conflicts might arise if similar freeware were
to emerge.
So, maybe this is not a feasible idea. Let the consensus
decide.
David J. Dachtera
djesys.nospam at eartlink.net
================================================================================
Archive-Date: Tue, 7 Jul 1998 22:01:30 +0200
MIME-Version: 1.0
Date: Tue, 7 Jul 1998 15:01:00 -0500
Message-ID: <00068DCE.1870@advocatehealth.com>
From: David.Dachtera@advocatehealth.com (David Dachtera)
Reply-To: Free-VMS@lp.se
Subject: Re: rm -rf equiv (was Re: Mailing List postings....)
To: Free-VMS@lp.se
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Peter,
Re: Output Re-direction
In a very un-UN*X-like manner, you can
$ DEFINE/USER SYS$OUTPUT filespec
...for just about any command implemented as an image
external to DCL. This is the equivalent to UN*X's
"stdout" stream. SYS$ERROR = stderr, SYS$INPUT = stdin,
SYS$COMMAND = (no UN*X equivalent).
For SHOW SYMBOL, you can (usually)
$ SPAWN/OUT=filespec SHOW SYMBOL/ALL[/GLOBAL]
This works for many of DCL's "internal" commands.
Also, per your example, perl is add-on freeware, not part
of DCL - DCL has no "recursive descent parsers", AFAIK.
If they were anywhere, they'd be in LIB$FIND_FILE or the
routines that comprise it.
Most DELTREE.COM's implement F$SEARCH() to traverse
directory trees from the ends of the "branches" back
toward the root. As on most most other o.s.es,
directories cannot be deleted unless they are empty. So,
for each directory level there's a two-step process:
Step 1: $ DELETE [.THISLEVEL]*.*;*
Step 2: $ DELETE THISLEVEL.DIR;
Also, deleting a directory usually requires that you have
either BYPASS privilege or DELETE access to the directory
being deleted.
The exception to this rule is the unsupported freeware
DFU program from Digital which implements a "fast
deltree" function (which can leave files "orphaned" (not
found in a directory) if interrupted).
David J. Dachtera
djesys.nospam at earthlink.net
______________________________ Reply Separator _________________________________
Subject: rm -rf equiv (was Re: Mailing List postings....)
Author: Free-VMS@lp.se at PO_EXTERNET
Date: 7/7/98 1:36 PM
Richard Levitte wrote to Jim Kingdon:
> For example, I wish I had an equivalent to "rm -rf" (DELETE/TREE or
> whatever we'd call it). Others might disagree with this specific
> example, but the point is that surely there is _some_ aspect of _some_
> VMS utility that could be improved.
To get "rm -rf" on VMS now one can modify the recursive descent parsers
in DCL to do DELETE. Alternatively, one can use perl in this fashion:
$ type rmtree.com
$ perl -"MFile::Path" -e
"@d=map(VMS::Filespec::unixify($_),@ARGV);rmtree(\@d,0,0)" 'p1
where the usage is:
@rmtree DEV:[ROOT.SDIR]
and everything from DEV:[ROOT.SDIR..] on down will be deleted including
DEV:[ROOT]SDIR.DIR;1, but everything else in DEV:[ROOT] will stay.
BTW, I do think that a /TREE qualifier (or similar) to DELETE would be cool.
> There are absolutelly places where improvement is in place. The removal
> of a directory tree is on my wishlist as well (but there's no need for an
> extra qualifier, just more intelligent handling of the directory tree
> :-)). *thinks* hmm, I think I that somewhere among my sources... time
> to dig that up, I guess...
In my opinion the two problems with VMS are:
1) 8 dir depth limit (now gone in the RMS that comes with 7.2?)
2) inconsistent I/O redirection in DCL (somewhat ameliorated by
DCLcomplete and/or PIPE)
Allegedly, DOS and its heirs learned '>', '>>', '|' et al. from Microsoft's
early foray into SCO Xenix. But VMS never learned: some verbs take /OUT, some
take /LIST, and some don't take anything. E.g. the only way that I know how*
to redirect the output of SHOW SYMBOL * is to do a SET HOST 0/LOG beforehand
(which in turn requires a network up and running). *:if you know of some
other trick I would love to hear about it.
Unfortunately coming up with a new .CLD for everthing that you'd want to
re-direct would entail a great deal of work. Hence having it built into the
shell at the outset would be a good thing I'd think (assuming folks agree that
it is good :-).
Peter Prymmer
================================================================================
Archive-Date: Tue, 7 Jul 1998 22:28:54 +0200
Message-ID: <199807072023.PAA18983@taarna.sector7.com>
To: Free-VMS@lp.se
Subject: Re: Re[2]: DCL on other platforms (was Mailing List postings....
In-Reply-To: Your message of "Tue, 07 Jul 1998 14:03:52 CDT." <00068D17.1870@advocatehealth.com>
Date: Tue, 07 Jul 1998 15:23:26 -0500
From: Jay Bolton <jay@sector7.com>
Reply-To: Free-VMS@lp.se
David...
I am told by fairly reliable sources within the company that "Transpiler(tm)"
is held by Sector 7, USA, Inc. although I have not seen any paperwork that
specifically documents this, other than some trade literature which uses
the (tm) mark to denote it.
Jay
================================================================================
Archive-Date: Tue, 7 Jul 1998 22:47:55 +0200
MIME-Version: 1.0
Date: Tue, 7 Jul 1998 15:41:50 -0500
Message-ID: <00068E51.1870@advocatehealth.com>
From: David.Dachtera@advocatehealth.com (David Dachtera)
Reply-To: Free-VMS@lp.se
Subject: Re[2]: rm -rf equiv (was Re: Mailing List postings....)
To: Free-VMS@lp.se
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Peter (et al),
To get some idea how complex "DELTREE" really is, you can
download from the following URL:
http://home.eartlink.net/~djesys/freeware/vms/vms_dos.zip
In the archive, you'll find my version of a DELTREE.COM.
(It's a VMS .ZIP archive - won't unpack on other systems,
at least not correctly, anyway.) DELTREE.COM is unique in
that it uses no SET DEFAULT commands. That way, a
nonDELETE-able file in the middle of a branch does not
leave your default disk/directory in an unknown state.
This should illustrate the situation rather clearly.
The "problem" (if you want to call it that) is that you
cannot delete a directory until it is empty. If you did,
you'd leave files "orphaned" (no directory entry).
That's why this works the way it does.
David J. Dachtera
djesys.nospam at earthlink.net
================================================================================
Archive-Date: Tue, 7 Jul 1998 23:00:36 +0200
Date: Tue, 7 Jul 98 14:00:18 PDT
From: pvhp@forte.com (Peter Prymmer)
Reply-To: Free-VMS@lp.se
Message-ID: <9807072100.AA10185@forte.com>
To: David.Dachtera@advocatehealth.com, Free-VMS@lp.se
Subject: Re: rm -rf equiv (was Re: Mailing List postings....)
David Dachtera wrote in reply to me:
> Peter,
>
> Re: Output Re-direction
>
> In a very un-UN*X-like manner, you can
>
> $ DEFINE/USER SYS$OUTPUT filespec
>
> ...for just about any command implemented as an image
> external to DCL. This is the equivalent to UN*X's
> "stdout" stream. SYS$ERROR = stderr, SYS$INPUT = stdin,
> SYS$COMMAND = (no UN*X equivalent).
Yes I understand, but the fact that it is not as simple or elegent as
$ verb > filespec
was the problem. It's just a criticism of DCL and one that I hope could
be avoided. Free source code in C for a wide variety of shells that do
implement such I/O redirection is available. The source to PIPE and
DCLcomplete and perl which all do it on VMS is also available.
> For SHOW SYMBOL, you can (usually)
>
> $ SPAWN/OUT=filespec SHOW SYMBOL/ALL[/GLOBAL]
>
> This works for many of DCL's "internal" commands.
Thanks for the tip! I hadn't thought of that (I'd posted the problem to
comp.os.vms a while back too :-)
> Also, per your example, perl is add-on freeware, not part
> of DCL - DCL has no "recursive descent parsers", AFAIK.
> If they were anywhere, they'd be in LIB$FIND_FILE or the
> routines that comprise it.
>
> Most DELTREE.COM's implement F$SEARCH() to traverse
> directory trees from the ends of the "branches" back
> toward the root. As on most most other o.s.es,
> directories cannot be deleted unless they are empty. So,
> for each directory level there's a two-step process:
When I referred to recursive descent parsers I was referring to the various
DELTREE.COM's that are written with recursive sub calls - no fancy library
call.
I should have pointed out to folks that the perl solution that I mentioned
can run into trouble (ACCESS VIO) on really big devices that have not been
purged on VAXen running 6.2 with perl compiled with DEC C V5.3-006, though I
have not seen any trouble with it in recent months.
> Step 1: $ DELETE [.THISLEVEL]*.*;*
> Step 2: $ DELETE THISLEVEL.DIR;
>
> Also, deleting a directory usually requires that you have
> either BYPASS privilege or DELETE access to the directory
> being deleted.
>
> The exception to this rule is the unsupported freeware
> DFU program from Digital which implements a "fast
> deltree" function (which can leave files "orphaned" (not
> found in a directory) if interrupted).
Yes I've used that too - very powerful.
BTW, Thanks also for the URLs for accelr8 and xlnt - those were the
products that I was referring to earlier.
Peter Prymmer
================================================================================
Archive-Date: Tue, 7 Jul 1998 23:24:21 +0200
Date: Tue, 7 Jul 1998 17:23:45 -0400 (EDT)
From: Jerrold Leichter <leichter@smarts.com>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: rm -rf equiv (was Re: Mailing List postings....)
In-Reply-To: <9807072100.AA10185@forte.com>
Message-ID: <Pine.SOL.3.96.980707171730.21292R-100000@just>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
This little thread is a wonderful example of one reason - perhaps not the most
important one, but a significant one - why a FreeVMS project has never gotten
off the ground.
Whether an 'rm -rf' equivalent is available, whether redirectly a la Unix is
available - these are trivial points. No DELETE is available! No DCL is
available! Worrying about whether a new, yet-to-be-designed (much less
written) implementation will include new, ultimately trivial features (it's no
big deal to implement tree deletion, and redirection is pretty useless for
most native VMS utilities, since they don't act as pipelines) is like spending
our debating about the brand of air freshener to be used in the apartment
you're going to rent in a skyscraper located in a city that exists so far as
sketches in some urban planner's notebook!
Once the basic stuff is written and working, anyone can hack to his heart's
content to add nifty features and extensions. Without the basic stuff, why
waste everyone's time?
-- Jerry
================================================================================
Archive-Date: Wed, 8 Jul 1998 00:55:37 +0200
Date: Tue, 7 Jul 1998 18:58:15 -0400
From: "Brian Schenkenberger, VAXman-" <system@TMESIS.COM>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Message-ID: <009C8D61.A962AAB3.1@TMESIS.COM>
Subject: Re: DCL on other platforms (was Mailing List postings....)
>Peter Prymmer wrote:
>
>> In the commercial realm (a few hundred dollars or so)
>> there is Acceler8 and at least one other DCL clone expressly for NT that
>> were shown at last Fall's DECUS in Anaheim.
>
>Not sure if this is the one you're talking about but check out XLNT:
>
> http://www.advsyscon.com/products/xlnt/
>
>It's been a while since I checked it out so I'm not sure/don't recall
>how good of an example of a DCL clone it is.... & it's NOT free....
And it's not XLNT either. I can make it crash 14 different ways from Sunday
with a simple pseudo DCL hack. For those of you that are aware of my plight
for nearly 2.5 years would not patronize this product.
Acceler8's DCL is DCL like. XLNT sucks eggs.
I've spent more time in the bowels of DCL than probably anybody on this list.
If a DCL language is what you want, I could put one together that would sink
coffin nails into the not-so-XLNT products. However, as I've said may times
before, DCL is NOT VMS!
--
VAXman- OpenVMS APE certification number: AAA-0001 VAXman@TMESIS.COM
================================================================================
Archive-Date: Wed, 8 Jul 1998 01:49:48 +0200
Message-ID: <1.5.4.32.19980707235605.006f6a40@snake.srv.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 07 Jul 1998 17:56:05 -0600
To: Free-VMS@lp.se
From: Kevin Handy <kth@srv.net>
Reply-To: Free-VMS@lp.se
Subject: Re: Re[2]: FreeVMS Project - Future?
At 02:06 PM 7/7/98 -0500, you wrote:
> Folks,
>
> Another idea ocurred to me this morning, and I wanted to
> pass it along in the hope that it might be useful.
>
> I want to suggest that all 3GLs for FreeVMS be C
> transpilers (that word may be someone's trademark - check
> it out). That way, existing software can more easily be
> ported from OpenVMS to FreeVMS(, BSD, etc.).
I'd prefer everything to be coded using a small set of
languages. Preferibally just C/C++. This would make it
easier for others to work on the code. If you look at Unix,
almost everyone codes in C, so you only need to know one
language to be involved in the fun.
We would want to be able to give users other languages, but I'd
still prefer to use something that has been standardized for
several platforms, so the code may be ported to other enviornments
easily. You don't see any Bliss programs running on Unix,
because of the lack of a standard compiler.
> I thought since GCC and GAS are already around, it might
> make sense. There's even G77 - a Fortran-to-C transpiler,
> and some others. I know there's a BTRAN out there;
> however, the author admits that it's incomplete.
Actually, G77 is built onto the GCC code generator. It doesn't
do an intermediate conversion to C. This is another way to
write a fairly portable compiler. GCC was designed with the
idea of being able to re-use the code generator.
f77 (which is probibly what you are thinging of) does go through
a C translation.
Btran is incomplete, but it is still able to handle a lot
of Vax/Basic code. Mostly what is missing are: file I/O,
structures, and functions (and I'm working on them in my rare
moments of spare time). I have actually gotten many programs
to compile through it.
> I've read in this mailing list that BLISS-to-C might be
> kinda hairy.
Someone started up one of these called IGNORANCE (ignorance is bliss)
which sould be available on the web somewhere. I don't know how far
it got, but since I don't know bliss....
> Accelr8 (www.accelr8.com) and Sector7 (www.sector7.com)
> already have commercial transpiler products as well as
> VMS-like environment suites for commercial UN*X. Don't
> know what conflicts might arise if similar freeware were
> to emerge.
If we do the work ourselves, and don't copy their code, there
should'nt be any problem. We're just doing the same things they
did (creating VMS like routines). Only Digital (err, Compaq)
should be able to complain, and if you don't copy their code,
they shouldn't be able to complain too much.
> So, maybe this is not a feasible idea. Let the consensus
> decide.
Also, my company has an accounting package written in (Vax/Basic,
Vax/C, Cdd) that I am thinking of making available in the near future
on the Web. (It was one of my main reasons for Btran). And am
wondering what kind of intrest there is here? It includes
General Ledger, Accounts Receivable, Accounts Payable, Payroll,
Inventory, Purchase Order, Job Costing, Work In Process,
Bank Reconciliation, ...
Btran has parsed all of the source code, but the generated code is
not quite there, and libraries are missing (RMS, SMG, ...).
I have started a new version (which will be running on Linux
using PostgreSQL), but it is in a very preliminary state (just
working on file layouts).
Anyone have any kind of intrest in this type of stuff? I'll
probibly release it as freeware, with a request for donations
to help fund additional development.
-------------------------------------------------------------
Kevin Handy kth@srv.net Accounting Software for
Software Solutions. Inc. VAX/VMS Computer Systems
Idaho Falls, Idaho
================================================================================
Archive-Date: Wed, 8 Jul 1998 02:35:06 +0200
Date: Tue, 7 Jul 1998 20:35:25 -0400
Message-ID: <199807080035.UAA10345@harvey.cyclic.com>
From: Jim Kingdon <kingdonc@cyclic.com>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
In-Reply-To: <009C8D61.A962AAB3.1@TMESIS.COM> (system@TMESIS.COM)
Subject: Re: DCL on other platforms (was Mailing List postings....)
References: <009C8D61.A962AAB3.1@TMESIS.COM>
> I've spent more time in the bowels of DCL than probably anybody on
> this list. If a DCL language is what you want, I could put one
> together that would sink coffin nails into the not-so-XLNT products.
Well, sounds like you have an opportunity to prove this assertion :-),
since DCL is certainly (part of) what Free-VMS wants. I don't think
any of us _want_ to fight with the arcane build procedure for BOSS,
but if BOSS is the only game in town....
> However, as I've said may times before, DCL is NOT VMS!
True. But we need DCL, and we need the rest of VMS. So getting DCL
would be a step towards our goal.
================================================================================
Archive-Date: Wed, 8 Jul 1998 02:55:24 +0200
Date: Wed, 8 Jul 1998 02:55:18 +0200
Message-ID: <3254-Wed08Jul1998025518+0200-levitte@lp.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
In-Reply-To: <9807071836.AA26560@forte.com> (pvhp@forte.com)
Subject: Re: rm -rf equiv (was Re: Mailing List postings....)
MIME-Version: 1.0
Content-Type: Text/Plain; Charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
From: pvhp@forte.com (Peter Prymmer)
and everything from DEV:[ROOT.SDIR..] on down will be deleted including
DEV:[ROOT]SDIR.DIR;1, but everything else in DEV:[ROOT] will stay.
Ehemmm... let's think real carefully before we do that last thing
(deleting SDIR.DIR). I've a gut feeling that would take it one step too
far.
1) 8 dir depth limit (now gone in the RMS that comes with 7.2?)
I see no problem in removing that restriction.
E.g. the only way that I know how* to redirect the output of SHOW
SYMBOL * is to do a SET HOST 0/LOG beforehand
$ DEFINE/USER SYS$OUTPUT dev:[dir]logfile.LOG
Unfortunately coming up with a new .CLD for everthing that you'd want
to re-direct would entail a great deal of work. Hence having it built
into the shell at the outset would be a good thing I'd think (assuming
folks agree that it is good :-).
Adding " qualifier OUTPUT, default value (type=$infile)" is not very
hard (and can be done automagically). Thinking of it each time you make
a new command definition is less work. Doing the routine that does the
work once and for all is less work, even...
But you're right, people are very used to the Unixly redirections these
days, and I don't really see a problem with adding them, BUT be careful,
because < and > are part of the directory spec. syntax (can be used
instead of [ and ]), and for the sake of internationalization, I suggest
we keep that syntax feature.
--
R Levitte, Levitte Programming; Spannv. 38, I; S-168 35 Bromma; SWEDEN
Tel: +46-8-26 52 47; Cel: +46-708-20 09 64; No fax right now
PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65
Check http://richard.levitte.org/ for my public key. bastard@bofh.se
"price, performance, quality. Choose any two you like"
================================================================================
Archive-Date: Wed, 8 Jul 1998 03:12:40 +0200
Date: Wed, 8 Jul 1998 03:12:24 +0200
Message-ID: <2991-Wed08Jul1998031224+0200-levitte@lp.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
In-Reply-To: <4FD6422BE942D111908D00805F3158DF0415865A@red-msg-52.dns.microsoft.com> (message from Chris Kaler on Tue, 7 Jul 1998 11:53:52 -0700)
Subject: RE: rm -rf equiv (was Re: Mailing List postings....)
MIME-Version: 1.0
Content-Type: Text/Plain; Charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
From: Chris Kaler <ckaler@microsoft.com>
Hi Chris, been a long time :-).
CK> Actually it does do it today, it just has a "bug". DELETE [...]*.*;*
CK> will do a recursive delete, it just tries to delete a directory
CK> before it has deleted the contents. That is a fairly
CK> straightforward thing to fix. However, there are likely DCL
CK> scripts that rely on the behavior... so how do you change in a
CK> compatible way? Do you care?
Hmm, I must say that the only script that I've seen that relies on this
is one that fixes the problem, by spinning around the delete until there
are no more files to delete, including the directories...
If we are going to keep strict compatibility (that is, not breaking
possible scripts, only doing additions), the /TREE qualifier that someone
proposed isn't such a bad idea. Perhaps with another name, like
/RECURSIVE. I must say it feels a little silly, because that qualifier
is redundant, with the only detail that we remain "bug compatible".
I dunno...
In my opinion the two problems with VMS are:
1) 8 dir depth limit (now gone in the RMS that comes with 7.2?)
CK> I doubt if it is *really* fixed. I know they were planning some work
CK> to make it better for backup and PC connectivity, but the problem is
CK> that the RMS data structures have a fixed structure for 8 levels.
Hmm, is it possible that we will encounter problems if we're not "bug
compatible" there as well?
CK> Exactly -- that's why I built the PIPE command. It was a way of
CK> making it work in a backwardly compatible way. :-)
The PIPE command is good. And I understand the backward compatibility
issues that DEC has to go through. However, I'd like to ask you if we
really need to have this a separate command? How about having that as an
inherent part of DCL? How many problems will that give us? The only
programs that I've seen that expect a ">" as one of it's arguments are
Unix programs that have been ported with some extra routines to handle
redirection themselves.
The next question to ask is really how far we want to go? Is redirection
enough or do we want to have all the features of Unix shells in DCL
(including command grouping in subshells with the help of parenthesis)?
In that case, I'd immediately say that we're facing a pretty challenging
design of DCL :-). Perhaps a too challenging one...
I am a little sleepy, so it's possible I don't make much sense...
--
R Levitte, Levitte Programming; Spannv. 38, I; S-168 35 Bromma; SWEDEN
Tel: +46-8-26 52 47; Cel: +46-708-20 09 64; No fax right now
PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65
Check http://richard.levitte.org/ for my public key. bastard@bofh.se
"price, performance, quality. Choose any two you like"
================================================================================
Archive-Date: Wed, 8 Jul 1998 03:42:30 +0200
Date: Wed, 8 Jul 1998 03:41:50 +0200
Message-ID: <6041-Wed08Jul1998034150+0200-levitte@lp.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
In-Reply-To: <1.5.4.32.19980707235605.006f6a40@snake.srv.net> (message from Kevin Handy on Tue, 07 Jul 1998 17:56:05 -0600)
Subject: Re: Re[2]: FreeVMS Project - Future?
MIME-Version: 1.0
Content-Type: Text/Plain; Charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
From: Kevin Handy <kth@srv.net>
If you look at Unix, almost everyone codes in C, so you only need to
know one language to be involved in the fun.
C is more or less part of Unix. They grew very much together, and C has
become an inherent part of Unix.
You don't see any Bliss programs running on Unix, because of the lack
of a standard compiler.
Bliss has been Digital's system programming language for a loooong time,
and has more or less been an inherent part of Digital's OS'es (except for
Unix), just like C is more or less an inherent part of Unix.
There's no need to have a language war here. Let's be practical. I
personaly don't mind if other languages are used (and made available!).
Hell, I can even take routines written in Lisp if it shows up. But for
now, it seems like C is the only really practical language, since there
are compilers for it more or less everywhere.
Someone wants to build a compiler or transpiler? Just go right ahead.
There is, however, one thing I want to be clear: I want all languages to
be interoperable, the same way it is under OpenVMS today. And that,
gentlemen, can be a tricky part, and requires us to talk with each other.
--
R Levitte, Levitte Programming; Spannv. 38, I; S-168 35 Bromma; SWEDEN
Tel: +46-8-26 52 47; Cel: +46-708-20 09 64; No fax right now
PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65
Check http://richard.levitte.org/ for my public key. bastard@bofh.se
"price, performance, quality. Choose any two you like"
================================================================================
Archive-Date: Wed, 8 Jul 1998 04:07:46 +0200
Date: Tue, 7 Jul 98 19:07:27 PDT
From: pvhp@forte.com (Peter Prymmer)
Reply-To: Free-VMS@lp.se
Message-ID: <9807080207.AA09339@forte.com>
To: Free-VMS@lp.se, levitte@lp.se
Subject: Re: rm -rf equiv (was Re: Mailing List postings....)
Richard Levitte wrote in response to me:
> From: pvhp@forte.com (Peter Prymmer)
>
> and everything from DEV:[ROOT.SDIR..] on down will be deleted including
> DEV:[ROOT]SDIR.DIR;1, but everything else in DEV:[ROOT] will stay.
>
> Ehemmm... let's think real carefully before we do that last thing
> (deleting SDIR.DIR). I've a gut feeling that would take it one step too
> far.
Do you mean for the /TREE qualifier to DELETE? Yes by all means. I do not
mind having to do an extra DELETE SDIR.DIR;* if necessary :-)
> 1) 8 dir depth limit (now gone in the RMS that comes with 7.2?)
>
> I see no problem in removing that restriction.
:-)
> E.g. the only way that I know how* to redirect the output of SHOW
> SYMBOL * is to do a SET HOST 0/LOG beforehand
>
> $ DEFINE/USER SYS$OUTPUT dev:[dir]logfile.LOG
Thanks.
> Unfortunately coming up with a new .CLD for everthing that you'd want
> to re-direct would entail a great deal of work. Hence having it built
> into the shell at the outset would be a good thing I'd think (assuming
> folks agree that it is good :-).
>
> Adding " qualifier OUTPUT, default value (type=$infile)" is not very
> hard (and can be done automagically). Thinking of it each time you make
> a new command definition is less work. Doing the routine that does the
> work once and for all is less work, even...
Well you'd need INPUT and to translate '>>' you'd need an APPEND qualifier
as well eh? It sounded like a lot of extra work to me.
> But you're right, people are very used to the Unixly redirections these
> days, and I don't really see a problem with adding them, BUT be careful,
> because < and > are part of the directory spec. syntax (can be used
> instead of [ and ]), and for the sake of internationalization, I suggest
> we keep that syntax feature.
Yes I understand (I've even written scripts that deal with the <DIR> spec
output of INSTALL LIST e.g.). Actually I found myself amazed that those were
the only two real "complaints" I had. I guess I'd say that I've come to peace
with the process heavy environment of VMS provided it gives me the rock solid
reliability that we all love.
Other wild fantasies on my personal wish list: an ability for the shell to
deal with /sys$system/filespecs/that/look/unixy (ala POSIX). And given that
the inspiration for tcsh's filename completion was DEC system 10's you'd think
that tab-to-complete-partial-filespec would have been in DCL but it isn't.
Heh. When I compare my DCL prompt usage to typical unix hackers I wind up
using DECWindows cut and paste a lot more than they do.
All of these are just wishlist items of course. In more serious matters I
have seen it mentioned that there is a preference for building on top of a
Mach kernel. What is(are) the intended target architecture(s)?
Peter Prymmer
================================================================================
Archive-Date: Wed, 8 Jul 1998 04:19:12 +0200
Date: Tue, 7 Jul 98 19:18:33 PDT
From: pvhp@forte.com (Peter Prymmer)
Reply-To: Free-VMS@lp.se
Message-ID: <9807080218.AA09753@forte.com>
To: Free-VMS@lp.se, ckaler@microsoft.com, levitte@lp.se
Subject: RE: rm -rf equiv (was Re: Mailing List postings....)
Richard Levitte wrote:
> The next question to ask is really how far we want to go? Is redirection
> enough or do we want to have all the features of Unix shells in DCL
> (including command grouping in subshells with the help of parenthesis)?
> In that case, I'd immediately say that we're facing a pretty challenging
> design of DCL :-). Perhaps a too challenging one...
Redirection should not even be on the todo list if it will hold things up
any. In this regard Jerrold Leichter had a good point :-)
Anything that can be run and experimented with should prove enjoyable.
Peter Prymmer
================================================================================
Archive-Date: Wed, 8 Jul 1998 04:28:07 +0200
Date: Wed, 8 Jul 1998 04:27:54 +0200
Message-ID: <2662-Wed08Jul1998042754+0200-levitte@lp.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
In-Reply-To: <9807080207.AA09339@forte.com> (pvhp@forte.com)
Subject: Re: rm -rf equiv (was Re: Mailing List postings....)
MIME-Version: 1.0
Content-Type: Text/Plain; Charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
From: pvhp@forte.com (Peter Prymmer)
> Ehemmm... let's think real carefully before we do that last thing
> (deleting SDIR.DIR). I've a gut feeling that would take it one step too
> far.
Do you mean for the /TREE qualifier to DELETE? Yes by all means. I
do not mind having to do an extra DELETE SDIR.DIR;* if necessary :-)
I meant nothing about the /TREE qualifier, I talked about the handling of
recursive directory spec. and how to handle such delete's.
Well you'd need INPUT and to translate '>>' you'd need an APPEND
qualifier as well eh? It sounded like a lot of extra work to me.
Good point, except I don't see much use for the /INPUT qualifier...
Where input is needed, the file is usually given as an argument
already...
Other wild fantasies on my personal wish list: an ability for the
shell to deal with /sys$system/filespecs/that/look/unixy (ala POSIX).
Helloooooo, qualifier ambiguity! :-)
I don't see that happen with DCL...
All of these are just wishlist items of course. In more serious
matters I have seen it mentioned that there is a preference for
building on top of a Mach kernel. What is(are) the intended target
architecture(s)?
No specific architecture is targeted. Whatever is possible to use.
That's one of reasons to choose Mach.
Really time for me to go and sleep... Laundry in less that 4 hours...
'night...
--
R Levitte, Levitte Programming; Spannv. 38, I; S-168 35 Bromma; SWEDEN
Tel: +46-8-26 52 47; Cel: +46-708-20 09 64; No fax right now
PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65
Check http://richard.levitte.org/ for my public key. bastard@bofh.se
"price, performance, quality. Choose any two you like"
================================================================================
Archive-Date: Wed, 8 Jul 1998 06:50:06 +0200
Date: Tue, 7 Jul 1998 20:41:53 -0700 (PDT)
Message-ID: <2.2.16.19980707225613.23576310@earthlink.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Free-VMS@lp.se
From: "David J. Dachtera" <djesys@earthlink.net>
Reply-To: Free-VMS@lp.se
Subject: Re: rm -rf equiv (was Re: Mailing List postings....)
Folks,
Jerry makes a good point.
However, I want to try and point out something may have escaped most of us...
It occurred to me after reading Peter's note about "rm -rf" for the
umpteenth time (isn't quoting wonderful?) that a basic understanding of the
differences between OpenVMS and UN*X will be an essential skill for those
participating in the process.
Chris Kaler noted that he thought the behaviour of "DELETE [...]*.*;*"
displayed on OpenVMS was "a bug", and thought it "a fairly straightforward
thing to fix".
What many may not know is that SYS$SYSTEM:DELETE.EXE, the program which
facilitates the DELETE (and PURGE?) commands is entirely dependent upon the
LIB$FIND_FILE routine and its constituents - the program itself does nothing
to examine the directories on its own.
Those accustomed to UN*X understand that it is the shell's responsibility to
expand wildcarded filespec's and pass them to the program (or shell script)
as a (VERY!) long list of parameters (well beyond the P1 - P8 limits in
DCL). That's why even when the "ls" program is not accessible you can "pwd"
and "echo *" to see what your current working directory is and what files
are there (but nothing about them). If you want to examine a directory tree
in a UN*X program (as in "rm -rf"), you must do it yourself.
In VMS, on the other hand, it is the PROGRAM's (DCL procedure's)
responsibility to be sensitive to and to process wildcarded filespec's
appropriately - by calling LIB$FIND_FILE (or F$SEARCH()) and processing the
data that is returned. DCL is a bit more work, since you must be sensitive
to receiving the same filespec. on two successive passes through a loop
containing F$SEARCH(); if this happens, the filespec. is not wildcarded.
Also, when a null string is returned, that's the end of the list.
LIB$FIND_FILE simply returns a "no more files" status upon reaching the end
of a wildcarded list.
In UN*X, each program has it's own set of "options" (DCL equivalent:
qualifiers), and there is little or no consistency from one program to
another. The shell simply passes these to the program as parameters - the
shell does not process them.
In VMS, on the other hand, the command is pre-processed somewhat so that the
CLI$ routines can be called to retrieve the information about the qualifiers
present and any qualifier values. For each program, it is not necessary to
re-invent the "CLI wheel" - you just call CLI$whatever. Qualifiers tend to
be more consistent since the burden of interpreting the command line is
lifted from the programmer's shoulders, allowing for more flexibility in the
qualifier names.
No, DCL is not VMS, any more than csh is UN*X (POSIX?). The differences,
however, are none the less important to remember.
Even if the available programming languages are limited to GAS, GCC and G++
(God, I sure hope not!), if you want your programs to work on OpenVMS and
FreeVMS without changes, you'd better pay attention to the details!
David J. Dachtera
dba DJE Systems
At 05:23 PM 7/7/98 -0400, Jerrold Leichter wrote:
>This little thread is a wonderful example of one reason - perhaps not the most
>important one, but a significant one - why a FreeVMS project has never gotten
>off the ground.
>
>Whether an 'rm -rf' equivalent is available, whether redirectly a la Unix is
>available - these are trivial points. No DELETE is available! No DCL is
>available! Worrying about whether a new, yet-to-be-designed (much less
>written) implementation will include new, ultimately trivial features (it's no
>big deal to implement tree deletion, and redirection is pretty useless for
>most native VMS utilities, since they don't act as pipelines) is like spending
>our debating about the brand of air freshener to be used in the apartment
>you're going to rent in a skyscraper located in a city that exists so far as
>sketches in some urban planner's notebook!
>
>Once the basic stuff is written and working, anyone can hack to his heart's
>content to add nifty features and extensions. Without the basic stuff, why
>waste everyone's time?
> -- Jerry
>
>
>
>
================================================================================
Archive-Date: Wed, 8 Jul 1998 09:53:40 +0200
Message-ID: <003f01bdaa45$b3a45a80$fbfe21c0@theo.progis.de>
Reply-To: Free-VMS@lp.se
From: "Klaus Kaempf" <kkaempf@rmi.de>
To: <Free-VMS@lp.se>
Subject: Re: Re[2]: FreeVMS Project - Future?
Date: Wed, 8 Jul 1998 09:54:19 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
>There's no need to have a language war here. Let's be practical. I
>personaly don't mind if other languages are used (and made available!).
That's the problem. If we're building a 'free' VMS, it must be portable across
platforms and there must be *supported* compilers available which *guarantee*
equal program behaviour (i.e. free of fundamental bugs).
This is a huge task and I only see gnu c (read: egcs) as the only practical
programming environment.
>Someone wants to build a compiler or transpiler? Just go right ahead.
Right. Either construct a 'Bliss -> C' converter or a bliss frontend for gcc.
There already is c, c++, Fortran, and Pascal and the egcs developers are open to
extensions.
>
>There is, however, one thing I want to be clear: I want all languages to
>be interoperable, the same way it is under OpenVMS today. And that,
>gentlemen, can be a tricky part, and requires us to talk with each other.
This is *very* tricky. The OpenVMS calling standard just talks about how and
where arguments are passed between functions on an assembly language level. This
part shouldn't be too hard to define. However, it must be done on a 'per
processor' basis. The harder part is to argue about function argument types and
how close we resemble VMS. Most structural types in VMS are based on VAX
assembly and are byte aligned which gives a huge performance penalty on RISC
platforms (like the Alpha). OpenVMS 7.x with the 64bit API tries to correct
this, but makes such programs not easily portable to older vms versions.
Klaus
---
Klaus Kaempf kkaempf@rmi.de
Jakobstr. 181
D-52064 Aachen Yes, my email account changed.
================================================================================
Archive-Date: Wed, 8 Jul 1998 10:16:09 +0200
Sender: christof.zeile@ins.uni-stuttgart.de
Message-ID: <35A32ABC.1B87@ins.uni-stuttgart.de>
Date: Wed, 08 Jul 1998 10:15:56 +0200
From: Christof Zeile <christof.zeile@ins.uni-stuttgart.de>
Reply-To: Free-VMS@lp.se
MIME-Version: 1.0
To: Free-VMS@lp.se
Subject: Languages and Calling Standard
References: <1.5.4.32.19980707235605.006f6a40@snake.srv.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Kevin Handy wrote:
>
>
> I'd prefer everything to be coded using a small set of
> languages. Preferibally just C/C++. This would make it
> easier for others to work on the code. If you look at Unix,
> almost everyone codes in C, so you only need to know one
> language to be involved in the fun.
>
> We would want to be able to give users other languages, but I'd
> still prefer to use something that has been standardized for
> several platforms, so the code may be ported to other enviornments
> easily. You don't see any Bliss programs running on Unix,
> because of the lack of a standard compiler.
I agree, but I perhaps we should think about using C++
instead of C, at least for some security-relevant
parts of the code. Buffer overruns are very often the
reason for security holes in Unix utilities.
Perhaps in C++ one could define objects with some
kind of bounds checking etc. Or a "real" string type.
Now there is another problem, and I don't know if I understand
it quite right, perhaps somebody can help:
In 1996, Klaus Kaempf wrote in a contribution to this list:
> All Free-VMS needs is a 'calling standard' which defines how functions
> are called on a machine language level. The current openVMS/Alpha
> calling standard defines an 'argument information' register where
> the calling function puts the number of *actual* arguments. The called
> function in turn checks this value against the number of *expected*
> arguments and adds default values appropriately.
Now if the libraries to be developped for FreeVMS should be made
portable,
a problem arises (and please tell me if what I describe below could
really happen):
Think of a procedure LIB$XYZ(arg1,arg2) that takes two arguments. One
day there is a new version of VMS, and now LIB$XYZ(arg1,arg2,arg3)
takes three arguments. No problem with the calling standard of VMS:
If an old program calls LIB$XYZ with two arguments and is relinked
against the new version, LIB$XYZ will
notice that one argument is missing and add a default value.
Now if somebody develops under Linux or whatever and the compiler
does not know anything about passing the number of arguments, he
cannot just extend the argument list. If he does, the old software
will not work with the new library.
Even worse: What about software written for VMS that relies on the
VMS calling standard? In the past, VMS programmers could just omit
the trailing arguments. And FreeVMS is intended to be compatible,
isn't it?
Klaus Kaempf wrote:
> Implementing this calling standard is the job of the gnu c backend
> which must be changed for the target system anyhow.
So is this one of the first things to do?
Well, perhaps I got something wrong. Would anybody like to
comment? I am really interested in understanding the whole
thing better.
Christof
================================================================================
Archive-Date: Wed, 8 Jul 1998 10:36:30 +0200
Message-ID: <01e201bdaa4b$b136ce30$fbfe21c0@theo.progis.de>
Reply-To: Free-VMS@lp.se
From: "Klaus Kaempf" <kkaempf@rmi.de>
To: <Free-VMS@lp.se>
Subject: Re: PC-VMS
Date: Wed, 8 Jul 1998 10:37:15 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
>A long time ago I promised to dig this up and make it available.
>I've got the book but came up empty on the disks. I'm still digging through
>5 1/4 floppy piles without luck. If I find it I'll be glad to donate them
>to the FreeVMS effort in some way.
Having the code is not the problem, having the copyright (or the allowance to
post it) is the problem !
Klaus
================================================================================
Archive-Date: Wed, 8 Jul 1998 12:02:04 +0200
Date: Wed, 8 Jul 1998 12:01:57 +0200
Message-ID: <2077-Wed08Jul1998120157+0200-levitte@lp.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
In-Reply-To: <35A32ABC.1B87@ins.uni-stuttgart.de> (message from Christof Zeile on Wed, 08 Jul 1998 10:15:56 +0200)
Subject: Re: Languages and Calling Standard
MIME-Version: 1.0
Content-Type: Text/Plain; Charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
From: Christof Zeile <christof.zeile@ins.uni-stuttgart.de>
I agree, but I perhaps we should think about using C++ instead of C,
at least for some security-relevant parts of the code. Buffer overruns
are very often the reason for security holes in Unix utilities.
If you want to write in C++, that's fine with me. Beware, however, of
name mangling.
About the security argument... I have to disagree, it's not a more
"secure" language than C. Not in itself. Actually, the comparison you
made is like saying that you take better pictures if you have a more
expensive camera...
Something that helps keeping away from buffer overflows is the way you do
library and system routine calls. You specify sizes everywhere.
(note that I said "helps". It's perfectly possible (and it has been
done) to shoot yourself in the foot with buffer overflows on VMS as well.
But for some reason, it doesn't happen very often at all (and it's
usually an inheritance from a Unix program port).
Now if the libraries to be developped for FreeVMS should be made
portable, a problem arises (and please tell me if what I describe
below could really happen):
Hmm... I'm tempted to use the same line of thinking as RMS did about the
GNU project: The final goal is to have a Free VMS, with a working kernel,
compilers, yada, yada, yada. The absolute compatibility will be in that
environment. If other architectures/OS combinations do not have things
like a call argument counter (and I've seen 0 who actually don't), that's
too bad. If it's solvable in some way (a low-level hack or some macro
magic), it's a pity, but it will be a flaw in *that* architecture/OS
combination. There will be times when we'll have to shrug and say "what
the hell can I do about that?"
Actually, come to think of it, there's one pretty ugly way to fix that...
C++ and default arguments... But I don't recommend it, because it
depends a lot on declarations, not definitions... ANd will break other
languages, if and when they are brought in.
--
R Levitte, Levitte Programming; Spannv. 38, I; S-168 35 Bromma; SWEDEN
Tel: +46-8-26 52 47; Cel: +46-708-20 09 64; No fax right now
PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65
Check http://richard.levitte.org/ for my public key. bastard@bofh.se
"price, performance, quality. Choose any two you like"
================================================================================
Archive-Date: Wed, 8 Jul 1998 12:46:22 +0200
Message-ID: <025601bdaa5d$d7dc9580$fbfe21c0@theo.progis.de>
Reply-To: Free-VMS@lp.se
From: "Klaus Kaempf" <kkaempf@rmi.de>
To: <Free-VMS@lp.se>
Subject: Re: Languages and Calling Standard
Date: Wed, 8 Jul 1998 12:47:09 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Christof Zeile wrote:
>Kevin Handy wrote:
>>
>>
>> I'd prefer everything to be coded using a small set of
>> languages. Preferibally just C/C++. This would make it
[...]
>
>I agree, but I perhaps we should think about using C++
>instead of C, at least for some security-relevant
>parts of the code. Buffer overruns are very often the
>reason for security holes in Unix utilities.
>Perhaps in C++ one could define objects with some
>kind of bounds checking etc. Or a "real" string type.
Oh no, please don't try C++. There are *too* much portability (and sometimes
performance) problems.
Buffer overruns are a programmers problem, not a programming language problem.
Depending on the language to catch such errors leads to bad coding style. Since
we're building a VMS system, use descriptors for buffers and other array objects
and *check* values before using them.
>
>
>In 1996, Klaus Kaempf wrote in a contribution to this list:
>
>> All Free-VMS needs is a 'calling standard' which defines how functions
>> are called on a machine language level. The current openVMS/Alpha
>> calling standard defines an 'argument information' register where
>> the calling function puts the number of *actual* arguments. The called
>> function in turn checks this value against the number of *expected*
>> arguments and adds default values appropriately.
This 'feature' is used in about every vms fortran program i've seen !
>
>Now if the libraries to be developped for FreeVMS should be made portable,
>a problem arises (and please tell me if what I describe below couldreally
happen):
>
>Think of a procedure LIB$XYZ(arg1,arg2) that takes two arguments. One
>day there is a new version of VMS, and now LIB$XYZ(arg1,arg2,arg3)
>takes three arguments. No problem with the calling standard of VMS:
>If an old program calls LIB$XYZ with two arguments and is relinked
>against the new version, LIB$XYZ will notice that one argument is missing and
add a default value.
Yes. This happens if you change a library without the prototype feature of
recent C compilers. If you do such a change, you *have to* change the procedure
name also !! If you expect the procedure to be extended in later versions, use
variable argument lists (LIB$XYZ(arg1,arg2,...) in C) in the first place and
pass information about the third argument in arg1 or arg2. Some stdarg/vararg
implementations can determine the number of actual arguments at run-time, but
this isn't portable !
This, of course, won't work with the typical fortran usage of, for example, SMG$
routines. Some of them have 'zillions' of arguments but you just have to give
some. The others are filled with zero values *by the compiler*. So this isn't
part to the calling standard (being on machine code level) but must be
implemented in the compiler front end.
>
>Now if somebody develops under Linux or whatever and the compiler
>does not know anything about passing the number of arguments, he
>cannot just extend the argument list. If he does, the old software
>will not work with the new library.
Sure. This is why shared libraries on unix (linux) have a major and minor
version number. The minor number changes on bug fixes and you get a warning if
it doesn't match. The major number changes on functional changes like argument
types/argument counts and the (dynamic) linker refuses start the program if the
major numbers don't match.
>
>Even worse: What about software written for VMS that relies on the
>VMS calling standard? In the past, VMS programmers could just omit
>the trailing arguments. And FreeVMS is intended to be compatible,
>isn't it?
Yes. FreeVMS should be compatible but should not support lazy programmers !! If
we're defining a calling standard, we might use an argument information register
like OpenVMS does. This would help with trailing arguments but giving away a
full register isn't feasible on most CPUs.
>
>Klaus Kaempf wrote:
>
>> Implementing this calling standard is the job of the gnu c backend
>> which must be changed for the target system anyhow.
>
>So is this one of the first things to do?
No, I don't think so. We should start with DCL and a portable programming
environment for implementing commands. This will be based on the target system
(vms, linux, unix, windows, whatever...) and only relies on the used language
(C, C++, Bliss, Macro, ...) and the defined interfaces.
Defining a calling standard is part of the operating system and the linker. And
we won't have either anytime soon.
Klaus
---
Klaus Kaempf kkaempf@rmi.de
Jakobstr. 181
D-52064 Aachen Yes, my email account changed.
================================================================================
Archive-Date: Wed, 8 Jul 1998 13:04:01 +0200
Date: Wed, 8 Jul 1998 13:03:52 +0200
Message-ID: <8614-Wed08Jul1998130352+0200-levitte@lp.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
In-Reply-To: <025601bdaa5d$d7dc9580$fbfe21c0@theo.progis.de> (kkaempf@rmi.de)
Subject: Re: Languages and Calling Standard
MIME-Version: 1.0
Content-Type: Text/Plain; Charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
From: "Klaus Kaempf" <kkaempf@rmi.de>
Sure. This is why shared libraries on unix (linux) have a major and
minor version number.
VMS too :-)
Yes. FreeVMS should be compatible but should not support lazy
programmers !! If we're defining a calling standard, we might use an
argument information register like OpenVMS does. This would help with
trailing arguments but giving away a full register isn't feasible on
most CPUs.
Make it part of the stack frame in such cases. Obviously, this will be
architecture-dependent...
Defining a calling standard is part of the operating system and the
linker.
Don't forget the compiler ;-).
--
R Levitte, Levitte Programming; Spannv. 38, I; S-168 35 Bromma; SWEDEN
Tel: +46-8-26 52 47; Cel: +46-708-20 09 64; No fax right now
PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65
Check http://richard.levitte.org/ for my public key. bastard@bofh.se
"price, performance, quality. Choose any two you like"
================================================================================
Archive-Date: Wed, 8 Jul 1998 13:55:14 +0200
Message-ID: <02b901bdaa67$777d3690$fbfe21c0@theo.progis.de>
Reply-To: Free-VMS@lp.se
From: "Klaus Kaempf" <kkaempf@rmi.de>
To: <Free-VMS@lp.se>
Subject: Re: Languages and Calling Standard
Date: Wed, 8 Jul 1998 13:56:07 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
>Make it part of the stack frame in such cases. Obviously, this will be
>architecture-dependent...
I still doubt that an argument count is really necessary. It moves the
(desirable) strong typing from the high-level language to the run-time
enviroment. I've yet to see a vms function that can't be implemented without it.
>
> Defining a calling standard is part of the operating system and the
> linker.
>
>Don't forget the compiler ;-).
Hmm. I think the compiler should *implement* the calling standard, not *define*
it :-)
================================================================================
Archive-Date: Wed, 8 Jul 1998 14:02:31 +0200
Date: Wed, 8 Jul 1998 14:02:26 +0200
Message-ID: <9326-Wed08Jul1998140226+0200-levitte@lp.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
In-Reply-To: <02b901bdaa67$777d3690$fbfe21c0@theo.progis.de> (kkaempf@rmi.de)
Subject: Re: Languages and Calling Standard
MIME-Version: 1.0
Content-Type: Text/Plain; Charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
From: "Klaus Kaempf" <kkaempf@rmi.de>
>Make it part of the stack frame in such cases. Obviously, this will be
>architecture-dependent...
I still doubt that an argument count is really necessary. It moves the
(desirable) strong typing from the high-level language to the run-time
enviroment. I've yet to see a vms function that can't be implemented
without it.
Sorry, you lose. I'd like to see your compiler check the descriptors...
> Defining a calling standard is part of the operating system and the
> linker.
>
>Don't forget the compiler ;-).
Hmm. I think the compiler should *implement* the calling standard, not
*define* it :-)
OK, I missed that first word, but in that case, I'd say the linker
implements the calling standard as well instead of defining it.
Let's drop this particular thread, it's becoming silly :-).
--
R Levitte, Levitte Programming; Spannv. 38, I; S-168 35 Bromma; SWEDEN
Tel: +46-8-26 52 47; Cel: +46-708-20 09 64; No fax right now
PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65
Check http://richard.levitte.org/ for my public key. bastard@bofh.se
"price, performance, quality. Choose any two you like"
================================================================================
Archive-Date: Wed, 8 Jul 1998 15:17:12 +0200
Message-ID: <02f601bdaa72$91aab780$fbfe21c0@theo.progis.de>
Reply-To: Free-VMS@lp.se
From: "Klaus Kaempf" <kkaempf@rmi.de>
To: <Free-VMS@lp.se>
Subject: Re: Languages and Calling Standard
Date: Wed, 8 Jul 1998 15:15:27 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
>> I still doubt that an argument count is really necessary. It moves the
>> (desirable) strong typing from the high-level language to the run-time
>> enviroment. I've yet to see a vms function that can't be implemented
>> without it.
>
>Sorry, you lose. I'd like to see your compiler check the descriptors...
>
??? This I don't quite understand. The argument count I'm refering to is a
special register telling a (machine code) function how (and how many) values are
passed. Descriptors (in the vms sense) are data structures describing the type
of a value.
---
Klaus Kaempf kkaempf@rmi.de
Jakobstr. 181
D-52064 Aachen Yes, my email account changed.
================================================================================
Archive-Date: Wed, 8 Jul 1998 15:48:08 +0200
Date: Wed,