Discussion:
: PARC.EXE available for IA64?
(too old to reply)
Art
2017-01-07 18:14:09 UTC
Permalink
Raw Message
We have been using this software "forever" in one minor (yet important) application. We are migrating Alpha to Itanium and am wondering if the source (or a pre-built EXE) is available. I don't recall where we got the Alpha version from 7 or 8 years ago when we last migrated to VMS v8.3 .

The program identifies itself as:

PARC - Portable Archive utility based on SEA's ARC Version 5.21
Version 1.1.3 Beta, created xx:xx xx/xx/xx
VAX/VMS Routines V2.1.1 Beta created 09:30 03/15/90

Copyright 1989-90 Lawrence J. Jones; All Rights Reserved
(C) COPYRIGHT 1985,86,87 by System Enhancement Associates;
ALL RIGHTS RESERVED

Please refer inquiries about the portable version to:

Lawrence J. Jones (mailto:***@sdrc.com)
701 Woodgate Road, Cincinnati, OH 45244

Please refer other inquiries to:

System Enhancement Associates, Inc.
925 Clifton Ave., Clifton, NJ 07013

You may copy and distribute this program freely, provided that:
1) No fee is charged for such copying and distribution, and
2) It is distributed ONLY in its original, unmodified state.



Perhaps it's time to switch the app to a "modern" compression utility like ZIP :)

Cheers,
Art
Steven Schweda
2017-01-07 19:06:40 UTC
Permalink
Raw Message
Post by Art
We have been using this software "forever" in one minor
(yet important) application. We are migrating Alpha to
Itanium and am wondering if the source (or a pre-built EXE)
is available.
Perhaps you've already realized that having the source for
unsupported but important programs is, uh, important?

I know nothing, but a quick Web search found a couple of
potential replacements:

https://sourceforge.net/projects/arc/
http://www.svgalib.org/rus/nomarch.html

The second gets fewer compiler complaints on a Mac. I
haven't tried either on VMS, but building looks pretty
straightforward (no "configure" script, only a "make" file,
which seems to do little exotic).
Post by Art
Perhaps it's time to switch the app to a "modern"
compression utility like ZIP :)
Perhaps. The answer might depend on what you're doing.
If you do decide to use the Info-ZIP Zip and UnZip programs,
then you might do us all a favor by selecting versions newer
than those from 1990. (At least the source is generally
available.)
Steven Schweda
2017-01-09 23:06:08 UTC
Permalink
Raw Message
[...]
A quick look suggests that these are not very
satisfactory. The second one only extracts. The first
appears to be less portable than whatever you had/have.

I pounded on the lamest (and least VMS-compatible) pieces,
and got something unattractive which seems to work in simple
cases, at least:

ALP $ crea /dire [.test]

ALP $ arc a test/misc.arc Changelog Readme
Creating new archive: test/misc.arc
Adding file: changelog. analyzing, crunched, done. (44%)
Adding file: readme. analyzing, crunched, done. (41%)

ALP $ set defa [.test]
ALP $ arc x misc.arc
Extracting file: changelog.
Extracting file: readme.

ALP $ back /comp /log *. [-]
%BACKUP-S-COMPARED, compared ALP$DKC0:[UTILITY.SOURCE.arc.arc-5_21p]Changelog.;1
%BACKUP-S-COMPARED, compared ALP$DKC0:[UTILITY.SOURCE.arc.arc-5_21p]Readme.;1

Note that Zip compresses better, and doesn't damage case
in file specs:

ALP $ zipx [.test]misc.zip Changelog Readme
adding: Changelog (deflated 59%)
adding: Readme (deflated 51%)

So, for any number of reasons, I'd recommend using modern
Zip+UnZip instead of any such ARC program(s). But, if you're
sufficiently desperate, let me know, and I can assemble a
(crude) source kit. (And then you're on your own. The
Info-ZIP programs have better support, too.)
IanD
2017-01-10 02:35:56 UTC
Permalink
Raw Message
Isn't this partly why people are also migrating to open source based OS's which logically is an extension of the idea of escaping closed source applications / utilities, for the same reason?

If VSI had not come along, all those using OpenVMS would be in the same position, stuck

I know through the current license agreement with HP that existing code cannot be open sourced, but there's been very little if nothing said about the new stuff being developed by VSI

The whole notion of companies being around for 100's of years and their longevity is now on the radar for business risk which is also a reason why open source has grown in popularity

I still think open source is a direction for OpenVMS to head in because it will at least keep it in the selection criteria for a number of companies choosing an OS going forward

Just what are the plans for open sourcing any newly developed parts of OpenVMS? Or will it remain a closed source system bar the open source tools ported to it?

What about a redhat model for OpenVMS (in time of course, once it's proven viable?)
David Froble
2017-01-10 08:44:59 UTC
Permalink
Raw Message
Post by IanD
Isn't this partly why people are also migrating to open source based OS's
which logically is an extension of the idea of escaping closed source
applications / utilities, for the same reason?
If VSI had not come along, all those using OpenVMS would be in the same position, stuck
I know through the current license agreement with HP that existing code
cannot be open sourced, but there's been very little if nothing said about
the new stuff being developed by VSI
You don't pay attention, do you? Can't remember who, and might have been
several people from VSI, that mentioned that whatever they develop belongs to
VSI and they can do with it as they please.
Post by IanD
The whole notion of companies being around for 100's of years and their
longevity is now on the radar for business risk which is also a reason why
open source has grown in popularity
I still think open source is a direction for OpenVMS to head in because it
will at least keep it in the selection criteria for a number of companies
choosing an OS going forward
Just what are the plans for open sourcing any newly developed parts of
OpenVMS? Or will it remain a closed source system bar the open source tools
ported to it?
What about a redhat model for OpenVMS (in time of course, once it's proven viable?)
As long as the OS just works, why do you keep bringing up this dead issue of
"open source"? It really just doesn't matter. Perhaps you live in some
environment where people worship "open source", but, that's a false religion.

As for pricing model, it was clearly stated in this venue, by someone from VSI,
that they are looking at exactly what you mention, no license fees, mandatory
support to use the OS, and revenue from support. Search back through the posts,
you'll find it.
Stephen Hoffman
2017-01-10 17:47:41 UTC
Permalink
Raw Message
Post by IanD
Isn't this partly why people are also migrating to open source based
OS's which logically is an extension of the idea of escaping closed
source applications / utilities, for the same reason?
You're going to want to include more context in your replies, if you're
going to include dangling antecedents. If you're referring to lost
source code such as this old ARC tool, that happens with open and with
closed source. I've rewritten hunks of code, because the original tool
had been lost. I've patched fixes into binaries, too. Both in
open-source work, and in commercial and proprietary environments.
Stuff that's not checked in occasionally gets lost, and sometimes whole
source code pools get lost.
Post by IanD
If VSI had not come along, all those using OpenVMS would be in the same position, stuck
Even with VSI, we're rather stuck. There was another of the "are the
{insert your preferred feature here} plans ambitious enough?" thread
quite recently and I've posted more than a few of similar ilk, and
there's the whacking great pile of work that VSI has to catch up beyond
the work on the port. This while the development work on more than a
few other competing platforms continues apace. Ports are a fact of
life in IT, and some are easier than others, and some projects simply
choose to run the servers into the ground and exit the business rather
than port. Which is analogous to not keeping the source code around,
as you've alluded.
Post by IanD
I know through the current license agreement with HP that existing code
cannot be open sourced, but there's been very little if nothing said
about the new stuff being developed by VSI
All of what they develop is their code. That's part of what's on the
the roadmap. What happens and what's contractually permissible after
HPE exits the OpenVMS business, we shall learn.
Post by IanD
The whole notion of companies being around for 100's of years and their
longevity is now on the radar for business risk which is also a reason
why open source has grown in popularity
I've gotten badly stuffed having to port between open source packages, too.
Post by IanD
I still think open source is a direction for OpenVMS to head in because
it will at least keep it in the selection criteria for a number of
companies choosing an OS going forward
While I agree, the customer base fought against that not all that long ago.
Post by IanD
Just what are the plans for open sourcing any newly developed parts of
OpenVMS? Or will it remain a closed source system bar the open source
tools ported to it?
Open-sourcing hunks of OpenVMS won't matter for years, if ever. This
can work, if you're building isolated hunks. But managing and building
open source with a mix of binary blobs of HPE code as dependencies is
even more complex than building OpenVMS as is done now. I'm one of
the few folks around that ever ran the system builds on another system.
VSI went through not a little effort with getting all that to work in
Bolton, I'm sure. Then y'all have to sort out the source code control
system, as VDE is not distributed. A distributed source system is
necessary here too, and a migration from VDE to
git/mercurial/fossil/etc is a very large effort. Then there's the
licensing and code review of the changes, if those are to be accepted
back into OpenVMS.
Post by IanD
What about a redhat model for OpenVMS (in time of course, once it's proven viable?)
Most of us like having free developers. But saying "Beetlejuice" and
saying "Open Source" three times are both equally likely to produce
those free developers.


Moving to the RHEL approach requires a sufficiently active community of
skilled folks, and that's not something that's readily or freely
available nor — outside of payment — easily acquired. More than a
few folks that contribute to Linux are employed by some commercial
entity, too. OpenVMS OS code is not trivial to work on, either.
Working on OpenVMS itself is also rather different from working on
application code, even when you're working with a user-mode utility.
Some kernel bugs have blown up in some quite unexpected places
elsewhere in OpenVMS too, such as that infamous NFS floating point
register bug. Pending the completion of the port to x86-64, working on
OpenVMS also involves a non-trivial investment in setting up emulation
and/or acquiring the requisite hardware. Then there's finding the
folks willing and able to deal with command-line development and tools,
and specifically tools on and for OpenVMS — there's a learning curve
there, for folks not already accustomed.

VSI would also have to shift their entire administrative and
code-management and mental mindset across their entire staff, and the
folks at VSI would likely also have to anoint the requisite "benevolent
dictator" to run the project. For the folks here that haven't yet
managed volunteers — having done both — managing volunteers is very
different than managing teams of employees. While there are some
overlaps — such as ethics, not tolerating any forms of harassment nor
any criminal behaviors, and maintaining appropriately high community
standards — there are entirely different motivations and strategies and
rewards involved.


TL;DR: For the foreseeable future, VSI is the path forward for folks
that are presently running OpenVMS, and that don't want to or don't
need to or cannot currently afford to invest in porting to other
platforms. VSI themselves either find a path to one of Kerry's "blue
ocean" new markets, or they manage and maintain stability and with
growth sufficient to maintain existing customers and to draw sufficient
new customers to offset the inevitable migrations (and with sufficient
extra to fund further investments in new work), or the OpenVMS prices
stay high and then start to increase and then current OpenVMS sites get
to port our data and/or our applications preferably before the hardware
and software fails. Whether any of that involves open source
development?
--
Pure Personal Opinion | HoffmanLabs LLC
John Reagan
2017-01-10 18:25:08 UTC
Permalink
Raw Message
Post by IanD
Isn't this partly why people are also migrating to open source based OS's which logically is an extension of the idea of escaping closed source applications / utilities, for the same reason?
If VSI had not come along, all those using OpenVMS would be in the same position, stuck
I know through the current license agreement with HP that existing code cannot be open sourced, but there's been very little if nothing said about the new stuff being developed by VSI
Some of the "new" stuff is very intertwingled with old code. For example, I added a new $FAO !AW code for the next release. I added (I think) 6 instructions in SYSFAO.MAR. Open-sourcing just those 6 instructions isn't going to do anything.
Stephen Hoffman
2017-01-07 22:56:36 UTC
Permalink
Raw Message
Post by Art
We have been using this software "forever" in one minor (yet important)
application. ...
ARC was last commonly used many years ago, and is only rarely seen in
recent years.

Do what they very likely did last time during the previous port, and
translate this binary using DECmigrate / AEST / OMSAIS tools; the Alpha
to Integrity translator. This based on some of the text that was
posted, text which could imply that the existing executable was
originally a VAX binary and was run through DECmigrate / VEST / OMSVA;
through the VAX-to-Alpha binary translator tool.

Or haul over some of the ARC source code and build it as described in
another reply, and see if that works.

Or migrate the archives to something that's getting more use, as you'd
suggested. If it's zip and unzip you choose for that, make sure
you're using at least zip 3.0 and unzip 6.0, or later versions. There
are current versions of those tools available via the Process Software
resource site, but it's usually better to download the source and build
it locally. Then you have it.

Long term: use newer tools where feasible and work to eliminate
dependencies on the widgets lacking source code, obviously.
--
Pure Personal Opinion | HoffmanLabs LLC
Loading...