Good afternoon,  Management is wondering if a new CMOD Zos release is expected in 2025.  (Just for planning purposes) We are currently on V10.5

Yep, that's the documentation page I'm looking at.     Not sure if anybody is using this yet.   We want to give it a try and just looking for any tips on how to set up the application.   We can work our way thru it, if not.

GXIFF to be exact - not XML

Up to this point we have always used generic indexing to load PDFs, Tiffs, etc.  We have a customer who wants to send the index information via XML.  I know that this is an option in CMOD, but i don't have an example of what the application will look to accomplish this.  Is anyone using XML indexing vs Generic Indexing for PDFs?  Can you share an example of an application.

Thank you for the response!
The developer running this utility tried LOAD_START_DT and that is giving the results that match our CMOD Client search.
I think we are ok.

We want to run ARSDOC Query against the System Load table to obtain daily counts for some of our cmod application loads.  However when we supply the date range we are looking for, using the ODDAT_LOAD_TIME,  the results do not match what we see in the CMOD Client.  How can we make this work and get proper counts for the proper dates?

           OSHELL /u/arssp/product/bin/arsdoc query -                               
        -h ARSSP                -                                         
        -G 'System Load'        -                                         
        -d /u/arsss/tmp1        -                                         
        -o LOADCNTS.GIAUTOF.out  -                                         
        -e ,                    -                                         
        -i "WHERE               -                                         
           ODDAT_LOAD_TIME >= '2021-11-04 00:00:00.000000'  -             
           AND ODDAT_LOAD_TIME < '2021-11-05 00:00:00.000000'  -           
           AND APPL_NAME LIKE 'GIAUTOF%'"                   -             
        -v   

VIEW FROM CMOD CLIENT
2021-11-05 21:08:42.328850   FEDEXPDF16002   GIAUTOF-V01
2021-11-04 21:08:25.774097   FEDEXPDF16002   GIAUTOF-V01
2021-11-03 21:05:20.620995   FEDEXPDF16002   GIAUTOF-V01
2021-11-02 21:07:43.251008   FEDEXPDF16002   GIAUTOF-V01

ARSDOC QUERY RESULTS:
Output:
11/03/21 21:05:20,FEDEXPDF16002,GIAUTOF-V01

This was the final step to make this work.  End of each line needs a hex'0D15' (and convert EBCDIC to ASCII)

   SORT FIELDS=COPY                         
   INREC BUILD=(1:1,78,X'0D15')             
   OUTREC OVERLAY=(1:1,80,TRAN=ETOA)       

Thanks for all assistance!

thank you sir.  Message received.

Ed,

You are absolutely right...that's what I'm doing.  But the customer wants to view this as a single document.
So they don't want each line loaded with different indexes, as a different entities.
Is it possible to load them as a single document?  But still have the LINES view sequentially instead of strung together?  (like so....). or am I reaching for the impossible here?

   BROWSE       TEST.ARSS.R6683.PREVAIL.RF80                  L
   Command ===>                                             
********************************* Top of Data *********
AL,   ,G ,S5498,00,00,2014-11-24,9901-01-01,000000700 
AL,001,F ,A0030,00,00,1996-01-01,2000-12-31,000200000 
AL,001,F ,A0040,00,00,1996-01-01,2000-12-31,000200000 
AL,001,F ,A0130,00,00,1999-01-01,9901-01-01,000002500 
AL,001,F ,A0300,00,00,1996-01-01,2000-12-31,000013000 
AL,001,F ,A0302,00,00,1996-01-01,2000-12-31,000013000 
AL,001,F ,A0304,00,00,1996-01-01,2000-12-31,000026000 
AL,001,F ,A0308,00,00,1996-01-01,2000-12-31,000026000 
AL,001,F ,A0310,00,00,1996-01-01,2000-12-31,000026000 
AL,001,F ,A0320,00,00,1996-01-01,2000-12-31,000013000 
AL,001,F ,A0322,00,00,1996-01-01,2000-12-31,000013000 
AL,001,F ,A0324,00,00,1996-01-01,2000-12-31,000026000 
AL,001,F ,A0326,00,00,1996-01-01,2000-12-31,000026000 
AL,001,F ,A0328,00,00,1996-01-01,2000-12-31,000026000 
AL,001,F ,A0330,00,00,1996-01-01,2000-12-31,000026000 
AL,001,F ,A0342,00,00,1996-01-01,2000-12-31,000013000 
AL,001,F ,A0348,00,00,1996-01-01,2000-12-31,000026000 
AL,001,F ,A0350,00,00,1996-01-01,2000-12-31,000026000 
AL,001,F ,A0360,00,00,1996-01-01,2000-12-31,000013000 

Ed,  I am closer.  I had to run a convert on the host file:

CONVERT EBCDIC TO ASCII
using �ETOA�

And now my data loads...and looks better...but it is loading as one continuous string instead of individual
comma delimited records.  (screenshot attached)

...and just one more clarification on this....there is actually not a SINGLE DOCUMENT that exceeds the 50MB limit in our file.    So apparently when we change our APPLICATION GROUP OBJECT SIZE it changes the way the documents are batched together and loaded to OAM.
Does this change your responses at all?  I am forwarding this info to tec support, but wanted to be sure I gave you all the information.

That's it!  You're a genius.  It's not loading for me yet....but the file on USS sure looks better.  Will plug away a bit more and may have another question if I can't get it to 'take'.

yes it's in a regular old mvs dataset.  I've got to convert ebcdic to ascii don't I.   is that the step I'm missing?
Recommendation on how easiest to do that?

thank you very much for helpful info.  Lori

Why do we get these unable to store object errors when loading CMOD using the Generic Indexer method?
Our response to these has been to 'tweek' the OBJECT SIZE in the application group until we can get the batch to load.  Is there a better way to handle these (or better yet to prevent these abends)?

SDSF OUTPUT DISPLAY CS98JABD JOB63866  DSID   167 LINE 1       COLUMNS 02- 81 
COMMAND INPUT ===>                                                  SCROLL ===>    CSR 
arsload: Using /u/arssp/tmp1 for temporary files                               
arsload: Processing file >/u/arssp/tmp1/cs98jabd<                               
arsload: Load Version <8.5.0.8> Operating System <z/OS> <04.24.00>             
arsload: Server Version <8.5.0.8> Operating System <z/OS> <04.24.00> Database <D
arsload: 03/24/16 12:59:56 -- Loading started, 560308704 bytes to process       
OnDemand Load Id = >55662-2682-0-380FAA-16885-16885<                           
An error occurred.  Contact your system administrator and/or consult the System
Unable to store the object >380FAAK<.  Object size 66199666                     
The last row successfully loaded was 913                                       
Loaded 913 rows into the database                                               
arsload: 03/24/16 13:00:34 Loading failed                                       
arsload: Processing failed for file >/u/arssp/tmp1/cs98jabd<                   
arsload: 03/24/16 13:00:34 -- Unloading started                                 
OnDemand UnLoad Successful - LoadId(55662-2682-0-380FAA-16885-16885) Rows Delete
03/24/16 13:00:37 -- Unloading of data was successful                           
arsload: Processing has stopped.  The remaining files will NOT be processed.   
******************************** BOTTOM OF DATA ********************************