VERIFIED SOLUTION i
Various Doc1 GUIDs explained
UPDATED: September 18, 2017
I see various tags in the Doc1 Interchange Journal (DIJ) What is the difference between DocMasterID, DocInstanceID, and JobGUID?
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE eGAD SYSTEM "eGAD.Dtd">
<Version major="4" minor="3"/>
<ResourceGUID p="1" value="33DC34D3A8474AD599203ABDF995BA63"/>
<ResourceGUID p="0" value="86BC1A67257548458F5EB0FAE579C0EB"/>
<document docID="1" docMasterID="796ED2FB7E2B8F61B521F9DEFE2B9854" docInstanceID="DC005E00992811E3AEC544AC881EB40B">
Grant Boyle - 19-Apr-2012 13:07:12
(1) docMasterID from the XML journal is copied to the document property doc.guid which is used
by default in constructing the guid.dri index entries.
(2) It is legal to have duplicate values of docMasterID. With E2AM, you are allow to load
multiple renditions of the same document content into vault. For example, you could have an HTML
and AFP version of the same invoice loaded. When rendering, vault will choose among the
renditions the first guid that supports the requested output mode. So you can think of documents
with the same docMasterID as having the same content.
(3) E2AM has its own database of what documents exist. Normally this data is populated by Vault
passing the XML journals on to E2AM once they are loaded (via the PresentJournalPath= setting in
the DocMasterID is assumed in a couple of cases to be unique. Some versions of e2 Present will
choke on a file that contains a DocMasterID that is the same as a record that has already been
processed. Even though the data is different within the DIJ entry, it’s not different enough to
create a unique ID.
Per Engineering, 2009:
The official word from Development on DocMasterID
The master ID is generated from a hash of:
Offset to start of publication
Offset of end of publication
DIJ Account number
DIJ Statement date
So given sensible data it should be unique. However, items 1) and 2) are a byte offset to the
start and end of the publication input data. So you could get duplicate MasterIDs if the input
data was fixed record length. (i.e., mainframe data among others)
If a customer uses data that has fixed length records and fields AND they do more than one run
that contains records with the same statement date, it is highly likely that the first
DocMasterID in subsequent runs will match a DocMasterID in a previous run.
The JobGUID from DOC1 is produced solely based on the Date plus the Run Time of the job. The
Run Time is calculated down to the second:
So it's possible that if you start a job within the same second as another, the JobGUID can be
the same, even though the files are unique.
My recommendation is that be sure to run your jobs at least one second apart from each other at
any given time. This would ensure that the JobGUID is unique every time.
In XML journal you can check <datetime>20140218214412</datetime> field to see when the job was
run. If the <datetime> tag in two journals has the same value, the JobGUID will also be the
From: Steven Bickmore
Sent: 15 May 2009 10:18
To: Gary McMahon
Yes, DocInstanceID in the printstream is about as unique as you can get, it’s generated using
the MAC address and current time.
Per Gary McMahon:
Generate produces duplicate DocInstanceIDs if you have Jobs running in parallel on the same
physical machine. So the algorithm that DOC1 uses to create doc instance id’s needs to be
modified in order for them to be unique. Unfortunately there is no way at this point in time for
the DOC1 programmer to influence how the doc1 instance id is created. Neither DOC1 nor PCE do
allow modification of this.
- No Downloads