Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.vms > #378323 > unrolled thread

DCL2

Back to article view | Back to comp.os.vms

Contents

  DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-05 21:41 -0500
    Re: DCL2 Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> - 2025-12-06 11:42 +0100
      Re: DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-06 10:33 -0500
        Re: DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-06 10:57 -0500
          Re: DCL2 Chris Townley <news@cct-net.co.uk> - 2025-12-06 16:12 +0000
            Re: DCL2 kludge@panix.com (Scott Dorsey) - 2025-12-06 14:45 -0500
              Re: DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-06 15:23 -0500
                Re: DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-06 15:47 -0500
                  Re: DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-07 12:03 -0500
                Re: [Info-vax] DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-07 12:09 -0500
              Re: DCL2 Chris Townley <news@cct-net.co.uk> - 2025-12-07 14:18 +0000
                Re: DCL2 kludge@panix.com (Scott Dorsey) - 2025-12-07 10:03 -0500
                Re: DCL2 cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-08 20:13 +0000
          Re: [Info-vax] DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-06 15:41 -0500
      Re: DCL2 Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-14 01:45 +0000
        Re: DCL2 antispam@fricas.org (Waldek Hebisch) - 2025-12-15 01:51 +0000
          Re: DCL2 Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-15 02:56 +0000
          Re: DCL2 cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-15 16:37 +0000
            Re: DCL2 jgd@cix.co.uk (John Dallman) - 2025-12-15 19:37 +0000
              Re: DCL2 Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-15 22:59 +0000
        Re: DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-15 11:58 -0500
    Re: DCL2 "Craig A. Berry" <craigberry@nospam.mac.com> - 2025-12-06 15:28 -0600
      Re: DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-06 18:46 -0500
        Re: DCL2 "Craig A. Berry" <craigberry@nospam.mac.com> - 2025-12-07 07:17 -0600
          Re: DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-07 11:07 -0500
            Re: DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-07 11:13 -0500
              Re: DCL2 steve sparrow <sdsparrow@aol.com> - 2025-12-08 11:14 -0600
                Re: DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-08 19:07 -0500
          Re: DCL2 cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-16 14:05 +0000
            Re: DCL2 "Craig A. Berry" <craigberry@nospam.mac.com> - 2025-12-16 15:20 -0600
              Re: DCL2 Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-16 21:59 +0000
              Re: DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-16 20:17 -0500
                Re: DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-16 20:42 -0500
                Re: DCL2 "Craig A. Berry" <craigberry@nospam.mac.com> - 2025-12-17 07:19 -0600
                  Re: DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-18 09:46 -0500
                Re: DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-18 09:44 -0500
              Re: DCL2 cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-17 16:55 +0000
            Re: DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-16 20:26 -0500
              Re: DCL2 cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-17 16:57 +0000
                SIMH + OpenVMS 5.5-2H4 standalone BACKUP: ISO appears as DJAx not DUAx flexmcmurphy <plica2006@gmail.com> - 2025-12-17 23:00 +0000
                Re: DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-17 20:45 -0500
                  Re: DCL2 cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-18 15:03 +0000
        Re: DCL2 Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-14 01:41 +0000
          Re: DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-15 11:59 -0500
            Re: DCL2 Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-15 23:01 +0000
              Re: DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-15 19:28 -0500
                Re: DCL2 Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-16 01:24 +0000
                  Re: DCL2 Sam Thomas <sam@noneya.com> - 2025-12-16 17:38 +0000
                    Re: DCL2 Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-16 22:07 +0000
                      Re: DCL2 Sam Thomas <sam@noneya.com> - 2025-12-17 14:52 +0000
                        Re: DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-17 20:34 -0500
                          Re: DCL2 Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-18 02:31 +0000
                            Re: DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-17 21:40 -0500
    Re: DCL2 Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-12-08 14:12 +0000
      Re: DCL2 Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-12-08 14:23 +0000
      Re: DCL2 bill <bill.gunshannon@gmail.com> - 2025-12-08 15:42 -0500
        Re: DCL2 cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-10 20:50 +0000
          Re: DCL2 Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-12-11 13:11 +0000
            Re: DCL2 cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-11 16:22 +0000
      Re: DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-08 19:58 -0500
        Re: DCL2 Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-12-09 13:31 +0000
      Re: DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-08 20:35 -0500
        Re: DCL2 Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-12-09 13:55 +0000
          Re: DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-09 20:08 -0500
            Re: DCL2 Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-12-10 14:14 +0000
    Re: DCL2 Mark Berryman <mark@theberrymans.com> - 2025-12-13 11:27 -0700
      Re: DCL2 Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-14 01:31 +0000
      Re: DCL2 Arne Vajhøj <arne@vajhoej.dk> - 2025-12-15 11:48 -0500

Page 1 of 4  [1] 2 3 4  Next page →

#378323 — DCL2

Context
-------

1)

My opinion is that DCL:
* is fine for interactive use
* is fine for small scripts (5-25 lines with at most a few lexical
   functions, a few if statements and 'Pn' usage
* is not up to expectations for writing large scripts aka
   programming in DCL

One can argue that DCL should not be used for programming, but fact
is that it is used that way.

So what is missing for programming? I would say biggest
items are:
* loops
* switch/case
* arrays
* user defined lexicals

2)

Shell capabilities does not sell systems today. Users are not doing
shell at all. Programmers work mostly on PC's. Only system managers are
still doing a lot of shell work and their shell experience is not likely
to determine platform decisions.

So VSI cannot justify investing a lot of money in a new shell, because
there is no business case.

3)

The vast majority of future VMS system managers will have experience
with alternative scripting languages that actually are available on VMS.
Most notable bash (GNV) and Python, but there are other: I like Groovy,
there may still be some that like Perl etc. So future DCL programming
will mostly be enhancing existing COM file done by existing VMS system
managers.

This mean VSI cannot break backwards compatibility for DCL - whatever
ran in 1985 has to run the exact same way today.

4)

According to many years of internet gossip, then the DCL code base
is very difficult to enhance, because it is Macro-32 and very tricky
Macro-32 that is. The last big language change was probbaly
if-then-else-endif in 1988.

VSI cannot start classic evolution process of adding new features
to DCL over time.

What to do?
-----------

A totally new shell with a new syntax is not a solution:
* the oldtimers want DCL
* the newcomers want standard (bash, Python etc.)
* expensive

A reimplementation of DCL in C (or another language, but C is
probably the current preference) is not a solution:
* risk only achieving 99.9% compatiblity instead of 100% compatibility
* expensive

What I see left is the "RATFOR approach" (in this century it should
probbaly be called "transpiling approach", but I suspect more people
here know about RATFOR than all the transpiling to JavaScript being
done today). Pre-processing extended DCL to old DCL.

Convert loop constructs to goto's and labels. Convert switch/case to
if's. Convert arrays from name[ix] to name_'ix'. Add a syntax for
declaring user defined lexicals from shareable images and translate
usage to call of UDL utility that calls functions in shareable
image and return value in symbol that is then used.

This should by design ensure 100% compatibility. Anything not new
will be left unchanged and processed by todays DCL.

And due to the fixed format and relative simplicity of of DCL then
I suspect that the pre-processor would not be that bad to implement.
But of course I could be wrong.

Preprocessing would obviously only work before symbol substitution.

$ a[1] = 123

works.

$ b1 = "["
$ b2 = "]"
$ a'b1'1'b2' = 123

does not work.

It could be implemented different ways.

A) On the fly

$ @@foobar

will preprocess foobar.xcom into memory and let DCL read from that memory.

B) Separate step

$ dcl2 foobar

converting foobar.xcom to foobar.com and:

$ @foobar

I am wondering maybe something like this has already been done and
are on one of the DECUS tapes.

Arne

[toc] | [next] | [standalone]

#378324

Arne Vajhøj formulated on Saturday :
> Context
> -------
>
> 1)
>
> My opinion is that DCL:
> * is fine for interactive use
> * is fine for small scripts (5-25 lines with at most a few lexical
>    functions, a few if statements and 'Pn' usage
> * is not up to expectations for writing large scripts aka
>    programming in DCL
>
> One can argue that DCL should not be used for programming, but fact
> is that it is used that way.
>
> So what is missing for programming? I would say biggest
> items are:
> * loops
> * switch/case
> * arrays
> * user defined lexicals
>

I have been working on very long and complex DCL procedures in the past
(not anymore since I'm retired) and to be honest, have never been
bothered by the lack of specific loop, case, or array constructs. All
of that can be pretty well implemented with the DCL structures existing
today, and can be made perfectly readable if you make the effort to
write your DCL code and document it clearly.

User written lexical functions, on the other hand, would be a real
bonus. There are, for one, still many parts of the operating system
for which you need to get information, and the only possible way to do
it is to parse some output (think of everything TCP/IP, for example),
while there is a callable interface available to get the info properly.


-- 
Marc Van Dyck

[toc] | [prev] | [next] | [standalone]

#378325

On 12/6/2025 5:42 AM, Marc Van Dyck wrote:
> Arne Vajhøj formulated on Saturday :
>> So what is missing for programming? I would say biggest
>> items are:
>> * loops
>> * switch/case
>> * arrays
>> * user defined lexicals
> 
> I have been working on very long and complex DCL procedures in the past
> (not anymore since I'm retired) and to be honest, have never been
> bothered by the lack of specific loop, case, or array constructs. All
> of that can be pretty well implemented with the DCL structures existing
> today, and can be made perfectly readable if you make the effort to
> write your DCL code and document it clearly.

It is certainly possible. Lots of people have been doing it.

But a pre-processor could make it easier.

$ i = 1
$ loop_1:
$    if i .gt. 3 then goto end_loop_1
...
$    i = i + 1
$    goto loop_1
$ end_loop_1:

works, but I think:

$ for i = 1 to 3
...
$ endfor

would be nicer.

> User written lexical functions, on the other hand, would be a real
> bonus. There are, for one, still many parts of the operating system
> for which you need to get information, and the only possible way to do
> it is to parse some output (think of everything TCP/IP, for example),
> while there is a callable interface available to get the info properly.

Yes.

And even though it is possible to run an exe that set a symbol
with lib$set_symbol, then getting it as a lexical would make it
more readable.

Arne

[toc] | [prev] | [next] | [standalone]

#378326

On 12/6/2025 10:33 AM, Arne Vajhøj wrote:
> On 12/6/2025 5:42 AM, Marc Van Dyck wrote:
>> User written lexical functions, on the other hand, would be a real
>> bonus. There are, for one, still many parts of the operating system
>> for which you need to get information, and the only possible way to do
>> it is to parse some output (think of everything TCP/IP, for example),
>> while there is a callable interface available to get the info properly.
> 
> Yes.
> 
> And even though it is possible to run an exe that set a symbol
> with lib$set_symbol, then getting it as a lexical would make it
> more readable.

Note that VSI could add it to existing DCL:

f$udl(shrimg, arg1, ...)

with a convention of entry point:

int udl$function(int narg, enum dcl_type *argtyp, void *argval, enum 
dcl_typ *rettyp, void *retval)

If they wanted to.

New lexical functions have been added over time.

Arne

[toc] | [prev] | [next] | [standalone]

#378328

On 06/12/2025 15:57, Arne Vajhøj wrote:
> On 12/6/2025 10:33 AM, Arne Vajhøj wrote:
>> On 12/6/2025 5:42 AM, Marc Van Dyck wrote:
>>> User written lexical functions, on the other hand, would be a real
>>> bonus. There are, for one, still many parts of the operating system
>>> for which you need to get information, and the only possible way to do
>>> it is to parse some output (think of everything TCP/IP, for example),
>>> while there is a callable interface available to get the info properly.
>>
>> Yes.
>>
>> And even though it is possible to run an exe that set a symbol
>> with lib$set_symbol, then getting it as a lexical would make it
>> more readable.
> 
> Note that VSI could add it to existing DCL:
> 
> f$udl(shrimg, arg1, ...)
> 
> with a convention of entry point:
> 
> int udl$function(int narg, enum dcl_type *argtyp, void *argval, enum 
> dcl_typ *rettyp, void *retval)
> 
> If they wanted to.
> 
> New lexical functions have been added over time.
> 
> Arne
> 

Too true - many of them. I started using DCL on VMS 4.7

-- 
Chris

[toc] | [prev] | [next] | [standalone]

#378330

Let me just say that as the Unix shell advanced from ssh through ksh and 
into modern bash (with some csh sidelines), at the same time that all these
great scripting facilities were being added to the shell-- people stopped 
using the shell for scripting and moved to special scripting languages like
perl and python.

So, while I am a fan of the unix shell (and less of a fan of DCL but still
someone who appreciates DCL), I don't think most of the effort that has
gone into making a sophisticated command language has been of that much
use, since how people use the shell has changed.

That being the case, I would think it would be better to spend the effort
into getting better python integration for VMS than in souping up DCL.
(And I really don't like python at all... the indentation being syntax
reminds me far too much of JCL... but it's what everyone uses today.)
--scott
-- 
"C'est un Nagra. C'est suisse, et tres, tres precis."

[toc] | [prev] | [next] | [standalone]

#378331

On 12/6/2025 2:45 PM, Scott Dorsey wrote:
> Let me just say that as the Unix shell advanced from ssh through ksh and
> into modern bash (with some csh sidelines), at the same time that all these
> great scripting facilities were being added to the shell-- people stopped
> using the shell for scripting and moved to special scripting languages like
> perl and python.
> 
> So, while I am a fan of the unix shell (and less of a fan of DCL but still
> someone who appreciates DCL), I don't think most of the effort that has
> gone into making a sophisticated command language has been of that much
> use, since how people use the shell has changed.
> 
> That being the case, I would think it would be better to spend the effort
> into getting better python integration for VMS than in souping up DCL.

VMS Python already has quite some VMS integration.

https://wiki.vmssoftware.com/VMS-Specific_Python_Modules

I have always wanted something like:

dcl.init() # open pseudo terminal
res1 = dcl.do(command1) # send command to pseudo terminal and return output
...
resn = dcl.do(commandn) # send command to pseudo terminal and return output
dcl.close() # close pseudo terminal

Point being that reusing the same DCL process is better than
starting a new per command for certain things.

Arne

[toc] | [prev] | [next] | [standalone]

#378333

On 12/6/2025 3:23 PM, Arne Vajhøj wrote:
> I have always wanted something like:
> 
> dcl.init() # open pseudo terminal
> res1 = dcl.do(command1) # send command to pseudo terminal and return output
> ...
> resn = dcl.do(commandn) # send command to pseudo terminal and return output
> dcl.close() # close pseudo terminal
> 
> Point being that reusing the same DCL process is better than
> starting a new per command for certain things.

Example of DCL requiring same process:

the skipping N lines in COPY trick

$ open/read f z.txt
$ read f dummy
$ read f dummy
$ copy f zz.txt
$ close f

Arne

[toc] | [prev] | [next] | [standalone]

#378341

On 12/6/2025 3:47 PM, Arne Vajhøj wrote:
> On 12/6/2025 3:23 PM, Arne Vajhøj wrote:
>> I have always wanted something like:
>>
>> dcl.init() # open pseudo terminal
>> res1 = dcl.do(command1) # send command to pseudo terminal and return 
>> output
>> ...
>> resn = dcl.do(commandn) # send command to pseudo terminal and return 
>> output
>> dcl.close() # close pseudo terminal
>>
>> Point being that reusing the same DCL process is better than
>> starting a new per command for certain things.
> 
> Example of DCL requiring same process:
> 
> the skipping N lines in COPY trick
> 
> $ open/read f z.txt
> $ read f dummy
> $ read f dummy
> $ copy f zz.txt
> $ close f

Also possible to add lines:

$ open/write f zz.txt
$ write f "X"
$ write f "X"
$ copy z.txt f
$ close f

or if one want VAR not VFC:

$ create zz.txt
$
$ open/append f zz.txt
$ write f "X"
$ write f "X"
$ copy z.txt f
$ close f

Arne

[toc] | [prev] | [next] | [standalone]

#378342 — Re: [Info-vax] DCL2

On 12/6/2025 3:47 PM, Brian Schenkenberger wrote:
> On Dec 6, 2025, at 15:23, Arne Vajhøj via Info-vax <info-vax@rbnsn.com> 
> wrote:
>> I have always wanted something like:
>>
>> dcl.init() # open pseudo terminal
>> res1 = dcl.do(command1) # send command to pseudo terminal and return 
>> output
>> ...
>> resn = dcl.do(commandn) # send command to pseudo terminal and return 
>> output
>> dcl.close() # close pseudo terminal
> 
> PTD$ routines exist today.

I know.

>                                 However, you’d need a process with DCL mapped 
> connected
> with the pseudo-terminal to execute the command you pass to it.

I know.

>                                                                   You’d be 
> no better off
> than if you used a PIPE because that process is NOT the process for 
> which you may be
> seeking the information (ie. SHOW PROCESS).

That model would mean a Python process and a DCL process. A
process duo.

And yes that could be a problem in some cases.

But in most cases I would expect both to either not be
interested in processes or be interested in other processes
than themselves.

> I really had to bend over backward to have my DCL debugger work in/with 
> the current
> process because I wanted to be able to debug DCL in the process 
> environment where a
> problem may persent itself. (eg. quotas, rights, privileges, defaults, 
> etc.) Debugging DCL
> in a BATCH or NETWORK process was another goal. Debugging DCL in 
> environments
> that are NOT interactive are quite different and there are often 
> problems that the author
> doesn’t see until his|her procedure is executing in those environments.

DCL debugger is probably a bit different. It is by definition interested
in its own process. More difficult problem I think.

More advanced requirements means more advanced solution needed.

BTW, what is status of your DCL debugger? Commercial available?
Free available? Sitting on the shelf?

Arne

[toc] | [prev] | [next] | [standalone]

#378337

On 06/12/2025 19:45, Scott Dorsey wrote:
> Let me just say that as the Unix shell advanced from ssh through ksh and
> into modern bash (with some csh sidelines), at the same time that all these
> great scripting facilities were being added to the shell-- people stopped
> using the shell for scripting and moved to special scripting languages like
> perl and python.
> 
> So, while I am a fan of the unix shell (and less of a fan of DCL but still
> someone who appreciates DCL), I don't think most of the effort that has
> gone into making a sophisticated command language has been of that much
> use, since how people use the shell has changed.
> 
> That being the case, I would think it would be better to spend the effort
> into getting better python integration for VMS than in souping up DCL.
> (And I really don't like python at all... the indentation being syntax
> reminds me far too much of JCL... but it's what everyone uses today.)
> --scott

I think you will find it started with sh (aka the Bourne shell) rather 
than ssh!

-- 
Chris

[toc] | [prev] | [next] | [standalone]

#378338

Chris Townley  <news@cct-net.co.uk> wrote:
>
>I think you will find it started with sh (aka the Bourne shell) rather 
>than ssh!

I never said I could type accurately!
--scott
-- 
"C'est un Nagra. C'est suisse, et tres, tres precis."

[toc] | [prev] | [next] | [standalone]

#378348

In article <10h42ce$3g04g$1@dont-email.me>,
Chris Townley  <news@cct-net.co.uk> wrote:
>On 06/12/2025 19:45, Scott Dorsey wrote:
>> Let me just say that as the Unix shell advanced from ssh through ksh and
>> into modern bash (with some csh sidelines), at the same time that all these
>> great scripting facilities were being added to the shell-- people stopped
>> using the shell for scripting and moved to special scripting languages like
>> perl and python.
>> 
>> So, while I am a fan of the unix shell (and less of a fan of DCL but still
>> someone who appreciates DCL), I don't think most of the effort that has
>> gone into making a sophisticated command language has been of that much
>> use, since how people use the shell has changed.
>> 
>> That being the case, I would think it would be better to spend the effort
>> into getting better python integration for VMS than in souping up DCL.
>> (And I really don't like python at all... the indentation being syntax
>> reminds me far too much of JCL... but it's what everyone uses today.)
>
>I think you will find it started with sh (aka the Bourne shell) rather 
>than ssh!

I mean, if we want to split hairs, it started well before Bourne
was on the scene.  Thompson wrote a rudimentary shell that was
the default until Bourne came from the UK and did the 7th Ed
shell in pseudo-Algol 68.  :-)

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#378332 — Re: [Info-vax] DCL2

On 12/6/2025 12:14 PM, Brian Schenkenberger wrote:
> On Dec 6, 2025, at 10:57, Arne Vajhøj via Info-vax <info-vax@rbnsn.com> wrote:
>> On 12/6/2025 10:33 AM, Arne Vajhøj wrote:
>>> On 12/6/2025 5:42 AM, Marc Van Dyck wrote:
>>>> User written lexical functions, on the other hand, would be a real
>>>> bonus. There are, for one, still many parts of the operating system
>>>> for which you need to get information, and the only possible way to do
>>>> it is to parse some output (think of everything TCP/IP, for example),
>>>> while there is a callable interface available to get the info properly.
>>> Yes.
>>> And even though it is possible to run an exe that set a symbol
>>> with lib$set_symbol, then getting it as a lexical would make it
>>> more readable.
>>
>> Note that VSI could add it to existing DCL:
>>
>> f$udl(shrimg, arg1, ...)
>>
>> with a convention of entry point:
>>
>> int udl$function(int narg, enum dcl_type *argtyp, void *argval, enum dcl_typ *rettyp, void *retval)
>>
>> If they wanted to.
>>
>> New lexical functions have been added over time.
> 
> I'll try but likely a waste of time as my posts do not seem to make it through via the mailing list.

I got to the mail list, but none of the two news servers
I checked.

> Many years ago, I extended DCL with a lexical extension. I called it F$X. There was much talk
> at the time about being able to add site lexicals to DCL, so I did the grunt work to see if I could
> add such a mechanism. This fell out of my work on the DCL Debugger I was working on at the
> time.
> 
> IMNSHO, this is not a great idea. DCL programs will be written and shared, and people will not
> have the particular extended lexical code. What language will the extended code be written in
> if it is shared? C? What if a site doesn't possess a C compiler license?

It would be a generic VMS shareable image, VMS calling standard to
provide the capability.

People could make them in C or Pascal or Macro-32 or ...

If someone want to share some DCL and the source of the extension,
then recipient would need the relevant compiler.

But I think that is a fair restriction.

> If there’s something not available in DCL today that one believes would benefit by being called
> as if a lexical, it’s be better to simply write a program that can accept command line arguments
> via LIB$GET_FOREIGN, CLI$ and CLD definition, or a combination thereof with LIB$TPARSE
> and, if necessary, store results in a symbol.

That is and always have been a possibility.

Just not quite as elegant as a lexical function.

> Extensive programs written in DCL are slow! Sure, it’s easy to make quick edits and fixes, but
> DCL is not nor should it be considered a programming language like compiled languages.

That is definitely good advice.

But at least historically then programming in DCL has happened.

There is a book to prove it.

>                                                                                       I’d
> prefer to see, if something new were to be added, support for larger integer math (ie. 64 bit) is
> my request. Of course, it *is* possible now but takes some special effort to perform such math
> using F$fao() and the results really aren’t “integers” as far as DCL is concerned.

That could also be useful.

64 bit or go all the way aka unlimited (there are of course
practical limits)?

But that may require changes to real DCL.

I don't see a DCL pre-processor adding that. It could
add type declaration and store values as string.
Like PHP BC. But every operation would be something
externally. Performance would suck.

Arne

[toc] | [prev] | [next] | [standalone]

#378375

On Sat, 06 Dec 2025 11:42:47 +0100, Marc Van Dyck wrote:

> User written lexical functions, on the other hand, would be a real
> bonus. There are, for one, still many parts of the operating system for
> which you need to get information, and the only possible way to do it is
> to parse some output (think of everything TCP/IP, for example), while
> there is a callable interface available to get the info properly.

POSIXish shells seem to feel less need for such built-in extensions.

Is this a reflection on the ease of doing command substitutions in them, 
vis-à-vis DCL?

Some newer commands in the Linux world have the option to produce output 
in JSON format, which also helps.

[toc] | [prev] | [next] | [standalone]

#378376

Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> On Sat, 06 Dec 2025 11:42:47 +0100, Marc Van Dyck wrote:
> 
>> User written lexical functions, on the other hand, would be a real
>> bonus. There are, for one, still many parts of the operating system for
>> which you need to get information, and the only possible way to do it is
>> to parse some output (think of everything TCP/IP, for example), while
>> there is a callable interface available to get the info properly.
> 
> POSIXish shells seem to feel less need for such built-in extensions.
> 
> Is this a reflection on the ease of doing command substitutions in them, 
> vis-à-vis DCL?
> 
> Some newer commands in the Linux world have the option to produce output 
> in JSON format, which also helps.

First, backwards compatibility is a powerful force blocking
possible improvement.  I was using Sun OS and Solaris in
nineties.  Later I looked at Solaris from 2007.  In 2007
they shipped crappy '/bin/sh' which had exactly the same
problems as I remembered from my earlier use.  I suspect
that it was bug-for-bug compatible with '/bin/sh' which
they shipped in 1984.  And I suspect that if you get
current Solaris from Oracle, you will get the same crappy
'/bin/sh'.

The same forces that prevent improvments to '/bin/sh' work
for DCL, so chance of change here is very small.

Second, early Unix had relatively cheap process creation,
but some implementations (PDP-11 and 16-bit Xenix) had
thight limit on process size.  So, there was preference
to using external commands for extentions.  Unix provides
commands (and /proc filesystem in Linux) so that information
is available in textual form, meaning less need for
libraray API.

Third, Unix shell does not play as distingished role as
DCL in VMS, users can have different shells.  There are
scripting languages and for programming shell is just
one of available scripting languages.  Some scripting
languages (like Perl) give access to system calls, most
have FFI, so that one can call code in shared libraries.

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#378377

On Mon, 15 Dec 2025 01:51:47 -0000 (UTC), Waldek Hebisch wrote:

> First, backwards compatibility is a powerful force blocking possible
> improvement. I was using Sun OS and Solaris in nineties. Later I
> looked at Solaris from 2007. In 2007 they shipped crappy '/bin/sh'
> which had exactly the same problems as I remembered from my earlier
> use. I suspect that it was bug-for-bug compatible with '/bin/sh'
> which they shipped in 1984. And I suspect that if you get current
> Solaris from Oracle, you will get the same crappy '/bin/sh'.

It was quite common for Unix admins, back in the day, as soon as they
had set up a new machine, to install the GNU tools (bash etc) on it.
That way, you didn’t have to put up with the crappy, proprietary,
vendor-provided tools.

[toc] | [prev] | [next] | [standalone]

#378378

In article <10hnpjg$2648n$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:
>Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>> On Sat, 06 Dec 2025 11:42:47 +0100, Marc Van Dyck wrote:
>> 
>>> User written lexical functions, on the other hand, would be a real
>>> bonus. There are, for one, still many parts of the operating system for
>>> which you need to get information, and the only possible way to do it is
>>> to parse some output (think of everything TCP/IP, for example), while
>>> there is a callable interface available to get the info properly.
>> 
>> POSIXish shells seem to feel less need for such built-in extensions.
>> 
>> Is this a reflection on the ease of doing command substitutions in them, 
>> vis-à-vis DCL?
>> 
>> Some newer commands in the Linux world have the option to produce output 
>> in JSON format, which also helps.
>
>First, backwards compatibility is a powerful force blocking
>possible improvement.  I was using Sun OS and Solaris in
>nineties.  Later I looked at Solaris from 2007.  In 2007
>they shipped crappy '/bin/sh' which had exactly the same
>problems as I remembered from my earlier use.  I suspect
>that it was bug-for-bug compatible with '/bin/sh' which
>they shipped in 1984.  And I suspect that if you get
>current Solaris from Oracle, you will get the same crappy
>'/bin/sh'.

It is true that Solaris/illumos put large, perhaps almost
excessive, emphasis on stability and backwards compatibility.
However in this case, the criticism is a bit unfair.  As you
sort of alude below, on Unix systems, command interpreters are
interchangeable.  Both Solaris and illumos ship with multiple
shells, and the preference is to write scripts using ksh93, not
/bin/sh.  That said, I will grant you that it is annoying to
have to assume the subset of behavior defined by 7th Edition
research Unix for "portable" shell scripts, and increasingly
even that is tenuous on Linux systems.

>The same forces that prevent improvments to '/bin/sh' work
>for DCL, so chance of change here is very small.
>
>Second, early Unix had relatively cheap process creation,
>but some implementations (PDP-11 and 16-bit Xenix) had
>thight limit on process size.  So, there was preference
>to using external commands for extentions.  Unix provides
>commands (and /proc filesystem in Linux) so that information
>is available in textual form, meaning less need for
>libraray API.

Not only is there less need, it would have been rather difficult
in early Unix.  There was little sharing going on back then; I
think some of that was a reaction to the complexity of sharing
in Multics.  It took 20-ish years to get shared libraries, and
even then the model that won was based on TENEX and GENIE.

>Third, Unix shell does not play as distingished role as
>DCL in VMS, users can have different shells.  There are
>scripting languages and for programming shell is just
>one of available scripting languages.  Some scripting
>languages (like Perl) give access to system calls, most
>have FFI, so that one can call code in shared libraries.

Indeed.

However, I'll go out on a limb and say that, whatever the
limitations of DCL, Unix shells aren't particularly good
programming languages, and would be a bad model to emulate.
They spend too much effort trying to thread the needle between
being interactive command interpreters, with all of the rich UI
semantics that demands, _and_ being programming languages; in
areas where these conflict, the experience is usually mediocre
for both.

One feels that, in a sense, both Unix and VMS suffer from lack
of clear separation here, but on balance, VMS is probably better
suited to address that precisely because of the privileged
position of DCL in the overall system.  _If_ the user's state
were represented by well-defined objects with clear interfaces,
then one could imagine a programming language that would be
co-equal to a command interpreter, but that was _just_ a
language interpreter, and not a shell; the shell similarly would
be just a shell, and not a programming language interpreter.

By way of example, one might look to z/VM and CMS and the way
that REXX and XEDIT are integrated into the environment; REXX is
not a command interpreter, but one can easily write the
equivalent of shell scripts in it.  Similarly, XEDIT is a text
editor, but REXX scripts can "address", thus making it possible
to implement REXX programs with TUIs that leverage the
(considerable) power of the text editor.  The result is a
plethora of very rich, yet highly consistent, text-oriented
interfaces: the file and mail readers, the help system, etc.

Implementing this in a general way for a Unix-style system would
be, essentially, impossible.  And while it would be a heavy lift
for VMS, I imagine it would at least be possible.

Would it be worth it, though?  Particularly vis an incremental
improvement to the existing system?  I kind of doubt it.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#378382

In article <10hpdgu$1sb$1@reader2.panix.com>,
cross@spitfire.i.gajendra.net (Dan Cross) wrote:

> I will grant you that it is annoying to have to assume the subset 
> of behavior defined by 7th Edition research Unix for "portable" 
> shell scripts, and increasingly even that is tenuous on Linux systems.

Ubuntu's replacement of classic sh by the not-entirely-compatible dash
was a particular low point there. 

John 

[toc] | [prev] | [next] | [standalone]

#378383

On Mon, 15 Dec 2025 19:37 +0000 (GMT Standard Time), John Dallman wrote:

> Ubuntu's replacement of classic sh by the not-entirely-compatible
> dash was a particular low point there.

dash is meant to be a more strict and less feature-ridden
POSIX-compliant shell. It’s on Debian, too. So “/bin/sh” stopped
referring to bash years ago, and now uses dash instead.

From <https://manpages.debian.org/dash(1)>:

    dash is the standard command interpreter for the system. The
    current version of dash is in the process of being changed to
    conform with the POSIX 1003.2 and 1003.2a specifications for the
    shell. This version has many features which make it appear similar
    in some respects to the Korn shell, but it is not a Korn shell
    clone (see ksh(1)). Only features designated by POSIX, plus a few
    Berkeley extensions, are being incorporated into this shell. This
    man page is not intended to be a tutorial or a complete
    specification of the shell.

If you want /bin/bash, you say /bin/bash.

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.os.vms

csiph-web