Discussion:
FreeAXP
(too old to reply)
Chris Townley
2020-08-12 22:54:09 UTC
Permalink
Finally been made redundant, and having to lose the VMS systems 7 years ago, I am trying to get back onboard with VMS.

My Alpha workstation needs a bit of work, so playing with FreeAXP.

I installed 8.3 on FreeAXP in 2017, but realise I am a bit out of date with version 3.0. They talk about new installations have changed all the directories, but I cannot find any guides to upgrading to the latest 4...

Has anybody any recommendations?


Regards


Chris
El SysMan
2020-08-17 14:01:06 UTC
Permalink
Post by Chris Townley
Finally been made redundant, and having to lose the VMS systems 7 years ago, I am trying to get back onboard with VMS.
My Alpha workstation needs a bit of work, so playing with FreeAXP.
I installed 8.3 on FreeAXP in 2017, but realise I am a bit out of date with version 3.0. They talk about new installations have changed all the directories, but I cannot find any guides to upgrading to the latest 4...
Has anybody any recommendations?
Regards
Chris
Deploying of an Alpha/VMS instance on FreeAXP simple as write sys$output "Hello VMS micro-World!".
Just try, u will be a winner in this task in 10 minutes.
Chris Townley
2020-08-17 18:39:33 UTC
Permalink
четверг, 13 августа 2020 г. в 01:54:10 UTC+3,
Deploying of an Alpha/VMS instance on FreeAXP simple as write sys$output "Hello VMS micro-World!".
Just try, u will be a winner in this task in 10 minutes.
I am familiar with VMS, and have been running FreeAXP for over 3 years - I was worried about the configuration change upgrading to v4

However I had a swift response on the freeAXP forum, and now running the new version - with both HP VMS 8.3 and now VSI VMS V8.4-2L1 - impressed so far...

Next to consider my physical alpha...

Chris
richard...@gmail.com
2020-09-01 01:55:28 UTC
Permalink
Post by Chris Townley
четверг, 13 августа 2020 г. в 01:54:10 UTC+3,
Deploying of an Alpha/VMS instance on FreeAXP simple as write sys$output "Hello VMS micro-World!".
Just try, u will be a winner in this task in 10 minutes.
I am familiar with VMS, and have been running FreeAXP for over 3 years - I was worried about the configuration change upgrading to v4
However I had a swift response on the freeAXP forum, and now running the new version - with both HP VMS 8.3 and now VSI VMS V8.4-2L1 - impressed so far...
Next to consider my physical alpha...
Chris
I am not having any luck with the VSI Alpha/OpenVMS v8.4.2L1 ISO images. The *.ZIPEXE do not execute on an Alpha, nor does my Windows UnZip like it. However, my HPE Alpha/OpenVMS v7.3-2 UnZip on a a H/W Alpha can extract the ISO file with reported errors, but then the ISO file is incompatible with my Win10 system that I would use to burn to a CD.

BUT, the same VSI site with the VSI Alpha/OpenVMS v8.4-2L1 ALPHA0842L1DOC.ZIPEXE does work and produces a working ISO file that can be burned by Win10.

What might I be doing wrong? Any suggestions?

Thanks,
Rick
Steven Schweda
2020-09-01 03:15:30 UTC
Permalink
Post by ***@gmail.com
I am not having any luck with the VSI Alpha/OpenVMS
v8.4.2L1 ISO images. [...]
"not having any luck with" is not a particularly useful
problem description.
Post by ***@gmail.com
[...] The *.ZIPEXE do not execute on an Alpha, [...]
The UnZip self-extractor (UnZipSFX) is
architecture/OS-specific, so that's not amazing.
Post by ***@gmail.com
[...] nor does my Windows UnZip like it. [...]
I know nothing about your "my Windows UnZip", or how,
exactly, you determined whether that program did or did not
"like" anything. As usual, showing actual actions (commands)
with their actual results (error messages, ...) can be more
helpful than vague descriptions or interpretations.
Copy+paste is your friend.
Post by ***@gmail.com
[...] However, my HPE Alpha/OpenVMS v7.3-2 UnZip on a a H/W
Alpha can extract the ISO file with reported errors, [...]
Which "reported errors"? Anything beyond a warning about
"nnn extra bytes at beginning or within zipfile" would be
especially interesting.
Post by ***@gmail.com
[...] but then the ISO file [...]
ISO is a standards organization, not, in itself, a type of
disk image file.

https://www.iso.org
Post by ***@gmail.com
[...] is incompatible with my Win10 system that I would use
to burn to a CD.
Again, your conclusion of "incompatible", although
interesting, conveys no actual information about how you
reached it. That is, what you did, or what happened when you
did it.

VMS distribution media tend to contain some VMS-specific
file system, not always an ISO-9660 (or similar) file system.
This can cause some optical-disc-writing programs to be
confused/dissatisfied, because they don't see what they
expect to see in such a disc image. Interestingly, on a Mac,
the Finder's 'Burn Disk Image "XXX" to Disc...' option ("Burn
Disc") worked just fine for me. On Windows, you may need to
find a program which is willing to burn whatever you tell it
to burn to a disc.
Post by ***@gmail.com
What might I be doing wrong? [...]
Ask someone who can see what you're doing?
geze...@rlgsc.com
2020-09-01 04:22:22 UTC
Permalink
Post by Steven Schweda
Post by ***@gmail.com
I am not having any luck with the VSI Alpha/OpenVMS
v8.4.2L1 ISO images. [...]
"not having any luck with" is not a particularly useful
problem description.
Post by ***@gmail.com
[...] The *.ZIPEXE do not execute on an Alpha, [...]
The UnZip self-extractor (UnZipSFX) is
architecture/OS-specific, so that's not amazing.
Post by ***@gmail.com
[...] nor does my Windows UnZip like it. [...]
I know nothing about your "my Windows UnZip", or how,
exactly, you determined whether that program did or did not
"like" anything. As usual, showing actual actions (commands)
with their actual results (error messages, ...) can be more
helpful than vague descriptions or interpretations.
Copy+paste is your friend.
Post by ***@gmail.com
[...] However, my HPE Alpha/OpenVMS v7.3-2 UnZip on a a H/W
Alpha can extract the ISO file with reported errors, [...]
Which "reported errors"? Anything beyond a warning about
"nnn extra bytes at beginning or within zipfile" would be
especially interesting.
Post by ***@gmail.com
[...] but then the ISO file [...]
ISO is a standards organization, not, in itself, a type of
disk image file.
https://www.iso.org
Post by ***@gmail.com
[...] is incompatible with my Win10 system that I would use
to burn to a CD.
Again, your conclusion of "incompatible", although
interesting, conveys no actual information about how you
reached it. That is, what you did, or what happened when you
did it.
VMS distribution media tend to contain some VMS-specific
file system, not always an ISO-9660 (or similar) file system.
This can cause some optical-disc-writing programs to be
confused/dissatisfied, because they don't see what they
expect to see in such a disc image. Interestingly, on a Mac,
the Finder's 'Burn Disk Image "XXX" to Disc...' option ("Burn
Disc") worked just fine for me. On Windows, you may need to
find a program which is willing to burn whatever you tell it
to burn to a disc.
Post by ***@gmail.com
What might I be doing wrong? [...]
Ask someone who can see what you're doing?
Chris,

Just use ISO file directly on FreeAXP. There should be no reason to actually burn a physical disk.

- Bob Gezelter, http://www.rlgsc.com
richard...@gmail.com
2020-09-01 05:01:49 UTC
Permalink
Post by ***@rlgsc.com
Post by ***@gmail.com
I am not having any luck with the VSI Alpha/OpenVMS
v8.4.2L1 ISO images. [...]
Just use ISO file directly on FreeAXP. There should be no reason to actually burn a physical disk.
- Bob Gezelter, http://www.rlgsc.com
Thank you Bob.

That is what I thought to try on a whim soon after I posted earlier.

I moved the install disk image output by the H/W Alpha running UnZip to the Windows system running FreeAXP and mounted the *.ISO file as a disk image. Then booted my FreeAXP server from it and upgraded from HP Alpha/OpenVMS v7.3-2 to VSI Alpha/OpenVMS v8.4-2L1. So far, it is running. Worked through the new VSI licenses and it seems to be working.

It still begs the answer to the question: How does one start with the VSI self-extracting ZIP file of the ISO CD Image (called an .ISO file) actually burned onto a physical CD to be used in my H/W Alpha, which is my real end purpose. The FreeAXP server is a fun and useful tool, but not viable for our group's intended use. In fact, I would say this is a great example of it's use. A dry run, testing sandbox for upgrading or migrating, etc.

Rick
Steven Schweda
2020-09-01 05:21:03 UTC
Permalink
[...] How does one start with the VSI self-extracting ZIP file of the
ISO CD Image (called an .ISO file) actually burned onto a physical CD to
be used in my H/W Alpha,
Use a competent unzip program to extract the disc image file from the
zip archive. Info-ZIP UnZip runs on Windows, and plenty of others
should be able to do the job, too.

Use a competent disc-writing program to write the CD.

People have been doing this for years, so I'd bet that a Web search
for terms like, say:

burn vms cd windows

would find a few recommendations for disc-burning programs.
It still begs the answer to the question: [...]
I had some questions, too.
Chris Townley
2020-09-01 10:46:10 UTC
Permalink
Post by Steven Schweda
[...] How does one start with the VSI self-extracting ZIP file of the
ISO CD Image (called an .ISO file) actually burned onto a physical CD to
be used in my H/W Alpha,
Use a competent unzip program to extract the disc image file from the
zip archive. Info-ZIP UnZip runs on Windows, and plenty of others
should be able to do the job, too.
Use a competent disc-writing program to write the CD.
People have been doing this for years, so I'd bet that a Web search
burn vms cd windows
would find a few recommendations for disc-burning programs.
It still begs the answer to the question: [...]
I had some questions, too.
I simply opened the .ZIPEXE files in turn in WinXIP, and dragged the ISO file to Windows disk, I then opened them with FreeAXP. Worked for me except for the two VMS install errors reported elsewhere

Chris
Hunter Goatley
2020-09-01 12:20:00 UTC
Permalink
Post by Steven Schweda
Use a competent disc-writing program to write the CD.
People have been doing this for years, so I'd bet that a Web search
burn vms cd windows
would find a few recommendations for disc-burning programs.
That would be ImgBurn, the only disc-burning tool I've used on Windows
since 1999.

http://imgburn.com/
--
Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
***@goatley.com http://hunter.goatley.com/
Bob Wilson
2020-09-01 12:37:58 UTC
Permalink
Post by Hunter Goatley
Post by Steven Schweda
Use a competent disc-writing program to write the CD.
People have been doing this for years, so I'd bet that a Web search
burn vms cd windows
would find a few recommendations for disc-burning programs.
That would be ImgBurn, the only disc-burning tool I've used on Windows
since 1999.
http://imgburn.com/
--
Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
I've used ImgBurn, and it's done the job...however, their web site is a mess. I found it pretty tough to find the ImgBurn kit amongst all of the noise (i.e. I downloaded a junk-ware kit or two before finding the ImgBurn kit in a *tiny* lightweight typeface). In addition, in their installation there's some junk-ware that you need to opt-out of, lest you end up with some unexpected baggage.

Be careful if you choose to download and install ImgBurn (once installed it works like a champ).

n.b. I found on my Window-7 system, which I installed from a OEM kit, there was *no* disc burning application supplied with the kit. Maybe Windows supplies one now, but at the time that I was doing the testing I had to find something to do-the-deed.

bw
Bob Wilson
2020-09-01 12:58:57 UTC
Permalink
The MD5 checksum for ALPHA0842L1.ZIPEXE is:

"2228FC25D9640A16A57BADA6D8C609EC"

I believe this is the one that you're using...if it's a different one please post the file name and I'll re-do.

bw
Bob Wilson
2020-09-01 12:29:03 UTC
Permalink
Rick Dyson:

I hate to sound pedantic, but are you certain that you used a binary mode transfer? (been there, done that)

Also, anecdotally: The .zipexe passing through multiple file systems (VMS -> linux -> Windows -> ...) has apparently introduced corruption (you can never really tell what happens once stuff goes out into the wild [and when/how something was corrupted])

If all else fails, you could generate a MD5 checksum in a case where someone (any volunteers) is known to have successfully "run" the .zipexe, and compare it to a MD5 checksum of the file that you're trying to "run".

If there are no volunteers, :-), I could generate a MD5 checksum from the version of the file on the VSI server where these files are sourced for external distribution.

n.b. We use the .ISO file type because most tools for burning discs (Windows, linux & Mac) seem to handle the files that file type correctly...most of our stuff is ODS-x. It's .ISO in the sense of a "ISO Image" (the entire contents of a disc).
Jan-Erik Söderholm
2020-09-01 12:32:41 UTC
Permalink
Post by Bob Wilson
I hate to sound pedantic, but are you certain that you used a binary
mode transfer? (been there, done that)
Also, anecdotally: The .zipexe passing through multiple file systems
(VMS -> linux -> Windows -> ...) has apparently introduced corruption
(you can never really tell what happens once stuff goes out into the
wild [and when/how something was corrupted])
If all else fails, you could generate a MD5 checksum in a case where
someone (any volunteers) is known to have successfully "run" the
.zipexe, and compare it to a MD5 checksum of the file that you're trying
to "run".
If there are no volunteers, :-), I could generate a MD5 checksum from
the version of the file on the VSI server where these files are sourced
for external distribution.
n.b. We use the .ISO file type because most tools for burning discs
(Windows, linux & Mac) seem to handle the files that file type
correctly...most of our stuff is ODS-x. It's .ISO in the sense of a "ISO
Image" (the entire contents of a disc).
Also do not forget that these "ISO" files are fine to "connect" and mount
directly on VMS using LD. I have the LP "disks" mounted that way. Neat...
Dave Froble
2020-09-01 16:45:33 UTC
Permalink
Post by Jan-Erik Söderholm
Also do not forget that these "ISO" files are fine to "connect" and mount
directly on VMS using LD. I have the LP "disks" mounted that way. Neat...
Yeah, that's what I did too.

Optical is so last decade/century ....
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
John E. Malmberg
2020-09-01 13:28:28 UTC
Permalink
Post by Bob Wilson
n.b. We use the .ISO file type because most tools for burning discs
(Windows, linux & Mac) seem to handle the files that file type
correctly...most of our stuff is ODS-x. It's .ISO in the sense of a
"ISO Image" (the entire contents of a disc).
What may be the defaults for the tools you are familiar with may not be
the defaults for some random burning program installed on a system.

Some older CD burning software required using the ".iso" type for image
files.

Many of the newer burning tools expect a real ISO file system if you
tell it that you have an ".iso" file type.

If it does not find an ISO file system, it may fail to properly burn the
disk, or only burn the part of the image that contains an ISO filesystem.

None of the OpenVMS distribution media that I am aware of are true
".iso" disk types. All are disk images.

Raw binary copies will work.

ISO disk copy / diagnostic software will either visibly fail or on IA64
OpenVMS media only copy a small part of the disk.

You have to check your CD/DVD burning software to see if it takes an
"image" format first.

If it does not have an image format, then it will probably treat ".iso"
files as images.

You must also choose the option to burn the entire disk at once. That
is not the default for many PC CD burners. With out that setting the
resulting disk probably can not be read on OpenVMS.

Regards,
-John
Bob Wilson
2020-09-01 13:39:48 UTC
Permalink
re: ...for some random burning program installed on a system

Do you have an instance of anything less than 5 years old?

No matter what, anything chosen (as the default file type) will be wrong some % of the time, or not work some % of the time.

And chances are that what's "familiar" is what most folks have access to.

bw
Stephen Hoffman
2020-09-01 14:32:10 UTC
Permalink
Post by Bob Wilson
re: ...for some random burning program installed on a system
Do you have an instance of anything less than 5 years old?
Mac was seemingly slightly cranky about burning ISO-named not-ISO-9660
volumes, when last I checked. I've been renaming the distro to DMG for
a while and haven't verified the continued existence of that crankiness
recently, though. IIRC, High Sierra was the last test with ISO, and
renaming to DMG worked there. On Mojave, I've renamed automatically
prior to burning.
Post by Bob Wilson
No matter what, anything chosen (as the default file type) will be
wrong some % of the time, or not work some % of the time.
Ayup. This is also your distro and your support calls overhead and your
operating system that you want adopted widely, too.
Post by Bob Wilson
And chances are that what's "familiar" is what most folks have access to.
Approximately nobody understands optical media across a variety of platforms.

I'm comfortable discussing OpenVMS recording and optical-media
generation on OpenVMS, and with optical burning on macOS, was once more
familiar with Windows and with what didn't work over there, and some
experience with burning on Linux and BSDs with dvdtools. (With Windows
in years past, Nero was a never-ending source of issues with image
burns.)

Mac will perform an image burn with the image renamed to DMG, which is
what I've used on High Sierra and Mojave. But the OpenVMS Alpha ODS-2
image or the OpenVMS I64 El Torito image is obviously not a Mac disk
image, so this file type isn't technically correct.

As mentioned above, Mac might also work with IMG or DSK or BIN file
types, haven't tried those.

What Windows or Linux does with a DMG or IMG or BIN file type by
default—past use with a port of dvdtools or related—I haven't tried.

Whatever happens here will likely involve some massaging of the disk
image on the target system, and with some documentation for that.




Future plans: I'd hope that the era of optical media on OpenVMS ends
with OpenVMS I64 Itanium, and that x86-64 uses bootable USB devices,
and that OpenVMS x86-64 has one or two images per release. VSI hasn't
commented on that, AFAIK. (There's a whole pile of work here around
image checksums and secured distribution and related tasks. Work which
has classically been at most half-baked on OpenVMS.)

But yes, bootable USB media means we'll still need to use dd or other
tools to generate the bootable USB media, which'll need documentation,
see above.

Bootable USB media means we won't need to have a working optical device
on the servers, nor stuffing kits into a DVD-R/RW+R/RW volume, and
avoids requiring Blu-ray BD or some such.

I'd expect somebody at VSI would have kittens before we'll encounter a
widely-available VDI VirtualBox or VMware VMDK or other bootable guest
image was officially and widely available, but stranger things have
happened.




Bottom line: crowd-source what optical-media burning steps work on each
of the common platforms and (if/when) for USB images or VDIs or VMDKs,
figure out what works on most platforms and adopt the most portable
naming (IMG, BIN, VDI, VMDK, etc) generally in the distribution, and
publish the per-platform details. This collection is basically what
DEC/Compaq/HP/HPE did internally, with (for instance) the use of
CDBurnerXP (less the adware) on Windows, COPY/RECORDABLE on OpenVMS,
cdrtools ports or cdrkit ports or dvdrtools ports on other platforms,
etc.
--
Pure Personal Opinion | HoffmanLabs LLC
Bob Wilson
2020-09-01 17:36:54 UTC
Permalink
Post by Stephen Hoffman
Mac was seemingly slightly cranky about burning ISO-named not-ISO-9660
volumes, when last I checked. I've been renaming the distro to DMG for
a while and haven't verified the continued existence of that crankiness
recently, though. IIRC, High Sierra was the last test with ISO, and
renaming to DMG worked there. On Mojave, I've renamed automatically
prior to burning.
Renaming to .DMG not required. On Catalina (macOS 10.15.6) on my Mac-at-home I was just able to directly burn a ODS-2 ".ISO Image file" to a DVD disc (Finder -> File -> Burn <file> to Disc... -- having pre-selected the file to be burned).

I confirmed the contents of the DVD disc that I burned were what was expected ;-).
Steven Schweda
2020-09-01 17:42:30 UTC
Permalink
Post by Stephen Hoffman
Mac was seemingly slightly cranky about burning ISO-named
not-ISO-9660 volumes, when last I checked. [...]
That seems a bit vague.
Post by Stephen Hoffman
[...] I've been renaming the distro to DMG for a while and
haven't verified the continued existence of that crankiness
recently, though. [...]
I don't recall having any such trouble, including a couple
of weeks ago, when I did the IA64 discs on my Mac Pro (Mid
2010), running macOS Mojave, Version 10.14.6.

The supplied-with-the-OS UnZip (/usr/bin/unzip, "UnZip
6.00") did the extraction (with the avoidable but unavoided
warning message about the "extra bytes at beginning or within
zipfile". And, as I said before:

[...] the Finder's 'Burn Disk Image "XXX" to Disc...'
option ("Burn Disc") worked just fine for me.

No renaming or any other fiddling required.
Chris Scheers
2020-09-01 19:48:00 UTC
Permalink
Just to throw one more curve at this discussion:

I rarely burn physical CDs/DVDs any more.

VirtualBox has an option to use a physical disk instead of a container file.

Assuming you have an emulator/hypervisor with this capability, you can
boot from a .ISO image and install to a physical drive. Then take the
drive to your target system and boot it.

This is assuming that all your disk controller supports JBOD, your
interconnects are compatible, etc. But this works for me 90% of the
time or better when these conditions are met.
Post by Stephen Hoffman
Post by Bob Wilson
re: ...for some random burning program installed on a system
Do you have an instance of anything less than 5 years old?
Mac was seemingly slightly cranky about burning ISO-named not-ISO-9660
volumes, when last I checked. I've been renaming the distro to DMG for a
while and haven't verified the continued existence of that crankiness
recently, though. IIRC, High Sierra was the last test with ISO, and
renaming to DMG worked there. On Mojave, I've renamed automatically
prior to burning.
Post by Bob Wilson
No matter what, anything chosen (as the default file type) will be
wrong some % of the time, or not work some % of the time.
Ayup. This is also your distro and your support calls overhead and your
operating system that you want adopted widely, too.
Post by Bob Wilson
And chances are that what's "familiar" is what most folks have access to.
Approximately nobody understands optical media across a variety of platforms.
I'm comfortable discussing OpenVMS recording and optical-media
generation on OpenVMS, and with optical burning on macOS, was once more
familiar with Windows and with what didn't work over there, and some
experience with burning on Linux and BSDs with dvdtools. (With Windows
in years past, Nero was a never-ending source of issues with image burns.)
Mac will perform an image burn with the image renamed to DMG, which is
what I've used on High Sierra and Mojave. But the OpenVMS Alpha ODS-2
image or the OpenVMS I64 El Torito image is obviously not a Mac disk
image, so this file type isn't technically correct.
As mentioned above, Mac might also work with IMG or DSK or BIN file
types, haven't tried those.
What Windows or Linux does with a DMG or IMG or BIN file type by
default—past use with a port of dvdtools or related—I haven't tried.
Whatever happens here will likely involve some massaging of the disk
image on the target system, and with some documentation for that.
Future plans: I'd hope that the era of optical media on OpenVMS ends
with OpenVMS I64 Itanium, and that x86-64 uses bootable USB devices, and
that OpenVMS x86-64 has one or two images per release. VSI hasn't
commented on that, AFAIK. (There's a whole pile of work here around
image checksums and secured distribution and related tasks. Work which
has classically been at most half-baked on OpenVMS.)
But yes, bootable USB media means we'll still need to use dd or other
tools to generate the bootable USB media, which'll need documentation,
see above.
Bootable USB media means we won't need to have a working optical device
on the servers, nor stuffing kits into a DVD-R/RW+R/RW volume, and
avoids requiring Blu-ray BD or some such.
I'd expect somebody at VSI would have kittens before we'll encounter a
widely-available VDI VirtualBox or VMware VMDK or other bootable guest
image was officially and widely available, but stranger things have
happened.
Bottom line: crowd-source what optical-media burning steps work on each
of the common platforms and (if/when) for USB images or VDIs or VMDKs,
figure out what works on most platforms and adopt the most portable
naming (IMG, BIN, VDI, VMDK, etc) generally in the distribution, and
publish the per-platform details. This collection is basically what
DEC/Compaq/HP/HPE did internally, with (for instance) the use of
CDBurnerXP (less the adware) on Windows, COPY/RECORDABLE on OpenVMS,
cdrtools ports or cdrkit ports or dvdrtools ports on other platforms, etc.
--
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360 Internet: ***@applied-synergy.com
Fax: 817-237-3074
Loading...