On 2022-03-12, Scott Dorsey <kludge@panix.com> wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>On 2022-03-08, Dave Froble <davef@tsoft-inc.com> wrote:
>>>
>>> So, you were born with this knowledge about Linux?
>>>
>>> I do so dislike double standards ...
>>
>>Huh ????
>>
>>_WHAT_ double standards ?
>
> I think his argument is that you had to learn both Linux and VMS operations
> somewhere.
>

Like I said Scott, _what_ double standards ?

At no point have I claimed to have learnt something without reading
the documentation and Bill's argument seems to be that he found the
VMS documentation more difficult to read than the Unix documentation
he has used.

I don't know what Bill found to be confusing, but I can see some people
being confused by all the VMS-specific stuff such as a way over-complex
descriptor system, as well as the fact the documentation needs to be
written at a lower level than with the Unix documentation to deal with
all the exposed structures that in Unix are hidden behind call interfaces,
C structs, etc.

There's a strong argument for using a clean and simple descriptor setup
instead of null terminated strings. Unfortunately, the VMS descriptor
setup is neither clean or simple.

I can also only imagine what a newcomer to VMS would think if you have
to get them up to speed on the combined 32-bit/64-bit program executables
and how that compares to how cleaner what they are used to is.

> And I don't know about you, but I find the Gray Wall and associated tutorial
> manuals to be a lot better-written and more useful than the Linux man pages.
>

I see the man pages as a mixture of reference material and online help
(and vastly better than the VMS help, which is written for a ASR-33 user
input device, is chopped up into little pieces, has no built-in search
capability, etc).

There are also full searchable reference manuals for all the GNU components
(and some other components) shipped as part of Linux.

I can also find full public documentation for Linux for the things I am
not allowed to know about in VMS or cannot implement easily (such as how
to add a new filesystem to VMS or how to write a new CLI).

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Saturday, March 12, 2022 at 1:53:08 PM UTC-5, Simon Clubley wrote:
> On 2022-03-12, Scott Dorsey <klu...@panix.com> wrote:
> > Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> >>On 2022-03-08, Dave Froble <da...@tsoft-inc.com> wrote:
> >>>
> >>> So, you were born with this knowledge about Linux?
> >>>
> >>> I do so dislike double standards ...
> >>
> >>Huh ????
> >>
> >>_WHAT_ double standards ?
> >
> > I think his argument is that you had to learn both Linux and VMS operations
> > somewhere.
> >
>
> Like I said Scott, _what_ double standards ?
>
> At no point have I claimed to have learnt something without reading
> the documentation and Bill's argument seems to be that he found the
> VMS documentation more difficult to read than the Unix documentation
> he has used.
>
> I don't know what Bill found to be confusing, but I can see some people
> being confused by all the VMS-specific stuff such as a way over-complex
> descriptor system, as well as the fact the documentation needs to be
> written at a lower level than with the Unix documentation to deal with
> all the exposed structures that in Unix are hidden behind call interfaces,
> C structs, etc.
>
> There's a strong argument for using a clean and simple descriptor setup
> instead of null terminated strings. Unfortunately, the VMS descriptor
> setup is neither clean or simple.
>
> I can also only imagine what a newcomer to VMS would think if you have
> to get them up to speed on the combined 32-bit/64-bit program executables
> and how that compares to how cleaner what they are used to is.
>
> > And I don't know about you, but I find the Gray Wall and associated tutorial
> > manuals to be a lot better-written and more useful than the Linux man pages.
> >
>
> I see the man pages as a mixture of reference material and online help
> (and vastly better than the VMS help, which is written for a ASR-33 user
> input device, is chopped up into little pieces, has no built-in search
> capability, etc).
>
> There are also full searchable reference manuals for all the GNU components
> (and some other components) shipped as part of Linux.
>
> I can also find full public documentation for Linux for the things I am
> not allowed to know about in VMS or cannot implement easily (such as how
> to add a new filesystem to VMS or how to write a new CLI).
>
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

It seems to me that we need to differentiate between the documentation being difficult or the information documented being difficult. From your own posting you state that descriptors are difficult. OK (not to me but...) if that TOPIC is difficult, it has nothing to do with the documentation unless the explanation needs further edits to make it more clear. If the topic is difficult to understand, take a class and ask questions from someone that can provide other examples or walk you through it. Stating that the Linux/Unix stuff is better because it is hifdden behind easier interfaces, avoids the problem not solve it.

On 3/12/2022 1:53 PM, Simon Clubley wrote:
> I don't know what Bill found to be confusing, but I can see some people
> being confused by all the VMS-specific stuff such as a way over-complex
> descriptor system,

The use of descriptors is hidden for those programming in enough high
level languages: Pascal, Fortran, Cobol, Basic etc.. It can hardly
get any simpler than that.

Those programming in and Macro-32 need to know that they are sending
over type, length and address. Not particular complex. If they can't
grasp that concept then I don't think they will get far on those
languages.

OK. There is an ugly side to descriptors - when one goes outside
simple fixed length or variable length strings, then it can become
tricky. But that is extremely rare and usually only happens
for some advanced language interop problems.

> as well as the fact the documentation needs to be
> written at a lower level than with the Unix documentation to deal with
> all the exposed structures that in Unix are hidden behind call interfaces,
> C structs, etc.

There is nothing low level in sending over complex structures instead
of simple data types. Almost all modern API's does that (it is just
called an object!).

> There's a strong argument for using a clean and simple descriptor setup
> instead of null terminated strings. Unfortunately, the VMS descriptor
> setup is neither clean or simple.

I can't see what can be omitted in descriptors for single strings.

> I can also only imagine what a newcomer to VMS would think if you have
> to get them up to speed on the combined 32-bit/64-bit program executables
> and how that compares to how cleaner what they are used to is.

Co-existance of 32 and 64 bit pointers can be a hassle.

But hopefully not that many newcomers to VMS will have to deal with that.

> There are also full searchable reference manuals for all the GNU components
> (and some other components) shipped as part of Linux.

It could be useful to supplement the tree structure of VMS help with a
search capability.

> I can also find full public documentation for Linux for the things I am
> not allowed to know about in VMS or cannot implement easily (such as how
> to add a new filesystem to VMS or how to write a new CLI).

There are way more documentation available for Linux than for VMS.

Because there are simply way more developers of Linux.

That is how the world is.

Arne

On 03/12/22 18:53, Simon Clubley wrote:
> On 2022-03-12, Scott Dorsey<kludge@panix.com> wrote:
>> Simon Clubley<clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>> On 2022-03-08, Dave Froble<davef@tsoft-inc.com> wrote:
>>>>
>>>> So, you were born with this knowledge about Linux?
>>>>
>>>> I do so dislike double standards ...
>>>
>>> Huh ????
>>>
>>> _WHAT_ double standards ?
>>
>> I think his argument is that you had to learn both Linux and VMS operations
>> somewhere.
>>
>
> Like I said Scott, _what_ double standards ?
>
> At no point have I claimed to have learnt something without reading
> the documentation and Bill's argument seems to be that he found the
> VMS documentation more difficult to read than the Unix documentation
> he has used.
>
> I don't know what Bill found to be confusing, but I can see some people
> being confused by all the VMS-specific stuff such as a way over-complex
> descriptor system, as well as the fact the documentation needs to be
> written at a lower level than with the Unix documentation to deal with
> all the exposed structures that in Unix are hidden behind call interfaces,
> C structs, etc.
>
> There's a strong argument for using a clean and simple descriptor setup
> instead of null terminated strings. Unfortunately, the VMS descriptor
> setup is neither clean or simple.
>
> I can also only imagine what a newcomer to VMS would think if you have
> to get them up to speed on the combined 32-bit/64-bit program executables
> and how that compares to how cleaner what they are used to is.
>
>> And I don't know about you, but I find the Gray Wall and associated tutorial
>> manuals to be a lot better-written and more useful than the Linux man pages.
>>
>
> I see the man pages as a mixture of reference material and online help
> (and vastly better than the VMS help, which is written for a ASR-33 user
> input device, is chopped up into little pieces, has no built-in search
> capability, etc).
>
> There are also full searchable reference manuals for all the GNU components
> (and some other components) shipped as part of Linux.
>
> I can also find full public documentation for Linux for the things I am
> not allowed to know about in VMS or cannot implement easily (such as how
> to add a new filesystem to VMS or how to write a new CLI).
>
> Simon.
>

It's a while since I used the grey wall, but to be fair, all the info
was there, it's just wasn't organised in a way that made things easy
to find. I remember doing some serial comms work years ago and needed
to consult 3 or 4 volumes to find the info, bits of which were
distributed across all of them. System service calls can be a bit
arcane as well, though that's probably just a matter of familiarity.

Compare that to the unix approach. Originally just a set of runoff
pages, very much on your own, but the methodology, ways and means of
accessing information, have changed. For example, plugin fopen() to a
search engine and you get dozens of the basic man page descriptions,
but also a range of pages with code snippets illustrating usage.
Much faster way to get productive. Solve the problem, not get bogged
down trying to find the information...

Chris

In article <622cf1b9$0$703$14726298@news.sunsite.dk>, =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>On 3/12/2022 1:53 PM, Simon Clubley wrote:
>> I don't know what Bill found to be confusing, but I can see some people
>> being confused by all the VMS-specific stuff such as a way over-complex
>> descriptor system,
>
>The use of descriptors is hidden for those programming in enough high
>level languages: Pascal, Fortran, Cobol, Basic etc.. It can hardly
>get any simpler than that.
>
>Those programming in and Macro-32 need to know that they are sending
>over type, length and address. Not particular complex. If they can't
>grasp that concept then I don't think they will get far on those
>languages.

CLRL -(SP) ;dynamic; dsc$a_pointer
PUSHL #<DSC$K_CLASS_D@<DSC$B_CLASS@TOBITS>>!- ; dsc$b_class
<DSC$K_DTYPE_T@<DSC$B_DTYPE@TOBITS>> ; dsc$b_type

I just build dynamic descriptors on the stack and let VMS allocate for
me the storage for the data.

>OK. There is an ugly side to descriptors - when one goes outside
>simple fixed length or variable length strings, then it can become
>tricky. But that is extremely rare and usually only happens
>for some advanced language interop problems.

There a uniform definition for myriad generic structures that descriptors
entail beyond simple strings, but Simon just likes to hear himself bitch
and believes we want to as well.

>> as well as the fact the documentation needs to be
>> written at a lower level than with the Unix documentation to deal with
>> all the exposed structures that in Unix are hidden behind call interfaces,
>> C structs, etc.
>
>There is nothing low level in sending over complex structures instead
>of simple data types. Almost all modern API's does that (it is just
>called an object!).

;)

Simon isn't happy unless it's littered with lots of "squigglies", typedefs,
and other C eunuchisms.

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

I speak to machines with the voice of humanity.

On 2022-03-12, abrsvc <dansabrservices@yahoo.com> wrote:
>
> It seems to me that we need to differentiate between the documentation being difficult or the information documented being difficult. From your own posting you state that descriptors are difficult. OK (not to me but...) if that TOPIC is difficult, it has nothing to do with the documentation unless the explanation needs further edits to make it more clear. If the topic is difficult to understand, take a class and ask questions from someone that can provide other examples or walk you through it. Stating that the Linux/Unix stuff is better because it is hifdden behind easier interfaces, avoids the problem not solve it.

I don't find VMS descriptors difficult because I have been used to them
since the 1990s. However, they are complex with all the variants they
offer and I can easily see newcomers being overwhelmed by the mass of
detail while getting used to the rest of VMS at the same time.

Try to consider, as a VMS person, being asked to learn how to work with
z/OS and write software for it. An experienced z/OS person will not have
a problem because they are used to it. A newcomer to z/OS, OTOH, will see
all the strange new concepts and ways of doing things that they have never
encountered before and could easily be lost in a mass of detail.

That feeling is exactly the same feeling that people new to VMS could
easily feel when they are exposed to an operating system with concepts
and ways of doing things they have never seen before.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-03-13, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
> In article <622cf1b9$0$703$14726298@news.sunsite.dk>, =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>>On 3/12/2022 1:53 PM, Simon Clubley wrote:
>>> I don't know what Bill found to be confusing, but I can see some people
>>> being confused by all the VMS-specific stuff such as a way over-complex
>>> descriptor system,
>>
>>The use of descriptors is hidden for those programming in enough high
>>level languages: Pascal, Fortran, Cobol, Basic etc.. It can hardly
>>get any simpler than that.
>>
>>Those programming in and Macro-32 need to know that they are sending
>>over type, length and address. Not particular complex. If they can't
>>grasp that concept then I don't think they will get far on those
>>languages.
>
> CLRL -(SP) ;dynamic; dsc$a_pointer
> PUSHL #<DSC$K_CLASS_D@<DSC$B_CLASS@TOBITS>>!- ; dsc$b_class
> <DSC$K_DTYPE_T@<DSC$B_DTYPE@TOBITS>> ; dsc$b_type
>
> I just build dynamic descriptors on the stack and let VMS allocate for
> me the storage for the data.
>

And you sound exactly like the experienced z/OS programmer used to
doing things in z/OS assembly language and wondering why newcomers
to z/OS can't just do the same thing.

>
>
>>OK. There is an ugly side to descriptors - when one goes outside
>>simple fixed length or variable length strings, then it can become
>>tricky. But that is extremely rare and usually only happens
>>for some advanced language interop problems.
>
> There a uniform definition for myriad generic structures that descriptors
> entail beyond simple strings, but Simon just likes to hear himself bitch
> and believes we want to as well.
>

Tell me Brian, am I living rent-free in your head ? :-)

It certainly sounds like it...

>
>
>>> as well as the fact the documentation needs to be
>>> written at a lower level than with the Unix documentation to deal with
>>> all the exposed structures that in Unix are hidden behind call interfaces,
>>> C structs, etc.
>>
>>There is nothing low level in sending over complex structures instead
>>of simple data types. Almost all modern API's does that (it is just
>>called an object!).
>
> ;)
>
> Simon isn't happy unless it's littered with lots of "squigglies", typedefs,
> and other C eunuchisms.
>

You mean the stuff that abstracts away implementation details so that
you can write portable code that you can more easily move between
architectures and different bit sized environments without having to
rewrite the whole thing ? :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 3/14/22 09:58, Simon Clubley wrote:
> On 2022-03-12, abrsvc <dansabrservices@yahoo.com> wrote:
>>
>> It seems to me that we need to differentiate between the documentation being difficult or the information documented being difficult. From your own posting you state that descriptors are difficult. OK (not to me but...) if that TOPIC is difficult, it has nothing to do with the documentation unless the explanation needs further edits to make it more clear. If the topic is difficult to understand, take a class and ask questions from someone that can provide other examples or walk you through it. Stating that the Linux/Unix stuff is better because it is hifdden behind easier interfaces, avoids the problem not solve it.
>
> I don't find VMS descriptors difficult because I have been used to them
> since the 1990s. However, they are complex with all the variants they
> offer and I can easily see newcomers being overwhelmed by the mass of
> detail while getting used to the rest of VMS at the same time.
>
> Try to consider, as a VMS person, being asked to learn how to work with
> z/OS and write software for it. An experienced z/OS person will not have
> a problem because they are used to it. A newcomer to z/OS, OTOH, will see
> all the strange new concepts and ways of doing things that they have never
> encountered before and could easily be lost in a mass of detail.
>

Not really. I hadn't touched an IBM Mainframe since the DOS/E VM370
days and had no problem doing the challenges on the Mastering the
Mainframe program just a couple weeks ago. The hardest parts had to
do with stuff they use that runs on Linux. All the z/OS stuff was a
piece of cake.

> That feeling is exactly the same feeling that people new to VMS could
> easily feel when they are exposed to an operating system with concepts
> and ways of doing things they have never seen before.

I still think learning VMS is harder. I don't think it needs to be, but
it is.

bill

On 3/14/22 10:03, Simon Clubley wrote:
> On 2022-03-13, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>> In article <622cf1b9$0$703$14726298@news.sunsite.dk>, =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>>> On 3/12/2022 1:53 PM, Simon Clubley wrote:
>>>> I don't know what Bill found to be confusing, but I can see some people
>>>> being confused by all the VMS-specific stuff such as a way over-complex
>>>> descriptor system,
>>>
>>> The use of descriptors is hidden for those programming in enough high
>>> level languages: Pascal, Fortran, Cobol, Basic etc.. It can hardly
>>> get any simpler than that.
>>>
>>> Those programming in and Macro-32 need to know that they are sending
>>> over type, length and address. Not particular complex. If they can't
>>> grasp that concept then I don't think they will get far on those
>>> languages.
>>
>> CLRL -(SP) ;dynamic; dsc$a_pointer
>> PUSHL #<DSC$K_CLASS_D@<DSC$B_CLASS@TOBITS>>!- ; dsc$b_class
>> <DSC$K_DTYPE_T@<DSC$B_DTYPE@TOBITS>> ; dsc$b_type
>>
>> I just build dynamic descriptors on the stack and let VMS allocate for
>> me the storage for the data.
>>
>
> And you sound exactly like the experienced z/OS programmer used to
> doing things in z/OS assembly language and wondering why newcomers
> to z/OS can't just do the same thing.
>
>>
>>
>>> OK. There is an ugly side to descriptors - when one goes outside
>>> simple fixed length or variable length strings, then it can become
>>> tricky. But that is extremely rare and usually only happens
>>> for some advanced language interop problems.
>>
>> There a uniform definition for myriad generic structures that descriptors
>> entail beyond simple strings, but Simon just likes to hear himself bitch
>> and believes we want to as well.
>>
>
> Tell me Brian, am I living rent-free in your head ? :-)
>
> It certainly sounds like it...
>
>>
>>
>>>> as well as the fact the documentation needs to be
>>>> written at a lower level than with the Unix documentation to deal with
>>>> all the exposed structures that in Unix are hidden behind call interfaces,
>>>> C structs, etc.
>>>
>>> There is nothing low level in sending over complex structures instead
>>> of simple data types. Almost all modern API's does that (it is just
>>> called an object!).
>>
>> ;)
>>
>> Simon isn't happy unless it's littered with lots of "squigglies", typedefs,
>> and other C eunuchisms.
>>
>
> You mean the stuff that abstracts away implementation details so that
> you can write portable code that you can more easily move between
> architectures and different bit sized environments without having to
> rewrite the whole thing ? :-)

Ah... There's the rub...

It seems that VMS people want to continue to live in the 70's where
job security meant writing code that could not be easily understood
and certainly couldn't be moved (easily or otherwise) to a different
architecture or even OS.

bill

On 2022-03-13 01:12:37 +0000, chris said:

> It's a while since I used the grey wall, but to be fair, all the info
> was there, it's just wasn't organised in a way that made things easy to
> find. I remember doing some serial comms work years ago and needed to
> consult 3 or 4 volumes to find the info, bits of which were distributed
> across all of them. System service calls can be a bit arcane as well,
> though that's probably just a matter of familiarity.

Descriptors and system services are arcane, and with lots of glue code
in languages without built-in support. And often with glue code, even
in those languages with better support.

Navigation in the current OpenVMS documentation needs help, and the
availability of recipes—what used to be in TIMA/STARS and what was once
accessible via AskQ and ilk—are lacking. The OpenVMS doc is old,
piecemeal, and in need of an overhaul and updates.

As examples of gaps in the current OpenVMS documentation: writing
secure apps, data security, and network security applications. There
are others. VSI is aware of these gaps, and has a support database
replacement presently being populated. When the product support team
can't find an existing recipe or existing example to send to a
customer, they presumably write one anew, and add it to the database.
This all takes time and effort. Substantive other work here awaits, too.

One longer-term downside of providing these source code examples is
that any bugs or issues or limits tend to spread widely, should those
arise in any examples. And these are easy mistakes to make, whether
around error handling or data security, or otherwise. Which means
abstracting this code can be preferable (remove the glue code, and
improve the APIs), whether it's moving descriptors into objects, or
providing better-abstracted APIs for the most commonly employed source
code recipe sequences. The existing SYS$EXAMPLES and related code
examples have (or had) source build issues, too.

Examples of gaps here include networking (IP, DNS, TLS, etc) and the
network security APIs, and pretty much all of ACME—ACME is a massively
flexible design, but also sometimes subtle and difficult to correctly
use for common operations. There are others. All of this really needs
to be better abstracted, and incorporated into the platform.

Descriptors were a nice idea in 1978 too, but expectations have
changed. C and C++ could have used better abstractions for dealing with
descriptors too, but C and C++ extensions for descriptors seems rather
less than worthwhile in 2025. And the typical replacement of adding
message-passing enhancements is a far investment in the run-time and in
the compilers generally, and well beyond the existing and required
compiler work that is already critical path development work for VSI.

> Compare that to the unix approach. Originally just a set of runoff
> pages, very much on your own, but the methodology, ways and means of
> accessing information, have changed. For example, plugin fopen() to a
> search engine and you get dozens of the basic man page descriptions,
> but also a range of pages with code snippets illustrating usage. Much
> faster way to get productive. Solve the problem, not get bogged down
> trying to find the information...

With apps such as Dash, too. https://kapeli.com/dash

Getting system services and other OpenVMS reference materials into
formats available for inclusion into these or similar tools is another
project.

The built-in documentation tags increasingly available in various
tooling is making source code easier to document, as well. This isn't a
new idea, what with Doxygen, and as OpenVMS itself generates some
documentation from source code. (For generating error messages and
recovery documentation, see GNM on the OpenVMS freeware.)

But for now and for the next year or three, VSI is occupied getting
OpenVMS x86-64 stable and working and shipping. Which can and is and
should be the priority.

--
Pure Personal Opinion | HoffmanLabs LLC

In article <t0ni03$8a0$2@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>{...snip...}
>
>You mean the stuff that abstracts away implementation details so that
>you can write portable code that you can more easily move between
>architectures and different bit sized environments without having to
>rewrite the whole thing ? :-)

If it was truly portable, it wouldn't need "#ifdef <some arch> #endif"s.

I work on VMS so I have no need to have things work on zOS or *ix or M$DOS
or WEENDOZE. If only Apple could have figured out a way to have old 32 bit
apps run on their latest OSX. Maybe you should go proselytize to the Apple
fanbois about portability.

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

I speak to machines with the voice of humanity.

On 2022-03-12, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 3/12/2022 1:53 PM, Simon Clubley wrote:
>> as well as the fact the documentation needs to be
>> written at a lower level than with the Unix documentation to deal with
>> all the exposed structures that in Unix are hidden behind call interfaces,
>> C structs, etc.
>
> There is nothing low level in sending over complex structures instead
> of simple data types. Almost all modern API's does that (it is just
> called an object!).
>

RMS, Arne, RMS. In any sane environment, that's how it would be implemented
behind the scenes in a OO language or behind a subroutine interface in C
instead of being something that the user would have to directly manipulate.

Also itemlists and having to specify every bit of information you want
along with where to store it, instead of just returning an object (or a
struct) containing all available fields and your program just referencing
what it needs.

Also, in Unix (thanks to C being the lowest supported language), pointers
are an abstraction that the compiler deals with behind the scenes for you
when it comes time to store them away and pass them around. In VMS,
traditional pointers are an unabstracted and direcly exposed longword
field that cannot just be automatically resized by passing "-m64" or
similar on the compiler command line.

Just some examples off the top of my head.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 3/14/22 14:48, Simon Clubley wrote:
>
>
> Also, in Unix (thanks to C being the lowest supported language)

Every Unix I have ever used supported native assembler. I think that
qualifies as lower. Or don't you consider assembler as a language?

bill

On 2022-03-14, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
> On 3/14/22 09:58, Simon Clubley wrote:
>>
>> Try to consider, as a VMS person, being asked to learn how to work with
>> z/OS and write software for it. An experienced z/OS person will not have
>> a problem because they are used to it. A newcomer to z/OS, OTOH, will see
>> all the strange new concepts and ways of doing things that they have never
>> encountered before and could easily be lost in a mass of detail.
>>
>
> Not really. I hadn't touched an IBM Mainframe since the DOS/E VM370
> days and had no problem doing the challenges on the Mastering the
> Mainframe program just a couple weeks ago. The hardest parts had to
> do with stuff they use that runs on Linux. All the z/OS stuff was a
> piece of cake.
>

Yes, but you clearly had prior experience and conceptual knowledge which
helped you. Many people these days simply don't have any prior knowledge
or even understanding of such things.

For example, consider that you have programmed in DEC Basic all your life
and then you have a C++ manual dumped in front of you and told that's what
you need to get up to speed on because that's what you will be using from
now on.

That's how different VMS would feel to someone who had only ever used Linux
and Windows and had absolutely no idea of the concepts behind VMS.

>> That feeling is exactly the same feeling that people new to VMS could
>> easily feel when they are exposed to an operating system with concepts
>> and ways of doing things they have never seen before.
>
> I still think learning VMS is harder. I don't think it needs to be, but
> it is.
>

Do you have any specific examples why you think this is ?

Is it the lack of tutorial material ?

Overwhelming levels of detail in the documentation ?

Not enough reading guides about what trails to follow through the
documentation for various tasks ? (Or the fact that such trails don't
appear to exist for VMS ?)

For anyone interested, here's the trail for the Java Reflection functionality:

https://docs.oracle.com/javase/tutorial/reflect/index.html

It contains a mixture of tutorial/conceptual material along with links to
detailed reference material and includes code examples. That's the kind of
thing people expect these days and which is sorely lacking in the VMS
documentation set.

There's no point having a lot of documentation if you don't have task
orientated guides and tutorials to help you understand and navigate it.
That's how people get lost in a mass of detail.

Here's the main Java tutorial page:

https://docs.oracle.com/javase/tutorial/index.html

VMS badly needs task orientated guides like that as part of the
documentation set. Spending silly time wading through the documentation
set and gradually assembling clues to the pieces of knowledge you need
is not an acceptable approach these days.

The closest VMS comes are things like the programming concepts manuals
which jump in way too deeply way too quickly for any absolute newcomers
to VMS. None of us here would have any problems at all understanding the
material in those manuals if we wanted to learn a part of VMS that we
had not previously used, but we are not the kind of people that such
manuals should be written for these days.

At a minimum, there needs to be the kind of trail-based documentation
I have pointed to above as part of the VMS documentation set.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-03-14, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
> On 3/14/22 14:48, Simon Clubley wrote:
>>
>>
>> Also, in Unix (thanks to C being the lowest supported language)
>
> Every Unix I have ever used supported native assembler. I think that
> qualifies as lower. Or don't you consider assembler as a language?
>

We had this discussion recently. On Unix, once outside of the very
lowest and localised parts of the kernel, that's generally confined
to compiler generated code and _very_ specialist bits of asm inserts
to (for example) get to CPU-specific registers that you cannot get
to from within C.

In Unix, there's nothing like the assembler friendly (but portable
horrible) API interfaces you get in VMS and that's a _really_ good thing.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 3/14/2022 2:48 PM, Simon Clubley wrote:
> On 2022-03-12, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 3/12/2022 1:53 PM, Simon Clubley wrote:
>>> as well as the fact the documentation needs to be
>>> written at a lower level than with the Unix documentation to deal with
>>> all the exposed structures that in Unix are hidden behind call interfaces,
>>> C structs, etc.
>>
>> There is nothing low level in sending over complex structures instead
>> of simple data types. Almost all modern API's does that (it is just
>> called an object!).
>
> RMS, Arne, RMS. In any sane environment, that's how it would be implemented
> behind the scenes in a OO language or behind a subroutine interface in C
> instead of being something that the user would have to directly manipulate.

Block, record, struct, object are really the same.

An object can provide a little extra encapsulation by having private
fields and public accessors and mutators, but that is just icing on
the cake.

RMS blocks is really the modern way.

> Also itemlists and having to specify every bit of information you want
> along with where to store it, instead of just returning an object (or a
> struct) containing all available fields and your program just referencing
> what it needs.

Item lists are a relative low level construct, but also only used
in low level calls SYS$ not LIB$.

It is easy to do better with a language supporting
maps/dictionaries/associative arrays and garbage collection.

But doing it memory and CPU efficient, non memory leaking and
binary upgradeable way is not easy in C or similar languages.

I believe something like the following is rather common:

typedef void *CTX;
....
CTX ctx;
foobar_init(&ctx);
foobar_something(&ctx);
foobar_cleanup(&ctx);

It may end up being easier to split the one function in a hundred
functions.

Which would have had a performance impact 40 years ago.

> Also, in Unix (thanks to C being the lowest supported language), pointers
> are an abstraction that the compiler deals with behind the scenes for you
> when it comes time to store them away and pass them around. In VMS,
> traditional pointers are an unabstracted and direcly exposed longword
> field that cannot just be automatically resized by passing "-m64" or
> similar on the compiler command line.

That is a not really a block problem.

If DEC had decided to go only 64 bit pointers on Alpha 30 years ago,
then the block definitions could have had 64 bit address fields
in blocks on Alpha and Itanium.

But they did not. For many reasons.

Arne

On 2022-03-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 3/14/2022 2:48 PM, Simon Clubley wrote:
>> Also, in Unix (thanks to C being the lowest supported language), pointers
>> are an abstraction that the compiler deals with behind the scenes for you
>> when it comes time to store them away and pass them around. In VMS,
>> traditional pointers are an unabstracted and direcly exposed longword
>> field that cannot just be automatically resized by passing "-m64" or
>> similar on the compiler command line.
>
> That is a not really a block problem.
>

It is when you can't compile your RMS program (for example) to fully
use a 64-bit address space by simply using a compiler switch when you
recompile the programs without needing to make any user source code changes.

> If DEC had decided to go only 64 bit pointers on Alpha 30 years ago,
> then the block definitions could have had 64 bit address fields
> in blocks on Alpha and Itanium.
>
> But they did not. For many reasons.
>

Yes, because when VMS was designed it had to work with a certain language
which does not have an abstracted pointer size concept where the
implementation details are mostly hidden from the user's source code.

There are some things that Unix from that era did not get right (null
terminated strings being the main example), but the use of a HLL instead
of assembly language was the one thing that it did get right.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 3/14/22 15:30, Simon Clubley wrote:
> On 2022-03-14, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 3/14/22 09:58, Simon Clubley wrote:
>>>
>>> Try to consider, as a VMS person, being asked to learn how to work with
>>> z/OS and write software for it. An experienced z/OS person will not have
>>> a problem because they are used to it. A newcomer to z/OS, OTOH, will see
>>> all the strange new concepts and ways of doing things that they have never
>>> encountered before and could easily be lost in a mass of detail.
>>>
>>
>> Not really. I hadn't touched an IBM Mainframe since the DOS/E VM370
>> days and had no problem doing the challenges on the Mastering the
>> Mainframe program just a couple weeks ago. The hardest parts had to
>> do with stuff they use that runs on Linux. All the z/OS stuff was a
>> piece of cake.
>>
>
> Yes, but you clearly had prior experience and conceptual knowledge which
> helped you. Many people these days simply don't have any prior knowledge
> or even understanding of such things.

Do you really think there is any similarity between DOS/E on a 4331
running VM/370 40 years ago and a current zSystem run z/OS? You really
have no knowledge of Big Blue, do you?

>
> For example, consider that you have programmed in DEC Basic all your life
> and then you have a C++ manual dumped in front of you and told that's what
> you need to get up to speed on because that's what you will be using from
> now on.

Been there, done that. Took the Jensen and Wirth "Users Manual and
Report" with me on vacation and learned Pascal in two weeks.

>
> That's how different VMS would feel to someone who had only ever used Linux
> and Windows and had absolutely no idea of the concepts behind VMS.
>
>>> That feeling is exactly the same feeling that people new to VMS could
>>> easily feel when they are exposed to an operating system with concepts
>>> and ways of doing things they have never seen before.
>>
>> I still think learning VMS is harder. I don't think it needs to be, but
>> it is.
>>
>
> Do you have any specific examples why you think this is ?
>
> Is it the lack of tutorial material ?
>
> Overwhelming levels of detail in the documentation ?

I just find the explanations to be poor. I find it very difficult
to find things I need in the documentation. But that could just
be me. :-)

>
> Not enough reading guides about what trails to follow through the
> documentation for various tasks ? (Or the fact that such trails don't
> appear to exist for VMS ?)
>
> For anyone interested, here's the trail for the Java Reflection functionality:
>
> https://docs.oracle.com/javase/tutorial/reflect/index.html
>
> It contains a mixture of tutorial/conceptual material along with links to
> detailed reference material and includes code examples. That's the kind of
> thing people expect these days and which is sorely lacking in the VMS
> documentation set.
>
> There's no point having a lot of documentation if you don't have task
> orientated guides and tutorials to help you understand and navigate it.
> That's how people get lost in a mass of detail.
>
> Here's the main Java tutorial page:
>
> https://docs.oracle.com/javase/tutorial/index.html

There are enough third party books on Java it is unlikely I would
ever look at any of that. And I didn't when learning Java,

>
> VMS badly needs task orientated guides like that as part of the
> documentation set. Spending silly time wading through the documentation
> set and gradually assembling clues to the pieces of knowledge you need
> is not an acceptable approach these days.
>
> The closest VMS comes are things like the programming concepts manuals
> which jump in way too deeply way too quickly for any absolute newcomers
> to VMS. None of us here would have any problems at all understanding the
> material in those manuals if we wanted to learn a part of VMS that we
> had not previously used, but we are not the kind of people that such
> manuals should be written for these days.
>
> At a minimum, there needs to be the kind of trail-based documentation
> I have pointed to above as part of the VMS documentation set.

If I had to state an opinion, it would be that the documentation seems
to me to assume to much pre-knowledge on the part of the reader. It
assumes one is already an experienced professional with experience using
VMS and therefore no clarifications are necessary. But, again, that
could be just me.

bill

On 2022-03-14, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
> On 3/14/22 15:30, Simon Clubley wrote:
>> On 2022-03-14, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>> On 3/14/22 09:58, Simon Clubley wrote:
>>>>
>>>> Try to consider, as a VMS person, being asked to learn how to work with
>>>> z/OS and write software for it. An experienced z/OS person will not have
>>>> a problem because they are used to it. A newcomer to z/OS, OTOH, will see
>>>> all the strange new concepts and ways of doing things that they have never
>>>> encountered before and could easily be lost in a mass of detail.
>>>>
>>>
>>> Not really. I hadn't touched an IBM Mainframe since the DOS/E VM370
>>> days and had no problem doing the challenges on the Mastering the
>>> Mainframe program just a couple weeks ago. The hardest parts had to
>>> do with stuff they use that runs on Linux. All the z/OS stuff was a
>>> piece of cake.
>>>
>>
>> Yes, but you clearly had prior experience and conceptual knowledge which
>> helped you. Many people these days simply don't have any prior knowledge
>> or even understanding of such things.
>
> Do you really think there is any similarity between DOS/E on a 4331
> running VM/370 40 years ago and a current zSystem run z/OS? You really
> have no knowledge of Big Blue, do you?
>

My IBM knowledge is mainly MVS 3.8 (obviously!) and some modern z/OS.
Even from the MVS 3.8 days, there's enough in there to give you a jump
start with getting up to speed with how modern z/OS works.

The hardware doesn't really matter in this case. It's the mindset and
general way of doing things that really matters.

In the DEC world, because of its origins, you can use RSX to help understand
some of the core VMS concepts. Hell, even some of the PDP-11 userland tools
are mostly the same regardless of which underlying PDP-11 operating system
they are running on.

>>
>> For example, consider that you have programmed in DEC Basic all your life
>> and then you have a C++ manual dumped in front of you and told that's what
>> you need to get up to speed on because that's what you will be using from
>> now on.
>
> Been there, done that. Took the Jensen and Wirth "Users Manual and
> Report" with me on vacation and learned Pascal in two weeks.
>

Pascal's a little easier to learn than C++. :-)

>>
>> That's how different VMS would feel to someone who had only ever used Linux
>> and Windows and had absolutely no idea of the concepts behind VMS.
>>
>>>> That feeling is exactly the same feeling that people new to VMS could
>>>> easily feel when they are exposed to an operating system with concepts
>>>> and ways of doing things they have never seen before.
>>>
>>> I still think learning VMS is harder. I don't think it needs to be, but
>>> it is.
>>>
>>
>> Do you have any specific examples why you think this is ?
>>
>> Is it the lack of tutorial material ?
>>
>> Overwhelming levels of detail in the documentation ?
>
> I just find the explanations to be poor. I find it very difficult
> to find things I need in the documentation. But that could just
> be me. :-)
>

Not really. See below.

>>
>> Not enough reading guides about what trails to follow through the
>> documentation for various tasks ? (Or the fact that such trails don't
>> appear to exist for VMS ?)
>>
>> For anyone interested, here's the trail for the Java Reflection functionality:
>>
>> https://docs.oracle.com/javase/tutorial/reflect/index.html
>>
>> It contains a mixture of tutorial/conceptual material along with links to
>> detailed reference material and includes code examples. That's the kind of
>> thing people expect these days and which is sorely lacking in the VMS
>> documentation set.
>>
>> There's no point having a lot of documentation if you don't have task
>> orientated guides and tutorials to help you understand and navigate it.
>> That's how people get lost in a mass of detail.
>>
>> Here's the main Java tutorial page:
>>
>> https://docs.oracle.com/javase/tutorial/index.html
>
> There are enough third party books on Java it is unlikely I would
> ever look at any of that. And I didn't when learning Java,
>

Neither did I when learning Java in general. However, I did use it
to learn how to use Reflection (which was an entirely new concept to me
for Java) and I found the material to be well written, pitched at just
the right level for an otherwise experienced programmer, and gave me
all the pointers I needed to jump into the reference manuals once
I understood how the concepts worked on Java.

It was massively better than trying to manually pull together the pieces
from the documentation and VMS could seriously do with material along
those lines as part of the documentation set.

>>
>> VMS badly needs task orientated guides like that as part of the
>> documentation set. Spending silly time wading through the documentation
>> set and gradually assembling clues to the pieces of knowledge you need
>> is not an acceptable approach these days.
>>
>> The closest VMS comes are things like the programming concepts manuals
>> which jump in way too deeply way too quickly for any absolute newcomers
>> to VMS. None of us here would have any problems at all understanding the
>> material in those manuals if we wanted to learn a part of VMS that we
>> had not previously used, but we are not the kind of people that such
>> manuals should be written for these days.
>>
>> At a minimum, there needs to be the kind of trail-based documentation
>> I have pointed to above as part of the VMS documentation set.
>
> If I had to state an opinion, it would be that the documentation seems
> to me to assume to much pre-knowledge on the part of the reader. It
> assumes one is already an experienced professional with experience using
> VMS and therefore no clarifications are necessary. But, again, that
> could be just me.
>

And _that_ Bill is something that I agree with you about and why
I think a trail-based introduction to VMS-specific concepts would be
a really good thing.

I've just had another look at the programming concepts manual and while
_I_ have absolutely no problem understanding it, it does go way too deep
way too quickly for the absolute beginner and a newcomer could easily get
lost in the mass of fine detail. It's called a concepts manual, but that
manual was written for people like us. It wasn't written for absolute
newcomers to VMS.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 3/14/22 18:15, Simon Clubley wrote:
> On 2022-03-14, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 3/14/22 15:30, Simon Clubley wrote:
>>> On 2022-03-14, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>>> On 3/14/22 09:58, Simon Clubley wrote:
>>>>>
>>>>> Try to consider, as a VMS person, being asked to learn how to work with
>>>>> z/OS and write software for it. An experienced z/OS person will not have
>>>>> a problem because they are used to it. A newcomer to z/OS, OTOH, will see
>>>>> all the strange new concepts and ways of doing things that they have never
>>>>> encountered before and could easily be lost in a mass of detail.
>>>>>
>>>>
>>>> Not really. I hadn't touched an IBM Mainframe since the DOS/E VM370
>>>> days and had no problem doing the challenges on the Mastering the
>>>> Mainframe program just a couple weeks ago. The hardest parts had to
>>>> do with stuff they use that runs on Linux. All the z/OS stuff was a
>>>> piece of cake.
>>>>
>>>
>>> Yes, but you clearly had prior experience and conceptual knowledge which
>>> helped you. Many people these days simply don't have any prior knowledge
>>> or even understanding of such things.
>>
>> Do you really think there is any similarity between DOS/E on a 4331
>> running VM/370 40 years ago and a current zSystem run z/OS? You really
>> have no knowledge of Big Blue, do you?
>>
>
> My IBM knowledge is mainly MVS 3.8 (obviously!) and some modern z/OS.
> Even from the MVS 3.8 days, there's enough in there to give you a jump
> start with getting up to speed with how modern z/OS works.

MVS was outside my experience. I did DOS/E which was a modified version
of DOS for DOD. Ran on those trailer mounted 360/40.

>
> The hardware doesn't really matter in this case. It's the mindset and
> general way of doing things that really matters.

My mindset is not to any particular OS or vendor. I have worked at the
application and systems level on at least a dozen different systems.

>
> In the DEC world, because of its origins, you can use RSX to help understand
> some of the core VMS concepts. Hell, even some of the PDP-11 userland tools
> are mostly the same regardless of which underlying PDP-11 operating system
> they are running on.

My RSX experience is very limited. First used it as a beltway bandit and
didn't really like it.

>
>>>
>>> For example, consider that you have programmed in DEC Basic all your life
>>> and then you have a C++ manual dumped in front of you and told that's what
>>> you need to get up to speed on because that's what you will be using from
>>> now on.
>>
>> Been there, done that. Took the Jensen and Wirth "Users Manual and
>> Report" with me on vacation and learned Pascal in two weeks.
>>
>
> Pascal's a little easier to learn than C++. :-)

The much more experienced programmers where I was working at the time
would not agree with you. That's why I got the task.

>
>>>
>>> That's how different VMS would feel to someone who had only ever used Linux
>>> and Windows and had absolutely no idea of the concepts behind VMS.
>>>
>>>>> That feeling is exactly the same feeling that people new to VMS could
>>>>> easily feel when they are exposed to an operating system with concepts
>>>>> and ways of doing things they have never seen before.
>>>>
>>>> I still think learning VMS is harder. I don't think it needs to be, but
>>>> it is.
>>>>
>>>
>>> Do you have any specific examples why you think this is ?
>>>
>>> Is it the lack of tutorial material ?
>>>
>>> Overwhelming levels of detail in the documentation ?
>>
>> I just find the explanations to be poor. I find it very difficult
>> to find things I need in the documentation. But that could just
>> be me. :-)
>>
>
> Not really. See below.
>
>>>
>>> Not enough reading guides about what trails to follow through the
>>> documentation for various tasks ? (Or the fact that such trails don't
>>> appear to exist for VMS ?)
>>>
>>> For anyone interested, here's the trail for the Java Reflection functionality:
>>>
>>> https://docs.oracle.com/javase/tutorial/reflect/index.html
>>>
>>> It contains a mixture of tutorial/conceptual material along with links to
>>> detailed reference material and includes code examples. That's the kind of
>>> thing people expect these days and which is sorely lacking in the VMS
>>> documentation set.
>>>
>>> There's no point having a lot of documentation if you don't have task
>>> orientated guides and tutorials to help you understand and navigate it.
>>> That's how people get lost in a mass of detail.
>>>
>>> Here's the main Java tutorial page:
>>>
>>> https://docs.oracle.com/javase/tutorial/index.html
>>
>> There are enough third party books on Java it is unlikely I would
>> ever look at any of that. And I didn't when learning Java,
>>
>
> Neither did I when learning Java in general. However, I did use it
> to learn how to use Reflection (which was an entirely new concept to me
> for Java) and I found the material to be well written, pitched at just
> the right level for an otherwise experienced programmer, and gave me
> all the pointers I needed to jump into the reference manuals once
> I understood how the concepts worked on Java.
>
> It was massively better than trying to manually pull together the pieces
> from the documentation and VMS could seriously do with material along
> those lines as part of the documentation set.
>
>>>
>>> VMS badly needs task orientated guides like that as part of the
>>> documentation set. Spending silly time wading through the documentation
>>> set and gradually assembling clues to the pieces of knowledge you need
>>> is not an acceptable approach these days.
>>>
>>> The closest VMS comes are things like the programming concepts manuals
>>> which jump in way too deeply way too quickly for any absolute newcomers
>>> to VMS. None of us here would have any problems at all understanding the
>>> material in those manuals if we wanted to learn a part of VMS that we
>>> had not previously used, but we are not the kind of people that such
>>> manuals should be written for these days.
>>>
>>> At a minimum, there needs to be the kind of trail-based documentation
>>> I have pointed to above as part of the VMS documentation set.
>>
>> If I had to state an opinion, it would be that the documentation seems
>> to me to assume to much pre-knowledge on the part of the reader. It
>> assumes one is already an experienced professional with experience using
>> VMS and therefore no clarifications are necessary. But, again, that
>> could be just me.
>>
>
> And _that_ Bill is something that I agree with you about and why
> I think a trail-based introduction to VMS-specific concepts would be
> a really good thing.
>
> I've just had another look at the programming concepts manual and while
> _I_ have absolutely no problem understanding it, it does go way too deep
> way too quickly for the absolute beginner and a newcomer could easily get
> lost in the mass of fine detail. It's called a concepts manual, but that
> manual was written for people like us. It wasn't written for absolute
> newcomers to VMS.
>

The only books I have seen that I would say were written for the rank
beginner were "VMS for Unix Users" and Unix for VMS Users" (or some
very similar titles) and the couple of VAX-11 BASIC books I still have.

:-)

bill

On 3/14/2022 4:06 PM, Simon Clubley wrote:
> On 2022-03-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 3/14/2022 2:48 PM, Simon Clubley wrote:
>>> Also, in Unix (thanks to C being the lowest supported language), pointers
>>> are an abstraction that the compiler deals with behind the scenes for you
>>> when it comes time to store them away and pass them around. In VMS,
>>> traditional pointers are an unabstracted and direcly exposed longword
>>> field that cannot just be automatically resized by passing "-m64" or
>>> similar on the compiler command line.
>>
>> That is a not really a block problem.
>
> It is when you can't compile your RMS program (for example) to fully
> use a 64-bit address space by simply using a compiler switch when you
> recompile the programs without needing to make any user source code changes.

If DEC had gone clean 64 bit pointers then there would not even
be a compiler switch. VAX would be 32 bit pointers and Alpha & Itanium
would be 64 bit. And it would work fine with RMS blocks. RMS blocks
would not have the same size on VAX as on Alpha & Itanium, but not
a problem.

>> If DEC had decided to go only 64 bit pointers on Alpha 30 years ago,
>> then the block definitions could have had 64 bit address fields
>> in blocks on Alpha and Itanium.
>>
>> But they did not. For many reasons.
>
> Yes, because when VMS was designed it had to work with a certain language
> which does not have an abstracted pointer size concept where the
> implementation details are mostly hidden from the user's source code.

If Macro-32 had been the only issue with going 64 bit pointers, then I
think DEC would have gone that route. But plenty of other reasons.

Arne

On 2022-03-14, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
> On 3/14/22 18:15, Simon Clubley wrote:
>>
>> Pascal's a little easier to learn than C++. :-)
>
> The much more experienced programmers where I was working at the time
> would not agree with you. That's why I got the task.
>

So IOW, what you are really saying is that those programmers would
prefer to use a language that allows them to throw something together
that appears to work, instead of using a language that tries harder
to make them do the right thing. :-)

Work with the language, not against it. You get better results that way. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 3/14/22 21:41, Simon Clubley wrote:
> On 2022-03-14, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 3/14/22 18:15, Simon Clubley wrote:
>>>
>>> Pascal's a little easier to learn than C++. :-)
>>
>> The much more experienced programmers where I was working at the time
>> would not agree with you. That's why I got the task.
>>
>
> So IOW, what you are really saying is that those programmers would
> prefer to use a language that allows them to throw something together
> that appears to work, instead of using a language that tries harder > to make them do the right thing. :-)

No, they would have preferred that a new language not be introduced
into the production environment. But with the advent of microcomputers
(*which they also didn't think would work as the Terak we got to work
with only had 28K words of RAM and everyone knew that wasn't enough
memory to do anything practical :-) )The only languages supported by
the Terak were F77 and UCSD-Pascal. I was the new guy who didn't have
enough experience to know what was impossible so I got the task of
making the Teraks usable. :-) Yes, I did.

>
> Work with the language, not against it. You get better results that way. :-)

Work with the languages that actually exist on the system You get
better results that way. :-)

bill

On 3/14/2022 6:51 PM, Bill Gunshannon wrote:
> On 3/14/22 18:15, Simon Clubley wrote:
>> On 2022-03-14, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>> Been there, done that.  Took the Jensen and Wirth "Users Manual and
>>> Report" with me on vacation and learned Pascal in two weeks.
>>
>> Pascal's a little easier to learn than C++. :-)
>
> The much more experienced programmers where I was working at the time
> would not agree with you.

Most would agree with Simon.

C++ is a way more complex language than Pascal.

Or to qualify it: ISO C++ is way more complex
than ISO non-extended Pascal and more complex than
VMS Pascal.

(Object Pascal and Delphi are probably as complex
as ISO C++)

Just the fact that C++ support procedural, object oriented,
generic and in recent versions functional programming ensures
that.

Arne

On 03/14/22 17:37, Stephen Hoffman wrote:
> On 2022-03-13 01:12:37 +0000, chris said:
>
>> It's a while since I used the grey wall, but to be fair, all the info
>> was there, it's just wasn't organised in a way that made things easy
>> to find. I remember doing some serial comms work years ago and needed
>> to consult 3 or 4 volumes to find the info, bits of which were
>> distributed across all of them. System service calls can be a bit
>> arcane as well, though that's probably just a matter of familiarity.
>
> Descriptors and system services are arcane, and with lots of glue code
> in languages without built-in support. And often with glue code, even in
> those languages with better support.
>
> Navigation in the current OpenVMS documentation needs help, and the
> availability of recipes—what used to be in TIMA/STARS and what was once
> accessible via AskQ and ilk—are lacking. The OpenVMS doc is old,
> piecemeal, and in need of an overhaul and updates.
>
> As examples of gaps in the current OpenVMS documentation: writing secure
> apps, data security, and network security applications. There are
> others. VSI is aware of these gaps, and has a support database
> replacement presently being populated. When the product support team
> can't find an existing recipe or existing example to send to a customer,
> they presumably write one anew, and add it to the database. This all
> takes time and effort. Substantive other work here awaits, too.
>
> One longer-term downside of providing these source code examples is that
> any bugs or issues or limits tend to spread widely, should those arise
> in any examples. And these are easy mistakes to make, whether around
> error handling or data security, or otherwise. Which means abstracting
> this code can be preferable (remove the glue code, and improve the
> APIs), whether it's moving descriptors into objects, or providing
> better-abstracted APIs for the most commonly employed source code recipe
> sequences. The existing SYS$EXAMPLES and related code examples have (or
> had) source build issues, too.
>
> Examples of gaps here include networking (IP, DNS, TLS, etc) and the
> network security APIs, and pretty much all of ACME—ACME is a massively
> flexible design, but also sometimes subtle and difficult to correctly
> use for common operations. There are others. All of this really needs to
> be better abstracted, and incorporated into the platform.
>
> Descriptors were a nice idea in 1978 too, but expectations have changed.
> C and C++ could have used better abstractions for dealing with
> descriptors too, but C and C++ extensions for descriptors seems rather
> less than worthwhile in 2025. And the typical replacement of adding
> message-passing enhancements is a far investment in the run-time and in
> the compilers generally, and well beyond the existing and required
> compiler work that is already critical path development work for VSI.
>
>> Compare that to the unix approach. Originally just a set of runoff
>> pages, very much on your own, but the methodology, ways and means of
>> accessing information, have changed. For example, plugin fopen() to a
>> search engine and you get dozens of the basic man page descriptions,
>> but also a range of pages with code snippets illustrating usage. Much
>> faster way to get productive. Solve the problem, not get bogged down
>> trying to find the information...
>
> With apps such as Dash, too. https://kapeli.com/dash
>
> Getting system services and other OpenVMS reference materials into
> formats available for inclusion into these or similar tools is another
> project.
>
> The built-in documentation tags increasingly available in various
> tooling is making source code easier to document, as well. This isn't a
> new idea, what with Doxygen, and as OpenVMS itself generates some
> documentation from source code. (For generating error messages and
> recovery documentation, see GNM on the OpenVMS freeware.)
>
> But for now and for the next year or three, VSI is occupied getting
> OpenVMS x86-64 stable and working and shipping. Which can and is and
> should be the priority.
>
>

Thanks, more or less what I suspected. No longer a vms user, but would
like to see it succeed. Problem is that it's so far behind the
mainstream now, it will take a lot of effort to catch up. As I said,
porting cups or other mainstream printing system would fix the printing
issue for good, but even that would require effort from people
familiar with both unix and vms.

What might be just as important is the head in sand attitude of some,
as the song goes, you ain't gonna learn what you don't want to know. In
computing, I always expected to have to keep up with developments and
in fact, that's one of the main attractions of tech, lifelong learning
and always a student...

Chris

>
>