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

[lists at openmailbox.org]

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.

> 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.

> > The way it often works in banking that use IBM teller terminals is store
> > and forward. If a plane hits the data center the transaction will
> > eventually get committed to the DR host.
> 
> Teller transactions are typically considered minor (less than a thousand
> or two), so store-forward may be ok for that level. The bank will often
> decide to eat the loss should this type of event happen.

They don't have to eat them except in plane hits bank branch scenario and
only in the tiny window during which the teller screamed ^% ^&(*@ as the
plane became visible through the branch window. This is not normally going
to be much of an accounting issue. The latencies are extremely low. I just
meant in theory possibly not zero, depending on plane's arrival time.

ATM and POS transactions are often processed like teller transactions and
large banks have significant volume.

> OpenVMS clusters are designed for server-server and site to site DR/DT
> features - not client or branch DT/DR.

Ok, well that sounds fine except for what I was talking about! We don't
really have a server to server model.

> Store and forward might be ok for remote teller / ATM devices, but they 
> would not protect server to server transactions at the back end.

That's because there is usually only one server (mainframe) unless they are
replicating to a DR site. And both sites are most often in places where
disasters shouldn't happen- underground, reinforced, etc. Not that they
never do but it helps.

> > I don't understand how there could be no data loss if the data source

By this I meant the source of the transaction as in front-end.

> > was struck. I understand the data loss could be mitigated even greatly,
> > but to say no data loss at all seems physically impossible, having
> > nothing to do with software/hardware technology but just as a
> > consequence of transmission
> > time, etc. To say the database (whatever that means) is always in a
> > consistent state, sure, that has to happen and has for many decades.
> > Again,
> > probably not to this day on many platforms but at least yours and mine,
> > probably implemented in very different ways.
> 
> See above note - when plane hits DC1, data is not lost if the App errors 
> out and the App takes whatever action is deemed appropriate. If local
> branch is using store and forward, then when the cluster state transition 
> completes (usually less than a couple of minutes), then the App can retry
> sending the update or ask the teller to re-enter or ??? and the data will
> be applied to the DC2 site.

Yeah, I said that. I used unclear language when I said "data source" above.
I meant transaction source. I mean if plane hits bank branch, or internet
shop, etc. Front end.

> > 
> > I can't imagine we're even talking about this today in 2016. It's so
> > obvious that when you're dealing with money you have to have two-
> > phase
> > commit and preserve LUW and the atomicity of your transactions and all
> > the
> > underlying pieces.
> 
> That is a critical application view, but feeder / ISV apps may not have
> 2PC as part of their design.
> 
> > 
> > > If transaction updates are not critical, then it's not a big deal. If
> > > the transactions are measured in large $'s (banks measure some in
> > > millions of $'s), then it really is a big deal.
> > 
> > Right, and the facilities to do that have been available for decades on
> > IBM, even without anything resembling clustering.
> > 
> 
> 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. I can remember being in a few DR tests to verify the plan worked
ok. But I can't remember a real disaster ever happening. I bet you really
don't know how a real one will affect you until a real one affects you.