Saving and restoring LOB data (was Max length of VARYING fields)

From: Buck

Isn't this what a Datalink field does for you? The concern with

datalinks,

though, is that they aren't saved and restored with the SQL data.

Exactly, and so now we step straight into RPG's strong/weak point -- the
tight integration with DB2 for i5 OS. Without that tight integration,
RPG is just a funky scripting language for SQL. With it, the compiler
folks need the database folks to er, cooperate :-)

This is an interesting issue. Ignoring your little slam of RPG (without the
engine, a Ferrari would just be a funky soap-box derby car <smirk>), the
whole issue of LOB archival is a good one.

As more large objects become a requisite part of data management, should
they really be part of the standard save/restore of relational data? It's
an interesting question. While the initial reaction might be that all
related data should be saved at the same time, it seems that the very nature
of much LOB data (large, essentially immutable streams) means that the very
archival medium (much less things like retention rules) should perhaps be
different for this sort of data.

So should we now start thinking about multi-medium save and restore
capabilities? Specifically relating back to SQL, should we in effect be
able to assign different save/restore attributes at the column level?

It's an interesting question, and one we already face to a smaller degree
with basic source management. Now that things like HTML files and images
are part of our application architecture, the standard QSYS source member
save and restore no longer works. And simply bumping up to a Unix-based
source control system doesn't work, since we're not just talking about
multiple data types, we're talking about multiple platforms! There aren't a
lot of complete multi-tiered version control, build and deploy solutions.

Ah, the new world of computing.

Joe