Thank you for the information.

First, before any of this I'd be running arsmaint -v (cache validation) and address - or at least document - any errors it reports.  I'd get started on doing this in prod now -- it can take a lot of time to repair manually.

For step 4/5, you don't need to rename the logical volumes, just mount the new lv at the old mountpoint.

And, of course, run the cache validation again as part of Step 7 while you're doing end-user testing.

Otherwise, the plan looks good!

-JD.

Hi Satya ,
A lot to unpack.

I do recommend taking a quick look at this https://www.youtube.com/watch?v=q5-wtUU6AAQ&t=16s video. It covers how CMOD manages large PDF print stream ingestion. In particular how we use PPDs as a means to quickly index PDF print streams, similar to TLE tags in AFP.

PDF indexer should run on a distributed platform then can remote load to CMOD on zOS. When we ingest PDF print streams, CMOD will extract the PDF resources, then compress the remaining text stream, again similar to AFP.

Are there size limitations - not so much, but you need to ensure you have the resources/memory/network bandwidth to manage the file. I also look at this in two ways. The PDF print stream can be larger (say a few GBs in size) but the underlying individual PDF statement within that stream might only be 1 MB. Also, for better performance, it might make sense limit the size of your PDF print stream to under say 2GB.

CMOD supports PDF/UA and PDF/A.

The URL was truncated and has been corrected.

Ed

I support the CMOD Administration, but am looking for advice regarding the underlying steps to convert the Cache storage from JFS to JFS2.  I was hoping someone could review the summary detail I got from the UNIX support team to see if these steps make sense or need changing.  We are hoping to do this in a Non-Prod environment before replicating the steps in Prod.

Step 1 : stop the CMOD application.

step 2 : create new filesystem (JFS2 )with new name.

step 3 : rsync the data from old filesystem to new filesystem

step 4 : unmount both filesystems and update the /etc/filesystem

step 5 : Rename the lvs and mount the filesystem

step 6 : Start and validate the application.

step 7 : after validation, remove the old filesystem

 
Any advice would be appreciated.

Thanks,

Hello Lars - please see the note that IBM recently put out in the Announcements section:

https://odug.net/index.php?board=3.0

Ed Arnold

Any news on a new version - or even regarding next fix pack?
Nothing here yet:
https://www.ibm.com/support/pages/lifecycle/search/?q=5724-J33

Additional Questions:

Are there any size limitations for PDFs that can be uploaded?
Does the solution support PDFs with accessibility features?
Does the tool support signed PDFs that are non-editable?

Just want to add my two bits, to the latest relevant conversation on CHARACTER REMOVAL.
When we were trying to move documents from one appgroup to another, a straaaaange error occurred.

ARS1129E Row 1:  The string "2017-03-24" could not be converted to a date from the format of %Y%m%d

But we HAVE "Character removal > Embedded - (dash)" activated!?!
So, it SHOULD work. *Lots of headscratching later:*

Now, there is this undocumented* thingie in the IND files, called "IGNORE_PREPROCESSING:1"... which I until now have dismissed.

But; The name of the section where "Character removal" is situated is actually - you guessed it - "Preprocessor Parameters".
(Whoever reads those section headers, anyway... ;-) )

So, after editing the IND file and setting "IGNORE_PREPROCESSING:0" - BAM, then arsload works as expected again.



*: Try googling ibm ondemand 10.5 "IGNORE_PREPROCESSING" :)

How is PDF'd stored in Z/os . Any suggestions or pointers where i can find more information