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

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" :)

I reached this post via a link from a CMOD Wiki page relating to arsdoc Return Codes.

When I run a similar command, I receive RC 3, not 768. The main differences:
a. I run on a Windows cmd client, a Windows 2022 server, and I use CMOD version 10.5.0.7 (on both ends)
b. I run arsdoc QUERY, not GET:
   arsdoc query -h ondemand -f "myFolder" -i "WHERE field1='value1' AND field2='value2'" -u LILOLDME -p C:\Temp\my.stash -L 1

Maybe they changed the return code in a later version, or maybe it is different whether you run GET or QUERY?

I know the z/OS versions sometimes are quite different, and that they may not be in sync with the Multiplatform versions, but it would be interesting to know; If you run the same again, do you still get the same RC? Or has it indeed been changed.

@Admins: please don't ban me for typing the "W" word in a z/OS sub-forum! ;)

Sure, here are a few things to check:

1. Did you verify that this particular file was included in your 10 GB file copy?
2. And its linked target? (Probably something like "f:\arscache1\<somenumber>\CBA\DOC\2FAAI")
3. Did you use the proper flags in robocopy so that the link file (I assume) was indeed copied as a link? Robocopy default is to copy the link TARGET instead of the actual link.
4. Also, even if it is a link, the link may be "dead". You can check this by right-clicking on the link file and check if it has a target file path or not (compare with the same file on your windows 2012 server)
EDIT:
5. Of course, also check the access settings for your OD user account against this folder structure. It is a beach  ;) in Windows, not like in the Unixes where you can just run "chmod sumthng" a couple o'times and it's done.

Hope this helps!

So, I have read existing threads here that touch upon the usage of the CMOD Unique DocID feature .

• Topic 1
• Topic 2
• Topic 3

I'd like to catch up with the community here as what can be done to create permanent document links. As far as I understand, even if we activate unique docids in CMOD, we are still required to use odfolder.recreateHit in combination with either getOpenDocid or getDocid - which IBM warns produces non-persistent links (in case of reloads etc).

IBM also states (in the same ODApi docs):

QuoteThe docid format is subject to change. If your application requires a unique document identifier to persist, consider using the Application Group field option "Unique ID".

What for, mate? How would that help? I can find no retrieve doc function that exclusively uses the unique docid (and perhaps a folder name or its Application Group or AGID) to retrieve a document.

So what's the use then, if we cannot create persistent doc links? (like the ones they have in that not-as-nice system "FileNet". This is a big commercial issue as the lack of links will entice companies into using or migrating to that system, instead of CMOD.)

Here is my current idea on how unique docids might be used to create persistent/permanent links.

1. Make sure the field you use for the Unique DocId has the same name in all Application Groups.
2. Search using a combination of folder name, application group name and the unique docid. For example:
URL Link = ODServer/search/folder_name/agcode+unique_docid
(such as www.mycomp.com/ODWEKServer/search/generalfolder/B6EA49-2ff02876-ffa5-4564-b0fb-966361dcf4f0 where "B6EA49" is an encoded Application Group Name and the rest is the actual, CMOD-generated Unique ID)
appgrpname = decodeAGname(agcode); // decodes "B6EA49" from the URL into some existing Application Group name
ODFolder odf = ods.openFolder(foldername); // "generalfolder" from the URL
odf.setApplGroupForSearchWithSQL(appgrpname);
ODHit uniqueHit = odf.search("WHERE $uniqidfieldname = $unique_docid); // get the unique hit
uniqueHit.retrieve('',C:\Temp\uniquefile);  // retrieve the unique file
//...Do something with the file...

(Note: this is untested code with the syntax of no real programming language - it is merely an idea)

Depending on how the rest of the web app is built, the user with the link will somehow need to be authenticated and have authorization to view the file.

Do you have any better ideas? Please share!
Or insights from IBM workshops etc? Sorry if I am currently not up to date.
Or improvements or helpful thoughts on the matter.

Quote from: mayank81089 on April 18, 2023, 03:08:14 PM
Thanks Lars,

Actually the problem was with the date format we figured it out and it resolved the problem

Glad to hear that you solved it - thanks for sharing the solution here!

Hey there,
How much data are we talking about - no of TBs and the number of documents? A rough estimate would be good enough.
If you plan to stay on the same platform (or close), an extract + ingest procedure may not be required.
Please provide some more details.

(PS: Send me a PM if you would like practical help for this project - advisory only or hands-on.)

There is one implication with installing all of CMOD when all you want is ODWEK, and that is when the yearly license audit takes place.
The automated tools will report CMOD as being installed on all of your ODWEK servers.
So far, a good explanation at a meeting has sufficed to convince the auditors that this is not a breach of licensing.
But it is the same type of meeting every year... 🙄😏

Hi Mayank,

Did you by any chance alter the data type of any of the fields in Production to DecFloat (or any other numerical data type)?
Since concat takes two strings and puts them together, I assume that tstcrt_number, cast_number and BS_CSI_No are all strings.
Another thing to check here, if for example BS_CSI_No is a numeric value, then your SQL should not have 'quotes' around its value.

Quote from: Justin Derrick on November 03, 2022, 05:26:04 PM
The largest one I'm aware of is/was in the low-single-digit petabyte range.  I would suspect that the number might have been 3.3 Petabytes...  33 sounds unfathomably large, even for CMOD.

-JD.

True, but still, IBM likes to brag 8) tell about it - here's a quote by Brian Phelps, available online:

Quote
IBM has thousands of archive and retrieval customers using CM OnDemand (CMOD), the largest of which has over 33 petabytes under management, with many others in the same size range.

Perhaps I misrecall slightly - 33 Petabytes is the max size one vendor's Storage repository can handle, and maybe it was 33 Billion documents in one system? Or Trillion ??? Anyways it was a huge number, that's for sure.

Hi all,

I believe I once saw a technical description of the famous OnDemand system, which allegedly holds 33 petabyte of document data on a standalone server.
But I cannot find it anymore. Does anyone have a link to where I can find detailed info on the setup of that system?

Does anyone have a list (full or partial) of the what the different bits in the MASK field of ARSSEG are for?
A guy asked us, the theory is that one or more of the bits determine which date style is used in the Segment date field of the table?

Yeah, I figured. But sometimes some of you wizards out there have something up your sleeve that I haven't thought of yet, so I thought "well, no harm in asking". :)
Thanks JD!

Another possibility, which I until just recently I thought only existed in Windows-based CMOD systems, but it does in Linux and probably in other Unix versions as well... is that your loads happen so fast that the Operating System runs out of ports. It actually uses one port per group/document in your input files (sic(k)!).

There are some simple commands to raise the number of ports available to arsload though. Unsure what they are in AIX, but you can Google that. If you run into a roadblock, get back to me and I'll dig out the solution from our archives.

I have noticed in Windows installations that the parser looking for the 4th filename part starts counting FROM THE END of the filenames.
So if the filenames don't have 8 parts (X.Y.Application.ApplicationGroup.Z.W.ARD.ind for example), it fails to pinpoint the correct file name part.

Try lengthening your file name from TEST1.0.INVOICE.INVOICE to TEST1.0.INVOICE.INVOICE.0.0.0.0 or TEST1.0.INVOICE.INVOICE.0.0.0.ARD and see if it makes any difference.