Discussion:
DCL's flaws (both scripting and UI)
(too old to reply)
Simon Clubley
2015-01-18 21:19:35 UTC
Permalink
I think it's time once again to build a list of DCL's flaws now that
VSI are around. Don't forget however that DCL is both a scripting
language and a UI. My initial list is below.

Some of DCL's UI flaws:

1) You can't edit commands across line boundaries. Even Windows CLIs
can do this.

2) You can't save your command history automatically, bash style, and
have it restored automatically at the next session.

With bash, you can have multiple shells active at the same time and
only the commands entered during a specific session will be added to
the history file when that session exits even though the shell has the
full command history from previous shells available (up to a user
defined limit).

Any implementation needs to think about the multiple shells active at
the same time issue before proposing a solution to this.

3) No filename completion. This is _really_ annoying especially since
it even exists (after a fashion) in the command prompt on current
versions of Windows.

4) No elegant incremental search through the command history (bash
Ctrl-R style).

Some of DCL's scripting limitations:

1) No structured programming constructs such as (for example) while
loops.

2) No ability to iterate cleanly over a list of items (bash "for i in"
style)

3) No ability to add site specific lexicals.

4) The output from the lexicals should be an immutable collection of
objects which you can then iterate over without having to worry about
the state changing during iteration.

5) No regex support (this is also a UI issue).

6) Pathetic limits on the maximum size of symbol contents.

7) No array or collection of objects support. (In addition to normal
arrays, DCL should also support associative arrays.)

DCL has absolutely no way to group related variables together in the
way you can with structs in C or objects in other languages.

8) You cannot delete a directory tree in one go.

9) differences is very limited by today's standards. The functionality
in GNU diff, with (for example) it's ability to find differences in
whole directory trees and produce patch files for the differences
in an entire tree, should be the minimum baseline for functionality
these days.

I also find the unified diff output to be a _lot_ more readable than
the output from the DCL differences command.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Stephen Hoffman
2015-01-18 21:57:51 UTC
Permalink
Post by Simon Clubley
I think it's time once again to build a list of DCL's flaws now that
VSI are around. Don't forget however that DCL is both a scripting
language and a UI. My initial list is below.
There's no...

UTF-8
asynchronous processing
floating point
unsigned integers
64-bit integers
binary data
objects
dictionaries
arrays
functions that return values
user-written lexical functions
support for menu-based and graphical-based user interfaces
JIT
compilation
embedding
debugging
DCL libraries
More specific error trapping than ON; let me catch specific errors.

etc...

Simon's command completion and command editing and command history, certainly.

Then there are parts of DCL which are seldom understood or easily misunderstood
scoping
quoting and double-quoting and the two-phase substitution processing
f$getqui
--
Pure Personal Opinion | HoffmanLabs LLC
David Froble
2015-01-19 01:56:09 UTC
Permalink
Post by Stephen Hoffman
Post by Simon Clubley
I think it's time once again to build a list of DCL's flaws now that
VSI are around. Don't forget however that DCL is both a scripting
language and a UI. My initial list is below.
I guess I'm just in a particular mood tonight. Live with it.

:-)
Post by Stephen Hoffman
There's no...
UTF-8
Should be a VMS data type, or types
Definitely a needful thing
Post by Stephen Hoffman
asynchronous processing
Use Basic and ASTs
Post by Stephen Hoffman
floating point
Basic has it
Post by Stephen Hoffman
unsigned integers
Basic SHOULD have this
Post by Stephen Hoffman
64-bit integers
Basic has it
Post by Stephen Hoffman
binary data
Basic has it
Post by Stephen Hoffman
objects
Can you be specific, don't really understand
Post by Stephen Hoffman
dictionaries
Can you be specific, don't really understand
Post by Stephen Hoffman
arrays
Basic has it
Post by Stephen Hoffman
functions that return values
Basic has it
Post by Stephen Hoffman
user-written lexical functions
Basic has it
Post by Stephen Hoffman
support for menu-based and graphical-based user interfaces
Hmmmmm ........ I've got a menu application ...
Post by Stephen Hoffman
JIT
Basic has it
Post by Stephen Hoffman
compilation
Basic has it
Post by Stephen Hoffman
embedding
Can you be specific, don't really understand
Post by Stephen Hoffman
debugging
Basic has it
Post by Stephen Hoffman
DCL libraries
Basic has object and run time libraries
Post by Stephen Hoffman
More specific error trapping than ON; let me catch specific errors.
Basic has it
Post by Stephen Hoffman
etc...
Simon's command completion and command editing and command history, certainly.
Then there are parts of DCL which are seldom understood or easily misunderstood
scoping
quoting and double-quoting and the two-phase substitution processing
f$getqui
Are we having fun yet?
Stephen Hoffman
2015-01-20 00:04:12 UTC
Permalink
Post by David Froble
Post by Stephen Hoffman
asynchronous processing
Use Basic and ASTs
But then BASIC doesn't script DCL commands all that well, either.
Post by David Froble
Post by Stephen Hoffman
floating point
Basic has it
DCL doesn't.
Post by David Froble
Post by Stephen Hoffman
64-bit integers
Basic has it
DCL doesn't.
Post by David Froble
Post by Stephen Hoffman
binary data
Basic has it
DCL doesn't.
Post by David Froble
Post by Stephen Hoffman
objects
Can you be specific, don't really understand
Objects are opaque wads of data (and variously also of the application
code, too) which can be passed around, and without particular regard
for what the object is or contains. Think of these like a string or an
integer variable, but where you don't have to know what the object
contains in order to work with it. With a string or an integer value
in BASIC, you have to special-case how you might print that, for
instance. With objects, the run-time takes care of that. Pass the
object to a print routine, and it gets printed. The metadata
necessary for handling binary data or for ASCII or UTF-8 string
encoding can be implemented here, too. There are other uses for
objects of course, and the approach is very flexible. In some
environments, objects can contain code, so you can package the code and
the related data together. This similar to how you might package
together some BASIC code into a single source file and then build it
into a shareable image, but applied at a much more granular level;
where the code and the data can be treated as, well, an object. Like a
shareable image, an object has a defined API, and related behaviors.
Which means that the source code doesn't end up all twisted together,
just like you would do with source files and libraries and shareable
images. But this where you might have, for instance, an object within
your code that contains a UTF-8 string and some code that can find the
length of that string for you, or that can dump out the string. It's
really quite handy. Newer Fortran and COBOL have some support for
this, as do Python and C++ and some other languages, but I've not seen
anything similar with BASIC.

I'm here intentionally not using entirely correct terminology, nor am I
detailing method invocations and messaging, or whatever a particular
language might call it.
Post by David Froble
Post by Stephen Hoffman
dictionaries
Can you be specific, don't really understand
Key-value stores. These are a form of an in-memory indexed file.
Specify the key, get the value. BASIC doesn't have anything similar
built into the language, though some folks do use RMS indexed files
here.
Post by David Froble
Post by Stephen Hoffman
arrays
Basic has it
So does DCL, if I wanted to substitute symbols.

...
Post by David Froble
Post by Stephen Hoffman
support for menu-based and graphical-based user interfaces
Hmmmmm ........ I've got a menu application ...
And you probably either used a framework (SMG, FMS, etc) to get there,
or you wrote and are maintaining a whole lot of code slinging control
sequences around. DCL doesn't have this option, but more than a few
folks have written menus in DCL. Warts and all. Less application code
and more shared code is better.
Post by David Froble
Post by Stephen Hoffman
JIT
Basic has it
No, BASIC does not have a JIT.
Post by David Froble
Post by Stephen Hoffman
compilation
Basic has it
DCL is interpreted, and also lacking a JIT.
Post by David Froble
Post by Stephen Hoffman
embedding
Can you be specific, don't really understand
There are parts of many applications where you can SPAWN a procedure,
or pass DCL commands into a subprocess. Imagine if that wasn't a
SPAWN, but that the same DCL code was compiled and linked directly into
the application.
Post by David Froble
Post by Stephen Hoffman
debugging
Basic has it
So does DCL, via third-party.
Post by David Froble
Post by Stephen Hoffman
DCL libraries
Basic has object and run time libraries
Those aren't easily callable from DCL, and DCL has no particular
subroutine capabilities for itself, which means that folks have a
scattering of separate DCL procedures that they locate by logical name
or path, or the folks embed copies of that shared DCL in various
procedures, or the folks create their own DCL activation logic. Which
gets messy.
Post by David Froble
Post by Stephen Hoffman
More specific error trapping than ON; let me catch specific errors.
Basic has it
But does your DCL?
Post by David Froble
...
Are we having fun yet?
Having worked a whole lot in DCL and BASIC and other languages over the
years, well, not really. :-)
--
Pure Personal Opinion | HoffmanLabs LLC
David Froble
2015-01-20 03:06:47 UTC
Permalink
Post by Stephen Hoffman
Post by David Froble
Post by Stephen Hoffman
asynchronous processing
Use Basic and ASTs
But then BASIC doesn't script DCL commands all that well, either.
Yes, make my point. When you need more than DCL has, then use something
that actually provides the requirements.

I'm not going to paste that 20 times, but it is the same statement for
most of what's below.
Post by Stephen Hoffman
Post by David Froble
Post by Stephen Hoffman
floating point
Basic has it
DCL doesn't.
See above :-)
Post by Stephen Hoffman
Post by David Froble
Post by Stephen Hoffman
64-bit integers
Basic has it
DCL doesn't.
Post by David Froble
Post by Stephen Hoffman
binary data
Basic has it
DCL doesn't.
Post by David Froble
Post by Stephen Hoffman
objects
Can you be specific, don't really understand
Objects are opaque wads of data (and variously also of the application
code, too) which can be passed around, and without particular regard for
what the object is or contains. Think of these like a string or an
integer variable, but where you don't have to know what the object
contains in order to work with it. With a string or an integer value
in BASIC, you have to special-case how you might print that, for
instance. With objects, the run-time takes care of that. Pass the
object to a print routine, and it gets printed. The metadata necessary
for handling binary data or for ASCII or UTF-8 string encoding can be
implemented here, too. There are other uses for objects of course, and
the approach is very flexible. In some environments, objects can
contain code, so you can package the code and the related data
together. This similar to how you might package together some BASIC
code into a single source file and then build it into a shareable image,
but applied at a much more granular level; where the code and the data
can be treated as, well, an object. Like a shareable image, an object
has a defined API, and related behaviors. Which means that the source
code doesn't end up all twisted together, just like you would do with
source files and libraries and shareable images. But this where you
might have, for instance, an object within your code that contains a
UTF-8 string and some code that can find the length of that string for
you, or that can dump out the string. It's really quite handy. Newer
Fortran and COBOL have some support for this, as do Python and C++ and
some other languages, but I've not seen anything similar with BASIC.
I'm here intentionally not using entirely correct terminology, nor am I
detailing method invocations and messaging, or whatever a particular
language might call it.
Ya know, samantics is an awful thing. It's confusing for some like me
when different names are used for the same thing.

A dynamic string descriptor I think would fit your definition of an
object. So would variables and such.

Basically (sic) I can store any data in a string descriptor, and pass
the address of the descriptor to some routine which knows what to do
with the stuff pointed to by the descriptor.

Now, I cannot imagine why I'd want to pass some code, rather than data,
to anything, but we all know I don't get out much, so that might not be
surprising. But, surprise, I can pass a string of code using a string
descriptor.
Post by Stephen Hoffman
Post by David Froble
Post by Stephen Hoffman
dictionaries
Can you be specific, don't really understand
Key-value stores. These are a form of an in-memory indexed file.
Specify the key, get the value. BASIC doesn't have anything similar
built into the language, though some folks do use RMS indexed files here.
Oh, you mean like a doubly dimensioned array, or other structure, where
I can load up some key-value pairs, then invoke a routine or code to
take a key value and return the associated value?

Different name for the same old things that have been done for many
years. Perhaps refined, or specialized, but same thing as your
description. Maybe for the old way someone actually has to know how to
design and implement code ....

:-)
Post by Stephen Hoffman
Post by David Froble
Post by Stephen Hoffman
arrays
Basic has it
So does DCL, if I wanted to substitute symbols.
...
Post by David Froble
Post by Stephen Hoffman
support for menu-based and graphical-based user interfaces
Hmmmmm ........ I've got a menu application ...
And you probably either used a framework (SMG, FMS, etc) to get there,
or you wrote and are maintaining a whole lot of code slinging control
sequences around. DCL doesn't have this option, but more than a few
folks have written menus in DCL. Warts and all. Less application code
and more shared code is better.
Well, actually, not SMG, FMS, and such. I could get cute and call the
routines that create the control sequences OBJECTs. In the end, any
method creates the control sequences, right? What matter if my OBJECTs
are in an OLB library? I could put them in a shared RTL.
Post by Stephen Hoffman
Post by David Froble
Post by Stephen Hoffman
JIT
Basic has it
No, BASIC does not have a JIT.
Are we into symantics again? I bet if e got down to detail
descriptions, we could call the ".BAC" files in RSTS/E Basic+ a form of
JIT. Or, maybe not.
Post by Stephen Hoffman
Post by David Froble
Post by Stephen Hoffman
compilation
Basic has it
DCL is interpreted, and also lacking a JIT.
Post by David Froble
Post by Stephen Hoffman
embedding
Can you be specific, don't really understand
There are parts of many applications where you can SPAWN a procedure, or
pass DCL commands into a subprocess. Imagine if that wasn't a SPAWN,
but that the same DCL code was compiled and linked directly into the
application.
Ya know, that could get rather tricky. Personally, I have no problem
with spawning a subprocess when I need to execute some DCL code. I
could most likely code the procedure in Basic, but it would re-inventing
the wheel, and that's just dumb.
Post by Stephen Hoffman
Post by David Froble
Post by Stephen Hoffman
debugging
Basic has it
So does DCL, via third-party.
Post by David Froble
Post by Stephen Hoffman
DCL libraries
Basic has object and run time libraries
Those aren't easily callable from DCL, and DCL has no particular
subroutine capabilities for itself, which means that folks have a
scattering of separate DCL procedures that they locate by logical name
or path, or the folks embed copies of that shared DCL in various
procedures, or the folks create their own DCL activation logic. Which
gets messy.
Post by David Froble
Post by Stephen Hoffman
More specific error trapping than ON; let me catch specific errors.
Basic has it
But does your DCL?
Post by David Froble
...
Are we having fun yet?
Having worked a whole lot in DCL and BASIC and other languages over the
years, well, not really. :-)
Well, I'm having fun. My argument still is, if you need more than what
DCL will do, there are alternatives in the compiled languages. Though I
won't recommend that C thingy ....

Now for the opposite, can anyone name anything that DCL can do that
cannot be done in Basic?


:-)
Stephen Hoffman
2015-01-20 05:04:11 UTC
Permalink
Post by David Froble
Ya know, samantics is an awful thing. It's confusing for some like me
when different names are used for the same thing.
A dynamic string descriptor I think would fit your definition of an
object. So would variables and such.
A descriptor is a very old and very limited and very primitive version
of an object, yes. But with objects — and this is one of the details —
you're never looking at a descriptor, you're always looking at a
transparent wad of data. And of code. It's an abstraction, but a
useful one.
Post by David Froble
Basically (sic) I can store any data in a string descriptor, and pass
the address of the descriptor to some routine which knows what to do
with the stuff pointed to by the descriptor.
Yes, but can you store code in one, too? If you worked at it, sure,
you could create a way to collect the data and the code together.

(*ponders what OOBASIC would look like and work like*)
Post by David Froble
Now, I cannot imagine why I'd want to pass some code, rather than data,
to anything, but we all know I don't get out much, so that might not be
surprising. But, surprise, I can pass a string of code using a string
descriptor.
The nice part is that you can avoid spreading knowledge of what's in
the object — private data, private routines, public routines, public
data — around throughout the application code. Objects are an
abstraction that cleanly and clearly enforces modularity.
Post by David Froble
Post by Stephen Hoffman
Key-value stores. These are a form of an in-memory indexed file.
Specify the key, get the value. BASIC doesn't have anything similar
built into the language, though some folks do use RMS indexed files here.
Oh, you mean like a doubly dimensioned array, or other structure, where
I can load up some key-value pairs, then invoke a routine or code to
take a key value and return the associated value?
Different name for the same old things that have been done for many
years. Perhaps refined, or specialized, but same thing as your
description. Maybe for the old way someone actually has to know how to
design and implement code ....
:-)
In BASIC, it would be a sorted array of structures. Yeah, not really
hugely new, but a whole lot easier to use and to work with than the old
ways, and less code to write and to maintain. Working on VMS now
reminds me of PDP-11, back when I started on VMS. The old stuff
worked, but was just harder to deal with, harder to work with, and much
more limited. With a dictionary, the access mechanisms, memory
management and the rest are all typically baked into the language
and/or the run-time.
Post by David Froble
Post by Stephen Hoffman
And you probably either used a framework (SMG, FMS, etc) to get there,
or you wrote and are maintaining a whole lot of code slinging control
sequences around. DCL doesn't have this option, but more than a few
folks have written menus in DCL. Warts and all. Less application code
and more shared code is better.
Well, actually, not SMG, FMS, and such. I could get cute and call the
routines that create the control sequences OBJECTs. In the end, any
method creates the control sequences, right? What matter if my OBJECTs
are in an OLB library? I could put them in a shared RTL.
So you're maintaining code to do that? OK. Your call. As has
happened, some old concepts get updated, and the applications can get
larger and more complex, because tasks that we all used to deal with —
control sequences and related processing — have gotten pushed down into
frameworks or into objects.

Those aren't objects.
Post by David Froble
Post by Stephen Hoffman
No, BASIC does not have a JIT.
Are we into symantics again? I bet if e got down to detail
descriptions, we could call the ".BAC" files in RSTS/E Basic+ a form of
JIT. Or, maybe not.
A JIT is an interpreter that can detect and compile and execute the
busiest of the interpreted code. It's a technique that can boost
performance. Because compilation is more expensive, it's not something
the interpreter necessarily wants to do for the entire code. But for
the busiest part of the code, it works well.
Post by David Froble
Well, I'm having fun. My argument still is, if you need more than what
DCL will do, there are alternatives in the compiled languages. Though
I won't recommend that C thingy ....
Now for the opposite, can anyone name anything that DCL can do that
cannot be done in Basic?
:-)
Given that I can generate and execute machine code from with a BASIC
program or given I can generate machine code from within DCL, and —
given sufficient privileges or a security vulnerability — that machine
code can then do anything I want. In short, both languages are Turing
complete. It's that DCL is clunky, slow, complex, difficult to use
and requires a whole lot of work to do what can now be simpler tasks.
Having used both DCL and BASIC for many years, both require more than a
little coding for what they deliver, and both have no shortage of
limitations. If you want new users, the folks are going to want
newer tools and higher-level abstractions. Could I write a web browser
in BASIC? Sure. But on some other platforms, the end user need write
a whole lot fewer lines of code to get to the target solution. Could
I write a web browser in BP2 on a PDP-11/RSX-11M box? Sure. That's
how I find using DCL and BASIC on VMS now. Workable, but a whole lot
of work.
--
Pure Personal Opinion | HoffmanLabs LLC
David Froble
2015-01-20 08:13:55 UTC
Permalink
Post by Stephen Hoffman
Given that I can generate and execute machine code from with a BASIC
program or given I can generate machine code from within DCL, and —
given sufficient privileges or a security vulnerability — that machine
code can then do anything I want. In short, both languages are Turing
complete. It's that DCL is clunky, slow, complex, difficult to use and
requires a whole lot of work to do what can now be simpler tasks.
Having used both DCL and BASIC for many years, both require more than a
little coding for what they deliver, and both have no shortage of
limitations. If you want new users, the folks are going to want newer
tools and higher-level abstractions. Could I write a web browser in
BASIC? Sure. But on some other platforms, the end user need write a
whole lot fewer lines of code to get to the target solution. Could I
write a web browser in BP2 on a PDP-11/RSX-11M box? Sure. That's how I
find using DCL and BASIC on VMS now. Workable, but a whole lot of work.
Ah, but why can you do so?

We both know why so much can be done easily in things like Python. It's
because an extensive library of support routines exists as part of the
distribution. Where did they come from? Somebody had to write them.

I also have libraries of routines to do things. If I have libraries in
Basic that match the libraries in say Python, then what's the major
difference between the environments? I suggest it's very little.

Even that C thingy would be rather poor, if it didn't have all the
libraries of procedures.

So, yeah, without all the tools, library routines, boiler plate stuff,
and such, writing a program in Basic can be rather tiresome. When I
need to write only 10% or less of the code to do something, then it
becomes much more useful. Is my stuff maybe older, and perhaps less
universal? Not so all inclusive? Yeah. But still very helpful. If it
does everything I need, what does the missing stuff matter, to me?

I always did enjoy tools and R&D and such more than writing applications.
Jan-Erik Soderholm
2015-01-20 12:54:36 UTC
Permalink
Post by David Froble
I also have libraries of routines to do things. If I have libraries in
Basic that match the libraries in say Python, then what's the major
difference between the environments? I suggest it's very little.
Doesn't your Basic need a compiler? And if so, do you have
a compiler on every system? Or do you need to build your
quick-fix one-of-the-kind tool on some other system first?

With Python you get a fast edit/test/edit/test cycle.
With Basic ou get edit/compile/copy/test/edit/compile/copy/test.

That is, if your Basic compiler is on another system.

Jan-Erik.
David Froble
2015-01-20 13:26:00 UTC
Permalink
Post by Jan-Erik Soderholm
Post by David Froble
I also have libraries of routines to do things. If I have libraries in
Basic that match the libraries in say Python, then what's the major
difference between the environments? I suggest it's very little.
Doesn't your Basic need a compiler? And if so, do you have
a compiler on every system? Or do you need to build your
quick-fix one-of-the-kind tool on some other system first?
With Python you get a fast edit/test/edit/test cycle.
With Basic ou get edit/compile/copy/test/edit/compile/copy/test.
That is, if your Basic compiler is on another system.
Jan-Erik.
Basic compiler on all systems. And if not, with DECnet and FAL, it
doesn't matter. I can even execute the image sitting on a dev system on
say a production system over the network. Well, if same architecture.

But, for us, the production system has the compiler, so no issue.
Jan-Erik Soderholm
2015-01-20 13:25:59 UTC
Permalink
Post by Jan-Erik Soderholm
Post by David Froble
I also have libraries of routines to do things. If I have libraries in
Basic that match the libraries in say Python, then what's the major
difference between the environments? I suggest it's very little.
Doesn't your Basic need a compiler? And if so, do you have
a compiler on every system? Or do you need to build your
quick-fix one-of-the-kind tool on some other system first?
With Python you get a fast edit/test/edit/test cycle.
With Basic ou get edit/compile/copy/test/edit/compile/copy/test.
That is, if your Basic compiler is on another system.
Jan-Erik.
Basic compiler on all systems. And if not, with DECnet and FAL, it doesn't
matter. I can even execute the image sitting on a dev system on say a
production system over the network. Well, if same architecture.
But, for us, the production system has the compiler, so no issue.
I guess that "but, for us" is the key here... :-)

Anyway, I can't see getting a Basic compiler is the general
answer to having something to complement DCL.

Oh, and another thing... The Python port is no-cost. I have
not checked, but I do not think the Basic compiler is.

Jan-Erik.
David Froble
2015-01-20 14:50:18 UTC
Permalink
Post by Jan-Erik Soderholm
Post by Jan-Erik Soderholm
Post by David Froble
I also have libraries of routines to do things. If I have libraries in
Basic that match the libraries in say Python, then what's the major
difference between the environments? I suggest it's very little.
Doesn't your Basic need a compiler? And if so, do you have
a compiler on every system? Or do you need to build your
quick-fix one-of-the-kind tool on some other system first?
With Python you get a fast edit/test/edit/test cycle.
With Basic ou get edit/compile/copy/test/edit/compile/copy/test.
That is, if your Basic compiler is on another system.
Jan-Erik.
Basic compiler on all systems. And if not, with DECnet and FAL, it doesn't
matter. I can even execute the image sitting on a dev system on say a
production system over the network. Well, if same architecture.
But, for us, the production system has the compiler, so no issue.
I guess that "but, for us" is the key here... :-)
Anyway, I can't see getting a Basic compiler is the general
answer to having something to complement DCL.
What about Cobol?

I'm not saying it has to be Basic. I'm saying there are existing
alternatives.
Post by Jan-Erik Soderholm
Oh, and another thing... The Python port is no-cost. I have
not checked, but I do not think the Basic compiler is.
That is a business decision.

I'm thinking that some or all of the compilers should be bundled with
VMS. Better chance of including them in a support contract.
Jan-Erik Soderholm
2015-01-20 14:51:49 UTC
Permalink
Post by David Froble
Post by Jan-Erik Soderholm
Post by Jan-Erik Soderholm
Post by David Froble
I also have libraries of routines to do things. If I have libraries in
Basic that match the libraries in say Python, then what's the major
difference between the environments? I suggest it's very little.
Doesn't your Basic need a compiler? And if so, do you have
a compiler on every system? Or do you need to build your
quick-fix one-of-the-kind tool on some other system first?
With Python you get a fast edit/test/edit/test cycle.
With Basic ou get edit/compile/copy/test/edit/compile/copy/test.
That is, if your Basic compiler is on another system.
Jan-Erik.
Basic compiler on all systems. And if not, with DECnet and FAL, it doesn't
matter. I can even execute the image sitting on a dev system on say a
production system over the network. Well, if same architecture.
But, for us, the production system has the compiler, so no issue.
I guess that "but, for us" is the key here... :-)
Anyway, I can't see getting a Basic compiler is the general
answer to having something to complement DCL.
What about Cobol?
Yes, I'm using Python for many tasks where the former guy would have
spent more time to hack together a Cobol application. Progress.

All our main applications uses Cobol and all new *application*
development uses Cobol. But that is not what we are talking
about here, right?

I'm not talking about Python replacing Cobol, but Python
complementing DCL.
Post by David Froble
I'm not saying it has to be Basic. I'm saying there are existing
alternatives.
Agree. And Python is a good complement to DCL.
Post by David Froble
I'm thinking that some or all of the compilers should be bundled with VMS.
Better chance of including them in a support contract.
Doesn't matter. What matter is how it is today.

Jan-Erik.
Bill Gunshannon
2015-01-20 15:05:14 UTC
Permalink
Post by Jan-Erik Soderholm
Post by David Froble
Post by Jan-Erik Soderholm
Post by Jan-Erik Soderholm
Post by David Froble
I also have libraries of routines to do things. If I have libraries in
Basic that match the libraries in say Python, then what's the major
difference between the environments? I suggest it's very little.
Doesn't your Basic need a compiler? And if so, do you have
a compiler on every system? Or do you need to build your
quick-fix one-of-the-kind tool on some other system first?
With Python you get a fast edit/test/edit/test cycle.
With Basic ou get edit/compile/copy/test/edit/compile/copy/test.
That is, if your Basic compiler is on another system.
Jan-Erik.
Basic compiler on all systems. And if not, with DECnet and FAL, it doesn't
matter. I can even execute the image sitting on a dev system on say a
production system over the network. Well, if same architecture.
But, for us, the production system has the compiler, so no issue.
I guess that "but, for us" is the key here... :-)
Anyway, I can't see getting a Basic compiler is the general
answer to having something to complement DCL.
What about Cobol?
Yes, I'm using Python for many tasks where the former guy would have
spent more time to hack together a Cobol application. Progress.
Don't confuse programming language abiltiy and programmer ability.
I have written program in COBOL in a half hour while others took
days to accomplish the same thing using PHP.
Post by Jan-Erik Soderholm
All our main applications uses Cobol and all new *application*
development uses Cobol. But that is not what we are talking
about here, right?
I'm not talking about Python replacing Cobol, but Python
complementing DCL.
Post by David Froble
I'm not saying it has to be Basic. I'm saying there are existing
alternatives.
Agree. And Python is a good complement to DCL.
Post by David Froble
I'm thinking that some or all of the compilers should be bundled with VMS.
Better chance of including them in a support contract.
Doesn't matter. What matter is how it is today.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
JF Mezei
2015-01-20 16:23:00 UTC
Permalink
Since my original suggestion of autocomplete for username and password
was so well received, I shall provide a good solution to the DCL issue:

iCobol for command language. Yes, interactive cobol. (or interpreted cobol)

Think about it. It maintains the readability of DCL, provides for many
different variable types, allows one to call system services (including
passing strings by descriptors), has structure, loops etc. In essence,
it provides all that we need.

And if the VAX Cobol is used, iCobol could also make use of its screen
handling abilities to provide full screen (characetr cell) interface
right from the command line. This would bring in a capability MVS has
had since the early 1980s with TSO. :-)
Bob Koehler
2015-01-21 16:40:46 UTC
Permalink
Post by David Froble
Basic compiler on all systems. And if not, with DECnet and FAL, it
doesn't matter. I can even execute the image sitting on a dev system on
say a production system over the network. Well, if same architecture.
But, for us, the production system has the compiler, so no issue.
We generally don't allow compilers on production systems as the
customer is deathly afraid of what unauthorized software someone
might write.

But there's always "Basic" vs. "basic". Macro-32 is not Basic and
not a compiler on VAXen, but it makes a good basic compiler for many
of us.
David Froble
2015-01-21 18:40:08 UTC
Permalink
Post by Bob Koehler
Post by David Froble
Basic compiler on all systems. And if not, with DECnet and FAL, it
doesn't matter. I can even execute the image sitting on a dev system on
say a production system over the network. Well, if same architecture.
But, for us, the production system has the compiler, so no issue.
We generally don't allow compilers on production systems as the
customer is deathly afraid of what unauthorized software someone
might write.
But there's always "Basic" vs. "basic". Macro-32 is not Basic and
not a compiler on VAXen, but it makes a good basic compiler for many
of us.
So, the customer has tunnel vision, huh? If it's called a compiler,
they see it, but if it's called an assembler, they don't see it?

:-)

What about DCL, since some misguided souls seem to proclaim it a
"programming language"?
j***@gmail.com
2015-01-20 13:10:05 UTC
Permalink
Post by David Froble
But still very helpful. If it
does everything I need, what does the missing stuff matter, to me?
I don't think anyone is suggesting otherwise... for you. If you like your house,
and you don't want to leave, stay put.

But I think even you might be able to concede that for the larger world
simply pairing DCL and DEC Basic as a sufficient development tool chain
for everyone else would be a bit of a stretch. But given your recent posts,
it seems like you are even more dug into this view point.

EJ
David Froble
2015-01-20 13:46:06 UTC
Permalink
Post by j***@gmail.com
Post by David Froble
But still very helpful. If it
does everything I need, what does the missing stuff matter, to me?
I don't think anyone is suggesting otherwise... for you. If you like your house,
and you don't want to leave, stay put.
But I think even you might be able to concede that for the larger world
simply pairing DCL and DEC Basic as a sufficient development tool chain
for everyone else would be a bit of a stretch. But given your recent posts,
it seems like you are even more dug into this view point.
EJ
It's rather difficult for me to know what I don't have, if I don't need
/ use it.

If someone can show me what I cannot do, that other tools can do, then
maybe my environment is not so all inclusive. So far, I have not been
shown such.

This discussion start as "what is deficient in DCL", and my argument is
that instead of insisting that DCL be enhanced, possibly using a better
tool would be a better course of action. Now it has expanded to the
merits of other tools, such as Python and Perl, considered "modern"
while I've suggested that some of the older compiled languages, used
with a good tool set, are also appropriate for the job.

Now, it is possible that some of the "modern" tool sets are easier for
some to use, if they have the expertise, while those more used to more
"traditional" tool sets might not have the same result.

What I think happens with a language such s Basic is that some people,
not you Steve, have never really explored it, and just dismiss it out of
hand. My argument is that while some concepts that are possible only
because of newer HW may be missing, because HP ignored VMS for so long,
that the capabilities of Basic, while having a few warts (what doesn't?)
can match up rather well to any other environment on VMS. I have as
yet not seen any evidence to contradict this.
Jan-Erik Soderholm
2015-01-20 14:39:06 UTC
Permalink
It's rather difficult for me to know what I don't have, if I don't need /
use it.
And if you never ask or check yourself, you will never know.

Your loss and *we* could just as well try to explain it
to the cat.

Regards,
Jan-Erik.
Jan-Erik Soderholm
2015-01-20 12:46:48 UTC
Permalink
Key-value stores. These are a form of an in-memory indexed file. Specify
the key, get the value. BASIC doesn't have anything similar built into
the language, though some folks do use RMS indexed files here.
Oh, you mean like a doubly dimensioned array, or other structure, where I
can load up some key-value pairs, then invoke a routine or code to take a
key value and return the associated value?
Different name for the same old things that have been done for many years.
Perhaps refined, or specialized, but same thing as your description. Maybe
for the old way someone actually has to know how to design and implement
code ....
A built-in standard data type in Python, "Dictionaries".

https://docs.python.org/2/tutorial/datastructures.html#dictionaries

No routines to write, just use it...

Jan-Erik.
David Froble
2015-01-20 14:01:38 UTC
Permalink
Post by Jan-Erik Soderholm
Key-value stores. These are a form of an in-memory indexed file. Specify
the key, get the value. BASIC doesn't have anything similar built into
the language, though some folks do use RMS indexed files here.
Oh, you mean like a doubly dimensioned array, or other structure, where I
can load up some key-value pairs, then invoke a routine or code to take a
key value and return the associated value?
Different name for the same old things that have been done for many years.
Perhaps refined, or specialized, but same thing as your description.
Maybe
for the old way someone actually has to know how to design and implement
code ....
A built-in standard data type in Python, "Dictionaries".
https://docs.python.org/2/tutorial/datastructures.html#dictionaries
No routines to write, just use it...
Jan-Erik.
Not quite that simple. You still need to load the data. You still need
to request a pair (or pairs) match. If I was to perform such, I think
the amount of code would be similar.

But consider, anything "built in" was written by someone, and without
it, the starting points would be the same. To compare apples with
apples, consider that in my environment the "tool" also exists. Now the
usage of the tool becomes very similar.

However, for the converse, let's say the specific tool does not exist in
Python. Again, the starting point is equal. How hard will it be to
implement the desired action? I cannot say, as I do not have expertise
with Python. Perhaps a few such examples might show where advantage lies?
Jan-Erik Soderholm
2015-01-20 14:37:07 UTC
Permalink
Post by David Froble
Post by Jan-Erik Soderholm
Key-value stores. These are a form of an in-memory indexed file. Specify
the key, get the value. BASIC doesn't have anything similar built into
the language, though some folks do use RMS indexed files here.
Oh, you mean like a doubly dimensioned array, or other structure, where I
can load up some key-value pairs, then invoke a routine or code to take a
key value and return the associated value?
Different name for the same old things that have been done for many years.
Perhaps refined, or specialized, but same thing as your description. Maybe
for the old way someone actually has to know how to design and implement
code ....
A built-in standard data type in Python, "Dictionaries".
https://docs.python.org/2/tutorial/datastructures.html#dictionaries
No routines to write, just use it...
Jan-Erik.
Not quite that simple. You still need to load the data.
OK, I'm lost... :-)

Should Python (or any other tool) make up the data from thin air?
*Any* construct would need to have the data loaded, not?

Don't be fooled by the example using hard coded values, they
doen't have to be, of course. But that you mujst understand.
It's just an exmaple, after all.
Post by David Froble
You still need to request a pair (or pairs) match.
I do not understand that. A key corresponds to a value.
As expected for that specific data type. What is it that
you need to request?
Post by David Froble
If I was to perform such, I think the
amount of code would be similar.
What "code"? Is there a built in similar data type in Basic?
Post by David Froble
But consider, anything "built in" was written by someone, and without it,
the starting points would be the same. To compare apples with apples,
consider that in my environment the "tool" also exists.
So if I buy the same Basic compiler, it does exist?
Post by David Froble
However, for the converse, let's say the specific tool does not exist in
Python.
Why pretend that? It does.
It's included in the base Python standard.
Not specific for the VMS port, if that is what you think (?).
It is a Python standard data type on ay platform.
Post by David Froble
Again, the starting point is equal.
OK, so a similar data type exist in the base Basic distribution?
I thought not.
Post by David Froble
How hard will it be to implement the desired action?
I cannot say, as I do not have expertise with Python.
It's there. Just use it.

Weird discussion...

Jan-Erik.
David Froble
2015-01-20 17:50:59 UTC
Permalink
Post by Jan-Erik Soderholm
OK, so a similar data type exist in the base Basic distribution?
I thought not.
If your position is dependent upon a particular data type existing, then
I submit the following:


10 Dim L$(99,2) ! Create an array of dynamic string descriptors

<some code to load L$(index,1) with a key value
and L$(index,2) with the associated data>

! This would be the "tool" to retrive data based upon the key
String Function RetriveData( <key> )
For I% = 1% to 99%
If <key> = L$(I%,1%)
Then RetriveData = L$(I%,2%)
Exit Function
End If
Next I%
RetriveData = ""
End Function

! This would be a retrival
D$ = RetriveData( <some key> )


Ok, syntax may not be all correct, and it's over simplified, but I think
the above shows just how easy it would be to implement that capability
in Basic, AND I submit that the data type to allow the capability
already exists in Basic.
Simon Clubley
2015-01-20 20:19:42 UTC
Permalink
Post by David Froble
Post by Jan-Erik Soderholm
OK, so a similar data type exist in the base Basic distribution?
I thought not.
If your position is dependent upon a particular data type existing, then
10 Dim L$(99,2) ! Create an array of dynamic string descriptors
<some code to load L$(index,1) with a key value
and L$(index,2) with the associated data>
;+++
Post by David Froble
! This would be the "tool" to retrive data based upon the key
String Function RetriveData( <key> )
For I% = 1% to 99%
If <key> = L$(I%,1%)
Then RetriveData = L$(I%,2%)
Exit Function
End If
Next I%
RetriveData = ""
End Function
! This would be a retrival
D$ = RetriveData( <some key> )
;---

Based on your previous message, what you don't seem to have picked up
on is that a dictionary is an associative data structure which means
that in a DCL which supported associative arrays/dictionaries the code
above between ";+++" and ";---" could be replaced with the following
single DCL line:

$ value = L{some_string_containing_the_key}

assuming you use "{" and "}" to denote an array index and L is the
associative array/dictionary. (You can't use "[" or "]" here as they
are already taken by DCL.)

You could also dynamically add an element to or delete an element from
the dictionary in a single DCL line as well.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
David Froble
2015-01-20 20:40:26 UTC
Permalink
Post by Simon Clubley
Post by David Froble
Post by Jan-Erik Soderholm
OK, so a similar data type exist in the base Basic distribution?
I thought not.
If your position is dependent upon a particular data type existing, then
10 Dim L$(99,2) ! Create an array of dynamic string descriptors
<some code to load L$(index,1) with a key value
and L$(index,2) with the associated data>
;+++
Post by David Froble
! This would be the "tool" to retrive data based upon the key
String Function RetriveData( <key> )
For I% = 1% to 99%
If <key> = L$(I%,1%)
Then RetriveData = L$(I%,2%)
Exit Function
End If
Next I%
RetriveData = ""
End Function
! This would be a retrival
D$ = RetriveData( <some key> )
;---
Based on your previous message, what you don't seem to have picked up
on is that a dictionary is an associative data structure which means
that in a DCL which supported associative arrays/dictionaries the code
above between ";+++" and ";---" could be replaced with the following
$ value = L{some_string_containing_the_key}
assuming you use "{" and "}" to denote an array index and L is the
associative array/dictionary. (You can't use "[" or "]" here as they
are already taken by DCL.)
You could also dynamically add an element to or delete an element from
the dictionary in a single DCL line as well.
Simon.
Some code similar to what's between the +++ and --- would have to exist
somewhere. If part of DCL, fine, but must exist.

I was just showing that some new fangled data type in some new fangled
language wasn't much different that what exists in one of the old
compiled languages.
Jan-Erik Soderholm
2015-01-21 00:11:24 UTC
Permalink
Post by David Froble
Post by Simon Clubley
Post by David Froble
Post by Jan-Erik Soderholm
OK, so a similar data type exist in the base Basic distribution?
I thought not.
If your position is dependent upon a particular data type existing, then
10 Dim L$(99,2) ! Create an array of dynamic string descriptors
<some code to load L$(index,1) with a key value
and L$(index,2) with the associated data>
;+++
Post by David Froble
! This would be the "tool" to retrive data based upon the key
String Function RetriveData( <key> )
For I% = 1% to 99%
If <key> = L$(I%,1%)
Then RetriveData = L$(I%,2%)
Exit Function
End If
Next I%
RetriveData = ""
End Function
! This would be a retrival
D$ = RetriveData( <some key> )
;---
Based on your previous message, what you don't seem to have picked up
on is that a dictionary is an associative data structure which means
that in a DCL which supported associative arrays/dictionaries the code
above between ";+++" and ";---" could be replaced with the following
$ value = L{some_string_containing_the_key}
assuming you use "{" and "}" to denote an array index and L is the
associative array/dictionary. (You can't use "[" or "]" here as they
are already taken by DCL.)
You could also dynamically add an element to or delete an element from
the dictionary in a single DCL line as well.
Simon.
Some code similar to what's between the +++ and --- would have to exist
somewhere. If part of DCL, fine, but must exist.
I was just showing that some new fangled data type in some new fangled
language wasn't much different that what exists in one of the old compiled
languages.
Oh, it is very different, as I wrote in another post.

The dict data type in Python is an assisitive array with
the key value in an hash table for very fast lookups.
Your example is just an old sequential search. Could
be done in any language but always unefficient.

Jan-Erik.
j***@gmail.com
2015-01-21 01:13:13 UTC
Permalink
Post by David Froble
I was just showing that some new fangled data type in some new fangled
language wasn't much different that what exists in one of the old
compiled languages.
Out of curiosity, when's the last time you tried to learn a new programming
language on its own terms? You know, just for the sake of learning and
expanding the skill set?

EJ
David Froble
2015-01-21 02:57:00 UTC
Permalink
Post by j***@gmail.com
Post by David Froble
I was just showing that some new fangled data type in some new fangled
language wasn't much different that what exists in one of the old
compiled languages.
Out of curiosity, when's the last time you tried to learn a new programming
language on its own terms? You know, just for the sake of learning and
expanding the skill set?
EJ
I've tried looking at C several times. A disaster.

I've got Python on one of my systems. Doesn't make any sense to me.

Yes, others seem able to do multiple languages. Apparent I'm the
problem. I've done Cobol and Fortran in the very distant past. I've
implemented a database using mostly MACRO-32.

Perhaps part of the problem is that I neither see nor feel the need to
move on to other languages.

Regardless, with a few exceptions, such as what I consider a rather poor
release of SSL on VMS, I have not been convinced that I really need to
abandon what I already know. Being semi-retired could have something to
do with that.
j***@gmail.com
2015-01-21 13:32:00 UTC
Permalink
Post by David Froble
Perhaps part of the problem is that I neither see nor feel the need to
move on to other languages.
Regardless, with a few exceptions, such as what I consider a rather poor
release of SSL on VMS, I have not been convinced that I really need to
abandon what I already know.
It's not about abandoning. It's about expanding your horizons and your
expectations. Sometimes you can appreciate home all the more by going
out and exploring the world. It's even easier these days considering the
near oracle like quality of google. "How do I do X in language Y". Most
of the time it will take you to the relevant question on stackoverflow!

Darn kids these days, there was a time when you actually had to read
the manual and people were entitled to expect you to! They don't know
what they are missing. Or maybe its the other way around. :-)

EJ
David Froble
2015-01-21 18:49:41 UTC
Permalink
Post by j***@gmail.com
Post by David Froble
Perhaps part of the problem is that I neither see nor feel the need to
move on to other languages.
Regardless, with a few exceptions, such as what I consider a rather poor
release of SSL on VMS, I have not been convinced that I really need to
abandon what I already know.
It's not about abandoning. It's about expanding your horizons and your
expectations.
I'm 68 1/2 years old. These days, that 1/2 is significant.

On the days that I can actually convince myself to do something, it's
much more often working on the airplanes than the computers.
Post by j***@gmail.com
Sometimes you can appreciate home all the more by going
out and exploring the world.
The airplanes, at least for me, are much better for that.
Post by j***@gmail.com
It's even easier these days considering the
near oracle like quality of google. "How do I do X in language Y". Most
of the time it will take you to the relevant question on stackoverflow!
Darn kids these days, there was a time when you actually had to read
the manual and people were entitled to expect you to! They don't know
what they are missing. Or maybe its the other way around. :-)
You got that right. The DEC documentation could actually teach you some
things. At least for me, what has replaced it is of much poorer quality.
Phillip Helbig (undress to reply)
2015-01-21 21:34:30 UTC
Permalink
Post by j***@gmail.com
Out of curiosity, when's the last time you tried to learn a new programming
language on its own terms? You know, just for the sake of learning and
expanding the skill set?
No need. A good Fortran programmer can write Fortran in any language.
Simon Clubley
2015-01-21 22:18:00 UTC
Permalink
Post by David Froble
Some code similar to what's between the +++ and --- would have to exist
somewhere. If part of DCL, fine, but must exist.
I was just showing that some new fangled data type in some new fangled
language wasn't much different that what exists in one of the old
compiled languages.
I think probably the best way to respond here is to think about layers
of abstraction.

At the lowest level, you write code which runs on bare metal and you
get to think about (for example) which registers need saving according
to the ABI in use when you need to call an interrupt handler.

Somewhere higher up you are running under an operating system but
using lower level languages whose datatypes are modelled based on
the hardware typically in use.

A bit higher than that you have traditional problem area specific
languages which start to model datatypes in terms of the problems
the languages are designed to solve.

And somewhere towards the top of that scale, you have languages in
which the high level datatypes are decoupled from the hardware in use
and are designed to allow one to express some problems more compactly
at the expense of absolute code execution efficiency.

Going higher up that scale allows one to write code more quickly at
the expense of overall efficiency and as hardware has developed there's
been somewhat of a tendency to move higher up that scale for more
applications.

There's absolutely no reason, for example, why you can't manually write
an associative array library in assembly language, but you would be nuts
to do so these days unless you had some very specific and unusual reasons.

Likewise, just because a specific variant of a language was the best tool
for a specific range of jobs 20 years ago, this does not necessarily mean
this language is still the best choice for that same range of jobs 20
years on.

There will be some jobs for which that language is still an ideal choice
but there will also be other jobs for which other languages or a heavily
enhanced version of the original language are a better choice these days.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Jan-Erik Soderholm
2015-01-20 23:59:30 UTC
Permalink
Post by Jan-Erik Soderholm
OK, so a similar data type exist in the base Basic distribution?
I thought not.
If your position is dependent upon a particular data type existing, then I
10 Dim L$(99,2) ! Create an array of dynamic string descriptors
<some code to load L$(index,1) with a key value
and L$(index,2) with the associated data>
! This would be the "tool" to retrive data based upon the key
String Function RetriveData( <key> )
For I% = 1% to 99%
If <key> = L$(I%,1%)
Then RetriveData = L$(I%,2%)
Exit Function
End If
Next I%
RetriveData = ""
End Function
! This would be a retrival
D$ = RetriveData( <some key> )
Yes, but that uses a sequential search of the array, right?
The search time will grow in line with the size of the array.

Python dict's are hashed on the key and has very fast search
on the key value for any reasonable size within your current
memory limits.

Jan-Erik.
David Froble
2015-01-21 03:04:54 UTC
Permalink
Post by Jan-Erik Soderholm
Post by Jan-Erik Soderholm
OK, so a similar data type exist in the base Basic distribution?
I thought not.
If your position is dependent upon a particular data type existing, then I
10 Dim L$(99,2) ! Create an array of dynamic string descriptors
<some code to load L$(index,1) with a key value
and L$(index,2) with the associated data>
! This would be the "tool" to retrive data based upon the key
String Function RetriveData( <key> )
For I% = 1% to 99%
If <key> = L$(I%,1%)
Then RetriveData = L$(I%,2%)
Exit Function
End If
Next I%
RetriveData = ""
End Function
! This would be a retrival
D$ = RetriveData( <some key> )
Yes, but that uses a sequential search of the array, right?
The search time will grow in line with the size of the array.
Python dict's are hashed on the key and has very fast search
on the key value for any reasonable size within your current
memory limits.
Jan-Erik.
You appear to not have consider this in the original post.

"Ok, syntax may not be all correct, and it's over simplified"
^^^^^^^^^^^^^^^^^^^^

I was doing hashed keys back in 1974. I understand many ways to do
these things, from a simple binary search to B-tree structures, and such.

You've gone off on a tangent. The original post was to show that the
capability wasn't all that difficult in an older compiled language, and
that yes, a data type that does the job does exist in Basic.
Jan-Erik Soderholm
2015-01-21 11:34:33 UTC
Permalink
Post by David Froble
Post by Jan-Erik Soderholm
Post by Jan-Erik Soderholm
OK, so a similar data type exist in the base Basic distribution?
I thought not.
If your position is dependent upon a particular data type existing, then I
10 Dim L$(99,2) ! Create an array of dynamic string descriptors
<some code to load L$(index,1) with a key value
and L$(index,2) with the associated data>
! This would be the "tool" to retrive data based upon the key
String Function RetriveData( <key> )
For I% = 1% to 99%
If <key> = L$(I%,1%)
Then RetriveData = L$(I%,2%)
Exit Function
End If
Next I%
RetriveData = ""
End Function
! This would be a retrival
D$ = RetriveData( <some key> )
Yes, but that uses a sequential search of the array, right?
The search time will grow in line with the size of the array.
Python dict's are hashed on the key and has very fast search
on the key value for any reasonable size within your current
memory limits.
Jan-Erik.
You appear to not have consider this in the original post.
"Ok, syntax may not be all correct, and it's over simplified"
^^^^^^^^^^^^^^^^^^^^
Fine. I guess you had to do that to create an example. But then
it will not scale very well. Python lookup time is the same no
matter the size of the dictionary. For small dictionaries the
hash calculation might be longer then a seq search, though...

Of course I understand that you *could* build someting in Basic
that looks like the built-in "dict" datatype in Python, but it
will never be "built-in" and a part of the language standard.
Post by David Froble
I was doing hashed keys back in 1974. I understand many ways to do these
things, from a simple binary search to B-tree structures, and such.
Apart from that hashed keys doesn't use either binary search or
B-three structures, you might very well understand them anyway.
No problem. The point is still that is is not part of the Basic
language standard.
Post by David Froble
You've gone off on a tangent. The original post was to show that the
capability wasn't all that difficult in an older compiled language, and
that yes, a data type that does the job does exist in Basic.
No, it doesn't! There is no data type like the Python "dict" i Basic!
You have to write your own routines using the available (simpler)
data types.

Jan-Erik.
j***@gmail.com
2015-01-21 13:10:24 UTC
Permalink
Post by Jan-Erik Soderholm
No, it doesn't! There is no data type like the Python "dict" i Basic!
You have to write your own routines using the available (simpler)
data types.
I think his basic point (no pun intended!) is that the tools are good
enough for him so therefore they should be good enough for everyone.

It is true that there isn't a computational problem in the world that eludes
the power of DEC Basic. But that's true for pretty much any programming
language. I don't think anyone here is saving that they have a problem that
DEC Basic can't solve. I think most of us would simply find it onerous given
the expressive power that is now available... largely for free!

I would imagine that even Froble could concede that there was a time
that he looked forward to new features added to his trusty DEC Basic toolset.
I would hope that familiarity with that excitement could enable one to understand why others might be drawn to the features of newer languages.

EJ
Stephen Hoffman
2015-01-21 14:25:11 UTC
Permalink
Post by j***@gmail.com
I would imagine that even Froble could concede that there was a time
that he looked forward to new features added to his trusty DEC Basic toolset.
I would hope that familiarity with that excitement could enable one to
understand why others might be drawn to the features of newer languages.
Or to the substantially updated and got-to-have-it versions of VMS,
from the ancient times. Outside of the folks that want or need
Poulson-class servers, that's probably not V8.4-1H1. Whether the
x86-64 port or subsequent releases can add significant new features —
beyond the platform port — probably depends on how big VSI can get and
particularly on how much revenue they can realize from their initial
VMS and LP releases and/or support.

As for the future of BASIC, it'd be interesting to see what might
happen should VSI decide to overhaul DEC BASIC, adding object support,
pointer support, garbage collection and maybe some other new features
into the language. This'd probably best follow the Visual Basic AS
syntax for pointers, given the VB syntax is long established. This
won't draw all that many folks away from C, C++, Python or other
higher-profile languages. But the crowd using VB was and probably
still is bigger than the crowd using VMS, l'd expect.

The flaws in DCL, however, remain. It's clunky and confusing to use
with its asymmetric quoting and its fondness for quoted quotes for
various tasks, and that BASIC and Macro32 can solve various of these
limitations — sort of, as BASIC doesn't have a good way to chain
together a series of commands, short of spawning off DCL — won't draw
new folks to VMS.

Now as to whether VSI can get to profitability and can then start
seriously chasing what's available on other platforms, and can start
growing the user base? That's no small and no simple project, either.
--
Pure Personal Opinion | HoffmanLabs LLC
John Reagan
2015-01-21 14:50:33 UTC
Permalink
Post by Stephen Hoffman
As for the future of BASIC, it'd be interesting to see what might
happen should VSI decide to overhaul DEC BASIC, adding object support,
pointer support, garbage collection and maybe some other new features
into the language. This'd probably best follow the Visual Basic AS
syntax for pointers, given the VB syntax is long established. This
won't draw all that many folks away from C, C++, Python or other
higher-profile languages. But the crowd using VB was and probably
still is bigger than the crowd using VMS, l'd expect.
We provided a DEC BASIC to VB converter. As far as I know, almost nobody used it.
Stephen Hoffman
2015-01-21 15:17:51 UTC
Permalink
Post by John Reagan
We provided a DEC BASIC to VB converter. As far as I know, almost nobody used it.
But was that because they didn't like the language dialect, or because
they didn't want to or couldn't easily migrate to Microsoft Windows?
--
Pure Personal Opinion | HoffmanLabs LLC
Bill Gunshannon
2015-01-21 15:23:45 UTC
Permalink
Post by Stephen Hoffman
Post by John Reagan
We provided a DEC BASIC to VB converter. As far as I know, almost nobody used it.
But was that because they didn't like the language dialect, or because
they didn't want to or couldn't easily migrate to Microsoft Windows?
That was my immediate thought as well.

bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
David Froble
2015-01-21 19:25:42 UTC
Permalink
Post by John Reagan
Post by Stephen Hoffman
As for the future of BASIC, it'd be interesting to see what might
happen should VSI decide to overhaul DEC BASIC, adding object support,
pointer support, garbage collection and maybe some other new features
into the language. This'd probably best follow the Visual Basic AS
syntax for pointers, given the VB syntax is long established. This
won't draw all that many folks away from C, C++, Python or other
higher-profile languages. But the crowd using VB was and probably
still is bigger than the crowd using VMS, l'd expect.
We provided a DEC BASIC to VB converter. As far as I know, almost nobody used it.
I never knew about it.

What about a VB to DEC Basic converter?
V***@SendSpamHere.ORG
2015-01-21 14:58:51 UTC
Permalink
Post by Stephen Hoffman
Post by j***@gmail.com
I would imagine that even Froble could concede that there was a time
that he looked forward to new features added to his trusty DEC Basic toolset.
I would hope that familiarity with that excitement could enable one to
understand why others might be drawn to the features of newer languages.
Or to the substantially updated and got-to-have-it versions of VMS,
from the ancient times. Outside of the folks that want or need
Poulson-class servers, that's probably not V8.4-1H1. Whether the
x86-64 port or subsequent releases can add significant new features —
beyond the platform port — probably depends on how big VSI can get and
particularly on how much revenue they can realize from their initial
VMS and LP releases and/or support.
As for the future of BASIC, it'd be interesting to see what might
happen should VSI decide to overhaul DEC BASIC, adding object support,
pointer support, garbage collection and maybe some other new features
into the language. This'd probably best follow the Visual Basic AS
syntax for pointers, given the VB syntax is long established. This
won't draw all that many folks away from C, C++, Python or other
higher-profile languages. But the crowd using VB was and probably
still is bigger than the crowd using VMS, l'd expect.
The flaws in DCL, however, remain. It's clunky and confusing to use
with its asymmetric quoting and its fondness for quoted quotes for
Not any less "clunky and confusing ot use" than trying to cast C function
pointers. You either know its quirks and syntax or you have to learn it.
Post by Stephen Hoffman
various tasks, and that BASIC and Macro32 can solve various of these
limitations — sort of, as BASIC doesn't have a good way to chain
together a series of commands, short of spawning off DCL — won't draw
new folks to VMS.
The problem with spawning a command is that it is now NOT running in the
context of the process in which it might be trying to act upon.
Post by Stephen Hoffman
Now as to whether VSI can get to profitability and can then start
seriously chasing what's available on other platforms, and can start
growing the user base? That's no small and no simple project, either.
I'd think that a goal of simply maintaining the user base is better goal.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Stephen Hoffman
2015-01-21 15:30:19 UTC
Permalink
Post by V***@SendSpamHere.ORG
Post by Stephen Hoffman
The flaws in DCL, however, remain. It's clunky and confusing to use
with its asymmetric quoting and its fondness for quoted quotes for
Not any less "clunky and confusing ot use" than trying to cast C function
pointers. You either know its quirks and syntax or you have to learn it.
I've not suggested csh, C nor BASIC as a command line. Nor have I
suggested something as concise as BF, for that matter.
Post by V***@SendSpamHere.ORG
Post by Stephen Hoffman
Now as to whether VSI can get to profitability and can then start
seriously chasing what's available on other platforms, and can start
growing the user base? That's no small and no simple project, either.
I'd think that a goal of simply maintaining the user base is better goal.
Short-term, certainly. Longer-term, installed base growth with stable
or increasing revenues are what allows the vendor to substantially
enhance and upgrade the operating system, and are what allows the
vendor to lower the prices on the software and the support. Having VMS
as it is now through the next decade or two may well be a viable
business, but one that'll likely continue to slowly tail off as the
applications and as staff age out.

The command line is unfortunately the standard operations and
management interface for VMS right now, and aiming products at the
installed base and at arcane command line environments is unlikely to
become a growth market. Without new applications and new users that
are at least replacing those that are aging out and preferably adding
additional applications and users, there's no good outcome, either.
--
Pure Personal Opinion | HoffmanLabs LLC
JF Mezei
2015-01-21 15:37:47 UTC
Permalink
Post by Stephen Hoffman
The flaws in DCL, however, remain. It's clunky and confusing to use
with its asymmetric quoting and its fondness for quoted quotes for
various tasks,
2 questions:

1- Is it possible to get DCL to support modern quoting that causes less
irritation to Hoff ?

Is it possible that the quoting exagerations are not caused by the
quoting logic, but rather by the passing of arguments to other DCL
procedures which also then pass those arguments to others etc etc which
in the end forces on to ensure the arguments end up at the furthest
command procedure as a quoted string with possibly spaces in it ?

(as I recall, the LAT startup procedure required infinite supply of
quotes in the arguments.

Should that be fixed instead of the quoting mechanism ? For instance,
DCL treating the content of a symbol as a single string unit and not try
to break it up into different arguments ?

$myarg = "chocolate mousse cake"
@myrecipe 'myarg

would result in myrecipe.com seeing 1 argument "chocolate mousse cake"
instead of seing 3 arguments.



2- DCL versions

How difficult would it be to do something like Unix and have the first
line of a DCL command procedure define the DCL flavour. This would allow
procedures that make use of new features, new argumebnt apssing etc to
exist alongside procedures that use the old DCL for compatibility purposes.
V***@SendSpamHere.ORG
2015-01-21 15:52:28 UTC
Permalink
Post by JF Mezei
Post by Stephen Hoffman
The flaws in DCL, however, remain. It's clunky and confusing to use
with its asymmetric quoting and its fondness for quoted quotes for
various tasks,
1- Is it possible to get DCL to support modern quoting that causes less
irritation to Hoff ?
Is it possible that the quoting exagerations are not caused by the
quoting logic, but rather by the passing of arguments to other DCL
procedures which also then pass those arguments to others etc etc which
in the end forces on to ensure the arguments end up at the furthest
command procedure as a quoted string with possibly spaces in it ?
(as I recall, the LAT startup procedure required infinite supply of
quotes in the arguments.
Should that be fixed instead of the quoting mechanism ? For instance,
DCL treating the content of a symbol as a single string unit and not try
to break it up into different arguments ?
$myarg = "chocolate mousse cake"
@myrecipe 'myarg
would result in myrecipe.com seeing 1 argument "chocolate mousse cake"
instead of seing 3 arguments.
2- DCL versions
How difficult would it be to do something like Unix and have the first
line of a DCL command procedure define the DCL flavour. This would allow
procedures that make use of new features, new argumebnt apssing etc to
exist alongside procedures that use the old DCL for compatibility purposes.
It's software; most anything is possible. A "$! DCL2", for example, would
not break existing functionality but there's already been complaint in this
thread about some functions working in comments. I suppose it's fair but it
is no different than the shebang stuff in unix shells.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Stephen Hoffman
2015-01-21 16:05:34 UTC
Permalink
Post by JF Mezei
1- Is it possible to get DCL to support modern quoting that causes less
irritation to Hoff ?
If you believe that quoting is the extent of my issues with DCL, kindly
please re-read some of my earlier messages.
Post by JF Mezei
2- DCL versions
How difficult would it be to do something like Unix and have the first
line of a DCL command procedure define the DCL flavour.
Implementing a shebang-like
<http://en.wikipedia.org/wiki/Shebang_(Unix)> prefix in the file?
Certainly technically feasible, but it'd mean stuffing both CLIs into
P1 space or figuring out how to remap the CLIs on the fly, and logic to
figure out which grammar was in current use within a process. Much
easier to have separate CLI images and separate processes. Certainly
if the shebang approach was generalized beyond DCL grammar selection,
it'd allow other languages to be invoked. But then the shebang is not
how VMS traditionally differentiates this stuff, as VMS depends on
another of my favorite morasses, the file type. It'd be more typical
of VMS to use a different file type, whether .DCL64 or maybe
resurrecting the old CMD extension from eons past. Or if John Reagan
does get around to working on the DCL replacement, he could name it
.JCL. Changing the new file type away would avoid some of the
confusion that arises in network file transfers secondary to the use of
.COM for Windows executable files.

Can't say I see any of this happening anytime soon, though.
--
Pure Personal Opinion | HoffmanLabs LLC
JF Mezei
2015-01-21 16:17:28 UTC
Permalink
Post by Stephen Hoffman
If you believe that quoting is the extent of my issues with DCL, kindly
please re-read some of my earlier messages.
I did not mean to imply that the quoting was the only problem. The
trick here is to find a path that allows old stuff to continue to work
while VMS evolves with new functionality.

So with every problem you raise, the question becomes: can we evolve DCL
to fix this (either in a upward cmpatible way, or one requiring
DCL64.exe, the shebang or other approach).

Is it correct to state that with Unix, when you invoke a shell script, a
new process is created, so it becomes easier to give that process the
shell that is specified in the first line of the script ?
Bill Gunshannon
2015-01-21 16:18:09 UTC
Permalink
Post by Stephen Hoffman
Post by JF Mezei
1- Is it possible to get DCL to support modern quoting that causes less
irritation to Hoff ?
If you believe that quoting is the extent of my issues with DCL, kindly
please re-read some of my earlier messages.
Post by JF Mezei
2- DCL versions
How difficult would it be to do something like Unix and have the first
line of a DCL command procedure define the DCL flavour.
Implementing a shebang-like
<http://en.wikipedia.org/wiki/Shebang_(Unix)> prefix in the file?
Certainly technically feasible, but it'd mean stuffing both CLIs into
P1 space or figuring out how to remap the CLIs on the fly, and logic to
figure out which grammar was in current use within a process. Much
easier to have separate CLI images and separate processes. Certainly
if the shebang approach was generalized beyond DCL grammar selection,
it'd allow other languages to be invoked. But then the shebang is not
how VMS traditionally differentiates this stuff, as VMS depends on
another of my favorite morasses, the file type. It'd be more typical
of VMS to use a different file type, whether .DCL64 or maybe
resurrecting the old CMD extension from eons past. Or if John Reagan
does get around to working on the DCL replacement, he could name it
.JCL. Changing the new file type away would avoid some of the
confusion that arises in network file transfers secondary to the use of
.COM for Windows executable files.
Can't say I see any of this happening anytime soon, though.
Just my $.02 worth.

Seems to me based on all the comments I have seen on this subject that
the best solution would be to leave DCL alone as there are apparently
piles and piles of existing DCL scripts that one should not risk breaking.
Thus, the true solution would be to create a new scripting systems
totally separate from DCL.

bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
David Froble
2015-01-21 21:42:16 UTC
Permalink
Post by Stephen Hoffman
Post by JF Mezei
1- Is it possible to get DCL to support modern quoting that causes
less irritation to Hoff ?
If you believe that quoting is the extent of my issues with DCL, kindly
please re-read some of my earlier messages.
Post by JF Mezei
2- DCL versions
How difficult would it be to do something like Unix and have the first
line of a DCL command procedure define the DCL flavour.
Implementing a shebang-like
<http://en.wikipedia.org/wiki/Shebang_(Unix)> prefix in the file?
Certainly technically feasible, but it'd mean stuffing both CLIs into P1
space or figuring out how to remap the CLIs on the fly, and logic to
figure out which grammar was in current use within a process. Much
easier to have separate CLI images and separate processes. Certainly
if the shebang approach was generalized beyond DCL grammar selection,
it'd allow other languages to be invoked. But then the shebang is not
how VMS traditionally differentiates this stuff, as VMS depends on
another of my favorite morasses, the file type. It'd be more typical of
VMS to use a different file type, whether .DCL64 or maybe resurrecting
the old CMD extension from eons past. Or if John Reagan does get around
to working on the DCL replacement, he could name it .JCL. Changing the
new file type away would avoid some of the confusion that arises in
network file transfers secondary to the use of .COM for Windows
executable files.
Can't say I see any of this happening anytime soon, though.
Which leads back to the question "if there are working alternatives, why
not just use them?"
Simon Clubley
2015-01-21 21:45:02 UTC
Permalink
Post by David Froble
Which leads back to the question "if there are working alternatives, why
not just use them?"
Because the proposed solution for the problem area at hand may be better
given what we now know after years/decades of research.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
John Reagan
2015-01-21 16:21:33 UTC
Permalink
Post by JF Mezei
1- Is it possible to get DCL to support modern quoting that causes less
irritation to Hoff ?
To give some sense of the difficulty in changing DCL...

During the port to Itanium, we had the IMACRO compiler collect and print
out various pieces of information about the modules. The number of
"routines", sizes, number of temp registers used, CCs used, predicates used, and
flow graph information about the "complexity". It is common for routines to
jump into another routine and then into another routine, etc. While that wasn't a problem on VAX, it was somewhat of a problem on Alpha since you had to match
prologs with epilogs with respect to register restores, and it was worse on
Itanium to match up all the 'alloc' instructions so the output registers would
all match regardless of which entry point was used (and don't get me started
on NaTs).

The #1 complex module? The shadow driver. #2? One of the modules in the
Macro32 parser itself. #3? DCL. Routine after routine after routine all
with JSB linkages that jump in and out of each other with random pieces of
global state shoved into every corner. And the funky stack management (don't
forget DCL has a supervisor mode stack but the ^Y interrupts your user mode
program) when you hit ^Y/exit or ^Y/continue is calling standard specific and hurts your brain.
Post by JF Mezei
2- DCL versions
How difficult would it be to do something like Unix and have the first
line of a DCL command procedure define the DCL flavour. This would allow
procedures that make use of new features, new argumebnt apssing etc to
exist alongside procedures that use the old DCL for compatibility purposes.
Either that or a SET EXTENDED_DCL command or such. I actually like the shebang
style. One could imagine DCL taking the remainder of the .COM file and giving
it as input to the command in the shebang. That is if anybody can read the
DCL source code to figure it out.
Stephen Hoffman
2015-01-21 17:56:30 UTC
Permalink
Post by John Reagan
To give some sense of the difficulty in changing DCL...
Until the Itanium port, DCL had its own home-grown threading, too.

If VSI does decide to head down the shebang path (and no pun intended),
I'd prefer to see it using a different file type.

Right now, who knows what stuff is on the first line of an existing DCL
procedure.

Then there's one of the more subtle difficulties with file-format
sniffing in general: security. (This with file magic, which is
somewhat beyond the shebang handling.) There've been valid
multi-format files constructed, and sniffing file data to determine the
file type can be perilous practice, particularly if that sniffing is
not implemented in exactly the same way everywhere the sniffing is
being performed. One of the earliest attacks I've encountered was
Gifar <http://en.wikipedia.org/wiki/Gifar>, and there are others. Not
a big deal with entirely trusted files or when the sniff is always
consistent or when the file type always selects the file format, but
any inconsistent sniffing might not have the most desirable results.

Trying to do this syntax and grammar retrofit compatibly and within the
same DCL-ish context through SET PROCESS /PARSE-style syntax mechanisms
and shebangs and related does means more work than using entirely
separate CLIs, and it means that most sites will probably either stay
with DCL as it is, or will end up with a mixture of the two, and the
old code — short of a very effective translation tool — won't ever go
away. How much CC /STANDARD=VAXC code is still around, after all?
Again, absolute upward compatibility tends to lead to bigger messes and
more effort — particularly when the support for the old and deprecated
syntax doesn't ever get removed.

I'd rather see additions and enhancements that pull folks forward, and
— if there's a subsequent DCL retirement planned — a schedule for that
removal. But then DCL64 probably isn't going to sell a whole lot of
new licenses. Maybe a bash or another CLI might sell a few, though.
It'd be interesting to see the sys$cli interfaces officially
documented; there are internal areas of VMS that aren't documented
and/or aren't stable: sys$cli, what would be a file system layer, a
FUSE layer, etc.
--
Pure Personal Opinion | HoffmanLabs LLC
JF Mezei
2015-01-21 18:41:30 UTC
Permalink
Just an idea:

right now, within DCL, the "@" sign says read the DCL input from some
other location.

What about a different sign such as } or whatever to tell DCL to read
input not only from a different location but also with different command
processor ?

(there may be some implications when you submit a batch job, you might
have to specify the command processor if not DCL by default).
David Froble
2015-01-21 21:54:54 UTC
Permalink
Post by Stephen Hoffman
Post by John Reagan
To give some sense of the difficulty in changing DCL...
Until the Itanium port, DCL had its own home-grown threading, too.
If VSI does decide to head down the shebang path (and no pun intended),
I'd prefer to see it using a different file type.
Right now, who knows what stuff is on the first line of an existing DCL
procedure.
Might I suggest some form of "$ vfy :== f$verify(0)"
Post by Stephen Hoffman
Trying to do this syntax and grammar retrofit compatibly and within the
same DCL-ish context through SET PROCESS /PARSE-style syntax mechanisms
and shebangs and related does means more work than using entirely
separate CLIs, and it means that most sites will probably either stay
with DCL as it is, or will end up with a mixture of the two, and the old
code — short of a very effective translation tool — won't ever go
away. How much CC /STANDARD=VAXC code is still around, after all?
Again, absolute upward compatibility tends to lead to bigger messes and
more effort — particularly when the support for the old and deprecated
syntax doesn't ever get removed.
I'd rather see additions and enhancements that pull folks forward, and —
if there's a subsequent DCL retirement planned — a schedule for that
removal.
I think it's reasonable for "if it ain't broke, don't fix it", and
breaking someone's (however disgusting) DCL procedures will not leave
them very happy.

It's a bit like the "bird in the hand vs 2 very pretty birds in the
bush". There is never a guarantee you'll ever get any of the birds in
the bush. If you never try, then it's sure you won't get them. But
releasing the one in hand maybe isn't the best method to try for the
ones in the bush.

Now I'm wondering if any of that actually makes any sense ...
JF Mezei
2015-01-21 22:23:11 UTC
Permalink
Just a comment:

There have been suggestions about adding looping. (I use that as an
example).


One can already do looking in DCL, and except for ability to do a loop
on a single line which you can do in bash, there isn't much functionlity
that is prevented.

The focus should be on giving DCL functionlity that is missing or
extremely hard/complex to do.

for instance: make it possible do do

$edit "Recette de gâteau au chocolat.txt" instead of the extremely
complex and non obvious escaping needed in DCL/VMS.


Another suggestion: once VMS 1.0 is available on that architecture I
can't name without making people angry, VSI should poll those customers
who do migrate to that architecture on what features they are using (and
this need upward compatibility).

This may allow VSI to make non-upward competible changes to VMS on that
platform, knowing customers are not dependent on old behaviour and thus
enable new features that way without being hampered by customers with
legacy code who aren't gonna upgrade anyways.

V***@SendSpamHere.ORG
2015-01-21 19:44:23 UTC
Permalink
Post by Stephen Hoffman
Post by John Reagan
To give some sense of the difficulty in changing DCL...
Until the Itanium port, DCL had its own home-grown threading, too.
That was nothing. What RMS does is far crazier!
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
m***@gmail.com
2015-01-21 21:11:22 UTC
Permalink
Post by John Reagan
Post by JF Mezei
1- Is it possible to get DCL to support modern quoting that causes less
irritation to Hoff ?
To give some sense of the difficulty in changing DCL...
During the port to Itanium, we had the IMACRO compiler collect and print
out various pieces of information about the modules. The number of
"routines", sizes, number of temp registers used, CCs used, predicates used, and
flow graph information about the "complexity". It is common for routines to
jump into another routine and then into another routine, etc. While that wasn't a problem on VAX, it was somewhat of a problem on Alpha since you had to match
prologs with epilogs with respect to register restores, and it was worse on
Itanium to match up all the 'alloc' instructions so the output registers would
all match regardless of which entry point was used (and don't get me started
on NaTs).
The #1 complex module? The shadow driver. #2? One of the modules in the
Macro32 parser itself. #3? DCL. Routine after routine after routine all
with JSB linkages that jump in and out of each other with random pieces of
global state shoved into every corner. And the funky stack management (don't
forget DCL has a supervisor mode stack but the ^Y interrupts your user mode
program) when you hit ^Y/exit or ^Y/continue is calling standard specific and hurts your brain.
Post by JF Mezei
2- DCL versions
How difficult would it be to do something like Unix and have the first
line of a DCL command procedure define the DCL flavour. This would allow
procedures that make use of new features, new argumebnt apssing etc to
exist alongside procedures that use the old DCL for compatibility purposes.
Either that or a SET EXTENDED_DCL command or such. I actually like the shebang
style. One could imagine DCL taking the remainder of the .COM file and giving
it as input to the command in the shebang. That is if anybody can read the
DCL source code to figure it out.
No! Not the "shebang" style. The line starts out being a comment and then subsequent characters in the comment text say that it's not? That's illogical.

As for some other comments in this post I suggest people thinking about how they could be implemented.

You want to define an object/structure? What syntax would you use to define the fields? Under DCL I can say A = "0" in one line and the next say A = "78636534597487t784t" and DCL handles it. What happens with a string field in an object? Can you get the CLI to expand some "free-standing" strings (which presumably means a change of address) but not strings in objects?

To add looping (FOR, WHILE or whatever) the CLI would have to add some internal labels (start of loop, exit from loop) and an implicit GOTO to get back to the start of the loop. And if it doesn't have an explicitly labelled (cf. internally labelled) end point wouldn't it need BREAK and CONTINUE?


John
Simon Clubley
2015-01-21 21:41:36 UTC
Permalink
Post by m***@gmail.com
As for some other comments in this post I suggest people thinking
about how they could be implemented.
I've already posted some example syntax.
Post by m***@gmail.com
You want to define an object/structure? What syntax would you use
to define the fields? Under DCL I can say A = "0" in one line and the
next say A = "78636534597487t784t" and DCL handles it. What happens
with a string field in an object? Can you get the CLI to expand some
"free-standing" strings (which presumably means a change of address)
but not strings in objects?
You either allow assignment to implicitly create the field or you can
call an operator to explictly add the field to the object.

Conceptually, there's _no_ difference between a string in an object
and a free-standing string. They both have the string datatype and can
be directly compared. For example:

$ if free_standing_string .nes. object.string_field
$ then
$ ! Do something
$ endif

would be valid syntax in my mental model.
Post by m***@gmail.com
To add looping (FOR, WHILE or whatever) the CLI would have to add
some internal labels (start of loop, exit from loop) and an implicit
GOTO to get back to the start of the loop. And if it doesn't have an
explicitly labelled (cf. internally labelled) end point wouldn't it
need BREAK and CONTINUE?
You just use an iteration construct. A previous example:

$ queue_list = sys.o$getqui(<whatever>)
$ for queue in queue_list
$ write sys$output "queue name = ", queue.name
$ end for

would iterate over the list of queues returned and print out the name
of each one.

Of course, these are all just initial ideas and someone might come up
with a very good (and maybe obvious in hindsight :-)) reason why the
proposed syntax would not work.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Phillip Helbig (undress to reply)
2015-01-21 20:43:32 UTC
Permalink
Post by JF Mezei
@myrecipe 'myarg
Works, but officially it is 'myarg'. Leaving off the second " sometimes
works as well. Officially, always a pair. The only time asymmetry is
required is when expanding a symbol within a quoted string, e.g.
"''myarg'".
David Froble
2015-01-21 19:23:59 UTC
Permalink
Post by j***@gmail.com
I would imagine that even Froble could concede that there was a time
that he looked forward to new features added to his trusty DEC Basic toolset.
I would hope that familiarity with that excitement could enable one to
understand why others might be drawn to the features of newer languages.
Or to the substantially updated and got-to-have-it versions of VMS, from
the ancient times. Outside of the folks that want or need
Poulson-class servers, that's probably not V8.4-1H1. Whether the x86-64
port or subsequent releases can add significant new features — beyond
the platform port — probably depends on how big VSI can get and
particularly on how much revenue they can realize from their initial VMS
and LP releases and/or support.
As for the future of BASIC, it'd be interesting to see what might happen
should VSI decide to overhaul DEC BASIC, adding object support, pointer
support,
Sometimes my perspective is rather narrow, and I don't always understand
some concepts. Wouldn't you consider the LOC() function to take care of
the pointer question? I at least have found it very useful.
garbage collection and maybe some other new features into the
language. This'd probably best follow the Visual Basic AS syntax for
pointers, given the VB syntax is long established. This won't draw all
that many folks away from C, C++, Python or other higher-profile
languages. But the crowd using VB was and probably still is bigger than
the crowd using VMS, l'd expect.
The flaws in DCL, however, remain. It's clunky and confusing to use
with its asymmetric quoting and its fondness for quoted quotes for
various tasks, and that BASIC and Macro32 can solve various of these
limitations — sort of, as BASIC doesn't have a good way to chain
together a series of commands, short of spawning off DCL — won't draw
new folks to VMS.
Always room for improvement.
Now as to whether VSI can get to profitability and can then start
seriously chasing what's available on other platforms, and can start
growing the user base? That's no small and no simple project, either.
Well, that's the bottom line, huh?
David Froble
2015-01-21 19:17:18 UTC
Permalink
Post by j***@gmail.com
Post by Jan-Erik Soderholm
No, it doesn't! There is no data type like the Python "dict" i Basic!
You have to write your own routines using the available (simpler)
data types.
Ok, this is perhaps a "perspective" thing. My impression of Python, and
some other products, is that they SEEM very versatile because of all the
library procedures included in the distribution. Now, to me, a library
procedure is just that, and can exist in many environments. I, and this
is my perspective, perhaps different then that of others, do not
consider library routines as part of a language. I've been around
compiled languages for a long time, and "my perspective" is that the
code a compiler can generate is the language.

This is probably a rather narrow perspective, as there is usually more
than one way to skin a cat.
Post by j***@gmail.com
I think his basic point (no pun intended!) is that the tools are good
enough for him so therefore they should be good enough for everyone.
Actually, no, that is not the intention.

Specifically, my point is that while some seem (my perspective) to feel
that some capabilities don't exist in the older compiled languages, the
capability actually does exist. Not saying everyone needs to choose
that path.
Post by j***@gmail.com
It is true that there isn't a computational problem in the world that eludes
the power of DEC Basic.
YES! Just that. However, you may have a problem convincing some of
that statement.
Post by j***@gmail.com
But that's true for pretty much any programming
language. I don't think anyone here is saving that they have a problem that
DEC Basic can't solve. I think most of us would simply find it onerous given
the expressive power that is now available... largely for free!
I would imagine that even Froble could concede that there was a time
that he looked forward to new features added to his trusty DEC Basic toolset.
I would hope that familiarity with that excitement could enable one to understand why others might be drawn to the features of newer languages.
Since I worked with Basic+ on RSTS V4b, yes, you'd be very correct.
Many things have been added to VAX/DEC Basic. An example, the RECORD
construct, which opened up the capability for complex user declared
variable types.

I'm guessing the few compiler people figured that if they were going to
implement some feature, why not in all the languages, not just one.

Comments John?
John Reagan
2015-01-21 20:30:13 UTC
Permalink
Post by David Froble
Since I worked with Basic+ on RSTS V4b, yes, you'd be very correct.
Many things have been added to VAX/DEC Basic. An example, the RECORD
construct, which opened up the capability for complex user declared
variable types.
I'm guessing the few compiler people figured that if they were going to
implement some feature, why not in all the languages, not just one.
Comments John?
I doubt RECORD was added to BASIC just because it was in the another language.
We had no such concept to turn all the languages into single super-language.
We didn't add packed decimal to Fortran just because it is in COBOL, for
instance.

It probably was added (I have no connection) since it made DEC BASIC more
compatible with VMS and its interfaces. I'll make the same argument with
most of the features added to VAX Pascal V2 back in 1980ish, why we added
%LOC and %DESCR to Fortran, etc. It was probably all slanted toward the
common language environment and VMS' interfaces (hard to play with a FAB
if you don't have some notion of a structure or group - or you have no
typing like BLISS/Macro32).

VAX/DEC BASIC is quite different than the BASIC standards

* ANSI/ISO/IEC Standard for Minimal BASIC:
o ANSI X3.60-1978 "FOR MINIMAL BASIC"
o ISO/IEC 6373:1984 "DATA PROCESSING - PROGRAMMING LANGUAGES - MINIMAL BASIC"
* ANSI/ISO/IEC Standard for Full BASIC:
o ANSI X3.113-1987 "PROGRAMMING LANGUAGES FULL BASIC"
o ISO/IEC 10279:1991 "INFORMATION TECHNOLOGY - PROGRAMMING LANGUAGES - FULL BASIC"

Nobody has ever complained about that, right?
Craig A. Berry
2015-01-19 04:25:01 UTC
Permalink
Post by Stephen Hoffman
Post by Simon Clubley
I think it's time once again to build a list of DCL's flaws now that
VSI are around. Don't forget however that DCL is both a scripting
language and a UI. My initial list is below.
There's no...
UTF-8
asynchronous processing
floating point
unsigned integers
64-bit integers
binary data
objects
dictionaries
arrays
functions that return values
user-written lexical functions
support for menu-based and graphical-based user interfaces
JIT
compilation
embedding
debugging
DCL libraries
More specific error trapping than ON; let me catch specific errors.
etc...
Simon's command completion and command editing and command history, certainly.
Then there are parts of DCL which are seldom understood or easily misunderstood
scoping
quoting and double-quoting and the two-phase substitution processing
f$getqui
These are mostly good things to add, but very few of them would require
incompatible changes. Quite a few nice-to-have features, such as
character set conversion facilities or regular expressions, just need
new lexicals.

DCL is usually good about throwing a syntax error if it doesn't
understand something, and anything that's a syntax error now is fertile
ground for new features or notations. For example, curly braces don't
really do anything now that I can recall, so that delimiter could be
used for object or hash notation.

New data types and automatic data conversions would be difficult to do
compatibly, but if the new types were all objects and there were a
distinct object notation, it might be possible to eliminate any ambiguities.

It would be a gigantic mistake to ditch DCL rather than enhancing it.
Microsoft had to start something entirely new with PowerShell because
there was no hope of making DOS into a real language. DCL is infinitely
superior to DOS, even if it has some warts. Also, Microsoft could afford
to invest a ton in PowerShell and if it hadn't worked out, they could
have spent another fortune having another team implement something else.
VSI can't do that.

I spend a lot of my free time keeping Perl running on VMS, and I do
think Perl, Python, and bash should be available on the base
distribution, but for all its shortcomings I think DCL is too good to
give up on.
Simon Clubley
2015-01-19 20:40:16 UTC
Permalink
Post by Craig A. Berry
New data types and automatic data conversions would be difficult to do
compatibly, but if the new types were all objects and there were a
distinct object notation, it might be possible to eliminate any ambiguities.
I'm not seeing that as a real problem.

For example, if the lexicals start returning objects containing a set
of items instead of individual items as is currently done with the
lexicals, there's no reason why the new lexicals could not be placed in
their own package and referenced as such.

The fact the new lexicals will be returning entire objects instead of
individual strings means the calling sequence is going to change anyway.

For example, consider f$parse().

You would keep f$parse for compatibility with existing DCL code and
it would continue to return individual strings, but you could also
have a (say) sys package with a differently named f$parse returning an
object containing all the parsed fields in one go.

For example:

$ ! Old way
$ oname = f$parse(fname, , ,"NAME")
$ odir = f$parse(fname, , ,"DIRECTORY")
$ otype = f$parse(fname, , ,"TYPE")
$ write sys$output "name = ", oname, " dir = ", odir, " type = ", otype
$
$ ! New way
$ oparse = sys.o$parse(fname)
$ write sys$output "name = ", oparse.name, " dir = ",oparse.dir, -
" type = ", oparse.type

oparse would have a type of object (and a specific type of object).
However the variables within the oparse object would be of type string
and could be used as normal.

Furthermore, one could move objects around by assigning them to other
variables and the new variable would take on the type of the object
just as happens at the moment when a variable which was originally an
integer has a string assigned to it.

The above behaviour is totally compatible with existing DCL code and
you can mix-and-match old style and new style code in the same command
procedure.

In the above example, there's no reason why you could not say

$ if oname .nes. oparse.name
$ then
$ ! Do something
$ endif

as you would be comparing two string variables. The fact one of them
is contained within an object simply does not matter.

You may not be able to use string/integer operator names within objects
in order to avoid ambiguity when parsing multi-level objects, but apart
from that, I don't see any problem with the above approach.

It would also be nice to be able to write something like:

$ queue_list = sys.o$getqui(<whatever>)
$ for queue in queue_list
$ write sys$output "queue_name = ", queue.name
$ end for

That's a _lot_ cleaner than the current mess which is f$getqui()
especially when you start working on the entries within those queues
as well.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Bob Gezelter
2015-01-19 20:50:11 UTC
Permalink
Post by Simon Clubley
Post by Craig A. Berry
New data types and automatic data conversions would be difficult to do
compatibly, but if the new types were all objects and there were a
distinct object notation, it might be possible to eliminate any ambiguities.
I'm not seeing that as a real problem.
For example, if the lexicals start returning objects containing a set
of items instead of individual items as is currently done with the
lexicals, there's no reason why the new lexicals could not be placed in
their own package and referenced as such.
The fact the new lexicals will be returning entire objects instead of
individual strings means the calling sequence is going to change anyway.
For example, consider f$parse().
You would keep f$parse for compatibility with existing DCL code and
it would continue to return individual strings, but you could also
have a (say) sys package with a differently named f$parse returning an
object containing all the parsed fields in one go.
$ ! Old way
$ oname = f$parse(fname, , ,"NAME")
$ odir = f$parse(fname, , ,"DIRECTORY")
$ otype = f$parse(fname, , ,"TYPE")
$ write sys$output "name = ", oname, " dir = ", odir, " type = ", otype
$
$ ! New way
$ oparse = sys.o$parse(fname)
$ write sys$output "name = ", oparse.name, " dir = ",oparse.dir, -
" type = ", oparse.type
oparse would have a type of object (and a specific type of object).
However the variables within the oparse object would be of type string
and could be used as normal.
Furthermore, one could move objects around by assigning them to other
variables and the new variable would take on the type of the object
just as happens at the moment when a variable which was originally an
integer has a string assigned to it.
The above behaviour is totally compatible with existing DCL code and
you can mix-and-match old style and new style code in the same command
procedure.
In the above example, there's no reason why you could not say
$ if oname .nes. oparse.name
$ then
$ ! Do something
$ endif
as you would be comparing two string variables. The fact one of them
is contained within an object simply does not matter.
You may not be able to use string/integer operator names within objects
in order to avoid ambiguity when parsing multi-level objects, but apart
from that, I don't see any problem with the above approach.
$ queue_list = sys.o$getqui(<whatever>)
$ for queue in queue_list
$ write sys$output "queue_name = ", queue.name
$ end for
That's a _lot_ cleaner than the current mess which is f$getqui()
especially when you start working on the entries within those queues
as well.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
Gentlemen,

Actually, I would rather NOT debate a new or better language. Instead, I would be looking towards documenting and cleaning up the interface between the command line interpreter (CLI) and base system. I suspect that the last thing needed is yet another scripting language.

Cleaning up the interface might provide a better option than a particular language.

There are many languages for which immediate execution modes exist or can be developed (e.g., JavaScript, Python, Ruby, BASIC). The LIB$ routines already underlie the lexical functions. Cleaning up/documenting the CLI interface would allow other languages to be used as CLIs.

The distinction between scripting and programming languages has long since become a distinction without a difference.

- Bob Gezelter, http://www.rlgsc.com
John Reagan
2015-01-19 21:38:16 UTC
Permalink
Post by Simon Clubley
You would keep f$parse for compatibility with existing DCL code and
it would continue to return individual strings, but you could also
have a (say) sys package with a differently named f$parse returning an
object containing all the parsed fields in one go.
You mean like SYS$FILESCAN? What's your issue with multiple calls to F$PARSE? The overhead? You are writing in DCL after all...

And you want the lexical to populate all the fields even if you aren't going to use them? Isn't that more expensive? Imagine the overhead of collecting ALL the GETJPI fields or ALL the GETQUI fields? Ugh.
Post by Simon Clubley
$ queue_list = sys.o$getqui(<whatever>)
$ for queue in queue_list
$ write sys$output "queue_name = ", queue.name
$ end for
That's a _lot_ cleaner than the current mess which is f$getqui()
especially when you start working on the entries within those queues
as well.
But probably slower...
Simon Clubley
2015-01-19 21:52:09 UTC
Permalink
Post by John Reagan
Post by Simon Clubley
You would keep f$parse for compatibility with existing DCL code and
it would continue to return individual strings, but you could also
have a (say) sys package with a differently named f$parse returning an
object containing all the parsed fields in one go.
You mean like SYS$FILESCAN? What's your issue with multiple calls
to F$PARSE? The overhead? You are writing in DCL after all...
Using the traditional approach, the code is not nearly as concise is it
could be. There's also the overhead of calling the lexical multiple
times instead of just calling it once and returning an object containing
all the parsed fields.
Post by John Reagan
And you want the lexical to populate all the fields even if you
aren't going to use them? Isn't that more expensive? Imagine the
overhead of collecting ALL the GETJPI fields or ALL the GETQUI fields?
Ugh.
As computers have become faster and cheaper, the tradeoffs between
program development time and code execution time have changed.

I see Jan-Erik has also posted a queue example in Python which does
pretty much the same thing. If I read that code correctly, it appears
to populate an object in a similar way to the one I am suggesting.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
j***@yahoo.co.uk
2015-01-19 22:47:46 UTC
Permalink
Post by Simon Clubley
Post by John Reagan
Post by Simon Clubley
You would keep f$parse for compatibility with existing DCL code and
it would continue to return individual strings, but you could also
have a (say) sys package with a differently named f$parse returning an
object containing all the parsed fields in one go.
You mean like SYS$FILESCAN? What's your issue with multiple calls
to F$PARSE? The overhead? You are writing in DCL after all...
Using the traditional approach, the code is not nearly as concise is it
could be. There's also the overhead of calling the lexical multiple
times instead of just calling it once and returning an object containing
all the parsed fields.
Post by John Reagan
And you want the lexical to populate all the fields even if you
aren't going to use them? Isn't that more expensive? Imagine the
overhead of collecting ALL the GETJPI fields or ALL the GETQUI fields?
Ugh.
As computers have become faster and cheaper, the tradeoffs between
program development time and code execution time have changed.
I see Jan-Erik has also posted a queue example in Python which does
pretty much the same thing. If I read that code correctly, it appears
to populate an object in a similar way to the one I am suggesting.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
Simon said:
"As computers have become faster and cheaper, the tradeoffs between
program development time and code execution time have changed. "

Back in 1980 or so I remember telling my boss that when the 11/40 was
replaced with an 11/70, it would probably be sensible to consider
whether MACRO11 (with no debugger other than ODT) was actually the
right development tool to use for almost everything we developed. The
boss was actually very understanding (he was a Fortran man anyway).
As F77 hadn't arrived onsite at that point, DECUS RATFOR on top of
RSX/IAS Fortran4Plus filled in, till Whitesmiths C eventually arrived.

So here we are thirty odd years later having a remarkably similar
discussion, albeit with different hardware and software.

This time round I'd perhaps be happy with Python and GNV as major
pieces of the way forward, whilst hoping VSI could do a reasonable
job of not breaking the existing stuff for the next few years, and
maybe making point changes where important (e.g. disk volume sizes?).

Others may have other opinions, which is why the suggestion of
consulting the userbase outside this little enclave (current users?
potential?) is an interesting one.

Have a lot of fun
John
John Reagan
2015-01-19 22:53:11 UTC
Permalink
Post by Simon Clubley
Using the traditional approach, the code is not nearly as concise is it
could be. There's also the overhead of calling the lexical multiple
times instead of just calling it once and returning an object containing
all the parsed fields.
Concise <> readable/maintainable

If you want concise, I'll go get APL up and running for you.

And even with fast computers, many of those GETJPI items involve real I/O in the event some things are paged/swapped out (albeit unlikely given today's large memory configurations).

I'd rather not mung up DCL with aggregate returns (don't call them objects please) but rather say you should use Perl or Python for such larger tasks.
Stephen Hoffman
2015-01-20 00:23:08 UTC
Permalink
Post by John Reagan
I'd rather not mung up DCL with aggregate returns (don't call them
objects please) but rather say you should use Perl or Python for such
larger tasks.
Which gets back to looking at how to provide an alternative or a more
modern scripting language than what DCL provides.

So get Perl, Python or Lua into the base distro, and with a decent set
of libraries, and — like what is offered for DCL — allow an easy path
for direct invocation.

With embedding and scripting, where those languages support it, too.

For better or worse, DCL and Macro32 are the common programming
choices, having the benefit of being installed everywhere.
--
Pure Personal Opinion | HoffmanLabs LLC
John Reagan
2015-01-20 00:32:43 UTC
Permalink
Post by Stephen Hoffman
So get Perl, Python or Lua into the base distro, and with a decent set
of libraries, and -- like what is offered for DCL -- allow an easy path
for direct invocation.
My understanding is that the various legal departments don't want to include GPL code on the base distribution with the fear that it would require exposing all the source for all the pieces on the kit. That was why the separate DVD with Apache, GNV, etc. was created.

Personally (although I'm not a lawyer), I don't think that having an image with GPL doesn't taint the other images. However, adding regex() into the CRTL would be a problem.
Craig A. Berry
2015-01-20 01:14:38 UTC
Permalink
Post by John Reagan
Post by Stephen Hoffman
So get Perl, Python or Lua into the base distro, and with a decent set
of libraries, and -- like what is offered for DCL -- allow an easy path
for direct invocation.
My understanding is that the various legal departments don't want to include GPL code on the base distribution with the fear that it would require exposing all the source for all the pieces on the kit. That was why the separate DVD with Apache, GNV, etc. was created.
Personally (although I'm not a lawyer), I don't think that having an image with GPL doesn't taint the other images. However, adding regex() into the CRTL would be a problem.
The regular expression library libpcre is BSD, not GPL and is probably
more what you'd want than the one that ships with GNU libc anyway. With
Perl you have your choice of the Artistic or GPL licenses. I think
Artistic is a little less restrictive, but I am not a lawyer either.
Stephen Hoffman
2015-01-20 01:29:42 UTC
Permalink
Post by John Reagan
So get Perl, Python or Lua into the base distro, and with a decent set>
of libraries, and -- like what is offered for DCL -- allow an easy
path> for direct invocation.
My understanding is that the various legal departments don't want to
include GPL code on the base distribution with the fear that it would
require exposing all the source for all the pieces on the kit.
I'm well aware of the various GPLv2 and GPLv3 discussions, having been
in more than a few of those meetings over the years.
Post by John Reagan
That was why the separate DVD with Apache, GNV, etc. was created.
Might want to have the legal folks skim the Perl (artistic), Python or
Lua licenses, then. Those packages are not GPL.

FWIW, Apache isn't under GPL. It's under the Apache 2 license. Nor
are zip and unzip, for that matter, and those are a no-brainer for
inclusion into VMS.
Post by John Reagan
Personally (although I'm not a lawyer), I don't think that having an
image with GPL doesn't taint the other images.
GNV and some other bits are GPL, and the inclusion of GPL software and
particularly GPL3 software can be viewed as problematic in a
closed-source package. (This is also one of the reasons why I've
commented about open-sourcing VMS in the past, as that would simplify
some of the licensing and open-source integration. Though this open-
sourcing would obviously be a big mental shift and a business shift for
the folks at HP, and quite possibly also for the folks at VSI.)
Post by John Reagan
However, adding regex() into the CRTL would be a problem.
Digging around finds the <https://github.com/laurikari/tre/> regular
expression library, and there's also BSD grep
<http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/grep/>, and llvm
has regex bits including
<http://www.llvm.org/docs/doxygen/html/Regex_8h_source.html>
<http://llvm.org/docs/doxygen/html/Regex_8cpp_source.html>. Other
options are undoubtedly available, too.
--
Pure Personal Opinion | HoffmanLabs LLC
David Froble
2015-01-20 03:30:04 UTC
Permalink
Post by Stephen Hoffman
Post by John Reagan
I'd rather not mung up DCL with aggregate returns (don't call them
objects please) but rather say you should use Perl or Python for such
larger tasks.
Which gets back to looking at how to provide an alternative or a more
modern scripting language than what DCL provides.
So get Perl, Python or Lua into the base distro, and with a decent set
of libraries, and — like what is offered for DCL — allow an easy path
for direct invocation.
Which doesn't seem to be a problem, from what I can see.

Actually, if Python ran with DCL still being the CLI, it should not be a
problem. If you wanted Python as the CLI, that might be some work. Nor
do I have any clue what kind or how much work. Nor any clue as to any
benefits.
Post by Stephen Hoffman
With embedding and scripting, where those languages support it, too.
For better or worse, DCL and Macro32 are the common programming choices,
having the benefit of being installed everywhere.
Isn't that a business decision?

Selected languages could be bundled in with the base VMS distribution.
Marc Van Dyck
2015-01-20 18:15:51 UTC
Permalink
Post by John Reagan
If you want concise, I'll go get APL up and running for you.
Can we ask for that ? really ?
--
Marc Van Dyck
Bill Gunshannon
2015-01-20 18:40:15 UTC
Permalink
Post by Marc Van Dyck
Post by John Reagan
If you want concise, I'll go get APL up and running for you.
Can we ask for that ? really ?
It's been a long (really long) time since I looked, but wasn't APL
included in the CONDIST?

bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
abrsvc
2015-01-20 19:31:08 UTC
Permalink
APL is the only languages where it is easier to re-write the code than to debug it. Consise, yes. Short programs. yes. Easy to read and understand, not so much.
Bill Gunshannon
2015-01-20 19:39:12 UTC
Permalink
Post by abrsvc
APL is the only languages where it is easier to re-write the code than to debug it. Consise, yes. Short programs. yes. Easy to read and understand, not so much.
Once again, matter of opinion. Back when IBM was in it's prime they
were partnered with Marist College in Poughkeepsie. We used to get
their interns for summer work. Whizes with APL couldn't do anything
with COBOL or Fortran.

Oh, and I have been doing APL for over 30 years and I have no problem
understanding it. (Only do it for fun anymore, but still do it once
in a while.)

bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Jan-Erik Soderholm
2015-01-21 00:08:24 UTC
Permalink
Post by Bill Gunshannon
Post by abrsvc
APL is the only languages where it is easier to re-write the code than to debug it. Consise, yes. Short programs. yes. Easy to read and understand, not so much.
Once again, matter of opinion. Back when IBM was in it's prime they
were partnered with Marist College in Poughkeepsie. We used to get
their interns for summer work. Whizes with APL couldn't do anything
with COBOL or Fortran.
Oh, and I have been doing APL for over 30 years and I have no problem
understanding it. (Only do it for fun anymore, but still do it once
in a while.)
bill
This is one of the better APL tutorials I have seen:
https://www.youtube.com/watch?v=a9xAKttWgP4

I did some APL on an MVS mainframe in the 80's...

Jan-Erik.
c***@gmail.com
2015-01-21 15:16:33 UTC
Permalink
Post by Bill Gunshannon
Once again, matter of opinion. Back when IBM was in it's prime they
were partnered with Marist College in Poughkeepsie. We used to get
their interns for summer work. Whizes with APL couldn't do anything
with COBOL or Fortran.
The last time I had access to an APL compiler, I was wanted not to use it.
Turns out it was a transpiler which wrote BASIC. Both ran on a
DECSYSTEM-10 and the BASIC was interpreted.

Much to the dismay of a fellow who learned APL because it had a
reputation for doing large calculations "faster".
Bill Gunshannon
2015-01-21 15:28:47 UTC
Permalink
Post by c***@gmail.com
Post by Bill Gunshannon
Once again, matter of opinion. Back when IBM was in it's prime they
were partnered with Marist College in Poughkeepsie. We used to get
their interns for summer work. Whizes with APL couldn't do anything
with COBOL or Fortran.
The last time I had access to an APL compiler, I was wanted not to use it.
Turns out it was a transpiler which wrote BASIC. Both ran on a
DECSYSTEM-10 and the BASIC was interpreted.
Much to the dismay of a fellow who learned APL because it had a
reputation for doing large calculations "faster".
Immplementation shortcoming, not language shortcoming. All of the APL's
I have used were "large calculation fast". Even the one on the Z80. :-)

Anecdote: I worked with a guy at west Point who wrote an APL program
that took all the winning numbers for the New York State Lottery (this
was back when there was pretty much only one per state) Immplementation shortcoming, not language shortcoming. All of the APL's
I have used were "large calculation fast". Even the one on the Z80. :-)

Anecdote: I worked with a guy at West Point who wrote an APL program
that took all the winning numbers for the New York State Lottery (this
was back when there was pretty much only one lottery per state) and
searched for a patterns so he could predict a winning combination.
In all the years I was there he never succeeded as far as I know. :-)

bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
John Reagan
2015-01-21 14:47:46 UTC
Permalink
Post by Marc Van Dyck
Post by John Reagan
If you want concise, I'll go get APL up and running for you.
Can we ask for that ? really ?
--
Marc Van Dyck
I have the sources somewhere. :) One of my former co-workers was one of the VAX APL developers and was trying to get it running on Alpha. Apparently VAX APL generates VAX code on the fly for some diadic operators (I think double-dot and a few others). That was done for performance of course. He was playing with rewriting those into C and not do the on-the-fly code generation. It wouldn't be as fast, but it is portable and newer hardware is faster.

In my spare time after we get all the languages ported, updated to current standards, add all the new languages discussed here(I don't see the attraction to Rust or Lua myself and I dislike Python's indentation scheme), implement DCL64, and do it all without PAKs or revenue, I'll get right to it. I guess I'll need to setup a Kickstarter campaign for my salary.

And no, I don't have sources for VAX SCAN, VAX LISP, VAX Modula-2, VAX RPG-II, VAX CORAL, or VAX KOALA
Jan-Erik Soderholm
2015-01-19 23:23:23 UTC
Permalink
Post by Simon Clubley
I see Jan-Erik has also posted a queue example in Python which does
pretty much the same thing. If I read that code correctly, it appears
to populate an object in a similar way to the one I am suggesting.
Simon.
I was just thinking if commenting your OO-DCL example code. :-)

Yes, the Python implementation use the OO model that Python
is built upon. I have move the Python file that contains the
queue definitions to:

http://jescab2.dyndns.org/pub_docs/queues.py

so you can study how it is implementet. That file is what is
read by my first command in my example, "from vms import queues".
That "loads" the queue definitions and functions into Python.

As you can see, the higher level functions are built on the
interface to getquiw() that is included in the "starlet"
part of the VMS module for Python.

The "starlet" module has quite a few of the common system
services implented and directly usable from Python. Doing

import vms.starlet
help (vms-starlet) gives a list of functions directly
callable from the VMS port of Python:

acquire_galaxy_lock(...)
add_holder(...)
add_ident(...)
add_proxy(...)
adjwsl(...)
alloc(...)
ascefc(...)
asctim(...)
asctoid(...)
ascutc(...)
assign(...)
audit_event(...)
audit_eventw(...)
avoid_preempt(...)
bintim(...)
binutc(...)
brkthruw(...)
cancel(...)
check_access(...)
check_privilegew(...)
chkpro(...)
clref(...)
cpu_capabilities(...)
create_galaxy_lock(...)
create_galaxy_lock_table(...)
create_uid(...)
create_user_profile(...)
crelnm(...)
crelnt(...)
crembx(...)
creprc(...)
cvt_filename(...)
dacefc(...)
dalloc(...)
dassgn(...)
delete_galaxy_lock(...)
delete_galaxy_lock_table(...)
delete_intrusion(...)
delete_proxy(...)
dellnm(...)
delmbx(...)
delprc(...)
deq(...)
device_path_scan(...)
device_scan(...)
dismou(...)
display_proxy(...)
dlcefc(...)
enq(...)
enqw(...)
erapat(...)
expreg(...)
filescan(...)
find_held(...)
find_holder(...)
finish_rdb(...)
forcex(...)
format_acl(...)
format_audit(...)
free_user_capability(...)
get_align_fault_data(...)
get_galaxy_lock_info(...)
get_galaxy_lock_size(...)
get_security(...)
get_user_capability(...)
getdviw(...)
getenv(...)
getjpiw(...)
getlkiw(...)
getmsg(...)
getquiw(...)
getrmi(...)
getsyiw(...)
gettim(...)
getuai(...)
getutc(...)
grantid(...)
hash_password(...)
hiber(...)
icc_accept(...)
icc_close_assoc(...)
icc_connectw(...)
icc_disconnectw(...)
icc_open_assoc(...)
icc_receivew(...)
icc_reject(...)
icc_replyw(...)
icc_transceivew(...)
icc_transmitw(...)
idtoasc(...)
init_vol(...)
io_cleanup(...)
io_fastpathw(...)
io_performw(...)
io_setup(...)
mod_holder(...)
mod_ident(...)
mount(...)
numtim(...)
numutc(...)
parse_acl(...)
perm_dis_align_fault_report(...)
perm_report_align_fault(...)
persona_assume(...)
persona_clone(...)
persona_create(...)
persona_create_extension(...)
persona_delegate(...)
persona_delete(...)
persona_delete_extension(...)
persona_extension_lookup(...)
persona_find(...)
persona_modify(...)
persona_query(...)
persona_reserve(...)
process_affinity(...)
process_capabilities(...)
process_scan(...)
purgws(...)
readef(...)
registryw(...)
release_galaxy_lock(...)
rem_holder(...)
rem_ident(...)
resched(...)
resume(...)
revokid(...)
scan_intrusion(...)
schdwk(...)
set_devicew(...)
set_implicit_affinity(...)
set_process_propertiesw(...)
set_resource_domain(...)
set_security(...)
setddir(...)
setdfprot(...)
setef(...)
setime(...)
setpri(...)
setprn(...)
setprv(...)
setshlv(...)
setswm(...)
setuai(...)
setup_avoid_preempt(...)
snderr(...)
sndjbcw(...)
start_align_fault_report(...)
stop_align_fault_report(...)
subsystem(...)
suspnd(...)
timcon(...)
time_to_utc(...)
trnlnm(...)
utc_to_time(...)
verify_proxy(...)
waitfr(...)
wake(...)
wfland(...)
wflor(...)

In many cases higher level funtions has been created like
the ones I used in my example to read queue and job info.

Jan-Erik.
David Froble
2015-01-20 03:21:44 UTC
Permalink
Post by Simon Clubley
Post by John Reagan
Post by Simon Clubley
You would keep f$parse for compatibility with existing DCL code and
it would continue to return individual strings, but you could also
have a (say) sys package with a differently named f$parse returning an
object containing all the parsed fields in one go.
You mean like SYS$FILESCAN? What's your issue with multiple calls
to F$PARSE? The overhead? You are writing in DCL after all...
Using the traditional approach, the code is not nearly as concise is it
could be. There's also the overhead of calling the lexical multiple
times instead of just calling it once and returning an object containing
all the parsed fields.
Post by John Reagan
And you want the lexical to populate all the fields even if you
aren't going to use them? Isn't that more expensive? Imagine the
overhead of collecting ALL the GETJPI fields or ALL the GETQUI fields?
Ugh.
As computers have become faster and cheaper, the tradeoffs between
program development time and code execution time have changed.
I see Jan-Erik has also posted a queue example in Python which does
pretty much the same thing. If I read that code correctly, it appears
to populate an object in a similar way to the one I am suggesting.
Simon.
Then why not use the existing solution ???
V***@SendSpamHere.ORG
2015-01-19 22:28:59 UTC
Permalink
Post by John Reagan
Post by Simon Clubley
You would keep f$parse for compatibility with existing DCL code and
it would continue to return individual strings, but you could also
have a (say) sys package with a differently named f$parse returning an
object containing all the parsed fields in one go.
You mean like SYS$FILESCAN? What's your issue with multiple calls to F$PARSE? The overhead? You are writing in DCL after all...
And you want the lexical to populate all the fields even if you aren't going to use them? Isn't that more expensive? Imagine the overhead of collecting ALL the GETJPI fields or ALL the GETQUI fields? Ugh.
The everything and the kitchen sink approach to DCL coding... just in case
I decide to want something later on, get it all for me now! I'll step out
for lunch while you get it for me.
Post by John Reagan
Post by Simon Clubley
$ queue_list = sys.o$getqui(<whatever>)
$ for queue in queue_list
$ write sys$output "queue_name = ", queue.name
$ end for
That's a _lot_ cleaner than the current mess which is f$getqui()
especially when you start working on the entries within those queues
as well.
But probably slower...
But, those people that are pining for that will also (stupidly) do:

$ CALL A
$ ...
$ CALL B
$ ...
$ CALL C
$ ...
$ CALL D
$ ...
$ EXIT
$ A: SUBROUTINE
$ ...
$ EXIT
$ ENDSUBROUTINE
$ B: SUBROUTINE
$ ...
$ EXIT
$ ENDSUBROUTINE
$ C: SUBROUTINE
$ ...
$ EXIT
$ ENDSUBROUTINE
$ D: SUBROUTINE
$ ...
$ EXIT
$ ENDSUBROUTINE

Why? Because they write DCL like it's a programming language.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
David Froble
2015-01-20 03:20:04 UTC
Permalink
Post by John Reagan
Post by Simon Clubley
You would keep f$parse for compatibility with existing DCL code and
it would continue to return individual strings, but you could also
have a (say) sys package with a differently named f$parse returning an
object containing all the parsed fields in one go.
You mean like SYS$FILESCAN? What's your issue with multiple calls to F$PARSE? The overhead?
You are writing in DCL after all...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

And doesn't that put things into perspective?

:-) :-) :-)

This is an interesting discussion, and I think a good discussion, from
the perspective of "thinking".

But, what is going to be the most use to the most users? Scripting? Or
perhaps getting VMS to run serious applications?
Chris Scheers
2015-01-21 20:21:25 UTC
Permalink
Post by John Reagan
Post by Simon Clubley
You would keep f$parse for compatibility with existing DCL code and
it would continue to return individual strings, but you could also
have a (say) sys package with a differently named f$parse returning an
object containing all the parsed fields in one go.
You mean like SYS$FILESCAN? What's your issue with multiple calls to F$PARSE? The overhead? You are writing in DCL after all...
And you want the lexical to populate all the fields even if you aren't going to use them? Isn't that more expensive? Imagine the overhead of collecting ALL the GETJPI fields or ALL the GETQUI fields? Ugh.
That doesn't follow. One of the advantages of OO is that the
implementation is hidden.

There is no requirement to collect the values before they are used.

Some values may be collected when they are returned, some when the
object is created, some may even be collected before the object is created.

Hopefully, the implementation is written to do the "smart" thing.

And when problems are found, the implementation can be fixed without
breaking (hopefully) the higher level programs.
--
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360 Internet: ***@applied-synergy.com
Fax: 817-237-3074
John Reagan
2015-01-21 20:41:02 UTC
Permalink
Post by Chris Scheers
Post by John Reagan
Post by Simon Clubley
You would keep f$parse for compatibility with existing DCL code and
it would continue to return individual strings, but you could also
have a (say) sys package with a differently named f$parse returning an
object containing all the parsed fields in one go.
You mean like SYS$FILESCAN? What's your issue with multiple calls to F$PARSE? The overhead? You are writing in DCL after all...
And you want the lexical to populate all the fields even if you aren't going to use them? Isn't that more expensive? Imagine the overhead of collecting ALL the GETJPI fields or ALL the GETQUI fields? Ugh.
That doesn't follow. One of the advantages of OO is that the
implementation is hidden.
There is no requirement to collect the values before they are used.
Some values may be collected when they are returned, some when the
object is created, some may even be collected before the object is created.
Absolutely, that is why I objected (pardon the pun) to the use of the word
'object' in the original discussion. For the DCL extension, it felt more
like a structured return. Not smart at all. Quite different from the
Python/Perl examples provided later in the thread.

And I'm certainly not going to add real objects & methods to DCL. You'll
see object oriented COBOL before that. (and yes, the COBOL standard
did add object-oriented). And to be clear, you won't see OO COBOL either.
I wouldn't mind some things beyond COBOL85 but that isn't one. [I just spent
the last 1.5 years working on NonStop COBOL among other things.]
Simon Clubley
2015-01-21 21:25:38 UTC
Permalink
Post by John Reagan
Post by Chris Scheers
Post by John Reagan
Post by Simon Clubley
You would keep f$parse for compatibility with existing DCL code and
it would continue to return individual strings, but you could also
have a (say) sys package with a differently named f$parse returning an
object containing all the parsed fields in one go.
You mean like SYS$FILESCAN? What's your issue with multiple calls to F$PARSE? The overhead? You are writing in DCL after all...
And you want the lexical to populate all the fields even if you aren't going to use them? Isn't that more expensive? Imagine the overhead of collecting ALL the GETJPI fields or ALL the GETQUI fields? Ugh.
That doesn't follow. One of the advantages of OO is that the
implementation is hidden.
There is no requirement to collect the values before they are used.
Some values may be collected when they are returned, some when the
object is created, some may even be collected before the object is created.
Absolutely, that is why I objected (pardon the pun) to the use of the word
'object' in the original discussion. For the DCL extension, it felt more
like a structured return. Not smart at all. Quite different from the
Python/Perl examples provided later in the thread.
Actually, I do see them as actual objects and not just some aggregate
return. I also see the datatype of the object returned for a queue
itself as being distinct from the datatype returned for an entry (for
example).

Also, if you look at queues.py as posted by Jan-Erik, you will see that
most of the attributes of a queue (for example) are returned in one go.
I'm looking at the itemlist built in class Queue starting on line 57 and
the _getqui definition starting on line 321.
Post by John Reagan
And I'm certainly not going to add real objects & methods to DCL. You'll
see object oriented COBOL before that. (and yes, the COBOL standard
did add object-oriented). And to be clear, you won't see OO COBOL either.
I wouldn't mind some things beyond COBOL85 but that isn't one. [I just spent
the last 1.5 years working on NonStop COBOL among other things.]
Ok. :-) How about the DCL UI issues I raised ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Richard Maher
2015-01-21 22:16:56 UTC
Permalink
Post by John Reagan
[I just spent
the last 1.5 years working on NonStop COBOL among other things.]
VSI must've made it very worth your while to give up that gig!

Did you leave it inner-mode safe?
Jan-Erik Soderholm
2015-01-18 23:25:53 UTC
Permalink
I feel that DCL mostly does what I expect quite OK,
that is running the day to day opertion routines.

Now, there *is* a gap between DCL and compiled tools.
You will probably still write your "true" applications
in some compiled language, but there is still a place
for tools in between, for one-of-a-time "fix" jobs
and similar.

15 years ago some people installed Perl to fill that gap.
Today some uses Python partly becuse it feels more modern
and partly becuse there is a quite good Python port for VMS.

Python isn't perfect, of course. There is the V2 vs. V3
problem and some doesn't like the forced indentation,
mostly a habit and the code get "forced readability".

There are some ports of other tools like LUA for VMS,
but I do not think anything comes close to Python when
looking at built-in VMS integration.
David Froble
2015-01-19 01:46:10 UTC
Permalink
Post by Simon Clubley
I think it's time once again to build a list of DCL's flaws now that
VSI are around. Don't forget however that DCL is both a scripting
language and a UI. My initial list is below.
Do you mind if I'm an ass for a bit? I promise to be more reasonable at
the end.
Post by Simon Clubley
1) You can't edit commands across line boundaries. Even Windows CLIs
can do this.
It has been explained in the past that the problem was this stuff was
implemented in the terminal driver. I'd suggest looking at a different
implementation, such as an application that could do the command line
length and buffer and history, and maybe running multiple copies. Yes,
it is a PITA.
Post by Simon Clubley
2) You can't save your command history automatically, bash style, and
have it restored automatically at the next session.
See above for better implementation, not a patch on the terminal driver.
Post by Simon Clubley
With bash, you can have multiple shells active at the same time and
only the commands entered during a specific session will be added to
the history file when that session exits even though the shell has the
full command history from previous shells available (up to a user
defined limit).
I don't know why anyone would want 2 script processors at the same time.
Isn't that multiple sessions?

I also don't understand retaining the history.
Post by Simon Clubley
Any implementation needs to think about the multiple shells active at
the same time issue before proposing a solution to this.
3) No filename completion. This is _really_ annoying especially since
it even exists (after a fashion) in the command prompt on current
versions of Windows.
I still remember, with a grin, JF's idea of user name and password
completion.

:-)

:-)
Post by Simon Clubley
4) No elegant incremental search through the command history (bash
Ctrl-R style).
1) No structured programming constructs such as (for example) while
loops.
Learn the mantra,

"DCL is not a programming language".
"DCL is not a programming language".
"DCL is not a programming language".
"DCL is not a programming language".
Post by Simon Clubley
2) No ability to iterate cleanly over a list of items (bash "for i in"
style)
"DCL is not a programming language".
"DCL is not a programming language".
"DCL is not a programming language".

But, there is GOTO ...
Post by Simon Clubley
3) No ability to add site specific lexicals.
Write your own library routines, and call them from a reasonable
language, such as Basic.
Post by Simon Clubley
4) The output from the lexicals should be an immutable collection of
objects which you can then iterate over without having to worry about
the state changing during iteration.
"DCL is not a programming language".
"DCL is not a programming language".
Post by Simon Clubley
5) No regex support (this is also a UI issue).
"DCL is not a programming language".
"DCL is not a programming language".
Post by Simon Clubley
6) Pathetic limits on the maximum size of symbol contents.
"DCL is not a programming language".
"DCL is not a programming language".
Post by Simon Clubley
7) No array or collection of objects support. (In addition to normal
arrays, DCL should also support associative arrays.)
"DCL is not a programming language".
"DCL is not a programming language".
Post by Simon Clubley
DCL has absolutely no way to group related variables together in the
way you can with structs in C or objects in other languages.
"DCL is not a programming language".
"DCL is not a programming language".
Post by Simon Clubley
8) You cannot delete a directory tree in one go.
But, you can have a command procedure to do so ...
Post by Simon Clubley
9) differences is very limited by today's standards. The functionality
in GNU diff, with (for example) it's ability to find differences in
whole directory trees and produce patch files for the differences
in an entire tree, should be the minimum baseline for functionality
these days.
We know I don't get out much, but when I have something to compare, I
move it to VMS to use DIFF there. Guess I'm missing something.

But yeah, I jump through hoops when I want to compare a bunch of source
programs. I share that pain.
Post by Simon Clubley
I also find the unified diff output to be a _lot_ more readable than
the output from the DCL differences command.
Simon.
Ok, sorry, got carried away with the "paste" ...

:-)

DEC used to do this thing, they used to let people vote on desired
enhancements, and then choose projects based upon demand. This might be
a good practice to continue. Doing so on the internet, rather than a
couple times a year at DECUS.

Through all of what you wrote, there is this "feeling" that you are
writing from the perspective of a workstation, not a "server". Things
such the command line recall and length just don't come up when you're
running programs. As a software person, I can appreciate what you're
asking for. But from a production perspective, I don't see that it's
relavent.

Not saying you should not have all that you listed. But, I'd like you
to discuss them not from a development and / or management station, but
from a "running production" perspective.
JF Mezei
2015-01-19 03:31:43 UTC
Permalink
Post by David Froble
I also don't understand retaining the history.
I find it useful. Start a new session and you have command recall
available from previous session.
Post by David Froble
I still remember, with a grin, JF's idea of user name and password
completion.
Must be a good suggestion if you remember it ! :-)
Simon Clubley
2015-01-19 21:11:00 UTC
Permalink
Post by David Froble
Post by Simon Clubley
With bash, you can have multiple shells active at the same time and
only the commands entered during a specific session will be added to
the history file when that session exits even though the shell has the
full command history from previous shells available (up to a user
defined limit).
I don't know why anyone would want 2 script processors at the same time.
Isn't that multiple sessions?
Yes. Different terminal sessions running in multiple terminal windows at
the same time.
Post by David Froble
I also don't understand retaining the history.
It acts as a cache of your commonly used commands which are available
for immediate recall across multiple sessions.
Post by David Froble
Post by Simon Clubley
1) No structured programming constructs such as (for example) while
loops.
Learn the mantra,
"DCL is not a programming language".
Yes it is.

It's used to control the startup and operation of VMS.

It's used to control user created batch jobs and interactive command
procedures.

It doesn't matter that it's used in interpreted scripting environments
instead of compiled executables; it's still a programming language and
one which is very dated by today's standards.
Post by David Froble
Through all of what you wrote, there is this "feeling" that you are
writing from the perspective of a workstation, not a "server". Things
such the command line recall and length just don't come up when you're
running programs. As a software person, I can appreciate what you're
asking for. But from a production perspective, I don't see that it's
relavent.
Not saying you should not have all that you listed. But, I'd like you
to discuss them not from a development and / or management station, but
from a "running production" perspective.
These _are_ from a running production perspective (or don't you have
long or frequently used command lines as well as user written command
procedures in production use ?)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
David Froble
2015-01-20 03:42:46 UTC
Permalink
Post by Simon Clubley
Post by David Froble
Post by Simon Clubley
With bash, you can have multiple shells active at the same time and
only the commands entered during a specific session will be added to
the history file when that session exits even though the shell has the
full command history from previous shells available (up to a user
defined limit).
I don't know why anyone would want 2 script processors at the same time.
Isn't that multiple sessions?
Yes. Different terminal sessions running in multiple terminal windows at
the same time.
Post by David Froble
I also don't understand retaining the history.
It acts as a cache of your commonly used commands which are available
for immediate recall across multiple sessions.
I know what it does, I don't understand the need for the history.

Consider:

$ t login.com
$ login_vfy = F$VERIFY(0)
$
$ write SYS$OUTPUT "Performing [DFE]LOGIN.COM ...."
$
$ define /nolog GAMES DISK0:[DFE.GAMES]
$ define /nolog KER$COMM MODEM_PORT:
$ define /nolog TCPIP$FTP_NO_VERSION 1
$
$ cker*mit :== $SYS$SYSTEM:CKERMIT
$ delt :== delete /confirm /created /since=TODAY *.*;*
$ dial :== set host/dte MODEM_PORT:
$ em :== run GAMES:EMPIRE
$ lcp :== $SYS$SYSTEM:LATCP
$ ncp :== $SYS$SYSTEM:NCP
$ nsl :== $SYS$SYSTEM:TCPIP$NSLOOKUP
$ nslookup :== $SYS$SYSTEM:TCPIP$NSLOOKUP
$ print :== print/form=DFE
$ pv :== set process/priv=all
$ snn :== spawn/nowait/notify
$ syh :== show system /noprocess
$ sys :== @DISK0:[DFE]SYS.COM
$
$! SHUTDOWN == "@SYS$SYSTEM:SHUTDOWN 0 SHUTDOWN YES NO LATER NO NONE"
$ SHUTDOWN :== @SYS$SYSTEM:SHUTDOWN
$ REBOOT == "@SYS$SYSTEM:SHUTDOWN 0 SHUTDOWN YES YES LATER YES NONE"
$
$ @DISK1:[SOFTWARE]SRCLOGIN.COM
$
$ CANADA :== @DISK0:[DFE.GO]CANADA.COM
$ CLAY :== @DISK0:[DFE.GO]CLAY.COM
$ DFE :== @DISK0:[DFE.GO]DFE.COM
$ DFEUL :== @DISK0:[DFE.GO]DFEUL.COM
$ RENT :== @DISK0:[DFE.GO]RENT.COM
$ WRS :== @DISK0:[DFE.GO]WRS.COM
$
$! set prompt="DFE90A> "
$
$ login_vfy = F$VERIFY(login_vfy)


And there is more in the system SYLOGIN.COM
Post by Simon Clubley
Post by David Froble
Post by Simon Clubley
1) No structured programming constructs such as (for example) while
loops.
Learn the mantra,
"DCL is not a programming language".
Yes it is.
It's used to control the startup and operation of VMS.
^^^^^^^
Post by Simon Clubley
It's used to control user created batch jobs and interactive command
^^^^^^^
Post by Simon Clubley
procedures.
If the alignment is correct, you'll see that you even agree that it's a
"command language".
Post by Simon Clubley
It doesn't matter that it's used in interpreted scripting environments
instead of compiled executables; it's still a programming language and
one which is very dated by today's standards.
Dated, I'll give you, and could stand some improvements.
Post by Simon Clubley
Post by David Froble
Through all of what you wrote, there is this "feeling" that you are
writing from the perspective of a workstation, not a "server". Things
such the command line recall and length just don't come up when you're
running programs. As a software person, I can appreciate what you're
asking for. But from a production perspective, I don't see that it's
relavent.
Not saying you should not have all that you listed. But, I'd like you
to discuss them not from a development and / or management station, but
from a "running production" perspective.
These _are_ from a running production perspective (or don't you have
long or frequently used command lines as well as user written command
procedures in production use ?)
In general, no, we do not.

Yes, there is command files for backups and some other things. But we
do not solve problems in DCL.
Stephen Hoffman
2015-01-20 05:12:20 UTC
Permalink
Post by David Froble
Post by Simon Clubley
Post by David Froble
I also don't understand retaining the history.
It acts as a cache of your commonly used commands which are available
for immediate recall across multiple sessions.
I know what it does, I don't understand the need for the history.
Perform a RECALL/OUT=sys$login:history.log just before LOGOUT, and then
perform a RECALL/INPUT=sys$login:history.log when you next log in. You
now have your command recall buffer populated with what you did prior
to your LOGOUT. It's handy for various tasks, particularly given the
easy access to some command or group of commands you were working with
earlier.
Post by David Froble
If the alignment is correct, you'll see that you even agree that it's a
"command language".
DCL is a programming language, and it is used — like BASIC can be used
— to string commands together. DCL can also be used for general
programming tasks.
Post by David Froble
Yes, there is command files for backups and some other things. But we
do not solve problems in DCL.
Then you're unusual, in that regard. Yours would be the first site
I've encountered that didn't have a fair amount of DCL or other
scripting language around.
--
Pure Personal Opinion | HoffmanLabs LLC
JF Mezei
2015-01-20 05:25:11 UTC
Permalink
Post by Stephen Hoffman
Perform a RECALL/OUT=sys$login:history.log just before LOGOUT, and then
perform a RECALL/INPUT=sys$login:history.log when you next log in.
Not quite. History not saved when you don't actually logout (crashed,
close xterm window etc) and history not "live" shared between different
windows .
Bob Koehler
2015-01-21 16:37:24 UTC
Permalink
Post by JF Mezei
Post by Stephen Hoffman
Perform a RECALL/OUT=sys$login:history.log just before LOGOUT, and then
perform a RECALL/INPUT=sys$login:history.log when you next log in.
Not quite. History not saved when you don't actually logout (crashed,
close xterm window etc) and history not "live" shared between different
windows .
All of my shells on UNIX and Mac screw up the history when
logging from multiple processes at the same time. You have one
that doesn't?

It's more prevalent in VMS when using network file access, but on any
OS beware of history files containing access information that was typed
on command lines.
Simon Clubley
2015-01-21 17:58:04 UTC
Permalink
Post by Bob Koehler
Post by JF Mezei
Not quite. History not saved when you don't actually logout (crashed,
close xterm window etc) and history not "live" shared between different
windows .
All of my shells on UNIX and Mac screw up the history when
logging from multiple processes at the same time. You have one
that doesn't?
Bash on RHEL based systems I have used has always saved session history
from multiple sessions into one .bash_history file without each session
clobbering the other session history (subject to the requested maximum
amount of history to keep).

I've seen people complain about the above clobbering so it must happen,
but I have never seen this.
Post by Bob Koehler
It's more prevalent in VMS when using network file access, but on any
OS beware of history files containing access information that was typed
on command lines.
Which is why for bash you can (and I do) unset HISTFILE when doing that.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
abrsvc
2015-01-21 18:12:23 UTC
Permalink
Having worked on code that was a replacement for DCL, I would vote for an add-on environment that could be "called" from a shell DCL procedure. I agree with Hoff in that the file extention should be different as well. Whether C64 (for 64bit DCL) or CMD for a "command" file is a good fit can be debated. The bottom line here is that the process context and environment created by process creation with teh DCL cli should remain. It should be easier that way. Why recreate the wheel as far as process context is concerned.

Thoughts?
Jan-Erik Soderholm
2015-01-21 18:23:44 UTC
Permalink
Post by abrsvc
Having worked on code that was a replacement for DCL, I would vote for
an add-on environment that could be "called" from a shell DCL procedure.
I agree with Hoff in that the file extention should be different as
well. Whether C64 (for 64bit DCL) or CMD for a "command" file is a good
fit can be debated. The bottom line here is that the process context
and environment created by process creation with teh DCL cli should
remain. It should be easier that way. Why recreate the wheel as far as
process context is concerned.
Thoughts?
Agree.
Let the process start up in DCL and let the programmer or
system manager, decide if and when to call an additional
tool to complement DCL.

I do not see any reason to change the COM file name just
becuse some of them are calling some other tool.

In fact, I always run all my Python scripts from a small
DCL file, that way it is easy to add setup for some
specific logicals or whatever before calling Python.

------------------------------------------
$! My little demo COM file running Python
$!
$ python
from VMS import queues
import <some other modules...>

do whatever needed in Python...

quit
$!
$ exit
------------------------------------------

Easy and from the "outside" still looks just as
any other COM file on the system.

Jan-Erik.
Bob Gezelter
2015-01-21 19:36:31 UTC
Permalink
Post by abrsvc
Having worked on code that was a replacement for DCL, I would vote for an add-on environment that could be "called" from a shell DCL procedure. I agree with Hoff in that the file extention should be different as well. Whether C64 (for 64bit DCL) or CMD for a "command" file is a good fit can be debated. The bottom line here is that the process context and environment created by process creation with teh DCL cli should remain. It should be easier that way. Why recreate the wheel as far as process context is concerned.
Thoughts?
abrsrv,

.CMD is already allocated (to RSX-11 MCR).

- Bob Gezelter, http://www.rlgsc.com
abrsvc
2015-01-21 19:42:23 UTC
Permalink
Post by Bob Gezelter
abrsrv,
.CMD is already allocated (to RSX-11 MCR).
- Bob Gezelter, http://www.rlgsc.com
Yep, knew that. Just threw out an example. The bottom line is that I agree that there should be a way to differentiate between the command files.

A further thought: Using the different file extentions could be a triger too without requiring a special invokation of the "new" command language no? Update DCL to process files with the new extention by passing them to the new CLI?
j***@yahoo.co.uk
2015-01-21 21:08:12 UTC
Permalink
Post by Simon Clubley
Post by Bob Koehler
Post by JF Mezei
Not quite. History not saved when you don't actually logout (crashed,
close xterm window etc) and history not "live" shared between different
windows .
All of my shells on UNIX and Mac screw up the history when
logging from multiple processes at the same time. You have one
that doesn't?
Bash on RHEL based systems I have used has always saved session history
from multiple sessions into one .bash_history file without each session
clobbering the other session history (subject to the requested maximum
amount of history to keep).
I've seen people complain about the above clobbering so it must happen,
but I have never seen this.
Post by Bob Koehler
It's more prevalent in VMS when using network file access, but on any
OS beware of history files containing access information that was typed
on command lines.
Which is why for bash you can (and I do) unset HISTFILE when doing that.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
There's a shared-shell-history vs separate-shell-history thing for bash
in multiple sessions. It's per-user configurable. Does that add anything
here?

Can I remember how? No. Can I think of a suitable web query that will
find the answers rather than the unanswered question? No, not quickly
anyway. Am I convinced that I used to do it on either RedHat/FC or
(Open)Suse, in the last few years? Absolutely.

Have a lot of fun.
Stephen Hoffman
2015-01-20 00:04:24 UTC
Permalink
Post by David Froble
Post by Simon Clubley
I think it's time once again to build a list of DCL's flaws now that
VSI are around. Don't forget however that DCL is both a scripting
language and a UI. My initial list is below.
Do you mind if I'm an ass for a bit? I promise to be more reasonable
at the end.
Post by Simon Clubley
1) You can't edit commands across line boundaries. Even Windows CLIs
can do this.
It has been explained in the past that the problem was this stuff was
implemented in the terminal driver. I'd suggest looking at a different
implementation, such as an application that could do the command line
length and buffer and history, and maybe running multiple copies. Yes,
it is a PITA.
Ayup. The terminal driver, another hunk of legacy VMS code. Code
that's accumulated more than a little technical debt, and which is
inherently a very complex piece of code. Code that's best either
overhauled or even re-architected and reworked into a newer and simpler
design, but this would break compatibility for the applications that
(still?) need the more arcane features of the classic terminal driver.

Serial port controllers themselves are legacy designs, beyond (maybe)
the console, and that's often replaced with a management processor.

There is a cost to providing compatibility.
Post by David Froble
Post by Simon Clubley
2) You can't save your command history automatically, bash style, and
have it restored automatically at the next session.
See above for better implementation, not a patch on the terminal driver.
DCL does most of the command processing already, it's the current
command line processing where DCL depends on the features of the
terminal driver, and the driver itself can't manage the long-line wrap.
DCL either reads out or loads in command lines, using the terminal
driver.
Post by David Froble
Post by Simon Clubley
With bash, you can have multiple shells active at the same time and
only the commands entered during a specific session will be added to
the history file when that session exits even though the shell has the
full command history from previous shells available (up to a user
defined limit).
I don't know why anyone would want 2 script processors at the same
time. Isn't that multiple sessions?
I also don't understand retaining the history.
History means your commands are available over separate logins, and
over server reboots. It's really handy to have. You're not copying
and pasting commands into files or into notebooks, for when you get
back to work the next day. It's increasingly common to hack this
feature into VMS with RECALL commands, but that's rather clunky.
Post by David Froble
Post by Simon Clubley
Any implementation needs to think about the multiple shells active at
the same time issue before proposing a solution to this.
3) No filename completion. This is _really_ annoying especially since
it even exists (after a fashion) in the command prompt on current
versions of Windows.
Filename and full-on command completion would be handy to have.
Post by David Froble
I still remember, with a grin, JF's idea of user name and password completion.
:-)
:-)
Yes, a joke. But there are parts of the login that are pretty crufty.

Certificate-based logins would be handy. Not quite the same as
password completion, but something that's used very heavily with
ssh-based logins. Other systems use biometric readers (problems and
all) or two-factor with tokens or out-of-band authentication.
Post by David Froble
Post by Simon Clubley
4) No elegant incremental search through the command history (bash
Ctrl-R style).
1) No structured programming constructs such as (for example) while
loops.
Learn the mantra,
"DCL is not a programming language".
"DCL is not a programming language".
"DCL is not a programming languaige".
"DCL is not a programming language".
Is that like "we've always done it this way" or "nobody needs more than
640K"? DCL is a programming language. It's just an old and clunky
one, and part of dusting off VMS means updates.
Post by David Froble
Post by Simon Clubley
2) No ability to iterate cleanly over a list of items (bash "for i in"
style)
"DCL is not a programming language".
"DCL is not a programming language".
"DCL is not a programming language".
An iterator would be very handy. Cleaner code.
Post by David Froble
But, there is GOTO ...
Computed goto, if you're willing to hack the symbols. Hard to
troubleshoot, though. Or patching your code on the fly, if you're
willing to substitute a GOTO for some other command.
Post by David Froble
Post by Simon Clubley
3) No ability to add site specific lexicals.
Write your own library routines, and call them from a reasonable
language, such as Basic.
Why not from the command language?
Post by David Froble
Post by Simon Clubley
4) The output from the lexicals should be an immutable collection of
objects which you can then iterate over without having to worry about
the state changing during iteration.
"DCL is not a programming language".
"DCL is not a programming language".
That's variously referred to as an iterator, and that would be handy.
More than a few DCL procedures around are iterating over a pattern
match of records within a file, or within a list of files, after all.
(This is also where having a JIT would be handy too, as these sorts of
loops can be automatically detected and internally compiled within DCL,
and the performance of the DCL procedure would hopefully then improve,
and this with minimal or no effort on the part of the DCL programmer.
The JIT hopefully improves some parts of the DCL procedure performance
"for free", as far as the DCL programmer can see. Now figuring out how
and then retrofitting a JIT into DCL itself, that won't be easy. That
the DCL commands can change at run-time based on a symbol substitution
somewhere else can make something like a JIT slightly more interesting.)
Post by David Froble
Post by Simon Clubley
5) No regex support (this is also a UI issue).
"DCL is not a programming language".
"DCL is not a programming language".
DCL does shedloads of pattern-matching — badly — so having regular
expressions would be useful. The wildcards % and * only get you so
far, and pretty soon you're rolling your own substring matching — this
once you're past the stage where you're looking for an FTP tool with
in-built scripting or pattern-matching logic, and have decided to write
some DCL to provide for the application requirements. (If you're not
re-designing your way out of using FTP, of course.)
Post by David Froble
Post by Simon Clubley
6) Pathetic limits on the maximum size of symbol contents.
"DCL is not a programming language".
"DCL is not a programming language".
Yeah, and the lack of binary data support here, too. This also ties
into having objects, where I can deal with a blob of data without
having to specifically manage the blob.

Adding UTF-8 can get ugly if you don't go "all in" on UTF-8 throughout,
as you're then having to identify the data encoding in the strings and
file records explicitly, or trying to detect it manually. UTF-8 also
means that character string lengths aren't the same as the number of
bytes in the string, too.
Post by David Froble
Post by Simon Clubley
7) No array or collection of objects support. (In addition to normal
arrays, DCL should also support associative arrays.)
"DCL is not a programming language".
"DCL is not a programming language".
Yeah; arrays in DCL using symbol substitution is ugly. Dictionaries —
arrays that work something like indexed files, also called key-value
stores, and probably what you're referring to with associative arrays —
would be handy, too. More than a little DCL code around ends up
either hacking in arrays, or using an RMS indexed (dictionary) or
relative (array) file, or ending up having to create and then connect
with some compiled code.
Post by David Froble
Post by Simon Clubley
DCL has absolutely no way to group related variables together in the
way you can with structs in C or objects in other languages.
"DCL is not a programming language".
"DCL is not a programming language".
Scopes are sort-of kind-of related to symbol visibility, but they're
rather murky. Having something akin to a structure or an object would
be useful.
Post by David Froble
Post by Simon Clubley
8) You cannot delete a directory tree in one go.
But, you can have a command procedure to do so ...
As others have commented, with V8.4, you can add a qualifier to get there.
Post by David Froble
Post by Simon Clubley
9) differences is very limited by today's standards. The functionality
in GNU diff, with (for example) it's ability to find differences in
whole directory trees and produce patch files for the differences
in an entire tree, should be the minimum baseline for functionality
these days.
We know I don't get out much, but when I have something to compare, I
move it to VMS to use DIFF there. Guess I'm missing something.
There are other interesting and useful and different tools around; part
of what learning another system can help with, even if you're (staying)
on VMS.
Post by David Froble
But yeah, I jump through hoops when I want to compare a bunch of source
programs. I share that pain.
A good IDE can help here, too.

For folks on OS X and going beyond the various BSD and GNU tools that
are available, the differences support in Xcode can be handy, as can
the third-party Kaleidoscope.app differences application.
Post by David Froble
Post by Simon Clubley
I also find the unified diff output to be a _lot_ more readable than
the output from the DCL differences command.
Simon.
Ok, sorry, got carried away with the "paste" ...
:-)
DEC used to do this thing, they used to let people vote on desired
enhancements, and then choose projects based upon demand. This might
be a good practice to continue. Doing so on the internet, rather than
a couple times a year at DECUS.
I'm actually somewhat skeptical on that, particularly if you've got
something new or very different in mind. Voting does work, but tends
to get incremental improvements. Having done more than a few customer
surveys and related, it's unusual to get significant new features
through this path. Now for incremental changes such as getting zip and
unzip into the base distro, that got voted on and unfortunately never
happened.
Post by David Froble
Through all of what you wrote, there is this "feeling" that you are
writing from the perspective of a workstation, not a "server". Things
such the command line recall and length just don't come up when you're
running programs. As a software person, I can appreciate what you're
asking for. But from a production perspective, I don't see that it's
relavent.
Much of what Simon is suggesting is directly or indirectly associated
with application development on VMS, and with using tools such as
scripting language improvements that allows more complex and more
maintainable applications to be put together more quickly and easily.
That's dead-on deep into server application territory, too.
Post by David Froble
Not saying you should not have all that you listed. But, I'd like you
to discuss them not from a development and / or management station, but
from a "running production" perspective.
History is about the only one that isn't directly production-execution
related, and keeping track of command history is something increasingly
common in production environments.

All its warts aside, DCL is a programming language, and folks can and
do write real programs in it. But DCL can be improved. Or DCL can be
replaced with something more tightly specified. Why? For a number
of tasks, applications written in scripting languages are generally
faster to develop and to deploy than are applications written in
compiled languages. But then DCL doesn't interface with compiled
languages all that well — how many of us are tossing around
lib$set_logical and lib$set_symbol and related code and not something
like "$ program_result = compiled_program_invocation(arg1, arg2)"
syntax — so going full-on compiled for an application is still pretty
common. That's before discussing the various issues with the compilers
and of the development environments, too.

Or turning around that whole "DCL is not a programming language" that
you're used here, ask yourself why that is, what the issues and
limitations of DCL are here, and whether those can be addressed in DCL
or in a hypothetical replacement. Look less at what can't be done, and
more at what can and should be.

Now as for what VSI plans here, we'll find out. They've more than a
little work ahead of them, and they're going to want to reach
sustainable revenues.
--
Pure Personal Opinion | HoffmanLabs LLC
David Froble
2015-01-20 04:49:16 UTC
Permalink
Post by Stephen Hoffman
Post by David Froble
Post by Simon Clubley
I think it's time once again to build a list of DCL's flaws now that
VSI are around. Don't forget however that DCL is both a scripting
language and a UI. My initial list is below.
Do you mind if I'm an ass for a bit? I promise to be more reasonable
at the end.
Post by Simon Clubley
1) You can't edit commands across line boundaries. Even Windows CLIs
can do this.
It has been explained in the past that the problem was this stuff was
implemented in the terminal driver. I'd suggest looking at a
different implementation, such as an application that could do the
command line length and buffer and history, and maybe running multiple
copies. Yes, it is a PITA.
Ayup. The terminal driver, another hunk of legacy VMS code. Code
that's accumulated more than a little technical debt, and which is
inherently a very complex piece of code. Code that's best either
overhauled or even re-architected and reworked into a newer and simpler
design, but this would break compatibility for the applications that
(still?) need the more arcane features of the classic terminal driver.
Serial port controllers themselves are legacy designs, beyond (maybe)
the console, and that's often replaced with a management processor.
There is a cost to providing compatibility.
I don't know the internals. Does TelNet and such use the terminal
driver? Is this one of the pieces of "cruft code" that you' like to see
go away or be replaced?

There probably is some people using serial lines somewhere. But from
what I see, serial lines are a thing of the past.

There is probably someone somewhere running applications on the console.
Post by Stephen Hoffman
Post by David Froble
Post by Simon Clubley
2) You can't save your command history automatically, bash style, and
have it restored automatically at the next session.
See above for better implementation, not a patch on the terminal driver.
DCL does most of the command processing already, it's the current
command line processing where DCL depends on the features of the
terminal driver, and the driver itself can't manage the long-line wrap.
DCL either reads out or loads in command lines, using the terminal driver.
It sounds as if possibly DCL would be the place to implement long lines
and such. But, I know nothing ...
Post by Stephen Hoffman
Post by David Froble
Post by Simon Clubley
With bash, you can have multiple shells active at the same time and
only the commands entered during a specific session will be added to
the history file when that session exits even though the shell has the
full command history from previous shells available (up to a user
defined limit).
I don't know why anyone would want 2 script processors at the same
time. Isn't that multiple sessions?
I also don't understand retaining the history.
History means your commands are available over separate logins, and over
server reboots. It's really handy to have. You're not copying and
pasting commands into files or into notebooks, for when you get back to
work the next day. It's increasingly common to hack this feature into
VMS with RECALL commands, but that's rather clunky.
I know what the history does. I just don't see it being a major
stumbling point.
Post by Stephen Hoffman
Post by David Froble
Post by Simon Clubley
Any implementation needs to think about the multiple shells active at
the same time issue before proposing a solution to this.
3) No filename completion. This is _really_ annoying especially since
it even exists (after a fashion) in the command prompt on current
versions of Windows.
Filename and full-on command completion would be handy to have.
Post by David Froble
I still remember, with a grin, JF's idea of user name and password completion.
:-)
:-)
Yes, a joke. But there are parts of the login that are pretty crufty.
I'm not so sure it was a joke when he wrote it.
Post by Stephen Hoffman
Certificate-based logins would be handy.
Yes. This would be a good security enhancement.
Post by Stephen Hoffman
Not quite the same as password
completion, but something that's used very heavily with ssh-based
logins. Other systems use biometric readers (problems and all) or
two-factor with tokens or out-of-band authentication.
Post by David Froble
Post by Simon Clubley
4) No elegant incremental search through the command history (bash
Ctrl-R style).
1) No structured programming constructs such as (for example) while
loops.
Learn the mantra,
"DCL is not a programming language".
"DCL is not a programming language".
"DCL is not a programming languaige".
"DCL is not a programming language".
Is that like "we've always done it this way" or "nobody needs more than
640K"?
No. It's "there are better existing methods".
Post by Stephen Hoffman
DCL is a programming language. It's just an old and clunky one,
and part of dusting off VMS means updates.
Post by David Froble
Post by Simon Clubley
2) No ability to iterate cleanly over a list of items (bash "for i in"
style)
"DCL is not a programming language".
"DCL is not a programming language".
"DCL is not a programming language".
An iterator would be very handy. Cleaner code.
Post by David Froble
But, there is GOTO ...
Computed goto, if you're willing to hack the symbols. Hard to
troubleshoot, though. Or patching your code on the fly, if you're
willing to substitute a GOTO for some other command.
Post by David Froble
Post by Simon Clubley
3) No ability to add site specific lexicals.
Write your own library routines, and call them from a reasonable
language, such as Basic.
Why not from the command language?
Well, if you let DCL call user written routines, that would solve
multiple issues, right?
Post by Stephen Hoffman
Post by David Froble
Post by Simon Clubley
4) The output from the lexicals should be an immutable collection of
objects which you can then iterate over without having to worry about
the state changing during iteration.
"DCL is not a programming language".
"DCL is not a programming language".
That's variously referred to as an iterator, and that would be handy.
More than a few DCL procedures around are iterating over a pattern match
of records within a file, or within a list of files, after all. (This
is also where having a JIT would be handy too, as these sorts of loops
can be automatically detected and internally compiled within DCL, and
the performance of the DCL procedure would hopefully then improve, and
this with minimal or no effort on the part of the DCL programmer. The
JIT hopefully improves some parts of the DCL procedure performance "for
free", as far as the DCL programmer can see. Now figuring out how and
then retrofitting a JIT into DCL itself, that won't be easy. That the
DCL commands can change at run-time based on a symbol substitution
somewhere else can make something like a JIT slightly more interesting.)
Post by David Froble
Post by Simon Clubley
5) No regex support (this is also a UI issue).
"DCL is not a programming language".
"DCL is not a programming language".
DCL does shedloads of pattern-matching — badly — so having regular
expressions would be useful. The wildcards % and * only get you so
far, and pretty soon you're rolling your own substring matching — this
once you're past the stage where you're looking for an FTP tool with
in-built scripting or pattern-matching logic, and have decided to write
some DCL to provide for the application requirements. (If you're not
re-designing your way out of using FTP, of course.)
Post by David Froble
Post by Simon Clubley
6) Pathetic limits on the maximum size of symbol contents.
"DCL is not a programming language".
"DCL is not a programming language".
Yeah, and the lack of binary data support here, too. This also ties
into having objects, where I can deal with a blob of data without having
to specifically manage the blob.
Adding UTF-8 can get ugly if you don't go "all in" on UTF-8 throughout,
as you're then having to identify the data encoding in the strings and
file records explicitly, or trying to detect it manually. UTF-8 also
means that character string lengths aren't the same as the number of
bytes in the string, too.
Your argument on UTF-8 was justified long ago. I'm willing to bet my
"betting dollar", my new one, Bob has dibs on my old one, that VSI will
agree.
Post by Stephen Hoffman
Post by David Froble
Post by Simon Clubley
7) No array or collection of objects support. (In addition to normal
arrays, DCL should also support associative arrays.)
"DCL is not a programming language".
"DCL is not a programming language".
Yeah; arrays in DCL using symbol substitution is ugly. Dictionaries —
arrays that work something like indexed files, also called key-value
stores, and probably what you're referring to with associative arrays —
would be handy, too. More than a little DCL code around ends up either
hacking in arrays, or using an RMS indexed (dictionary) or relative
(array) file, or ending up having to create and then connect with some
compiled code.
Post by David Froble
Post by Simon Clubley
DCL has absolutely no way to group related variables together in the
way you can with structs in C or objects in other languages.
"DCL is not a programming language".
"DCL is not a programming language".
Scopes are sort-of kind-of related to symbol visibility, but they're
rather murky. Having something akin to a structure or an object would
be useful.
Post by David Froble
Post by Simon Clubley
8) You cannot delete a directory tree in one go.
But, you can have a command procedure to do so ...
As others have commented, with V8.4, you can add a qualifier to get there.
Post by David Froble
Post by Simon Clubley
9) differences is very limited by today's standards. The functionality
in GNU diff, with (for example) it's ability to find differences in
whole directory trees and produce patch files for the differences
in an entire tree, should be the minimum baseline for functionality
these days.
We know I don't get out much, but when I have something to compare, I
move it to VMS to use DIFF there. Guess I'm missing something.
There are other interesting and useful and different tools around; part
of what learning another system can help with, even if you're (staying)
on VMS.
Post by David Froble
But yeah, I jump through hoops when I want to compare a bunch of
source programs. I share that pain.
A good IDE can help here, too.
For folks on OS X and going beyond the various BSD and GNU tools that
are available, the differences support in Xcode can be handy, as can the
third-party Kaleidoscope.app differences application.
Post by David Froble
Post by Simon Clubley
I also find the unified diff output to be a _lot_ more readable than
the output from the DCL differences command.
Simon.
Ok, sorry, got carried away with the "paste" ...
:-)
DEC used to do this thing, they used to let people vote on desired
enhancements, and then choose projects based upon demand. This might
be a good practice to continue. Doing so on the internet, rather than
a couple times a year at DECUS.
I'm actually somewhat skeptical on that, particularly if you've got
something new or very different in mind. Voting does work, but tends to
get incremental improvements. Having done more than a few customer
surveys and related, it's unusual to get significant new features
through this path. Now for incremental changes such as getting zip and
unzip into the base distro, that got voted on and unfortunately never
happened.
When customers have inadequate "vision", there is the software engineers
to correct the vision, right?

As for ZIP, you're thinking about the HP years. Why are you surprised?
Post by Stephen Hoffman
Post by David Froble
Through all of what you wrote, there is this "feeling" that you are
writing from the perspective of a workstation, not a "server". Things
such the command line recall and length just don't come up when you're
running programs. As a software person, I can appreciate what you're
asking for. But from a production perspective, I don't see that it's
relavent.
Much of what Simon is suggesting is directly or indirectly associated
with application development on VMS, and with using tools such as
scripting language improvements that allows more complex and more
maintainable applications to be put together more quickly and easily.
That's dead-on deep into server application territory, too.
There are some who recognized the need long ago, and developed their own
tools. I realize this method isn't much help for the user community as
a whole. I'm so deep into my own methods that I'd probably not be as
good with any new tools, and, maybe that's why I have some problems
seeing the need for any new tools.
Post by Stephen Hoffman
Post by David Froble
Not saying you should not have all that you listed. But, I'd like you
to discuss them not from a development and / or management station,
but from a "running production" perspective.
History is about the only one that isn't directly production-execution
related, and keeping track of command history is something increasingly
common in production environments.
As our users never see a "$" prompt, I don't see how such would help them.
Post by Stephen Hoffman
All its warts aside, DCL is a programming language, and folks can and do
write real programs in it. But DCL can be improved. Or DCL can be
replaced with something more tightly specified. Why? For a number of
tasks, applications written in scripting languages are generally faster
to develop and to deploy than are applications written in compiled
languages. But then DCL doesn't interface with compiled languages all
that well
— how many of us are tossing around lib$set_logical and
lib$set_symbol and related code
Guilty as charged ...

:-)

But, once written, it does work ...
Post by Stephen Hoffman
and not something like "$ program_result
= compiled_program_invocation(arg1, arg2)" syntax — so going full-on
compiled for an application is still pretty common. That's before
discussing the various issues with the compilers and of the development
environments, too.
Or turning around that whole "DCL is not a programming language" that
you're used here, ask yourself why that is, what the issues and
limitations of DCL are here, and whether those can be addressed in DCL
or in a hypothetical replacement. Look less at what can't be done, and
more at what can and should be.
Or, possibly, look at what is now being done ...
Post by Stephen Hoffman
Now as for what VSI plans here, we'll find out. They've more than a
little work ahead of them, and they're going to want to reach
sustainable revenues.
Craig A. Berry
2015-01-19 03:30:11 UTC
Permalink
Post by Simon Clubley
8) You cannot delete a directory tree in one go.
DELETE/TREE was added in 8.4 but DFU DELETE/TREE is much better and has
been available for some time. Unfortunately the latter requires
privileges over and above ownership of the directory tree involved.
Post by Simon Clubley
9) differences is very limited by today's standards. The functionality
in GNU diff, with (for example) it's ability to find differences in
whole directory trees and produce patch files for the differences
in an entire tree, should be the minimum baseline for functionality
these days.
I also find the unified diff output to be a _lot_ more readable than
the output from the DCL differences command.
Agreed. That's why I've been using GNU diff on VMS quite a lot for the
last fifteen years or so.
JF Mezei
2015-01-19 03:39:06 UTC
Permalink
Post by Simon Clubley
8) You cannot delete a directory tree in one go.
I am not too concerned about these problems because they can easily be
solved with relatively minor updates to the commands themselves (and as
was pointed out delete/tree was added).

Consider 8.3 when Guy Peleg managed to add a lot of neat features to
DCL, Backup and others stuff.

The big question what what needs to change at the lower "core" level, of
any.

Shoudl DCL continue to be updated and fast forward to 21st century, or
should it be frozen and something new brought in ? I think Hoff has
asked those questions fairly elegantly.
Matthew H McKenzie
2015-01-19 07:29:49 UTC
Permalink
He has,

I think a port of python would probably go a long way towards resolving
these.
- abstracting too, the system calls in wrappers.
- leaving DCL mostly as it is, preserving snippet value.
- reducing the need for C and COBOL code as well.
Post by JF Mezei
Post by Simon Clubley
8) You cannot delete a directory tree in one go.
I am not too concerned about these problems because they can easily be
solved with relatively minor updates to the commands themselves (and as
was pointed out delete/tree was added).
Consider 8.3 when Guy Peleg managed to add a lot of neat features to
DCL, Backup and others stuff.
The big question what what needs to change at the lower "core" level, of
any.
Shoudl DCL continue to be updated and fast forward to 21st century, or
should it be frozen and something new brought in ? I think Hoff has
asked those questions fairly elegantly.
Jan-Erik Soderholm
2015-01-19 12:49:25 UTC
Permalink
Post by Matthew H McKenzie
He has,
I think a port of python would probably go a long way towards resolving
these.
Available today.
http://www.vmspython.org/doku.php
Post by Matthew H McKenzie
- abstracting too, the system calls in wrappers.
Available today (if you are still talkning about Python).

Here is what the interface to SYSQUI looks like.
This lists all queues, all jobs in the queues
and the filename of all files in those jobs:

------------------------------------------------
from vms import queues
for q in queues.all_queues():
print "Queue: ", q.queue_name
for j in q.jobs():
print " Job: ", j.job_name
for f in j.files:
print " Name: ", f.specification
------------------------------------------------

Thats all.

You can of course get all other information and
also "do" things like deleting jobs.
Post by Matthew H McKenzie
- leaving DCL mostly as it is, preserving snippet value.
Yes, DCL does what it does quite OK today...


Jan-Erik.
Craig A. Berry
2015-01-20 01:25:33 UTC
Permalink
Post by Jan-Erik Soderholm
Post by Matthew H McKenzie
He has,
I think a port of python would probably go a long way towards resolving
these.
Available today.
http://www.vmspython.org/doku.php
Post by Matthew H McKenzie
- abstracting too, the system calls in wrappers.
Available today (if you are still talkning about Python).
Here is what the interface to SYSQUI looks like.
This lists all queues, all jobs in the queues
------------------------------------------------
from vms import queues
print "Queue: ", q.queue_name
print " Job: ", j.job_name
print " Name: ", f.specification
------------------------------------------------
Thats all.
You can of course get all other information and
also "do" things like deleting jobs.
And you can do all of that in Perl as well with the VMS::Queue module,
which has been around for 17 years now. Here's something similar to the
above Python example:

use VMS::Queue;

for my $j (VMS::Queue::entry_list()) {
my $jinfo = VMS::Queue::entry_info($j);
print "Queue: $$jinfo{QUEUE_NAME} Job: $$jinfo{JOB_NAME}\n";
for my $f (VMS::Queue::file_list($j)) {
print " File: $$f{FILE_SPECIFICATION}\n";
}
}

It can also decode bitmaps for you, which F$GETQUI can't do.
David Froble
2015-01-20 04:50:58 UTC
Permalink
Post by Craig A. Berry
Post by Jan-Erik Soderholm
Post by Matthew H McKenzie
He has,
I think a port of python would probably go a long way towards resolving
these.
Available today.
http://www.vmspython.org/doku.php
Post by Matthew H McKenzie
- abstracting too, the system calls in wrappers.
Available today (if you are still talkning about Python).
Here is what the interface to SYSQUI looks like.
This lists all queues, all jobs in the queues
------------------------------------------------
from vms import queues
print "Queue: ", q.queue_name
print " Job: ", j.job_name
print " Name: ", f.specification
------------------------------------------------
Thats all.
You can of course get all other information and
also "do" things like deleting jobs.
And you can do all of that in Perl as well with the VMS::Queue module,
which has been around for 17 years now. Here's something similar to the
use VMS::Queue;
for my $j (VMS::Queue::entry_list()) {
my $jinfo = VMS::Queue::entry_info($j);
print "Queue: $$jinfo{QUEUE_NAME} Job: $$jinfo{JOB_NAME}\n";
for my $f (VMS::Queue::file_list($j)) {
print " File: $$f{FILE_SPECIFICATION}\n";
}
}
It can also decode bitmaps for you, which F$GETQUI can't do.
But, that "$j" is just SO alien looking ...

Sorry, old dog ...

:-)
Jan-Erik Soderholm
2015-01-20 12:39:03 UTC
Permalink
Post by Craig A. Berry
Post by Jan-Erik Soderholm
Post by Matthew H McKenzie
He has,
I think a port of python would probably go a long way towards resolving
these.
Available today.
http://www.vmspython.org/doku.php
Post by Matthew H McKenzie
- abstracting too, the system calls in wrappers.
Available today (if you are still talkning about Python).
Here is what the interface to SYSQUI looks like.
This lists all queues, all jobs in the queues
------------------------------------------------
from vms import queues
print "Queue: ", q.queue_name
print " Job: ", j.job_name
print " Name: ", f.specification
------------------------------------------------
Thats all.
You can of course get all other information and
also "do" things like deleting jobs.
And you can do all of that in Perl as well with the VMS::Queue module,
which has been around for 17 years now. Here's something similar to the
use VMS::Queue;
for my $j (VMS::Queue::entry_list()) {
my $jinfo = VMS::Queue::entry_info($j);
print "Queue: $$jinfo{QUEUE_NAME} Job: $$jinfo{JOB_NAME}\n";
for my $f (VMS::Queue::file_list($j)) {
print " File: $$f{FILE_SPECIFICATION}\n";
}
}
It can also decode bitmaps for you, which F$GETQUI can't do.
Of course! :-)
I never said it could not be done in Perl. :-)
Maybe it is just me, but I prefer the Python syntax.
More clear and readable, IMHO...

The main point is that to do the same in DCL, you will
need a few more lines then aprox 6-7.

Jan-Erik.
c***@gmail.com
2015-01-19 14:10:55 UTC
Permalink
Post by Craig A. Berry
Post by Simon Clubley
I also find the unified diff output to be a _lot_ more readable than
the output from the DCL differences command.
Agreed. That's why I've been using GNU diff on VMS quite a lot for the
last fifteen years or so.
We've never found any other OS' differencing engine with as usable output as VMS'.
There was a discussion about this a while back in c.o.v, and how the approach
taken by the VMS engine differs from that used by gnu.

But we've taken to using third party products on Windows and Mac, and they do a
nice job with a nice GUI interface. Right now BeyondCompare (Windows or Mac) is
one we really like and any future VMS work on differencing should look at features
in tools such as that. Lot of our Windowsonly users are using CodeDiff, but it writes
HTML with \ in the URLs.
Simon Clubley
2015-01-19 19:50:01 UTC
Permalink
Post by Craig A. Berry
Post by Simon Clubley
8) You cannot delete a directory tree in one go.
DELETE/TREE was added in 8.4 but DFU DELETE/TREE is much better and has
been available for some time. Unfortunately the latter requires
privileges over and above ownership of the directory tree involved.
Interesting; I didn't know that. :-)

I have not used 8.4 yet (and I am not likely to in the near future as
my current job ends in a couple of months) so I have not had the
opportunity to be exposed to this new qualifier.
Post by Craig A. Berry
Post by Simon Clubley
9) differences is very limited by today's standards. The functionality
in GNU diff, with (for example) it's ability to find differences in
whole directory trees and produce patch files for the differences
in an entire tree, should be the minimum baseline for functionality
these days.
I also find the unified diff output to be a _lot_ more readable than
the output from the DCL differences command.
Agreed. That's why I've been using GNU diff on VMS quite a lot for the
last fifteen years or so.
I've used GNU diff on VMS as well and it's capabilities could well do
with being added into the VMS native differences program IMHO.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Phillip Helbig (undress to reply)
2015-01-19 21:32:16 UTC
Permalink
Post by Simon Clubley
I think it's time once again to build a list of DCL's flaws now that
VSI are around. Don't forget however that DCL is both a scripting
language and a UI. My initial list is below.
1) You can't edit commands across line boundaries. Even Windows CLIs
can do this.
This isn't really a DCL issue, though, is it?
Post by Simon Clubley
8) You cannot delete a directory tree in one go.
Yes you can. What version of VMS do you have? Try HELP.
Simon Clubley
2015-01-19 22:16:19 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Simon Clubley
1) You can't edit commands across line boundaries. Even Windows CLIs
can do this.
This isn't really a DCL issue, though, is it?
It affects DCL so in a way that makes it a DCL issue.

If the terminal driver code is so yucky it can't be fixed, then why
can't this be handled within DCL itself with it's own input routines ?
Post by Phillip Helbig (undress to reply)
Post by Simon Clubley
8) You cannot delete a directory tree in one go.
Yes you can. What version of VMS do you have? Try HELP.
I mentioned earlier on that I wasn't aware this was added to VMS 8.4.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
V***@SendSpamHere.ORG
2015-01-19 22:08:27 UTC
Permalink
Post by Simon Clubley
I think it's time once again to build a list of DCL's flaws now that
VSI are around. Don't forget however that DCL is both a scripting
language and a UI. My initial list is below.
1) You can't edit commands across line boundaries. Even Windows CLIs
can do this.
Yes and no. The default behaviour is an issue with the terminal driver;
not DCL.
Post by Simon Clubley
2) You can't save your command history automatically, bash style, and
have it restored automatically at the next session.
A simple hack.
Post by Simon Clubley
With bash, you can have multiple shells active at the same time and
only the commands entered during a specific session will be added to
the history file when that session exits even though the shell has the
full command history from previous shells available (up to a user
defined limit).
Any implementation needs to think about the multiple shells active at
the same time issue before proposing a solution to this.
3) No filename completion. This is _really_ annoying especially since
it even exists (after a fashion) in the command prompt on current
versions of Windows.
I just double-click MB1 and click MB2. ;)
Post by Simon Clubley
4) No elegant incremental search through the command history (bash
Ctrl-R style).
Another simple hack.
Post by Simon Clubley
1) No structured programming constructs such as (for example) while
loops.
That could, IMO, be easily added.
Post by Simon Clubley
2) No ability to iterate cleanly over a list of items (bash "for i in"
style)
See: F$element()
Post by Simon Clubley
3) No ability to add site specific lexicals.
I once hacked such a beast.
Post by Simon Clubley
4) The output from the lexicals should be an immutable collection of
objects which you can then iterate over without having to worry about
the state changing during iteration.
Why? Use a programming language if this is important.
Post by Simon Clubley
5) No regex support (this is also a UI issue).
Perhaps, useful. I loathe the cryptographic nature of regex in unix-born
or C-born lingos.
Post by Simon Clubley
6) Pathetic limits on the maximum size of symbol contents.
7) No array or collection of objects support. (In addition to normal
arrays, DCL should also support associative arrays.)
Why? Use a programming language if this is important.
Post by Simon Clubley
DCL has absolutely no way to group related variables together in the
way you can with structs in C or objects in other languages.
Use a programming language if this is important.
Post by Simon Clubley
8) You cannot delete a directory tree in one go.
$ HELP DELETE file /TREE
Post by Simon Clubley
9) differences is very limited by today's standards. The functionality
in GNU diff, with (for example) it's ability to find differences in
whole directory trees and produce patch files for the differences
in an entire tree, should be the minimum baseline for functionality
these days.
I also find the unified diff output to be a _lot_ more readable than
the output from the DCL differences command.
I prefer DIFFERENCE/PARALLEL so don't muck with my DIFFs! ;)
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
David Froble
2015-01-20 04:56:17 UTC
Permalink
Post by V***@SendSpamHere.ORG
I prefer DIFFERENCE/PARALLEL so don't muck with my DIFFs! ;)
Is there any other way to use it?

Though, I could use a much wider terminal at times ....

:-)
V***@SendSpamHere.ORG
2015-01-20 13:06:22 UTC
Permalink
Post by David Froble
Post by V***@SendSpamHere.ORG
I prefer DIFFERENCE/PARALLEL so don't muck with my DIFFs! ;)
Is there any other way to use it?
Though, I could use a much wider terminal at times ....
:-)
$ DIFFERENCES/PARALLEL/WIDTH=255/OUTPUT=blah.DIF blah.one blah.two
$ EDIT blah.DIF
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Loading...