Editing DCL command lines longer than the current terminal width
Simon Clubley
longer than the current terminal width ?
Having just spent a good chunk of the weekend editing long command lines
(as part of some application testing), it is my opinion [currently, Not
So Humble :-)] that the inability to fully edit DCL command lines longer
than the current terminal width is now unacceptable.
What do other people think ?
I am aware from previous discussions that there is a problem within the
terminal driver, but I find it hard to believe that it can be _that_
difficult to fix.
I am also aware (on terminal emulators with the ability to set long
widths) that you can play tricks with set term/width, but playing tricks
in order to accomplish tasks is what we accuse other operating systems
of doing. In VMS, this should just work.
Simon.
PS: Just had an idea: Does the VMS port of bash (for people without Unix
experience, it's a Unix CLI) allow you to edit command lines longer than
the current terminal width, and if so, can you get it to execute DCL
commands ?
--
Simon Clubley, simon_clubley@remove_me.altavista.co.uk-Earth.UFP
In the task of removing Microsoft from the marketplace, I have discovered a
truly remarkable plan, but this signature is too small to contain it.
Phillip Helbig
allow one to edit lines longer than the terminal width at the prompt, so
it CAN be done.
Note that the problem occurs not just at the DCL prompt, but e.g. at the
MAIL prompt as well. It should of course be fixed everywhere.
Dave Kneitel
to edit beyond the terminal width - terminal emulators do not (in VMS or
unix).
"Simon Clubley" <simon_clubley@remove_me.altavista.co.uk-Earth.UFP> wrote in
message news:nuwF7.13058$xS6....@www.newsranger.com...
JF Mezei
>
> Are there any plans to fix the inability to fully edit DCL command lines
> longer than the current terminal width ?
$SET TERM/WIDTH=132
$RECALL command
edit command
run command
$SET TERM/WIDTH=80
If you are using decwindows, there are easier ways with the mouse that make it
possible to send the first portion, edit it, and then send the second portion.
And with 7.2, you can also save and recall your command buffer. Perhaps you
can save your recall buffer, edit it, save it, and then get DCL to read that
recall buffer with the corrected long command. (HELP RECALL ) Again, with
multiple windows, it is fairly easy to do.
Simon Clubley
JF Mezei wrote:
>
>Simon Clubley wrote:
>>
>> Are there any plans to fix the inability to fully edit DCL command lines
>> longer than the current terminal width ?
>
>$SET TERM/WIDTH=132
>$RECALL command
>edit command
>run command
>$SET TERM/WIDTH=80
Thanks for the response JF, but I am already familiar with the various
workarounds that you mentioned. All the possible options are cumbersome
and as I already mentioned, I don't think that we should have to mess
around like this...
Simon.
Simon Clubley
<6uxF7.27908$D7.82...@news02.optonline.net>, Dave Kneitel wrote:
>
>Are you connecting via Xwindows or a terminal emulator - Xwindows allows you
>to edit beyond the terminal width - terminal emulators do not (in VMS or
>unix).
>
Hello,
Which X-Windows access method are you thinking of, apart from a terminal
session, that gives you access to a DCL prompt ? Even on X-Windows, you
still run a terminal emulator to get a DCL prompt. It's the operating
system, not the terminal emulator, that controls the editing of the
command line.
BTW, on Linux, using bash, you _can_ edit command lines that are longer than
than the current terminal width; I do it all the time.
Further comments welcome,
Simon.
John Reagan
> PS: Just had an idea: Does the VMS port of bash (for people without Unix
> experience, it's a Unix CLI) allow you to edit command lines longer than
> the current terminal width, and if so, can you get it to execute DCL
> commands ?
>
I just tried my latest bash. I typed a very long command that wrapped to
the next line. The left-arrow key would go back from the 2nd line to
the first. I could add additional non-space characters and the rest of
the command line would push out as expected. However, when I tried to
insert spaces or tabs, the resulting command line was garbled. I didn't
spend any time trying to track down the reason.
--
John Reagan
Compaq Pascal/{A|I}MACRO Project Leader
Tom Linden
Nic Clews
> > I just tried my latest bash. I typed a very long command that wrapped to
bash is also a colloquialism for 'having a go'
when I was at school it also meant physical retribution.
it also means a get-together or party where most carbon based
participants will be suffering from the after effects of alcohol,
although alcohol is not compulsory for having a bash.
The Bourne Again SHell of which you speak perhaps was put together
during one or a combination of all three of the above.
--
Regards, Nic Clews CSC Computer Sciences
nclews at csc dot com
Steve Thompson
> Are there any plans to fix the inability to fully edit DCL command lines
> longer than the current terminal width ?
>
> Having just spent a good chunk of the weekend editing long command lines
> (as part of some application testing), it is my opinion [currently, Not
> So Humble :-)] that the inability to fully edit DCL command lines longer
> than the current terminal width is now unacceptable.
>
> What do other people think ?
> [...]
Right. Pet peeve. This was unacceptable from day one.
steve
Mark Daniel
>
> Are there any plans to fix the inability to fully edit DCL command lines
> longer than the current terminal width ?
>
> Having just spent a good chunk of the weekend editing long command lines
> (as part of some application testing), it is my opinion [currently, Not
> So Humble :-)] that the inability to fully edit DCL command lines longer
> than the current terminal width is now unacceptable.
>
> What do other people think ?
Strongly agree. It's embarressing in front of my U*x colleagues.
--
Non sinere illegitamus carborundum.
Keith Parris
> longer than the current terminal width ?
Hear, hear! This has been one of those little nagging annoyances to
me for a long, long time, and I would greatly welcome a fix. I've
often used the workaround of switching to 132-column mode, but that
only helps if the command is under 132 columns in length.
I'd even be happy to settle for a partial fix (for example, it might
work with DECterms but not all brands of video terminals) -- that
would be OK.
-------------------------------------------------------------------
Keith Parris | parris at encompasserve dot org | VMS consulting on:
Clusters, Disaster Tolerance, Internals, Performance, Storage & I/O
Mark Daniel
As well as an inconvenient in practice (he adds as an afterthought :^)
David J. Dachtera
>
> Mark Daniel wrote:
> >
> > Simon Clubley wrote:
> > >
> > > Are there any plans to fix the inability to fully edit DCL command lines
> > > longer than the current terminal width ?
> > >
> > > Having just spent a good chunk of the weekend editing long command lines
> > > (as part of some application testing), it is my opinion [currently, Not
> > > So Humble :-)] that the inability to fully edit DCL command lines longer
> > > than the current terminal width is now unacceptable.
> > >
> > > What do other people think ?
> >
> > Strongly agree. It's embarressing in front of my U*x colleagues.
>
> As well as an inconvenient in practice (he adds as an afterthought :^)
Well, o.k. Understand what you're asking for here. In VMS terms, ...
When a <DEL> is received and the cursor is already at column 1, somehow
you must accomplish *ALL* of the following:
1. Move the cursor to the end of the previous display line. Issue an
ASCII space (cursor should wrap to the next display line).
2. Read and store the character under the cursor.
3. If the terminal supports display editing, you must request the
terminal to delete the character under the cursor and "collapse" the
line (shift everything over one byte toward the cursor position so that
the character that was in column two(2) is now under the cursor which
should remain at column one(1)). If the terminal does not support
display editing, you must issue an "erase to end of line" sequence and
repaint that line on the screen minus the first character.
(What if there's more than two display lines? Starting to get the idea
that this is not as simple as it seems?)
4. Move the cursor to the end of the previous display line. Issue the
character that was stored at step 2. The cursor should wrap to the next
display line. Move the cursor to the end of the previous display line.
...and while doing the above, edit the command line buffer to accurately
reflect this manipulation.
Starting to get the picture now?
What if it's a *REALLY* long line and wraps to a total of three display
lines? What then?
My advice would be to get the VMS source listings, find the code that
needs a fix, write and test the fix, and donate the code to OpenVMS
engineering to see if they will implement it.
Long shot at best, but worth a try if you think you're up to the
challenge.
Yes, I understand that VMS is not open source. Why let that stand in
your way? Do you want this fixed or not?
--
David J. Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/
Larry Kilgallen
> When a <DEL> is received and the cursor is already at column 1, somehow
> you must accomplish *ALL* of the following:
<snip the details>
> What if it's a *REALLY* long line and wraps to a total of three display
> lines? What then?
That was a nice summary.
> My advice would be to get the VMS source listings, find the code that
> needs a fix, write and test the fix, and donate the code to OpenVMS
> engineering to see if they will implement it.
If the fix works for all cases, I think they will be grateful.
If it was easy, they probably would have done it by now.
Phillip Helbig
As I've pointed out before, the NEWSRDR program, which has a very VMS
look and feel (similar to VMS MAIL---which of course also has the
edit-long-lines problem), has no problem in this area, so it can't be
THAT difficult.
Fred Kleinsorge
functionality, and nobody has wanted to try and tackle the multi-line
editing problem in the terminal driver. If DCL were doing it all itself,
then the task would be far simpler.
BTW - in a DECterm, you can handle lines as wide as 256 characters (the
widest width set term/width supports). Set your terminal width to 256, go
into OPTIONS->DISPLAY and enable horizontal synch and the horizontal scroll
bar.
_Fred
Phillip Helbig wrote in message
<01KAI0DSH...@sysdev.deutsche-boerse.com>...
Phillip Helbig
> Phillip Helbig wrote in message
> <01KAI0DSH...@sysdev.deutsche-boerse.com>...
> > > Well, o.k. Understand what you're asking for here. In VMS terms, ...
> >
> >As I've pointed out before, the NEWSRDR program, which has a very VMS
> >look and feel (similar to VMS MAIL---which of course also has the
> >edit-long-lines problem), has no problem in this area, so it can't be
> >THAT difficult.
>
> The problem is that DCL relies on the terminal driver for this
> functionality, and nobody has wanted to try and tackle the multi-line
> editing problem in the terminal driver. If DCL were doing it all itself,
> then the task would be far simpler.
>
> BTW - in a DECterm, you can handle lines as wide as 256 characters (the
> widest width set term/width supports). Set your terminal width to 256, go
> into OPTIONS->DISPLAY and enable horizontal synch and the horizontal scroll
> bar.
How many lines of code (in what language) is the terminal driver?
Is it a bug or feature that DCL relies on the terminal driver?
Was there a reason not to have this in the terminal driver, or was it
just an oversight?
I guess I could fire up NEWSRDR and get into the habit of typing SPAWN
before each command. :-)
Rob Brooks
> Fred wrote:
>>
>> The problem is that DCL relies on the terminal driver for this
>> functionality, and nobody has wanted to try and tackle the multi-line
>> editing problem in the terminal driver. If DCL were doing it all itself,
>> then the task would be far simpler.
>>
> Is it a bug or feature that DCL relies on the terminal driver?
> Was there a reason not to have this in the terminal driver, or was it
> just an oversight?
TTDRIVER is built from a few modules written in Macro-32. It
was a design decision that the command-line editing is done in the driver.
This decision was made, of course, back in the early 80's, when
command-line editing came about in VAX/VMS (V4.0?).
The goal of the VAX-to-Alpha port was bug-for-bug compatibility; it
is likely this will be the goal of the Alpha-to-Itanium port. In other
words, while VMS Engineering agrees that the command-line editing scheme
should be re-worked, it is unlikely to get done, except as a
midnight (unfunded) project before the Itanium port.
--
Rob Brooks VMS Engineering -- I/O Exec Group brooks!cuebid.zko.dec.com
Forrest Kenney
> How many lines of code (in what language) is the terminal driver?
>
The bulk of the line editing code is in the module ttycharo.mar but not
all of it. I just look it is on the order of 4600 lines of some of the ugliest
macro code you are going to find. All of this logic happens at DEVICE
IPL in kernel mode.
While you are at it you need to make it work for VAX, Alpha, and with
an eye toward the future IPF. Also you have to make sure that it does not
break Asian versions of VMS and their multi-byte support. For fun and
extra bonus points you had better not break any funky undocumented
quirks in the driver that users depend upon, or for that matter third party
intercept drivers rely on.
Yup easy, if it were easy and simple with low system impact it would
have been done a long time ago. All you need is a simple editor. To keep
the code reasonable and the performance acceptable a real minimal editor
was added into the terminal driver. It was minimal on purpose.
>
> Is it a bug or feature that DCL relies on the terminal driver?
When it was done it was considered a feature. Put it at the lowest
level make it work at as low a cost as practical and everybody gets it
for free. Put it anyplace else and now you can end up with many versions
of the code.
>
> Was there a reason not to have this in the terminal driver, or was it
> just an oversight?
One reason was given above. Remember that VMS is record oriented so
things like DCL don't see any data until a terminator for the record is seen.
Unix is just the opposite it is character oriented just like most editors. So
you
want to edit a command line fork off an editor let it edit the command and
when it is done pipe it back to the shell for execution.
Different models and when the editing stuff was put into the O.S. it was
placed the the most logical place for the most users to get it at the least
cost.
Lots have changed since then not the least of which is the resources
VMS has to do things. Back when the editing was done there was one
person who did nothing but terminal driver work. Plus there were two or
three folks around who really knew the design of the code. Now there is no
developer that takes care of it full time. If something breaks somone will
hunt the problem down and fix it.
Forrest Kenney
OpenVMS
Gotfryd Smolik, VMS lists
[...]
>+Is it a bug or feature that DCL relies on the terminal driver?
Feature. Definitely.
Have you anytime work thru WAN with really slow/overloaded
connection ? If yes - then you must know the differrence
between character oriented and record oriented "line edit".
In the first you wait (b.ex. 2 seconds) for *any* character
sent, for the second all editing is done *liocally*[1], you
must "wait to see what happens" only line-by-line.
[1] - suposing the terminal or local computer is able
doing "line edit".
*Today* the feature may not be a primary requirement :)
>+Was there a reason not to have this in the terminal driver, or was it
>+just an oversight?
Full screen editing ??
Probably none of VT-series can edit "multiline", then here
was no reason to control the feature in driver... IMHO.
Regards - Gotfryd
--
=====================================================================
$ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") -
THEN EXCUSE/OBJECT=ME
$! G...@stanpol.zabrze.pl
=====================================================================
David Mathog
>
> The problem is that DCL relies on the terminal driver for this
> functionality, and nobody has wanted to try and tackle the multi-line
> editing problem in the terminal driver. If DCL were doing it all itself,
> then the task would be far simpler.
So send something zinging past the terminal driver so that DCL (or any
program it chooses to invoke) can do it all. If DCL would let you call
up an editor and run what comes out of it then the problem would be
solved. Effectively it would be the equivalent of:
$ edit commands.com ! no line length problem if you use the right
editor
$ @commands ! DCL in general should accept longer command lines
too, but that's just a buffer thing
$ del commands.com; ! clean up
All that's needed is a trigger to let DCL do this. Once you're in the
editor an EXIT runs the line or lines in the editor buffer, a QUIT
(empty or no output file) does nothing.
You can pretty much do this now by wrapping the 3 lines above in a .com
and defining a command to run it. Except that up arrow or recall # is a
pain. The recall case should be the easiest of all to fix, just
add something like:
$ recall/edit 10
The up arrow case is harder.
$ (up/down arrow one or many times)
$ some very long command
which wraps
and is therefore
a pain in the butt
Now what? You can't get up to the front of the line to put, for
instance "ec" (edit command)
there - that's what started this whole thread. You can pull a few
tricks to search through the recall
buffer to find the number, but that's awkward. In this one case some
other workaround is required. The up/down arrows go through recall (or
are in some way linked to it) so all that's really needed is one other
key that will pass through the terminal driver and into DCL. For the
sake of argument, let that
be ^E (edit) then you could do:
$ (up/down arrow one or many times)
$ ^E
and this turns into the equivalent of
$ recall/edit 1
and you're all set.
Regards,
David Mathog
mat...@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech
Paul Sture
appear to be ignored, and don't garble anything.
___
Paul Sture
Switzerland
Joe Heimann
> Phillip Helbig <HEL...@sysdev.deutsche-boerse.com> writes:
>> Fred wrote:
>>>
>>> The problem is that DCL relies on the terminal driver for this
>>> functionality, and nobody has wanted to try and tackle the multi-line
>>> editing problem in the terminal driver. If DCL were doing it all itself,
>>> then the task would be far simpler.
>>>
>> How many lines of code (in what language) is the terminal driver?
>> Is it a bug or feature that DCL relies on the terminal driver?
>> Was there a reason not to have this in the terminal driver, or was it
>> just an oversight?
> TTDRIVER is built from a few modules written in Macro-32. It
> was a design decision that the command-line editing is done in the driver.
> This decision was made, of course, back in the early 80's, when
> command-line editing came about in VAX/VMS (V4.0?).
Possibly in V4.2, as I recall that was when the TT driver changed how
it worked. Remember it because it broke the handling of flow control
for a couple of Diablo 630 ECS daisy wheel printers we had connected
to serial ports. Since we used carbon film ribbons, they stopped and
paused for the ribbon to be changed. Before 4.2 the flow control was
able to stop and restart without "splitting" the escape sequences for
the extended characters. After, once the printer buffer filled, the
sequences were messed up and we could get garbage printed out. We
ended up using a workaround of dropping the data rate from 9600 to
1200 bps. That gave us a short period of time before the buffer was
full. Got pretty good at swapping a ribbon in 15 seconds.
> The goal of the VAX-to-Alpha port was bug-for-bug compatibility; it
> is likely this will be the goal of the Alpha-to-Itanium port. In other
> words, while VMS Engineering agrees that the command-line editing scheme
> should be re-worked, it is unlikely to get done, except as a
> midnight (unfunded) project before the Itanium port.
Joe Heimann
Patrick Young
> > How many lines of code (in what language) is the terminal driver?
> >
>
> The bulk of the line editing code is in the module ttycharo.mar but not
> all of it. I just look it is on the order of 4600 lines of some of the
> ugliest
I would *not* call it ugly. A job needed to be done at the time, it does
it well.
> macro code you are going to find. All of this logic happens at DEVICE
> IPL in kernel mode.
>
Having just taken a look at it and noted that you have provided a lot
of work into it - I can understand your feelings and agree. The QA
involved in changing a line of that code must be interesting.
It is a foundation on top of which many "houses of cards" have been built.
You are right - the IA64 port puts this request in the "maybe later"
department.
During a port it is one of the last things you (or anyone in their right
mind) would want to mess with.
Gabriel Sterk
>
> Are there any plans to fix the inability to fully edit DCL command lines
> longer than the current terminal width ?
>
> Having just spent a good chunk of the weekend editing long command lines
> (as part of some application testing), it is my opinion [currently, Not
> So Humble :-)] that the inability to fully edit DCL command lines longer
> than the current terminal width is now unacceptable.
>
> What do other people think ?
Agreed.
Worked in the 1980's with an opsys (Honeywell CP-6), which worked
perfectly with the dumbest of terminals, like ADM3's and the more intelligents:
VT's & Tattungs.
Gabriel Sterk
JF Mezei
> Worked in the 1980's with an opsys (Honeywell CP-6), which worked
> perfectly with the dumbest of terminals, like ADM3's and the more intelligents:
> VT's & Tattungs.
Actually, perhaps this is it. If you set the terminal to autowrap and such
that a backspace at the column 1 results in cursor going to last column of
previous line, then the operating system wouldn't really know what was going
on as you were backspacing through a long line which the OS would think were
on a single line.
However, when you consider editing commands such as <CTRL-U> which erases to
beginning of line, it wouldn't work properly in that scenario since it would
only erase rto rge beginning of the second line, letting you think that the
first line was still there when in fact it wouldn't be.
Perhaps the VMS guys should assign a VT sequence to get DECTERM to QUICKLY pop
up a window into which the long command would be displayed and editable
locally, and when you press OK, it is then sent to the remote host as if you
had typed it. Inside of a local window, the text would appear as a single long
string which the window would wrap to fit the window without inserting
anything inside the string.
Welsh, John
Simon,
You can edit lines up to the max line length of 255
characters
which exceed the terminal width ( 80 or 132 ) by doing the
following:
At the edit asterisk prompt ( * ) type SET NOTRUNC then type C to
enter edit mode.
John Welsh.
Integration Manager.
AVNET Computer Marketing.
Enterprise Solutions Division.
Unit A, 22-24 College St.
Gladesville. NSW. 2111.
Phone: 02 8877 0752
Fax: 02 8877 0720
mailto:john....@avnet.com
-----Original Message-----
From: Simon Clubley
[SMTP:simon_clubley@remove_me.altavista.co.uk-Earth.UFP]
Sent: Tuesday, 6 November 2001 12:29
To: Info...@Mvb.Saic.Com
Subject: Editing DCL command lines longer than the current
terminal width
Are there any plans to fix the inability to fully edit DCL command
lines
longer than the current terminal width ?
Having just spent a good chunk of the weekend editing long command
lines
(as part of some application testing), it is my opinion [currently,
Not
So Humble :-)] that the inability to fully edit DCL command lines
longer
than the current terminal width is now unacceptable.
What do other people think ?
I am aware from previous discussions that there is a problem within
the
terminal driver, but I find it hard to believe that it can be _that_
difficult to fix.
I am also aware (on terminal emulators with the ability to set long
widths) that you can play tricks with set term/width, but playing
tricks
in order to accomplish tasks is what we accuse other operating
systems
of doing. In VMS, this should just work.
Simon.
PS: Just had an idea: Does the VMS port of bash (for people without
Unix
experience, it's a Unix CLI) allow you to edit command lines longer
than
the current terminal width, and if so, can you get it to execute DCL
commands ?
--
Paul Repacholi
Or TECO, and it can/could delete back over a line ending with no trouble...
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.
Paul Repacholi
> Right. Pet peeve. This was unacceptable from day one.
But it was not a day one problem :) It only became a problem
when it was added cause all you ungratfull wretches bitched
that you could not edit program input like you could at a DCL prompt.
(or at least that's how I remember it...)
Paul Repacholi
> > Strongly agree. It's embarressing in front of my U*x colleagues.
> As well as an inconvenient in practice (he adds as an afterthought :^)
You should not be, Unix's terminal code can't edit anything to save
it life! Most of the shells can, but that does not help the other
applications. The TT driver one line edit was done so there was
still some editing for apps when DCL is out of the picture.
The editing in DCL is another whole ball of wax...
Mark Daniel
Woops. Had no idea that such *seemingly* inconsequential functionality
would require a significant rewrite of core kernel architecture.
Perhaps this new functionality should only be seriously considered after
the IA64 port has settled down a little.
I profited from the analysis right up to the "My advice.." which
thereafter seemed to have a decidedly familiar ascerbic tone to it.
Whilst making a premium outlay for a premium product I would have
thought the vendor might consider making the appropriate changes to
their product if there was a significant demand, hence the hand up
during the straw poll. If open source then it's a whole different
story.
I *did* imagine that some sort of algorithm might need to be employed in
resolving the issue of removing or inserting the character from display
and input buffer but having designed and implemented non-trivial
algorithms myself just assumed that that this might a necessary step in
achieving the objective once the decision had been made.
If U*x shells can manage it ...
While I'm taking time out for this I might add another request related
to the command-line, a command buffer exceeding 255 characters, perhaps
even something approaching the design limits of the $dsc string
structures. I understand that this is much, much more non-tivial :^)
but still desirable. Goodness knows how much more complex this will
make multi-line command editing. Let's see 65535 / 80 ~= 819 lines / 24
~= 34 screens. Nah, I can't wait for my terminal emulator to manage the
refresh, forget the command-line editing issue, much too complex, just
give us a bigger command buffer.
<end_note>
--
Non sinere illegitamus carborundum.
Alan Greig
wrote:
>Mark Daniel <Mark....@wasd.vsm.com.au> writes:
>
>> > Strongly agree. It's embarressing in front of my U*x colleagues.
>
>> As well as an inconvenient in practice (he adds as an afterthought :^)
>
>You should not be, Unix's terminal code can't edit anything to save
>it life! Most of the shells can, but that does not help the other
>applications. The TT driver one line edit was done so there was
>still some editing for apps when DCL is out of the picture.
>
>The editing in DCL is another whole ball of wax...
Perhaps someone could implement the TOPS-20 TEXTI and COMND JSYS
(system services) during the IA64 port.... If DEC could get it right
in the mid 70s there's no excuse for VMS today. The excuse back then
for making it a non-goal was that Dave Cutler didn't like the
overhead. No I don't really expect this to be done for the IA64 port
but the lack of a COMND style command interface still irks me to this
day, TOPS-20 from around V5 onwards also supported VMS style command
line editing *and* EMACS like command line editing.
From http://www.opost.com/dlm/tenex/hbook.html
Origins and Development of TOPS-20
by Dan Murphy
Copyright (c) 1989, 1996 - Dan Murphy
The COMND Service
Another interesting step was the development of the COMND JSYS. This
system call provides a set of services to implement the TOPS-20 style
of command interface (escape recognition, question-mark help, etc. as
discussed previously). It was not, however, part of TENEX as it came
from BBN. Rather, those interface characteristics were individually
coded in each program that supported them, and in fact, only the EXEC
supported them in general. Other programs typically supported only
recognition of file names, since that was provided by the GTJFN system
call. Even basic command line editing (rubout to delete a character,
control-U to erase the line, etc.) was not centralized and was
provided more or less or not at all by various programs.
The need for centralized command line editing was addressed earlier in
the TOPS-20 development by the addition of the TEXTI JSYS (and related
subsets RDTXT and RDLINE). The increasing use of video terminals had
made the ad hoc provisions of the various utility programs
particularly glaring. With TEXTI, we undertook to both centralize the
line editing functions and to make them sensitive to the type of
terminal being used. At that time, taking advantage of the video
terminal's ability to erase a character or line was still impressive.
Some systems had been able to add at least a minimum of video terminal
line editing support because they only supported line input, and the
line buffering was done centrally. TENEX had been designed with a
maximum of terminal flexibility however and so had no general way of
editing input. The TEXTI JSYS provided many options so that it could
be used as well by programs that wanted more or less than
line-at-a-time input.
Implementing a centralized command input library was not, however, an
item that appeared on our schedules. Within the last year before the
system shipped, we had identified and were working on a few utility
programs that needed specific improvements. One of these was DUMPER
(the disk-to-tape backup and restore utility), and it had a
particularly bad command interface. I had the task of improving
DUMPER's user interface to meet some minimal level of acceptability,
but I had been procrastinating doing anything about it because it
would be a rather routine and boring task. In the meantime, I had
started thinking about how this style of command interface could be
centralized into a set of functions and tables.
Because of the highly interactive nature of the interface, partial
execution of the program itself is necessary during input of the
command. For example, if file name recognition is attempted, the
defaults and any other pertinent context must be available so that
failure or success can be determined. However, the program must not
take any irrevocable action until the command is confirmed (typically
with a carriage return) so that the user can erase all or part of it
with the line editing keys. Even the original TENEX Exec didn't get
this quite right. The user could erase the entire command line with
control-U, but could not delete backward more than the current field.
In other words, the Exec knew how to flush all state for the current
line and start over, and it knew how to delete characters from the
current field before it was completed, but it didn't know how to flush
part of the state and backup into a field already completed.
My idea for solving the backup problem was not to backup at all but
rather save the command text and then rescan it from the beginning
with the unwanted part removed. With that idea and a list of functions
to handle the various kinds of fields that would occur in a command
line, I started writing a library-type facility instead of just point
enhancements to DUMPER. Of course, DUMPER was intended to be, and did
become, the first program to use new facility, but by the time of
TOPS-20's first release, these command parsing routines had been
integrated into the monitor as the COMND JSYS. Most utilities had not
been modified to use it however, and the Exec still had its original
parsing code. Correcting all this was done in later releases.
===== END QUOTED ARTICLE=====
Btw. One of the three available PDP-10 emulators (KLH) now has full
KL-10 support and can boot TOPS-20 V7. Previously available emulator
KS-10 support limited us to TOPS-20 V4.1. Supposedly the ethernet code
is working and supporting TOPS-20 TCPIP V4 through the host system but
haven't had a chance to try it yet. That means telnet, ftp, smtp mail
should all be usable. See alt.sys.pdp10 for details.
--
Alan
Bob Koehler
>
> Perhaps someone could implement the TOPS-20 TEXTI and COMND JSYS
> (system services) during the IA64 port.... If DEC could get it right
> in the mid 70s there's no excuse for VMS today.
I can't for the life of me understand calling the COMND JSYS getting
it right. Working with TOPS-20 was so painfull I went out and
learned BLISS-10.
Alan Greig
wrote:
I can't make sense of the above. If working with TOPS-20 was so
painful why would learning BLISS-10 make things easier? Ok BLISS-10/20
was free and BLISS-36 expensive but I am confused. The best high level
interface to COMND (IMHO) was provided by Rutgers Pascal (Chuck
Hedrick) but it wasn't exactly hard to use even from MACRO-10
assembler.
What was it you found painful ?
--
Alan
R.J.S.@not.a.net
>wrote:
>Perhaps someone could implement the TOPS-20 TEXTI and COMND JSYS
>(system services) during the IA64 port.... If DEC could get it right
>in the mid 70s there's no excuse for VMS today. The excuse back then
>for making it a non-goal was that Dave Cutler didn't like the
>overhead. No I don't really expect this to be done for the IA64 port
>but the lack of a COMND style command interface still irks me to this
>day, TOPS-20 from around V5 onwards also supported VMS style command
>line editing *and* EMACS like command line editing.
Stan Rabinowitz did it, way, way back in 1981 or so. VMS didn't want
to include the functionality, because they said it would "slow the
command parser down too much". Many felt the real reason was that the
person who wrote the first DCL parser for VMS didn't think of it, so
it was unacceptable. NIH and all that.
David Mathog
The odds of ever seeing this seem remote at this time, but why not
implement an
API that allow hooks directly into DCL bypassing (in a sense) the
terminal
driver completely. Something like (C binding):
int DCL$OPEN_ACCESS(HANDLE *thehandle, TERMINFO *theterm);
/* open/initialize API access to DCL and also identify for it the
terminal emulation
(if any) through theterm. This would also hook sys$Input,
sys$Output and sys$error to
AST driven routines so that interactive programs could be serviced
as if they were talking
to a terminal. One field in the HANDLE structure would be
MAXDCLLINE, so if longer lines
are added the same code would continue to work. */
int DCL$CLOSE_ACCESS(HANDLE *thehandle); /* close API access to DCL */
int DCL$RECALL_COUNT(HANDLE *thehandle): /* return number of lines in
recall buffer */
int DCL$RECALL_LINE_LENGTH(HANDLE *thehandle, int line): /* return
length of recall line */
int DCL$RECALL_RETRIEVE(HANDLE *thehandle, char *buffer, int bufsize,
int line);
/* return the specified RECALL line into the buffer of size
bufsize */
int DCL$EXECUTE_LINE(HANDLE *thehandle, char *buffer, int bufsize);
/* stuff a command line into DCL and execute it */
Given that API, one could relatively easily hack up a favorite editor
(assuming that
source code is available) to allow arbitrarily long command line entry,
retrieval, editing,
and even execution of interactive terminal based programs. And there
could be a true X11 version
(perhaps based on NEDIT) and a serial version (based on TPU or even
pico.) The serial version
doesn't even have to implement terminal emulation internally, it just
has to relay sys$*
connections across to the real terminal/terminal emulator living on the
user end of the line.
Regards,
David Mathog
mat...@caltech.edu
Peter Weaver
news:3BF1653B...@caltech.edu...
> R.J.S.@not.a.net wrote:
>...
> Given that API, one could relatively easily hack up a favorite editor
> (assuming that
> source code is available) to allow arbitrarily long command line entry,
> retrieval, editing,
Before VMS V4 introduced line editing a person named Jay Beller (Bellar??)
had a utility that allowed us to edit DCL commands using a mini EDT editor.
KP1 would advance one word, KP2 was EOL, KP4 was Forward, KP5 was reverse...
I do not remember what it did with the line-wrap, but it was a very handy
program. Everyone I knew had a copy in their LOGIN.COM at the time.
Any old ADMINS/11 or ADMINS/32 programmers out there know where Jay is these
days? I see his company is still listed at
http://www.admins.com/adminspr/contacts.html, but I do not know if he is
still there or if he still does VMS.
Frank da Cruz
Alan Greig <a.g...@virgin.net> wrote:
:
: ... The best high level
: interface to COMND (IMHO) was provided by Rutgers Pascal (Chuck
: Hedrick) but it wasn't exactly hard to use even from MACRO-10
: assembler.
Not at all. There was a macro package from DEC called CMD to make it
even easier, by Ted Hess I think (DEC-20 Kermit uses it):
search monsym,macsym,cmd
.require sys:macrel,sys:cmd
I'm pretty sure it was standard on all TOPS-20s.
Btw, we (at Columbia U) wrote a full COMND interface for SAIL (the language,
not the site) and used it quite heavily for many years. I don't have a copy
of it any more, but it's probably on some DECUS tape somewhere.
And then there was the hideous GLXLIB version, which is how you got COMND-
like features in TOPS-10 (e.g. in OPR and friends). OK, I shouldn't say
"hideous"... I should know as well as anybody that portable code is rarely
a thing of beauty :-)
- Frank
Bob Koehler
>
> What was it you found painful
Macro-10, for starters. As in the hardware design, where accumulator
0 is a real accumulator to some instructions, but ignored for others.
Just one of my favorite PITAs.
As in not having access to the operating system calls from all high
level languages. Always had to write some assembly code to create
our own interface.
And having passwords on a per-directory basis.
I could go on, but I don't want to start an OS religion war.
jmfb...@aol.com
koe...@encompasserve.org (Bob Koehler) wrote:
>In article <vjd2vt0e30sit7172...@4ax.com>, Alan Greig
<a.g...@virgin.net> writes:
>>
>> What was it you found painful
>
> Macro-10, for starters. As in the hardware design, where accumulator
> 0 is a real accumulator to some instructions, but ignored for others.
> Just one of my favorite PITAs.
Then don't use it. I suspect you're confused, though.
>
> As in not having access to the operating system calls from all high
> level languages. Always had to write some assembly code to create
> our own interface.
I find that to be proper. What system call did you need for
an application that wasn't available through the compiler language?
>
> And having passwords on a per-directory basis.
For what? Writing? That happens to be a good design. Most
directories could be read, unless somebody was really, really
paranoid or there existed a user who liked to mess around.
>
> I could go on, but I don't want to start an OS religion war.
>
It sounds more like you didn't RTFM.
/BAH
Subtract a hundred and four for e-mail.
Alan Greig
>> And having passwords on a per-directory basis.
>
>For what? Writing? That happens to be a good design. Most
>directories could be read, unless somebody was really, really
>paranoid or there existed a user who liked to mess around.
I'm guessing he means that unlike VMS TOPS-20 did not have a distinct
user authorization file but instead held details in a directory
header. A normal directory would be "files only" but a user account
would be "not files only". Don't recall this ever causing me any
problems though. TOPS-20 directory numbers mapped to TOPS-10 PPNs
(UICs) for compatibility purposes.
>
>>
>> I could go on, but I don't want to start an OS religion war.
>>
>It sounds more like you didn't RTFM.
>
>/BAH
>
>Subtract a hundred and four for e-mail.
--
Alan
jmfb...@aol.com
Alan Greig <a.g...@virgin.net> wrote:
>On Wed, 14 Nov 01 13:38:39 GMT, jmfb...@aol.com wrote:
>
>
>>> And having passwords on a per-directory basis.
>>
>>For what? Writing? That happens to be a good design. Most
>>directories could be read, unless somebody was really, really
>>paranoid or there existed a user who liked to mess around.
>
>I'm guessing he means that unlike VMS TOPS-20 did not have a distinct
>user authorization file but instead held details in a directory
>header. A normal directory would be "files only" but a user account
>would be "not files only". Don't recall this ever causing me any
>problems though. TOPS-20 directory numbers mapped to TOPS-10 PPNs
>(UICs) for compatibility purposes.
The only people I encountered who found the architecture
irritating were ones who were trying to fuck around.
In-house, most of us had POKE privs and we simply PIVOTed
to the PPN we needed to access as a user. TOPS-10 and
TOPS-20 were not single-user system designs.
Bob Koehler
re Macro-10:
> Then don't use it. I suspect you're confused, though.
Not an option since the compiler's couldn't do what we needed.
> I find that to be proper. What system call did you need for
> an application that wasn't available through the compiler language?
I don't recallw hich ones anymore, but we used several JSYS that neither
Fortran not Cobol had a clue about. Those were the only compilers we
had until I loaded BLISS-10 off the freeware tape. Coming from calling
everything from Fortran on our RSX and VMS systems I found it to be
quite a pain.
> For what? Writing? That happens to be a good design. Most
> directories could be read, unless somebody was really, really
> paranoid or there existed a user who liked to mess around.
Writing, reading, ... No centralize UAF file, and up until the last
couple years no option to encrypt the passwords. The whole concept
of subdirectories seems to be solely for the admins to organize the
users, not for the users to organize files.
> It sounds more like you didn't RTFM.
I had my head stuck in them all the time. Coming from a VMS and RSX
background I "knew" DEC would have good manuals. Something I didn't
get let down on until ULTRIX.
Alan Greig
wrote:
>In article <9su33p$t16$2...@bob.news.rcn.net>, jmfb...@aol.com writes:
>
>re Macro-10:
>
>> Then don't use it. I suspect you're confused, though.
>
>Not an option since the compiler's couldn't do what we needed.
>
>> I find that to be proper. What system call did you need for
>> an application that wasn't available through the compiler language?
>
>I don't recallw hich ones anymore, but we used several JSYS that neither
>Fortran not Cobol had a clue about. Those were the only compilers we
>had until I loaded BLISS-10 off the freeware tape. Coming from calling
>everything from Fortran on our RSX and VMS systems I found it to be
>quite a pain.
You ran into the problem of trying to use a native TOPS-20 feature
from Fortran or Cobol which were designed to support TOPS-10 so had no
interface to things such as COMND. A lot of sites wrote their own
package but there were also (usually non DEC) provided languages such
as Pascal, Simula and SAIL which provided a high level interface to
TOPS-20 calls. DEC should have provided a general calling convention
form HLLs to avoid everyone having to re-invent the wheel (no pun
intended :-))
I am fairly certain that the PASCAL implementation was callable from
any other TOPS-20 HLL including DEC's own. So you just called the
PASCAL RTL COMND interface routines from FORTRAN. You had to go an
grab Rutgers Pascal first though and DEC should have done a better job
here I agree.
I can also recall a student who wrote a generally callable interface
from HLLs in Macro as part of a project. But he shouldn't really have
had to do so.
Sometimes DEC targeted layered products at TOPS-10 and assumed that
not supporting the additional TOPS-20 features was ok.
>> For what? Writing? That happens to be a good design. Most
>> directories could be read, unless somebody was really, really
>> paranoid or there existed a user who liked to mess around.
>
>Writing, reading, ... No centralize UAF file, and up until the last
>couple years no option to encrypt the passwords. The whole concept
>of subdirectories seems to be solely for the admins to organize the
>users, not for the users to organize files.
>
>> It sounds more like you didn't RTFM.
>
>I had my head stuck in them all the time. Coming from a VMS and RSX
>background I "knew" DEC would have good manuals. Something I didn't
>get let down on until ULTRIX.
--
Alan
Rich Alderson
> I am fairly certain that the PASCAL implementation was callable from any
> other TOPS-20 HLL including DEC's own. So you just called the PASCAL RTL
> COMND interface routines from FORTRAN. You had to go an grab Rutgers Pascal
> first though and DEC should have done a better job here I agree.
Actually, the Pascal and Fortran stack regimens differed in such a way that we
could not use Pascal with System 1022 at Chicago or Stanford, which was a grave
disappointment to me.
--
Rich Alderson alders...@panix.com
"You get what anybody gets. You get a lifetime." --Death, of the Endless
Alan Greig
Rich Alderson wrote:
> Alan Greig <a.g...@virgin.net> writes:
>
> > I am fairly certain that the PASCAL implementation was callable from any
> > other TOPS-20 HLL including DEC's own. So you just called the PASCAL RTL
> > COMND interface routines from FORTRAN. You had to go an grab Rutgers Pascal
> > first though and DEC should have done a better job here I agree.
>
> Actually, the Pascal and Fortran stack regimens differed in such a way that we
> could not use Pascal with System 1022 at Chicago or Stanford, which was a grave
> disappointment to me.
>
That rings a bell but I think that Chuck Hedrick fixed this and provided a
compilation option to use Fortran style calls. Not sure if he backported this to
TOPS-10 but I'm fairly confident it was in the native TOPS-20 S-Pascal (Systems
Pascal - Pascal with systems programming extensions) Yep EXTERN FORTRAN sounds
familiar.
>
> --
> Rich Alderson alders...@panix.com
> "You get what anybody gets. You get a lifetime." --Death, of the Endless
--
Alan Greig
jmfb...@aol.com
Alan Greig <a.g...@virgin.net> wrote:
>On 15 Nov 2001 09:20:41 -0600, koe...@encompasserve.org (Bob Koehler)
>wrote:
>
>>In article <9su33p$t16$2...@bob.news.rcn.net>, jmfb...@aol.com writes:
>>
>>re Macro-10:
>>
>>> Then don't use it. I suspect you're confused, though.
>>
>>Not an option since the compiler's couldn't do what we needed.
>>
>>> I find that to be proper. What system call did you need for
>>> an application that wasn't available through the compiler language?
>>
>>I don't recallw hich ones anymore, but we used several JSYS that neither
>>Fortran not Cobol had a clue about. Those were the only compilers we
>>had until I loaded BLISS-10 off the freeware tape. Coming from calling
>>everything from Fortran on our RSX and VMS systems I found it to be
>>quite a pain.
>
>You ran into the problem of trying to use a native TOPS-20 feature
>from Fortran or Cobol which were designed to support TOPS-10 so had no
>interface to things such as COMND.
Ah, now I understand. I thought he was talking about I/O.
>A lot of sites wrote their own
>package but there were also (usually non DEC) provided languages such
>as Pascal, Simula and SAIL which provided a high level interface to
>TOPS-20 calls. DEC should have provided a general calling convention
>form HLLs to avoid everyone having to re-invent the wheel (no pun
>intended :-))
Real men used PIVOT :-)).
>
>I am fairly certain that the PASCAL implementation was callable from
>any other TOPS-20 HLL including DEC's own. So you just called the
>PASCAL RTL COMND interface routines from FORTRAN. You had to go an
>grab Rutgers Pascal first though and DEC should have done a better job
>here I agree.
>
>I can also recall a student who wrote a generally callable interface
>from HLLs in Macro as part of a project. But he shouldn't really have
>had to do so.
>
>Sometimes DEC targeted layered products at TOPS-10 and assumed that
>not supporting the additional TOPS-20 features was ok.
Nope. That's not how it happened. Language development stopped
targeting TOPS-10 in the late 70s.
<snip>
Bob Koehler
>
> You ran into the problem of trying to use a native TOPS-20 feature
> from Fortran or Cobol which were designed to support TOPS-10 so had no
> interface to things such as COMND.
Fortran-10 and Cobol-whatever had no concept of OS things, just
implemented pretty much what the ANSI standard required with a few
extensions like tab formatting. Couldn't get to a TOPS-10 UUO or
a TOPS-20 JSYS.
Bliss-10 seemed to have some inkling of what a UUO was, but since it
had in line assembly capabilities one code code up a JSYS. The
tricky part was doing it in a way that let one catch the skip on
success return (another primitive idea).
Alan Greig
jmfb...@aol.com wrote:
> I
> >Sometimes DEC targeted layered products at TOPS-10 and assumed that
> >not supporting the additional TOPS-20 features was ok.
>
> Nope. That's not how it happened. Language development stopped
> targeting TOPS-10 in the late 70s.
>
The compilers were fixed to generate native TOPS-20 monitor calls and handle
TOPS-20 file specs etc but it didn't extend all the way to providing easy
access to JSYS UUOs.
--
Alan Greig
jmfb...@aol.com
commenting on your assumption that the reason this wasn't done
was because they were doing TOPS-10 development.