> Here's an interesting problem.
>
> Suppose you wanted to write an application for a
> manufacturing process that will, in all probability, run for
> the next 30 years. No direct control of the process itself
> is entailed (i.e., you don't need the program to operation
> valves or run motors), but you do need this program to
> compute manufacturing parameters for each customer. I/O
> requirements are very modest, mostly simple keyboard and display.
>
> What would you write it in? Clearly, you'd want to be
> independent of a particular software vendor, so the likes of
> Visual BASIC isn't an option.
> You'd also want to write in a language that isn't nearing
> obsolescence, nor one that's still evolving. "Niche"
> languages would be out of the question, as longevity could be
> a problem.
>
> So what would it be? My vote is for FORTRAN.
I've been following this thread for a few days now, and I'd like to contribute my $0.02.
The original problem statement asserted several presumptions:
>you'd want to be
> independent of a particular software vendor..
>...
> You'd also want to write in a language that isn't nearing
> obsolescence, nor one that's still evolving. "Niche"
> languages would be out of the question, as longevity could be
> a problem.
I think a number of people were duped by these presumptions into focusing on the longevity of
the language. To me, having seen many good things come and go, I would not speculate on
the longevity of anything that we could conclude might have permanence. Many languages have
appeared to be "the answer for all time" only to fade into obscurity, not for lack of good
qualities, but because of the money behind some other language's marketing department and
the heat of passion for the new stuff in the buyer's pockets.
But in the stated problem there are larger issues that have mostly gone by without discussion.
Given the original problem statement, I would have to ask:
- If the app is not "controlling the process itself", then what is it controlling?
Given that the process varies per customer but the app does not control the process itself, then
I'm going to hypothesize that the app controls information about the process, such as variations in a
manufacturer's process "recipe". For example, the process produces a commodity such as gasoline,
and different customers each purchase their own formulation.
If the output is a custom formulation, then, after any number-crunching, the app could produce a very
simple text document.
Would such an application require the power of FORTRAN or C?
If the I/O is mostly for data entry and display, then couldn't a raw Access databse suffice? At the very
least, the data could be more easily forwarded to a newer environment than custom code.
- Will the application run on a general-purpose computer or on a specific architecture?
If general purpose, then survivabilty of the language (its development and operational environments)
would be of primary concern.
If on a specific architecture, it would make sense to write it in the machine language of that platform,
provided it was fully documented with specs and functional comments.
- Is the manufacturing process expected to persist without significant changes for the 30 years?
If so, the app could be burned into a stable media (PROM, EEPROM, or the like).
But if it would be subject to significant changes, perhaps better to maintain source and compiled
versions.
Having run a factory for 6 years, I understand the desire for a solution that can be created and
left alone. But 20 other years in business and in systems, I know that things change, and often when
least convenient and most costly to rectify.
It is a good goal to want a system that will run unaltered and survive for 30 years. But will the business
still be in business then? Or will the industry have changed, the need for the product in the marketplace
have changed, the machinery or degree of meeting customer variation have all gone away?
I think the solution to this problem does not lie in having "one right answer", but in having a
data-forwarding strategy that is flexible, responsive, updatable, and maintainable. It would be better
to change the app several times in the 30 years with reasonable costs than to bet on one solution that
could be broken a few short years later. Just depends on what's at risk and how much of a gambler you are...
So, I hope that's some food for thought...
-John M.
Montclair, NJ
Fellow classic'ers,
An idea just occurred to me, one that was inspired by a 'group buy' I did several years ago, on behalf of the ClassicCmp community, for Teledisk.
Before I can even consider implementing it, though, I need to know how many of the group's members own one or more of the following Data I/O device programmers: UniSite or UniSite XPi, 2900, 3900, or 3980 XPi (in short, any one of the 'UniFamily' programmers).
I see no need to clutter the list with responses. Please contact me off-list. If, for whatever reason, you try to reply and it bounces, try my backup address of kc7gr at qsl dot net.
Thanks much.
-=-=-=-=-=-=-=-=-=-=-=-
Bruce Lane, Owner & Head Hardware Heavy,
Blue Feather Technologies -- http://www.bluefeathertech.com
kyrrin (at) bluefeathertech do/t c=o=m
"If Salvador Dali had owned a computer, would it have been equipped with surreal ports?"
Hi,
I have been looking at your cctalk bulletin board and it appears that
Frank McConnell is someone who knows a lot about old HP computers. I
have been tasked to replace the HP 9133 computer on some of our test
equipment with new PC's. I was hoping to contact somebody who might know
if this is possible and how to do it. So I was wondering if you knew how
I could contact Frank McConnell or somebody who might know.
Sincerely
Phil Matthews
DRS Optronics Inc
Electrical Engineer
(321) 309-2124
phil_matthews at drsoptronics.com
I slapped an AHA 1640 PCMCIA card in my Linux laptop, compiled
tapetools 0.4 and 0.6 and started shoving tapes in my TSZ07. I wrote
these tapes myself a number of years ago, and have finally gotten
around to attempting to extract them. Things seemed to go fine,
except that on certain tapes, I saw a page or two of partial records
reported - i.e. - these VMS BACKUP tapes were written with a block
size of 16384, and some tapes report ~2500 records of 16384 bytes
(1600 bpi), and some report a few hundred records of 16384, then a few
at a smaller number, then more at 16384, etc. I'd think there were
some read problems, but the tape wasn't shoe-shining - it buzzed along
at full tilt.
Does anyone here have any experience with reading VMS BACKUP tapes
with tapetools? Can you share your observations? I haven't yet tried
reading the files - I know there were some VMS BACKUP extractors in C
years ago, and I've even used them, but I'll probably have to re-find
and rebuilt them. I could also fire up simh and VMS, but at the
moment, my VMS install CDs are somewhere else.
I'm really just after the data for now - it's all the stuff I worked
on at Software Results years ago - all the COMBOARD software as well
as a wad of personal files (one-off programs, stuff from newsgroups,
etc.). I still have the Fuji Eagle that was spun down a few weeks
after the backup was made, but I haven't attempted to power that up
yet to see if it still works.
Thanks for sharing any tapetools stories (and any suggestions about
'modern' VMS BACKUP extractors).
-ethan
I noticed my HP 262X terminals have a "Duracell TR133" battery in the back
to maintain settings when powered off. The battery indicates "Mercury" on
the side.
Are mercury batteries rechargable? I would have thought they'd use a nicad
or something to charge up while the unit was on.
The TR133 battery also indicates "4.2V". It seems the Duracell replacement
for this battery is Alkaline, and 4.5V. Should I use it?
Jay
Hi,
A fellow programmer / collector recently passed away,
and I'm helping his widow find homes for some of
his hardware, software, manuals, etc.
She just wrote to me:
I have found another stack of HP Journals,
not every month, from 1979-1987 and 1992.
Are they keepers?
IIRC, I've got a box of HP Journals from her already,
that I was planning on taking to the Vintage Computer
Festival (www.vintage.org).
Anyone here interested in HP Journals should email me
for discussions / offers. No, I do not have a list of
issues available at this time. I hope to be reunited
with the box (making its way from Phoenix) before VCF,
but...
thanks,
Stan
Sorry for the interruption to your normally scheduled off-topic messages.
Cameron,
I occasionally get the following error when attempting to e-mail you:
----- The following addresses had permanent fatal errors -----
<spectre at floodgap.com>
(reason: 553 5.3.5 system config error)
----- Transcript of session follows -----
451 4.4.1 reply: read error from mail.floodgap.com.
553 5.3.5 mail.flactem.com. config error: mail loops back to me (MX
problem?)
554 5.3.5 Local configuration error
It's happened twice this morning, and once about a couple weeks ago.
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
Do you still have this board? I think the part number is MLSI-DR11BO
Attached are a couple of pictures.
Steve Andow
Process Control Systems Int'l
11993 Ravenna Rd. Suite 5A Chardon, Ohio 44024 USA
Phone: (440)286-4440 Fax: (440)286-8630
sandow at proconsysint.com
