[Info-vax] Programming languages on VMS

[Bill Gunshannon]

On 02/09/2018 11:18 PM, DaveFroble wrote:
> Stephen Hoffman wrote:
>> On 2018-02-09 22:49:12 +0000, Jan-Erik Soderholm said:
>>
>>> Why would it not be "restorable"? Yes, we have some fairly static 
>>> data still in RMS files (shouold be moved into Rdb). This is of 
>>> course highly site specific and each environment has to evaluate the 
>>> possible risks in getting some files that are "out of sync". It is 
>>> all about risk analysing.
>>
>> Because it's been my experience that online backups are less than 
>> transparently restorable, and files captured with /IGNORE=INTERLOCK 
>> are not guaranteed internal consistency nor are related files 
>> necessarily captured consistently across other related files.
>>
>> But I'm really not interested in bringing your site forward, as it's 
>> very clear you're not interested in that task.
>>
>>> Right. I see backup/restore of the file system, and backup/restore of 
>>> the/a database as two separate entities. The backup of Rdb through 
>>> RMU/BACKUP and RMU/RESTORE (including handling of AIJ journaling 
>>> files) is quite different from regular backups of your file system.
>>
>> No, it's not.   It's only different because there's been effectively 
>> zero thought given to this whole area and there's been a pile of 
>> disparate pieces patched and otherwise taped together over the decades.
>>
>>> OK, right. If you think that giving the system *one* command to 
>>> restore what has been deleted by accident, as "a whole lot of work". 
>>> Fine. Hard to argue there... :-)
>>
>> That's because you haven't used the tools that others have.  Which in 
>> various cases involves little more than "here's the target device or 
>> target server for backups, have at" and the backups then defaulting to 
>> and taking care of everything else, including frequency and pruning 
>> among other details.
>>
>>> Work by me or by the system? There is one script running each night 
>>> doing the backups. This has been running with some minor changes 
>>> since 2010 (when we switched from local tape station with weekly 
>>> manual tape changes) to:
>>
>> Can't say I find creating backup scripts and dealing with tapes and 
>> tape libraries entirely straightforward nor particularly easy, but 
>> then that's me.   In comparison with the complexity of OpenVMS, the 
>> capabilities and the simplicity of Time Machine was a pleasant 
>> surprise, for instance.
>>
>>> *I* think that you are often exaggerating that OpenVMS is that far 
>>> behind in many areas.
>>
>> What I mention is already available and already in use.   Servers and 
>> enterprise gear does commonly tend to trail what's available, and for 
>> various reasons.  But expectations can and do shift.
>>
>>> The *main*, as I see it, problem is that many of those working with 
>>> OpenVMS have let *themselves* falling behind when it comes to what is 
>>> happening in the IT business.
>>
>> Have you considered how you yourself and your systems fit into that? 
>> Have you pondered how you'd replace your entire system from within and 
>> incrementally, and how you'd work to get there?
> 
> Ok, here is where some of these arguments fall apart.
> 
> Consider a mfg company, which is what Jan Erik has.  IT is a necessary 
> expense.  Not directly something that produces income.

And, as a necessary expense one would expect it would constantly come
under scrutiny as to whether or not there is a better (read more
economical) option.

> 
> The purpose of a mfg company is to produce goods, which are sold, thus 
> creating profits.

Based on how many of these companies are wasting so much money on crap
like the Olympics and social engineering one might doubt if that was
true.

> 
> Now, if, and that is a valid question, the IT system is meeting the 
> company's requirements, why would the company waste money to replace 
> their IT system?  

Long list for this one.
   1) Old system is getting harder (and more expensive) to maintain
   2) Daily operation is potentially costing more because of the
      inefficiency of the system compared to something more modern
   3) potential for a catastrophic failure due to the age of the
      equipment

And the list goes on and on.

>                   As requirements change, the system(s) can be modified 
> to reflect changing requirements.  But rarely, if ever, will things 
> change so much that the current IT system is so far away from 
> requirements.  It just doesn't happen.

Of course it does.  If what you said was true there would still be
piles of PDP-11's, Prime 50-series and IBM 360's running out there.
There aren't, why?

> 
> So, replacement of the entire system just isn't going to happen.

Bad logic.  Especially in the case of something like the aforementioned
catastrophic failure.

> 
> The IT system(s) are there to run the company, 

And for that reason alone they have to be reliable, well maintained and
easily returned to operation in the event of a failure.

>                                                 not as a daycare for 
> those "new people" in IT that want to practice the rubbish they were 
> taught in the learned halls of higher education.  

Now your sounding like certain others in this group.

>                                                   The company is not 
> there for such to ruin a working system.
No, but they are there to ensure the continued operation of those
systems.  And if they see the current system as unreliable and not
easily maintained it is their job to make thast point known.

> 
> Yes, I'm aware that at times an idiot is put in charge.  An idiot that 
> thinks he knows all, and is going to make his mark by throwing out the 
> working system(s) and isn't stopped before he destroys the company.

Not as often as you seem to think.  And just because they produce
evidence that the old system is obsolete doesn't mean they are wrong
or don;t have the companies best interests at heart.

> 
> This happened at one of my previous customers.  Easton Sports was the 
> distribution sub-division of Easton Aluminum, a company that mfg among 
> other things aluminum baseball bats.  An innovative company that was 
> doing well. However, the parent company brought in this idiot from one 
> of the large accounting firms, and he brought in some of these young 
> people who just knew that what must happen was to be a 100% Microsoft 
> shop.  When people on the distribution side, who realized what a 
> disaster was about to happen and spoke up, the idiot shut down the 
> distribution sub-division and brought the work into the parent company.  
> And yes, they threw out what was working, and spent millions trying to 
> replace it.  One forecasting system had three attempts to replace it, 
> and failed every time.  But the idiot never wavered from his "know it 
> all" attitude.  I'm sure he's screwing up at other places, but, don't 
> look for Easton Aluminum, it doesn't exist anymore.

Like most of these doom and gloom stories I am sure there were numerous
other reasons why the company failed to compete.

> 
> If a company has a working solution, if they need new people to work 
> with it, and such don't exist, then they will train them.

That is done in some cases (General Dynamics and COBOL Programmers).
But it won't save cost cause by running old and inefficient hardware.
And, it won't keep the system running when support is no longer
provided.

Let me provide a counter to your Easton story.  Ever hear of a
children's magazine called Highlights?  Local company.  About 10
miles up the road from here. When I first came back to this area
to work at the University they were a PDP-11/RSTS shop.  Then, one
day, all of the PDP-11's rolled out as a donation to the University.
Don't know what replaced them, but my guess would be PC's.  No
downtime.  Magazines continued to roll out and the company is still
thriving today.  (as a side note, I now this because all the University
wanted were the RA drives to hook up to the VAX they were running. I
got all the PDP-11's and RL disk drives.  They were my first personal
systems and I can assure you not only did they work when I got them
but continued to work for more than a decade at which time I donated
them to a computer museum and to the best of my knowledge still run
today!!)


Like most things systems age.  And replacement becomes necessary even
if they are still running.  As I have mentioned in the past, I have an
MGB.  Car runs fine.  But I wouldn't want to rely on it as my primary
means of transportation. I could go out tomorrow and find it won't
start and while parts are generally available some parts are not
available short of having them machined and even the ones that are
available could take days to weeks to acquire.  How many businesses
could survive those conditions in their IT System?

bill