On 01/01/2025 16:12, Arne Vajhøj wrote:
VMS Pascal for C/Java/C# programmers:
https://www.vajhoej.dk/arne/articles/vmspascal.html
It is a "pre-release" - I am not sure I got it right.
So I would love some feedback.
Interesting - many thanks
I was surprised to see that Pascal was created in 2970!
VMS Pascal for C/Java/C# programmers:
https://www.vajhoej.dk/arne/articles/vmspascal.html
It is a "pre-release" - I am not sure I got it right.
So I would love some feedback.
Arne
I was surprised to see that Pascal was created in 2970!
VMS Pascal for C/Java/C# programmers:
https://www.vajhoej.dk/arne/articles/vmspascal.html
It is a "pre-release" - I am not sure I got it right.
So I would love some feedback.
Arne
Arne Vajhøj has brought this to us :
VMS Pascal for C/Java/C# programmers:
https://www.vajhoej.dk/arne/articles/vmspascal.html
It is a "pre-release" - I am not sure I got it right.
So I would love some feedback.
In the first section, you might also mention that VMS Pascal has
excellent support in LSE/SCA - for those who still use DECset...
Didn't see anything about the VARYING type and its so useful
<varying>.BODY and <varying>.LENGTH functions, as well as READV and
WRITEV. Probably the most important things to know if you have to
manipulate character strings.
May be also mention that the VMS Pascal compiler comes with declaration modules for all VMS system services and RTLs. Combined with LSE/SCA
support, this makes system programming extremely easy.
Ah, and also, good support of VMS Pascal by SDL...
On 1/2/2025 5:01 AM, Marc Van Dyck wrote:
Ah, and also, good support of VMS Pascal by SDL...
Too advanced for me.
On Thu, 2 Jan 2025 17:19:14 -0500, Arne Vajhøj wrote:
On 1/2/2025 5:01 AM, Marc Van Dyck wrote:
Ah, and also, good support of VMS Pascal by SDL...
Too advanced for me.
SDL is just the common language used for defining interfaces. That’s how files like STARLET.PAS get automatically generated.
On 1/2/2025 5:01 AM, Marc Van Dyck wrote:
Ah, and also, good support of VMS Pascal by SDL...
Too advanced for me.
:-)
On 1/2/2025 7:34 PM, Lawrence D'Oliveiro wrote:
On Thu, 2 Jan 2025 17:19:14 -0500, Arne Vajhøj wrote:
On 1/2/2025 5:01 AM, Marc Van Dyck wrote:
Ah, and also, good support of VMS Pascal by SDL...
Too advanced for me.
SDL is just the common language used for defining interfaces. That’s
how files like STARLET.PAS get automatically generated.
I know what it is is.
On Thu, 2 Jan 2025 20:49:43 -0500, Arne Vajhøj wrote:
On 1/2/2025 7:34 PM, Lawrence D'Oliveiro wrote:
On Thu, 2 Jan 2025 17:19:14 -0500, Arne Vajhøj wrote:
On 1/2/2025 5:01 AM, Marc Van Dyck wrote:
Ah, and also, good support of VMS Pascal by SDL...
Too advanced for me.
SDL is just the common language used for defining interfaces. That’s
how files like STARLET.PAS get automatically generated.
I know what it is is.
It’s also not that hard to understand, if you take the “Rosetta Stone” approach of looking at the original SDL source and comparing with its
output for a particular language that you know.
There was also one called MDL, if I recall rightly, which looked like it
was more on the MACRO level.
On 1/2/2025 5:19 PM, Arne Vajhøj wrote:
On 1/2/2025 5:01 AM, Marc Van Dyck wrote:
Ah, and also, good support of VMS Pascal by SDL...
Too advanced for me.
:-)
But speaking of SDL.
Does anybody know what VSI's plan is for SDL on VMS x86-64?
Rewrite?
On 1/2/2025 8:52 PM, Arne Vajhøj wrote:
On 1/2/2025 5:19 PM, Arne Vajhøj wrote:
On 1/2/2025 5:01 AM, Marc Van Dyck wrote:
Ah, and also, good support of VMS Pascal by SDL...
Too advanced for me.
:-)
But speaking of SDL.
Does anybody know what VSI's plan is for SDL on VMS x86-64?
Rewrite?
It's written in C++ so we were waiting for a native C++ compiler.
As it turns out, SDL uncovered some dark areas of the compiler that needed addressing.
We have a working SDL on X86 now.
On 1/2/2025 10:29 PM, Robert A. Brooks wrote:
On 1/2/2025 8:52 PM, Arne Vajhøj wrote:
On 1/2/2025 5:19 PM, Arne Vajhøj wrote:
On 1/2/2025 5:01 AM, Marc Van Dyck wrote:
Ah, and also, good support of VMS Pascal by SDL...
Too advanced for me.
:-)
But speaking of SDL.
Does anybody know what VSI's plan is for SDL on VMS x86-64?
Rewrite?
It's written in C++ so we were waiting for a native C++ compiler.
As it turns out, SDL uncovered some dark areas of the compiler that needed >> addressing.
We have a working SDL on X86 now.
I thought it was PL/I. Which is why I asked.
On 1/2/2025 7:34 PM, Lawrence D'Oliveiro wrote:
On Thu, 2 Jan 2025 17:19:14 -0500, Arne Vajhj wrote:
On 1/2/2025 5:01 AM, Marc Van Dyck wrote:
Ah, and also, good support of VMS Pascal by SDL...
Too advanced for me.
SDL is just the common language used for defining interfaces. That?s how
files like STARLET.PAS get automatically generated.
I know what it is is. Otherwise I could not have commented on
the level.
On 1/2/2025 10:32 PM, Arne Vajhøj wrote:
On 1/2/2025 10:29 PM, Robert A. Brooks wrote:
On 1/2/2025 8:52 PM, Arne Vajhøj wrote:
But speaking of SDL.
Does anybody know what VSI's plan is for SDL on VMS x86-64?
Rewrite?
It's written in C++ so we were waiting for a native C++ compiler.
As it turns out, SDL uncovered some dark areas of the compiler that
needed
addressing.
We have a working SDL on X86 now.
I thought it was PL/I. Which is why I asked.
Rewritten in the early 2000's.
VMS Pascal for C/Java/C# programmers:
https://www.vajhoej.dk/arne/articles/vmspascal.html
It is a "pre-release" - I am not sure I got it right.
So I would love some feedback.
On 1/2/2025 10:48 PM, Robert A. Brooks wrote:
On 1/2/2025 10:32 PM, Arne Vajhøj wrote:
I thought it was PL/I. Which is why I asked.
Rewritten in the early 2000's.
Ah. So it was rewritten for Itanium instead of being AEST'ed.
I wonder whether it was because someone at HP decided
to do the right thing or because AEST couldn't handle
it.
In article <vl3pi8$2r2sr$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
VMS Pascal for C/Java/C# programmers:
https://www.vajhoej.dk/arne/articles/vmspascal.html
It is a "pre-release" - I am not sure I got it right.
So I would love some feedback.
C supports 'long double' which _may_ be the same as
`quadruple`, depending on the implementation, though
that's usually 80-bit floats.
I would not say that 'chr' and 'ord' are like casts in C.
Pascal is strongly, statically typed; C is weakly typed with
implicit conversions. Conversion between characters and integer
types in Pascal is an explicit operation, but `int c = 'a' + 1;`
is perfectly legal in C.
You give two C equivalents of, `round`: `lround` and
`ceil(v + 0.5)`. Surely the latter should be `trunc(v + 0.5)`:
But, consider negative numbers,
and note that one would still
have to do a conversion to an integer type.
Your C equivalent of `substr` is not correct; exercise left to
the reader (consider what happens when `ix` is beyond the end of
the string). For that matter, this is true of the VSI Pascal
example as well: you should specify the preconditions that must
be true.
`readln` and `fgets` are not similar in that `readln` strips the
line ending sequence, and `fgets` does not.
`f = fopen,fnm "r");` is an obvious typo.
`while not eof(f)) do` is an obvious typo.
You may want to mention that Pascal, the semicolon is a
statement separator, not a terminator, and hence why the last
"END" in the protocol is followed by "." and not ";".
The structure you present at the end as "equivalent" of a
varying character array is not correct. `integer16` is a signed
type, with a maximum value of 32,767. The length field for a
`varying [n] of char` is an integer subrange type with word
representation. That is, `length` is unsigned 0..max, where max
is <= 65,535.
On 1/3/2025 10:11 AM, Dan Cross wrote:
In article <vl3pi8$2r2sr$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
VMS Pascal for C/Java/C# programmers:
https://www.vajhoej.dk/arne/articles/vmspascal.html
It is a "pre-release" - I am not sure I got it right.
So I would love some feedback.
C supports 'long double' which _may_ be the same as
`quadruple`, depending on the implementation, though
that's usually 80-bit floats.
Very good point. It is 128 bit on VMS unless using /L_DOUBLE=64.
Added.
I would not say that 'chr' and 'ord' are like casts in C.
Pascal is strongly, statically typed; C is weakly typed with
implicit conversions. Conversion between characters and integer
types in Pascal is an explicit operation, but `int c = 'a' + 1;`
is perfectly legal in C.
It was the best explanation I could come up with.
You give two C equivalents of, `round`: `lround` and
`ceil(v + 0.5)`. Surely the latter should be `trunc(v + 0.5)`:
Ooops. All ceil should be floor.
Fixed.
But, consider negative numbers,
Very good point.
I have added notes.
and note that one would still
have to do a conversion to an integer type.
Yes.
Fixed.
Your C equivalent of `substr` is not correct; exercise left to
the reader (consider what happens when `ix` is beyond the end of
the string). For that matter, this is true of the VSI Pascal
example as well: you should specify the preconditions that must
be true.
Invalid index or length causes an exception in VMS Pascal.
But I don't want to get into that level of detail.
`readln` and `fgets` are not similar in that `readln` strips the
line ending sequence, and `fgets` does not.
Close enough for the purpose of this article.
`f = fopen,fnm "r");` is an obvious typo.
`while not eof(f)) do` is an obvious typo.
Fixed.
You may want to mention that Pascal, the semicolon is a
statement separator, not a terminator, and hence why the last
"END" in the protocol is followed by "." and not ";".
The article is more what to do than why to do that.
The structure you present at the end as "equivalent" of a
varying character array is not correct. `integer16` is a signed
type, with a maximum value of 32,767. The length field for a
`varying [n] of char` is an integer subrange type with word
representation. That is, `length` is unsigned 0..max, where max
is <= 65,535.
Ooops.
You are right.
I was sure that the limit was 32K but it is 64K.
Fixed.
And also fixed in the description of VARYING further up.
In article <67781447$0$711$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/3/2025 10:11 AM, Dan Cross wrote:
`readln` and `fgets` are not similar in that `readln` strips the
line ending sequence, and `fgets` does not.
Close enough for the purpose of this article.
Perhaps. I may be worth an asterisk, as often C programmers
will want to write:
while ((s = fgets(s, len, fp)) != NULL) {
char *nl = strchr(s, '\n');
if (nl != NULL)
*nl = '\0';
}
Which is a bit more cumbersome than the Pascal equivalent. When
carriage returns get mixed in, it gets even nastier, so much so
that one may just write a helper function to deal with it.
I think you are right. I have added a note.
`f = fopen,fnm "r");` is an obvious typo.
`while not eof(f)) do` is an obvious typo.
Fixed.
Fixed, but the comparison to C is slightly wrong:
`while not(eof(f)) do` is not exactly the same as
`while(!feof(f))`. In particular, while in VSI Pascal `EOF(f)`
will be true on the first iteration of the loop if `f` is empty,
the same is not true for `feof` from stdio: in order for `feof`
to be true, stdio must observe the end-of-file condition of `f`
via some input operation. This leads to awkward code sequences
like this:
ch = fgetc(fp);
while (!feof(fp)) {
/*
* Do something with `ch`
* ...
*/
ch = fgetc(fp);
}
C feof is a crap function.
I think I will drop feof completely and add fgetc
not returning EOF. I already have fgets not returning NULL.
The structure you present at the end as "equivalent" of a
varying character array is not correct. `integer16` is a signed
type, with a maximum value of 32,767. The length field for a
`varying [n] of char` is an integer subrange type with word
representation. That is, `length` is unsigned 0..max, where max
is <= 65,535.
Ooops.
You are right.
I was sure that the limit was 32K but it is 64K.
Fixed.
And also fixed in the description of VARYING further up.
You should seriously mention the STRING type, though.
I think VARYING OF CHAR is what is used most in VMS Pascal.
Also, it's a bit of a bummer that you didn't mention nested
functions/procedures, which are among the cooler aspects of the
language:
$ type foo.pas
(* foo *)
program foo(output);
procedure hello;
procedure world(var who: String);
function punct: char;
begin
punct := '!'
end;
begin
who := 'World' + punct
end;
var
who: String (10);
begin
world(who);
writeln('Hello, ', who)
end;
begin
hello
end.
There is already an example. fac is inside testfac.
I will add a note about it.
In article <67781447$0$711$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/3/2025 10:11 AM, Dan Cross wrote:
`readln` and `fgets` are not similar in that `readln` strips the
line ending sequence, and `fgets` does not.
Close enough for the purpose of this article.
Perhaps. I may be worth an asterisk, as often C programmers
will want to write:
while ((s = fgets(s, len, fp)) != NULL) {
char *nl = strchr(s, '\n');
if (nl != NULL)
*nl = '\0';
}
Which is a bit more cumbersome than the Pascal equivalent. When
carriage returns get mixed in, it gets even nastier, so much so
that one may just write a helper function to deal with it.
`f = fopen,fnm "r");` is an obvious typo.
`while not eof(f)) do` is an obvious typo.
Fixed.
Fixed, but the comparison to C is slightly wrong:
`while not(eof(f)) do` is not exactly the same as
`while(!feof(f))`. In particular, while in VSI Pascal `EOF(f)`
will be true on the first iteration of the loop if `f` is empty,
the same is not true for `feof` from stdio: in order for `feof`
to be true, stdio must observe the end-of-file condition of `f`
via some input operation. This leads to awkward code sequences
like this:
ch = fgetc(fp);
while (!feof(fp)) {
/*
* Do something with `ch`
* ...
*/
ch = fgetc(fp);
}
The structure you present at the end as "equivalent" of a
varying character array is not correct. `integer16` is a signed
type, with a maximum value of 32,767. The length field for a
`varying [n] of char` is an integer subrange type with word
representation. That is, `length` is unsigned 0..max, where max
is <= 65,535.
Ooops.
You are right.
I was sure that the limit was 32K but it is 64K.
Fixed.
And also fixed in the description of VARYING further up.
You should seriously mention the STRING type, though.
Also, it's a bit of a bummer that you didn't mention nested functions/procedures, which are among the cooler aspects of the
language:
$ type foo.pas
(* foo *)
program foo(output);
procedure hello;
procedure world(var who: String);
function punct: char;
begin
punct := '!'
end;
begin
who := 'World' + punct
end;
var
who: String (10);
begin
world(who);
writeln('Hello, ', who)
end;
begin
hello
end.
In article <vl9aln$o72$1@dont-email.me>, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/3/2025 1:17 PM, Dan Cross wrote:
In article <67781447$0$711$14726298@news.sunsite.dk>,
And also fixed in the description of VARYING further up.
You should seriously mention the STRING type, though.
I think VARYING OF CHAR is what is used most in VMS Pascal.
Weird; I can't imagine why.
Regardless, it may be worthwhile to
at least mention it, since you state explicitly that there are
three types for representing textual, string-like data, but
VSI's documentation makes it clear that there are actually four.
Also, it's a bit of a bummer that you didn't mention nested
functions/procedures, which are among the cooler aspects of the
language:
$ type foo.pas
(* foo *)
program foo(output);
procedure hello;
procedure world(var who: String);
function punct: char;
begin
punct := '!'
end;
begin
who := 'World' + punct
end;
var
who: String (10);
begin
world(who);
writeln('Hello, ', who)
end;
begin
hello
end.
There is already an example. fac is inside testfac.
I will add a note about it.
Ah, I see it now; the lack of indentation makes it hard to spot.
On 1/3/2025 1:51 PM, Dan Cross wrote:
In article <vl9aln$o72$1@dont-email.me>, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/3/2025 1:17 PM, Dan Cross wrote:
In article <67781447$0$711$14726298@news.sunsite.dk>,
And also fixed in the description of VARYING further up.
You should seriously mention the STRING type, though.
I think VARYING OF CHAR is what is used most in VMS Pascal.
Weird; I can't imagine why.
I never use string (on VMS).
$ search sys$common:[syshlp.examples.pascal]*.pas varying
$ search sys$common:[syshlp.examples.pascal]*.pas "string("
indicate that whoever write VMS Pascal examples also prefer
varying of char over string.
If I were to guess about why, then I believe it is historic
reasons. varying of char has been there since like forever.
string was added with ISO Pascal support later.
Regardless, it may be worthwhile to
at least mention it, since you state explicitly that there are
three types for representing textual, string-like data, but
VSI's documentation makes it clear that there are actually four.
Good point.
I have updated.
Also, it's a bit of a bummer that you didn't mention nested
functions/procedures, which are among the cooler aspects of the
language:
$ type foo.pas
(* foo *)
program foo(output);
procedure hello;
procedure world(var who: String);
function punct: char;
begin
punct := '!'
end;
begin
who := 'World' + punct
end;
var
who: String (10);
begin
world(who);
writeln('Hello, ', who)
end;
begin
hello
end.
There is already an example. fac is inside testfac.
I will add a note about it.
Ah, I see it now; the lack of indentation makes it hard to spot.
I don't indent them.
With the blank lines I put in then I feel that indenting
nested procedures/functions would make it too much space.
In article <6778415e$0$708$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/3/2025 1:51 PM, Dan Cross wrote:
In article <vl9aln$o72$1@dont-email.me>, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/3/2025 1:17 PM, Dan Cross wrote:
In article <67781447$0$711$14726298@news.sunsite.dk>,
And also fixed in the description of VARYING further up.
You should seriously mention the STRING type, though.
I think VARYING OF CHAR is what is used most in VMS Pascal.
Weird; I can't imagine why.
I never use string (on VMS).
$ search sys$common:[syshlp.examples.pascal]*.pas varying
$ search sys$common:[syshlp.examples.pascal]*.pas "string("
indicate that whoever write VMS Pascal examples also prefer
varying of char over string.
If I were to guess about why, then I believe it is historic
reasons. varying of char has been there since like forever.
string was added with ISO Pascal support later.
I suspect that's close, but ISO Pascal doesn't have a 'VARYING'
array type, either.
I suspect you're referring to what ISO calls "Extended Pascal"
(ISO 10206); ISO Pascal (ISO 7185) doesn't support a `String`
type of either the VSI Pascal form or the Turbo
Pascal/Delphi/FreePascal form, only manifest string literals and
`packed array [1..n] of char`. Of course, one can define a type
alias, and ISO 7185 says this:
|Any type designated packed and denoted by an array-type having
|as its index-type a denotation of a subrange-type specifying a
|smallest value of 1 and a largest value of greater than 1, and
|having as its component-type a denotation of the char-type,
|shall be designated a string-type.
An annoyance with ISO Pascal is that an array's size is part of
its type, and there is no separate slice type that could act
as a window into an array independent of size and be passed
around, so it is difficult to write procedures and functions
that operate on e.g. strings, generically. See also, >https://www.lysator.liu.se/c/bwk-on-pascal.html
However, these deficiencies are largely addressed in ISO 10206
Extended Pascal, which provides a variable-length string type
and permits conformant array parameters, which for VSI Pascal
appear to monomorphize over the argument type.
... I feel that indenting nested
procedures/functions would make it too much space.
On Fri, 3 Jan 2025 14:58:22 -0500, Arne Vajhøj wrote:
... I feel that indenting nested
procedures/functions would make it too much space.
At an indentation step of 4 columns and a window width of typically 100 columns, I find that leaves room for plenty of indentation steps.
In article <6778415e$0$708$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/3/2025 1:51 PM, Dan Cross wrote:
In article <vl9aln$o72$1@dont-email.me>, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/3/2025 1:17 PM, Dan Cross wrote:
In article <67781447$0$711$14726298@news.sunsite.dk>,
And also fixed in the description of VARYING further up.
You should seriously mention the STRING type, though.
I think VARYING OF CHAR is what is used most in VMS Pascal.
Weird; I can't imagine why.
I never use string (on VMS).
$ search sys$common:[syshlp.examples.pascal]*.pas varying
$ search sys$common:[syshlp.examples.pascal]*.pas "string("
indicate that whoever write VMS Pascal examples also prefer
varying of char over string.
If I were to guess about why, then I believe it is historic
reasons. varying of char has been there since like forever.
string was added with ISO Pascal support later.
I suspect that's close, but ISO Pascal doesn't have a 'VARYING'
array type, either.
I suspect you're referring to what ISO calls "Extended Pascal"
(ISO 10206); ISO Pascal (ISO 7185) doesn't support a `String`
type of either the VSI Pascal form or the Turbo
Pascal/Delphi/FreePascal form, only manifest string literals and
`packed array [1..n] of char`.
In article <vl9khp$cdg$1@reader2.panix.com>,
Dan Cross <cross@spitfire.i.gajendra.net> wrote:
However, these deficiencies are largely addressed in ISO 10206
Extended Pascal, which provides a variable-length string type
and permits conformant array parameters, which for VSI Pascal
appear to monomorphize over the argument type.
Actually, I guess that conformant array parameterss were in ISO
7185, which had two "levels" of compliance; level 0 omitted them
and level 1 includes them. That language is retained in ISO
10206. Original, Wirth Pascal does not have them.
Extended Pascal's variable string type appears more or less
identical to the string type in VSI Pascal.
VMS Pascal for C/Java/C# programmers:
https://www.vajhoej.dk/arne/articles/vmspascal.html
It is a "pre-release" - I am not sure I got it right.
So I would love some feedback.
On 1/3/2025 7:59 AM, Arne Vajhøj wrote:
On 1/2/2025 10:48 PM, Robert A. Brooks wrote:
On 1/2/2025 10:32 PM, Arne Vajhøj wrote:
I thought it was PL/I. Which is why I asked.
Rewritten in the early 2000's.
Ah. So it was rewritten for Itanium instead of being AEST'ed.
I wonder whether it was because someone at HP decided to do the right
thing or because AEST couldn't handle it.
I am not aware of an attempt to AEST it; it was rewritten by Walter
Breu (sp?) of HP Germany. He was not in VMS Engineering, so I wasn't
paying a lot of attention when he was doing the work.
Pretty sure it was part of the "get rid of all PL/I" initiative.
On 2025-01-03 14:30:37 +0000, Robert A. Brooks said:
On 1/3/2025 7:59 AM, Arne Vajhøj wrote:
On 1/2/2025 10:48 PM, Robert A. Brooks wrote:
On 1/2/2025 10:32 PM, Arne Vajhøj wrote:
I thought it was PL/I. Which is why I asked.
Rewritten in the early 2000's.
Ah. So it was rewritten for Itanium instead of being AEST'ed.
I wonder whether it was because someone at HP decided to do the right
thing or because AEST couldn't handle it.
I am not aware of an attempt to AEST it; it was rewritten by Walter
Breu (sp?) of HP Germany. He was not in VMS Engineering, so I wasn't
paying a lot of attention when he was doing the work.
Pretty sure it was part of the "get rid of all PL/I" initiative.
That's basically correct, yes. And Walter Breu was the author of the
SDLC port and of some related updates. One of the goals of that SDLC
port was character-level-formatting compatibility with the PL/I version
of the SDL tool; matching DIFF'ing.
Various factors that triggered this port including the transition of PL/
I to Uniprise and later Kednos — and particularly the lack of a PL/I compiler on Itanium — and caused an interest in reducing the usage of
PL/I within OpenVMS. MONITOR was the biggest existing user of PL/I.
And Walter Breu was the author of the SDLC port ...
I tried installing 2.3 on VMS Alpha.
And the installation procedure attempts to send an
email to him at hp.com.
Unusual!
On 2025-01-04, Arne Vajhøj <arne@vajhoej.dk> wrote:
I tried installing 2.3 on VMS Alpha.
And the installation procedure attempts to send an
email to him at hp.com.
Unusual!
Not really. The guy was just ahead of his time. :-)
VMS Pascal for C/Java/C# programmers:
https://www.vajhoej.dk/arne/articles/vmspascal.html
It is a "pre-release" - I am not sure I got it right.
So I would love some feedback.
Arne
On 1/1/2025 11:12 AM, Arne Vajhøj wrote:For modern OpenVMS usage, you might want to discuss how to get 64-bit
VMS Pascal for C/Java/C# programmers:I'll look and give feedback.
https://www.vajhoej.dk/arne/articles/vmspascal.html
It is a "pre-release" - I am not sure I got it right.
So I would love some feedback.
Arne
John
[snip]
I have a copy of Theo De Klerk's book on my bookshelf. I did the
technical review of that book (wow, that is a long time ago!)
On 1/7/2025 4:04 PM, Dan Cross wrote:
In article <73aedef89896db7fe5bc43b8d47a8560537c6a48@i2pn2.org>,
John Reagan <johnrreagan@earthlink.net> wrote:
[snip]
I have a copy of Theo De Klerk's book on my bookshelf. I did the
technical review of that book (wow, that is a long time ago!)
It looks like it would be a very nice reference; it's a that it
is no longer available. I wonder if the author retained rights,
or if those lie with Digital Press? If the former, perhaps the
electronic copy others mentioned might show up in the Internet
Archive's library or something similar.
Good question. My last email exchange with Theo was several years ago.
I suspect that Digital Press (or who ever bought all of their IP) would
still own the copyright to that version but could he provide an "almost
final draft" for some archive in much the same way the C/C++ standard >committees provide "drafts" of the standards to avoid copyright issues.
In article <73aedef89896db7fe5bc43b8d47a8560537c6a48@i2pn2.org>,
John Reagan <johnrreagan@earthlink.net> wrote:
[snip]
I have a copy of Theo De Klerk's book on my bookshelf. I did the
technical review of that book (wow, that is a long time ago!)
It looks like it would be a very nice reference; it's a that it
is no longer available. I wonder if the author retained rights,
or if those lie with Digital Press? If the former, perhaps the
electronic copy others mentioned might show up in the Internet
Archive's library or something similar.
- Dan C.
In article <4fce5c9d3be918e8a00edccd228701713d4fd059@i2pn2.org>,
John Reagan <johnrreagan@earthlink.net> wrote:
On 1/7/2025 4:04 PM, Dan Cross wrote:
In article <73aedef89896db7fe5bc43b8d47a8560537c6a48@i2pn2.org>,
John Reagan <johnrreagan@earthlink.net> wrote:
[snip]
I have a copy of Theo De Klerk's book on my bookshelf. I did the
technical review of that book (wow, that is a long time ago!)
It looks like it would be a very nice reference; it's a that it
is no longer available. I wonder if the author retained rights,
or if those lie with Digital Press? If the former, perhaps the
electronic copy others mentioned might show up in the Internet
Archive's library or something similar.
Good question. My last email exchange with Theo was several years ago.
I suspect that Digital Press (or who ever bought all of their IP) would
still own the copyright to that version but could he provide an "almost
final draft" for some archive in much the same way the C/C++ standard
committees provide "drafts" of the standards to avoid copyright issues.
That would be very cool! There aren't that many books about
OpenVMS out there, it seems; even fewer about application
development. It would be great to have a few titles available.
VMS Pascal for C/Java/C# programmers:
https://www.vajhoej.dk/arne/articles/vmspascal.html
It is a "pre-release" - I am not sure I got it right.
So I would love some feedback.
On 1/6/2025 5:52 PM, John Reagan wrote:
On 1/1/2025 11:12 AM, Arne Vajhøj wrote:For modern OpenVMS usage, you might want to discuss how to get 64-bit pointers vs 32-bit pointers. C has the pointer_size pragma to modify
VMS Pascal for C/Java/C# programmers:I'll look and give feedback.
https://www.vajhoej.dk/arne/articles/vmspascal.html
It is a "pre-release" - I am not sure I got it right.
So I would love some feedback.
the "current pointer size". Pascal uses the [QUAD] attribute in front
of the pointer uparrow. There isn't a DCL qualifier (or module-level attribute) to control the default of 32-bits. I'd add one now but who
would use it?
var
ptr64 : [quad] ^integer;
ptr32 : ^integer;
The compiler will call the appropriate Pascal RTL routine for NEW or
NEW64 based on the pointer's type.
On 1/7/2025 6:02 PM, Dan Cross wrote:
In article <4fce5c9d3be918e8a00edccd228701713d4fd059@i2pn2.org>,
John Reagan <johnrreagan@earthlink.net> wrote:
On 1/7/2025 4:04 PM, Dan Cross wrote:
In article <73aedef89896db7fe5bc43b8d47a8560537c6a48@i2pn2.org>,
John Reagan <johnrreagan@earthlink.net> wrote:
[snip]
I have a copy of Theo De Klerk's book on my bookshelf. I did the
technical review of that book (wow, that is a long time ago!)
It looks like it would be a very nice reference; it's a that it
is no longer available. I wonder if the author retained rights,
or if those lie with Digital Press? If the former, perhaps the
electronic copy others mentioned might show up in the Internet
Archive's library or something similar.
Good question. My last email exchange with Theo was several years ago.
I suspect that Digital Press (or who ever bought all of their IP) would
still own the copyright to that version but could he provide an "almost
final draft" for some archive in much the same way the C/C++ standard
committees provide "drafts" of the standards to avoid copyright issues.
That would be very cool! There aren't that many books about
OpenVMS out there, it seems; even fewer about application
development. It would be great to have a few titles available.
Once upon a time there were a reasonable number of of VMS books
available - including about development.
I have a list:
https://www.vajhoej.dk/arne/vms/books.html
But most of them are both not available for sale any longer
and not uptodate (either describe VMS VAX or VMS Alpha).
Probably not enough market today. How many would buy a book
about VMS Pascal development today? 25? 50? 100?
Once upon a time there were a reasonable number of of VMS books
available - including about development.
I have a list:
https://www.vajhoej.dk/arne/vms/books.html
But most of them are both not available for sale any longer
and not uptodate (either describe VMS VAX or VMS Alpha).
Probably not enough market today. How many would buy a book
about VMS Pascal development today? 25? 50? 100?
That's a good question; I have no idea how large the audience
for such things would be, but I suspect it would be small.
However, there's something to be said for written materials that
are in the detail level somewhere between general programming
books about, say, a language or data structures or something,
and the reference manuals for the languages.
I don't think I'm saying anything novel here, but if authors and
publishers are willing to allow some of these older titles to be
distributed electronically, that can start to bridge that gap.
- Dan C.
On 1/7/2025 6:02 PM, Dan Cross wrote:
In article <4fce5c9d3be918e8a00edccd228701713d4fd059@i2pn2.org>,
John Reagan <johnrreagan@earthlink.net> wrote:
On 1/7/2025 4:04 PM, Dan Cross wrote:
In article <73aedef89896db7fe5bc43b8d47a8560537c6a48@i2pn2.org>,
John Reagan <johnrreagan@earthlink.net> wrote:
[snip]
I have a copy of Theo De Klerk's book on my bookshelf. I did the
technical review of that book (wow, that is a long time ago!)
It looks like it would be a very nice reference; it's a that it
is no longer available. I wonder if the author retained rights,
or if those lie with Digital Press? If the former, perhaps the
electronic copy others mentioned might show up in the Internet
Archive's library or something similar.
Good question. My last email exchange with Theo was several years ago.
I suspect that Digital Press (or who ever bought all of their IP) would
still own the copyright to that version but could he provide an "almost
final draft" for some archive in much the same way the C/C++ standard
committees provide "drafts" of the standards to avoid copyright issues.
That would be very cool! There aren't that many books about
OpenVMS out there, it seems; even fewer about application
development. It would be great to have a few titles available.
Once upon a time there were a reasonable number of of VMS books
available - including about development.
I have a list:
https://www.vajhoej.dk/arne/vms/books.html
But most of them are both not available for sale any longer
and not uptodate (either describe VMS VAX or VMS Alpha).
Probably not enough market today. How many would buy a book
about VMS Pascal development today? 25? 50? 100?
Arne
On Wed, 8 Jan 2025 13:08:29 -0000 (UTC), cross@spitfire.i.gajendra.net
(Dan Cross) wrote:
Once upon a time there were a reasonable number of of VMS books
available - including about development.
I have a list:
https://www.vajhoej.dk/arne/vms/books.html
But most of them are both not available for sale any longer
and not uptodate (either describe VMS VAX or VMS Alpha).
Probably not enough market today. How many would buy a book
about VMS Pascal development today? 25? 50? 100?
That's a good question; I have no idea how large the audience
for such things would be, but I suspect it would be small.
BTB, on Arne's list of VMS books, one, at least, should still be
commercially available:
Roland Hughes: The Minimum You Need to Know to Be an OpenVMS
Application Developer
https://www.theminimumyouneedtoknow.com/app_book.html
For years now the question has been surfacing in the OpenVMS community
"Where are the pimply faced kids?" The other situation which seems to continually occur is a developer of one language suddenly finding
themselves having to modify or maintain an application written in a
language completely foreign to them...
Indeed, does anybody under sixty, follow comp.os.vms?
On 1/7/2025 7:00 PM, Arne Vajhøj wrote:
Once upon a time there were a reasonable number of of VMS books
available - including about development.
I have a list:
https://www.vajhoej.dk/arne/vms/books.html
But most of them are both not available for sale any longer
and not uptodate (either describe VMS VAX or VMS Alpha).
Probably not enough market today. How many would buy a book
about VMS Pascal development today? 25? 50? 100?
If a book has an electronic format, does it matter how many would
purchase it?
Speaking of books, I have one that I may never have use for again:
VAX/VMS Internals and Data Structures
Ruth E. Goldenberg
Lawrence J. Kenah
Version 5.2
Also had an earlier version, but haven't seen it for some time ...
Question for Camiel: will you be writing the one for VMS x86-64 9.2?
On 1/8/2025 19:35, Arne Vajhøj wrote:
Question for Camiel: will you be writing the one for VMS x86-64 9.2?
We do plan to put out a white paper on some X86 changes related to
kernel mode
I/O work.
Specifically, the SVAPTE mechanism has been replaced with what we view
as a cleaner
mechanism for driver writers.
On 1/8/2025 7:09 PM, Dave Froble wrote:
On 1/7/2025 7:00 PM, Arne Vajhøj wrote:
Once upon a time there were a reasonable number of of VMS books
available - including about development.
I have a list:
https://www.vajhoej.dk/arne/vms/books.html
But most of them are both not available for sale any longer
and not uptodate (either describe VMS VAX or VMS Alpha).
Probably not enough market today. How many would buy a book
about VMS Pascal development today? 25? 50? 100?
If a book has an electronic format, does it matter how many would
purchase it?
The variable cost per copy would be very small (maybe only
the fee for processing payment).
But there is also fixed cost for distributing electronically.
Decide on what to do to prevent illegal copying. Generate the
file to distribute. Get it up on some e-commerce web site.
Not zero but not that expensive either. It would require a little
bit of sale though.
The problem will likely be that even if it would financially
be positive, then the amount would be very small. If the copyright
owner is an individual, then a plus of a few hundred or thousand
dollars will be OK. But if the copyright owner is
Big Mega Publishing Inc, then they will not do anything
with an expected profit under hundreds of thousands of dollars.
Indeed, does anybody under sixty, follow comp.os.vms?
In article <vln5d0$318c0$2@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
The problem will likely be that even if it would financially
be positive, then the amount would be very small. If the copyright
owner is an individual, then a plus of a few hundred or thousand
dollars will be OK. But if the copyright owner is
Big Mega Publishing Inc, then they will not do anything
with an expected profit under hundreds of thousands of dollars.
Many technical books that previously cost rather tidy sums are
now available for free, as authors and publishers realized that
the audience had dwindled to negligible and there was no longer
a financial incentive to holding on to the IP.
It's kind of weirdly fascinating how thing that used to cost
staggering sums are now available just for free.
There were at least:
* VMS VAX 4.4
* VMS VAX 5.2
* VMS Alpha 1.5
Not sure if there were for earlier VMS versions.
No:
* VMS Alpha 7.x (64 bit !)
* VMS Itanium
Question for Camiel: will you be writing the one for VMS x86-64 9.2?
For years now the question has been surfacing in the OpenVMS communityNo one knows what it is, let alone how to use it. Thus, there is no
"Where are the pimply faced kids?"
Indeed, does anybody under sixty, follow comp.os.vms?I lurk here and IRC 2600 #vms occasionally. Now that Google Groups is
On 2025-01-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
There were at least:
* VMS VAX 4.4
* VMS VAX 5.2
* VMS Alpha 1.5
Not sure if there were for earlier VMS versions.
No:
* VMS Alpha 7.x (64 bit !)
There was a memory or process supplement book published IIRC however.
* VMS Itanium
Question for Camiel: will you be writing the one for VMS x86-64 9.2?
He and other VSI employees had previously said no to a full book but the posting from Rob in this thread about a selective release of changes is welcome news.
Subcommandante XDelta <vlf@star.enet.dec.com> writes:
For years now the question has been surfacing in the OpenVMS communityNo one knows what it is, let alone how to use it. Thus, there is no
"Where are the pimply faced kids?"
demand for it. How would a young guy, say 15 year's old, go about
getting his hands on it?
It's not being taught in colleges anymore and you can't
legally get it at home.
The products and licenses are laughably expensive,
especially when compared to other systems like Windows, Mac, and of
course Linux. Even when there was a real hobbyist program, it was very restrictive. Expensive software running on expensive hardware might have worked in the 1980s, but it doesn't work now.
Unfortunately, the
business model wasn't updated to today's time. That is why there's no
new community members.
I was speaking to a well-known member of the community a few months
back on IRC, and even he said it was far easier and much, much cheaper to set up a new server running something other than VMS. Even VSI's web server
runs on Ubuntu if I'm not mistaken.
Indeed, does anybody under sixty, follow comp.os.vms?I lurk here and IRC 2600 #vms occasionally. Now that Google Groups is
dead, the place (and usenet itself) is usable again.
On 2025-01-08, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
In article <vln5d0$318c0$2@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
The problem will likely be that even if it would financially
be positive, then the amount would be very small. If the copyright
owner is an individual, then a plus of a few hundred or thousand
dollars will be OK. But if the copyright owner is
Big Mega Publishing Inc, then they will not do anything
with an expected profit under hundreds of thousands of dollars.
Many technical books that previously cost rather tidy sums are
now available for free, as authors and publishers realized that
the audience had dwindled to negligible and there was no longer
a financial incentive to holding on to the IP.
It's kind of weirdly fascinating how thing that used to cost
staggering sums are now available just for free.
Indeed.
About 20 years ago I found the VMS device drivers in C book in
a local large bookshop (either York or Leeds, I don't remember).
Such a thing would be utterly unheard of these days.
On 2025-01-09, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
About 20 years ago I found the VMS device drivers in C book in
a local large bookshop (either York or Leeds, I don't remember).
Such a thing would be utterly unheard of these days.
I was curious so I looked further and found the receipt still in the
book. I purchased it from Waterstones at 9-10 High Ousegate in York
on 26.06.01 at 16:05.
So, 20 years ago, you could purchase VMS Digital Press books directly
from a major high street bookseller. I also very strongly suspect it
was on the shelf in the shop because I would have used a more local Waterstones if I was going to ask them to order it.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 432 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 30:19:23 |
| Calls: | 9,081 |
| Calls today: | 4 |
| Files: | 13,409 |
| Messages: | 6,022,133 |