That's basically how I've done this in the past other than printing the report back on to the spool and then doing a spool print to a dataset.

Would be interesting to see if both SL298 and SL299 were opened at the same time.  Definitely looks like SL299 was opened right after SL297 was closed.  If both were opened simultaneously that would tell me some sort of CMOD hiccup.  If SL298 was opened first maybe something locked it up temporarily?

That definitely makes it difficult.  Of course the obvious question is, can the report creator throw something on the first page for you to trigger on?  Not always an option but I've gotten a few developers to do it before.

How different are the date locations?  For example are the "thru" dates locations consistent?  Basically I would try making a Trigger 2 which the date would be based off and have it point at blank spaces where there wouldn't be any if it was the date thru date format thus stopping the indexer from trying to pull in the date on those pages.

I believe the default for JOBBREAK is True.

Thanks Ed,
We did try that,  the DBAs failed to get a reorg to work after multiple attempts.  The docs are kept forever so I don't think there would be much space to reclaim anyways.
  I had to roll up my sleeves and restore my DB2 knowledge from my brain archives to dig down and find the issue.  What it looks like happened is when the DBA created the OAM database he created a relatively small simple database, particular the 32K tablespace.  When the users started hammering us with PDFs it filled the 32K table quickly and we hit the 32 dataset limit for the 32K tablespace OSMOTS32.  He repeated the same definition for our second OAM database so that filled up just as fast.
  I ended up having him define the next database using a partitioned tablespace for OSMOTS32 using VSAM extended in the back end and allowing 128 partitions.  Based on my estimates that should get us through a little more than half the year before we need another one.  We can live with that.
Figured I'd update just in case someone else runs into this.

Anybody run into the following issue with their OAM database?  Sadly, due to circumstances out of our control, we are way out of support on both CMOD and DB2 so we have no help from IBM forthcoming.  Shot in the dark that someone else has run into this.
  We have an instance that is loading a lot of PDFs through a windows loader into our CMOD instance on z/OS.  Everything is going fine until, after only a few weeks and only a few million documents, we hit this:

ARS0430E LOAD40PW OAM Error: ARGMVSST: 0000000b(0000000c-8802fc78) OND.  426
COLL.FOREVER1.SGD4099B.MCDY99(CAA.R7294) OAM OSREQ MSGAREA:  DSNT408I
SQLCODE = -904, ERROR:  UNSUCCESSFUL EXECUTION CAUSED BY AN
UNAVAILABLE RESOURCE. REASON 00C900A4, TYPE OF RESOURCE
00000200, AND RESOURCE NAME OBD4099B.OSMOTS32   

DSNT501I  +ONDDODP DSNISGPI RESOURCE UNAVAILABLE  709
           CORRELATION-ID=OND40P                     
           CONNECTION-ID=DB2CALL                     
           LUW-ID=DODP.DODPLU1.DBEDD5A785C4=172377   
           REASON 00C900A4                           
           TYPE 00000200                             
           NAME OBD4099B.OSMOTS32                     

Our DBAs are very inexperienced and have been unable to diagnose the issue.  Our solution was to create a new OAM database which, as mentioned, only lasted a couple weeks and now we find ourselves with the same issue.  Available storage is way more than needed so were having a hard time figuring out why OAM cannot find enough available segment space.  We have a half dozen other instances on our system that have been loading this way for years with no issues.  If anybody has run into something similar I would appreciate it if you could share your findings.

CMOD on z/OS V10.1
DB2 11
z/OS V2.4

All ours have indexing of some sort defined.  If you can it probably wouldn't hurt defining a Trigger1 at the very least.

Did you try double quotes around the parameters in the -b parameter?  -b "1,BranchCode"   
That's how we have ours working.

Maybe this will help for starters.  This is for DB2 on z/OS and shows the open segments for all AGs.  shows us % used.

SELECT DATE(CURRENT DATE) AS RUN_DATE FROM ONDDB.ARSUSER     
WHERE USERID LIKE 'ADMIN';                                     
SELECT SUBSTR(A.NAME,1,10) AS APP_GROUP,                       
DECIMAL((DECIMAL(S.INS_ROWS,11,2))/                           
(DECIMAL(S.MAX_ROWS/100.00,11,2)),11,2) PCT_USED,             
SUBSTR(S.TABLE_NAME,1,10) AS TABLE_P,                       
S.AGID, INTEGER(S.MAX_ROWS)                                   
FROM ONDDB.ARSSEG S, ONDDB.ARSAG A                           
WHERE SUBSTR(S.TABLE_NAME,1,2) <> 'SL'                         
AND S.AGID        = A.AGID                                     
AND S.CLOSED_DATE = 0                                         
ORDER BY A.NAME, S.START_DATE DESC;                           

Can't do it by ARSXML?  That's what I'd normally do.  The concept of adding 800 users manually is painful to me.

Since we haven't seen your indexing I would presume that in and around line 59 of your input data the indexer is finding the trigger you based that field off of.  check the definition for that trigger and see if it appears around line 59. eg if the field is set to FIELD1=2,11,10 then look 2 lines up from " 0081  02-" on record # 59.  If your trigger is found there you'll need to find a different trigger to base that date off of.

Your field for that index is pulling data from the wrong location on the report.  If it's truly trying to index a date you need to adjust your field parameters pick up that date.  It's clearly pulling a string from a different location and it isn't a date in the format of %d/%m/%Y

we could use a little more information.  What is the retention of the current OAM?  Will the retention change make it shorter or longer than the current retention?

Has anyone checked if your OSMC (OAM Storage Management Cycle) is completing successfully for your OAM storage groups?  OSMC should be running daily and it handles the transitions.  If there is any errors (missing objects, missing directory) the processing ends for that storage group and moves on to the next.  We've discovered in the past a few storage groups that had been erroring out for months and the docs sat on DASD well beyond their transition dates.