Hi.

Just got a mail with a link to:

"Community license for Alpha servers, valid until September 2023".

Downloaded a COM file LMF commands for ALPHA-SYSTEM and ALPHA-LP.

They could name the file xxx_COM.TXT instead of xxx.COM so
that Windows doesn't think it is an executable COM file...

On Wed, 2022-09-14 at 15:16 +0200, Jan-Erik Söderholm wrote:
> Hi.
>
> Just got a mail with a link to:
>
> "Community license for Alpha servers, valid until September 2023".
>
> Downloaded a COM file LMF commands for ALPHA-SYSTEM and ALPHA-LP.
>
> They could name the file xxx_COM.TXT instead of xxx.COM so
> that Windows doesn't think it is an executable COM file...

I just got mine.

Unfortunately I tihnk someone has got the licences wrong. Last year's
licence was authorised for HOBBYIST, the I got this year is authorised
for "EVAL".

/AUTHORIZATION=HOBY-VSICOMMUNITY-XXCENSOREDXX
vs.
/AUTHORIZATION=EVAL-XXXXXXXXXXXXXXXXXXXXXXXXX

Is that correct or is it plain wrong?
--
Tactical Nuclear Kittens

On 9/14/2022 1:58 PM, Single Stage to Orbit wrote:
> On Wed, 2022-09-14 at 15:16 +0200, Jan-Erik Söderholm wrote:
>> Hi.
>>
>> Just got a mail with a link to:
>>
>> "Community license for Alpha servers, valid until September 2023".
>>
>> Downloaded a COM file LMF commands for ALPHA-SYSTEM and ALPHA-LP.
>>
>> They could name the file xxx_COM.TXT instead of xxx.COM so
>> that Windows doesn't think it is an executable COM file...
>
> I just got mine.
>
> Unfortunately I tihnk someone has got the licences wrong. Last year's
> licence was authorised for HOBBYIST, the I got this year is authorised
> for "EVAL".
>
> /AUTHORIZATION=HOBY-VSICOMMUNITY-XXCENSOREDXX
> vs.
> /AUTHORIZATION=EVAL-XXXXXXXXXXXXXXXXXXXXXXXXX
>
> Is that correct or is it plain wrong?

If the license loads and the products run, it's correct.

I don't know why authorization string would have changed, but as
long as it's good for a year, it really does not matter.

My *guess* is that the same process is being used for the hobby generation as it
is for potential customers receiving short-term (30/60 day) time-limited licenses.

--

--- Rob

On Wed, 2022-09-14 at 15:59 -0400, Robert A. Brooks wrote:
> On 9/14/2022 1:58 PM, Single Stage to Orbit wrote:
> > On Wed, 2022-09-14 at 15:16 +0200, Jan-Erik Söderholm wrote:
> >
> > /AUTHORIZATION=HOBY-VSICOMMUNITY-XXCENSOREDXX
> > vs.
> > /AUTHORIZATION=EVAL-XXXXXXXXXXXXXXXXXXXXXXXXX
> >
> > Is that correct or is it plain wrong?
>
> If the license loads and the products run, it's correct.
>
> I don't know why authorization string would have changed, but as
> long as it's good for a year, it really does not matter.
>
> My *guess* is that the same process is being used for the hobby
> generation as it is for potential customers receiving short-term
> (30/60 day) time-limited licenses.

Fair enough, I'll boot up my AXP emulator and load the licences in.

Many thanks.
--
Tactical Nuclear Kittens

On Wednesday, September 14, 2022 at 6:16:14 AM UTC-7, Jan-Erik Söderholm wrote:

(snip)

> They could name the file xxx_COM.TXT instead of xxx.COM so
> that Windows doesn't think it is an executable COM file...

Yes, why did Windows use the COM extension, for something else,
when VMS already had a use for it.

As well as I know it, Windows executes file appropriately,
independent of extension, if they have one of COM, EXE, BAT, CMD,
and probably others that I forgot.

That is, it doesn't use the extension to decide how to run it.

On 9/14/2022 6:46 PM, gah4 wrote:
> On Wednesday, September 14, 2022 at 6:16:14 AM UTC-7, Jan-Erik Söderholm wrote:
>> They could name the file xxx_COM.TXT instead of xxx.COM so
>> that Windows doesn't think it is an executable COM file...
>
> Yes, why did Windows use the COM extension, for something else,
> when VMS already had a use for it.

Windows inherited it from DOS. And DOS supposedly inherited it from CP/M.

> As well as I know it, Windows executes file appropriately,
> independent of extension, if they have one of COM, EXE, BAT, CMD,
> and probably others that I forgot.
>
> That is, it doesn't use the extension to decide how to run it.

I would have thougth that EXE/COM and BAT/CMD was treated
differently.

Arne

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>On 9/14/2022 6:46 PM, gah4 wrote:
>> On Wednesday, September 14, 2022 at 6:16:14 AM UTC-7, Jan-Erik Söderholm wrote:
>>> They could name the file xxx_COM.TXT instead of xxx.COM so
>>> that Windows doesn't think it is an executable COM file...
>>
>> Yes, why did Windows use the COM extension, for something else,
>> when VMS already had a use for it.
>
>Windows inherited it from DOS. And DOS supposedly inherited it from CP/M.

Yes, and CP/M inherited most things from RT-11.... but... not this one.
In RT-11 the .COM file is a command language script just like in VMS.
So you can blame Gary for this one.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On Wednesday, September 14, 2022 at 4:05:01 PM UTC-7, Arne Vajhøj wrote:
>
(snip, I wrote)

> > That is, it doesn't use the extension to decide how to run it.

> I would have thougth that EXE/COM and BAT/CMD was treated
> differently.

As far as I know, early DOS days it did keep EXE and COM separate.
Then some system programs changed, but to avoid confusion they
kept the old extension. The system can tell them apart.

CMD came from OS/2, and BAT from MS-DOS. Windows accepts both.

It does seem that it could separate EXE/COM from BAT/CMD, but as
I understand, it doesn't.

I remember EXE back to TOPS-10 days, but that was before I knew
about RT-11. Somewhere in the DEC days, anyway.

> Just got a mail with a link to:
>
> "Community license for Alpha servers, valid until September 2023".

My e-mail had links labelled "Get your Integrity license" and "Get
your Alpha license".

> Downloaded a COM file LMF commands for ALPHA-SYSTEM and ALPHA-LP.

My links led to ".zip" archives (so no ".COM" problem):

ALPHA_COMMUNITY_LICENSE_PAK.zip
INTEGRITY_COMMUNITY_LICENSE_PAK.zip

which contained:

INTEGRITY_COMMUNITY_LICENSE_PAK_SEP_2022.COM
ALPHA_COMMUNITY_LICENSE_PAK_SEP_2022.COM

which UnZip 6.00 extracted as Record format: Stream_LF, with
bonus/spurious CR line endings.

To avoid the defective line endings, you could use "unzip -a" when
unpacking, or "set file /attr = rfm:stm" after unpacking (without "-a").

Apparently my suggestion to use an easily sortable date format in
such file names failed to have any effect.

gah4 wrote:
> I remember EXE back to TOPS-10 days, but that was before I knew
> about RT-11. Somewhere in the DEC days, anyway.

I don't know if TOPS-10 or TOPS-20 introduced .EXE first. Or if
they did it at the same time? Before that there were things like
..SAV and .SHR.

Den 2022-09-15 kl. 06:23, skrev Steven Schweda:
>> Just got a mail with a link to:
>>
>> "Community license for Alpha servers, valid until September 2023".
>
> My e-mail had links labelled "Get your Integrity license" and "Get
> your Alpha license".
>
>> Downloaded a COM file LMF commands for ALPHA-SYSTEM and ALPHA-LP.
>
> My links led to ".zip" archives (so no ".COM" problem):
>
> ALPHA_COMMUNITY_LICENSE_PAK.zip
> INTEGRITY_COMMUNITY_LICENSE_PAK.zip
>

Sure, but the Windows Explorer shows the zip content and you can
open the file from there. But if the file has an .COM extension,
you do not get all the right-click options, such as e.g. Notepad.

If the file is first saved to an uncompressed directory, a right-
click gives the usual file handling options, including Notepad.
No big deal...

That worked fine in this case, but sometimes the COM files has
VMS file attributes that implies line/record endings that are
not understod, and it is just displayed as a mass of text.
Need to first unzip on VMS to be able to read the text files.

And it is no big deal, I simply rename it to xxx_COM.TXT in my
laptop repository of VMS related files.

> Sure, but the Windows Explorer shows the zip content [...]

My complaint is more general; Windows was not involved at my end. It
looks as if it might have been involved at VSI:

$ unzip -Zv ALPHA_COMMUNITY_LICENSE_PAK.zip

Archive: SYS$SYSROOT:[SYSMGR]ALPHA_COMMUNITY_LICENSE_PAK.zip;1
There is no zipfile comment.
[...]

Central directory entry #1:
---------------------------

ALPHA_COMMUNITY_LICENSE_PAK_SEP_2022.COM

offset of local header from start of archive: 0
(0000000000000000h) bytes
file system or operating system of origin: MS-DOS, OS/2 or NT FAT
[...]

> Need to first unzip on VMS to be able to read the text files.

Did you try that? That's exactly what led to the faulty line endings
in the .COM files on my VMS system. (That, combined with the way the
..zip archives and their contents were made.)

$ @ ALPHA_COMMUNITY_LICENSE_PAK_SEP_2022.COM
%DCL-W-MAXPARM, too many parameters - reenter command with fewer parameters
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-MAXPARM, too many parameters - reenter command with fewer parameters
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character

A different file was also not a roaring success for what might be
related reasons: sys$help:VSI_OPENVMS_CRTL_NOTES.TXT (part of the
RTL-V0500 patch). I suspect that that one looked fine on a Windows
system, too.

It's possible that VMS users would have less trouble if VSI used VMS
more.

On 9/14/2022 8:16 AM, Jan-Erik Söderholm wrote:
> Hi.
>
> Just got a mail with a link to:
>
> "Community license for Alpha servers, valid until September 2023".
>
> Downloaded a COM file LMF commands for ALPHA-SYSTEM and ALPHA-LP.
>
> They could name the file xxx_COM.TXT instead of xxx.COM so
> that Windows doesn't think it is an executable COM file...
>

I usually rename mine to .DCL on my Mac so it doesn't think it's a Windows file.

--
John H. Reinhardt

Den 2022-09-15 kl. 15:41, skrev Steven Schweda:
>> Sure, but the Windows Explorer shows the zip content [...]
>
> My complaint is more general; Windows was not involved at my end. It
> looks as if it might have been involved at VSI:
>
> $ unzip -Zv ALPHA_COMMUNITY_LICENSE_PAK.zip
>
> Archive: SYS$SYSROOT:[SYSMGR]ALPHA_COMMUNITY_LICENSE_PAK.zip;1
> There is no zipfile comment.
> [...]
>
> Central directory entry #1:
> ---------------------------
>
> ALPHA_COMMUNITY_LICENSE_PAK_SEP_2022.COM
>
> offset of local header from start of archive: 0
> (0000000000000000h) bytes
> file system or operating system of origin: MS-DOS, OS/2 or NT FAT
> [...]
>
>
>> Need to first unzip on VMS to be able to read the text files.
>
> Did you try that? That's exactly what led to the faulty line endings
> in the .COM files on my VMS system. (That, combined with the way the
> .zip archives and their contents were made.)
>
> $ @ ALPHA_COMMUNITY_LICENSE_PAK_SEP_2022.COM
> %DCL-W-MAXPARM, too many parameters - reenter command with fewer parameters
> %DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
> %DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
> %DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
> %DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
> %DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
> %DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
> %DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
> %DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
> %DCL-W-MAXPARM, too many parameters - reenter command with fewer parameters
> %DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
> %DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
> %DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
> %DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
> %DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
> %DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
> %DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
> %DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
>
>
> A different file was also not a roaring success for what might be
> related reasons: sys$help:VSI_OPENVMS_CRTL_NOTES.TXT (part of the
> RTL-V0500 patch). I suspect that that one looked fine on a Windows
> system, too.
>
> It's possible that VMS users would have less trouble if VSI used VMS
> more.

Good points, of course. I have not tried to move he zip to any
VMS system, just wanted to look at the COM file... :-)

Now, when it comes to these basic LMF files, it is not uncommon
that one has to copy/paste the content into a console window, and
since the emulated environments usually are on Windows, a Windows
compatilble file might be the right thing anyway.

And it is fine to copy into the console of any AlphaServer also.

On Wednesday, September 14, 2022 at 10:39:20 PM UTC-7, Lars Brinkhoff wrote:
> gah4 wrote:
> > I remember EXE back to TOPS-10 days, but that was before I knew
> > about RT-11. Somewhere in the DEC days, anyway.

> I don't know if TOPS-10 or TOPS-20 introduced .EXE first. Or if
> they did it at the same time? Before that there were things like
> .SAV and .SHR.

I didn't know about TOPS-20 until some years later.

Yes, the usual TOPS-10 file was .SAV, which you got from the SAVE
command, which pretty much wrote memory to disk.

I think I remember the transition for TOPS-10, in about 1977.

> [...] I have not tried to move [t]he zip to any VMS system, [...]

You should. (I claim.)

> [...] since the emulated environments usually are on Windows, [...]

Mine are on Macs.

> [...] a Windows compatilble file might be the right thing anyway.

Who says that "a Windows compatilble file" can't also be naturally
VMS-compatible? If you fetch any of the software kits from
antinode.info, do you have any trouble reading the text files in them on
a Windows system?

This is starting to sound like those old (bogus) claims that a
"zip -V" archive is _supposed_ to appear corrupt on a non-VMS system.

In article <tfsk6o$2tu7b$2@dont-email.me>,
=?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik.soderholm@telia.com>
writes:

> Hi.
>
> Just got a mail with a link to:
>
> "Community license for Alpha servers, valid until September 2023".
>
> Downloaded a COM file LMF commands for ALPHA-SYSTEM and ALPHA-LP.
>
> They could name the file xxx_COM.TXT instead of xxx.COM so
> that Windows doesn't think it is an executable COM file...

Maybe they just want to ignore folks who do VMS-related stuff on
Windows. :-)

In article <d0c84e94-ede0-448d-a191-ce0d903756c4n@googlegroups.com>,
Steven Schweda <sms.antinode@gmail.com> writes:

> > Just got a mail with a link to:
> >
> > "Community license for Alpha servers, valid until September 2023".
>
> My e-mail had links labelled "Get your Integrity license" and "Get
> your Alpha license".
>
> > Downloaded a COM file LMF commands for ALPHA-SYSTEM and ALPHA-LP.
>
> My links led to ".zip" archives (so no ".COM" problem):
>
> ALPHA_COMMUNITY_LICENSE_PAK.zip
> INTEGRITY_COMMUNITY_LICENSE_PAK.zip
>
> which contained:
>
> INTEGRITY_COMMUNITY_LICENSE_PAK_SEP_2022.COM
> ALPHA_COMMUNITY_LICENSE_PAK_SEP_2022.COM
>
> which UnZip 6.00 extracted as Record format: Stream_LF, with
> bonus/spurious CR line endings.
>
> To avoid the defective line endings, you could use "unzip -a" when
> unpacking, or "set file /attr = rfm:stm" after unpacking (without "-a").

Surely they should have used /VMS when zipping it.

gah4 <gah4@u.washington.edu> writes:

> On Wednesday, September 14, 2022 at 10:39:20 PM UTC-7, Lars Brinkhoff wrote:
>> gah4 wrote:

>>> I remember EXE back to TOPS-10 days, but that was before I knew
>>> about RT-11. Somewhere in the DEC days, anyway.

>> I don't know if TOPS-10 or TOPS-20 introduced .EXE first. Or if
>> they did it at the same time? Before that there were things like
>> .SAV and .SHR.

> I didn't know about TOPS-20 until some years later.

> Yes, the usual TOPS-10 file was .SAV, which you got from the SAVE
> command, which pretty much wrote memory to disk.

> I think I remember the transition for TOPS-10, in about 1977.

I believe that the .EXE format for executables was introduced by TENEX, the BBN
operating system for the PDP-10 with attached BBN pager, for experiments in
demand-paged virtual memory.

(TOPS-20 was DEC's development of TENEX, with appropriate licensing. Think VSI.)

The .EXE format was ported to Tops-10 later; TOPS-20 was introduced in 1974/5.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

> Surely they should have used /VMS when zipping it.

You seem to assume that they used Info-ZIP Zip on a VMS system when
making the archive. Evidence suggests otherwise. See above:

> file system or operating system of origin: MS-DOS, OS/2 or NT FAT

I suspect that if the file had been created/stored on a VMS system
and was (easily) readable there, and they had used Info-ZIP Zip on a VMS
system when making the archive, then -V (/VMS) wouldn't have mattered.

I also suspect that if you had a file on a Windows system, with CR+LF
line endings, and used Info-ZIP Zip on a Windows system with "-ll" (as
the "zip -h" help says, "-l convert LF to CR LF (-ll CR LF to LF)"),
then the results might have been better, too.

What does _not_ work well is whatever they actually did with
whichever tools they actually used.

As invited ("If you have any problems or questions, contact us
[...]"), I sent a complaint to the "community" e-mail address. The
reply said:

Thank you for your comments and sorry for the inconvenience. We
will consider changing our process.

So, perhaps all will be well in the future. (Better documentation of
the work-arounds would be better than nothing, but I suspect that
someone at VSI can puzzle out a procedure which can take what they start
with and produce a universally acceptable product.)

On 9/17/2022 4:15 PM, Phillip Helbig (undress to reply) wrote:

> Surely they should have used /VMS when zipping it.
>

It is my impression that many at VSI have no problem with using WEENDOZE ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

Rich Alderson wrote:
> I believe that the .EXE format for executables was introduced by
> TENEX, the BBN operating system for the PDP-10 with attached BBN
> pager, for experiments in demand-paged virtual memory.

The TENEX format is not exactly the same as the TOPS-20 .EXE, but it's
similar. TENEX names executable files .SAV, not .EXE. TOPS-20 can load
the TENEX format.

I examined the TENEX .SAV format in detail and documented it here:
https://gunkies.org/wiki/TENEX_sharable_save_file

On 9/17/22 21:27, Dave Froble wrote:
> On 9/17/2022 4:15 PM, Phillip Helbig (undress to reply) wrote:
>
>> Surely they should have used /VMS when zipping it.
>>
>
> It is my impression that many at VSI have no problem with using WEENDOZE
> ...
>

That's probably because most serious VMS users moved out of the 80's
a long time ago. Being as VMS has apparently given up on the desktop
permanently what would you expect most VMS users to be using on their
desktop?

It is interesting that VMS now runs on the hardware found on 99% of
the desktops and there is considerable interest in the concept of
using obscure OSes as a security enhancement (see the latest copy
of CACM for a mention) but we still see no interest in even probing
that niche. :-)

bill

In article <jooqruFccnfU1@mid.individual.net>, Bill Gunshannon
<bill.gunshannon@gmail.com> writes:

> That's probably because most serious VMS users moved out of the 80's
> a long time ago. Being as VMS has apparently given up on the desktop
> permanently what would you expect most VMS users to be using on their
> desktop?

If you are using VMS, it doesn't have to be on your desktop, but it
could be.

On 9/18/22 11:19, Phillip Helbig (undress to reply) wrote:
> In article <jooqruFccnfU1@mid.individual.net>, Bill Gunshannon
> <bill.gunshannon@gmail.com> writes:
>
>> That's probably because most serious VMS users moved out of the 80's
>> a long time ago. Being as VMS has apparently given up on the desktop
>> permanently what would you expect most VMS users to be using on their
>> desktop?
>
> If you are using VMS, it doesn't have to be on your desktop, but it
> could be.
>

Maybe if your still running a VAX. I thought VSI said "No desktop"?

bill