Messages

46

General / Re: Latest IBM OnDemand Training

« on: July 22, 2023, 09:33:53 AM »

Hi Wayne... 

Admittedly, this is quite old, but I believe most of the info is the same.

https://ODUG.tv/ODUG-IndexingPDFonCMODv95withBudPaton-2015-09.mp4
https://ODUG.tv/ODUG-IndexingPDFonCMODv95withBudPaton-2015-09.pdf

-JD.

47

z/OS Server / Re: CMOD for z/OS v10.5 load server

« on: July 22, 2023, 09:06:30 AM »

Generally speaking, client software (arsdoc/arsload/windows clients) works with at least x-1 -- so unless you're doing something exotic, a simple load from one server to another should work.

Since IBM isn't willing to guarantee/support this cross-version functionality, your only alternative is to test it thoroughly in your dev region.

-JD.

48

z/OS Server / Re: ARSMAINT - Catchup after migration

« on: July 11, 2023, 01:08:06 PM »

Nope.  Running a single AG at a time is a good idea though.

Only other advice I have is to run it over a long weekend when usage is low.

-JD.

49

z/OS Server / Re: Encoded and OptionalAttribute fields to define in odindex

« on: June 29, 2023, 12:27:30 PM »

After feed back I went back and verified some information , i think Its not worth and amount of work involved

Honestly, I don't think anyone in this thread really understands what you're trying to do.  I'll recommend some more education and training for your team about what CMOD is, what it does, and how it does it.

The amount of work you're doing is far, far in excess of what is necessary to store XML data in CMOD.

-JD.

50

z/OS Server / Re: Change Filter to Index

« on: June 28, 2023, 11:30:34 AM »

The setting you're changing adds an index at the database level. 

When you move from Filter to Index, and click 'Ok', there will be a delay while CMOD tells the database to build those indexes on ALL of the database tables -- it will look like the Admin client is stuck, but it's just waiting for the database to finish doing all the work. 

Because this requires a lot of work for the database, it's best to do this during a maintenance window, even though it doesn't require a CMOD outage.  And finally, the setting affects old AND new documents.

Hope that helps.  Take care. 

-JD.

51

z/OS Server / Re: Encoded and OptionalAttribute fields to define in odindex

« on: June 19, 2023, 07:49:34 AM »

And base64 isn't encryption.  Unless they're doing something bizarre like encrypting the data, converting the binary data to base64, then storing it as text.  Quite literally a waste of CPU and storage at every step...

-JD.

52

z/OS Server / Re: Encoded and OptionalAttribute fields to define in odindex

« on: June 09, 2023, 08:11:22 AM »

That's the first time I've ever heard of base64 encoding data for storage in CMOD...

Base64 is normally used for sending binary data through systems that only support text encoding (like eMail)...  What's the rationale for converting to Base64?  The other problem with Base64 is that it INCREASES the size of files, costing you more in storage...

That issue aside...  XML is already supported by CMOD...  Why not use the native support to store the XML?

-JD.

53

z/OS Server / Re: Encoded and OptionalAttribute fields to define in odindex

« on: June 02, 2023, 08:04:35 AM »

So...  A few things...

You haven't described how the documents are 'encoded'.  Can you give us more information on that?  Remember that CMOD is simply a repository, and anything you load will be returned to you in the same format (with minor exceptions for document transforms at load time like line data to AFP and AFP to PDF).

Second, CMOD doesn't like 'null' fields, as it's ambiguous, and makes documents harder to find in the future.  If there's no way to avoid empty fields, then consider setting a default value in the CMOD Admin Client instead of trying to insert empty fields into CMOD.

-JD.

54

MP Server / Re: CMOD V8.5 -> 9.5 Upgrade Error message ARS4012E for arsdb -uv

« on: May 15, 2023, 11:49:53 AM »

It's a common error:  https://cmod.wiki/index.php?title=ARS4012E

Consider applying all available fixpacks to v9.5 before performing the upgrade:  http://cmod.co/95013

-JD.

55

MP Server / Re: Sectrum Protect Version 8.1.8.0 Move from Windows Server to Red Hat 8.6

« on: April 21, 2023, 10:26:46 AM »

That's not really enough information for us to be able to answer your question. 

Can you give us details about how the system is configured so we can better understand your situation?

You need to help us so we can help you. 

-JD.

56

MP Server / Re: Question Setting Up LDAP & SSL Authentication for Windows Clients on CMOD V10.5

« on: April 20, 2023, 11:22:41 AM »

Hi Janine.

You don't need root to create or manage the key database or stash files.  CMOD just needs to know where they are, and have permission to read them.

As for the ARSLDAP.INI file, it appears that you only need that if you want to create custom error messages, everything else is configured in ars.cfg.

You can find more information on LDAP-specific parameters here:
https://cmod.wiki/index.php?title=ars.cfg#IBM_CMOD_LDAP_Configuration

Good luck.

-JD.

57

Report Indexing / Re: Ignore 2GB File Limit with Daemon

« on: April 12, 2023, 07:51:27 AM »

There doesn't seem to be any documentation on this option -- do you have any info you can share on this option?

-JD.

58

OD/WEK & JAVA API / Re: How install odwek v10.x only to linux?

« on: April 12, 2023, 07:50:41 AM »

Servers are still licensed on Processor Value Units (PVUs) right?  Otherwise someone could archive terabytes of data and pay nothing as long as nobody ever accessed it, which doesn't seem right. 

-JD.

59

Report Indexing / Re: Ignore 2GB File Limit with Daemon

« on: April 11, 2023, 06:30:43 AM »

Exporting it in the profile of the account that runs the process (or in the shell script that starts the arsload daemon) is the right way forward.

-JD.

60

MP Server / Re: Sectrum Protect Version 8.1.8.0 Move from Windows Server to Red Hat 8.6

« on: March 25, 2023, 04:55:42 PM »

Hey Dani.

You might get more help from the mailing list & forums dedicated to ADSM / TSM / Spectrum Protect at ADSM.org.

As for architectural issues, you can absolutely run TSM and CMOD on the same server, but you'll want to add more RAM and CPU.  You may want to keep them separate if you have a very high level of transactions, to help spread the load across separate servers.

Alternately, you could migrate the data to any number of the cloud storage options, or even just a plain filesystem if your storage is in the sweet spot.

How much data do you have stored in TSM, or do you have a tape library?

-JD.