This is G o o g l e's cache of http://www.lp.se/ftp/mailinglists/FREE-VMS.1998-10.
G o o g l e's cache is the snapshot that we took of the page as we crawled the web.
The page may have changed since that time. Click here for the current page without highlighting.
Google is not affiliated with the authors of this page nor responsible for its content. |
| These search terms have been highlighted: | levitte | programming |
|
|
Archive-Date: Tue, 27 Oct 1998 14:51:50 +0100
Date: Tue, 27 Oct 1998 08:51:38 -0500 (EST)
From: Jerrold Leichter <leichter@smarts.com>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
CC: music@triumf.ca
Subject: Re: DCL Internal commands
In-Reply-To: <009CE4B3.1B3BCE64.157@triumf.ca>
Message-ID: <Pine.GSO.4.02A.9810270814220.2512-100000@just>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
| >Even on "regular" VMS, relying on the text returned by F$MESSAGE is
| >rather, um, aggressive DCL coding style.
|
| So then, just how do you reword a message? Write a completely new
| set, I guess, and then associate them with given error code integers.
Let's distinguish between "code using documented and supported interfaces" and
code doing whatever it takes and damn the documentation.
Code of the former sort does not rely on the text of error messages. These
are subject to change at the user's whim - haven't you ever seen the classic
April Fool's message file that replaces all the system messages with things
like "File !AS not found - what are you, blind?". So the answer to "how do
you reword a message?" in this domain is "You don't!" Full stop.
Code of the former sort does not rely on the full message number; it always
uses LIB$MATCH_COND to match condition values correctly. No other method is
supported.
Further, code of the former sort *does not rely on the numerical values of
condition values*! It uses only the symbolic names. If you look through the
VMS documentation, you won't find *any* guarantees that specific condition
values might not change in the future. The theory, at least, was that code
would always let the Linker resolve condition values as global values; if
condition values ever changed, the corresponding shared libraries would be
given new major versions, forcing a re-link.
In practice, this last constraint proved almost unimplementable. People
don't want to re-link code; and some compilers (C, in particular - but not
exclusively) even put the explicit numerical values into standard header
files, thus tieing any code produced using them to those numerical values.
In recognition of this reality, the VMS developers (and other DEC developers
of VMS code) have tried to keep the numerical values constant across releases.
However, this has always been on a "best effort" basis - there is to this day,
as far as I know, no official commitment to it, and in fact there have been a
few cases in the past - I can't recall them now, but they weren't in the VMS
core - where condition code values *did* change across releases.
In general, VMS programmers (DEC and otherwise) are very good at sticking to
"documented and supported interfaces". This is one of the areas where that
commitment has been a bit weak. One of the reasons for it is DCL.
Unfortunately, DCL started life being seen as a CLI that supported fairly
simple command files. It was not viewed as a programming language, or as any
kind of tool for sophisticated programming. That's way DCL had such primitive
control structures, for example. That's also why there has never been any
real debugging support for DCL.
One of the things missing from DCL is any decent way to deal with status
values. There's no way to access the global values in STARLET, and there's no
analogue of the C header files, or analogous things for other languages, that
define condition values. There's no F$MATCH_COND(), so if you want to compare
condition values "correctly", you're on your own.
Since, regardless of the original design goals for DCL, it has come to be a
significant VMS programming language, this is all very unfortunate. It's
difficult to fix day-1 design bugs, especially when they've distorted code for
20 years. This is not an area VMS has to be proud of....
In fact, sophisticated DCL usage in general relies - is forced to rely - on
oddities of implementation, unsupported assumptions, and outright bugs.
Designing a "new DCL" is a thankless task: Do you go for "bug for bug"
compatibility (very hard), or do you try to produce a cleaner, better design
(leading to endless complaints about broken DCL command files)? DEC, which at
least had the old code base, stuck to the former approach. (You can see it in
such bizarre compromises as: Lexicals are not evaluated in comments, *except*
for F$VERIFY().)
Personally, I would vote for a cleaner, saner design. Toss out the accretions
of 20 or more years of hacking. Most code in most command files will work
just fine. If a few things don't come over unchanged - fix them. (Even on
VMS, people have been forced to do that: How many old command files stopped
working when DCL finally started *enforcing* the requirement that all command
lines have a leading "$" - even those at the beginning of the file?) Trying
to support every last bit of hackery will take a huge amount of time and
effort, which is better spent elsewhere. (Reminds me of a comment on the new
800+ page book on sendmail, written by Eric Allman, sendmail's developer: For
the time and effort expended in writing the book, he could have re-written
sendmail so that it didn't *need* so much documentation!)
There's a lesson from the Unix community to be learned here: "Undocumented
hacks" have always been the norm in the Unix world. When IBM set out to
develop AIX - the closest thing to a "from-scratch" Unix development effort in
the commercial world; everything else is just modified BSD or System V sources
- they first tried to implement what was in the documentation, then quickly
changed over to being "bug-for-bug" compatible. Even so, many Unix types
deride AIX as "not really Unix".
Linux, however, has never tried for "bug-for-bug" compatibility with anything.
It is what it is. In some very significant ways, Linux is very different from
other Unix implementations. The differences are generally pretty universally
held to be improvements over ossified practices slavishly copied from port to
port of antique code. If you'd listened to the Unix gurus of 10 years ago,
you'd have been convinced that an OS like that would never be accepted in the
Unix community. Hah. It's beginning to *define* Unix.
Backward compatibility is extraordinarily useful - but it can also be a curse.
Reasonable design requires that you discard it when its costs exceed its
benefits. A cost/benefit analysis for FreeVMS is not at all the same as one
for traditional VMS.
-- Jerry
================================================================================
Archive-Date: Tue, 27 Oct 1998 15:14:28 +0100
Message-ID: <19981027141416.28079.qmail@hotmail.com>
From: "Steve Lindsey" <stevelindsey@hotmail.com>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: DCL Internal commands
MIME-Version: 1.0
Content-Type: text/plain
Date: Tue, 27 Oct 1998 06:14:15 PST
>From: Jerrold Leichter <leichter@smarts.com>
>
>Let's distinguish between "code using documented and supported
interfaces" ...
I agree with the general thrust, but,
>A cost/benefit analysis for FreeVMS is not at all the same as one
>for traditional VMS.
there are some, i'm sure, that will point out that it's not always the
same people who pay the cost that reap the benefit.
Steve Lindsey
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
================================================================================
Archive-Date: Tue, 27 Oct 1998 16:07:00 +0100
MIME-Version: 1.0
Date: Tue, 27 Oct 1998 08:29:05 -0600
Message-ID: <0001DA1F.eval@advocatehealth.com>
From: David.Dachtera@advocatehealth.com (David Dachtera)
Reply-To: Free-VMS@lp.se
Subject: Re[6]: DCL Internal commands
To: Free-VMS@lp.se, "Scott Hamilton; +61-2-9950 1693; NSW Dept Education and Training" <SHAMILTON1@dev.develop1.tafensw.edu.au>
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Scott Hamilton writes:
>I prefer, though it's silly to say it here...
>
>blbc r0
...which is fine for VAX Assembler (MACRO32) and the
Alpha/MACRO migration compiler. Other languages will have
similar conditional expression constructs. In this
specific case, however, you know where the rsult will be
returned. Usually, in a higher-level language, you need
to assign the function result to a specific variable,
then test the value.
David J. Dachtera
dba DJE Systems
================================================================================
Archive-Date: Tue, 27 Oct 1998 19:29:34 +0100
Message-ID: <4FD6422BE942D111908D00805F3158DF0A75779B@RED-MSG-52>
From: Chris Kaler <ckaler@microsoft.com>
Reply-To: Free-VMS@lp.se
To: "'Free-VMS@lp.se'" <Free-VMS@lp.se>
Subject: RE: DCL Internal commands
Date: Tue, 27 Oct 1998 10:29:23 -0800
> Just a strange question - if DEC sort of forbids you from working on
> FreeVMS, how is it your are participating here? What would be DEC's
> view of FreeVMS ?
DEC doesn't "forbid" me from doing anything. However, when I worked
for DEC there was an explicit confidentiality agreement. I only
"contribute"
here what has been publicly disclosed or what I believe to be common
sense or derivative work to that which has been publicly disclosed.
I suspect that DEC (er... Compaq) wouldn't care if I did contribute code,
however, if for some reason they wanted to sue, they would have a very
strong case. That won't help Richard or your cause, so why draw the foul?
Chris
================================================================================
Archive-Date: Tue, 27 Oct 1998 19:40:07 +0100
Message-ID: <4FD6422BE942D111908D00805F3158DF0A75779E@RED-MSG-52>
From: Chris Kaler <ckaler@microsoft.com>
Reply-To: Free-VMS@lp.se
To: "'Free-VMS@lp.se'" <Free-VMS@lp.se>
Subject: RE: DCL Internal commands
Date: Tue, 27 Oct 1998 10:39:56 -0800
The reason is just simplicity. If you have a logical name server, then
the translation service RPCs to a common server. If you put user-mode
logicals in DCL, then the translation service has to do two RPCs: one
to "DCL" and one to the logical name server since you never really know
if a user-mode logical exists. Of course, this assumes that the app is
running is a separate address space from DCL.
Another reason is inheritance. I actually don't remember what VMS does
in this situation, it has been too long :-(. If I create a user-mode
logical and SPAWN a sub-process that inherits logicals, will it inherit
the user-mode logical? I can't remember if it did or if we wanted it
to. This also pushes the desire to have a common server.
Of course we where trying to do more than just emulate DCL. If that is
all you want, it might make sense to do some sort of a shared-memory
hash and look there first.
Chris
-----Original Message-----
From: levitte@lp.se [mailto:levitte@lp.se]
Sent: Monday, October 26, 1998 5:40 PM
To: free-vms@lp.se
Subject: Re: DCL Internal commands
In article <4FD6422BE942D111908D00805F3158DF0A757769@RED-MSG-52> Chris Kaler
<ckaler@microsoft.com> writes:
Chris, I need you to explain the following:
However, I don't agree that the "simplest" way to achieve
compatibility is to build commands into DCL. I would argue that
DCL is nothing more that a parser, state machine, and process
manager. You implement symbols and user mode logicals using
separate servers whose client-side API has aggressive caching.
What I'm hung up on is user mode (ha, spelled it right this time!)
logicals. Those are created at some point, live through an image load
and run, and go to the great graveyard of logicals when the image
exits. The reason user mode logicals survive *some* commands is
because those are internal to DCL (from a CDU point of view, they are
cliroutines). To emulate that birth, life and death of user mode
logicals seems to be pretty easy if you can identify the "image exit"
(would be a subprocess death in a Unix shell like implementation).
From that point of view, to further emulate the same behavior as
todays DCL, exactly the same commands would need to be internal in
"FreeDCL".
I rely on exactly that behavior in DCL. I expect my user mode
logicals to wither and die when an image exits, and to see the
supervisor (or exec) mode definition again right after. I can't,
right now, understand your idea of implementing this.
And oh, what I say does not at all preclude having a logical name
server, on the contrary. The death of user mode logicals would be
something like telling the server "kill anything matching the tuple
(<cookie>, <user-mode-flag>)", the rest being up to the efficiency of
that server.
--
R Levitte, Levitte Programming; Spannv. 38, I; S-168 35 Bromma; SWEDEN
Tel: +46-8-26 52 47; Cell: +46-708-20 09 64; Fax: +46-708-20 06 13
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, 27 Oct 1998 22:10:24 +0100
Date: Tue, 27 Oct 1998 12:10:23 -0500 (EST)
From: Noah Paul <noahp@ultranet.com>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: DCL Internal commands
In-Reply-To: <LEVITTE.98Oct27031401@nic.bofh.se>
Message-ID: <Pine.LNX.3.96.981027121012.6511A-100000@merlin>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
The Hurd has been going on since 1984.
-----------
Regards,
Noah Paul <noahp@altavista.net>
"TCP/IP is OK if you've got a little informal club, and it doesn't make
any difference if it takes a while to fix it."
-- Ken Olson, in Digital News, 1988
On 27 Oct 1998, Richard Levitte - VMS Whacker wrote:
> In article <4FD6422BE942D111908D00805F3158DF0A75778C@RED-MSG-52> Chris Kaler <ckaler@microsoft.com> writes:
>
> How long has GNU Hurd been going on?
>
> I do not know exactly. I do know that RMS' first plans to build a
> complete free OS (GNU) are more than 10 years old. I also know that
> before Hurd 0.01 (the first public release of *any* kind), there had
> been a bunch of years with talking, planning, building...
>
> --
> R Levitte, Levitte Programming; Spannv. 38, I; S-168 35 Bromma; SWEDEN
> Tel: +46-8-26 52 47; Cell: +46-708-20 09 64; Fax: +46-708-20 06 13
> 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, 27 Oct 1998 22:42:17 +0100
Date: Tue, 27 Oct 1998 15:42:04 -0600 (CST)
From: Chuck Milam <milam@uwosh.edu>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: DCL Internal commands
In-Reply-To: <Pine.LNX.3.96.981027121012.6511A-100000@merlin>
Message-ID: <Pine.GSO.4.02.9810271541020.782-100000@epsilon>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
> > I do not know exactly. I do know that RMS' first plans to build a
> > complete free OS (GNU) are more than 10 years old. I also know that
> > before Hurd 0.01 (the first public release of *any* kind), there had
> > been a bunch of years with talking, planning, building...
It's no wonder that RMS is so sore about the popularity of Linux. It blew
right by his pet project.
----------------------------------------------------------
Chuck Milam I.T. Division - Academic Computing
milam@uwosh.edu University of Wisconsin at Oshkosh
================================================================================
Archive-Date: Tue, 27 Oct 1998 22:56:24 +0100
Date: Tue, 27 Oct 1998 13:55:46 PST
From: "Fred W. Bach, TRIUMF Operations" <music@triumf.ca>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
CC: music@triumf.ca
Message-ID: <009CE539.F5E13334.2978@triumf.ca>
Subject: RE: DCL Internal commands
>Message-ID: <4FD6422BE942D111908D00805F3158DF0A75779E@RED-MSG-52>
>From: Chris Kaler <ckaler@microsoft.com>
>Reply-To: Free-VMS@lp.se
>To: "'Free-VMS@lp.se'" <Free-VMS@lp.se>
>Subject: RE: DCL Internal commands
>Date: Tue, 27 Oct 1998 10:39:56 -0800
[snip]
>Another reason is inheritance. I actually don't remember what VMS does
>in this situation, it has been too long :-(. If I create a user-mode
>logical and SPAWN a sub-process that inherits logicals, will it inherit
>the user-mode logical? I can't remember if it did or if we wanted it
>to. This also pushes the desire to have a common server.
The spawned process DOES inherit the logical, and it inherits it in
what appears to be USER MODE. (The command "SHOW" spawns an image
so it cancels user mode. The command DEFINE doesn't.) Here's how
it goes:
ERICH>
ERICH> SHOW LOG FRED
"FRED" = "JUNK" (LNM$PROCESS_TABLE)
ERICH> SHOW LOG FRED
%SHOW-S-NOTRAN, no translation for logical name FRED
ERICH> DEFINE/USER FRED JUNK
ERICH> SPAWN
%DCL-S-SPAWNED, process MUSIC_1 spawned
%DCL-S-ATTACHED, terminal now attached to process MUSIC_1
ERICH> SHO LOG FRED
"FRED" = "JUNK" (LNM$PROCESS_TABLE)
ERICH> SHO LOG FRED
%SHOW-S-NOTRAN, no translation for logical name FRED
ERICH> STOP/ID=0
%DCL-S-RETURNED, control returned to process Music_0
ERICH> SHOW LOG FRED
"FRED" = "JUNK" (LNM$PROCESS_TABLE)
ERICH> SHOW LOG FRED
%SHOW-S-NOTRAN, no translation for logical name FRED
ERICH>
So the user-mode logical is given to the spawned process as its OWN
user-mode logical. It disappears in that spawned process after an
image is run there. Then, when that spawned process exits and gives
control back to the parent process, the same user-mode logical in
that process is STILL THERE, and disappears after the next image
exits.
>
>Of course we where trying to do more than just emulate DCL. If that is
>all you want, it might make sense to do some sort of a shared-memory
>hash and look there first.
>
>Chris
Chris,
You are suggesting that FreeDCL should do MORE than real DCL. I
LIKE this idea. (I don't consider it to be in contradiction of the
100% compatability I was talking about earlier.) As a cyclotron
operator, what I tell the Controls Group is this: "Sure, give me
more features. Digitize the world. Log everything. I like new
and better features. But just don't take away anything I use (or
break any control features I have now)."
Sure, sometimes I will have to change or add disk names and node
names and (hardware) logical assignments. That kind of thing is
unavoidable as the hardware develops.
But what my edict means is NOT "don't improve the interface", but
what it means is do not take away any of the **functionality** I
now enjoy. This functionality includes the learned ergonomic
interfaces, "human" engineering, if you will. We have nifty
digital readouts and controls for just about everything, but we
still have phase **knobs** on our console and real **analog**
Keithley electrometers. Nice ballistics. Excellent readability.
(They also read beam current when if all the computers crash
because they're analog meters reading analog voltages.) I tell the
Controls people that they can pry the knobs out of my cold dead
fingers and remove the Keithleys over my cold dead body. I'm not
alone in this feeling. So historic features are very important to
users. But this doesn't mean that progress has to stop.
So FreeDCL (I keep writing that as FredDCL :-) ) can and should
have new features.
I see no *obvious* way to tell which DCL commands will terminate
user mode, except to use VERB and see if it runs an image or a
cli routine.
Fred W. Bach , Operations Group | Internet: music@triumf.ca
TRIUMF (Canada's National Meson Lab.) | Voice: 604-222-1047 loc 6278/6327
4004 WESBROOK MALL, UBC CAMPUS | FAX: 604-222-1074
University of British Columbia, Vancouver, B.C., CANADA V6T 2A3
"Accuracy is important. Details can mean the difference between life & death."
These are my opinions, which should ONLY make you read, think, and question.
They do NOT necessarily reflect the views of my employer or fellow workers.
================================================================================
Archive-Date: Wed, 28 Oct 1998 11:03:10 +0100
Date: Tue, 27 Oct 1998 19:16:48 -0800 (PST)
Message-ID: <2.2.16.19981027222346.43d73a3e@earthlink.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Free-VMS@lp.se
From: "David J. Dachtera" <djesys@earthlink.net>
Reply-To: Free-VMS@lp.se
Subject: RE: DCL Internal commands
At 01:55 PM 10/27/98 PST, Fred W. Bach wrote:
> Sure, sometimes I will have to change or add disk names and node
> names and (hardware) logical assignments. That kind of thing is
> unavoidable as the hardware develops.
I've got a bunch of DCL code that I call "SSCKB" which stands for "Shadow
Set Constituency Knowledge Base" (so that knowledge of shadow-set
constituency resides somewhere other than between one person's ears when a
disk error reduces a shadow set). When we add (or subtract) disks, we just
take a new "snapshot" of the system's condition (what disks are mounted to
which shadow-set, which disks/shadow-sets constitute which volume-set,
etc.). The code doesn't know - doesn't need to care. It just updates the
knowledge base (data file).
Would this be of any value to you?
Oh yeah, there's even a proc. you can invoke at cluster startup time (on the
founding node) to PREFER a specific MSCP host (where supported) for each
disk before the disks are MOUNTed as per the knowledge base.
David J. Dachtera
dba DJE Systems
================================================================================
Archive-Date: Wed, 28 Oct 1998 19:38:32 +0100
Date: Wed, 28 Oct 1998 10:38:05 PST
From: "Fred W. Bach, TRIUMF Operations" <music@triumf.ca>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
CC: music@triumf.ca
Message-ID: <009CE5E7.826D6414.1557@triumf.ca>
Subject: RE: DCL Internal commands
>Date: Tue, 27 Oct 1998 19:16:48 -0800 (PST)
>Message-ID: <2.2.16.19981027222346.43d73a3e@earthlink.net>
>To: Free-VMS@lp.se
>From: "David J. Dachtera" <djesys@earthlink.net>
>Reply-To: Free-VMS@lp.se
>Subject: RE: DCL Internal commands
>
>At 01:55 PM 10/27/98 PST, Fred W. Bach wrote:
>> Sure, sometimes I will have to change or add disk names and node
>> names and (hardware) logical assignments. That kind of thing is
>> unavoidable as the hardware develops.
>
>I've got a bunch of DCL code that I call "SSCKB" which stands for "Shadow
>Set Constituency Knowledge Base" (so that knowledge of shadow-set
>constituency resides somewhere other than between one person's ears when a
>disk error reduces a shadow set). When we add (or subtract) disks, we just
>take a new "snapshot" of the system's condition (what disks are mounted to
>which shadow-set, which disks/shadow-sets constitute which volume-set,
>etc.). The code doesn't know - doesn't need to care. It just updates the
>knowledge base (data file).
>
>Would this be of any value to you?
Why yes, I think so. We don't run a shadow system here but we do
swap disks around from time to time (or cluster to cluster) and
reassign logicals or modify DCL routines as applicable. In fact
today is maintenance day and we are doing such an operation right
now! Where possible we try to make directory references all into
logicals inside our DCL code so that we only have to change the
logicals and not the DCL code. However, there is still a ton of
DCL code, a lot of it in LOGIN.COM files, which references specific
disks and specific directories on those disks. It would seem to me
that we could teach people to change their DCL code to look at a
current table (knowledge base) instead. That way we wouldn't have
to *manually* redefine system logicals each time we added or
subtracted a disk from the system. Maybe system UP time would be
longer - fewer interruptions. I like that idea. Thanks very much
for the offer. I shall mention it to our Controls group.
>
>Oh yeah, there's even a proc. you can invoke at cluster startup time (on the
>founding node) to PREFER a specific MSCP host (where supported) for each
>disk before the disks are MOUNTed as per the knowledge base.
>
>David J. Dachtera
>dba DJE Systems
Sounds interesting. Thanks.
Fred W. Bach , Operations Group | Internet: music@triumf.ca
TRIUMF (Canada's National Meson Lab.) | Voice: 604-222-1047 loc 6278/6327
4004 WESBROOK MALL, UBC CAMPUS | FAX: 604-222-1074
University of British Columbia, Vancouver, B.C., CANADA V6T 2A3
"Accuracy is important. Details can mean the difference between life & death."
These are my opinions, which should ONLY make you read, think, and question.
They do NOT necessarily reflect the views of my employer or fellow workers.
================================================================================
Archive-Date: Wed, 28 Oct 1998 21:51:08 +0100
MIME-Version: 1.0
Date: Wed, 28 Oct 1998 14:29:28 -0600
Message-ID: <0001F09F.eval@advocatehealth.com>
From: David.Dachtera@advocatehealth.com (David Dachtera)
Reply-To: Free-VMS@lp.se
Subject: Re[2]: DCL Internal commands
To: <free-vms@lp.se>, levitte@lp.se (Richard Levitte - VMS Whacker)
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Folks,
A while back, I posted a list of DCL commands and the
images / cliroutines they invoke. It was intended as a
partial "to do" list for FreeVMS.
If I can find it, I'll repost it. If you can, though,
search the mailing list archives for July, circa. 15-Jul
looking for "PROGRAMS.TXT". The list is extensive, but
not exhaustive - I'm sure I missed something. This list
shows what commands are processed by which program or
which cliroutine. You'll notice that the great bulk of
the commands are "external", and only a small number of
commands use "cliroutines". Also, the ASSIGN and DEFINE
commands are conspicuous by their absence - these and the
other "missing" commands are facilitated by
"cliroutines"; that is, they are "internal".
David J. Dachtera
dba DJE Systems
================================================================================
Archive-Date: Wed, 28 Oct 1998 22:23:06 +0100
MIME-Version: 1.0
Date: Wed, 28 Oct 1998 15:04:38 -0600
Message-ID: <0001F160.eval@advocatehealth.com>
From: David.Dachtera@advocatehealth.com (David Dachtera)
Reply-To: Free-VMS@lp.se
Subject: DCL External commands
To: Free-VMS@lp.se
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Folks,
Below you will find a first draft of a program list for
FreeVMS. These are the command programs that will be
needed once a suitable DCL is established. I hope this
can be useful to the project.
I incorporated this into the message body in the hope
that it would not get scrambled.
David J. Dachtera
dba DJE Systems
--------------------- Cut Here -------------------------
PROGRAMS.TXT - Cross Reference of DCL Commands to the Programs which
13-JUL-1998 Facilitate Them
====================================================================
The following provides a listing derived from the output of the VERB
program. This list is provided in the hope that it can become the
basis for a "task list". The list is not 100% complete, but it does
cover most of the commonly used commands. A section at the end
contains suggestions for additional commands which are not found in
traditional VMS. Your updates and corrections are welcome.
For any release of VAX/VMS or OpenVMS from Digital, the .CLD files
can be found in the .A saveset of the distribution. Refer to them
for a complete list of qualifiers supported by each (variant of each)
command. Most of the commands not found in the following list are
implemented as "internal" commands in DCL; that is, they are not
facilitated by a program external to DCL. The commands listed here
are those for which a program is needed other than DCL.
The image names listed below are as found in the VERB output. Other
names for some images may be more appropriate.
In the following list, the main command is shown with it's related
"default" image, along with any keywords or qualifiers which modify
the image name and the name of the image invoked by each keyword or
qualifier.
Command Keyword or
/Qualifier Image name
---------------------------------------+-----------------------------------
ACCOUNTING ACC
APPEND COPY
ANALYZE ANALYZOBJ
/AUDIT ANALAUDIT
/CRASH_DUMP SDA
/DISK_STRUCTURE VERIFY
/ERROR_LOG ERF
/IMAGE ANALYZOBJ
/MEDIA ANALYZBAD
/OBJECT ANALYZOBJ
/PROCESS_DUMP ANALIMDMP
/RMS_FILE ANALYZRMS
/SYSTEM SDA
BACKUP BACKUP
CONVERT CONVERT
/RECLAIM RECLAIM
COPY COPY
/FTP OPENVMS$FTP
/RCP OPENVMS$RCP
CREATE CREATE
/FDL CREATEFDL
DELETE DELETE
/CHARACTERISTIC QUEMAN
/ENTRY QUEMAN
/FORM QUEMAN
/INTRUSION CIA
/KEY cliroutine delkey
/QUEUE QUEMAN
/MANAGER QUEMAN
/SYMBOL cliroutine delsym
DIFFERENCES DIFF
DIRECTORY DIRECTORY
/APPLICATION_PROTOCOL=FTAM OSIF$DIR
/FTP OPENVMS$FTPDIR
DISABLE
AUTOSTART QUEMAN
QUEUE QUEMAN
DISMOUNT DISMOUNT
DUMP DUMP
EDIT TPU
/ACL ACLEDT
/DPE DPE
/EDT EDT
/FDL EDF (EDF_TV)
/SLP SUMSLP
/SUM SUMSLP
/TECO TECO (TECO32_TV)
/TPU TPU
ENABLE
AUTOSTART QUEMAN
QUEUE QUEMAN
EXCHANGE EXCHANGE
/NETWORK EXCHANGE$NETWORK
HELP HELP
INITIALIZE INIT
/QUEUE QUEMAN
INSTALL INSTALL
LIBRARIAN LIBRARIAN
/RSX11 BACKTRANS
LICENSE LMF
/GENERATE PAK$DIR:PAK$USER.EXE
LINK LINK
MACRO MACRO32 (or ALPHA_MACRO)
/ALPHA MACRO64
/MIGRATION ALPHA_MACRO
/RSX11 BACKTRANS
/VAX MACRO32
MAIL MAIL
/DECMAIL DECMAIL
/SERVER MAIL_SERVER
MESSAGE MESSAGE
MONITOR MONITOR (MONITOR_TV)
MOUNT VMOUNT
PHONE PHONE
PRINT SUBMIT
RENAME RENAME
REPLY REPLY
REQUEST REQUEST
RUN cliroutine run
(Process) RUNDET
RUNOFF RUNOFF
/CONTENTS DSRTOC
/INDEX DSRINDEX
SET
ACCOUNTING SET
ACL SETSHOSECUR
AUDIT SETAUDIT
BROADCAST SET
CARD_READER SET
CLASSIFICATION SETSHOCLASS
CLUSTER SET
COMMAND CDU
CONTROL_Y cliroutine setctly
DAY SET
DEVICE SET
DEFAULT cliroutine setdefalt
DIRECTORY
/ACL SETSHOSECUR
/CLASSIFICATION SETSHOCLASS
/EDIT ACLEDT
DISPLAY DECW$SETSHODIS
ENTRY QUEMAN
FILE
/ACL SETSHOSECUR
/CLASSIFICATION SETSHOCLASS
/EDIT ACLEDT
HOST RTPAD
/BTS BTSLNK
/DTE DTEPAD
/DUP HSCPAD
/HSC HSCPAD
/LAT LTPAD
/MOP NET$CCR
/RLOGIN OPENVMS$RLOGIN
/SNA SNATERM
/TELNET OPENVMS$TELNET
/TN3270 OPENVMS$TN3270
/VTP VTPAD
/X29 PSIPAD
KEY SET
LANGUAGE SET
LOGINS SET
MAGTAPE SET
MESSAGE SETP0
ON cliroutine seton
OUTPUT_RATE cliroutine setflush
PASSWORD SETP0
PREFIX cliroutine setprefix
PRINTER SET
PROCESS SET
PROMPT cliroutine setprompt
PROTECTION SET
/DEFAULT cliroutine setprot
RESTART_VALUE QUEMAN
RMS_DEFAULT SET
QUEUE QUEMAN
RIGHTS_LIST SETRIGHTS
SECURITY SETSHOSECUR
SERVER SETSHOSERVER
SYMBOL (cliroutine setsymbol)
TEMPLATE SEVMS$SETSHOWTEMPLATE
TERMINAL SET
TIME SET
UIC cliroutine setuic
VERIFY cliroutine setverify
WATCH SETWATCH
WORKING_SET SET
START
/CPU SMPUTIL
/QUEUE QUEMAN
/ZONE FTSS$UTIL
STOP
/CPU SMPUTIL
/ENTRY QUEMAN
/QUEUE QUEMAN
/ZONE FTSS$UTIL
SUBMIT SUBMIT
/SNA SNASUBMIT
SYNCHRONIZE QUEMAN
TYPE TYPE
UNLOCK UNLOCK
Additional Commands We Would Like to See:
ARCHIVE
/COMPRESS=
GZIP GZIP
TAR[BALL] CPIO?
ZIP ZIP
/DECOMPRESS=
GZIP GUNZIP
TAR[BALL] CPIO?
ZIP UNZIP
This command should support all the existing DCL-format qualifiers for
ZIP and UNZIP. Both programs may need a modification to support the
ARCHIVE verb. The GZIP and GUNZIP programs (usually two names for the
same program - it supports both compress and decompress) may need
modification to support the ARCHIVE verb and the CLI$ routines.
Likewise, the CPIO program would need to be ported from BSD/Linux to
VMS and have support added for the ARCHIVE verb and the CLI$ routines.
As an alternative to the above qualifiers, a "dispatcher" program could
be sensitive to the extension of the specified input/output file and
invoke the appropriate (un)packager(s) (LIB$DO_COMMAND?).
ASSEMBLE GAS
This command is intended to invoke the Gnu Assembler directly, without
using Gnu-C or Gnu-C++ as a cross-compiler. This could replace the
MACROxx assembler. Presumably, there would be a suitable version of
GAS available for each CPU supported by the Mach kernel.
DELETE
/TREE DELTREE
This was discussed in the FreeVMS Mailing List. It is recommended
that the DELTREE.EXE program _NOT_ be installed with privileges. The
program should scan the files in the tree to ensure that there are
no non-deletable files in any path in the tree _BEFORE_ any files
are actually deleted. Suitably privileged users could then use the
SET PROCESS/PRIVILEGE=BYPASS command to overcome any protection
related problems. Files which are in use would still remain non-
deleteable. A /OVERRIDE qualifier could be implemented allowing
files in use to be marked for deletion and be removed from the
directory.
MORE MORE
This command would perform as expected: accept input on its stdin
stream and provide output on its stdout stream. The user response
(any keystroke) should be solicited on the stdcmd stream (i.e.,
SYS$COMMAND - no UNIX equivalent). Additionally, it should support
a subset of common text editor functions, allowing the user to
scroll back (<PREV SCREEN>) and forward (<NEXT SCREEN>) without
being subject to the current /PAGE=SAVE limitations.
================================================================================
Archive-Date: Thu, 29 Oct 1998 00:47:35 +0100
Message-ID: <1.5.4.32.19981028235642.006c0be4@snake.srv.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 28 Oct 1998 16:56:42 -0700
To: Free-VMS@lp.se
From: Kevin Handy <kth@srv.net>
Reply-To: Free-VMS@lp.se
Subject: Re: DCL External commands
I think that it would also be helpful to add to this table a list
of resources that are already available for anyone who wants to work
on something. It would also help to know how far along any particular
item is, and who is working on it.
At 03:04 PM 10/28/98 -0600, you wrote:
>Command Keyword or
> /Qualifier Image name
>---------------------------------------+-----------------------------------
>ACCOUNTING ACC
>
>APPEND COPY
>
>ANALYZE ANALYZOBJ
Resources: GNU binutils
> /AUDIT ANALAUDIT
> /CRASH_DUMP SDA
> /DISK_STRUCTURE VERIFY
> /ERROR_LOG ERF
> /IMAGE ANALYZOBJ
> /MEDIA ANALYZBAD
> /OBJECT ANALYZOBJ
> /PROCESS_DUMP ANALIMDMP
> /RMS_FILE ANALYZRMS
> /SYSTEM SDA
>
>BACKUP BACKUP
Resources: Free-VMS web page
>
>CONVERT CONVERT
> /RECLAIM RECLAIM
>
>COPY COPY
> /FTP OPENVMS$FTP
> /RCP OPENVMS$RCP
>
>CREATE CREATE
> /FDL CREATEFDL
>
DEBUG
>DELETE DELETE
> /CHARACTERISTIC QUEMAN
> /ENTRY QUEMAN
> /FORM QUEMAN
> /INTRUSION CIA
> /KEY cliroutine delkey
> /QUEUE QUEMAN
> /MANAGER QUEMAN
> /SYMBOL cliroutine delsym
>
>DIFFERENCES DIFF
>
>DIRECTORY DIRECTORY
> /APPLICATION_PROTOCOL=FTAM OSIF$DIR
> /FTP OPENVMS$FTPDIR
>
>DISABLE
> AUTOSTART QUEMAN
> QUEUE QUEMAN
>
>DISMOUNT DISMOUNT
>
>DUMP DUMP
>
>EDIT TPU
> /ACL ACLEDT
> /DPE DPE
> /EDT EDT
Resources: SEDIT ??
> /FDL EDF (EDF_TV)
> /SLP SUMSLP
> /SUM SUMSLP
> /TECO TECO (TECO32_TV)
Resources: The retrocomputing museum
> /TPU TPU
>
>ENABLE
> AUTOSTART QUEMAN
> QUEUE QUEMAN
>
>EXCHANGE EXCHANGE
> /NETWORK EXCHANGE$NETWORK
>
>HELP HELP
>
>INITIALIZE INIT
> /QUEUE QUEMAN
>
>INSTALL INSTALL
>
>LIBRARIAN LIBRARIAN
Resources: GNU Binutils
> /RSX11 BACKTRANS
>
>LICENSE LMF
> /GENERATE PAK$DIR:PAK$USER.EXE
>
>LINK LINK
Resources: GNU Binutils
>
>MACRO MACRO32 (or ALPHA_MACRO)
Resources: GNU as (binutils)
> /ALPHA MACRO64
> /MIGRATION ALPHA_MACRO
> /RSX11 BACKTRANS
> /VAX MACRO32
>
>MAIL MAIL
> /DECMAIL DECMAIL
> /SERVER MAIL_SERVER
>
>MESSAGE MESSAGE
>
>MONITOR MONITOR (MONITOR_TV)
>
>MOUNT VMOUNT
>
>PHONE PHONE
>
>PRINT SUBMIT
>
>RENAME RENAME
>
>REPLY REPLY
>
>REQUEST REQUEST
>
>RUN cliroutine run
> (Process) RUNDET
>
>
>RUNOFF RUNOFF
> /CONTENTS DSRTOC
> /INDEX DSRINDEX
>
>SET
> ACCOUNTING SET
> ACL SETSHOSECUR
> AUDIT SETAUDIT
> BROADCAST SET
> CARD_READER SET
> CLASSIFICATION SETSHOCLASS
> CLUSTER SET
> COMMAND CDU
> CONTROL_Y cliroutine setctly
> DAY SET
> DEVICE SET
> DEFAULT cliroutine setdefalt
> DIRECTORY
> /ACL SETSHOSECUR
> /CLASSIFICATION SETSHOCLASS
> /EDIT ACLEDT
> DISPLAY DECW$SETSHODIS
> ENTRY QUEMAN
> FILE
> /ACL SETSHOSECUR
> /CLASSIFICATION SETSHOCLASS
> /EDIT ACLEDT
> HOST RTPAD
> /BTS BTSLNK
> /DTE DTEPAD
> /DUP HSCPAD
> /HSC HSCPAD
> /LAT LTPAD
Isn't LAT patented so that you can't use it without a licesce?
I heard that DEC was keeping LAT tightly controlled (now owned by Meridian?).
If not, it would be really nice to be able to make use of old DecServers
on Free-VMS/*nix boxes.
> /MOP NET$CCR
> /RLOGIN OPENVMS$RLOGIN
> /SNA SNATERM
> /TELNET OPENVMS$TELNET
Resources: Steal from Linux/BSD/...
> /TN3270 OPENVMS$TN3270
> /VTP VTPAD
> /X29 PSIPAD
> KEY SET
> LANGUAGE SET
> LOGINS SET
> MAGTAPE SET
> MESSAGE SETP0
> ON cliroutine seton
> OUTPUT_RATE cliroutine setflush
> PASSWORD SETP0
> PREFIX cliroutine setprefix
> PRINTER SET
> PROCESS SET
> PROMPT cliroutine setprompt
> PROTECTION SET
> /DEFAULT cliroutine setprot
> RESTART_VALUE QUEMAN
> RMS_DEFAULT SET
> QUEUE QUEMAN
> RIGHTS_LIST SETRIGHTS
> SECURITY SETSHOSECUR
> SERVER SETSHOSERVER
> SYMBOL (cliroutine setsymbol)
> TEMPLATE SEVMS$SETSHOWTEMPLATE
> TERMINAL SET
> TIME SET
> UIC cliroutine setuic
> VERIFY cliroutine setverify
> WATCH SETWATCH
> WORKING_SET SET
>
>START
> /CPU SMPUTIL
> /QUEUE QUEMAN
> /ZONE FTSS$UTIL
>
>STOP
> /CPU SMPUTIL
> /ENTRY QUEMAN
> /QUEUE QUEMAN
> /ZONE FTSS$UTIL
/ID ?????
>
>SUBMIT SUBMIT
> /SNA SNASUBMIT
>
>SYNCHRONIZE QUEMAN
>
>TYPE TYPE
Didn't thay add a /PAGE option to type in later versions of VMS
(ala more)
>
>UNLOCK UNLOCK
>
>
>Additional Commands We Would Like to See:
>
>ARCHIVE
> /COMPRESS=
> GZIP GZIP
> TAR[BALL] CPIO?
> ZIP ZIP
BZIP BZIP2
bzip2 is also coming into common use
> /DECOMPRESS=
> GZIP GUNZIP
> TAR[BALL] CPIO?
> ZIP UNZIP
BZIP BUNZIP2
see above
>
>This command should support all the existing DCL-format qualifiers for
>ZIP and UNZIP. Both programs may need a modification to support the
>ARCHIVE verb. The GZIP and GUNZIP programs (usually two names for the
>same program - it supports both compress and decompress) may need
>modification to support the ARCHIVE verb and the CLI$ routines.
>Likewise, the CPIO program would need to be ported from BSD/Linux to
>VMS and have support added for the ARCHIVE verb and the CLI$ routines.
>
>As an alternative to the above qualifiers, a "dispatcher" program could
>be sensitive to the extension of the specified input/output file and
>invoke the appropriate (un)packager(s) (LIB$DO_COMMAND?).
>
>
>ASSEMBLE GAS
>
>This command is intended to invoke the Gnu Assembler directly, without
>using Gnu-C or Gnu-C++ as a cross-compiler. This could replace the
>MACROxx assembler. Presumably, there would be a suitable version of
>GAS available for each CPU supported by the Mach kernel.
>
>
>DELETE
> /TREE DELTREE
>
>This was discussed in the FreeVMS Mailing List. It is recommended
>that the DELTREE.EXE program _NOT_ be installed with privileges. The
>program should scan the files in the tree to ensure that there are
>no non-deletable files in any path in the tree _BEFORE_ any files
>are actually deleted. Suitably privileged users could then use the
>SET PROCESS/PRIVILEGE=BYPASS command to overcome any protection
>related problems. Files which are in use would still remain non-
>deleteable. A /OVERRIDE qualifier could be implemented allowing
>files in use to be marked for deletion and be removed from the
>directory.
>
>
>MORE MORE
>
LESS would also be nice/maybe even better
>This command would perform as expected: accept input on its stdin
>stream and provide output on its stdout stream. The user response
>(any keystroke) should be solicited on the stdcmd stream (i.e.,
>SYS$COMMAND - no UNIX equivalent). Additionally, it should support
>a subset of common text editor functions, allowing the user to
>scroll back (<PREV SCREEN>) and forward (<NEXT SCREEN>) without
>being subject to the current /PAGE=SAVE limitations.
>
Some common unix programs that would be nice, some of which
are already available for VMS
EDIT/EMACS EMACS
EDIT/VI VI
Two Common Unix editors
PING PING
Very usefull for debugging
Don't forget programming languages that should be added,
AWK
BASIC
BLISS
C
C++
COBAL
DIBOL
FOCAL
FORTH
FORTRAN
INTERCAL
JAVA
LISP
Objective C
PASCAL
PERL
PYTHON
And some comman add-ons
CDD
Datatreive
LATEX
TEX
Rdb
-------------------------------------------------------------
Kevin Handy kth@srv.net Accounting Software for
Software Solutions. Inc. VAX/VMS Computer Systems
Idaho Falls, Idaho
================================================================================
Archive-Date: Thu, 29 Oct 1998 11:23:23 +0100
Message-ID: <19981029102342.1553.qmail@hotmail.com>
From: "Steve Lindsey" <stevelindsey@hotmail.com>
Reply-To: Free-VMS@lp.se
To: Free-VMS@lp.se
Subject: Re: DCL External commands
Content-Type: text/plain
Date: Thu, 29 Oct 1998 02:23:41 PST
David (supplied verb - image cross reference)
Could you state which version this relates to
TIA
Steve Lindsey
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
================================================================================
Archive-Date: Thu, 29 Oct 1998 15:36:53 +0100
MIME-Version: 1.0
Date: Thu, 29 Oct 1998 08:26:25 -0600
Message-ID: <0001F842.eval@advocatehealth.com>
From: David.Dachtera@advocatehealth.com (David Dachtera)
Reply-To: Free-VMS@lp.se
Subject: Re[2]: DCL External commands
To: Free-VMS@lp.se, Kevin Handy <kth@srv.net>
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Kevin,
Do you have URLs for any of these "resources"?
David J. Dachtera
dba DJE Systems
______________________________ Reply Separator _________________________________
Subject: Re: DCL External commands
Author: Kevin Handy <kth@srv.net> at PO_EXTERNET
Date: 10/28/98 5:56 PM
I think that it would also be helpful to add to this table a list
of resources that are already available for anyone who wants to work
on something. It would also help to know how far along any particular
item is, and who is working on it.
At 03:04 PM 10/28/98 -0600, you wrote:
>Command Keyword or
> /Qualifier Image name
>---------------------------------------+-----------------------------------
>ACCOUNTING ACC
>
>APPEND COPY
>
>ANALYZE ANALYZOBJ
Resources: GNU binutils
> /AUDIT ANALAUDIT
> /CRASH_DUMP SDA
> /DISK_STRUCTURE VERIFY
> /ERROR_LOG ERF
> /IMAGE ANALYZOBJ
> /MEDIA ANALYZBAD
> /OBJECT ANALYZOBJ
> /PROCESS_DUMP ANALIMDMP
> /RMS_FILE ANALYZRMS
> /SYSTEM SDA
>
>BACKUP BACKUP
Resources: Free-VMS web page
>
>CONVERT CONVERT
> /RECLAIM RECLAIM
>
>COPY COPY
> /FTP OPENVMS$FTP
> /RCP OPENVMS$RCP
>
>CREATE CREATE
> /FDL CREATEFDL
>
DEBUG
>DELETE DELETE
> /CHARACTERISTIC QUEMAN
> /ENTRY QUEMAN
> /FORM QUEMAN
> /INTRUSION CIA
> /KEY cliroutine delkey
> /QUEUE QUEMAN
> /MANAGER QUEMAN
> /SYMBOL cliroutine delsym
>
>DIFFERENCES DIFF
>
>DIRECTORY DIRECTORY
> /APPLICATION_PROTOCOL=FTAM OSIF$DIR
> /FTP OPENVMS$FTPDIR
>
>DISABLE
> AUTOSTART QUEMAN
> QUEUE QUEMAN
>
>DISMOUNT DISMOUNT
>
>DUMP DUMP
>
>EDIT TPU
> /ACL ACLEDT
> /DPE DPE
> /EDT EDT
Resources: SEDIT ??
> /FDL EDF (EDF_TV)
> /SLP SUMSLP
> /SUM SUMSLP
> /TECO TECO (TECO32_TV)
Resources: The retrocomputing museum
> /TPU TPU
>
>ENABLE
> AUTOSTART QUEMAN
> QUEUE QUEMAN
>
>EXCHANGE EXCHANGE
> /NETWORK EXCHANGE$NETWORK
>
>HELP HELP
>
>INITIALIZE INIT
> /QUEUE QUEMAN
>
>INSTALL INSTALL
>
>LIBRARIAN LIBRARIAN
Resources: GNU Binutils
> /RSX11 BACKTRANS
>
>LICENSE LMF
> /GENERATE PAK$DIR:PAK$USER.EXE
>
>LINK LINK
Resources: GNU Binutils
>
>MACRO MACRO32 (or ALPHA_MACRO)
Resources: GNU as (binutils)
> /ALPHA MACRO64
> /MIGRATION ALPHA_MACRO
> /RSX11 BACKTRANS
> /VAX MACRO32
>
>MAIL MAIL
> /DECMAIL DECMAIL
> /SERVER MAIL_SERVER
>
>MESSAGE MESSAGE
>
>MONITOR MONITOR (MONITOR_TV)
>
>MOUNT VMOUNT
>
>PHONE PHONE
>
>PRINT SUBMIT
>
>RENAME RENAME
>
>REPLY REPLY
>
>REQUEST REQUEST
>
>RUN cliroutine run
> (Process) RUNDET
>
>
>RUNOFF RUNOFF
> /CONTENTS DSRTOC
> /INDEX DSRINDEX
>
>SET
> ACCOUNTING SET
> ACL SETSHOSECUR
> AUDIT SETAUDIT
> BROADCAST SET
> CARD_READER SET
> CLASSIFICATION SETSHOCLASS
> CLUSTER SET
> COMMAND CDU
> CONTROL_Y cliroutine setctly
> DAY SET
> DEVICE SET
> DEFAULT cliroutine setdefalt
> DIRECTORY
> /ACL SETSHOSECUR
> /CLASSIFICATION SETSHOCLASS
> /EDIT ACLEDT
> DISPLAY DECW$SETSHODIS
> ENTRY QUEMAN
> FILE
> /ACL SETSHOSECUR
> /CLASSIFICATION SETSHOCLASS
> /EDIT ACLEDT
> HOST RTPAD
> /BTS BTSLNK
> /DTE DTEPAD
> /DUP HSCPAD
> /HSC HSCPAD
> /LAT LTPAD
Isn't LAT patented so that you can't use it without a licesce?
I heard that DEC was keeping LAT tightly controlled (now owned by Meridian?).
If not, it would be really nice to be able to make use of old DecServers
on Free-VMS/*nix boxes.
> /MOP NET$CCR
> /RLOGIN OPENVMS$RLOGIN
> /SNA SNATERM
> /TELNET OPENVMS$TELNET
Resources: Steal from Linux/BSD/...
> /TN3270 OPENVMS$TN3270
> /VTP VTPAD
> /X29 PSIPAD
> KEY SET
> LANGUAGE SET
> LOGINS SET
> MAGTAPE SET
> MESSAGE SETP0
> ON cliroutine seton
> OUTPUT_RATE cliroutine setflush
> PASSWORD SETP0
> PREFIX cliroutine setprefix
> PRINTER SET
> PROCESS SET
> PROMPT cliroutine setprompt
> PROTECTION SET
> /DEFAULT cliroutine setprot
> RESTART_VALUE QUEMAN
> RMS_DEFAULT SET
> QUEUE QUEMAN
> RIGHTS_LIST SETRIGHTS
> SECURITY SETSHOSECUR
> SERVER SETSHOSERVER
> SYMBOL (cliroutine setsymbol)
> TEMPLATE SEVMS$SETSHOWTEMPLATE
> TERMINAL SET
> TIME SET
> UIC cliroutine setuic
> VERIFY cliroutine setverify
> WATCH SETWATCH
> WORKING_SET SET
>
>START
> /CPU SMPUTIL
> /QUEUE QUEMAN
> /ZONE FTSS$UTIL
>
>STOP
> /CPU SMPUTIL
> /ENTRY QUEMAN
> /QUEUE QUEMAN
> /ZONE FTSS$UTIL
/ID ?????
>
>SUBMIT SUBMIT
> /SNA SNASUBMIT
>
>SYNCHRONIZE QUEMAN
>
>TYPE TYPE
Didn't thay add a /PAGE option to type in later versions of VMS
(ala more)
>
>UNLOCK UNLOCK
>
>
>Additional Commands We Would Like to See:
>
>ARCHIVE
> /COMPRESS=
> GZIP GZIP
> TAR[BALL] CPIO?
> ZIP ZIP
BZIP BZIP2
bzip2 is also coming into common use
> /DECOMPRESS=
> GZIP GUNZIP
> TAR[BALL] CPIO?
> ZIP UNZIP
BZIP BUNZIP2
see above
>
>This command should support all the existing DCL-format qualifiers for
>ZIP and UNZIP. Both programs may need a modification to support the
>ARCHIVE verb. The GZIP and GUNZIP programs (usually two names for the
>same program - it supports both compress and decompress) may need
>modification to support the ARCHIVE verb and the CLI$ routines.
>Likewise, the CPIO program would need to be ported from BSD/Linux to
>VMS and have support added for the ARCHIVE verb and the CLI$ routines.
>
>As an alternative to the above qualifiers, a "dispatcher" program could
>be sensitive to the extension of the specified input/output file and
>invoke the appropriate (un)packager(s) (LIB$DO_COMMAND?).
>
>
>ASSEMBLE GAS
>
>This command is intended to invoke the Gnu Assembler directly, without
>using Gnu-C or Gnu-C++ as a cross-compiler. This could replace the
>MACROxx assembler. Presumably, there would be a suitable version of
>GAS available for each CPU supported by the Mach kernel.
>
>
>DELETE
> /TREE DELTREE
>
>This was discussed in the FreeVMS Mailing List. It is recommended
>that the DELTREE.EXE program _NOT_ be installed with privileges. The
>program should scan the files in the tree to ensure that there are
>no non-deletable files in any path in the tree _BEFORE_ any files
>are actually deleted. Suitably privileged users could then use the
>SET PROCESS/PRIVILEGE=BYPASS command to overcome any protection
>related problems. Files which are in use would still remain non-
>deleteable. A /OVERRIDE qualifier could be implemented allowing
>files in use to be marked for deletion and be removed from the
>directory.
>
>
>MORE MORE
>
LESS would also be nice/maybe even better
>This command would perform as expected: accept input on its stdin
>stream and provide output on its stdout stream. The user response
>(any keystroke) should be solicited on the stdcmd stream (i.e.,
>SYS$COMMAND - no UNIX equivalent). Additionally, it should support
>a subset of common text editor functions, allowing the user to
>scroll back (<PREV SCREEN>) and forward (<NEXT SCREEN>) without
>being subject to the current /PAGE=SAVE limitations.
>
Some common unix programs that would be nice, some of which
are already available for VMS
EDIT/EMACS EMACS
EDIT/VI VI
Two Common Unix editors
PING PING
Very usefull for debugging
Don't forget programming languages that should be added,
AWK
BASIC
BLISS
C
C++
COBAL
DIBOL
FOCAL
FORTH
FORTRAN
INTERCAL
JAVA
LISP
Objective C
PASCAL
PERL
PYTHON
And some comman add-ons
CDD
Datatreive
LATEX
TEX
Rdb
-------------------------------------------------------------
Kevin Handy kth@srv.net Accounting Software for
Software Solutions. Inc. VAX/VMS Computer Systems
Idaho Falls, Idaho
================================================================================
Archive-Date: Thu, 29 Oct 1998 15:36:57 +0100
MIME-Version: 1.0
Date: Thu, 29 Oct 1998 08:25:27 -0600
Message-ID: <0001F841.eval@advocatehealth.com>
From: David.Dachtera@advocatehealth.com (David Dachtera)
Reply-To: Free-VMS@lp.se
Subject: Re[2]: DCL External commands
To: Free-VMS@lp.se, "Steve Lindsey" <stevelindsey@hotmail.com>
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
The list was drawn from V6.1, the highest version
permitted under the Hobbyist license. I omitted those
qualifiers that did not tend to change the IMAGE,
since my thrust was to create some kind of program
list, not a detailed analysis.
The differences between V6.1 and V5.5-2 are minor, but
irritating (like TYPE/TAIL, DIRECTORY/PAGE=SAVE and SET
FILE/ATTRIBUTE). Unless hardware limits you, I don't
personally recommend running anything lower than V5.5-2,
although application software may demand that you do
otherwise. V5.4-2 and V5.3-2 are also very stable, but
lack some key functionality. Also, Stand-alone BACKUP in
earlier versions will hang if you try to use the /LOG
qualifier when doing stand-alone saves or restores.
I don't know how this would tend to "poison" any
potential contributors (from a copyright standpoint), but
the .CLD files can be found in the .A saveset of most any
VMS distribution. DCLINT.CLD, as the name suggests, is
the basic foundation. Others found there expand this into
the uncustomized VMS we all know and love. For any
version, you can find out what commands and qualifiers
are available by examining these files. Note that this
will include most of the "undocumented" qualifiers, where
the .HLP and .HLB files will contain info. only on the
documented commands and qualifiers, and are sometimes out
of sync. with the hardcopy documentation.
David J. Dachtera
dba DJE Systems
______________________________ Reply Separator _________________________________
Subject: Re: DCL External commands
Author: "Steve Lindsey" <stevelindsey@hotmail.com> at PO_EXTERNET
Date: 10/29/98 4:23 AM
David (supplied verb - image cross reference)
Could you state which version this relates to
TIA
Steve Lindsey
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com