[Info-vax] HP Integrity rx2800 i4 (2.53GHz/32.0MB) :: PAKs won't load

[Stephen Hoffman]

On 2016-02-29 18:57:31 +0000, lists at openmailbox.org said:

> On Mon, 29 Feb 2016 18:27:23 +0000
> Kerry Main via Info-vax <info-vax at rbnsn.com> wrote:
> 
>> If a transaction is not completed after being committed in an 
>> active-active Cluster scenario OR in a 2PC app environment, the data is 
>> not lost, but rather an error occurs on the App screen and the App 
>> logic decides what to do with the error. In this scenario, the data did 
>> not complete at all sites, so the transaction or IO is rolled back from 
>> all sites. The update is not considered complete.
> 
> Right, standard stuff.

Other than that clustering has little to do with 2PC or 3PC transaction 
processing, sure.

Why can these get confused?   Because OpenVMS tries to write all I/O to 
disk and tries to use careful ordering of I/O writes (so that files are 
seldom left inconsistent or corrupted), it's rare to lose an I/O.   
(I've seen it happen a few times and usually secondary to a controller 
that's lost its marbles, but it's very rare.)   The downside here 
involves scaling of the I/O load.   (That, and RMS is largely incapable 
of online file management and online backup, but that's fodder for 
another day.)   Caching I/O in memory is far faster than writing to 
disk, but you then have to look at preserving the data over crashes and 
outages and upgrades.   You're also headed at RAIS and away from 
classic RAID.   OpenVMS stinks at dealing with large I/O loads, 
particularly without application help.   Linux regularly blows the 
sneakers off OpenVMS I/O, largely because Linux caches far more.    
Similarly, clustering also tends to run into a wall when multiple hosts 
are all busy slamming I/O at too few spindles.   You end up sharding 
your data across spindles and with segmenting (not partitioning) your 
cluster, particularly if you can't get your I/O load past the lock 
manager and the disk speeds.  Or you cache your data in memory, with 
all the considerations that that entails.

But none of that I/O processing is transactional.    You can easily end 
up with half set of writes written, and confusion, depending on where 
the network or the server or the application dropped out.

For transactional processing on OpenVMS, that usually involves the RMS 
Journaling product and/or DECdtm and/or a transactional database 
package, or some add-on transaction manager.

With the exception of any OpenVMS sites located in Sweden and which are 
utterly perfect and forever happy with Oracle Rdb, wouldn't it be nice 
to have a transactional database or two built into OpenVMS?

>> The difference is that 2PC is a fault tolerant Application level 
>> design, while an OpenVMS multi-site cluster is an OS and above design 
>> which  may have many critical applications, support utilities and ISV 
>> application running that were not designed with 2PC in mind.
> 
> Ok.

Clustering is nice to have, but it's not centrally relevant to a 
transactional environment.

>> Old saying used to be that the 2 best OS clustering technologies were  
>> from  OS's that had the same 3 letters - VMS/MVS (aka OpenVMS/z/OS)
> 
> It's funny because we don't ever use the world clustering or think 
> about clustering in those terms. Many big shops run on one box. And 
> most don't use replication so much. The ones that do perhaps only for 
> certain
> applications rather than the whole floor. Most just send tapes with a courier.

Transaction managers can and do operate across disparate hosts, as well 
as across clusters, as well as within clusters.


Some light reading:
http://blog.acolyer.org/2016/01/14/no-compromises/
http://the-paper-trail.org/blog/consensus-protocols-paxos/


-- 
Pure Personal Opinion | HoffmanLabs LLC