Thanks Rob, I realize that. Way back in 2017. Time flies ...

We'll submit this as a possible improvement. The version number is in a fixed position so different versions could co-exist in most cases. Or it could be a selectable choice which version to use, system wide or per application group.

Quote from: rjrussel on June 10, 2024, 02:07:44 PM
Version 7 UUIDS weren't a thing when the feature was added to CMOD.

I can also add that I ran a count of the first two bytes of the CMOD generated ids and, not surprisingly, all 256 possible values between 00 and ff were represented with a fairly even distribution.
//Nils

Thanks Justin,

Sorry to correct you but UUIDs are 128-bit and the dashes are in very specific positions. :) Nicely described on Wikipedia: https://en.wikipedia.org/wiki/Universally_unique_identifier

After testing the export/reload approach on some 100 thousand documents it is quite clear that the CMOD generated UUIDs are version 4 (random), indicated by the number "4" in the first position of the third group (xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx). Version 7 would probably have been a better choice to improve the database indexes. Or you could by all means identify it as version 4 and still use a combination of timestamp and randomness, which is what we have done in our UDF tests to update existing data.

Oh well, it's never easy, is it? Heads or tails ... :-\
//Nils

Does anyone happen to know how the Unique ID values are generated by CMOD? Do they conform to any of the defined UUID versions?
We are looking into ways to create UUIDs for old documents without export/reload and it seems to be good practice to use a timestamp-first format.

Does anyone know the difference between arsdoc delete and its bulk siebling that was introduced in 10.1.0.4?

The description of the bulk_delete function merely says "Use to delete a large number of documents from the system" and the command parameters are slightly different. No explanation of what the real difference is, and why would you ever want to not use the bulk_delete function?

We need to delete millions of index records from an application group and I started off using the regular arsdoc delete which totally hogged the system. Deleting 100,000 docs could run for hours.

I did one small test with bulk_delete and it was lightning fast which made me wonder if it takes some undesired shortcuts, like not deleting annotations. Haven't mustered up the courage to use it again without knowing exactly what it does and does not do ...

Appreciate any insights.

//Nils

Sorry for late response, been a bit busy after upgrade from 9.5 to 10.1 recently ...  :)

Our front-end application currently uses a combination of folder field and application group field search. If a folder contains multiple ags, folder search is used. If a folder contains a single ag, ag seach is used. The logic is obviously different for these two paths and is of course bound to break if we add a second ag to a single ag folder.

The search in question works with the single ag folder but we must move away from that and only use folder search.
//Nils

Thanks, RR. The filtering method has been used successfully but now the result sets are growing too large.
A typical search looks for a customer number, a date range and a variable number of document types. The "document type" is a mapped field.
Without the document type(s) in the search, the result could easily be tens of thousands, which after filtering could boil down to a few dozens.
//Nils

Thanks, Darrell.
That approach would be possible for just a few values but the requirement is more than that.
I forgot to mention in my original post that they are using the ODWEK Java API at version 10.1.0.4. They have now made a workaround and perform a separate search for each value, which of course isn't very efficient.
Maybe this is a candidate for the wish list for the product. I have often missed the ability to select multiple search values in the dropdowns in the client as well.
//Nils

The development team maintaining our CMOD frontend has run into a problem with searching folder fields where the underlying application group(s) have mapped values.
Some customers want to query such fields for multiple values but the only valid search operator is "equal". Also, they want to search using the database values, not the displayed values.
A typical use case is searching for all documents with certain document types (e.g. "Invoice", "Insurance Policy" etc) for a certain period.
I have tried adding a folder field with the "Internal" attribute which enables searching by database value, but it is still limited to the "equal" operator.

Any suggestions (preferrably not involving raw SQL search) would be greatly appreciated.

//Nils

Great news with Hitachi Content Platform finally being supported.
Does anyone have a technical description of how this support is implemented?

Did you, by any chance, forget to transfer the index file in ASCII format this time?

//Nils

Your trace shows that the load program still expects an ACIF index file. See if it makes a difference if you put the load file name after all other options:

"C:\Program Files\ibm\OnDemand for Windows\bin\ARSLOAD.EXE" -f  -I atp-20tapp003 -g NAFSAG -a NAFSAPP -X G "D:\OnDemand_data\arsdoc_get.12366.NAFSAG.NAFSAPP"

You could also temporarily change the indexer setting in NAFSAPP to Generic, but remember to backup any ACIF parameters in the app and restore the original indexer settings after you are done loading.

//Nils

Joining the party late...  :)
The error message in the first post indicates that the AG is defined with ACIF indexing so the load program expects an index file in AFP format.
The index file produced by arsdoc get is in the Generic indexer format so you must use the -X G flag in your arsload command.

It's been a while since you asked, but since there are no responses...

I have arswww.cgi running in a new development system with exactly the same setup. The following page was very useful when configuring IIS:

http://www.coastrd.com/cgioniis7

Giving permissions to the built-in IUSR account seemed to be the key to your issue.

The 8.5.0.0 version of the CGI hangs if you use POST requests from your web pages. This is solved in 8.5.0.1 but a new bug was introduced which causes document retrievals to fail if the folder name is obtained from a cookie and the folder name contains accented characters. I have an open PMR for that.

Apart from that, everything seems to be working ok. We will upgrade our production system to this environment as soon as the accented character problem is washed out.

A word of caution if you install the OnDemand client on the same machine as TSM. I recently did that in my lab environment and when I uninstalled the OD client (version 8.4.1.04) it blew my TSM installation to pieces. The OD client uninstall dropped the whole registry branch below HKLM\SOFTWARE\IBM\ADSM and probably did some more nasty things since restoring this registry branch was not enough to cure the TSM server...