RE: Detached datasets and DRDA compliance

> From: David Morris
> 
> Hi Joe,

Hi David!

> I hope you have had a nice weekend.

Just getting ready to leave... waiting for the rest of the family to
wake up.  (I'm excited <g>)

> Single system and simple is always best if it meets your needs but
there
> are quite a few design requiments that are suited to a "detached
> dataset". I have used this type of technique in quite a few
programming
> languages and on several platforms -- its been a while but even
RPGIII.
> If you need to support undo/redo, pivot table type view/selection,
> multi-systems, fail over or the buildup of complex schedules/products
> then a detached dataset is likely to be useful. They can simplify
> development and testing and help you provide reliable and functional
> applications that perform well.

Oh absolutely.  Please note that I am not against detached datasets per
se.  I've used them many times in the past.  For example, I get the name
"detached dataset" from the concept of "detached processing", which we
were doing back in the 80's/90's over at SSA.  We had standalone OS/2
thick client applications that in effect downloaded portions of the
database and stored it locally for processing.  While not exactly the
same methodological approach, it served the same purpose: data could be
manipulated and updated locally without requiring host resources.  In
our case, one application was offline formulation; you could create
different versions of formulations using different ingredients and
different manufacturing processes and then compare the results,
eventually uploading the one that performed best.

No, you're quite correct that detached processing has merits in many
application situations, especially as we move into more heterogenous
environments.


> As always, there are trade-offs. Performance isn't that big of a
concern
> locking can be. In a stateless application locking isn't trivial but
> there are quite a few patterns that will work. I will usually use
> optimistic locking along with some sort of user overridable locking
> flag.

I've worked on projects of this sort for decades, which is why I bring
up the issues of database collisions, locking, and so on.  These are not
trivial issues, and also not ones that are easily "refactored" into
existing code.  Locking in particular needs to be addressed from day
one; are you planning to do before/after image comparison, lock flags,
update counts?  There are a number of mechanisms, but changing your
entire system from one to the other is a relatively painful process,
especially if you're not using a message-based server approach and are
instead leaving the locking code in the client.

With the .NET approach of detached datasets, it's clear to me that there
is no system-level approach to these issues and that each programmer is
going to be left to roll their own.  That's about as ugly a scenario as
I can picture.

Joe