This is G o o g l e's cache of http://www.lp.se/ftp/mailinglists/FREE-VMS.1999-01.
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: Sat, 2 Jan 1999 12:59:16 +0100
From: Cenobite <cenobite@the.satanic.org>
Reply-To: Free-VMS@lp.se
Message-ID: <199901020227.SAA27578@the.satanic.org>
Subject: Re: Why don't we just start?
To: Free-VMS@lp.se
Date: Fri, 1 Jan 1999 18:27:11 -0800 (PST)
In-Reply-To: <3.0.3.16.19981225185133.4857174a@earthlink.net> from "David J. Dachtera" at Dec 25, 98 06:51:33 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
> In order to understand how to begin building, you must first read the
> blueprint - difficult to do when none exists.
Hey, whoa! That's just not true! VMS is one of the *best* documented systems
available today. Our blueprint is "VAX/VMS Internals and Data Structures."
We don't really need a wacky prebuilt kernel like Mach or OSkit.
- hbm
================================================================================
Archive-Date: Mon, 4 Jan 1999 17:59:37 +0100
MIME-Version: 1.0
Date: Mon, 4 Jan 1999 12:43:57 -0600
Message-ID: <0002E69F.C21492@advocatehealth.com>
From: David.Dachtera@advocatehealth.com (David Dachtera)
Reply-To: Free-VMS@lp.se
Subject: Re[2]: Why don't we just start?
To: Free-VMS@lp.se
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Um, well...
How much of "VAX/VMS Internals and Data Structures" would
apply to the Mach kernel? ...to Motorola 680x0? ...to
Intel x86? ...to the Alpha CPU? (Hint: Alpha requires
EXTENSIVE help from firmware ("PAL code") to provide even
equivalent function to VMS's native VAX CPU.)
I'll let Richard speak for himself. However, I can say
that the reason for building FVMS on Mach is PORTABILITY,
especially to Intel/x86.
David J. Dachtera
dba DJE Systems
http://home.earthlink.net/~djesys/
______________________________ Reply Separator _________________________________
Subject: Re: Why don't we just start?
Author: Free-VMS@lp.se at PO_EXTERNET
Date: 1/1/99 8:27 PM
> In order to understand how to begin building, you must first read the
> blueprint - difficult to do when none exists.
Hey, whoa! That's just not true! VMS is one of the *best* documented systems
available today. Our blueprint is "VAX/VMS Internals and Data Structures."
We don't really need a wacky prebuilt kernel like Mach or OSkit.
- hbm
================================================================================
Archive-Date: Tue, 5 Jan 1999 14:17:54 +0100
Message-ID: <3.0.3.16.19981229082056.2c17535a@earthlink.net>
Date: Tue, 29 Dec 1998 08:20:56
To: Free-VMS@lp.se
From: "David J. Dachtera" <djesys@earthlink.net>
Reply-To: Free-VMS@lp.se
Subject: Re: Why don't we just start?
In-Reply-To: <LEVITTE.98Dec29010304@nic.bofh.se>
References: <"David J. Dachtera"'s message of Sat, 26 Dec 1998 20:48:33> <3.0.3.16.19981226204833.1b57e43a@earthlink.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Folks,
I'd just like to again suggest that these programs be developed using Gnu-C
(GCC) on a "real" VMS system so that when FVMS is ready, the source code
for them is here, debugged and ready to compile and link.
If anyone is put off by the size or complexity of the program list at
http://home.earthlink.net/~djesys/vms/freevms/proglist.txt - don't let it
bother you.
Just start simple. For example:
$ CREATE
The CREATE command (no /DIRECTORY or /FDL) is fairly simple: open a
sequential variable file on stdout; then, open SYS$INPUT (stdin) and read
until EOF writing each input record to the output file. The /DIRECTORY and
/FDL routines can be added later.
$ DIFFERENCES
Not as simple as it seems, but the hard part is the part beyond the RMS
interface - just open the files, read them and ...
$ COPY and $ APPEND
This one must use the input file FAB, etc. structures to create the output
file. The APPEND verb tells COPY.EXE to compare the file attributes and
report differences, but to do the append regardless. For these two
commands, the RMS interface is hairier than the rest of the "mechanics".
Beyond opening the files, it's just a simple I/O program.
$ RENAME
Check the doc.'s. Shouldn't be hard, but remember that these commands
(RENAME, COPY, APPEND) need to handle wildcard filespec.'s.
$ DUMP
Handy item - must have. The "hard" part is formatting the human-readable
output.
Just some ideas about where to start. These are fairly simple compared to
the other tasks that lie ahead.
Don't sweat stuff like ANALYZE, LINK or MACRO right now. There'll be time
for that later. Maybe someone could add a CLI$ interface to GAS and that
could suffice as an assembler for now (and maybe not).
Richard and others have committed to hacking the kernel.
However, we need some SERIOUS work in the RTL (System Services, Utility
Routines). We'll need this to make things happen once a kernel is running.
So, folks, what ya gonna do?
David J. Dachtera
dba DJE Systems
================================================================================
Archive-Date: Tue, 5 Jan 1999 16:58:00 +0100
Date: Tue, 05 Jan 1999 10:54:47 -0500 (EST)
Message-ID: <99010510544704@star.zko.dec.com>
From: parke@star.zko.dec.com (Pati die.)
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: Why don't we just start?
I guess one question, in re: the short list, is what do you do about the "DCL"
harness for the ndw commands.
If you are working on a "real" VMS System, you can write the command
definitions, but are you also thinking of a temporary U*X/L*X development
environment for those with harder access to a "real" VMS machine.
Also you need to consider (for more advanced commands) the implications
of the differences between FVMS and "VMS" as there will be differences.
Bill Parke
COMPAQ Computer Corp. But speaking for myself
================================================================================
Archive-Date: Tue, 5 Jan 1999 17:51:49 +0100
Date: Tue, 05 Jan 1999 11:49:44 -0500 (EST)
From: Chris Thompson RCL Montreal Neuro <CHRIS@rclvax.medcor.mcgill.ca>
Reply-To: Free-VMS@lp.se
Subject: Re: Why don't we just start?
To: Free-VMS@lp.se
Message-ID: <01J66I8XWP1E91WHWP@medcor.mcgill.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
The messages in the last few days make it sound as though Free-VMS is just
a small step away.
To me the thing that distinguishes VMS files most from any other
system (apart from RSX-11) is the concept of version numbers. Perhaps everyone
else has a way of remembering what a file was called last Friday, or perhaps
everyone else is so sure that the NEW version is so much better than the OLD
one that a simple save-and-overwrite-the-last-file-without-even-asking is
quite acceptable. To me version numbers are very important in the development of new programs, and updating documents.
Chris Thompson.
================================================================================
Archive-Date: Tue, 5 Jan 1999 22:02:43 +0100
MIME-Version: 1.0
Date: Tue, 5 Jan 1999 16:36:19 -0600
Message-ID: <0002FAA8.C21492@advocatehealth.com>
From: David.Dachtera@advocatehealth.com (David Dachtera)
Reply-To: Free-VMS@lp.se
Subject: Re[2]: Why don't we just start?
To: Free-VMS@lp.se
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Well, part of the reason why I suggested starting with
some basic command programs is to minimize the impact of
of the differences between OVMS and FVMS in its initial
incarnation. Also, one of the main goals is to provide a
high degree of source code compatibility between OVMS and
FVMS. A program which compiles/links/runs on OVMS should
compile/link/run on FVMS with few, if any, changes.
Most of the SET commands, for example, are tightly
integrated with the kernel and the internal data
structures of the o.s. So, until there's something
concrete in that arena, we'll need to keep busy with the
more "peripheral" issues such as the "simple" command
programs.
I'm not sure what you might mean by "'DCL' harness". If
you mean the CLI interface, just refer to the CLI section
of the OpenVMS Utility Routines manual. Remember, if it
compiles/links/runs on OVMS, it should compile/link/run on
FVMS with few, if any, changes.
That "link" phase is probably to most foreign concept
for UN*X folks, since compiled output is generally
executable without further linkage editing. On UN*X, the
concept of a "link" is more akin to a "file alias" in
OpenVMS. For anyone familiar with IBM mainframe o.s.-es,
LNKEDT = The LINKer. You usually LINK compiled programs
on DOS and Windows to make .OBJ files into executables.
Just cook up the source code for now. Get the programs
running on "real" VMS. We'll deal with compatibility
issues as they arise.
As to Chris Thompson's issues, yes: full ODS-2 and RMS
support is another primary goal of the project.
Otherwise, a simple DCL emulator on (any o.s.) would
suffice.
David J. Dachtera
dba DJE Systems
http://home.earthlink.net/~djesys/
______________________________ Reply Separator _________________________________
Subject: Re: Why don't we just start?
Author: Free-VMS@lp.se at PO_EXTERNET
Date: 1/5/99 9:54 AM
I guess one question, in re: the short list, is what do you do about the "DCL"
harness for the ndw commands.
If you are working on a "real" VMS System, you can write the command
definitions, but are you also thinking of a temporary U*X/L*X development
environment for those with harder access to a "real" VMS machine.
Also you need to consider (for more advanced commands) the implications
of the differences between FVMS and "VMS" as there will be differences.
Bill Parke
COMPAQ Computer Corp. But speaking for myself
================================================================================
Archive-Date: Tue, 5 Jan 1999 23:28:37 +0100
Message-ID: <369274D0.85436F1@srv.net>
Date: Tue, 05 Jan 1999 13:23:44 -0700
From: Kevin Handy <kth@srv.net>
Reply-To: Free-VMS@lp.se
MIME-Version: 1.0
To: Free-VMS@lp.se
Subject: Re: Why don't we just start?
References: <01J66I8XWP1E91WHWP@medcor.mcgill.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Chris Thompson RCL Montreal Neuro wrote:
>
> The messages in the last few days make it sound as though Free-VMS is just
> a small step away.
> To me the thing that distinguishes VMS files most from any other
> system (apart from RSX-11) is the concept of version numbers. Perhaps everyone
> else has a way of remembering what a file was called last Friday, or perhaps
> everyone else is so sure that the NEW version is so much better than the OLD
> one that a simple save-and-overwrite-the-last-file-without-even-asking is
> quite acceptable. To me version numbers are very important in the development of new programs, and updating documents.
> Chris Thompson.
[assuming you're talking about the thread on using the Linux
kernal as the FreeVMS kernel]
Most Unix file systems will allow semi-colons in file names,
so emulating the version numbers on a Unix system would not
be extremely hard. It could be handled by the interface functions,
through some type of loop-back file system, or by a whole new file
system.
I miss the version numbers when I work in other OS's, but if a
loop-back file system were developed with version numbers you'd
gain their useage even under Linux shells.
[I'm defining this loop-back as a file system on top of another
file system, or set of programs. I believe this is how they
impliment the /proc file system]
================================================================================
Archive-Date: Wed, 6 Jan 1999 01:53:56 +0100
Date: Tue, 5 Jan 1999 18:53:50 -0600
From: John Goerzen <jgoerzen@complete.org>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: Why don't we just start?
Message-ID: <19990105185350.A233@complete.org>
References: <01J66I8XWP1E91WHWP@medcor.mcgill.ca> <369274D0.85436F1@srv.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <369274D0.85436F1@srv.net>; from Kevin Handy on Tue, Jan 05, 1999 at 01:23:44PM -0700
On Tue, Jan 05, 1999 at 01:23:44PM -0700, Kevin Handy wrote:
> Most Unix file systems will allow semi-colons in file names,
Indeed, I believe POSIX mandates it.
> [I'm defining this loop-back as a file system on top of another
> file system, or set of programs. I believe this is how they
> impliment the /proc file system]
Well something is confused somewhere then :-)
In Linux, a loop filesystem is basically a filesystem in a file. For
instance, a common use is for people that burn CDs; they'd have a 650 MB ISO
filesystem image stored as a file someplace. Using the loopback driver, it
can be mounted as a real filesystem; ie:
mount -t iso9660 -o loop,ro ~/mynewcd.iso /mnt
In this sense, loopback is not a filesystem in itself but rather a driver
that enables filesystems to be layered.
/proc, on the other hand, is a separate filesystem. It is only unique in
that the "files" are provided "virtually" by the kernel; no real device or
file is accessed, just kernel data structures.
John
================================================================================
Archive-Date: Wed, 6 Jan 1999 02:04:13 +0100
Date: Tue, 5 Jan 1999 18:03:31 -0500 (EST)
From: Noah Paul <noahp@altavista.net>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: (David Dachtera) Re[2]: Why don't we just start?
Message-ID: <Pine.LNX.3.96.990105180138.10032C-100000@merlin>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Long Threads:
Perhaps from now on, when replying to a long thread, we should include
the sender-who-were-replying-to's name in the Subject line? This makes
things a lot less confusing. Like I did above:
Re: (David Dachtera) Re[2]: Why don't we just start?
On Internals & Data Structures:
I have a copy of _VAX/VMS_Internals_and_Data_Structures_, and while I have
not read it extensively (too complicated for me, I don't know enough VMS),
It seems to have a *lot* of stuff assuming VAXish CPU protection
(4-level, is it?) and VAX assembly language. However, it has a bit of
general stuff ... I also have a book about VAX Architecture ... my old
man used to work for DEC.
On Mach:
I think that Mach's a bit too complicated. I am in favor of doing a small
bootstrap which can be fitted to many platforms and portable C code from
then on. We could do emulation of protection, etc. which isn't hardware
dependant. We should start with Intel (much-supported) and the move on
(Linux did this, with various unofficial (mostly) offshoots -- PowerPC,
Alpha, m68k, mips, SPARC -- which were later incorported into the kernel).
On My Personal Troubles:
I'm having some *major* problems with connectivity to the Internet, so for
a few weeks I'll only be able to correspond with anyone about 1 day per
week. Hopefully this will get resolved soon, I have some content I want
to serve ...
-------------
Regards,
Noah Paul <noahp@altavista.net>
PGP Public Key: http://gandolf.lincnet.org/~noahp/Public_Key
On Mon, 4 Jan 1999, David Dachtera wrote:
> Um, well...
>
> How much of "VAX/VMS Internals and Data Structures" would
> apply to the Mach kernel? ...to Motorola 680x0? ...to
> Intel x86? ...to the Alpha CPU? (Hint: Alpha requires
> EXTENSIVE help from firmware ("PAL code") to provide even
> equivalent function to VMS's native VAX CPU.)
>
> I'll let Richard speak for himself. However, I can say
> that the reason for building FVMS on Mach is PORTABILITY,
> especially to Intel/x86.
>
> David J. Dachtera
> dba DJE Systems
> http://home.earthlink.net/~djesys/
>
>
> ______________________________ Reply Separator _________________________________
> Subject: Re: Why don't we just start?
> Author: Free-VMS@lp.se at PO_EXTERNET
> Date: 1/1/99 8:27 PM
>
>
>
> > In order to understand how to begin building, you must first read the
> > blueprint - difficult to do when none exists.
>
> Hey, whoa! That's just not true! VMS is one of the *best* documented systems
> available today. Our blueprint is "VAX/VMS Internals and Data Structures."
> We don't really need a wacky prebuilt kernel like Mach or OSkit.
> - hbm
>
>
>
================================================================================
Archive-Date: Wed, 6 Jan 1999 02:06:51 +0100
Date: Tue, 5 Jan 1999 18:06:12 -0500 (EST)
From: Noah Paul <noahp@altavista.net>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: Why don't we just start?
In-Reply-To: <369274D0.85436F1@srv.net>
Message-ID: <Pine.LNX.3.96.990105180345.10032D-100000@merlin>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
This emulation of version numbers thing has been implemented, at least
with GNU tools, like this:
foo File "foo", hmm?
foo~ Backup of file "foo"
foo~1 1st version of file "foo"
This could be easily implemented as a UMSDOS/FAT32-like addon
to {your favorite non-RMS file system}, with ~ being any character
you desire ... ; would make the most sense.
--------------
Regards,
Noah Paul <noahp@altavista.net>
PGP Public Key: http://gandolf.lincnet.org/~noahp/Public_Key
On Tue, 5 Jan 1999, Kevin Handy wrote:
> Chris Thompson RCL Montreal Neuro wrote:
> >
> > The messages in the last few days make it sound as though Free-VMS is just
> > a small step away.
> > To me the thing that distinguishes VMS files most from any other
> > system (apart from RSX-11) is the concept of version numbers. Perhaps everyone
> > else has a way of remembering what a file was called last Friday, or perhaps
> > everyone else is so sure that the NEW version is so much better than the OLD
> > one that a simple save-and-overwrite-the-last-file-without-even-asking is
> > quite acceptable. To me version numbers are very important in the development of new programs, and updating documents.
> > Chris Thompson.
>
> [assuming you're talking about the thread on using the Linux
> kernal as the FreeVMS kernel]
>
> Most Unix file systems will allow semi-colons in file names,
> so emulating the version numbers on a Unix system would not
> be extremely hard. It could be handled by the interface functions,
> through some type of loop-back file system, or by a whole new file
> system.
>
> I miss the version numbers when I work in other OS's, but if a
> loop-back file system were developed with version numbers you'd
> gain their useage even under Linux shells.
>
> [I'm defining this loop-back as a file system on top of another
> file system, or set of programs. I believe this is how they
> impliment the /proc file system]
>
================================================================================
Archive-Date: Wed, 6 Jan 1999 02:58:26 +0100
Date: Tue, 5 Jan 1999 18:57:22 -0500 (EST)
From: Noah Paul <noahp@altavista.net>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: vmsopt - Library for Parsing Arguments
Message-ID: <Pine.LNX.3.96.990105184230.10067A-100000@merlin>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
*Clarification* In this library, an "argument" is the thing following a
colon, and an option is the thing following the slash.
vmsopt is a library for parsing a program's options in VMS style
to a program:
PROGRAM /OPTION /OPTION:ARGUMENT
I uploaded a zip file to:
http://www.ultranet.com/~noahp/vmsopt.zip
(or, by ftp:)
ftp://www.ultranet.com/~noahp/public_html/vmsopt.zip
(Did we agree on .ZIP as the archive format OSLA?)
(Richard: can you put this up on the free-vms.org ftp site?)
It's used like this:
while( (n = vmsopt_parse( argc, argv ) ) != -1 )
{
if( n == 2 )
{
/** option with argument, option is
stored in optstr, argument is stored
in optarg **/
}
else
{
/** just option, stored in optstr **/
}
}
Hope it's useful.
--------------
Regards,
Noah Paul <noahp@altavista.net>
PGP Public Key: http://gandolf.lincnet.org/~noahp/Public_Key
================================================================================
Archive-Date: Wed, 6 Jan 1999 03:47:39 +0100
Message-ID: <3.0.3.16.19990105205804.3a7f1b72@earthlink.net>
Date: Tue, 05 Jan 1999 20:58:04
To: Free-VMS@lp.se
From: "David J. Dachtera" <djesys@earthlink.net>
Reply-To: Free-VMS@lp.se
Subject: Re: Responses (was Re: (David Dachtera) Re[2]: Why don't we just start?)
In-Reply-To: <Pine.LNX.3.96.990105180138.10032C-100000@merlin>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 06:03 PM 1/5/99 -0500, Noah Paul wrote:
>On Long Threads:
>
>Perhaps from now on, when replying to a long thread, we should include
>the sender-who-were-replying-to's name in the Subject line? This makes
>things a lot less confusing. Like I did above:
>
> Re: (David Dachtera) Re[2]: Why don't we just start?
Well, at work I'm stuck with Lotus's cc:Mail which does not display the
author of the message (only the "Free-VMS@lp.se" address), nor the complete
internet mail headers. So, I don't always know who wrote the message I'm
responding to.
I had actually suggested earlier on that everyone use a signature file
where their e-mail user agent supports that functionality. Here at home I
have Eudora Pro V3.0.3 and for this message (only) I'm using the signature
file that I use on comp.os.vms, just as an example. By using a signature
file, it is easier (and more automatic) to find out who wrote what. Not all
user agents support this, however.
-------------------------------------------------------------------------
David J. Dachtera For a VMS licensing idea that
dba DJE Systems does for small/home biz what the
http://home.earthlink.net/~djesys/ hobby license does for VMS
hackers, see
http://home.earthlink.net/~djesys/soholic.txt
If you agree, e-mail Compaq and
voice your support!
================================================================================
Archive-Date: Wed, 6 Jan 1999 03:47:44 +0100
Message-ID: <3.0.3.16.19990105205611.3a7f583c@earthlink.net>
Date: Tue, 05 Jan 1999 20:56:11
To: Free-VMS@lp.se
From: "David J. Dachtera" <djesys@earthlink.net>
Reply-To: Free-VMS@lp.se
Subject: Re: Why don't we just start?
In-Reply-To: <Pine.LNX.3.96.990105180345.10032D-100000@merlin>
References: <369274D0.85436F1@srv.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 06:06 PM 1/5/99 -0500, Noah Paul wrote:
>This emulation of version numbers thing has been implemented, at least
>with GNU tools, like this:
>
> foo File "foo", hmm?
> foo~ Backup of file "foo"
> foo~1 1st version of file "foo"
>
>This could be easily implemented as a UMSDOS/FAT32-like addon
>to {your favorite non-RMS file system}, with ~ being any character
>you desire ... ; would make the most sense.
An important point to remember is that on OpenVMS, filetype extensions
*ARE* significant. The image activator seeks .EXE files by default. The "@"
operator in DCL seeks .COM files by default. LIBRARY/OBJECT seeks .OLB/.OBJ
files by default. LIBRARY/TEXT seeks .TLB/.TXT files by default. Etc., ...
Also, as was pointed out to me by someone in another thread, the ";"
character *IS* significant to certain UN*X shells, and must be either
quoted or escaped in such case.
David J. Dachtera
dba DJE Systems
http://home.earthlink.net/~djesys/
================================================================================
Archive-Date: Wed, 6 Jan 1999 18:15:06 +0100
MIME-Version: 1.0
Date: Wed, 6 Jan 1999 10:23:18 -0600
Message-ID: <0003023E.C21492@advocatehealth.com>
From: David.Dachtera@advocatehealth.com (David Dachtera)
Reply-To: Free-VMS@lp.se
Subject: Re: vmsopt - Library for Parsing Arguments
To: Free-VMS@lp.se
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
>PROGRAM /OPTION /OPTION:ARGUMENT
In DCL, the terminology is usually stated as:
verb[/qualifier[=value]]
or where a list of values is allowed:
verb[/qualifier[=(value[,value]]]
or where a list of keywords/values is allowed:
verb[/qualifier[=(keyword[=value][,keyword[=value]])]
DCL will, in most cases accept a colon (":") as well as
an equal sign ("="). I may have missed a "]" in the
above, also. (For those who may be wondering, optional
items are usually shown inside square brackets ("[]").
One of the most complex common commands I'm aware of
looks like this:
DIRECTORY/SELECT=SIZE=(MINIMUM=1000,MAXIMUM=1000000)
See the Utility Routines manual for a discussion of the
CLI$ routines. See the on-line help for the DIRECTORY
command for a brief discussion of the valid qualifiers,
keywords and values for this verb.
David J. Dachtera
dba DJE Systems
http://home.earthlink.net/~djesys/
______________________________ Reply Separator _________________________________
Subject: vmsopt - Library for Parsing Arguments
Author: Free-VMS@lp.se at PO_EXTERNET
Date: 1/5/99 5:57 PM
*Clarification* In this library, an "argument" is the thing following a
colon, and an option is the thing following the slash.
vmsopt is a library for parsing a program's options in VMS style
to a program:
PROGRAM /OPTION /OPTION:ARGUMENT
I uploaded a zip file to:
http://www.ultranet.com/~noahp/vmsopt.zip
(or, by ftp:)
ftp://www.ultranet.com/~noahp/public_html/vmsopt.zip
(Did we agree on .ZIP as the archive format OSLA?)
(Richard: can you put this up on the free-vms.org ftp site?)
It's used like this:
while( (n = vmsopt_parse( argc, argv ) ) != -1 )
{
if( n == 2 )
{
/** option with argument, option is
stored in optstr, argument is stored
in optarg **/
}
else
{
/** just option, stored in optstr **/
}
}
Hope it's useful.
--------------
Regards,
Noah Paul <noahp@altavista.net>
PGP Public Key: http://gandolf.lincnet.org/~noahp/Public_Key
================================================================================
Archive-Date: Wed, 6 Jan 1999 18:15:27 +0100
MIME-Version: 1.0
Date: Wed, 6 Jan 1999 10:25:48 -0600
Message-ID: <00030240.C21492@advocatehealth.com>
From: David.Dachtera@advocatehealth.com (David Dachtera)
Reply-To: Free-VMS@lp.se
Subject: Re: vmsopt - Library for Parsing Arguments
To: Free-VMS@lp.se
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
CORRECTED MESSAGE:
>PROGRAM /OPTION /OPTION:ARGUMENT
In DCL, the terminology is usually stated as:
verb[/qualifier[=value]]
or where a list of values is allowed:
verb[/qualifier[=(value[,value]])]
or where a list of keywords/values is allowed:
verb[/qualifier[=(keyword[=value][,keyword[=value]])]
DCL will, in most cases accept a colon (":") as well as
an equal sign ("="). I may have missed a "]" in the
above, also. (For those who may be wondering, optional
items are usually shown inside square brackets ("[]").
One of the most complex common commands I'm aware of
looks like this:
DIRECTORY/SELECT=SIZE=(MINIMUM=1000,MAXIMUM=1000000)
See the Utility Routines manual for a discussion of the
CLI$ routines. See the on-line help for the DIRECTORY
command for a brief discussion of the valid qualifiers,
keywords and values for this verb.
David J. Dachtera
dba DJE Systems
http://home.earthlink.net/~djesys/
______________________________ Reply Separator _________________________________
Subject: vmsopt - Library for Parsing Arguments
Author: Free-VMS@lp.se at PO_EXTERNET
Date: 1/5/99 5:57 PM
*Clarification* In this library, an "argument" is the thing following a
colon, and an option is the thing following the slash.
vmsopt is a library for parsing a program's options in VMS style
to a program:
PROGRAM /OPTION /OPTION:ARGUMENT
I uploaded a zip file to:
http://www.ultranet.com/~noahp/vmsopt.zip
(or, by ftp:)
ftp://www.ultranet.com/~noahp/public_html/vmsopt.zip
(Did we agree on .ZIP as the archive format OSLA?)
(Richard: can you put this up on the free-vms.org ftp site?)
It's used like this:
while( (n = vmsopt_parse( argc, argv ) ) != -1 )
{
if( n == 2 )
{
/** option with argument, option is
stored in optstr, argument is stored
in optarg **/
}
else
{
/** just option, stored in optstr **/
}
}
Hope it's useful.
--------------
Regards,
Noah Paul <noahp@altavista.net>
PGP Public Key: http://gandolf.lincnet.org/~noahp/Public_Key
================================================================================
Archive-Date: Wed, 6 Jan 1999 18:19:20 +0100
Date: Wed, 6 Jan 1999 09:43:02 -0500 (EST)
From: Jerrold Leichter <leichter@smarts.com>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: Why don't we just start?
In-Reply-To: <Pine.LNX.3.96.990105180345.10032D-100000@merlin>
Message-ID: <Pine.GSO.4.02A.9901060915130.15308-100000@just>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
| This emulation of version numbers thing has been implemented, at least
| with GNU tools, like this:
|
| foo File "foo", hmm?
| foo~ Backup of file "foo"
This is the syntax used when you *haven't* enabled versioning.
| foo~1 1st version of file "foo"
Actually, it would be foo.~1~.
This versioning scheme is implemented by Emacs and by the Gnu file utilities
like cp and mv. To enable it in Emacs:
(setq version-control 't)
(setq vc-make-backup-files 't) To also enable it for CVS files
(setq kept-new-versions <n>) How many versions to keep (like
SET FILE/VERSION_LIMIT=<n>)
(setq kept-old-versions <n>) How many of the oldest versions to
keep when creating a new version
(no VMS analogue)
(setq delete-old-versions nil) Controls whether Emacs deletes
excessive old versions. nil
means it asks for confirmation.
To enable it for all Gnu utilities that support it:
export VERSION_CONTROL=numbered
Most Gnu utilities also have a -V or --version-control switch to control
things on a case-by-case basis.
Since I started using these, I've found life on Unix much more pleasant. It's
*not* as good as real versioning supported in the file system, however,
because it doesn't apply to arbitrary programs, only to those that choose to
implement it. (Note the comparison to line editting - available in the
terminal driver - thus to all programs, at least for one remember line - on
VMS, but only in a Gnu library that programs may or may not use on Unix.)
One Gnu program that unfortunately does *not* use versioning is Bash. It
would be really, really nice if redirected output could be set to create a new
version. I've been meaning to find the time to add that to bash for a couple
of years now....
I *have* built a modified ls (based on Mark Baranowski's els) that sorts
multiple versions of files in the right order (i.e., interpreting the version
numbers of *numbers*, so that 10 is after 9). I've also got some simple,
limited definitions for things like purge and a wrapper around diff that,
like VMS DIFFERENCES, if invoked with a single file name, will compare that
file with its previous version. I even have the Unix equivalent of a handy
VMS command file I've had for years which shows you all files with multiple
versions. If anyone wants, I can make these available.
| This could be easily implemented as a UMSDOS/FAT32-like addon
| to {your favorite non-RMS file system}, with ~ being any character
| you desire ... ; would make the most sense.
Note that getting true VMS semantics is a bit trickier, since a file should be
accessible under a couple of different names - e.g., for the most recent
version, all of: foo.foo or foo.foo; or foo.foo;0 or foo.foo;<n> should work.
Only some of this is done by file name parsing's default substitution - some
is hard-wired into the XQP. Other file system interfaces don't support the
notion of a file having multiple equivalent names *only one of which actually
appears in the directory*. This can have subtle side-effects. NFS
implementations tend to fake this as best they can by linking foo.foo to
foo.foo;<n>, where <n> is the highest version number. They move the link when
a new version is created. I haven't seen any that also create foo.foo;0 and
foo.foo;-1 links, though they could. But this gets messy and expensive, and
is easily disrupted if the directory is accessed through some other OS that
doesn't follow the conventions. The Gnu scheme doesn't bother with this -
foo.foo is the most recent version, and all foo.foo.~<n>~'s are all "older".
Note that if you delete foo.foo, you no longer have a "most recent version".
-- Jerry
================================================================================
Archive-Date: Thu, 7 Jan 1999 10:30:11 +0100
Date: Thu, 7 Jan 1999 10:27:40 +0100 (CET)
From: "Gotfryd Smolik, VMS lists" <gotfryd@stanpol.com.pl>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: Why don't we just start?
In-Reply-To: <3.0.3.16.19990105205611.3a7f583c@earthlink.net>
Message-ID: <Pine.LNX.3.96.990107101400.4004B-100000@irys.stanpol.com.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 5 Jan 1999, David J. Dachtera wrote:
[cut]
+An important point to remember is that on OpenVMS, filetype extensions
+*ARE* significant. The image activator seeks .EXE files by default.
Sure. Is also on DOS: was mentioned here, that some elements
of DOS (like readable (hm.. "meanable" ? -;)) command, like
DIR etc.) are get from the RSX-VMS line. Also the predecesor
(CP/M) have (oh, why we haven't in VMS the genial PIPE parts
like /END_COPY_WHEN_FIND_STRING and other ?! /START_COPY is
available thru /REMAIN in SEARCH...).
Then it is implemented in Windows and means what expected:
the file type. Sure, sometime is implemented on the application
level (b.ex. office: if ypu will save file "TEST.OLD" as WORD
docs you get "TEST.OLD.doc" -;>, whole Microsoft...).
But the filesystem knows about two file parts and can "?" as
"%" is VMS and "*" separately: un*x not.
+ The "@" operator in DCL seeks .COM files by default.
Minor correction: I always speak "include file in command
line", the same (by idea, please not flame me because not precise)
way as &name does include symbol name. Was some time ago on info-VAX,
but it is general ! Also some application use the syntax (like
@.DIS file in MAIL) not only for "command file" meaning.
And - for the point: it is known in DOS world... Microsoft
(yes !) have implemented the "@file" meaning in the same way
to it own compilers and linker for DOS in old days.
If you will point the resolution "something as layer
on Linux (or other unix)" you are right -:(
Regards - Gotfryd
--
=====================================================================
$ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") -
THEN EXCUSE/OBJECT=ME
$! GS@stanpol.zabrze.pl
=====================================================================
================================================================================
Archive-Date: Thu, 7 Jan 1999 10:49:56 +0100
Date: Thu, 7 Jan 1999 10:49:14 +0100 (CET)
From: "Gotfryd Smolik, VMS lists" <gotfryd@stanpol.com.pl>
Reply-To: Free-VMS@lp.se
To: Noah Paul <noahp@altavista.net>
CC: Free-VMS@lp.se
Subject: Subject and 4-mode (was: Why don't...)
In-Reply-To: <Pine.LNX.3.96.990105180138.10032C-100000@merlin>
Message-ID: <Pine.LNX.3.96.990107103811.4004C-100000@irys.stanpol.com.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 5 Jan 1999, Noah Paul wrote:
+On Long Threads:
+
+Perhaps from now on, when replying to a long thread, we should include
+the sender-who-were-replying-to's name in the Subject line? This makes
IMHO no. Better may be changing the subject to more appriopiate,
like:
"VMS kernel/MACH (was: Why don't...)"
but not a horrible long one !
Already implemented -;)
[...]
+It seems to have a *lot* of stuff assuming VAXish CPU protection
+(4-level, is it?) and VAX assembly language.
Yes. And I always will say, that more-that-two mode protection
in the proper resolution for good OS...
(FYI: Intels x86 have 4-mode protection).
[...]
+then on. We could do emulation of protection, etc. which isn't hardware
+dependant.
Can be little difficult and processor-time consuming. But...
BTW: why you include *whole* previous mail ? -:(
At end of message... (harder readable, especially if the subject
is multithreaded *or* you start new subject: the reader don't know
what was before).
Regards - Gotfryd
--
=====================================================================
$ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") -
THEN EXCUSE/OBJECT=ME
$! GS@stanpol.zabrze.pl
=====================================================================
================================================================================
Archive-Date: Thu, 7 Jan 1999 22:53:58 +0100
Message-ID: <3.0.6.32.19990107164624.007b0bc0@pop.ultranet.com>
Date: Thu, 07 Jan 1999 16:46:24 -0800
To: Free-VMS@lp.se
From: noahp@altavista.net
Reply-To: Free-VMS@lp.se
Subject: Re: vmsopt - Library for Parsing Arguments
In-Reply-To: <0003023E.C21492@advocatehealth.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Oh my ... :( ... I was trying to learn the Syntax through a few
examples which used ':'. I'll have to rework this. :(
At 10:23 AM 1/6/99 -0600, you wrote:
> >PROGRAM /OPTION /OPTION:ARGUMENT
>
> In DCL, the terminology is usually stated as:
>
> verb[/qualifier[=value]]
>
> or where a list of values is allowed:
>
> verb[/qualifier[=(value[,value]]]
>
> or where a list of keywords/values is allowed:
>
> verb[/qualifier[=(keyword[=value][,keyword[=value]])]
>
> DCL will, in most cases accept a colon (":") as well as
> an equal sign ("="). I may have missed a "]" in the
> above, also. (For those who may be wondering, optional
> items are usually shown inside square brackets ("[]").
>
> One of the most complex common commands I'm aware of
> looks like this:
>
> DIRECTORY/SELECT=SIZE=(MINIMUM=1000,MAXIMUM=1000000)
>
> See the Utility Routines manual for a discussion of the
> CLI$ routines. See the on-line help for the DIRECTORY
> command for a brief discussion of the valid qualifiers,
> keywords and values for this verb.
>
> David J. Dachtera
> dba DJE Systems
> http://home.earthlink.net/~djesys/
>
>
>______________________________ Reply Separator
_________________________________
>Subject: vmsopt - Library for Parsing Arguments
>Author: Free-VMS@lp.se at PO_EXTERNET
>Date: 1/5/99 5:57 PM
>
>
>
>*Clarification* In this library, an "argument" is the thing following a
>colon, and an option is the thing following the slash.
>
> vmsopt is a library for parsing a program's options in VMS style
>to a program:
>
> PROGRAM /OPTION /OPTION:ARGUMENT
>
>I uploaded a zip file to:
>
> http://www.ultranet.com/~noahp/vmsopt.zip
>(or, by ftp:)
> ftp://www.ultranet.com/~noahp/public_html/vmsopt.zip
>(Did we agree on .ZIP as the archive format OSLA?)
>(Richard: can you put this up on the free-vms.org ftp site?)
>
>It's used like this:
>
> while( (n = vmsopt_parse( argc, argv ) ) != -1 )
> {
> if( n == 2 )
> {
> /** option with argument, option is
> stored in optstr, argument is stored
> in optarg **/
> }
> else
> {
> /** just option, stored in optstr **/
> }
> }
>
>Hope it's useful.
>
>--------------
>Regards,
>Noah Paul <noahp@altavista.net>
>
>PGP Public Key: http://gandolf.lincnet.org/~noahp/Public_Key
>
>
>
>
================================================================================
Archive-Date: Thu, 7 Jan 1999 22:54:16 +0100
Message-ID: <3.0.6.32.19990107165056.007b6280@pop.ultranet.com>
Date: Thu, 07 Jan 1999 16:50:56 -0800
To: Free-VMS@lp.se
From: noahp@altavista.net
Reply-To: Free-VMS@lp.se
Subject: Re: vmsopt - Library for Parsing Arguments
In-Reply-To: <0003023E.C21492@advocatehealth.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Oh my ... :( ... I was trying to learn the Syntax through a few
examples which used ':'. I'll have to rework this. :(
At 10:23 AM 1/6/99 -0600, you wrote:
> >PROGRAM /OPTION /OPTION:ARGUMENT
>
> In DCL, the terminology is usually stated as:
>
> verb[/qualifier[=value]]
>
> or where a list of values is allowed:
>
> verb[/qualifier[=(value[,value]]]
>
> or where a list of keywords/values is allowed:
>
> verb[/qualifier[=(keyword[=value][,keyword[=value]])]
>
> DCL will, in most cases accept a colon (":") as well as
> an equal sign ("="). I may have missed a "]" in the
> above, also. (For those who may be wondering, optional
> items are usually shown inside square brackets ("[]").
>
> One of the most complex common commands I'm aware of
> looks like this:
>
> DIRECTORY/SELECT=SIZE=(MINIMUM=1000,MAXIMUM=1000000)
>
> See the Utility Routines manual for a discussion of the
> CLI$ routines. See the on-line help for the DIRECTORY
> command for a brief discussion of the valid qualifiers,
> keywords and values for this verb.
>
> David J. Dachtera
> dba DJE Systems
> http://home.earthlink.net/~djesys/
>
>
>______________________________ Reply Separator
_________________________________
>Subject: vmsopt - Library for Parsing Arguments
>Author: Free-VMS@lp.se at PO_EXTERNET
>Date: 1/5/99 5:57 PM
>
>
>
>*Clarification* In this library, an "argument" is the thing following a
>colon, and an option is the thing following the slash.
>
> vmsopt is a library for parsing a program's options in VMS style
>to a program:
>
> PROGRAM /OPTION /OPTION:ARGUMENT
>
>I uploaded a zip file to:
>
> http://www.ultranet.com/~noahp/vmsopt.zip
>(or, by ftp:)
> ftp://www.ultranet.com/~noahp/public_html/vmsopt.zip
>(Did we agree on .ZIP as the archive format OSLA?)
>(Richard: can you put this up on the free-vms.org ftp site?)
>
>It's used like this:
>
> while( (n = vmsopt_parse( argc, argv ) ) != -1 )
> {
> if( n == 2 )
> {
> /** option with argument, option is
> stored in optstr, argument is stored
> in optarg **/
> }
> else
> {
> /** just option, stored in optstr **/
> }
> }
>
>Hope it's useful.
>
>--------------
>Regards,
>Noah Paul <noahp@altavista.net>
>
>PGP Public Key: http://gandolf.lincnet.org/~noahp/Public_Key
>
>
>
>
================================================================================
Archive-Date: Fri, 8 Jan 1999 00:48:14 +0100
From: Cenobite <cenobite@the.satanic.org>
Reply-To: Free-VMS@lp.se
Message-ID: <199901072348.PAA06748@the.satanic.org>
Subject: Re: vmsopt - Library for Parsing Arguments
To: Free-VMS@lp.se
Date: Thu, 7 Jan 1999 15:48:06 -0800 (PST)
In-Reply-To: <3.0.6.32.19990107165056.007b6280@pop.ultranet.com> from "noahp@altavista.net" at Jan 7, 99 04:50:56 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
> Oh my ... :( ... I was trying to learn the Syntax through a few
> examples which used ':'. I'll have to rework this. :(
There's also a standard library in VMS for doing this, and all (er, DEC
supplied...) programs that process command lines use it. There is a
specification language for specifying the syntax of your command as well,
so that syntax errors can be handled without image activation. See the
CLI$ documentation in the docset.
Henry B. Messenger
Explosive Networking
================================================================================
Archive-Date: Fri, 8 Jan 1999 01:55:54 +0100
Message-ID: <3.0.6.32.19990108005056.007a6a50@pop.ultranet.com>
Date: Fri, 08 Jan 1999 00:50:56 -0800
To: Free-VMS@lp.se
From: noahp@altavista.net
Reply-To: Free-VMS@lp.se
Subject: Re: vmsopt - Library for Parsing Arguments
In-Reply-To: <0003023E.C21492@advocatehealth.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Oh my ... :( ... I was trying to learn the Syntax through a few
examples which used ':'. I'll have to rework this. :(
At 10:23 AM 1/6/99 -0600, you wrote:
> >PROGRAM /OPTION /OPTION:ARGUMENT
>
> In DCL, the terminology is usually stated as:
>
> verb[/qualifier[=value]]
>
> or where a list of values is allowed:
>
> verb[/qualifier[=(value[,value]]]
>
> or where a list of keywords/values is allowed:
>
> verb[/qualifier[=(keyword[=value][,keyword[=value]])]
>
> DCL will, in most cases accept a colon (":") as well as
> an equal sign ("="). I may have missed a "]" in the
> above, also. (For those who may be wondering, optional
> items are usually shown inside square brackets ("[]").
>
> One of the most complex common commands I'm aware of
> looks like this:
>
> DIRECTORY/SELECT=SIZE=(MINIMUM=1000,MAXIMUM=1000000)
>
> See the Utility Routines manual for a discussion of the
> CLI$ routines. See the on-line help for the DIRECTORY
> command for a brief discussion of the valid qualifiers,
> keywords and values for this verb.
>
> David J. Dachtera
> dba DJE Systems
> http://home.earthlink.net/~djesys/
>
>
>______________________________ Reply Separator
_________________________________
>Subject: vmsopt - Library for Parsing Arguments
>Author: Free-VMS@lp.se at PO_EXTERNET
>Date: 1/5/99 5:57 PM
>
>
>
>*Clarification* In this library, an "argument" is the thing following a
>colon, and an option is the thing following the slash.
>
> vmsopt is a library for parsing a program's options in VMS style
>to a program:
>
> PROGRAM /OPTION /OPTION:ARGUMENT
>
>I uploaded a zip file to:
>
> http://www.ultranet.com/~noahp/vmsopt.zip
>(or, by ftp:)
> ftp://www.ultranet.com/~noahp/public_html/vmsopt.zip
>(Did we agree on .ZIP as the archive format OSLA?)
>(Richard: can you put this up on the free-vms.org ftp site?)
>
>It's used like this:
>
> while( (n = vmsopt_parse( argc, argv ) ) != -1 )
> {
> if( n == 2 )
> {
> /** option with argument, option is
> stored in optstr, argument is stored
> in optarg **/
> }
> else
> {
> /** just option, stored in optstr **/
> }
> }
>
>Hope it's useful.
>
>--------------
>Regards,
>Noah Paul <noahp@altavista.net>
>
>PGP Public Key: http://gandolf.lincnet.org/~noahp/Public_Key
>
>
>
>
================================================================================
Archive-Date: Fri, 8 Jan 1999 01:55:57 +0100
Message-ID: <3.0.6.32.19990107195705.007b1450@pop.ultranet.com>
Date: Thu, 07 Jan 1999 19:57:05 -0800
To: Free-VMS@lp.se
From: noahp@altavista.net
Reply-To: Free-VMS@lp.se
Subject: Re: Subject and 4-mode (was: Why don't...)
In-Reply-To: <Pine.LNX.3.96.990107103811.4004C-100000@irys.stanpol.com.p l>
References: <Pine.LNX.3.96.990105180138.10032C-100000@merlin>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 10:49 AM 1/7/99 +0100, you wrote:
>On Tue, 5 Jan 1999, Noah Paul wrote:
>
>+On Long Threads:
>+
>+Perhaps from now on, when replying to a long thread, we should include
>+the sender-who-were-replying-to's name in the Subject line? This makes
>
> IMHO no. Better may be changing the subject to more appriopiate,
>like:
>"VMS kernel/MACH (was: Why don't...)"
>
> but not a horrible long one !
> Already implemented -;)
>
>[...]
>+It seems to have a *lot* of stuff assuming VAXish CPU protection
>+(4-level, is it?) and VAX assembly language.
>
> Yes. And I always will say, that more-that-two mode protection
>in the proper resolution for good OS...
>(FYI: Intels x86 have 4-mode protection).
<
I always thought it was just 2-mode. But I'm not a real
hardware guy (always write portable code ... or what I
*think* is portable code until some guy w/ old hardware
or AIX threatens to do hurtful things to me physically.
Oh dear ...)
>
>[...]
>+then on. We could do emulation of protection, etc. which isn't hardware
>+dependant.
>
> Can be little difficult and processor-time consuming. But...
>
>BTW: why you include *whole* previous mail ? -:(
> At end of message... (harder readable, especially if the subject
>is multithreaded *or* you start new subject: the reader don't know
>what was before).
>
> Regards - Gotfryd
>
>--
>=====================================================================
>$ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") -
> THEN EXCUSE/OBJECT=ME
>$! GS@stanpol.zabrze.pl
>=====================================================================
>
>
================================================================================
Archive-Date: Fri, 8 Jan 1999 02:11:41 +0100
Date: Fri, 08 Jan 1999 12:13:57 +1100
From: "Scott Hamilton, +61-2-9950 1693, NSW Dept Education and Training" <SHAMILTON1@dev.develop1.tafensw.edu.au>
Reply-To: Free-VMS@lp.se
Subject: Re: vmsopt - Library for Parsing Arguments
To: Free-VMS@lp.se
Message-ID: <01J6AQ7D5ATU0093SJ@hmgwy1.isd.tafensw.edu.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
>Oh my ... :( ... I was trying to learn the Syntax through a few
>examples which used ':'. I'll have to rework this. :(
Also don't forget DCL qualifiers can be position dependant or independant
a great example is the BACKUP command with the /SAVE qualifier if it's
on the first parameter it's a restore operation if it's on the second
parameter then it's a save operation, the /LABEL qualifier then is
position independant (it can anywhere in the command line)
Scott, Esq.
-------------------------------------------------------------------------------
"I C more clearly now my N.S.W. Dept Education and Training
brain has gone." Information Technology Bureau
Technical Architecture team
w: +61-2-9950 1693 shamilton1@dev.develop1.tafensw.edu.au
================================================================================
Archive-Date: Fri, 8 Jan 1999 10:13:21 +0100
Date: Fri, 8 Jan 1999 10:12:04 +0100 (CET)
From: "Gotfryd Smolik, VMS lists" <gotfryd@stanpol.com.pl>
Reply-To: Free-VMS@lp.se
To: noahp@altavista.net
CC: Free-VMS@lp.se
Subject: Re: Subject and 4-mode (was: Why don't...)
In-Reply-To: <3.0.6.32.19990107195705.007b1450@pop.ultranet.com>
Message-ID: <Pine.LNX.3.96.990108100348.11014B-100000@irys.stanpol.com.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 7 Jan 1999 noahp@altavista.net wrote:
[...]
+>(FYI: Intels x86 have 4-mode protection).
+<
+ I always thought it was just 2-mode. [cut]
...because none of OS does use the support for 4-mode, right ?
Sure, it is known to me; if you will look (using DejaNews) there
was some threads on comp.os.vms (to be precise: I am are subscriber
of info-vax, and some threads can be not available in DejaNews
because are too old !) and you see the opinion (not only me,
but I am express it more time): x86 isn't so wrong ! The IBM
PC implementation limits some part of Intels X86 (interrupt
organization !!), but still: x86 can do much more than Linux
use.
What is interasant to me: know someone what architecture
(in the view of modes, interrupts etc.) may have Merced ?
Thanks.
Regards - Gotfryd
--
=====================================================================
$ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") -
THEN EXCUSE/OBJECT=ME
$! GS@stanpol.zabrze.pl
=====================================================================
================================================================================
Archive-Date: Fri, 8 Jan 1999 11:19:44 +0100
Date: Fri, 8 Jan 1999 11:18:40 +0100 (CET)
From: "Gotfryd Smolik, VMS lists" <gotfryd@stanpol.com.pl>
Reply-To: Free-VMS@lp.se
To: noahp@altavista.net
CC: Free-VMS@lp.se
Subject: Re: vmsopt - Library for Parsing Arguments
In-Reply-To: <3.0.6.32.19990107164624.007b0bc0@pop.ultranet.com>
Message-ID: <Pine.LNX.3.96.990108103048.11014C-100000@irys.stanpol.com.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 7 Jan 1999 noahp@altavista.net wrote:
+Oh my ... :( ... I was trying to learn the Syntax through a few
+examples which used ':'. I'll have to rework this. :(
[about description of DCL syntax)
Haven't check your library. But is you will rework it,
look also for the list-type data:
$ DIR *.COM,*.EXE
$ DIR *.COM+*.DIR
To be precise, the "+" and "," separator are not exactly
the same (unlike ":" and "=", where *are* the same in DCL point
od view), but in most cases are can be used as the same.
Regards - Gotfryd
--
=====================================================================
$ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") -
THEN EXCUSE/OBJECT=ME
$! GS@stanpol.zabrze.pl
=====================================================================
================================================================================
Archive-Date: Fri, 8 Jan 1999 14:39:54 +0100
Date: Fri, 8 Jan 99 08:34:56 EST
Message-ID: <009D1E6A3C1A5BA0.00001522@ais.com>
From: bruce@ais.com
Reply-To: Free-VMS@lp.se
Subject: Re: Subject and 4-mode (was: Why don't...)
To: Free-VMS@lp.se
Content-Type: text
Noah Paul writes:
>At 10:49 AM 1/7/99 +0100, you wrote:
>>On Tue, 5 Jan 1999, Noah Paul wrote:
>>
>>[...]
>>+It seems to have a *lot* of stuff assuming VAXish CPU protection
>>+(4-level, is it?) and VAX assembly language.
>>
>> Yes. And I always will say, that more-that-two mode protection
>>in the proper resolution for good OS...
>>(FYI: Intels x86 have 4-mode protection).
><
> I always thought it was just 2-mode. But I'm not a real
> hardware guy (always write portable code ... or what I
> *think* is portable code until some guy w/ old hardware
> or AIX threatens to do hurtful things to me physically.
> Oh dear ...)
>
If I recall correctly, the Intel CPU has 4 levels, however the memory model
will only effectively allow 2 levels of *memory* protection (not processor
modes) unless you use segments (ugh...). We probably want to avoid segments
like the plague -- they are a pain to use: using them in 16-bit mode means
that you can't have 32 bits of flat memory space which is expected by many
VMS programs, and using them in 32-bit mode means that the address width
(including the segment) expands to 48 or 64 bits depending on how you want
to implement the data structures. Lots of things in VMS assume 32-bit
addresses, or at least that sizeof (int) == sizeof (char *).
This, however, raises another potential issue: do we want to explicitly
allow for 64-bit addresses in descriptors &c for processors that allow it,
or should these be 32-bit as in (real) VMS? The tradeoffs here are obviously
that 64-bit addresses will be used by many future (and even present-day)
machines, but as noted above a lot of existing software unfortunately isn't
"clean" in this respect. How much compatibility do we want in this area?
Bruce C. Wright
================================================================================
Archive-Date: Fri, 8 Jan 1999 17:14:53 +0100
MIME-Version: 1.0
Date: Fri, 8 Jan 1999 10:52:16 -0600
Message-ID: <00032569.C21492@advocatehealth.com>
From: David.Dachtera@advocatehealth.com (David Dachtera)
Reply-To: Free-VMS@lp.se
Subject: Re[2]: vmsopt - Library for Parsing Arguments
To: Free-VMS@lp.se
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Yes - it's the CLI$ routines that we need to duplicate.
There's also the underlying STR$ routines. I would
imagine that the STR$ELEMENT routine would be a key a
part of the parser.
I'm also told that there's a [SYS]$PARSE routine, which
seems to be undocumented. This would be equivalent in
function to the DCL lexical function F$PARSE() for
validating/parsing filespec. strings. DCL seems to care
about this.
I have another good size bunch of doc.'s (including the
STR$ Routines manual) from DEC's website (freely
downloadable) that I need to convert from .PS to .PDF and
then upload them to Richard. I've got them on my
workstation at work - I just need to bring in my Zip disk
(yes, I know about COD) and copy them off so I can take
them home and "distill" them (kinda slow on a
486/DX4-100, but oh well...).
I'm also looking for a virtual hosting site here in the
Chicago, IL (USA) area so I can register "djesys.com" and
have more server space than the 6 MB that Earthlink
allows me on my personal website.
ISDN/constant-connection is still a bit beyond what I can
afford right now. Otherwise, I'd go that route and set up a
FreeBSD server or something.
Things never happen fast enough, do they?
David J. Dachtera
dba DJE Systems
http://home.earthlink.net/~djesys/
P.S.:
"COD" (Click Of Death) information on Iomega Zip/Jaz
drives is available at the following URL:
http://www.thirdeyesp.com/isage/iomega
______________________________ Reply Separator _________________________________
Subject: Re: vmsopt - Library for Parsing Arguments
Author: Free-VMS@lp.se at PO_EXTERNET
Date: 1/7/99 5:48 PM
> Oh my ... :( ... I was trying to learn the Syntax through a few
> examples which used ':'. I'll have to rework this. :(
There's also a standard library in VMS for doing this, and all (er, DEC
supplied...) programs that process command lines use it. There is a
specification language for specifying the syntax of your command as well,
so that syntax errors can be handled without image activation. See the
CLI$ documentation in the docset.
Henry B. Messenger
Explosive Networking
================================================================================
Archive-Date: Fri, 8 Jan 1999 20:28:35 +0100
Message-ID: <36964CA4.3FEB4FEE@srv.net>
Date: Fri, 08 Jan 1999 11:21:24 -0700
From: Kevin Handy <kth@srv.net>
Reply-To: Free-VMS@lp.se
MIME-Version: 1.0
To: Free-VMS@lp.se
Subject: Re: vmsopt - Library for Parsing Arguments
References: <00032569.C21492@advocatehealth.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
David Dachtera wrote:
>
> Yes - it's the CLI$ routines that we need to duplicate.
>
> There's also the underlying STR$ routines. I would
> imagine that the STR$ELEMENT routine would be a key a
> part of the parser.
Note that some of the STR$ functions already exist, and if anyone
wants to add to them, please send me a copy to append to what I
have already gathered (kth@srv.net)
> I'm also told that there's a [SYS]$PARSE routine, which
> seems to be undocumented. This would be equivalent in
> function to the DCL lexical function F$PARSE() for
> validating/parsing filespec. strings. DCL seems to care
> about this.
>
> I have another good size bunch of doc.'s (including the
> STR$ Routines manual) from DEC's website (freely
> downloadable) that I need to convert from .PS to .PDF and
> then upload them to Richard. I've got them on my
> workstation at work - I just need to bring in my Zip disk
> (yes, I know about COD) and copy them off so I can take
> them home and "distill" them (kinda slow on a
> 486/DX4-100, but oh well...).
What I think would be nice to have, is one set of routines that
would parse the .cld files into some internal structire, and then a
set of CLI$ routines that could use that information to parse
the passed parameters.
This way, on a "real" Free-VMS system the structure would be
passed into DCLTABLES and stored. When the program runs, it
would load the structure and then process the command line.
On non-VMS systems, like Linux, the CLI$ routines could call
the parse routines (based on the program name?), and then would
process the command line.
The only difference between the two would be where it got the
structure from, and where it got the command line from.
================================================================================
Archive-Date: Fri, 8 Jan 1999 20:46:21 +0100
Date: Fri, 8 Jan 1999 13:01:46 -0500
From: "Brian Schenkenberger, VAXman-" <system@TMESIS.COM>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Message-ID: <009D1E8F.82AE66B8.5@TMESIS.COM>
Subject: RE: Re[2]: vmsopt - Library for Parsing Arguments
> Yes - it's the CLI$ routines that we need to duplicate.
>
> There's also the underlying STR$ routines. I would
> imagine that the STR$ELEMENT routine would be a key a
> part of the parser.
The STR$ routines should be easy to duplicate. However, their
direct use in the current DCL CLI is relatively sparse.
> I'm also told that there's a [SYS]$PARSE routine, which
> seems to be undocumented. This would be equivalent in
> function to the DCL lexical function F$PARSE() for
> validating/parsing filespec. strings. DCL seems to care
> about this.
$PARSE is VERY well documented. You might be looking in the
wrong location for the documentation. SYS$PARSE is an RMS
service. Take a look in the RMS guide for details on $PARSE.
--
VAXman- OpenVMS APE certification number: AAA-0001 VAXman@TMESIS.COM
================================================================================
Archive-Date: Mon, 11 Jan 1999 04:08:43 +0100
Message-ID: <3.0.3.16.19990110212002.3d4721bc@earthlink.net>
Date: Sun, 10 Jan 1999 21:20:02
To: Free-VMS@lp.se
From: "David J. Dachtera" <djesys@earthlink.net>
Reply-To: Free-VMS@lp.se
Subject: VMS-Related Polls
In-Reply-To: <009D1E8F.82AE66B8.5@TMESIS.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Folks,
I posted the following to comp.os.vms over the weekend, and also wanted to
make the list aware of this - your votes should count, also!
In the hope that it might be found useful, informative, entertaining,
etc., I posted a new web page with some polls germaine to OpenVMS, this
newgroup thread and others. This should allow for some numbers to be
collected, at the very least. These are not scientific polls by any
stretch, so don't expect too much. Responses are completely anonymous -
no information is requested or extracted from your browser (to the best
of knowledge).
Please read the notes on the polls page. Here are the URLs:
The polls page is at:
http://home.earthlink.net/~djesys/vms/vmspolls.html
Notes on the polls:
http://home.earthlink.net/~djesys/vms/vmspolls.html#info
The polls are:
Should Digital have completed the Emerald project?
http://home.earthlink.net/~djesys/vms/vmspolls.html#emerald
Could your company benefit from an AFFORDABLE OpenVMS?
http://home.earthlink.net/~djesys/vms/vmspolls.html#affordable
If an affordable OpenVMS were available, how many licenses would you or
your company be likely to buy?
http://home.earthlink.net/~djesys/vms/vmspolls.html#licenses
Do you believe the current A.S.A.P. Program is suited to the needs of
your customers or your company?
http://home.earthlink.net/~djesys/vms/vmspolls.html#asap
I don't know if these will actually be useful. It was a freebie, so I
figured, "Why not?"
Enjoy!
-------------------------------------------------------------------------
David J. Dachtera For a VMS licensing idea that
dba DJE Systems does for small/home biz what the
http://home.earthlink.net/~djesys/ hobby license does for VMS
hackers, see
http://home.earthlink.net/~djesys/soholic.txt
If you agree, e-mail Compaq and
voice your support!
================================================================================
Archive-Date: Mon, 11 Jan 1999 16:19:10 +0100
Date: Mon, 11 Jan 1999 10:18:06 -0500 (EST)
Message-ID: <99011110180670@star.zko.dec.com>
From: parke@star.zko.dec.com (Pati die.)
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: Re[2]: vmsopt - Library for Parsing Arguments
The "SYS$PARSE" routine(s) you are looking for are TPARSE, available
asl LIB$TPARSE (or LIB$TABLE_PARSE) in the documentation.
Bill Parke
COMPAQ Computer Corporation
================================================================================
Archive-Date: Mon, 18 Jan 1999 17:51:34 +0100
Date: Fri, 15 Jan 1999 12:16:36 -0500 (EST)
From: Noah Paul <noahp@altavista.net>
Reply-To: Free-VMS@lp.se
To: Free VMS Group <Free-VMS@lp.se>
Subject: Eric S. Raymond, BLISS
Message-ID: <Pine.LNX.3.96.990115121544.5720A-100000@merlin>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
ESR's Museum of RetroComputing <URL:http://www.tuxedo.org/retro>
claims to have a partly-functional BLISS compiler.
This could be most useful.
--------------
Regards,
Noah Paul <noahp@altavista.net>
PGP Public Key: http://gandolf.lincnet.org/~noahp/Public_Key
================================================================================
Archive-Date: Mon, 18 Jan 1999 20:21:22 +0100
MIME-Version: 1.0
Date: Mon, 18 Jan 1999 15:02:46 -0600
Message-ID: <0003B711.C21492@advocatehealth.com>
From: David.Dachtera@advocatehealth.com (David Dachtera)
Reply-To: Free-VMS@lp.se
Subject: Re[2]: Why don't we just start?
To: Free-VMS@lp.se
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Folks,
Back before Christmas, we were all hot-to-trot about
beginning to program. So, I posted a program list to my
web-site
(http://home.earthlink.net/~djesys/vms/freevms/proglist.t
xt).
I suppose a lot of folks are busy with year-end stuff. Just
hoping to hear about any work beginning. There's a CVS set
up for the project where alpha/beta code can be placed.
I've not looked there yet ('cuz I'm a newbie to CVS). I had
also suggested that I would keep a list of who is
programming what, but have not yet received any mail in
that regard.
Does it seem rather a tall challenge?
Hey, I'm not a system-class programmer either, when it
comes to kernels and system services. That's why I
suggested to start "simple" and go with some of the
simpler command programs first (CREATE, APPEND/COPY,
DUMP, DIFFERENCES, etc.) So, don't feel you can't
contribute just 'cuz you're not a kernel hacker - very
few of us are (like Richard, Anton, and others).
C'mon, folks - give up a few nights of 90210 reruns, NYPD
Blue, football, cruising the web or the newsgroups, or
whatever and cook up some code.
I know - you need doc.'s. I've got some more .PS files
from the documentation area on Digital's web site that
I'm going to convert to .PDF and upload to Richard. I'll
do that this week. What I have should constitute the bulk
of the V6.1 doc. set (v6.0 with updates for V6.1).
I've received comments on this list from people at
Compaq, but to date no complaints about taking DEC's .PS
files and converting them to .PDF for distribution in
association with the project. So, until I hear otherwise,
I'll assume that this is not a problem - since the .PS
files are freely available for download, I'm using my own
resources to "distill" them, and the "distilled" results
are freely available for download.
If anyone from Compaq is "listening", remember - you can
always download the .PDFs and make them available at
http://www.partner.digital.com/www-swdev/pages/Home/TECH/
documents/ (or some suitable location under that path).
No credit or remuneration is requested. I only ask that
if there are any objections, please notify me at once and
I will cease such practices and request that Richard
delete them from the FTP server.
(The above three paragraphs will be duplicated in another
thread.)
David J. Dachtera
dba DJE Systems
http://home.earthlink.net/~djesys/
================================================================================
Archive-Date: Mon, 18 Jan 1999 20:21:28 +0100
MIME-Version: 1.0
Date: Mon, 18 Jan 1999 15:04:10 -0600
Message-ID: <0003B712.C21492@advocatehealth.com>
From: David.Dachtera@advocatehealth.com (David Dachtera)
Reply-To: Free-VMS@lp.se
Subject: Documentation
To: Free-VMS@lp.se
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Folks,
I know - you need doc.'s.
I've got some more .PS files from the documentation area
on Digital's web site that I'm going to convert to .PDF
and upload to Richard. I'll do that this week. What I
have should constitute the bulk of the V6.1 doc. set
(v6.0 with updates for V6.1).
I've received comments on this list from people at
Compaq, but to date no complaints about taking DEC's .PS
files and converting them to .PDF for distribution in
association with the project. So, until I hear otherwise,
I'll assume that this is not a problem - since the .PS
files are freely available for download, I'm using my own
resources to "distill" them, and the "distilled" results
are freely available for download.
If anyone from Compaq is "listening", remember - you can
always download the .PDFs and make them available at
http://www.partner.digital.com/www-swdev/pages/Home/TECH/
documents/ (or some suitable location under that path).
No credit or remuneration is requested. I only ask that
if there are any objections, please notify me at once and
I will cease such practices and request that Richard
delete them from the FTP server.
(The above three paragraphs were duplicated from another
thread.)
David J. Dachtera
dba DJE Systems
http://home.earthlink.net/~djesys/
================================================================================
Archive-Date: Mon, 18 Jan 1999 20:35:33 +0100
From: JayPed@aol.com
Reply-To: Free-VMS@lp.se
Message-ID: <33002c8c.36a38cb6@aol.com>
Date: Mon, 18 Jan 1999 14:34:14 EST
To: Free-VMS@lp.se
MIME-Version: 1.0
Subject: Re: Documentation
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
In a message dated 1/18/99 1:25:50 PM Central Standard Time,
David.Dachtera@advocatehealth.com writes:
<< I've got some more .PS files from the documentation area
on Digital's web site that I'm going to convert to .PDF
and upload to Richard. I'll do that this week. What I
have should constitute the bulk of the V6.1 doc. set
(v6.0 with updates for V6.1).
>>
Where is Richard's site with these pdf files? Just curious. I do appreciate
the PDF format rather than the PS format.
================================================================================
Archive-Date: Mon, 18 Jan 1999 21:52:27 +0100
MIME-Version: 1.0
Date: Mon, 18 Jan 1999 16:41:52 -0600
Message-ID: <0003B923.C21492@advocatehealth.com>
From: David.Dachtera@advocatehealth.com (David Dachtera)
Reply-To: Free-VMS@lp.se
Subject: Re[2]: Documentation
To: Free-VMS@lp.se
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Check the "Documents/Book references"
(http://www.free-vms.org/static/docs/) link at
www.free-vms.org
David J. Dachtera,
dbe DJE Systems
http://home.earthlink.net/~djesys/
______________________________ Reply Separator _________________________________
Subject: Re: Documentation
Author: Free-VMS@lp.se at PO_EXTERNET
Date: 1/18/99 1:34 PM
In a message dated 1/18/99 1:25:50 PM Central Standard Time,
David.Dachtera@advocatehealth.com writes:
<< I've got some more .PS files from the documentation area
on Digital's web site that I'm going to convert to .PDF
and upload to Richard. I'll do that this week. What I
have should constitute the bulk of the V6.1 doc. set
(v6.0 with updates for V6.1).
>>
Where is Richard's site with these pdf files? Just curious. I do appreciate
the PDF format rather than the PS format.
================================================================================
Archive-Date: Mon, 18 Jan 1999 22:17:28 +0100
From: JayPed@aol.com
Reply-To: Free-VMS@lp.se
Message-ID: <648ed7cc.36a3a4ba@aol.com>
Date: Mon, 18 Jan 1999 16:16:42 EST
To: Free-VMS@lp.se
MIME-Version: 1.0
Subject: Re: Re[2]: Documentation - implementation questions
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
In a message dated 1/18/99 2:54:29 PM Central Standard Time,
David.Dachtera@advocatehealth.com writes:
<< http://www.free-vms.org/static/docs/ >>
Nifty keeno. :-)
I have a question then. Let's say I wanted to implement a stand-alone system
service, something like sys$asctim. What I envisioned for this was a file
called asctim.c which implements the sys$asctim function.
I also envisioned defining all the arguments:
long sys$asctim (short timlen,
struct dsc$descriptor_s *p_timbuf,
struct quadword_time *p_timadr,
long cvtflg)
{
}
Where 'p_' is just a convention I personally use when naming pointer
arguments.
This begs many questions. Is C an acceptable language for creating this?
This does not provide for calling sys$asctim with fewer than 4 arguments.
When dealing with strings and time values, how do we describe them? I haven't
looked at the str$ routine implementation already done to see if it uses
'struct dsc$descriptor_s' or not. What of quadword time values? What of
flags? Is 'long' an acceptable definition for those?
How woud the standard VMS error code be returned, as an 'int'? or as a 'long'?
I remember some of these issues coming up before; specifically the 'optional'
parameters. I don't remember what the final word was on how free-VMS would
deal with this situation.
================================================================================
Archive-Date: Mon, 18 Jan 1999 22:57:57 +0100
Message-ID: <36A3B105.ABEDB66D@srv.net>
Date: Mon, 18 Jan 1999 15:09:09 -0700
From: Kevin Handy <kth@srv.net>
Reply-To: Free-VMS@lp.se
MIME-Version: 1.0
To: Free-VMS@lp.se
Subject: Re: Documentation - implementation questions
References: <648ed7cc.36a3a4ba@aol.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
JayPed@aol.com wrote:
>
> In a message dated 1/18/99 2:54:29 PM Central Standard Time,
> David.Dachtera@advocatehealth.com writes:
>
> << http://www.free-vms.org/static/docs/ >>
>
> Nifty keeno. :-)
>
> I have a question then. Let's say I wanted to implement a stand-alone system
> service, something like sys$asctim. What I envisioned for this was a file
> called asctim.c which implements the sys$asctim function.
>
> I also envisioned defining all the arguments:
>
> long sys$asctim (short timlen,
> struct dsc$descriptor_s *p_timbuf,
> struct quadword_time *p_timadr,
> long cvtflg)
> {
> }
>
> Where 'p_' is just a convention I personally use when naming pointer
> arguments.
>
> This begs many questions. Is C an acceptable language for creating this?
>
> This does not provide for calling sys$asctim with fewer than 4 arguments.
>
> When dealing with strings and time values, how do we describe them? I haven't
> looked at the str$ routine implementation already done to see if it uses
> 'struct dsc$descriptor_s' or not. What of quadword time values? What of
> flags? Is 'long' an acceptable definition for those?
It uses the structure, and is compatable with the same structure in VMS.
Note that the STR library now contains more than just the STR$
functions.
There several SYS$, LIB$, MTH functions
> How woud the standard VMS error code be returned, as an 'int'? or as a 'long'?
VMS uses 'unsigned long' for the error codes
> I remember some of these issues coming up before; specifically the 'optional'
> parameters. I don't remember what the final word was on how free-VMS would
> deal with this situation.
The only consenses decided was that the va_ routines should return
the number of parameters send, but since no Unix OS seems to fill this
information out...
I've been defining these with all the parameters as manditory, with a
'0' (null pointer) standing for a unused parameter, since VMS likes
most things to be passed as pointers, with NULL's for skipped
parameters.
If you look in the STR routines, you will see a file called
'sys_asctime.c'
(which is based on Paul Nankervis's work) that should give you a good
start.
He has send me a later version of his date functions, which I haven't
had a
chance update with (too much paid work to due this month)
================================================================================
Archive-Date: Mon, 18 Jan 1999 23:45:54 +0100
From: paulnank@au1.ibm.com
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Message-ID: <CA2566FD.007D00CD.00@au.ibm.com>
Date: Tue, 19 Jan 1999 10:45:57 +1100
Subject: Re: Re[2]: Documentation - implementation questions
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
> I have a question then. Let's say I wanted to implement a stand-alone
system
> service, something like sys$asctim. What I envisioned for this was a
file
> called asctim.c which implements the sys$asctim function.
>
> I also envisioned defining all the arguments:
>
> long sys$asctim (short timlen,
> struct dsc$descriptor_s *p_timbuf,
> struct quadword_time *p_timadr,
> long cvtflg)
> {
> }
>
> This begs many questions. Is C an acceptable language for creating this?
>
> This does not provide for calling sys$asctim with fewer than 4 arguments.
Don't forget that system services are normally defined in TWO places:-
1) the real procedure somewhere in kernel land, and
2) as a user callable routine which changes to kernel mode and does
some argument checking before calling the real procedure.
The current VMS user callable routines don't do that much checking before
calling
the real routines. However it could be reimplemented so that the user
callable
routine validates and rebuilds the argument list completely before calling
the
routine actually implementing the service. The result is that the real
service
need not validate arguments or worry about optional parameters.
While this should work for the main paremeters there are still situations
(like
variable length FIB blocks) where services would have to do their own
validation
and use defaults for unspecified parameters.
If this approach were taken then services could be coded blissfully unaware
of
variable argument lists - but the system service dispatcher would need to
know
all the gory details of parameter passing for the target machine (I think
that
it would have to anyway!).
And speaking of sys$asctim I have a version of it available at
http://luff.latrobe.edu.au/~ccpn
Paul Nankervis
================================================================================
Archive-Date: Tue, 19 Jan 1999 00:11:17 +0100
Date: Mon, 18 Jan 1999 18:10:20 -0500 (EST)
From: Jerrold Leichter <leichter@smarts.com>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: Re[2]: Documentation - implementation questions
In-Reply-To: <CA2566FD.007D00CD.00@au.ibm.com>
Message-ID: <Pine.GSO.4.02A.9901181807470.9967-100000@just>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
| The current VMS user callable routines don't do that much checking before
| calling the real routines. However it could be reimplemented so that the
| user callable routine validates and rebuilds the argument list completely
| before calling the routine actually implementing the service. The result
| is that the real service need not validate arguments or worry about
| optional parameters.
Yes, you *could* do that - if you didn't care about security. What's to
prevent a user from constructing bogus arguments and calling the code that
does the actual work directly, bypassing all the validity checking?
No, validity checking for any inner-mode routine *must* occur in the inner
mode. There are way too many methods for fooling it otherwise.
-- Jerry
================================================================================
Archive-Date: Tue, 19 Jan 1999 00:51:24 +0100
Date: Mon, 18 Jan 99 17:32:39 EST
Message-ID: <009D269102659C60.000017B6@ais.com>
From: bruce@ais.com
Reply-To: Free-VMS@lp.se
Subject: Re: Re[2]: Documentation - Implementation questions
To: Free-VMS@lp.se
Content-Type: text
JayPed@aol.com writes:
>I have a question then. Let's say I wanted to implement a stand-alone system
>service, something like sys$asctim. What I envisioned for this was a file
>called asctim.c which implements the sys$asctim function.
>
>I also envisioned defining all the arguments:
> [...]
>
>This begs many questions. Is C an acceptable language for creating this?
>
>This does not provide for calling sys$asctim with fewer than 4 arguments.
>
>When dealing with strings and time values, how do we describe them? I haven't
>looked at the str$ routine implementation already done to see if it uses
>'struct dsc$descriptor_s' or not. What of quadword time values? What of
>flags? Is 'long' an acceptable definition for those?
>
>How woud the standard VMS error code be returned, as an 'int'? or as a 'long'?
>
>I remember some of these issues coming up before; specifically the 'optional'
>parameters. I don't remember what the final word was on how free-VMS would
>deal with this situation.
I think C was decided as an acceptable (in fact, preferred) language for
FreeVMS code.
I don't know whether the type of the return value was ever discussed. I
would vote for an 'int' since on many modern platforms a 'long' implies 64
bits. For C code, it would be reasonable to define a specific type that was
guaranteed to be at least 32 bits that would be the "returned-status-value"
type. For compatibility reasons, I don't think we want a status value
that's more than 32 bits.
Most of the system services require all of their parameters to be specified,
at least as NULL pointers, rather than as short argument lists. This does
not cause any problems for C code or for most other modern languages on any
of the proposed target platforms. The problem occurs with the LIB$ code
which does allow for variable-length argument lists, where the optional
arguments can be specified not only as NULL but simply left out of the
argument list entirely. This causes more difficulty, and will eventually
require compiler modifications to handle correctly. In the short run it
should be possible to do some of the common LIB$ routines that have
relatively short calling sequences by requiring full argument lists; this
should not be a great hardship for new code, just for legacy code. The
real fun starts with components like SMG$ which have lots of optional
arguments; it's probably not reasonable to require the full argument list
for those components, although that might be needed in the early stages as
some of the basic system components get built.
Bruce C. Wright
================================================================================
Archive-Date: Tue, 19 Jan 1999 00:52:54 +0100
From: paulnank@au1.ibm.com
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Message-ID: <CA2566FD.00826857.00@au.ibm.com>
Date: Tue, 19 Jan 1999 11:44:59 +1100
Subject: Re: Re[2]: Documentation - implementation questions
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
>
>| The current VMS user callable routines don't do that much checking
before
>| calling the real routines. However it could be reimplemented so that the
>| user callable routine validates and rebuilds the argument list
completely
>| before calling the routine actually implementing the service. The result
>| is that the real service need not validate arguments or worry about
>| optional parameters.
>
>Yes, you *could* do that - if you didn't care about security. What's to
>prevent a user from constructing bogus arguments and calling the code that
>does the actual work directly, bypassing all the validity checking?
Absolutely nothing! But then the call would be in user mode and would not
be able to do anything! There is nothing to stop you from directly calling
the exe$... routines in VMS now - if you had the privileges.
>No, validity checking for any inner-mode routine *must* occur in the inner
>mode. There are way too many methods for fooling it otherwise.
But that is the point. A system service dispatcher has to exist to both
check the argument list AND do the change mode to kernel. After that it
doesn't really matter how the routines are implemented.
Paul
================================================================================
Archive-Date: Tue, 19 Jan 1999 01:48:35 +0100
Message-ID: <36A3D9F0.5AD8@bellsouth.net>
Date: Mon, 18 Jan 1999 20:03:44 -0500
From: Bob Martin <viper30@bellsouth.net>
Reply-To: Free-VMS@lp.se
MIME-Version: 1.0
To: Free-VMS@lp.se
Subject: Re: A.S.A.P
References: <0003B923.C21492@advocatehealth.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
David Dachtera wrote:
>
> Check the "Documents/Book references"
> (http://www.free-vms.org/static/docs/) link at
> www.free-vms.org
>
> David J. Dachtera,
> dbe DJE Systems
> http://home.earthlink.net/~djesys/
>
>
> ______________________________ Reply Separator _________________________________
> Subject: Re: Documentation
> Author: Free-VMS@lp.se at PO_EXTERNET
> Date: 1/18/99 1:34 PM
>
> In a message dated 1/18/99 1:25:50 PM Central Standard Time,
> David.Dachtera@advocatehealth.com writes:
>
> << I've got some more .PS files from the documentation area
> on Digital's web site that I'm going to convert to .PDF
> and upload to Richard. I'll do that this week. What I
> have should constitute the bulk of the V6.1 doc. set
> (v6.0 with updates for V6.1).
> >>
>
> Where is Richard's site with these pdf files? Just curious. I do appreciate
> the PDF format rather than the PS format.
Hear is what I found. It sure does sould like A.S.A.P to me..
I will have a legal expert look at this and define the legal
terms.
__________________________________________________________________________________
Director's Corner
ASAP -- Planning for Bold Future
A Message from the ASAP Director
October 1998
Dear ASAP Member,
Since June of this year, when Compaq's acquisition of
Digital became final, all of us at the combined company have
been hard at work making the "New World of Computing" a
reality. With our unique assets -- industry standard products,
useful, leading-edge innovations, customer responsiveness,
and committed partnerships, we believe we have the
ingredients required for the strongest partnership program in
the industry.
One important change of note is that Jack Mileski, director of
the program since its inception, has decided to pursue a new
opportunity and will now be Compaq's Director: Automotive
Industry Solutions. In leaving the program, Mileski said, "I
consider it a privilege that I've been associated with you, our
Software Partners, for the past 3+ years. We have had a
professional, and, I hope, mutually rewarding experience
together."
I've been aboard as ASAP Director for several weeks. My
goal is to build on the program's successes over the past
three years and to drive the creation of new partner program
combining the elements of ASAP, Tandem and Compaq's
existing partner programs.
While we continue developing our plans for an advanced
Compaq partner program into which ASAP Members will be
welcomed, we want to remind you that your existing program
benefits are available and fully operational.
Over the coming months we will continue to integrate our
organizations, to enhance our partnership program, and to
create mutual opportunities for you, our members. Watch
your mailboxes and e-mail, and our Web site for updates.
While we are moving ahead, don't hesitate to contact us with
questions or concerns. ASAP stands ready to respond to
you. Just call us at 800-332-4786 or reach us via e-mail at
alpha-developer@digital.com .
___________________________________________________________________________________
Bob Martin
Systems Administrator - Fairfield Communities - Ft. Laud. Fl.
================================================================================
Archive-Date: Tue, 19 Jan 1999 03:34:29 +0100
To: <free-vms@lp.se>
Subject: Re: Eric S. Raymond, BLISS
Message-ID: <LEVITTE.99Jan19031445@nic.bofh.se>
From: levitte@lp.se (Richard Levitte - VMS Whacker)
Reply-To: Free-VMS@lp.se
Date: 19 Jan 1999 02:14:45 GMT
References: <Pine.LNX.3.96.990115121544.5720A-100000@merlin>
In-Reply-To: Noah Paul's message of Fri, 15 Jan 1999 12:16:36 -0500 (EST)
MIME-Version: 1.0
Content-Type: Text/Plain; Charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
In article <Pine.LNX.3.96.990115121544.5720A-100000@merlin> Noah Paul <noahp@altavista.net> writes:
ESR's Museum of RetroComputing <URL:http://www.tuxedo.org/retro>
claims to have a partly-functional BLISS compiler.
This could be most useful.
I just sent him mail asking about that. Thanks for the pointer.
--
R Levitte, Levitte Programming; Spannv. 38, I; S-168 35 Bromma; SWEDEN
Tel: +46-8-26 52 47; Current work: +46-8-702 57 55
PGP key fingerprint = 35 3E 6C 9E 8C 97 85 24 BD 9F D1 9E 8F 75 23 6B
http://richard.levitte.org/pubkey2.asc for my public key. levitte@lp.se
"price, performance, quality. Choose any two you like"
================================================================================
Archive-Date: Tue, 19 Jan 1999 03:34:32 +0100
To: <free-vms@lp.se>
Subject: Re: Documentation - implementation questions
Message-ID: <LEVITTE.99Jan19032357@nic.bofh.se>
From: levitte@lp.se (Richard Levitte - VMS Whacker)
Reply-To: Free-VMS@lp.se
Date: 19 Jan 1999 02:23:57 GMT
References: <648ed7cc.36a3a4ba@aol.com> <36A3B105.ABEDB66D@srv.net>
In-Reply-To: Kevin Handy's message of Mon, 18 Jan 1999 15:09:09 -0700
MIME-Version: 1.0
Content-Type: Text/Plain; Charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
In article <36A3B105.ABEDB66D@srv.net> Kevin Handy <kth@srv.net> writes:
Note that the STR library now contains more than just the STR$
functions.
There several SYS$, LIB$, MTH functions
I'd strongly suggest you split them in three different libraries: STR,
LIB and MTH.
--
R Levitte, Levitte Programming; Spannv. 38, I; S-168 35 Bromma; SWEDEN
Tel: +46-8-26 52 47; Current work: +46-8-702 57 55
PGP key fingerprint = 35 3E 6C 9E 8C 97 85 24 BD 9F D1 9E 8F 75 23 6B
http://richard.levitte.org/pubkey2.asc for my public key. levitte@lp.se
"price, performance, quality. Choose any two you like"
================================================================================
Archive-Date: Tue, 19 Jan 1999 03:34:36 +0100
To: <free-vms@lp.se>
Subject: Re: Re[2]: Documentation - implementation questions
Message-ID: <LEVITTE.99Jan19033230@nic.bofh.se>
From: levitte@lp.se (Richard Levitte - VMS Whacker)
Reply-To: Free-VMS@lp.se
Date: 19 Jan 1999 02:32:30 GMT
References: <CA2566FD.007D00CD.00@au.ibm.com>
In-Reply-To: paulnank@au1.ibm.com's message of Tue, 19 Jan 1999 10:45:57 +1100
MIME-Version: 1.0
Content-Type: Text/Plain; Charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
In article <CA2566FD.007D00CD.00@au.ibm.com> paulnank@au1.ibm.com writes:
Don't forget that system services are normally defined in TWO places:-
1) the real procedure somewhere in kernel land, and
2) as a user callable routine which changes to kernel mode and does
some argument checking before calling the real procedure.
In a Mach-based system, the system services (or at least some of them.
Things like sys$asctim don't really need to be a system service per
se) would most probably live in a well-defined Mach server process.
And for safeties sake, it will have to do checks on the message it
gets from any requestor.
--
R Levitte, Levitte Programming; Spannv. 38, I; S-168 35 Bromma; SWEDEN
Tel: +46-8-26 52 47; Current work: +46-8-702 57 55
PGP key fingerprint = 35 3E 6C 9E 8C 97 85 24 BD 9F D1 9E 8F 75 23 6B
http://richard.levitte.org/pubkey2.asc for my public key. levitte@lp.se
"price, performance, quality. Choose any two you like"
================================================================================
Archive-Date: Tue, 19 Jan 1999 03:39:31 +0100
Date: Mon, 18 Jan 1999 19:38:15 -0500 (EST)
From: Noah Paul <noahp@altavista.net>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: Re[2]: Documentation - Implementation questions
In-Reply-To: <009D269102659C60.000017B6@ais.com>
Message-ID: <Pine.LNX.3.96.990118193717.459B-100000@merlin>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Most intelligent C compilers recognize that 'long' is too often
assumed to be equal to 'int', or 32 bits.
char 8 bits
short 16 bits
int 32 bits
long 32 bits
long long 64 bits
--------------
Regards,
Noah Paul <noahp@altavista.net>
PGP Public Key: http://gandolf.lincnet.org/~noahp/Public_Key
On Mon, 18 Jan 1999 bruce@ais.com wrote:
> JayPed@aol.com writes:
>
> >I have a question then. Let's say I wanted to implement a stand-alone system
> >service, something like sys$asctim. What I envisioned for this was a file
> >called asctim.c which implements the sys$asctim function.
> >
> >I also envisioned defining all the arguments:
> > [...]
> >
> >This begs many questions. Is C an acceptable language for creating this?
> >
> >This does not provide for calling sys$asctim with fewer than 4 arguments.
> >
> >When dealing with strings and time values, how do we describe them? I haven't
> >looked at the str$ routine implementation already done to see if it uses
> >'struct dsc$descriptor_s' or not. What of quadword time values? What of
> >flags? Is 'long' an acceptable definition for those?
> >
> >How woud the standard VMS error code be returned, as an 'int'? or as a 'long'?
> >
> >I remember some of these issues coming up before; specifically the 'optional'
> >parameters. I don't remember what the final word was on how free-VMS would
> >deal with this situation.
>
> I think C was decided as an acceptable (in fact, preferred) language for
> FreeVMS code.
>
> I don't know whether the type of the return value was ever discussed. I
> would vote for an 'int' since on many modern platforms a 'long' implies 64
> bits. For C code, it would be reasonable to define a specific type that was
> guaranteed to be at least 32 bits that would be the "returned-status-value"
> type. For compatibility reasons, I don't think we want a status value
> that's more than 32 bits.
>
> Most of the system services require all of their parameters to be specified,
> at least as NULL pointers, rather than as short argument lists. This does
> not cause any problems for C code or for most other modern languages on any
> of the proposed target platforms. The problem occurs with the LIB$ code
> which does allow for variable-length argument lists, where the optional
> arguments can be specified not only as NULL but simply left out of the
> argument list entirely. This causes more difficulty, and will eventually
> require compiler modifications to handle correctly. In the short run it
> should be possible to do some of the common LIB$ routines that have
> relatively short calling sequences by requiring full argument lists; this
> should not be a great hardship for new code, just for legacy code. The
> real fun starts with components like SMG$ which have lots of optional
> arguments; it's probably not reasonable to require the full argument list
> for those components, although that might be needed in the early stages as
> some of the basic system components get built.
>
> Bruce C. Wright
>
================================================================================
Archive-Date: Tue, 19 Jan 1999 16:50:47 +0100
Date: Tue, 19 Jan 99 10:50:17 EST
Message-ID: <009D2721F6FF3F20.00001C77@ais.com>
From: bruce@ais.com
Reply-To: Free-VMS@lp.se
Subject: Re: Re[2]: Documentation - Implementation questions
To: Free-VMS@lp.se
Content-Type: text
Noah Paul <noahp@altavista.net> writes:
>Most intelligent C compilers recognize that 'long' is too often
>assumed to be equal to 'int', or 32 bits.
>
> char 8 bits
> short 16 bits
> int 32 bits
> long 32 bits
> long long 64 bits
Not on several 64-bit processors, notably DEC C on Alpha-Unix. For
those processors, 'long' and 'long long' or 'int64' are all 64-bit
integers. Using 'long' to be 32 bits on a 64-bit machine is contrary
to the C standard, where 'long' is supposed to be the longest integer
available on the hardware. I don't doubt that there are compilers
out there that do this, but it's not something to be encouraged.
The C compilers commonly available on the x86 are sort of odd in this
respect. The hardware doesn't support anything larger than 32 bits,
although some of the compilers do support a 64-bit type. This can be
argued several ways, but it would certainly be surprising for a long
to be SO MUCH less efficient than an int on those processors.
In languages like C and Pascal, ideally it would be best to have a data
type that was specifically a status return data type, that could be
typedef'd to the appropriate sized integer for the hardware. However
this does not work for languages such as Fortran-77, which have no such
capability. That's one reason I was concerned about 32-bit vs 64-bit
returns, but another concern is that changing the 'size' of the return
value could cause portability problems when moving system components
from one processor to another.
Bruce C. Wright
====================================================================