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. :-)
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.

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.
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?
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 .
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...