| Hi Bob,
I'm not entirely familiar with PATHWORKS and the SEQUENTIAL vs.
SEQUENTIAL_FIXED issues as far as these two particular terms are
concerned. If what I'm about to say doesn't make sense, I'll do some
more research and try to fit my information into the terms you're
using.
From what you wrote, it sounds to me like there are two different
issues here. The first is the storage of Word documents in CMS, and the
second is the prepending of CMS history information to the Word
documents when they are fetched out. I'll tackle the second one first.
CMS does not, by default, either prepend or append history information
to elements. However, it can be instructed to do so, either on the
CREATE ELEMENT/HISTORY or the MODIFY ELEMENT/HISTORY command. This can
be useful for source files but is *not* wanted for binary files such as
Word documents! So my suggestion would be to check to see whether the
history attribute has been set on the Word documents within CMS by
doing a SHOW ELEMENT/FULL. If the history attribute is set, it will
appear in the resulting output. You can turn the history attribute off
via MODIFY ELEMENT/NOHISTORY, and that will cause CMS to cease adding
the history information to the element when it is reserved or fetched.
The first problem, however, is more serious. As I understand the
process, when an element is replaced in CMS, CMS does a
record-by-record comparison to see what changed and modifies its
internal delta file accordingly. Even when an element is created for
the first time, CMS processes it record-by-record. Now, this is fine as
long as the file is a valid RMS file. However, if it is not, then in
the process of storing the element, CMS will corrupt the file, because
it uses RMS calls to read each record. There is no way to recover from
this, as the file is corrupt within CMS.
PATHWORKS can be set up to copy files as straight binary data or as
valid RMS files. This probably maps to your use of the terms SEQUENTIAL
and SEQUENTIAL_FIXED, respectively, but I'm not familiar enough with
PATHWORKS to be able to say for sure. In the former case, however, if
an attempt is made to store those files in CMS, CMS will corrupt them.
In the latter case, CMS will handle them just fine.
If the Word documents are corrupt in CMS, there is no way to recover
them short of deleting the element and all of its generations and
starting over with a known good RMS file for that element. As an aside,
the DCL command ANALYZE/RMS can be used to check whether a file is
valid as far as RMS is concerned. If no errors are returned, then the
file may safely be stored in CMS. If errors are returned, then any
attempt to store the file in CMS will result in a corrupted CMS
element (but will have no effect on the file itself if /KEEP is
specified).
-- Daryl
|
| Hi again,
I forgot to mention it before, but the customer might find the CMS
Client for Windows helpful. The Client will let them create, fetch,
reserve, and replace elements and supports a number of other CMS
features as well, all without having to leave their Windows environment
and also without having to worry about how PATHWORKS is set up. The
Client always uses valid CMS files when interfacing with CMS on the VMS
server.
If interested, please contact Cathy Axel, the DECset product manager.
-- Daryl
|