This is G o o g l e's cache of http://www.lp.se/ftp/mailinglists/FREE-VMS.1996-10.
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: Mon, 07 Oct 1996 08:24:35 +0200
Sender: owner-free-vms@lp.se
Message-ID: <3258A116.6296@ins.uni-stuttgart.de>
Date: Mon, 07 Oct 1996 08:20:06 +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: What has happened to the list?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I haven't received any mail form the Free-VMS list
since 01-OCT-1996. I can't believe there is really
no activity on the list. Anyway, I'm still subscribed
to the list, as I have already checked.
What has gone wrong?
Christof
================================================================================
Archive-Date: Mon, 07 Oct 1996 21:40:46 +0200
Sender: owner-free-vms@lp.se
Date: Mon, 7 Oct 1996 15:43:42 -0400
Message-ID: <199610071943.PAA17165@harvey.cyclic.com>
From: Jim Kingdon <kingdonc@harvey.cyclic.com>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: What has happened to the list?
BCC:
> I haven't received any mail form the Free-VMS list since
> 01-OCT-1996. I can't believe there is really no activity on the list.
Believe it (at least, *I* haven't received anything either).
Remember folks, Free-VMS is a *volunteer* project. That means we all
need to chip in to make it happen. I'd like to thank Richard Levitte
for everything he has done, but if we wait for him (or any other one
person) to act before we do anything, we'll never get anywhere.
As for what I have done, I have been working on BACKUP. Enclosed is a
description of what I have done. I would very much like to upload
this work-in-progress to some FTP site so that other people can help
test and/or develop it. If anyone wants to provide such a site
(either "official" or "temporary") I would love to upload it. Unless
I start getting more feedback/help/encouragement, my motivation level
is likely to be low.
------------------------------
* The output from listings now more closely approximates the output of
VMS BACKUP/LIST.
* There is now a version which runs on VMS and accepts (a few) of the
qualifiers of BACKUP. It is still very rudimentary.
* Can read savesets on disk (created with the /SAVE_SET qualifier) as
well as on tape.
* More portable (in particular, no longer depends on things like
#ifdef sun to determined byte-order, and no longer depends on the
size of host data types like short and long).
* For older news items (that is, for changes which were in "v07i099:
Read VMS backup tapes" (read-vms-backs) from comp.sources.unix
archive, see the bottom of the ChangeLog file.
================================================================================
Archive-Date: Mon, 07 Oct 1996 22:55:36 +0200
Sender: owner-free-vms@lp.se
Date: Mon, 7 Oct 1996 22:38:26 +0200
Message-ID: <96100722382634@a400.sternwarte.uni-erlangen.de>
From: ai26@a400.sternwarte.uni-erlangen.de (Michael Lemke, Sternwarte Bamberg, Phone: +49-951-9522216)
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: What has happened to the list?
In a message of Mon, 7 Oct 1996 15:43:42 -0400, received on 7 Oct 1996, 22:17
Jim Kingdon <kingdonc@harvey.cyclic.com> wrote
to: Mailing list for the Free-VMS development team <Free-VMS@lp.se>
>
>* There is now a version which runs on VMS and accepts (a few) of the
>qualifiers of BACKUP. It is still very rudimentary.
>
Just an unpleasant remark from someone who is unlikely to contribute
anything useful (I have absoluely no clue how to go about writing an OS
let alone something complex as VMS): Does it make sense to start writing
something like the above before we have CLI$* routines? The above
BACKUP will have to do its own command parsing and once you start that
you've got Unix. Sorry, I don't mean to discourage anyone but maybe
some low level stuff is required first. But as I said, I have no idea
about this task.
Michael
--
Michael Lemke
Sternwarte Bamberg, University of Erlangen-Nürnberg, Germany
(michael@astro.as.utexas.edu or ai26@a400.sternwarte.uni-erlangen.de)
================================================================================
Archive-Date: Mon, 07 Oct 1996 23:12:47 +0200
Sender: owner-free-vms@lp.se
Date: Mon, 7 Oct 1996 17:12:37 -0400 (EDT)
From: Bob Koehler <KOEHLER@bessta.gsfc.nasa.gov>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Message-ID: <961007171237.2541@bessta.gsfc.nasa.gov>
Subject: Re: What has happened to the list?
ai26@a400.sternwarte.uni-erlangen.de (Michael Lemke, Sternwarte
Bamberg, Phone: +49-951-9522216) wrote:
>
>In a message of Mon, 7 Oct 1996 15:43:42 -0400, received on 7 Oct 1996, 22:17
>Jim Kingdon <kingdonc@harvey.cyclic.com> wrote
>to: Mailing list for the Free-VMS development team <Free-VMS@lp.se>
>
>>
>>* There is now a version which runs on VMS and accepts (a few) of the
>>qualifiers of BACKUP. It is still very rudimentary.
>>
>
>Just an unpleasant remark from someone who is unlikely to contribute
>anything useful (I have absoluely no clue how to go about writing an OS
>let alone something complex as VMS): Does it make sense to start writing
>something like the above before we have CLI$* routines? The above
>BACKUP will have to do its own command parsing and once you start that
>you've got Unix. Sorry, I don't mean to discourage anyone but maybe
>some low level stuff is required first. But as I said, I have no idea
>about this task.
>
I agree that it would be nice to have the lowest stuff first, but I certainly
wouldn't discourage anyone who wants to work on the "workings" of a utility
and do their own DCL parsing in the meantime. In the case of BACKUP, there's
a lot of listing, RMS, ODS, and tape handling stuff that's pretty independent
ofthe command line after it's been parsed.
================================================================================
Archive-Date: Tue, 08 Oct 1996 00:52:12 +0200
Sender: owner-free-vms@lp.se
Date: Tue, 8 Oct 1996 00:52:06 MET DST
Message-ID: <12889.42422.405647v0.1b7.LEVITTE@devil.bofh.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: What has happened to the list?
ai26@a400.sternwarte.uni-erlangen.de (Michael Lemke, Sternwarte
Bamberg, Phone: +49-951-9522216) wrote:
>let alone something complex as VMS): Does it make sense to start writing
>something like the above before we have CLI$* routines? The above
In the long run, no. And someone will most likely write those routines,
sooner or later (I hope for the sooner alternative. Given time, I might
very well jump on the task myself).
In the meantime, there will probably be a few packages that will do their
own command line parsing. This is not necessarelly a bad thing in itself,
since they will (by necessity) have some code that could be usefull to
build the CLI$ routines.
It would of course be very nice to do things "in the right order", which
is probably bottom-up (well, not really. middle-up and middle-down, if
you choose to call the libraries "middle"), but to do things like that,
a much tighter organization would probably be required. Another alternative
would of course have been for me to have already finished the kernel and
the libraries, but hey!, I just started this thing...
So, this -- er -- organization being quite loose, we will have to accept
things to come somewhat in disorder in the beginning. What counts, however,
is to create order from chaos, and to keep on building from there.
On the FTP front, I haven't heard much from decus.ch, that made an offer
some time ago. Anyone? Actually, what I'd like to have available is a
system on which accounts could be created pretty swiftly for anyone who
wants to build something for Free-VMS. I wouldn't expect this to be
possible on anything but a completelly standalone system. This for
several reasons, like security (yeah, there are paranoid system managers,
ay know :-)), politics (I am member in several computer clubs, but they
all require membership for all users, and have some restrictions on who
can become a member), economics (right, how should resources, like disk
and so on, be funded?).
I could at any time set up a VAXstation 4000 with some brand of VMS, or
a PC with Hurd. The problem is disk space. I currently don't have any
spare disk, and not the money to buy one. I'm asking around if anyone
wants to give one or two away (for a good cause, see?), but so far I got
siltz. Oh well...
Of course, if anyone *does* set up a machine on which free accounts can
be created, I guess we'll just be very happy, right? We just have to
set up some kind of account creation policy, and assign responsability
to a few people (this will depend very much on the donor).
Just my thoughts for the day (oh well, night...).
--
R Levitte, Levitte Programming; Spannvägen 38, I; S-161 43 Bromma; SWEDEN
Tel: +46-8-26 52 47; 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://www.lp.se/~levitte for my public key. bastard@bofh.se
================================================================================
Archive-Date: Tue, 08 Oct 1996 01:01:31 +0200
Sender: owner-free-vms@lp.se
Date: Tue, 8 Oct 1996 01:01:23 MET DST
Message-ID: <12889.42979.405647v0.1b7.LEVITTE@devil.bofh.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: What has happened to the list?
From: ai26@a400.sternwarte.uni-erlangen.de (Michael Lemke, Sternwarte
Bamberg, Phone: +49-951-9522216)
BACKUP will have to do its own command parsing and once you start that
you've got Unix. Sorry, I don't mean to discourage anyone but maybe
Hmm, I don't think Unix has anything to do with this. In most Unix of
today, you have getopt(), which does practically the same thing as the
CLI$ routines.
The big difference between VMS and Unix is the consistent naming that
have been given to the qualifiers (and that, gentlemen, has *nothing*
to do with the availability of the CLI$ routines), as well as the greater
flexibility of VMS qualifiers compared to Unix switches, like:
- positional qualifiers
- syntax and parameter checks
- parameter prompting when they are missing (really a DCL feature)
- abreviability
There are certainly other features I forget for the moment being.
So please, when you blame Unix, make sure you blame it correctly.
--
R Levitte, Levitte Programming; Spannvägen 38, I; S-161 43 Bromma; SWEDEN
Tel: +46-8-26 52 47; 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://www.lp.se/~levitte for my public key. bastard@bofh.se
================================================================================
Archive-Date: Tue, 08 Oct 1996 14:54:27 +0200
Sender: owner-free-vms@lp.se
Date: Tue, 8 Oct 1996 08:58:07 -0400
Message-ID: <199610081258.IAA22665@harvey.cyclic.com>
From: Jim Kingdon <kingdonc@harvey.cyclic.com>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: What has happened to the list?
> Does it make sense to start writing something like the above before we
> have CLI$* routines?
My BACKUP program-in-progress just calls the usual CLI$* routines.
Since Free-VMS will implement them in a way that is compatible with
VMS, this isn't a problem. I don't try to reimplement that
functionality.
(There is also a variant which works on unix with a different makefile
and an entirely different option syntax, but that isn't directly
relevant to free-vms as such).
> Just an unpleasant remark from someone who is unlikely to contribute
> anything useful (I have absoluely no clue how to go about writing an OS
> let alone something complex as VMS)
Are you sure you have nothing to contribute? For one thing, we will
need testers (for now, just testing individual programs like BACKUP,
running on an existing operating system (probably VMS); it will be a
while before we have a complete system for people to test). And even
in terms of coding, the user programs like BACKUP and COPY and so on
involve no particular wizardry; they just use the regular
system-provided routines like SYS$*, CLI$*, LIB$*, etc.
There are also ways to contribute which are essentially non-technical,
like working on the task list, providing an FTP site, buying a disk
for Levitte so he can set up that machine he was talking about, and
<use your imagination here. Look at the web site and figure out what
you can do, that free-VMS needs. Or ask, if you've read the web site
and still don't understand what free-VMS needs>.
================================================================================
Archive-Date: Tue, 08 Oct 1996 15:04:50 +0200
Sender: owner-free-vms@lp.se
Message-ID: <325A47ED.7937@ins.uni-stuttgart.de>
Date: Tue, 08 Oct 1996 14:24:13 +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: FTP Server
References: <199610071943.PAA17165@harvey.cyclic.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Jim Kingdon wrote:
> ...
> As for what I have done, I have been working on BACKUP. Enclosed is a
> description of what I have done. I would very much like to upload
> this work-in-progress to some FTP site so that other people can help
> test and/or develop it. If anyone wants to provide such a site
> (either "official" or "temporary") I would love to upload it. Unless
> I start getting more feedback/help/encouragement, my motivation level
> is likely to be low.
> =
Perhaps the mail of Kurt Schumacher is of some interest to you:
> Subject: FTP site for Free-VMS - Offer
> Date: Fri, 20 Sep 1996 12:09:36 MET_DST
> From: Kurt Schumacher - KS E & C <Kurt.Schumacher@decus.ch>
> To: FREE-VMS@LP.SE
> ...
> With the upgrade of the DECUS Switzerland machine to a AXP 1000A we mov=
e
> this system to EUnet Switzerland with direct EUnet Internet backbone
> access. So we dont have an own leased-line bottleneck anymore...
> =
> This will allow us to host an FTP server for the Free-VMS project!
>
> Let us know if there is an interest...
> =
> regards
> Kurt A. Schumacher
> +----------------------------------------------------------------------=
--+
> | Kurt Schumacher E-Mail: Kurt.Schumacher@decus.ch =
|
> | PSI-Mail: PSI%022847911312::K_SCHUMACHE=
R |
> | Riedhofstrasse 303 Voice: +41 1 342 42 54 =
|
> | CH-8049 Z=CFrich FAX: +41 1 342 42 54 =
|
> +----------------------------------------------------------------------=
--+
================================================================================
Archive-Date: Tue, 08 Oct 1996 16:22:44 +0200
Sender: owner-free-vms@lp.se
Date: Tue, 8 Oct 1996 10:26:26 -0400
Message-ID: <199610081426.KAA23074@harvey.cyclic.com>
From: Jim Kingdon <kingdonc@harvey.cyclic.com>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: FTP Server
> Perhaps the mail of Kurt Schumacher [from DECUS.CH] is of some
> interest to you:
It is; as far as I know DECUS.CH would be a very fine place to host an
FTP site.
However, I tried writing Kurt Schumacher regarding getting this set up
and have not (yet) received a response. So if anyone has an FTP site
that they want to provide "temporarily" until DECUS.CH gets theirs set
up, that would be welcome. I can probably do this for my BACKUP
program-in-progress (only) if I have to, but I'd rather spread out the
work if there is anyone else who can help with this.
================================================================================
Archive-Date: Tue, 08 Oct 1996 17:15:42 +0200
Sender: owner-free-vms@lp.se
Date: Tue, 08 Oct 1996 10:15:38 CST
From: Hunter Goatley <goathunter@MadGoat.COM>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Message-ID: <009A988A.1DA3DE1B.3@ALPHA.WKU.EDU>
Subject: Re: FTP Server
Jim Kingdon <kingdonc@harvey.cyclic.com> writes:
>
>However, I tried writing Kurt Schumacher regarding getting this set up
>and have not (yet) received a response. So if anyone has an FTP site
>that they want to provide "temporarily" until DECUS.CH gets theirs set
>up, that would be welcome. I can probably do this for my BACKUP
>program-in-progress (only) if I have to, but I'd rather spread out the
>work if there is anyone else who can help with this.
OK, I've set up a directory on FTP.WKU.EDU in [.VMS.FREE-VMS].
If you have files you want to put there, FTP them to ALPHA.WKU.EDU
(ANONYMOUS has PUT access there) in the [.FREE-VMS] directory, then
send mail directly to me to tell me it's there. I'll then move it to
the FTP.WKU.EDU directory.
Sound OK?
Hunter
------
Hunter Goatley, Process Software Corporation (TCPware)
<goathunter@MadGoat.com> http://www.wku.edu/www/madgoat/hunter.html
================================================================================
Archive-Date: Tue, 08 Oct 1996 17:18:21 +0200
Sender: owner-free-vms@lp.se
Date: Tue, 8 Oct 1996 17:06:31 +0200
Message-ID: <96100817063110@a400.sternwarte.uni-erlangen.de>
From: ai26@a400.sternwarte.uni-erlangen.de (Michael Lemke, Sternwarte Bamberg, Phone: +49-951-9522216)
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: What has happened to the list?
In a message of Tue, 8 Oct 1996 08:58:07 -0400, received on 8 Oct 1996, 16:17
Jim Kingdon <kingdonc@harvey.cyclic.com> wrote
to: Mailing list for the Free-VMS development team <Free-VMS@lp.se>
>> Does it make sense to start writing something like the above before we
>> have CLI$* routines?
>
>My BACKUP program-in-progress just calls the usual CLI$* routines.
>Since Free-VMS will implement them in a way that is compatible with
>VMS, this isn't a problem. I don't try to reimplement that
>functionality.
That's excellent. I got the impression this will be some kind of
standalone program that runs without VMS.
>
>Are you sure you have nothing to contribute? For one thing, we will
>need testers (for now, just testing individual programs like BACKUP,
>running on an existing operating system (probably VMS); it will be a
>while before we have a complete system for people to test). And even
>in terms of coding, the user programs like BACKUP and COPY and so on
>involve no particular wizardry; they just use the regular
>system-provided routines like SYS$*, CLI$*, LIB$*, etc.
Ok, testing is certainly something I can do, time permitting. Or add
some more or less useful remarks. But for the actual stuff... I'd like
to be able to but I've got another job to do.
Michael
--
Michael Lemke
Sternwarte Bamberg, University of Erlangen-Nürnberg, Germany
(michael@astro.as.utexas.edu or ai26@a400.sternwarte.uni-erlangen.de)
================================================================================
Archive-Date: Tue, 08 Oct 1996 17:21:57 +0200
Sender: owner-free-vms@lp.se
Date: Tue, 08 Oct 1996 11:20:26 -0500 (EST)
From: "Andrew C. Stoffel (914) 574-4784" <acs@campus.com>
Reply-To: Free-VMS@lp.se
Subject: Re: What has happened to the list?
To: Free-VMS@lp.se
Message-ID: <Pine.PMDF.3.91.961008095429.12367E-100000@RCCLNK.SUNYROCKLAND.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
-----BEGIN PGP SIGNED MESSAGE-----
On Mon, 7 Oct 1996, Jim Kingdon wrote:
> As for what I have done, I have been working on BACKUP. Enclosed is a
> description of what I have done. I would very much like to upload
> this work-in-progress to some FTP site so that other people can help
> test and/or develop it. If anyone wants to provide such a site
> (either "official" or "temporary") I would love to upload it. Unless
> I start getting more feedback/help/encouragement, my motivation level
> is likely to be low.
If anything floats by that I can copy locally (to me) I'll put it up
on my machine @
http://acs.sunyrockland.edu/freevms/
caveat: It's an NT machine sitting @ my desk....
- ------------------------------------------------------------------------
Andy Stoffel Project Consultant voice: (914) 574-4784
acs@campus.com http://acs.sunyrockland.edu/ fax: (914) 574-4354
Campus Consultants Group, Inc. A Campus America Company
[******* PGP public key: http://acs.sunyrockland.edu/pubkey.txt *******]
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQB1AwUBMlolrJ3f66UHPSGFAQELFgL5AV9nHzb0K22MHvza5U6xiihCulI6eY+m
pDmKi2RL4H5cULUzxavZMAGNU7iev6QsJheW/Kcme2abshF6K2ihjTEgDL3FUCj5
gp9r+SFB6thn1zHXRE7yDMW09WY0JLY2
=/Qsd
-----END PGP SIGNATURE-----
================================================================================
Archive-Date: Tue, 08 Oct 1996 19:38:50 +0200
Sender: owner-free-vms@lp.se
Date: Tue, 8 Oct 1996 13:38:40 -0400
From: JayPed@aol.com
Reply-To: Free-VMS@lp.se
Message-ID: <961008133840_205118399@emout14.mail.aol.com>
To: Free-VMS@lp.se
Subject: Re: What has happened to the list?
In a message dated 96-10-07 15:58:22 EDT, you write:
<< Remember folks, Free-VMS is a *volunteer* project. That means we all
need to chip in to make it happen. I'd like to thank Richard Levitte
for everything he has done, but if we wait for him (or any other one
person) to act before we do anything, we'll never get anywhere. >>
I would be willing to work on the CLI$ routines, including a "SET
COMMAND/OBJECT" utility to parse a .CLD file and create an .OBJ file.
This could be used as a first phase, and would be compatible with VMS
applications which use 'SET COMMAND/OBJECT" and link with the object file.
The second phase would be to have a DCLTABLES implementation.
Do we know how we want this kind of library routines written (CLI$), are we
planning to write in C or C++? Meaning are we going to use gcc or g++?
================================================================================
Archive-Date: Tue, 08 Oct 1996 20:36:58 +0200
Sender: owner-free-vms@lp.se
Date: Tue, 8 Oct 1996 14:37:00 -0400
From: JayPed@aol.com
Reply-To: Free-VMS@lp.se
Message-ID: <961008143658_121727106@emout10.mail.aol.com>
To: Free-VMS@lp.se
Subject: Case-sensitivity in routine names. cli$present or CLI$PRESENT?
In a message dated 96-10-08 13:47:14 EDT, you write:
<< Do we know how we want this kind of library routines written (CLI$), are
we
planning to write in C or C++? Meaning are we going to use gcc or g++? >>
Do we know how we want routines named ... in lowercase or uppercase?
Since VMS was case-insensitive on the routine names for so long, you could
call sys$exit or SYS$EXIT and both would work (as I recall). Do we know how
we want to handle the routine naming?
================================================================================
Archive-Date: Wed, 09 Oct 1996 01:14:37 +0200
Sender: owner-free-vms@lp.se
Date: Tue, 8 Oct 1996 16:14:41 -0700
From: Tony Konashenok <tonyk@sseos.lbl.gov>
Reply-To: Free-VMS@lp.se
Message-ID: <199610082314.QAA12476@sseos.lbl.gov>
To: free-vms@lp.se
Subject: FTP server and future problems
Hello folks:
Before we get an FTP server set up, we need to agree on some policy -- to
prevent possible serious problems in the future. I suggest the following:
1. There should be only one official repository. All others may mirror
the official server, but never accept submissions themselves.
2. There should be some kind of version control. It would probably be
wise to have a VMS-based server, so it would have version numbers in
the names. We also need either a code maintenancew system, or a human
maintainer who is the only person with write permission to the repository.
We should also make change logs mandatory, no matter how small the change is.
Maybe it's obvious to most of us, but in such a serious project we are
better off overprotected than underprotected.
3. We need a quality assurance team. In particular, when the system
finally takes shape, no piece of code should be released to the public
until it has gone through QA. It is not to be in lieu of alpha-beta-testing,
but to "keep weeds under control". What we are writing here is, after all,
a flavour of VMS -- a system which grew in the culture of good programming
style. The lack of QA is bound to lead us to sloppy programming a la U*IX.
It is not to say that all unixes are sloppy, but we have all seen enough
of it and probably don't want it to happen here.
4. We should probably allow list members to log into the repository server
machine, and do some development work there.
5. I can set up a machine for the project -- a VAXstation 3100/48 or 3200 with
about 2 GB worth of disks, but I have no funds to pay for the connectivity
we need. Right now, these are my test bench machines with no direct connection
to the outside world (they are only Ethernetted to my PC, which only has a
dial-out SLIP link). Lots of hardware, and no place to connect to.
(I could donate some disks, but these guys are pretty heavy bricks, and
shipping them from California to Sweden would cost about as much as buying
them locally, I'm afraid). Any suggestions?
Tony Konashenok
================================================================================
Archive-Date: Wed, 09 Oct 1996 02:09:55 +0200
Sender: owner-free-vms@lp.se
Date: Wed, 9 Oct 1996 02:09:52 MET DST
Message-ID: <12891.2416.405647v0.1b7.LEVITTE@devil.bofh.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: FTP Server
From: Christof Zeile <christof.zeile@ins.uni-stuttgart.de>
Perhaps the mail of Kurt Schumacher is of some interest to you:
> Subject: FTP site for Free-VMS - Offer
> Date: Fri, 20 Sep 1996 12:09:36 MET_DST
> From: Kurt Schumacher - KS E & C <Kurt.Schumacher@decus.ch>
> To: FREE-VMS@LP.SE
It is interesting, yes! And I think is was Jim who sent a message to
Kurt asking about the offer. I haven't seen a reply to it yet.
What I'd like to know is how Kurt was thinking management of the FTP site
would be done...
--
R Levitte, Levitte Programming; Spannvägen 38, I; S-161 43 Bromma; SWEDEN
Tel: +46-8-26 52 47; 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://www.lp.se/~levitte for my public key. bastard@bofh.se
================================================================================
Archive-Date: Wed, 09 Oct 1996 02:45:11 +0200
Sender: owner-free-vms@lp.se
Date: Wed, 9 Oct 1996 02:45:08 MET DST
Message-ID: <12891.4532.405647v0.1b7.LEVITTE@devil.bofh.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: What has happened to the list?
From: JayPed@aol.com
I would be willing to work on the CLI$ routines, including a "SET
COMMAND/OBJECT" utility to parse a .CLD file and create an .OBJ file.
Hear, hear! (was that correctly spellt?)
I say: go right ahead! The sooner we have such a library working,
the better!
Do we know how we want this kind of library routines written (CLI$), are we
planning to write in C or C++? Meaning are we going to use gcc or g++?
My plan has been to go C all the time. That's one of the few languages
where there's already a free compiler available (gcc, you guessed it).
--
R Levitte, Levitte Programming; Spannvägen 38, I; S-161 43 Bromma; SWEDEN
Tel: +46-8-26 52 47; 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://www.lp.se/~levitte for my public key. bastard@bofh.se
================================================================================
Archive-Date: Wed, 09 Oct 1996 02:49:16 +0200
Sender: owner-free-vms@lp.se
Date: Wed, 9 Oct 1996 02:49:12 MET DST
Message-ID: <12891.4776.405647v0.1b7.LEVITTE@devil.bofh.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: Case-sensitivity in routine names. cli$present or CLI$PRESENT?
Since VMS was case-insensitive on the routine names for so long, you could
call sys$exit or SYS$EXIT and both would work (as I recall). Do we know how
we want to handle the routine naming?
There's quite a lot of code out there that relly on this feature (some call
it a bug. I don't), so I think we should go for case-insensitivity whenever
a linker is built. In short: let's be bug compatable when needed :-).
--
R Levitte, Levitte Programming; Spannvägen 38, I; S-161 43 Bromma; SWEDEN
Tel: +46-8-26 52 47; 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://www.lp.se/~levitte for my public key. bastard@bofh.se
================================================================================
Archive-Date: Wed, 09 Oct 1996 03:08:58 +0200
Sender: owner-free-vms@lp.se
Date: Tue, 8 Oct 1996 21:14:01 -0400
Message-ID: <199610090114.VAA00895@harvey.cyclic.com>
From: Jim Kingdon <kingdonc@harvey.cyclic.com>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: What has happened to the list?
> That's excellent. I got the impression this will be some kind of
> standalone program that runs without VMS.
There is such a thing as standalone BACKUP, but that isn't what I am
working on (not yet, at least).
> Ok, testing is certainly something I can do, time permitting. Or add
> some more or less useful remarks. But for the actual stuff... I'd like
> to be able to but I've got another job to do.
Do not worry, it is all part of the master plan :-). You will start
out saying "oh, I'll just do a little testing" and next thing you know
you are looking at the clock saying "where did all the time go?".
<sinister laugh mode on>Bwahahaha.
================================================================================
Archive-Date: Wed, 09 Oct 1996 03:25:33 +0200
Sender: owner-free-vms@lp.se
Date: Tue, 8 Oct 1996 21:30:39 -0400
Message-ID: <199610090130.VAA00981@harvey.cyclic.com>
From: Jim Kingdon <kingdonc@harvey.cyclic.com>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: What has happened to the list?
> I would be willing to work on the CLI$ routines, including [related
> utilities]
Cool! Sign that person up on the task list before he changes his
mind! :-).
I assume you are aware of the VERB distribution--it has a certain
amount of possibly useful information.
> Do we know how we want this kind of library routines written (CLI$), are we
> planning to write in C or C++? Meaning are we going to use gcc or g++?
Well, I'm writing in C. I'm using DECC but view GCC as the goal
(maybe after someone enhances GCC to support globalvalue and any other
egregiously missing features, though). Nothing official about this
opinion, though...
================================================================================
Archive-Date: Wed, 09 Oct 1996 05:11:24 +0200
Sender: owner-free-vms@lp.se
Date: Wed, 9 Oct 1996 05:11:21 MET DST
Message-ID: <12891.13305.405647v0.1b7.LEVITTE@devil.bofh.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: What has happened to the list?
From: Jim Kingdon <kingdonc@harvey.cyclic.com>
> I would be willing to work on the CLI$ routines, including [related
> utilities]
Cool! Sign that person up on the task list before he changes his
mind! :-).
Yup. Done. I'll hack the WWW pages tomorrow...
I assume you are aware of the VERB distribution--it has a certain
amount of possibly useful information.
Yup, that's a pretty good source. I'll look for other docs as well
(the source is kind of a documentation, isn't it? :-)), if you wish.
--
R Levitte, Levitte Programming; Spannvägen 38, I; S-161 43 Bromma; SWEDEN
Tel: +46-8-26 52 47; 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://www.lp.se/~levitte for my public key. bastard@bofh.se
================================================================================
Archive-Date: Wed, 09 Oct 1996 09:55:16 +0200
Sender: owner-free-vms@lp.se
Date: Wed, 09 Oct 1996 09:55:06 CET
From: Jerzy Michal Pawlak <pawlak@hozavx.fuw.edu.pl>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
CC: pawlak@hozavx.fuw.edu.pl
Message-ID: <009A9950.69DA7940.3@hozavx.fuw.edu.pl>
Subject: Re: What has happened to the list?
> I assume you are aware of the VERB distribution--it has a certain
> amount of possibly useful information.
>
>Yup, that's a pretty good source. I'll look for other docs as well
>(the source is kind of a documentation, isn't it? :-)), if you wish.
You mean 'good source for information about structure of the command
tables'? It is probably true, but I'm wondering if we should use it.
Specifically, I would vote for dropping the '4 characters' rule - i.e.
make the DCL parser (and CLI$ routines) check the whole name, not just
first four characters. After all, even DEC announced that they are
going to drop this feature 'in some future release'.
And if we do it, it will probably mean very deep changes to the
structure of the command tables...
Michal Pawlak
http://hozavx.fuw.edu.pl/~pawlak/
================================================================================
Archive-Date: Wed, 09 Oct 1996 10:03:37 +0200
Sender: owner-free-vms@lp.se
From: kkaempf@progis.de (Klaus Kaempf)
Reply-To: Free-VMS@lp.se
Message-ID: <9610090649.AA11697@didymus.progis.de>
Subject: gcc globalvalue
To: Free-VMS@lp.se
Date: Wed, 9 Oct 1996 08:49:52 +0200 (MET DST)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
>=20
> Well, I'm writing in C. I'm using DECC but view GCC as the goal
Good !
> (maybe after someone enhances GCC to support globalvalue and any other
> egregiously missing features, though).
Just tell me what's missing and maybe it'll show up in GCC :-)
--=20
proGIS Software E-Mail: kkaempf@progis.de
Dipl.-Inform. Klaus K=E4mpf Fax: 0241-47067-29
Jakobstr. 117 Voice: 0241-47067-11
D-52064 Aachen WWW: http://www.progis.de
================================================================================
Archive-Date: Wed, 09 Oct 1996 10:03:46 +0200
Sender: owner-free-vms@lp.se
From: kkaempf@progis.de (Klaus Kaempf)
Reply-To: Free-VMS@lp.se
Message-ID: <9610090652.AA11712@didymus.progis.de>
Subject: Re: Case-sensitivity in routine names. cli$present or CLI$PRESENT?
To: Free-VMS@lp.se
Date: Wed, 9 Oct 1996 08:52:10 +0200 (MET DST)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
> There's quite a lot of code out there that relly on this feature (some =
call
> it a bug. I don't), so I think we should go for case-insensitivity whe=
never
> a linker is built. In short: let's be bug compatable when needed :-).
Writing a linker based on the code that's already in the bfd library shou=
ldn't
be too hard. All we need is a thorough documentation of the vms .exe form=
at.
--=20
proGIS Software E-Mail: kkaempf@progis.de
Dipl.-Inform. Klaus K=E4mpf Fax: 0241-47067-29
Jakobstr. 117 Voice: 0241-47067-11
D-52064 Aachen WWW: http://www.progis.de
================================================================================
Archive-Date: Wed, 09 Oct 1996 11:28:55 +0200
Sender: owner-free-vms@lp.se
Date: Wed, 9 Oct 1996 11:28:51 MET DST
Message-ID: <12891.35955.405647v0.1b7.LEVITTE@devil.bofh.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
CC: Free-VMS@lp.se, pawlak@hozavx.fuw.edu.pl
Subject: Re: What has happened to the list?
Specifically, I would vote for dropping the '4 characters' rule - i.e.
make the DCL parser (and CLI$ routines) check the whole name, not just
first four characters. After all, even DEC announced that they are
going to drop this feature 'in some future release'.
Hmm... Yup, I wouldn't mind dropping that feature. Let's just hope
there aren't too many scripts containing perverted command like "defix".
I would like to hear other peoples comments on this issue, thanks!
And if we do it, it will probably mean very deep changes to the
structure of the command tables...
Will it? Hmm, I was absolutelly convinced the full symbol names were
stored. How could VERB find out the full name otherwise. My guess is
that the '4 character rule' is just a faster comparison: longwords.
It's very much faster to compare two longwords than two strings.
Just FYI, I've never looked too closelly at VERB... Perhaps I should...
--
R Levitte, Levitte Programming; Spannvägen 38, I; S-161 43 Bromma; SWEDEN
Tel: +46-8-26 52 47; 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://www.lp.se/~levitte for my public key. bastard@bofh.se
================================================================================
Archive-Date: Wed, 09 Oct 1996 11:28:57 +0200
Sender: owner-free-vms@lp.se
Date: Wed, 9 Oct 1996 11:28:51 MET DST
Message-ID: <12891.35955.405647v0.1b7.LEVITTE@devil.bofh.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
CC: Free-VMS@lp.se, pawlak@hozavx.fuw.edu.pl
Subject: Re: What has happened to the list?
Specifically, I would vote for dropping the '4 characters' rule - i.e.
make the DCL parser (and CLI$ routines) check the whole name, not just
first four characters. After all, even DEC announced that they are
going to drop this feature 'in some future release'.
Hmm... Yup, I wouldn't mind dropping that feature. Let's just hope
there aren't too many scripts containing perverted command like "defix".
I would like to hear other peoples comments on this issue, thanks!
And if we do it, it will probably mean very deep changes to the
structure of the command tables...
Will it? Hmm, I was absolutelly convinced the full symbol names were
stored. How could VERB find out the full name otherwise. My guess is
that the '4 character rule' is just a faster comparison: longwords.
It's very much faster to compare two longwords than two strings.
Just FYI, I've never looked too closelly at VERB... Perhaps I should...
--
R Levitte, Levitte Programming; Spannvägen 38, I; S-161 43 Bromma; SWEDEN
Tel: +46-8-26 52 47; 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://www.lp.se/~levitte for my public key. bastard@bofh.se
================================================================================
Archive-Date: Wed, 09 Oct 1996 11:35:10 +0200
Sender: owner-free-vms@lp.se
Date: Wed, 09 Oct 1996 10:36:59 MET
From: Kurt Schumacher - KS E & C <Kurt.Schumacher@decus.ch>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
CC: Kurt.Schumacher@decus.ch
Message-ID: <009A9956.43888A60.3@elias.decus.ch>
Subject: Re: FTP Server
The new elias.decus.ch will be delivered next week with installation starting
soon. We will come on to the net END OF NOVEMBER 96 due to limited
ressources to do all the installation needed.
There will be an upload area available, move to the normal area or
ftp administrator accounts on request and negotiation.
regards
Kurt
at DECUS Europe in Barcelona right now.
+------------------------------------------------------------------------+
| Kurt Schumacher E-Mail: Kurt.Schumacher@decus.ch |
| PSI-Mail: PSI%022847911312::K_SCHUMACHER |
| Riedhofstrasse 303 Voice: +41 1 342 42 54 |
| CH-8049 Zürich FAX: +41 1 342 42 54 |
+------------------------------------------------------------------------+
================================================================================
Archive-Date: Wed, 09 Oct 1996 11:43:35 +0200
Sender: owner-free-vms@lp.se
Date: Wed, 09 Oct 1996 10:45:28 MET
From: Kurt Schumacher - KS E & C <Kurt.Schumacher@decus.ch>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
CC: Kurt.Schumacher@decus.ch
Message-ID: <009A9957.73337E40.10@elias.decus.ch>
Subject: Re: FTP Server
ftp server:
Basic system management is done by DECUS Switzerland, ftp administrator
accounts can be provided, holding special identifier to maintain the
Free-VMS part.
Further details need some negotiations.
regards,
Kurt
at DECUS Europe in Barcelona right now
+------------------------------------------------------------------------+
| Kurt Schumacher E-Mail: Kurt.Schumacher@decus.ch |
| PSI-Mail: PSI%022847911312::K_SCHUMACHER |
| Riedhofstrasse 303 Voice: +41 1 342 42 54 |
| CH-8049 Zürich FAX: +41 1 342 42 54 |
+------------------------------------------------------------------------+
================================================================================
Archive-Date: Wed, 09 Oct 1996 12:12:11 +0200
Sender: owner-free-vms@lp.se
Date: Wed, 9 Oct 1996 6:11:58 -0400 (EDT)
From: jhjennis2@mmm.com
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Message-ID: <961009061158.202bd807@mdw>
Subject: RE: FTP server and future problems
Hi Free-VMS list members,
I agree with these suggestions, especially about QA on the code. There are a lot
of good VMS people on this list that could test/assure the quality of the code
and make FreeMS a real "showpiece" of software development.
Best regards to all,
Jim Jennis, Systems & Network Mgr.
Imation Corp.
Printing & Publishing Systems Div.
Middleway, WV. USA.
Internet: jhjennis2@mmm.com
>Hello folks:
>Before we get an FTP server set up, we need to agree on some policy -- to
>prevent possible serious problems in the future. I suggest the following:
>1. There should be only one official repository. All others may mirror
>the official server, but never accept submissions themselves.
>2. There should be some kind of version control. It would probably be
>wise to have a VMS-based server, so it would have version numbers in
>the names. We also need either a code maintenancew system, or a human
>maintainer who is the only person with write permission to the repository.
>We should also make change logs mandatory, no matter how small the change is.
>Maybe it's obvious to most of us, but in such a serious project we are
>better off overprotected than underprotected.
>3. We need a quality assurance team. In particular, when the system
>finally takes shape, no piece of code should be released to the public
>until it has gone through QA. It is not to be in lieu of alpha-beta-testing,
>but to "keep weeds under control". What we are writing here is, after all,
>a flavour of VMS -- a system which grew in the culture of good programming
>style. The lack of QA is bound to lead us to sloppy programming a la U*IX.
>It is not to say that all unixes are sloppy, but we have all seen enough
>of it and probably don't want it to happen here.
>4. We should probably allow list members to log into the repository server
>machine, and do some development work there.
================================================================================
Archive-Date: Wed, 09 Oct 1996 15:55:42 +0200
Sender: owner-free-vms@lp.se
Date: Wed, 9 Oct 1996 09:55:40 -0400
Message-ID: <199610091355.JAA30603@serv01.net-link.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Free-VMS@lp.se
From: Todd Campbell <toddc@net-link.net>
Reply-To: Free-VMS@lp.se
Subject: Re: FTP server and future problems
At 04:14 PM 10/8/96 -0700, you wrote:
>
>Hello folks:
>Before we get an FTP server set up, we need to agree on some policy -- to
>prevent possible serious problems in the future. I suggest the following:
>
>5. I can set up a machine for the project -- a VAXstation 3100/48 or 3200 with
>about 2 GB worth of disks, but I have no funds to pay for the connectivity
>we need. Right now, these are my test bench machines with no direct connection
>to the outside world (they are only Ethernetted to my PC, which only has a
>dial-out SLIP link).
I spoke with my boss last night about this, and I may be able to put up such
a machine on our T1.
Let me know.
-Todd C. Campbell
Netlink Systems L.L.C.
================================================================================
Archive-Date: Wed, 09 Oct 1996 18:23:07 +0200
Sender: owner-free-vms@lp.se
Message-ID: <c=US%a=_%p=msft%l=RED-70-MSG-961009161835Z-60411@mail.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: What has happened to the list?
Date: Wed, 9 Oct 1996 09:18:35 -0700
Couple of things...
I beleive, and could have this backwards, that the VMS linker is
case sensitive, but that the compilers generate global symbols in
upper case which is why call sys$exit matches calling SYS$EXIT.
I wouldn't drop the 4 character verb limitation... as much of a pain as
it is.
People do rely on it, and I really don't see VMS changing it. If anyone
has
ever looked at the DCL sources you would understand.
Christopher
(now at Microsoft)
>----------
>From: Jerzy Michal Pawlak[SMTP:pawlak@hozavx.fuw.edu.pl]
>Sent: Wednesday, October 09, 1996 2:55 AM
>To: Free-VMS@lp.se
>Cc: pawlak@hozavx.fuw.edu.pl
>Subject: Re: What has happened to the list?
>
>> I assume you are aware of the VERB distribution--it has a certain
>> amount of possibly useful information.
>>
>>Yup, that's a pretty good source. I'll look for other docs as well
>>(the source is kind of a documentation, isn't it? :-)), if you wish.
>
>You mean 'good source for information about structure of the command
>tables'? It is probably true, but I'm wondering if we should use it.
>Specifically, I would vote for dropping the '4 characters' rule - i.e.
>make the DCL parser (and CLI$ routines) check the whole name, not just
>first four characters. After all, even DEC announced that they are
>going to drop this feature 'in some future release'.
>
>And if we do it, it will probably mean very deep changes to the
>structure of the command tables...
>
>Michal Pawlak
>http://hozavx.fuw.edu.pl/~pawlak/
>
================================================================================
Archive-Date: Wed, 09 Oct 1996 18:25:07 +0200
Sender: owner-free-vms@lp.se
From: John David Galt <jdg@rahul.net>
Reply-To: Free-VMS@lp.se
Date: Wed, 9 Oct 1996 09:24:59 -0700
Message-ID: <199610091624.AA16364@foxtrot.rahul.net>
To: Free-VMS@lp.se
Subject: Re: Case-sensitivity in routine names. cli$present or CLI$PRESENT?
> There's quite a lot of code out there that relly on this feature (some call
> it a bug. I don't), so I think we should go for case-insensitivity whenever
> a linker is built. In short: let's be bug compatable when needed :-).
AFAIK, the existing "feature" consists of having LINK be case-blind by
default. I'm all for keeping it that way, but would make the actual names
all upper-case for consistency, for those who want to do case-sensitive
linking.
John David Galt <jdg@rahul.net>
================================================================================
Archive-Date: Wed, 09 Oct 1996 18:58:44 +0200
Sender: owner-free-vms@lp.se
Date: Wed, 9 Oct 1996 12:58:55 -0400
From: JayPed@aol.com
Reply-To: Free-VMS@lp.se
Message-ID: <961009125854_1379612700@emout07.mail.aol.com>
To: Free-VMS@lp.se
Subject: Re: What has happened to the list?
In a message dated 96-10-09 04:00:05 EDT, you write:
<< You mean 'good source for information about structure of the command
tables'? It is probably true, but I'm wondering if we should use it.
Specifically, I would vote for dropping the '4 characters' rule - i.e.
make the DCL parser (and CLI$ routines) check the whole name, not just
first four characters. After all, even DEC announced that they are
going to drop this feature 'in some future release'. >>
I wasn't planning to copy the structure of DCLTABLES or anything like that.
I was planning to make a 'functionally equivalent' version of SET
COMMAND/OBJECT and CLI$GET_VALUE, CLI$PRESENT, CLI$DISPATCH.
It would be functionally equivalent supporting the same CLD language, with
parameters, positional qualifiers, alternate syntaxes (define syntax),
ambiguity checking (disallow), etc.
It would return the same named error codes CLI$_ABSENT, CLI$_PRESENT, etc.
Regarding that ... are we going to copy the error code values that VMS has?
Or will we just use the same names? Will CLI$_ABSENT have the exact same
value that it has on VMS ... or just the same name?
As far as the 4-character checking ... I think that is a run-time thing ... I
think the full names are stored in the DCLTABLES.
So ... I guess that is an important point to clear up ... do we insist on
following that VMS convention?
LOGOT == LOGOFF == LOGO == LOGOUT ???
I suppose we would break existing command files if we don't follow that
convention.
To me ... LOGOT and LOGOFF are not the same as LOGOUT and should result in a
syntax error. Whereas LOGO and LOGOU are the same as LOGOUT as long as they
are unambiguous substrings. (That is ... there is no LOGON command which
would make LOGO ambiguous). I always thought it was kind of humorous that
VMS allowed things like LOGOT to do a LOGOUT ... but not very useful.
This leads to other confusing things in DCL ... there were people who thought
there was a f$getspi function .... because they could do
$ cputime = f$getspi("CPU")
As it turned out ... this was actually doing an f$getsyi and not f$getspi.
Do we want to implement that same functionality?
I would rather see syntax errors generated in these cases ... and people
depending on this bad behaviour be darned ... or something.
-Jay Pedersen
================================================================================
Archive-Date: Wed, 09 Oct 1996 22:26:15 +0200
Sender: owner-free-vms@lp.se
Date: Wed, 9 Oct 1996 14:26:18 -0600
Message-ID: <9610092026.AA17223@snake.srv.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Free-VMS@lp.se
From: kth@srv.net (Kevin Handy)
Reply-To: Free-VMS@lp.se
Subject: Re: gcc globalvalue
>>
>> Well, I'm writing in C. I'm using DECC but view GCC as the goal
>
>> (maybe after someone enhances GCC to support globalvalue and any other
>> egregiously missing features, though).
>
>Just tell me what's missing and maybe it'll show up in GCC :-)
>
One difference I've noticed between VAX-C and GNU-C is that
VAX-C allows you to take the address of a number, and GNU-C
doesn't. This can really be useful in the VMS environment where
many parameters are passed by reference, and many of those
are either zero or one. An example:
VAX-C allows:
VAX$FUNCTION(&0L, &1L);
GNU-C needs:
long zero = 0L;
long one = 1L;
VAX$FUNCTION(&zero, &one);
Useful, but this isn't ANSI complient behavior, and I don't think
that Free-VMS would want to do it in the VAX-C way anyhow. Use the
standards whenever possible.
-------------------------------------------------------------
Kevin Handy kth@srv.ne Accounting Software for
Software Solutions. Inc. VAX/VMS Computer Systems
Idaho Falls, Idaho
================================================================================
Archive-Date: Wed, 09 Oct 1996 22:32:26 +0200
Sender: owner-free-vms@lp.se
Date: Wed, 9 Oct 1996 14:32:33 -0600
Message-ID: <9610092032.AA09782@snake.srv.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Free-VMS@lp.se
From: kth@srv.net (Kevin Handy)
Reply-To: Free-VMS@lp.se
Subject: Re: What has happened to the list?
>In a message dated 96-10-09 04:00:05 EDT, you write:
>
>
>Regarding that ... are we going to copy the error code values that VMS has?
> Or will we just use the same names? Will CLI$_ABSENT have the exact same
>value that it has on VMS ... or just the same name?
>
If you are planning on any kind of binary compatability, you should
use the same numeric values. Otherwise there will be a need to handle
VMS compiled images differently than Free-VMS compiled images.
Re-numbering them would only cause problems.
-------------------------------------------------------------
Kevin Handy kth@srv.ne Accounting Software for
Software Solutions. Inc. VAX/VMS Computer Systems
Idaho Falls, Idaho
================================================================================
Archive-Date: Wed, 09 Oct 1996 22:44:17 +0200
Sender: owner-free-vms@lp.se
Date: Wed, 9 Oct 1996 16:44:19 -0400
From: leichter@smarts.com (Jerry Leichter)
Reply-To: Free-VMS@lp.se
Message-ID: <199610092044.QAA21597@just.smarts.com>
To: Free-VMS@lp.se
Subject: Compatibility, DCL 4-character limitations, etc.
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
We know we want Free-VMS to be "compatible" with VMS. But there are all kinds of "compatibility".
For example, if there is to be a VAX or Alpha version of Free-VMS, should it be
binary-compatible with VMS - i.e., should an image built on one work on the
other? This would be very useful for testing and development, but would impose
all kinds of costs, since then either one builds two distinct sets of code to
deal with the VAX/Alpha world and "all others", or one has to come up with a
common generalization that supports both.
My own feeling is that binary compatibility is probably a good idea, since it
lets you "hit the ground running". Otherwise, before you can even get started,
you need to design and build a linker and an image activator and various other
very basic pieces. (Of course, the other possibility is to use one of the
"portable" Unix formats. The problem is that's it's unclear that any of them
support the primitives needed to implement VMS image file semantics.)
The next question is "bug-for-bug" compatibility or "upward compatibility". The
first says that things work *and fail* in exactly the same way on both systems.
The second says that stuff that works on VMS will work the same way on Free-VMS,
but if it fails on VMS, all best are off.
Bug-for-bug compatibility seems to me a waste of time. For one thing, it's a
moving target as new VMS versions ship. For another, it's not something you can
easily determine even for a particular version!
Really, VMS programmers are expected to work from the *documented* capabilities
of VMS, not from its implementation. And that's what Free-VMS should also start
from.
Now, the problem of extensions comes up. In general, I think the rule should be
"anything that is consistent with the VMS documentation shall work on Free-VMS";
but Free-VMS may add things.
The current documentation specifically says that only 4 characters of DCL
commands are used to identify the command. There are many command files that
make use of this feature. Yes, DEC has been saying for years that one shouldn't
rely on this rule remaining true, but in practice I doubt if DEC will ever
change it - too much existing code would break.
I contend that Free-DCL must also support such code. To do otherwise would be
to break upward compatibility.
Now, it might be possible to provide extended parsing *as an option*. For
example, there might be a SET [NO]EXTENDED_VERBS command. If done right, this
could provide both upward compatibility and extended functionality. But note
what's involved with "done right". Existing command files must continue to
work. Existing command files that invoke command files in extended format
must work. Extended format command files that invoke old-style non-extended
command files must work. What this comes down to is: SET [NO]EXTENDED_VERBS
must be defined at each level of procedure nesting. On entry to any command
file, the current setting is saved, and extended mode is turned off. On exit
from a command file, the previous setting is restored. "Interactive level", of
course, counts as a level of nesting.
This is the kind of detail that needs to be worked out for each proposed
extension. It's a complex job, but if you really want Free-VMS to *be* VMS, it
has to be done.
-- Jerry
================================================================================
Archive-Date: Wed, 09 Oct 1996 23:00:50 +0200
Sender: owner-free-vms@lp.se
Date: Wed, 09 Oct 1996 16:00:58 CST
From: Hunter Goatley <goathunter@MadGoat.COM>
Reply-To: Free-VMS@lp.se
To: FREE-VMS@LP.SE
Message-ID: <009A9983.866875B6.1@ALPHA.WKU.EDU>
Subject: VMSBACKUP available
I've added John Douglas Carey's version of VMSBACKUP to the Free-VMS
FTP directory on ftp.wku.edu:
ftp://ftp.wku.edu/vms/free-vms/testing/vmsbackup.tar
ftp://ftp.wku.edu/vms/free-vms/testing/vmsbackup.zip
I compiled and ran it on a Sun system---pretty nifty!
I agree about the need for quality-control on files on the FTP site,
etc. When a real volunteer steps up, I'll gladly get rid of my
directory. Until then, it's there, if you need it.
Hunter
------
Hunter Goatley, Process Software Corporation (TCPware)
<goathunter@MadGoat.com> http://www.wku.edu/www/madgoat/hunter.html
================================================================================
Archive-Date: Wed, 09 Oct 1996 23:33:55 +0200
Sender: owner-free-vms@lp.se
Date: Wed, 9 Oct 1996 23:33:50 MET DST
Message-ID: <12892.13918.405647v0.1b7.LEVITTE@devil.bofh.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: What has happened to the list?
I wasn't planning to copy the structure of DCLTABLES or anything like that.
I was planning to make a 'functionally equivalent' version of SET
COMMAND/OBJECT and CLI$GET_VALUE, CLI$PRESENT, CLI$DISPATCH.
I guess that someone (if not you) would build the code to build DCLTABLES
based upon your work.
Regarding that ... are we going to copy the error code values that VMS has?
Absolutelly. There are many scripts that depend on those codes. And it's
not that difficult to duplicate. I seriously doubt DEC would mind, after all
:-).
Or will we just use the same names?
That as well :-).
As far as the 4-character checking ... I think that is a run-time thing ... I
think the full names are stored in the DCLTABLES.
I was told recently that both are stored in DCLTABLES. The 4-character
variants in some kind of lookup table, and the real names with the
definitions...
VMS allowed things like LOGOT to do a LOGOUT ... but not very useful.
Actually, it's pretty nice to be allowed to make spelling errors (I know,
provided you have the first 4 characters right...). Oh well, I dunno.
$ cputime = f$getspi("CPU")
Hmm... "spi" = "System Processor Information"? Oh my...
I would rather see syntax errors generated in these cases ... and people
depending on this bad behaviour be darned ... or something.
In a way (transmogrifying into a bastard) it would be lots of fun seeing
all those scripts break, wither and die. *Niahahahaha* (transmogrifying
back). No seriously, I'm having some problems making up my mind about this.
One of the backsides with the current workings is that the name space is
finite, and you HAVE to make sure there's no other command starting with
the same 4 characters as your command. The only frontside (as opposed to
backside) [1] that I see is that the search for the right keyword is so
much faster when you compare longwords (which is what happens, I'm sure).
-----
[1] Yes, I know: advantage
--
R Levitte, Levitte Programming; Spannvägen 38, I; S-161 43 Bromma; SWEDEN
Tel: +46-8-26 52 47; 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://www.lp.se/~levitte for my public key. bastard@bofh.se
================================================================================
Archive-Date: Wed, 09 Oct 1996 23:49:23 +0200
Sender: owner-free-vms@lp.se
Message-ID: <c=US%a=_%p=msft%l=RED-70-MSG-961009211053Z-62247@mail.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: What has happened to the list?
Date: Wed, 9 Oct 1996 14:10:53 -0700
You *really* want to use the exact same values because many
people have them hard-coded in their code!
Christopher
>----------
>From: kth@srv.net[SMTP:kth@srv.net]
>Sent: Wednesday, October 09, 1996 1:32 PM
>To: Free-VMS@lp.se
>Subject: Re: What has happened to the list?
>
>>In a message dated 96-10-09 04:00:05 EDT, you write:
>>
>>
>>Regarding that ... are we going to copy the error code values that VMS has?
>> Or will we just use the same names? Will CLI$_ABSENT have the exact same
>>value that it has on VMS ... or just the same name?
>>
>If you are planning on any kind of binary compatability, you should
>use the same numeric values. Otherwise there will be a need to handle
>VMS compiled images differently than Free-VMS compiled images.
>Re-numbering them would only cause problems.
>-------------------------------------------------------------
>Kevin Handy kth@srv.ne Accounting Software for
>Software Solutions. Inc. VAX/VMS Computer Systems
>Idaho Falls, Idaho
>
>
================================================================================
Archive-Date: Thu, 10 Oct 1996 00:30:22 +0200
Sender: owner-free-vms@lp.se
Date: Thu, 10 Oct 1996 00:30:19 MET DST
Message-ID: <12892.17307.405647v0.1b7.LEVITTE@devil.bofh.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: free-vms@lp.se
Assar Westerlund <assar@sics.se>
================================================================================
Archive-Date: Thu, 10 Oct 1996 00:33:31 +0200
Sender: owner-free-vms@lp.se
Date: Thu, 10 Oct 1996 00:33:27 MET DST
Message-ID: <12892.17495.405647v0.1b7.LEVITTE@devil.bofh.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: free-vms@lp.se
Assar Westerlund <assar@sics.se>
Oops, sorry boys...
--
R Levitte, Levitte Programming; Spannvägen 38, I; S-161 43 Bromma; SWEDEN
Tel: +46-8-26 52 47; 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://www.lp.se/~levitte for my public key. bastard@bofh.se
================================================================================
Archive-Date: Thu, 10 Oct 1996 00:39:43 +0200
Sender: owner-free-vms@lp.se
To: Free-VMS@lp.se
Subject: Re: What has happened to the list?
References: <12892.13918.405647v0.1b7.LEVITTE@devil.bofh.se>
MIME-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
From: Assar Westerlund <assar@sics.se>
Reply-To: Free-VMS@lp.se
Date: 10 Oct 1996 00:40:05 +0200
Message-ID: <5ln2xvlq2i.fsf@assaris.sics.se>
Richard Levitte - VMS Whacker <levitte@lp.se> writes:
> In a way (transmogrifying into a bastard) it would be lots of fun seeing
> all those scripts break, wither and die. *Niahahahaha* (transmogrifying
> back). No seriously, I'm having some problems making up my mind about this.
> One of the backsides with the current workings is that the name space is
> finite, and you HAVE to make sure there's no other command starting with
> the same 4 characters as your command. The only frontside (as opposed to
> backside) [1] that I see is that the search for the right keyword is so
> much faster when you compare longwords (which is what happens, I'm sure).
Are you really going to make that HUGE amount of comparisons? And are
you sure there is that HUGE difference between a 32bit-word compare
and an efficient hash?
I don't really think it matters and it will probably matter even less
when LeViMS, sorry free-vms is done and works. Do what's right
instead (I think comparing all characters is the right thing, but then
I'm not a VMS-expert).
/assar
================================================================================
Archive-Date: Thu, 10 Oct 1996 00:50:46 +0200
Sender: owner-free-vms@lp.se
Message-ID: <c=US%a=_%p=msft%l=RED-70-MSG-961009223157Z-62687@mail4.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: Compatibility, DCL 4-character limitations, etc.
Date: Wed, 9 Oct 1996 15:31:57 -0700
>
>For example, if there is to be a VAX or Alpha version of Free-VMS, should it
>be
>binary-compatible with VMS - i.e., should an image built on one work on the
>other? This would be very useful for testing and development, but would
>impose
>all kinds of costs, since then either one builds two distinct sets of code to
>deal with the VAX/Alpha world and "all others", or one has to come up with a
>common generalization that supports both.
CK> Don't go there... it is a cold ugly place...
>My own feeling is that binary compatibility is probably a good idea, since it
>lets you "hit the ground running". Otherwise, before you can even get
>started,
>you need to design and build a linker and an image activator and various
>other
>very basic pieces. (Of course, the other possibility is to use one of the
>"portable" Unix formats. The problem is that's it's unclear that any of them
>support the primitives needed to implement VMS image file semantics.)
CK> I would strongly recommend that you shoot for source level
compatability
CK> but leverage off an existing VMS machine to bootstrap. Binary
compatability
CK> means that you need to provide the entire VMS exception handling
mechanisms
CK> as well as the system service transfer vectors. Having done this
before, you
CK> don't really want to go there. I would define the level of
compatability that you
CK> want to achieve, and shoot for that. I don't think it is 100%
otherwise you
CK> just lost the Intel platform. I don't think it is even 90%
otherwise you need to
CK> reproduce the entire driver subsystem to support 3rd part drivers.
I think what
CK> you really want is source level compatability with the documented
interfaces
CK> for user-level applications. That means somethings will break. So
be it.
>
>The next question is "bug-for-bug" compatibility or "upward compatibility".
>The
>first says that things work *and fail* in exactly the same way on both
>systems.
>The second says that stuff that works on VMS will work the same way on
>Free-VMS,
>but if it fails on VMS, all best are off.
CK> Yeah... but. There a quire a number of things that are "bugs" or
"not indended
CK> as features that people make use of. If you aren't carefull, you
will break them.
CK> That's why you need to define what you want to work. For example,
do you know
CK> what COPY/NONONONONONONONONONONONONONONONONONONONOLOG
CK> does? It is the same as COPY/LOG. Is that a bug or a feature?
>
>Bug-for-bug compatibility seems to me a waste of time. For one thing, it's a
>moving target as new VMS versions ship. For another, it's not something you
>can
>easily determine even for a particular version!
CK> It is the bugs that become features that you need to worry about.
There are many
CK> "aspects" of VMS that we wanted to change, but people had come to
rely on them
CK> and treat them as features... hence we were stuck.
>
>Really, VMS programmers are expected to work from the *documented*
>capabilities
>of VMS, not from its implementation. And that's what Free-VMS should also
>start
>from.
CK> That really depends on what they are doing. MIS staffs... probably.
DB vendors, never.
>
>Now, the problem of extensions comes up. In general, I think the rule should
>be
>"anything that is consistent with the VMS documentation shall work on
>Free-VMS";
>but Free-VMS may add things.
CK> I like that
>The current documentation specifically says that only 4 characters of DCL
>commands are used to identify the command. There are many command files that
>make use of this feature. Yes, DEC has been saying for years that one
>shouldn't
>rely on this rule remaining true, but in practice I doubt if DEC will ever
>change it - too much existing code would break.
CK> As well as having to re-write parts of DCL. It ain't gonna happen.
>I contend that Free-DCL must also support such code. To do otherwise would
>be
>to break upward compatibility.
>
>Now, it might be possible to provide extended parsing *as an option*. For
>example, there might be a SET [NO]EXTENDED_VERBS command. If done right,
>this
>could provide both upward compatibility and extended functionality. But note
>what's involved with "done right". Existing command files must continue to
>work. Existing command files that invoke command files in extended format
>must work. Extended format command files that invoke old-style non-extended
>command files must work. What this comes down to is: SET [NO]EXTENDED_VERBS
>must be defined at each level of procedure nesting. On entry to any command
>file, the current setting is saved, and extended mode is turned off. On exit
>from a command file, the previous setting is restored. "Interactive level",
>of
>course, counts as a level of nesting.
CK> Nice idea...
>
================================================================================
Archive-Date: Thu, 10 Oct 1996 00:57:30 +0200
Sender: owner-free-vms@lp.se
Date: Thu, 10 Oct 1996 00:57:21 MET DST
Message-ID: <12892.18929.405647v0.1b7.LEVITTE@devil.bofh.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: What has happened to the list?
Are you really going to make that HUGE amount of comparisons? And are
Nope, not really so much that it would matter, I think. But remember that
VMS ran (and still runs) on VAX 11/7xx, which are pretty slow with todays
measures (that is a translated swedish expression. I hope everyone
understands in any case). On those machines, I could believe it made a
difference. So the technical reason for doing longword comparison is
probably historical. Of course, people made use of it, so the issue is
really a compatibility one.
BTW, there is another thing we should decide upon that has to do with verbs:
should we accept commands that have extra characters at the end? You see,
since it's possible to define foreign commands with the same name as a
verb, some people have used command names with an extra character tucked
at the end, like this:
$ deletex foo.bar;*
$ deletex/symbol/global foobar
The last one is perfect if you have defined DELETE (or DEL*ETE) with the
value "DELETE/LOG" (ever tried DELETE/LOG/SYMBOL? In some VMS versions,
I think you got an error message, but I'm not sure any more...).
I don't really think it matters and it will probably matter even less
when LeViMS, sorry free-vms is done and works.
^^^^^^
Please meet Assar, a good friend of mine. He's the one who came up with
that name for the project when I talked about it (well, it was just my
thoughts back then) in a hamburger bar a bunch of years ago. Actually,
he's called me "LeViMS" ever since...
--
R Levitte, Levitte Programming; Spannvägen 38, I; S-161 43 Bromma; SWEDEN
Tel: +46-8-26 52 47; 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://www.lp.se/~levitte for my public key. bastard@bofh.se
================================================================================
Archive-Date: Thu, 10 Oct 1996 01:26:06 +0200
Sender: owner-free-vms@lp.se
Date: Thu, 10 Oct 1996 01:26:02 MET DST
Message-ID: <12892.20650.405647v0.1b7.LEVITTE@devil.bofh.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: RE: Compatibility, DCL 4-character limitations, etc.
From: Chris Kaler <ckaler@microsoft.com>
CK> I would strongly recommend that you shoot for source level
CK> compatability but leverage off an existing VMS machine to bootstrap.
May I remind everyone that the concensus has been since long that Free-VMS
should eventually be built on top of Mach. In that case especially, source
level compatibility is the way to go.
CK> don't really want to go there. I would define the level of
CK> compatability that you want to achieve, and shoot for that.
My thought was source compatibility down to the system routines and library
routines (the calls to them, mind you, not the routines themselves :-)).
This also means a level of functional compatibility. ASTs and Event Flags
should respond or be usefull in the same way. This means, of course, that
device driver designers, for example, will most probably have to work
differently. But that's already the case when building device drivers for
the Alpha, I've been told...
Whatever I've written could (and should) be subject to critique and/or
extension. I'm bound to forget things. I will need to define things more
clearly.
CK> what COPY/NONONONONONONONONONONONONONONONONONONONOLOG
CK> does? It is the same as COPY/LOG. Is that a bug or a feature?
That's perfectly logical to me :-).
CK> It is the bugs that become features that you need to worry about.
CK> There are many "aspects" of VMS that we wanted to change, but people
CK> had come to rely on them and treat them as features... hence we
CK> were stuck.
Care to give us a hint? This could be a way to make Free-VMS a "better VMS".
CK> As well as having to re-write parts of DCL. It ain't gonna happen.
I haven't looked at the source, but I've been told it's pretty ugly at
places. Anyway, again, give us a hint, please?
>work. Existing command files that invoke command files in extended format
>must work. Extended format command files that invoke old-style non-extended
>command files must work. What this comes down to is: SET [NO]EXTENDED_VERBS
...
CK> Nice idea...
There's another way to fix this, without the need for SET EXTENDED_VERBS.
Hint: this is the beginning of the definition of RUN:
define verb RUN
synonym R
synonym RU
So now you know why you can type "R FOO.EXE".
--
R Levitte, Levitte Programming; Spannvägen 38, I; S-161 43 Bromma; SWEDEN
Tel: +46-8-26 52 47; 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://www.lp.se/~levitte for my public key. bastard@bofh.se
================================================================================
Archive-Date: Thu, 10 Oct 1996 01:49:51 +0200
Sender: owner-free-vms@lp.se
Date: Wed, 9 Oct 1996 17:49:54 -0600
Message-ID: <9610092349.AA30942@snake.srv.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Free-VMS@lp.se
From: kth@srv.net (Kevin Handy)
Reply-To: Free-VMS@lp.se
Subject: Data Types
Before too much programming is done, some decision should be made
early about how to specify data types used in VMS structures,
if FreeVMS is going to run on machines other than Vax/Alpha.
For example: A structure that (on a vax) contains a 32 bit value
is specified as an "int" (thinking in C here). If the program
is moved to a 64 bit system, "int" changes to 64 bits.
Various structures, such as the length field in descriptors
(dsc$w_length) is defined as "unsigned short dsc$w_length"
(16 bits on VAX/VMS), but what will an "unsigned short"
be on a 64 bit system? It could be 32 or 16 bits depending
on the hardware and the compiler used.
Are we going to use a "standard" header file to define such
data types, (an int32 or some such) or should the type depend on the
hardware it is running on?
Floating point is another can of worms. VAX/VMS doesn't have IEEE
floating point hardware, Alpha/VMS does. How to handle programs when
they ask for G_FLOAT, D_FLOAT, H_FLOAT? Some VMS programs may expect
binary compatability with the floating point format. (printf in the
VMS C library maybe)
A data file created on one VMS system probibly should be readable
on another, unless we define different variations of FreeVMS
(FreeVMS/VAX, FreeVMS/Alpha, FreeVMS/Sun, FreeVMS/386, ...)
and not allow data compatability.
Also data structures may need to be passed between systems (networking,
clustering, data files ...) this will become a major problem if it is
not handled early in the design phase.
-------------------------------------------------------------
Kevin Handy kth@srv.ne Accounting Software for
Software Solutions. Inc. VAX/VMS Computer Systems
Idaho Falls, Idaho
================================================================================
Archive-Date: Thu, 10 Oct 1996 02:05:04 +0200
Sender: owner-free-vms@lp.se
Date: Wed, 9 Oct 1996 17:05:12 -0700 (PDT)
Message-ID: <2.2.16.19961009170353.0a370810@illyana.qualcomm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Free-VMS@lp.se
From: "Ryan A. Moore" <rmoore@qualcomm.com>
Reply-To: Free-VMS@lp.se
Subject: Re: Data Types
At 05:49 PM 10/9/96 -0600, Kevin Handy wrote:
>
> [data type, floating point stuff deleted]
>
>A data file created on one VMS system probibly should be readable
>on another, unless we define different variations of FreeVMS
>(FreeVMS/VAX, FreeVMS/Alpha, FreeVMS/Sun, FreeVMS/386, ...)
>and not allow data compatability.
>
>Also data structures may need to be passed between systems (networking,
>clustering, data files ...) this will become a major problem if it is
>not handled early in the design phase.
Also, you may also have to deal with big-endian/little-endian differences in
the same situtions.
-Ryan
+=====================================================================+
Ryan Moore (T-510R) Qualcomm, Inc. work:(619)658-2990
rmoore@qualcomm.com San Diego, CA home:(619)549-1634
+=====================================================================+
================================================================================
Archive-Date: Thu, 10 Oct 1996 02:43:40 +0200
Sender: owner-free-vms@lp.se
Message-ID: <c=US%a=_%p=msft%l=RED-70-MSG-961010001212Z-63205@mail2.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: Compatibility, DCL 4-character limitations, etc.
Date: Wed, 9 Oct 1996 17:12:12 -0700
>
>My thought was source compatibility down to the system routines and library
>routines (the calls to them, mind you, not the routines themselves :-)).
>This also means a level of functional compatibility. ASTs and Event Flags
>should respond or be usefull in the same way. This means, of course, that
>device driver designers, for example, will most probably have to work
>differently. But that's already the case when building device drivers for
>the Alpha, I've been told...
CK> But it isn't that simple :-). So, what about CTL$
CK> symbols. What about the P1 symbols that users
CK> can write to if they want to disable user-mode
CK> ASTs. Any what about supervisor mode. It is
CK> the "bastard child" of the modes in many ways.
CK> Not really kernel, not really user. Any thoughts
CK> on that? I presume MOVL addr,0(FP) to set
CK> an exception handler is right out, yes?
>
> CK> It is the bugs that become features that you need to worry about.
> CK> There are many "aspects" of VMS that we wanted to change, but people
> CK> had come to rely on them and treat them as features... hence we
> CK> were stuck.
>
>Care to give us a hint? This could be a way to make Free-VMS a "better VMS".
CK> Oh I don't know. How about the & is DCL. When
CK> we were doing pipes I really wanted to use that
CK> symbol, but we couldn't. Does anyone know more
CK> than one person who even knows what it does let
CK> alone uses it? How many apps really check the
CK> ODS level before assuming they know the on-disk
CK> structure or do they just assume that it is 2 or
CK> that if it isn't 1, it must be 2?
>
> CK> As well as having to re-write parts of DCL. It ain't gonna happen.
>
>I haven't looked at the source, but I've been told it's pretty ugly at
>places. Anyway, again, give us a hint, please?
CK> What I meant was that DCLs current code is written
CK> in such a way that it would require redesign to alter it
CK> and I suspect that it is not a priority for the team. It
CK> isn't an "afternoon fix"... that's all.
================================================================================
Archive-Date: Thu, 10 Oct 1996 06:19:49 +0200
Sender: owner-free-vms@lp.se
Date: Thu, 10 Oct 1996 06:19:41 MET DST
Message-ID: <12892.38269.405647v0.1b7.LEVITTE@devil.bofh.se>
From: Tony Konashenok <tonyk@sseos.lbl.gov>
Reply-To: Free-VMS@lp.se
To: free-vms@lp.se
Subject: RE: Compatibility, DCL 4-character limitations, etc.
$! May I remind everyone that the concensus has been since long that Free-VMS
$! should eventually be built on top of Mach. In that case especially, source
$! level compatibility is the way to go.
Actually, I meant to write about it in a few days, but I feel compelled to
react while it's still hot: we had some sort of consensus indeed, but was
it an INFORMED decision? After reading the paper about it, I had a strong
feeling that implementation was indeed a successful proof of concept, but
it left some important issues open, reliability and performance among them.
So, could anyone provide a compelling reason to write on top of Mach, other
than the fact that Mach already exists?
[Stay tuned for a longish attempt at the Free-VMS development specs]
Tony Konashenok
================================================================================
Archive-Date: Thu, 10 Oct 1996 06:31:16 +0200
Sender: owner-free-vms@lp.se
Date: Thu, 10 Oct 1996 06:31:12 MET DST
Message-ID: <12892.38960.405647v0.1b7.LEVITTE@devil.bofh.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: RE: Compatibility, DCL 4-character limitations, etc.
CK> Oh I don't know. How about the & is DCL. When
Does the same thing as ', but in the second pass. I know, "basically"...
Anyway, great for double indirection (or tripple, in some cases...).
I've seen it used in a whole bunch of scripts.
--
R Levitte, Levitte Programming; Spannvägen 38, I; S-161 43 Bromma; SWEDEN
Tel: +46-8-26 52 47; 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://www.lp.se/~levitte for my public key. bastard@bofh.se
================================================================================
Archive-Date: Thu, 10 Oct 1996 06:45:45 +0200
Sender: owner-free-vms@lp.se
Date: Thu, 10 Oct 1996 06:45:41 MET DST
Message-ID: <12892.39829.405647v0.1b7.LEVITTE@devil.bofh.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: RE: Compatibility, DCL 4-character limitations, etc.
So, could anyone provide a compelling reason to write on top of Mach, other
than the fact that Mach already exists?
Not really. I've taken a semi-close look at Mach recently (I have studied
Mach once upon a time, but that was a long time ago), and found that it
contains a bunch of features that could be very well applicable in a VMS
implementation. I guess that's the reason why the Emerald project was ever
started.
A real reason for picking Mach is that it is a pretty capable kernel that
is specifically created to allow as many kinds of systems to be built on
top of it. It does, to my understanding, come with a bunch of device
drivers, or alternativelly, such things are pretty easily found, and perhaps
only need some tweaking to be usefull.
The main issue here is how near the iron we want to hack. My thought with
building on top of Mach was that we would get a few things for free...
Otherwise, we'd have to either pick another kernel to build on (amoeba? :-))
or really build everything from scratch...
--
R Levitte, Levitte Programming; Spannvägen 38, I; S-161 43 Bromma; SWEDEN
Tel: +46-8-26 52 47; 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://www.lp.se/~levitte for my public key. bastard@bofh.se
================================================================================
Archive-Date: Thu, 10 Oct 1996 13:07:13 +0200
Sender: owner-free-vms@lp.se
Date: Thu, 10 Oct 1996 7:07:00 -0400 (EDT)
From: jhjennis2@mmm.com
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Message-ID: <961010070700.202c5cc3@mdw>
Subject: RE: Compatibility, DCL 4-character limitations, etc.
>$! May I remind everyone that the concensus has been since long that Free-VMS
>$! should eventually be built on top of Mach. In that case especially, source
>$! level compatibility is the way to go.
>So, could anyone provide a compelling reason to write on top of Mach, other
>than the fact that Mach already exists?
First, not being a Mach expert, perhaps I'm on very thin ice...however the objective in
developing Mach was to take nasty low level hardware architecture issues out of the
picture.....nice goal... and should make the code standard. I assume we would want FreeMS
to run transparently on just about any platform without having to "re-invent the wheel"
every time DEC, SUN, Intel, Motorola, HP comes up with some new CPU or architecture. There
has been a lot of good low level R&D done on mach at CMU (coincidently my alma mater - no
plug intended) and other places (DEC funded a lot of it)...so why not take advantage of
what the Mach research project generated, and spend the efforts of this team building a
much better mousetrap on the other end....just my $.02
Regards,
Jim Jennis, Systems & Network Mgr.
Imation Corp.
Printing & Publishing Systems Div.
Middleway, WV. USA.
Internet: jhjennis2@mmm.com
================================================================================
Archive-Date: Thu, 10 Oct 1996 13:59:16 +0200
Sender: owner-free-vms@lp.se
Date: Thu, 10 Oct 1996 20:59:15 JST
From: "Makoto Shimojima, Univ of Tsukuba/CDF" <mako@hep.px.tsukuba.ac.jp>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
CC: mako@hep.px.tsukuba.ac.jp
Message-ID: <009A9A76.5C3F4A5A.3@hep.px.tsukuba.ac.jp>
Subject: RE: Compatibility, DCL 4-character limitations, etc.
> I've taken a semi-close look at Mach recently (I have studied
> Mach once upon a time, but that was a long time ago), and found that it
> contains a bunch of features that could be very well applicable in a VMS
> implementation.
When you say "Mach" do you mean Mach3 developed at CMU, or Mach4 (flux)
developed at U of Utah? I understand they are both "mature" in that no
more development is taking place for either version...
mako
PS: Has anyone written an alternative command language interpreter for
OpenVMS? I think it is useful to have an interpreter template that
does nothing (perhaps echo back whatever you type... or something
like that). You could then add commands one by one.
================================================================================
Archive-Date: Thu, 10 Oct 1996 15:47:08 +0200
Sender: owner-free-vms@lp.se
Date: Thu, 10 Oct 1996 15:47:57 GMT1
From: tobiasz@delta.sggw.waw.pl
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Message-ID: <009A9A4A.DF4FD314.10@delta.sggw.waw.pl>
Subject: RE: Compatibility, DCL 4-character limitations, etc.
>
>Not really. I've taken a semi-close look at Mach recently (I have studied
>Mach once upon a time, but that was a long time ago), and found that it
>contains a bunch of features that could be very well applicable in a VMS
>implementation. I guess that's the reason why the Emerald project was ever
>started.
>
Is Mach kernel available for free ? Any pointers ? Would like to look at
it closer. Till now had impression it was not available for free.
Jacek Tobiasz
================================================================================
Archive-Date: Thu, 10 Oct 1996 15:56:28 +0200
Sender: owner-free-vms@lp.se
Date: Thu, 10 Oct 1996 09:56:29 -0400
From: leichter@smarts.com (Jerry Leichter)
Reply-To: Free-VMS@lp.se
Message-ID: <199610101356.JAA09687@just.smarts.com>
To: Free-VMS@lp.se
Subject: RE: Compatibility, DCL 4-character limitations, etc.
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
| [In response to my question about binary formats]
| May I remind everyone that the concensus has been since long that Free-VMS
| should eventually be built on top of Mach. In that case especially, source
| level compatibility is the way to go.
Actually, the questions are unrelated. Mach gives you enough control that you
can, if you design your server right, have it support any image file format it
cares to. I don't know what the Mach "native" format looks like, but I doubt
it's the same as the format used by the Unix servers that run on top of Mach!
Essentially, you never use the Mach "run an image" primitive - you point your
server at a file and tell *it* to "run" it, whatever that means. There's plenty
of precendent for this. Consider RSTS, for example - it doesn't have *any*
native executable file format. All it has is a native format for "Run Time
Systems", which are like Mach servers. (Well, Mach servers are sort of like
RSTS RTS's, which predate them by 15 years or so.) If your process is running
under the RSX RTS, it runs RSX-format tasks. If it's running under the RT11
RTS, it runs RT-11 format programs. If it's running under the TECO RTS, it runs
TECO macros! (Yes, really - "run a program" to the TECO RTS means "read the
file in and execute it as TECO commands.) Files are stamped with the RTS they
are to be run under, so if you try to get the RSX RTS to run an RT-11 image, it
first switches you to the RT-11 RTS.
VMS actually has minimal support for this - it's how the old RSX AME worked. (A
native RSX image can be run as if it were a VMS image. What actually happens is
that the RSX.EXE image is started, and it reads the RSX image and does what it
likes.)
The experimental Mach implementation of VMS done at DEC supported (a subset of)
native VMS binary images.
-- Jerry
================================================================================
Archive-Date: Thu, 10 Oct 1996 16:47:34 +0200
Sender: owner-free-vms@lp.se
Message-ID: <s25cc67a.025@bryan.org>
Date: Thu, 10 Oct 1996 09:48:41 -0500
From: Dale Lobb <DLobb@bryan.org>
Reply-To: Free-VMS@lp.se
To: JayPed@aol.com, Free-VMS@lp.se
Subject: Re: What has happened to the list?
After reading this and similar posts on the subject of
"What has happened to the list?", I believe that there is
a fundamental question that needs to be answered here: Are
we going to make a binary compatible version of OVMS or just
a look-alike, feel-alike version? I submit that the
intention is to produce a binary compatible operating system.
If such is true, then all operations that work under OVMS
had better work under FreeVMS. I also have a list of 'druthers'
concerning the operation of OVMS; however, supplanting the
capabilities of the base OS is the wrong approach, I think.
We would be better served by setting up an area to keep track
of these 'enhancement' ideas, and implementing them as options
later, after the base compatible OS is functional.
Just my opinion, but what does everyone else think?
====================================
Dale T. Lobb
Programmer Analyst
Bryan Memorial Hospital
DLobb@Bryan.Org
Personal Email: LordGeep@inetnebr.com
====================================
Received: from nic.lp.se by heimdall.bryan.org; (5.65v3.2/1.1.8.2/07Sep95-1110AM)
id AA02907; Wed, 9 Oct 1996 06:26:51 -0500
X-Listname: Mailing list for the Free-VMS development team <Free-VMS@lp.se>
Warnings-To: <>
Errors-To: owner-free-vms@lp.se
Sender: owner-free-vms@lp.se
Received: from emout07.mail.aol.com (emout07.mx.aol.com) by nic.lp.se (MX V4.2
VAX) with SMTP; Wed, 09 Oct 1996 18:58:42 +0200
Received: by emout07.mail.aol.com (8.6.12/8.6.12) id MAA26998 for
Free-VMS@lp.se; Wed, 9 Oct 1996 12:58:55 -0400
Date: Wed, 9 Oct 1996 12:58:55 -0400
From: JayPed@aol.com
Reply-To: Free-VMS@lp.se
Message-Id: <961009125854_1379612700@emout07.mail.aol.com>
To: Free-VMS@lp.se
Subject: Re: What has happened to the list?
In a message dated 96-10-09 04:00:05 EDT, you write:
<< You mean 'good source for information about structure of the command
tables'? It is probably true, but I'm wondering if we should use it.
Specifically, I would vote for dropping the '4 characters' rule - i.e.
make the DCL parser (and CLI$ routines) check the whole name, not just
first four characters. After all, even DEC announced that they are
going to drop this feature 'in some future release'. >>
I wasn't planning to copy the structure of DCLTABLES or anything like that.
I was planning to make a 'functionally equivalent' version of SET
COMMAND/OBJECT and CLI$GET_VALUE, CLI$PRESENT, CLI$DISPATCH.
It would be functionally equivalent supporting the same CLD language, with
parameters, positional qualifiers, alternate syntaxes (define syntax),
ambiguity checking (disallow), etc.
It would return the same named error codes CLI$_ABSENT, CLI$_PRESENT, etc.
Regarding that ... are we going to copy the error code values that VMS has?
Or will we just use the same names? Will CLI$_ABSENT have the exact same
value that it has on VMS ... or just the same name?
As far as the 4-character checking ... I think that is a run-time thing ... I
think the full names are stored in the DCLTABLES.
So ... I guess that is an important point to clear up ... do we insist on
following that VMS convention?
LOGOT == LOGOFF == LOGO == LOGOUT ???
I suppose we would break existing command files if we don't follow that
convention.
To me ... LOGOT and LOGOFF are not the same as LOGOUT and should result in a
syntax error. Whereas LOGO and LOGOU are the same as LOGOUT as long as they
are unambiguous substrings. (That is ... there is no LOGON command which
would make LOGO ambiguous). I always thought it was kind of humorous that
VMS allowed things like LOGOT to do a LOGOUT ... but not very useful.
This leads to other confusing things in DCL ... there were people who thought
there was a f$getspi function .... because they could do
$ cputime = f$getspi("CPU")
As it turned out ... this was actually doing an f$getsyi and not f$getspi.
Do we want to implement that same functionality?
I would rather see syntax errors generated in these cases ... and people
depending on this bad behaviour be darned ... or something.
-Jay Pedersen
================================================================================
Archive-Date: Thu, 10 Oct 1996 18:04:11 +0200
Sender: owner-free-vms@lp.se
Message-ID: <s25ccece.028@bryan.org>
Date: Thu, 10 Oct 1996 10:23:45 -0500
From: Dale Lobb <DLobb@bryan.org>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
CC: JayPed@aol.com
Subject: Re: What has happened to the list?
Well.... this is one of the few times that I will
respond to my own post. Now that I have read the
rest of the posts from yesterday. I am willing to
admit that I went off half-cocked. I think that
what we really need is source level compatibility
in the Free-VMS OS, but binary compatibility for
exchange of data. Data files created under
OpenVMS have got to be readable natively in
FreeVMS. Also, I like the idea of some sort of
switch to turn on/off extended functionality that
replaces stuff that works in OpenVMS. The default
should be to work as OVMS.
====================================
Dale T. Lobb
Programmer Analyst
Bryan Memorial Hospital
DLobb@Bryan.Org
Personal Email: LordGeep@inetnebr.com
====================================
================================================================================
Archive-Date: Thu, 10 Oct 1996 18:20:44 +0200
Sender: owner-free-vms@lp.se
Date: Thu, 10 Oct 1996 18:20:41 MET DST
Message-ID: <12893.15993.405647v0.1b7.LEVITTE@devil.bofh.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
CC: mako@hep.px.tsukuba.ac.jp
Subject: RE: Compatibility, DCL 4-character limitations, etc.
From: "Makoto Shimojima, Univ of Tsukuba/CDF" <mako@hep.px.tsukuba.ac.jp>
When you say "Mach" do you mean Mach3 developed at CMU, or Mach4 (flux)
I've looked at Mach3 so far. I must confess I -- uh -- didn't know Mach4
was as different as you seem to indicate...
PS: Has anyone written an alternative command language interpreter for
OpenVMS? I think it is useful to have an interpreter template that
does nothing (perhaps echo back whatever you type... or something
like that). You could then add commands one by one.
I think a friend of mine made a real simple thing not too long ago. It just
takes one line, a file name to an executable image, and launches it. Hmm,
now that I've looked, he's on this list.
Stellan?
--
R Levitte, Levitte Programming; Spannvägen 38, I; S-161 43 Bromma; SWEDEN
Tel: +46-8-26 52 47; 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://www.lp.se/~levitte for my public key. bastard@bofh.se
================================================================================
Archive-Date: Thu, 10 Oct 1996 18:30:31 +0200
Sender: owner-free-vms@lp.se
Date: Thu, 10 Oct 1996 12:30:43 -0400
From: JayPed@aol.com
Reply-To: Free-VMS@lp.se
Message-ID: <961010123042_330484860@emout13.mail.aol.com>
To: Free-VMS@lp.se
Subject: Re: Compatibility, DCL 4-character limitations, etc.
In a message dated 96-10-09 21:39:54 EDT, you write:
<< CK> But it isn't that simple :-). So, what about CTL$
CK> symbols. What about the P1 symbols that users
CK> can write to if they want to disable user-mode
CK> ASTs. Any what about supervisor mode. It is
CK> the "bastard child" of the modes in many ways.
CK> Not really kernel, not really user. Any thoughts
CK> on that? I presume MOVL addr,0(FP) to set
CK> an exception handler is right out, yes?
>>
I think this gets back to what level of compatibility are we striving for.
All the CTL$ symbols are undocumented and unsupported from DEC (well maybe
documented in the internals and data structures book :-).
Will we support a MACRO32 cross-assembler? I don't think MOVL addr, 0(FP)
comes into play without cross-assemblers. There is quite a bit of MACRO32
code around ... is there any thought about building a cross-assembler?
I think there should be support for the lib$ calls which set/clear the
exception handler (lib$establish and lib$revert I believe).
-Jay Pedersen
================================================================================
Archive-Date: Thu, 10 Oct 1996 18:38:28 +0200
Sender: owner-free-vms@lp.se
Date: Thu, 10 Oct 1996 18:38:25 MET DST
Message-ID: <12893.17057.405647v0.1b7.LEVITTE@devil.bofh.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: RE: Compatibility, DCL 4-character limitations, etc.
From: tobiasz@delta.sggw.waw.pl
Is Mach kernel available for free ? Any pointers ? Would like to look at
it closer. Till now had impression it was not available for free.
It's the kernel used by the GNU hurd, so it's as free as it can get.
--
R Levitte, Levitte Programming; Spannvägen 38, I; S-161 43 Bromma; SWEDEN
Tel: +46-8-26 52 47; 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://www.lp.se/~levitte for my public key. bastard@bofh.se
================================================================================
Archive-Date: Thu, 10 Oct 1996 18:42:29 +0200
Sender: owner-free-vms@lp.se
Date: Thu, 10 Oct 1996 18:42:22 MET DST
Message-ID: <12893.17294.405647v0.1b7.LEVITTE@devil.bofh.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: RE: Compatibility, DCL 4-c