I learned that new function level is available for Db2.

At this time, there is no plan for CMOD to require any of these new functions.

Db2 13 - What's new - Function level 507 (PH64907 - April 2025)

Function level 507 introduces online conversion of table partitions from PBR to PBG, enhanced concurrency for system temporal tables, LASTUSED support for application plans, more flexibility for temporal and archive-enabled tables, and greater than 64 GB allocation quantities.

There's a few reasons not to do this...

- The file it generates may be *enormous*, especially if the loaded files were compressed.
- Older versions of CMOD had issues generating generic index files over 2GB in size, rolling over the byte offset back to 0.
- Loading a single large file with data that spans years may break expiration processing, especially if the expiration type is 'Load'.
- Any error retrieving data from CMOD will result in the entire extract failing.
- If there's more than a couple thousand documents, you'll quickly reach a point where your filesystem will be overwhelmed, and simple commands (ls / cp / mv / rm) will take several minutes.

Most folks extract by Load ID or date or by a mostly-unique ID like customer number, etc.

If this is a particularly large job, reach out to me via eMail -- I have a fast & automated extraction utility I use for migrations.

-JD.

Goodday all,

Is it possible with the arsdoc get command to retrieve all archived documents from the AG?

I have tried some arsdoc get parameters, but not luck
Any help will be appreciated.

I am using this command:

arsdoc get -a -d /tmp/cmod -f "MSM Consignment Notes" -h archive -i "where CONSIGN_NO='*'" -G D150 -o TEST

Tried also with: CONSIGN_NO='%'

Thankyou

Kind regards ,

Michel

As of this writing there is no plan to replace the 10.5.0.9 Admin Client on the download site.

IF your shop is going to be administering ODF

THEN use the 10.5.0.8 Admin Client

OR request a copy of the 10.5.0.9 Admin Client from Level 2 that contains the fix.

Ed

Hi All,

Does anybody have any knowledge of OpenText? Is this a similar product as CMOD?
Customer of mine want to migrate to OpenText. I would rather stay at CMOD. I need some counter arguments why we should keep CMOD for archiving our documents.

Kind regards,

Michel.

Don't install the 10.5.0.9 admin client if you're going to use it to administer ODF.

Otherwise, it's fine - just ODF administration has an issue.

I'll append here as I find out more.

Ed

If holds on data are placed in OAM, expiration processing could be an issue.

CMOD does not know about OAM holds.  Unpredictable results may occur including ending up with orphan data objects.

Any holds on CMOD data should be managed from CMOD itself.

The optional feature ERM (Enhanced Retention Management) is the supported solution for managing holds.

https://www.ibm.com/docs/en/cmofm/10.5.0?topic=ondemand-enhanced-retention-management-erm

Ed

Hi Joe - hmmm - I see a similar problem out there in my archive, hope this helps.

________________________________________
|
| Short answer:
|
| manually separate the documents in ODFProcessDist.java and create 3 separate files and attachments.  If these are PDF files you may need to use the PDF2PDF Transform sample to properly format the multi document PDF and then use ODFProcessDist to break it up into multiple attachments
|
_________________________________________

| Longer answer with discussion:
_________________________________________


Problem Description:
It has been observed that when processing ODF rules, multiple documents that are returned from the search query that is defined at the Report Bundle level is returning multiple hits as a single file for an attachment in preparation for emailing.

For example, the following query.

MemberID = '12345678911'

...should return x3 documents (pdfs), as three separate documents can be identified within this single load.

I can see from the system log that a bulk document retrieval process is occurring under the hood, of which is returning a single .pdf file, with the three pdfs combined.

BULK DOCUMENT RETRIEVAL
 
Application Group                                            Agid         Flds->Handle
--------------------------------------------------------------------------------------
EOBDEMO                                                      5017         ->35FAAA,0,2144,0,2144,0x55,0x44,0,1,0
                                                                          ->35FAAA,0,3759,2144,3759,0x55,0x44,0,1,0
                                                                          ->35FAAA,0,5367,5903,5367,0x55,0x44,0,1,0

Is there a way to force CMOD to return the results as separate documents, of which can be treated as three separate attachments?

Is this cannot be achieved should a feature request be raised?
___________________________________________________________

The initial reply was:

ODF doesn't know there are 3 different documents. Whatever is returned using the sql statement is considered one report bundle.  If we need to separate the documents, we can add a qualifier to the sql statement and define a separate report bundle for each query. Then each report bundle would be retrieved separately.

____________________________________________________________

Dialogue:

Here is the issue we are facing in a little more detail. I will take the following use case whereby I would like the ability to send an email either with multiple attachments or a single email with a single attachment.



I have successfully made the appropriate updates to the ODProcessDist.java to handle this scenario, of which works perfectly using the steps described in you last comment, by having additional Report Bundles for a distribution for example



Report Bundle 1 = MemberID = '12345678911' and Invoice Number = '1234'

Report Bundle 2 = MemberID = '12345678911' and Invoice Number = '1235'

Report Bundle 3 = MemberID = '12345678911' and Invoice Number = '1236'

This example works fine however the issue comes whereby the MemberID will always be a static value, however the Invoice Number will not. This means we cannot pass an Invoice Number in the value as the value will not be known at the time of distribution.

How would this be achieved in this scenario?
________________________________________________________

The only other method would be to manually separate the documents in ODFProcessDist.java and create 3 separate files and attachments.   

If these are PDF files you may need to use the PDF2PDF Transform sample to properly format the multi document PDF and then use ODFProcessDist to break it up into multiple attachments

Refer to the following on PDF2PDF:

https://www.ibm.com/support/pages/define-generic-transform-odpdf2pdf-manipulate-pdf-file-distributed-odf-version-9507

If further assistance is required someone with expertise in this area will need to be engaged.

Ed

We are trying to implement ODF to email PDF formatted Invoices to customers.  The invoice application creates a single PDF file with hundreds of invoices each evening.  A specific customer number may be on many invoices within the PDF load file.  OnDemand Loader successfully segments the PDF load file based on a change in Invoice #.  The result is that CustomerNo 123 may end up with 5 or more invoices that can each be searched and retrieved individually from the OnDemand Client.

We have a unique ODF Bundle configured for each CustomerNo that has an SQL Source defined as CUSTOMERNO = '123'. We have a Distribution associated with that same CustomerNo = 123. So that each Distribution gets an email with their CustomerNo invoices.

This all works great, EXCEPT.  If there are multiple invoices for CustomerNo 123 within a Load, the ODF Bundle only retrieves 1 of the invoices matching the CustomerNo.  We can not figure out how to configure ODF to continue searching OnDemand and retrieve all of the invoices for this CustomerNo. 

I am hoping this is a simple configuration error on our part and not a limitation of ODF.

Has anyone configured a similar use case and provide advice?

BTW, the server is running CMOD for Windows v.10.5.0.2

Thanks,

Had a recent report of an APK460S on z/OS, loading from a PC to the mainframe.

APK460S

TRIGGERS SATISFIED, BUT INDEXES WERE INCOMPLETE AT END-OF-FILE.

The TRIGGERn parameters specified in the parameter file were met, but the end of the file was reached before the INDEXn parameters were located.


In that case that means that while this trigger was found



 TRIGGER1=*,1,X'31',(TYPE=GROUP)



But then based on that trigger the index was not found.



FIELD1=2,17,30,(TRIGGER=1,BASE=0)

INDEX1=X'53454354494F4E4944',FIELD1,(TYPE=GROUP,BREAK=YES)


Cause and resolution:

The mainframe would double-space before printing the change details line.

Windows still does the double-space when the report prints, but indexing was thrown off by 1.

After updating the FIELD1 line to look down 1 line instead of 2 all is well.