DCL's flaws (both scripting and UI)

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

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, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Stephen Hoffman]

On 2015-01-18 21:19:35 +0000, Simon Clubley said:

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

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

[Jan-Erik Soderholm]

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]

Simon Clubley wrote:
> 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.

> Some of DCL's UI flaws:
>
> 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.

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

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

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

:-)

:-)

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

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

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

> 3) No ability to add site specific lexicals.

Write your own library routines, and call them from a reasonable
language, such as Basic.

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

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

"DCL is not a programming language".
"DCL is not a programming language".

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

"DCL is not a programming language".
"DCL is not a programming language".

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

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

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

But, you can have a command procedure to do so ...

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

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

[David Froble]

Stephen Hoffman wrote:
> On 2015-01-18 21:19:35 +0000, Simon Clubley said:
>
>> 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:

I guess I'm just in a particular mood tonight. Live with it.

:-)

> There's no...
>
> UTF-8

Should be a VMS data type, or types
Definitely a needful thing

> asynchronous processing

Use Basic and ASTs

> floating point

Basic has it

> unsigned integers

Basic SHOULD have this

> 64-bit integers

Basic has it

> binary data

Basic has it

> objects

Can you be specific, don't really understand

> dictionaries

Can you be specific, don't really understand

> arrays

Basic has it

> functions that return values

Basic has it

> user-written lexical functions

Basic has it

> support for menu-based and graphical-based user interfaces

Hmmmmm ........ I've got a menu application ...

> JIT

Basic has it

> compilation

Basic has it

> embedding

Can you be specific, don't really understand

> debugging

Basic has it

> DCL libraries

Basic has object and run time libraries

> More specific error trapping than ON; let me catch specific errors.

Basic has it

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

[Craig A. Berry]

On 1/18/15 3:19 PM, Simon Clubley wrote:

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

> 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]

On 15-01-18 20:46, David Froble wrote:

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

> I still remember, with a grin, JF's idea of user name and password
> completion.

Must be a good suggestion if you remember it ! :-)

[JF Mezei]

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

[Craig A. Berry]

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.

[Matthew H McKenzie]

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.


"JF Mezei" <jfmezei...@vaxination.ca> wrote in message
news:54bc7c5b$0$44355$c3e8da3$66d3...@news.astraweb.com...

[Jan-Erik Soderholm]

Matthew H McKenzie skrev den 2015-01-19 08:29:
> 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

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

> - leaving DCL mostly as it is, preserving snippet value.

Yes, DCL does what it does quite OK today...


Jan-Erik.

[cme...@gmail.com]

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]

On 2015-01-19, Craig A. Berry <craig...@nospam.mac.com> wrote:
> On 1/18/15 3:19 PM, Simon Clubley wrote:
>
>> 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.

>> 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 Clubley]

On 2015-01-19, Craig A. Berry <craig...@nospam.mac.com> wrote:
>

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

[Bob Gezelter]

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

[Simon Clubley]

On 2015-01-19, David Froble <da...@tsoft-inc.com> wrote:

> Simon Clubley wrote:
>> 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.

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

>>
>> Some of DCL's scripting limitations:
>>
>> 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.

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

[Phillip Helbig (undress to reply)]

In article <m9h815$i3f$1...@dont-email.me>, Simon Clubley

<clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

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

This isn't really a DCL issue, though, is it?

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

Yes you can. What version of VMS do you have? Try HELP.

[John Reagan]

On Monday, January 19, 2015 at 3:40:48 PM UTC-5, Simon Clubley wrote:

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

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

But probably slower...

[Simon Clubley]

On 2015-01-19, John Reagan <xyzz...@gmail.com> wrote:
> On Monday, January 19, 2015 at 3:40:48 PM UTC-5, Simon Clubley wrote:
>
>> 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.

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

[VAXman-]

In article <m9h815$i3f$1...@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

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

Yes and no. The default behaviour is an issue with the terminal driver;
not DCL.

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

A simple hack.

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

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

Another simple hack.

>Some of DCL's scripting limitations:
>
>1) No structured programming constructs such as (for example) while
>loops.

That could, IMO, be easily added.

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

See: F$element()

>3) No ability to add site specific lexicals.

I once hacked such a beast.

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

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

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

Yeah, it should be infinite. :rolleyes:

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

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

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

$ HELP DELETE file /TREE

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

[Simon Clubley]

On 2015-01-19, Phillip Helbig (undress to reply) <hel...@asclothestro.multivax.de> wrote:
> In article <m9h815$i3f$1...@dont-email.me>, Simon Clubley
><clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>> Some of DCL's UI flaws:
>>
>> 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 ?

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

[VAXman-]

In article <467a46c3-867e-40e0...@googlegroups.com>, John Reagan <xyzz...@gmail.com> writes:
>On Monday, January 19, 2015 at 3:40:48 PM UTC-5, Simon Clubley wrote:
>
>> 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.

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

[johnwa...@yahoo.co.uk]

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]

On Monday, January 19, 2015 at 4:52:41 PM UTC-5, Simon Clubley wrote:

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

[Jan-Erik Soderholm]

Simon Clubley skrev den 2015-01-19 22:52:

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

[Stephen Hoffman]

On 2015-01-19 01:56:09 +0000, David Froble said:

> Stephen Hoffman wrote:
>
>> asynchronous processing
>
> Use Basic and ASTs

But then BASIC doesn't script DCL commands all that well, either.

>
>> floating point
>
> Basic has it

DCL doesn't.

>> 64-bit integers
>
> Basic has it

DCL doesn't.

>> binary data
>
> Basic has it

DCL doesn't.

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

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

>
>> arrays
>
> Basic has it

So does DCL, if I wanted to substitute symbols.

...

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

>
>> JIT
>
> Basic has it

No, BASIC does not have a JIT.

>
>> compilation
>
> Basic has it

DCL is interpreted, and also lacking a JIT.

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

>> debugging
>
> Basic has it

So does DCL, via third-party.

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

>
>> More specific error trapping than ON; let me catch specific errors.
>
> Basic has it

But does your DCL?

>
> ...

> Are we having fun yet?

Having worked a whole lot in DCL and BASIC and other languages over the
years, well, not really. :-)

[Stephen Hoffman]

On 2015-01-19 01:46:10 +0000, David Froble said:

> Simon Clubley wrote:
>> 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.
>
>> Some of DCL's UI flaws:
>>
>> 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Stephen Hoffman]

On 2015-01-19 22:53:11 +0000, John Reagan said:

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

[John Reagan]

On Monday, January 19, 2015 at 7:23:10 PM UTC-5, Stephen Hoffman wrote:

>
> 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]

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.

[Craig A. Berry]

On 1/19/15 6:49 AM, Jan-Erik Soderholm wrote:
> Matthew H McKenzie skrev den 2015-01-19 08:29:
>> 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
>
>
>> - 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.

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.

[Stephen Hoffman]

On 2015-01-20 00:32:43 +0000, John Reagan said:

> On Monday, January 19, 2015 at 7:23:10 PM UTC-5, Stephen Hoffman wrote:
>
>>
>> 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.

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

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

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

[David Froble]

Stephen Hoffman wrote:
> On 2015-01-19 01:56:09 +0000, David Froble said:
>
>> Stephen Hoffman wrote:
>>
>>> 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.

>>
>>> floating point
>>
>> Basic has it
>
> DCL doesn't.

See above :-)

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.

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

:-)

>>
>>> arrays
>>
>> Basic has it
>
> So does DCL, if I wanted to substitute symbols.
>
> ...
>>
>>> 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.

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

>>
>>> compilation
>>
>> Basic has it
>
> DCL is interpreted, and also lacking a JIT.
>
>>> 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.

>>> debugging
>>
>> Basic has it
>
> So does DCL, via third-party.
>
>>> 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.
>
>>
>>> More specific error trapping than ON; let me catch specific errors.
>>
>> Basic has it
>
> But does your DCL?
>
>>
>> ...
>> 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?


:-)

[David Froble]

John Reagan wrote:
> On Monday, January 19, 2015 at 3:40:48 PM UTC-5, Simon Clubley wrote:
>
>> 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?

[David Froble]

Then why not use the existing solution ???

[David Froble]

Stephen Hoffman wrote:
> On 2015-01-19 22:53:11 +0000, John Reagan said:
>
>> 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.

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

[David Froble]

Simon Clubley wrote:
> On 2015-01-19, David Froble <da...@tsoft-inc.com> wrote:
>> Simon Clubley wrote:
>>> 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.
>
>> 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

>>> Some of DCL's scripting limitations:
>>>
>>> 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.

If the alignment is correct, you'll see that you even agree that it's a
"command language".

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

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

[David Froble]

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.

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

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

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

> Certificate-based logins would be handy.

Yes. This would be a good security enhancement.

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

> DCL is a programming language. It's just an old and clunky one,
> and part of dusting off VMS means updates.
>>
>>> 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.
>
>>
>> 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.
>
>>
>>> 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?

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.

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?

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

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

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

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

[David Froble]

But, that "$j" is just SO alien looking ...

Sorry, old dog ...

:-)

[David Froble]

VAXman- @SendSpamHere.ORG wrote:

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

:-)

[Stephen Hoffman]

On 2015-01-20 03:06:47 +0000, David Froble said:

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

> 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*)

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

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

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

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

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

[Stephen Hoffman]

On 2015-01-20 03:42:46 +0000, David Froble said:

> Simon Clubley wrote:
>> On 2015-01-19, David Froble <da...@tsoft-inc.com> wrote:
>>
>>> 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.

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

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

[JF Mezei]

On 15-01-20 00:12, Stephen Hoffman wrote:

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

[David Froble]

Stephen Hoffman wrote:

> 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]

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.

[Jan-Erik Soderholm]

David Froble skrev den 2015-01-20 04:06:

> Stephen Hoffman wrote:

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

[Jan-Erik Soderholm]

David Froble skrev den 2015-01-20 09:13:

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

[VAXman-]

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

[johnso...@gmail.com]

On Tuesday, January 20, 2015 at 3:09:25 AM UTC-5, David Froble wrote:

> 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]

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]

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]

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.

[David Froble]

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]

David Froble skrev den 2015-01-20 15:01:
> Jan-Erik Soderholm wrote:
>> David Froble skrev den 2015-01-20 04:06:
>>
>>> Stephen Hoffman wrote:
>>
>>>>
>>>> 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.

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

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

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

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

> Again, the starting point is equal.

OK, so a similar data type exist in the base Basic distribution?
I thought not.

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

[Jan-Erik Soderholm]

David Froble skrev den 2015-01-20 14:46:

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

[David Froble]

Jan-Erik Soderholm wrote:
> David Froble skrev den 2015-01-20 14:26:
>> Jan-Erik Soderholm wrote:
>>> David Froble skrev den 2015-01-20 09:13:
>>>
>>>>
>>>> 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.

> 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]

David Froble skrev den 2015-01-20 15:50:
> Jan-Erik Soderholm wrote:
>> David Froble skrev den 2015-01-20 14:26:
>>> Jan-Erik Soderholm wrote:
>>>> David Froble skrev den 2015-01-20 09:13:
>>>>
>>>>>
>>>>> 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.

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

>
> 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]

In article <m9lq23$be8$1...@news.albasani.net>,

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.

>
> 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.
>
>
>>
>> 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.
>
>>
>> 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
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[JF Mezei]

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

[David Froble]

Jan-Erik Soderholm wrote:

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

[Marc Van Dyck]

John Reagan was thinking very hard :
>
> If you want concise, I'll go get APL up and running for you.
>
Can we ask for that ? really ?

--
Marc Van Dyck

[Bill Gunshannon]

In article <mn.a4837df102...@invalid.skynet.be>,

Marc Van Dyck <marc.gr...@invalid.skynet.be> writes:
> John Reagan was thinking very hard :
>>
>> If you want concise, I'll go get APL up and running for you.
>>
> Can we ask for that ? really ?

It's been a long (really long) time since I looked, but wasn't APL
included in the CONDIST?

[abrsvc]

APL is the only languages where it is easier to re-write the code than to debug it. Consise, yes. Short programs. yes. Easy to read and understand, not so much.

[Bill Gunshannon]

In article <07c34234-9fc9-4d76...@googlegroups.com>,

abrsvc <dansabr...@yahoo.com> writes:
> APL is the only languages where it is easier to re-write the code than to debug it. Consise, yes. Short programs. yes. Easy to read and understand, not so much.
>

Once again, matter of opinion. Back when IBM was in it's prime they
were partnered with Marist College in Poughkeepsie. We used to get
their interns for summer work. Whizes with APL couldn't do anything
with COBOL or Fortran.

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

[Simon Clubley]

On 2015-01-20, David Froble <da...@tsoft-inc.com> wrote:
> Jan-Erik Soderholm wrote:
>
>> 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> )
>

;---

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

$ value = L{some_string_containing_the_key}

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

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

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[David Froble]

Some code similar to what's between the +++ and --- would have to exist
somewhere. If part of DCL, fine, but must exist.

I was just showing that some new fangled data type in some new fangled
language wasn't much different that what exists in one of the old
compiled languages.

[Jan-Erik Soderholm]

David Froble skrev den 2015-01-20 18:50:
> Jan-Erik Soderholm wrote:
>
>> 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> )
>

Yes, but that uses a sequential search of the array, right?
The search time will grow in line with the size of the array.

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

Jan-Erik.

[Jan-Erik Soderholm]

Bill Gunshannon skrev den 2015-01-20 20:39:
> In article <07c34234-9fc9-4d76...@googlegroups.com>,
> abrsvc <dansabr...@yahoo.com> writes:
>> APL is the only languages where it is easier to re-write the code than to debug it. Consise, yes. Short programs. yes. Easy to read and understand, not so much.
>>
>
> Once again, matter of opinion. Back when IBM was in it's prime they
> were partnered with Marist College in Poughkeepsie. We used to get
> their interns for summer work. Whizes with APL couldn't do anything
> with COBOL or Fortran.
>
> Oh, and I have been doing APL for over 30 years and I have no problem
> understanding it. (Only do it for fun anymore, but still do it once
> in a while.)
>
> bill
>

This is one of the better APL tutorials I have seen:
https://www.youtube.com/watch?v=a9xAKttWgP4

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

Jan-Erik.

[Jan-Erik Soderholm]

Oh, it is very different, as I wrote in another post.

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

Jan-Erik.

[johnso...@gmail.com]

On Tuesday, January 20, 2015 at 3:35:51 PM UTC-5, David Froble wrote:

> I was just showing that some new fangled data type in some new fangled
> language wasn't much different that what exists in one of the old
> compiled languages.

Out of curiosity, when's the last time you tried to learn a new programming
language on its own terms? You know, just for the sake of learning and
expanding the skill set?

EJ

[David Froble]

I've tried looking at C several times. A disaster.

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

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

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

Regardless, with a few exceptions, such as what I consider a rather poor
release of SSL on VMS, I have not been convinced that I really need to
abandon what I already know. Being semi-retired could have something to
do with that.

[David Froble]

You appear to not have consider this in the original post.

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

^^^^^^^^^^^^^^^^^^^^

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

You've gone off on a tangent. The original post was to show that the
capability wasn't all that difficult in an older compiled language, and
that yes, a data type that does the job does exist in Basic.

[Jan-Erik Soderholm]

Fine. I guess you had to do that to create an example. But then
it will not scale very well. Python lookup time is the same no
matter the size of the dictionary. For small dictionaries the
hash calculation might be longer then a seq search, though...

Of course I understand that you *could* build someting in Basic
that looks like the built-in "dict" datatype in Python, but it
will never be "built-in" and a part of the language standard.

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

Apart from that hashed keys doesn't use either binary search or
B-three structures, you might very well understand them anyway.
No problem. The point is still that is is not part of the Basic
language standard.

> You've gone off on a tangent. The original post was to show that the
> capability wasn't all that difficult in an older compiled language, and
> that yes, a data type that does the job does exist in Basic.

No, it doesn't! There is no data type like the Python "dict" i Basic!
You have to write your own routines using the available (simpler)
data types.

Jan-Erik.

[johnso...@gmail.com]

On Wednesday, January 21, 2015 at 6:34:33 AM UTC-5, Jan-Erik Soderholm wrote:

> No, it doesn't! There is no data type like the Python "dict" i Basic!
> You have to write your own routines using the available (simpler)
> data types.

I think his basic point (no pun intended!) is that the tools are good
enough for him so therefore they should be good enough for everyone.

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

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

EJ

[johnso...@gmail.com]

On Tuesday, January 20, 2015 at 9:52:25 PM UTC-5, David Froble wrote:

> Perhaps part of the problem is that I neither see nor feel the need to
> move on to other languages.
>
> Regardless, with a few exceptions, such as what I consider a rather poor
> release of SSL on VMS, I have not been convinced that I really need to
> abandon what I already know.

It's not about abandoning. It's about expanding your horizons and your
expectations. Sometimes you can appreciate home all the more by going
out and exploring the world. It's even easier these days considering the
near oracle like quality of google. "How do I do X in language Y". Most
of the time it will take you to the relevant question on stackoverflow!

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

EJ

[Stephen Hoffman]

On 2015-01-21 13:10:24 +0000, johnso...@gmail.com said:

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

Or to the substantially updated and got-to-have-it versions of VMS,
from the ancient times. Outside of the folks that want or need
Poulson-class servers, that's probably not V8.4-1H1. Whether the
x86-64 port or subsequent releases can add significant new features —
beyond the platform port — probably depends on how big VSI can get and
particularly on how much revenue they can realize from their initial
VMS and LP releases and/or support.

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

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

Now as to whether VSI can get to profitability and can then start
seriously chasing what's available on other platforms, and can start
growing the user base? That's no small and no simple project, either.



--
Pure Personal Opinion | HoffmanLabs LLC

[John Reagan]

I have the sources somewhere. :) One of my former co-workers was one of the VAX APL developers and was trying to get it running on Alpha. Apparently VAX APL generates VAX code on the fly for some diadic operators (I think double-dot and a few others). That was done for performance of course. He was playing with rewriting those into C and not do the on-the-fly code generation. It wouldn't be as fast, but it is portable and newer hardware is faster.

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

And no, I don't have sources for VAX SCAN, VAX LISP, VAX Modula-2, VAX RPG-II, VAX CORAL, or VAX KOALA

[John Reagan]

On Wednesday, January 21, 2015 at 9:25:14 AM UTC-5, Stephen Hoffman wrote:

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

We provided a DEC BASIC to VB converter. As far as I know, almost nobody used it.

[VAXman-]

In article <m9ocr8$2ge$1...@dont-email.me>, Stephen Hoffman <seao...@hoffmanlabs.invalid> writes:
>On 2015-01-21 13:10:24 +0000, johnso...@gmail.com said:
>
>> I would imagine that even Froble could concede that there was a time
>> that he looked forward to new features added to his trusty DEC Basic
>> toolset.
>> I would hope that familiarity with that excitement could enable one to
>> understand why others might be drawn to the features of newer languages.
>
>Or to the substantially updated and got-to-have-it versions of VMS,
>from the ancient times. Outside of the folks that want or need
>Poulson-class servers, that's probably not V8.4-1H1. Whether the
>x86-64 port or subsequent releases can add significant new features —
>beyond the platform port — probably depends on how big VSI can get and
>particularly on how much revenue they can realize from their initial
>VMS and LP releases and/or support.
>
>As for the future of BASIC, it'd be interesting to see what might
>happen should VSI decide to overhaul DEC BASIC, adding object support,
>pointer support, garbage collection and maybe some other new features
>into the language. This'd probably best follow the Visual Basic AS
>syntax for pointers, given the VB syntax is long established. This
>won't draw all that many folks away from C, C++, Python or other
>higher-profile languages. But the crowd using VB was and probably
>still is bigger than the crowd using VMS, l'd expect.
>
>The flaws in DCL, however, remain. It's clunky and confusing to use
>with its asymmetric quoting and its fondness for quoted quotes for

Not any less "clunky and confusing ot use" than trying to cast C function
pointers. You either know its quirks and syntax or you have to learn it.

>various tasks, and that BASIC and Macro32 can solve various of these
>limitations — sort of, as BASIC doesn't have a good way to chain
>together a series of commands, short of spawning off DCL — won't draw
>new folks to VMS.

The problem with spawning a command is that it is now NOT running in the
context of the process in which it might be trying to act upon.

>Now as to whether VSI can get to profitability and can then start
>seriously chasing what's available on other platforms, and can start
>growing the user base? That's no small and no simple project, either.

I'd think that a goal of simply maintaining the user base is better goal.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

[cme...@gmail.com]

On Tuesday, January 20, 2015 at 2:39:14 PM UTC-5, Bill Gunshannon wrote:

>
> Once again, matter of opinion. Back when IBM was in it's prime they
> were partnered with Marist College in Poughkeepsie. We used to get
> their interns for summer work. Whizes with APL couldn't do anything
> with COBOL or Fortran.

The last time I had access to an APL compiler, I was wanted not to use it.
Turns out it was a transpiler which wrote BASIC. Both ran on a
DECSYSTEM-10 and the BASIC was interpreted.

Much to the dismay of a fellow who learned APL because it had a
reputation for doing large calculations "faster".

[Stephen Hoffman]

On 2015-01-21 14:50:33 +0000, John Reagan said:

> We provided a DEC BASIC to VB converter. As far as I know, almost
> nobody used it.

But was that because they didn't like the language dialect, or because
they didn't want to or couldn't easily migrate to Microsoft Windows?

[Bill Gunshannon]

In article <m9ofu1$f3v$1...@dont-email.me>,

Stephen Hoffman <seao...@hoffmanlabs.invalid> writes:
> On 2015-01-21 14:50:33 +0000, John Reagan said:
>
>> We provided a DEC BASIC to VB converter. As far as I know, almost
>> nobody used it.
>
> But was that because they didn't like the language dialect, or because
> they didn't want to or couldn't easily migrate to Microsoft Windows?

That was my immediate thought as well.

[Bill Gunshannon]

In article <36a713ca-0a0a-4994...@googlegroups.com>,

Immplementation shortcoming, not language shortcoming. All of the APL's
I have used were "large calculation fast". Even the one on the Z80. :-)

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

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

[Stephen Hoffman]

On 2015-01-21 14:58:51 +0000, VAXman- @SendSpamHere.ORG said:

> In article <m9ocr8$2ge$1...@dont-email.me>, Stephen Hoffman
> <seao...@hoffmanlabs.invalid> writes:
>>
>> The flaws in DCL, however, remain. It's clunky and confusing to use
>> with its asymmetric quoting and its fondness for quoted quotes for
>
> Not any less "clunky and confusing ot use" than trying to cast C function
> pointers. You either know its quirks and syntax or you have to learn it.

I've not suggested csh, C nor BASIC as a command line. Nor have I
suggested something as concise as BF, for that matter.

>> Now as to whether VSI can get to profitability and can then start
>> seriously chasing what's available on other platforms, and can start
>> growing the user base? That's no small and no simple project, either.
>
> I'd think that a goal of simply maintaining the user base is better goal.

Short-term, certainly. Longer-term, installed base growth with stable
or increasing revenues are what allows the vendor to substantially
enhance and upgrade the operating system, and are what allows the
vendor to lower the prices on the software and the support. Having VMS
as it is now through the next decade or two may well be a viable
business, but one that'll likely continue to slowly tail off as the
applications and as staff age out.

The command line is unfortunately the standard operations and
management interface for VMS right now, and aiming products at the
installed base and at arcane command line environments is unlikely to
become a growth market. Without new applications and new users that
are at least replacing those that are aging out and preferably adding
additional applications and users, there's no good outcome, either.

[JF Mezei]

On 15-01-21 09:25, Stephen Hoffman wrote:

> The flaws in DCL, however, remain. It's clunky and confusing to use
> with its asymmetric quoting and its fondness for quoted quotes for
> various tasks,

2 questions:

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

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

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

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

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

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



2- DCL versions

How difficult would it be to do something like Unix and have the first
line of a DCL command procedure define the DCL flavour. This would allow
procedures that make use of new features, new argumebnt apssing etc to
exist alongside procedures that use the old DCL for compatibility purposes.

[Bob Koehler]

In article <54bde6b7$0$58715$c3e8da3$88b2...@news.astraweb.com>, JF Mezei <jfmezei...@vaxination.ca> writes:
> On 15-01-20 00:12, Stephen Hoffman wrote:
>
>> Perform a RECALL/OUT=sys$login:history.log just before LOGOUT, and then
>> perform a RECALL/INPUT=sys$login:history.log when you next log in.
>
> Not quite. History not saved when you don't actually logout (crashed,
> close xterm window etc) and history not "live" shared between different
> windows .

All of my shells on UNIX and Mac screw up the history when
logging from multiple processes at the same time. You have one
that doesn't?

It's more prevalent in VMS when using network file access, but on any
OS beware of history files containing access information that was typed
on command lines.

[Bob Koehler]

In article <m9lknm$cob$1...@dont-email.me>, David Froble <da...@tsoft-inc.com> writes:
>
> Basic compiler on all systems. And if not, with DECnet and FAL, it
> doesn't matter. I can even execute the image sitting on a dev system on
> say a production system over the network. Well, if same architecture.
>
> But, for us, the production system has the compiler, so no issue.

We generally don't allow compilers on production systems as the
customer is deathly afraid of what unauthorized software someone
might write.

But there's always "Basic" vs. "basic". Macro-32 is not Basic and
not a compiler on VAXen, but it makes a good basic compiler for many
of us.

[VAXman-]

It's software; most anything is possible. A "$! DCL2", for example, would
not break existing functionality but there's already been complaint in this
thread about some functions working in comments. I suppose it's fair but it
is no different than the shebang stuff in unix shells.

[Stephen Hoffman]

On 2015-01-21 15:37:47 +0000, JF Mezei said:

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

If you believe that quoting is the extent of my issues with DCL, kindly
please re-read some of my earlier messages.

> 2- DCL versions
>
> How difficult would it be to do something like Unix and have the first
> line of a DCL command procedure define the DCL flavour.

Implementing a shebang-like
<http://en.wikipedia.org/wiki/Shebang_(Unix)> prefix in the file?
Certainly technically feasible, but it'd mean stuffing both CLIs into
P1 space or figuring out how to remap the CLIs on the fly, and logic to
figure out which grammar was in current use within a process. Much
easier to have separate CLI images and separate processes. Certainly
if the shebang approach was generalized beyond DCL grammar selection,
it'd allow other languages to be invoked. But then the shebang is not
how VMS traditionally differentiates this stuff, as VMS depends on
another of my favorite morasses, the file type. It'd be more typical
of VMS to use a different file type, whether .DCL64 or maybe
resurrecting the old CMD extension from eons past. Or if John Reagan
does get around to working on the DCL replacement, he could name it
.JCL. Changing the new file type away would avoid some of the
confusion that arises in network file transfers secondary to the use of
.COM for Windows executable files.

Can't say I see any of this happening anytime soon, though.

[JF Mezei]

On 15-01-21 11:05, Stephen Hoffman wrote:

> If you believe that quoting is the extent of my issues with DCL, kindly
> please re-read some of my earlier messages.

I did not mean to imply that the quoting was the only problem. The
trick here is to find a path that allows old stuff to continue to work
while VMS evolves with new functionality.

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

Is it correct to state that with Unix, when you invoke a shell script, a
new process is created, so it becomes easier to give that process the
shell that is specified in the first line of the script ?

[Bill Gunshannon]

In article <m9oing$s81$1...@dont-email.me>,

Just my $.02 worth.

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

[John Reagan]

On Wednesday, January 21, 2015 at 10:37:50 AM UTC-5, JF Mezei wrote:

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

To give some sense of the difficulty in changing DCL...

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

The #1 complex module? The shadow driver. #2? One of the modules in the
Macro32 parser itself. #3? DCL. Routine after routine after routine all
with JSB linkages that jump in and out of each other with random pieces of
global state shoved into every corner. And the funky stack management (don't
forget DCL has a supervisor mode stack but the ^Y interrupts your user mode
program) when you hit ^Y/exit or ^Y/continue is calling standard specific and hurts your brain.

>
>
>
> 2- DCL versions
>
> How difficult would it be to do something like Unix and have the first
> line of a DCL command procedure define the DCL flavour. This would allow
> procedures that make use of new features, new argumebnt apssing etc to
> exist alongside procedures that use the old DCL for compatibility purposes.

Either that or a SET EXTENDED_DCL command or such. I actually like the shebang
style. One could imagine DCL taking the remainder of the .COM file and giving
it as input to the command in the shebang. That is if anybody can read the
DCL source code to figure it out.

[Stephen Hoffman]

On 2015-01-21 16:21:33 +0000, John Reagan said:

> To give some sense of the difficulty in changing DCL...

Until the Itanium port, DCL had its own home-grown threading, too.

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

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

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

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

I'd rather see additions and enhancements that pull folks forward, and
— if there's a subsequent DCL retirement planned — a schedule for that
removal. But then DCL64 probably isn't going to sell a whole lot of
new licenses. Maybe a bash or another CLI might sell a few, though.
It'd be interesting to see the sys$cli interfaces officially
documented; there are internal areas of VMS that aren't documented
and/or aren't stable: sys$cli, what would be a file system layer, a
FUSE layer, etc.

[Simon Clubley]

On 2015-01-21, Bob Koehler <koe...@eisner.nospam.decuserve.org> wrote:
> In article <54bde6b7$0$58715$c3e8da3$88b2...@news.astraweb.com>, JF Mezei <jfmezei...@vaxination.ca> writes:
>>
>> Not quite. History not saved when you don't actually logout (crashed,
>> close xterm window etc) and history not "live" shared between different
>> windows .
>
> All of my shells on UNIX and Mac screw up the history when
> logging from multiple processes at the same time. You have one
> that doesn't?
>

Bash on RHEL based systems I have used has always saved session history
from multiple sessions into one .bash_history file without each session
clobbering the other session history (subject to the requested maximum
amount of history to keep).

I've seen people complain about the above clobbering so it must happen,
but I have never seen this.

> It's more prevalent in VMS when using network file access, but on any
> OS beware of history files containing access information that was typed
> on command lines.
>

Which is why for bash you can (and I do) unset HISTFILE when doing that.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[abrsvc]

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

Thoughts?

[Jan-Erik Soderholm]

Agree.
Let the process start up in DCL and let the programmer or
system manager, decide if and when to call an additional
tool to complement DCL.

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

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

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

do whatever needed in Python...

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

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

Jan-Erik.

[David Froble]

Bob Koehler wrote:

So, the customer has tunnel vision, huh? If it's called a compiler,
they see it, but if it's called an assembler, they don't see it?

:-)

What about DCL, since some misguided souls seem to proclaim it a
"programming language"?

[JF Mezei]

Just an idea:

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

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

(there may be some implications when you submit a batch job, you might
have to specify the command processor if not DCL by default).

[David Froble]

johnso...@gmail.com wrote:
> On Tuesday, January 20, 2015 at 9:52:25 PM UTC-5, David Froble wrote:
>
>> Perhaps part of the problem is that I neither see nor feel the need to
>> move on to other languages.
>>
>> Regardless, with a few exceptions, such as what I consider a rather poor
>> release of SSL on VMS, I have not been convinced that I really need to
>> abandon what I already know.
>
> It's not about abandoning. It's about expanding your horizons and your
> expectations.

I'm 68 1/2 years old. These days, that 1/2 is significant.

On the days that I can actually convince myself to do something, it's
much more often working on the airplanes than the computers.

> Sometimes you can appreciate home all the more by going
> out and exploring the world.

The airplanes, at least for me, are much better for that.

> It's even easier these days considering the
> near oracle like quality of google. "How do I do X in language Y". Most
> of the time it will take you to the relevant question on stackoverflow!
>
> Darn kids these days, there was a time when you actually had to read
> the manual and people were entitled to expect you to! They don't know
> what they are missing. Or maybe its the other way around. :-)

You got that right. The DEC documentation could actually teach you some
things. At least for me, what has replaced it is of much poorer quality.

[David Froble]

johnso...@gmail.com wrote:
> On Wednesday, January 21, 2015 at 6:34:33 AM UTC-5, Jan-Erik Soderholm wrote:
>
>> No, it doesn't! There is no data type like the Python "dict" i Basic!
>> You have to write your own routines using the available (simpler)
>> data types.

Ok, this is perhaps a "perspective" thing. My impression of Python, and
some other products, is that they SEEM very versatile because of all the
library procedures included in the distribution. Now, to me, a library
procedure is just that, and can exist in many environments. I, and this
is my perspective, perhaps different then that of others, do not
consider library routines as part of a language. I've been around
compiled languages for a long time, and "my perspective" is that the
code a compiler can generate is the language.

This is probably a rather narrow perspective, as there is usually more
than one way to skin a cat.

> I think his basic point (no pun intended!) is that the tools are good
> enough for him so therefore they should be good enough for everyone.

Actually, no, that is not the intention.

Specifically, my point is that while some seem (my perspective) to feel
that some capabilities don't exist in the older compiled languages, the
capability actually does exist. Not saying everyone needs to choose
that path.

> It is true that there isn't a computational problem in the world that eludes
> the power of DEC Basic.

YES! Just that. However, you may have a problem convincing some of
that statement.

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

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

Since I worked with Basic+ on RSTS V4b, yes, you'd be very correct.
Many things have been added to VAX/DEC Basic. An example, the RECORD
construct, which opened up the capability for complex user declared
variable types.

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

Comments John?