[Info-vax] portable sequential file formats (was: Re: Couple of questions on VMS -> world)

[David Froble]

Stephen Hoffman wrote:
> On 2015-03-18 23:38:21 +0000, johnwallace4 at yahoo.co.uk said:
> 
>> On Wednesday, 18 March 2015 01:22:16 UTC, johnso... at gmail.com  wrote:
>>> On Tuesday, March 17, 2015 at 1:00:04 PM UTC-4, li... at openmailbox.org 
>>> wrote:
>>>
>>>> Agreed. I don't understand how anybody can use Linux or most UNIX in
>>>> production for anything.
>>>
>>> But clearly it's been done and continues to be done. At quite large 
>>> scales too.
>>> I think of organizations such as Amazon, Twitter, Facebook, Google. 
>>> Perhaps
>>> you are focusing on the wrong things.
>>>
>>>> But it's still UNIX so it suffers from the same lack of naming 
>>>> conventions
>>>> and where Sun hasn't fixed [...]
>>>
>>> While annoying at times, it's really not a deal breaker. It's at most 
>>> a temporary
>>> speed bump for some.
>>>
>>>> And they're all based on C which is the root of all evil- it's
>>>> not *if* something bad is going to happen it's just when and how often.
>>>
>>> I think you need to separate your disgust at elements of the standard C
>>> library from that of the language itself.
>>>
>>> EJ
>>
>>
>> Twitter, Facebook, Google, etc are presentation-centric read-mostly
>> applications, on the whole. Nobody cares much if they work properly
>> or not, so long as they're mostly there most of the time.
> 
> The billing and ad-tracking systems are rather more robust, I'd expect. 
> That written, Facebook and others have done some very serious work on 
> distributed computing and scaling.  <https://github.com/facebook>, among 
> others.  As for not the social sites working properly or not, outages 
> and errors are a big problem for ad-driven social sites.  If the sites 
> are not around and not keeping their users happy and entertained, then 
> the sites are not adding content and not making money.  At the scale of 
> Facebook, keeping these servers online and operational and secure is not 
> an easy problem.   VMS supports nothing even close to the scale of many 
> modern configurations, for that matter.  A hundred nodes is three 
> Moonshot boxes in ~13U, after all.
> 
>> Equally, nobody notices much if they provide wrong data or lose data
>> from time to time. These are the outfits who are the target market for
>> HP/Foxconn's Cloudline disposable/nonmanageable/nondiagnosable servers.
> 
> RAIS.   Quite popular in some quarters, particularly as the costs of the 
> servers crater.  Why bother fixing something, when your software — akin 
> to clustering on VMS, but at much larger scale — can simply swap in 
> another box as needed.    Yes, scribes tell us that in the eldertimes, 
> computer technicians known as Field Servants used to perform 
> component-level repairs, and servers got periodic preventive maintenance 
> visits, but can you believe the costs involved with that sort of thing 
> now?  Scribes tell us that disks were once repaired, and boards and were 
> HDAs swapped around.
> 
> BTW, it's possible to get into trouble with first-tier server gear (with 
> design and software issues), too 
> <http://jacquesmattheij.com/saving-a-project-and-a-company>
> 
>> These well known outfits buy lots of kit but how representative are they
>> of the rest of the market? If you want a disposable webfacing
>> presentation-centric public setup, why not leave it to e.g. Amazon AWS
>> and the like, and forget about the hardware altogether?
> 
> Requirements differ: 
> <http://highscalability.com/blog/2015/3/16/how-and-why-swiftype-moved-from-ec2-to-real-hardware.html> 
> 
> 
>> But if you want a traditional transactional setup where data
>> availability and integrity and security are still things that matter,
>> there may be better options.
> 
> One question there being whether VMS is one of those better options, 
> particularly for new deployments.   Up until July 2014, the answer to 
> that question was usually "no".
> 
>> One size does not fit all?
> 
> Ayup.  That's why we're not all running {whatever}.
> 
>> "separate your disgust at elements of the standard C library from that 
>> of the language itself. "
>>
>> Lots of folk could benefit from doing that.
> 
> Ayup, and what will lists think of OpenVMS, given that more than a third 
> of OpenVMS is written in C?   I'd be inclined to use something else now, 
> but there's no-trivial cost involved in shifting languages.  Adding 
> another language to the existing collection of (mostly) C, Macro32 
> compiler code, and Bliss — and a variety of other bits in smaller 
> quantities, including Ada — just isn't going to be at the top of most 
> lists.  Particularly given the current team generally knows C, Macro32 
> and Bliss pretty well, too.
> 
> 

So, what's wrong with using Bliss?  It's there.  It works.  It was 
designed for this kind of stuff.

I won't say MACRO-32, since I have to beat myself with an ugly stick to 
look at some of my old code.  That's not something you do as a hobby. 
Either lots of it, or none of it.