| Nope, you can't do concurrent processing like you described.
The XREF file (cross-reference file) is locked during processing
to protect users from accessing any older XREF file during processing
(this would cause the cross references to be resolved incorrectly).
There is a discussion of this in the User Manual, Vol.1, page 4-16,
although this discussion is related to processing different elements
of a book, rather than the same element or file.
-Barbara
|
| As Barbara says, we lock the XREF file to prevent it being
**updated** simultaneously by two separate processes. Since
the reading and subsequent updating of the XREF file takes
place during tag translation, and during only a part of
tag translation, the actual time when a collision can occur
is only a small part of the time to do a complete DOCUMENT
command.
However, lots of DOCUMENT command executions never have anything
to do with an XREF file because they are not bookbuilds or
element builds. (Remember a bookbuild is a DOCUMENT run in which
the source file has a <PROFILE> tag, and an element build is one
in which the /PROFILE qualifier has been used.)
So, our steps to insure the integrity of the XREF file are
minimum protection for a file that is to be updated.
However if you have an SDML file, and you start up two processes
that have the **same default directory** and you start a DOCUMENT
command in each process, you will probably get into trouble with
the other temporary files that DOCUMENT is creating during a run.
If the processes are in **different default directories** you are
safe.
bill
|
| Ah, right, I was not on target with the cause of the problem.
Thanks for explaining it, Bill. I'm making a note to include
this info in the User Manual, Version 2.
Barbara
|