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"?>
<eGAD pakUID="PID_DC005E01992811E3AEC544AC881EB40B">
<platform>HP UNIX</platform>
<Version major="4" minor="3"/>
<NativeFormat value="AFPDS"/>
<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 
Jeremy Ridge:
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