Discussion created by ca.portal.admin on Jul 20, 2006
Hi Dave,
We make extensive use of TDMF and have not had any problems with it.
We are just coming to the end of a data centre consolidation project
where we have moved well over 50 CV's from one data centre to another
using TDMF. The CV's, which are very busy, were up and running during
the transfers and we have not had any problems.

The only time I have seen a problem was when we used it on a failing
box, moving the volumes off to a good box without having to take the
service down. The disk performance, which was very poor anyway, took a
further hit which caused IDMS problems - but I have never seen a problem
when using it against a good device.

I also used LDMF for the first time a few weeks ago. This lets you move
individual files whilst IDMS is still accessing them. Again no problems.


Steve Terry

'This post represents the views of the author and does not necessarily
accurately represent the views of BT.'
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no. 1800000

This electronic message contains information from British
Telecommunications plc which may be privileged and confidential. The
information is intended to be for the use of the individual(s) or entity
named above. If you are not the intended recipient, be aware that any
disclosure, copying, distribution or use of the contents of this
information is prohibited. If you have received this electronic message
in error, please notify us by telephone or e-mail (to the number or
address above) immediately.
We are using TDMF to copy our system from one set of dasd to another
set of
dasd. Has anyone out in IDMS land had any positive, negative or neural
experiences with using TDMF to move idms database while the database is
and running?

David Brenner



2828 N. Haskell

Dallas, TX 75204

214-841-6492 <>
IDMS Public Discussion Forum


"Ummm. It's either Don Casey (APL) or David Brenner (ACS), but no
evidence of any journal oddness taking place.

The corruption is not easily explained by journal issues; two records on
the same physical page in different set occurances go missing, and the
rest of the set is fine. Seems a little too tied to the physical page
to be explained by something related to journal image processing (either
outbound or inbound).

More of the story. We have had two separate incidents of broken chains
in the past few weeks, and one common theme is both occurred during
periods when volumes were taking place. The most recent break was
isolated to a 6 hour window in which the specific volume the file sits
on was being moved, we have just located the STORE event in the
journals, and are attempting to tie that to when the volume was
physically moved.

The earlier breaks (at the beginning of the month) are also loosely
correlated to volume moves, but those journals rolled off before we got
past the fix-the-problem-so-production-can-continue stage and into the
what-the-heck-caused-this stage.

For completeness, and in case it triggers any thoughts out there, there
are some other commmon themes in these breaks:

Three sets of corruption seen: two out of the first volume move attempt
(early July), one out of the second (earlier this week).

Two applications (A and B) involved. Both A and B in first event, only
B in second. No other apps appear to be affected.

Same CV for all three apps (our other CV, equally active, has not had
any issues surface).

We're not sure what's coincidence and what's cause at this point.

Don Casey