| Well, I grew up with RMS-11 (and then RMS-32 and then Rdb...)
Anyway, I'm not sure that I understand your questions, but here goes:
RMS has a SIP (System Integrated Product, a layered product where the
software is already embedded in VMS like DECnet) that provides
Recovery-unit, After-image and Before-image journalling.
Be aware that (at least when I worked with RMS journalling) the process
using the journalled files and the files themselves had to reside on
the same node. i.e. no DECnet remote access to journalled files. This
had to do with the fact that the lock manager only works in a single
node or VAXcluster environment, not across nodes "joined" only by
DECnet.
By the way, RMS journalling is not a stellar performer (see the RMS
notes file). RMS had to be retrofitted for journalling and one of the
design goals was apparently to disturb as little of the code/design as
possible. On the other hand, journalling was designed into
Rdb/DBMS/KODA. Also, you can't back up the RMS journal on-line nor can
you close out the journal files and start new ones. In addition, RMS
journals changes at the bucket (like a database page) level, not
record or node. Therefore, change a record and you store the entire
bucket (typically several blocks) in the AI journal file.
Active files = large journal files
I didn't quite understand the DECmessageQ vs FTSV issue. DECmessageQ
has the ability to deliver individual records whereas FTSV delivers
files. While I've written things that use FTSV's pre- and post-
processing, as you could do to write a complete application, it would
seem to me that it would be easier to use DMQ unless your "unit of
work" is an entire file. Even then, it would be a toss-up. You'd
always have an easier time controlling the process programmatically via
DMQ then dealing with a lot of command files in FTSV.
In either case, from your description, it is clear that the process is
not "real time". If you can batch it up via FTSV, then the loading of
data into the Rdb database isn't time critical and in fact the Rdb
database doesn't up-to-the-millisecond data. (It's not real-time, it's
trendy! :-)
Hope this helps
Steve
|
| I've implemented a Rdb database server for a CSO, using
DECmessageQ for client-server communication. The retro-fitted
application has better response time using less resources than
the original version which had 80-100 users directly attaching
to the database. DECmessageQ can be an excellent tool for
passing messages between processes. However, as a colleague
of mine is fond of saying, "never underestimate the bandwidth of
a van full of magtapes.".
If you use some sort of file copy (FTSV or other), you may have
a simpler task of designing and implementing the application:
no two-phase commit problems, easier recovery, etc.
Send me VAXmail or call at DTN 328-3042 if you would like
to discuss this further.
Ken
|