Messages

886

MP Server / Re: Which TSM server version?

« on: February 02, 2011, 03:05:34 AM »

Hello Michel,

Well I have found this page : http://www-01.ibm.com/software/support/lifecycleapp/PLCDetail.wss?synkey=V649976C05962P29&from=spf and it clearly states that the end of marketing for TSM 5.5 is 16.07.2010 for AAS (I don't know what it means).
For PPA (Passport Advantage), well the End Of Marketing is not yet reached.

But it has not yet an End Of Support date.

I suppose, that the End Of Support will happen in the middle of this year, but I really don't know. It would be better to ask your IBM representative if they have an idea of the EOS date.

Cheers,
Alessandro

887

MP Server / Re: Concurrent Users (ARSSOCKD)

« on: February 02, 2011, 12:32:13 AM »

This not really related but this past Friday we needed to perform some maintenance on our CMOD MP server but had to wait until the last user logged off.  We monitored the users by watching the 201 SysLog messages which reports every 30 minutes or so.  My question is how can the 201 ARSSOCKD commnad be manually executed, is there a ARS command to show current logins/license in use?

Thanks guys

Hello,

A little bit late, but better late than never!

If you are in Unix (at least AIX <8.5), then you can do that:

ps -ef |grep arssockd

Code: [Select]

odadmttt  569438 1786062   0   Nov 17      - 24:50 arssockd-ENTARCHI: db (idle)
odadmttt 1032404 1786062   0   Nov 17      - 21:40 arssockd-ENTARCHI: db (idle)
odadmttt 1536108 1786062   0   Nov 17      - 23:05 arssockd-ENTARCHI: db (idle)
[color=red]odadmttt 1614070 1786062   0   Nov 17      -  0:50 arssockd-ENTARCHI: license (Cur(0), Max(3500))[/color]
odadmttt 1769698 1786062   0   Nov 17      - 53:57 arssockd-ENTARCHI: db (idle)
odadmttt 1786062       1   0   Nov 17      - 16:53 arssockd-ENTARCHI: (accepting)
   odadm 5947452 7409676   0   Jan 30      -  3:12 arssockd-ENTARCH: db (idle)
   odadm 6496430 7327786   0 08:27:09  pts/1  0:00 grep arssockd
   odadm 6840324 7409676   0   Jan 30      -  3:16 arssockd-ENTARCH: db (idle)
   odadm 7184516 7409676   0   Jan 30      -  3:12 arssockd-ENTARCH: db (idle)
[color=red]   odadm 7282874 7409676   0   Jan 30      -  0:04 arssockd-ENTARCH: license (Cur(1), Max(3500))[/color]
   odadm 7409676       1   0   Jan 30      -  1:49 arssockd-ENTARCH: (accepting)
   odadm 7483582 7409676   0   Jan 30      -  3:19 arssockd-ENTARCH: db (idle)

As you can see I have 2 Instances of CMOD running in parallel. And the ENTARCH instance has exactly 1 user connected and the ENTARCHI has none.
So I would be able to shut down ENTARCHI without any problems.

This works at my knowledge only in AIX. And from what I've read (not yet tested with 8.5) only with CMOD < 8.5.

Cheers,
Alessandro

888

MP Server / Re: Moving from DB2 to Oracle

« on: February 02, 2011, 12:19:06 AM »

Just FYI...our system has the following versions of software
CMOD - 8.4.1.3
DB2 - 9.5.5
TSM - 5.4.2.0
AIX - 5.3

Hello Sandeep,

since it's a pure database conversion, it doesn't matter if it is AIX, Sun, HP, Windows or Linux (at least all the Multiplatform, for z/OS I don't know, but Oracle is not on z/OS :-P ).

The only think that might matters is really the version of cmod. But mostly when you go from Oracle -> DB2, the reverse is normally """easier""", but now with version 8.4.1+ you don't have the problems of numerical fields.

Cheers,
Alessandro

889

General / Re: CMOD Vs Filenet/Documentum/LiveLink

« on: February 01, 2011, 01:11:39 PM »

Hi,

here you have a good definition of Unstructured Data: http://en.wikipedia.org/wiki/Unstructured_data
and for Structured Date: http://en.wikipedia.org/wiki/Structured_data

And this one is also nice to read: http://www.information-management.com/issues/20040901/1009161-1.html

Cheers,
Alessandro

890

MP Server / Re: Moving from DB2 to Oracle

« on: February 01, 2011, 12:08:41 PM »

Well, I think I will disapoint some people :-)

But as you know, I work for IBM, and we are not really happy to know that you are going away from DB2 to the evilnice Oracle!!!

So I will explain you how to migrate from Oracle to DB2   The reverse is left to the reader as an exercise!!  

DISCLAIMER

THERE IS NO WARRANTY FOR THE EXPLANATION PROVIDED, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING I WILL PROVIDE THE EXPLANATION ?AS IS? WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE EXPLANATION IS WITH YOU. SHOULD THE EXPLANATION PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

I have automated some of what I describe in my post with scripts, but of course I cannot share them with you. I hope you understand.
I can only give you an explanation of what you need to be careful if you try to do the conversion yourself.

Conversion Oracle - DB2

0) BE SURE TO USE THE SAME INSTANCE NAME IN ORACLE AND DB2, otherwise you will loose the link with the local cache and with TSM.
1) Be sure to have a new working db2 installation configured only with the cache.
2) Then stop the DB2 and Oracle CMOD environment (but not the databases!)
3) Copy the content of all the ARS* tables from Oracle -> DB2
Please be careful with the table ARSANN and ARSAGPERMS, you need to find a way to convert the CLOB in VARCHAR some fields.
4) Then recreate all the segment table and repopulate them by reading the definition in the Oracle table syscat.columns and syscat.tables.
Please be careful, because the internal fields from each document index are not exactly the same between the 2 databases, for example in DB2 you have RESOURCE, but in Oracle the field is called RES_ID, and the type of COMP_TYPE and ANNOT are type RAW(1) in Oracle and CHARACTER(1) in DB2
You will see also that fields in Oracle are CHAR(n) and in DB2 they are called CHARACTER(n), or VARCHAR2(n) in Oracle and VARCHAR(n) in DB2.
When converting from Oracle -> DB2 you need to be extra carefull because Oracle has everything as number, and in DB2 they need to be converted correctly in SMALL INT, INTEGER or BIG INT. To help you can check for each field what type they are by looking at the ARSAGFLD in the Oracle Database.
If you are using CMOD <=8.4.0.X, then you need to be extra careful with all the fields of type integer in Oracle, because it might required a type BIG INT in DB2, so you need to check before with all your data, if some values are greater than 2147483647 and change accordingly the field type when you create the segment table AND you need to change the type in the ARSAGFLD, which means also that you need to change also the type of the field mapped in the folder... and if you do that with the folder, it might have a consequence with other Application Group where you will need to change the corresponding field... and guess what, it might have an influence in other folders, and other Application Groups as a side effect!!!
If you are using CMOD 8.4.1.X then you don't have these problems, except if your Oracle CMOD Data model was created before 8.4.1.X, and then you need to be careful on that aspect too!
One way to see what are the fields to be careful would be to export the whole data model from Oracle to DB2, and load one document in each Application Group and compare all the tables.
5) Of course, you need then to recreate all the index that CMOD created for you, so you need to check in the Oracle table sys.user_ind_columns which field is an index, and you need to recreate it back in DB2 with exactly the same name.
6) You might need also to be careful with the tablespace created with each segment table.
7) You might need to change in the folder MAX value and MIN value for the numerical fields, in case you made some modification with numbers in point 4)
8 ) You will need to reset the value of the last expiration date of password, otherwise all your passwords are going to be expired
9) You will need to be careful before starting CMOD with DB2, that you have a correct ars.ini pointing to the correct configuration files, and that the cache are point to the cache used by Oracle (be carefull with the permissions in case you are using different users), that TSM is configured correctly (if you are using TSM). take the oracle configuration as a template for your DB2 new instance.
10) After checking that the content of each tables are ok, that the configuration files are ok, and that all the permissions are ok, you can start CMOD in DB2
11) if CMOD DB2 starts OK, then you can try EVERY functions (log with a user, change password, load a document, retrieve a document, launch arsmaint, delete a document, etc...)
IF CMOD DB2 doesn't start... then, you need to check everystep to see what went wrong.
12) If Step 11 is ok, then you have a newly migrated CMOD in Oracle DB2  

I have found that DB2 Federation Server is just perfect to populate tables with CLOB/BLOBs between Oracle/DB2, and all the conversion of data types.
Maybe Oracle has a similar tool to interface with DB2, but I'm not aware of it.
Before using DB2 Federation Server, I was doing everything by hand... all the conversion of types, etc... and that was really a nightmare.
Now I can use it for Oracle<->DB2 conversion.

My experience tells me, that such migration is not trivial, and should be prepared very carefully, otherwise you will have problems.

Cheers,
Alessandro

891

MP Server / Re: Moving from DB2 to Oracle

« on: February 01, 2011, 11:42:20 AM »

Thanks Alessandro. We are all eagerly waiting for your migration related post. Will the size have such a huge increase on migration to Oracle if we store most of the indexes currently as string on DB2 rather than integer.

If you are storing mainly strings, then no... no differences.

Cheers,
Alessandro

892

MP Server / Re: Moving from DB2 to Oracle

« on: February 01, 2011, 02:37:45 AM »

Hello Sandeep,

the only 2 strong reasons are the following:
- You will need to pay the CMOD license AND Oracle License (because with CMOD, DB2 License is "free" as long as you use it only with CMOD)
- The other reason is the risk involved by such move, and no official support from IBM

Another reason, maybe less important is:
- The size of the library server will be bigger (around 100% bigger in average than the DB2 version if using lots of small int/integer fields)

From my experience, I've seen, that Oracle DBA loves to play with internal from some CMOD... and personally this is the biggest reason, BUT for management maybe this is not a strong reason.


Now, I see that there is some people interested in such migration :-D Hmmmm What should I do? 

So first, there is no official documentation, even unofficial. I have written some scripts to do it automatically, and it depends a lot on the customer data.
Now with the newest version of CMOD, I have no more problems with the conversion between number types (small int, integer, big int), so I might simplify some parts.

Well I will check what I have and explain in high level how it works, in another post.

Just for your information, all the information I'm going to write is without ANY WARRANTY, you are on your own, and IBM is officially not supporting such migration, and I won't be held responsible for any kind of corruption, loss of data, etc... due to the explanation I'm going to write in my next post.

Cheers,
Alessandro

893

MP Server / Re: Moving from DB2 to Oracle

« on: January 31, 2011, 02:43:33 PM »

Hi,

Well, I have done migration from DB2 <-> Oracle
I mean by migration, it was really a database conversion, and not a export/import from the index and data.

So from my experience, I've seen no real performance difference between Oracle and DB2.

And you must be aware that all the numerical fields in Oracle takes 8 bytes (for small Int, Integer, Big Integer, ...) so in the end it take a lot more space than DB2, which reserves exactly the number of bytes that you expect.
So in the last migration I went from a 370 Gig Library Database in Oracle to a "mere" 160 Gig in DB2, no compression involved.

If you are doing the DB2 -> Oracle migration, you need to be carefull, because the name of some fields are not the same (resourceid and res_id), the types are not always the same (Annotation: Oracle use CLOB and DB2 use varchar), etc... so this is not an easy transition, but it is possible, and you need to test it very carefully.
Depending on the CMOD Version you are using you need to be careful of the data type. before 8.4.1 Oracle knew only Integer and small Int... no Big Int was supported. So you might have here some nasty tricks to do if you want to convert to DB2 and have sometimes Integer or Big Integer.

You need to know also that, you are on your own, since it is not officially supported by IBM.
If you are taking the risk, then there will be at IBM some services people (like me) who could help you in the process.



May I know the reasons for considering the migration from DB2 to Oracle?

I'm asking because from my point of view if a product works, don't change it. I was working for a company where I was managing CMOD with DB2, and in 10 years we had no issues, it was working without any problems. And suddently the management said... the Software RoadMap is Oracle, and we need to migrate all product that can be migrated to oracle.
We did the work, but I still find it st*pid, especially for a database where we had 0 problems in 10 years (with updates too) except for filling filesystems... Only because nobody knew how to operate DB2, and they were fearing the day they might need someone, and at the same time, they had lots of Oracle DBA...
Now, these Oracle DBA are ... playing around with the internal of CMOD... which is for me worse than having supposively no one to take care of DB2.

So I am always wanting to know the reasons someone wants to migrate CMOD from DB2 <-> Oracle, especially if there are no issues!

Cheers,
Alessandro

894

General / Re: CMOD Vs Filenet/Documentum/LiveLink

« on: January 31, 2011, 12:38:07 AM »

The answer from Justin ist perfect, couldn't have say it better :-)

All the product you are comparing, you need to think also to another thing.

Structured and Non-Structured Data.

CMOD can do only Structured data, and he's good at it, so good that he's number one.
FileNet, Documentum, LiveLink, SharePoint, .... are more players in the Non-Structured data field.
Of course, FileNet, Documentum, etc can/could do also Structured Data archiving, but they are nowhere as good as CMOD.
Simply put, it's another field, another rules.

Each tools has his good side and bad side.

CMOD is really easy and has excellent performance in its own field, meaning cold archiving.
Yes the others can do that too, but not at the performance level of CMOD.
It follows the philosophy, do one thing, but do it well.

If you take FileNet, it's a neat and nice product, but the installation is a nightmare, the fixes are less than optimal like CMOD.
Well it's a wonderfull product on its field, for all unstructured data, BPM, etc... it's number one, or nearly at the top (I'm not sure at which ranks)
But for doing the work of CMOD, it's overkill.
That's why you have now the integration with CMOD, so you can the best of both world.

At least at IBM, we don't see them as competitors, but as complementary products, which can give to the customer the best option on each field.

You know the whole idea of having one system which is number 1 in everything and with performance... is a dream.

Cheers,
Alessandro

895

Other / Re: arsdoc delete

« on: January 26, 2011, 04:26:14 AM »

Document retrieval was running slow and we have found over 500 documents that have loaded with dates ranging from 01/26/2010 to 10/12/2022 which is affecting the searches.  I have looked into the possibility of using arsdoc delete to remove them, but as you stated this only deletes the Index entries therefore leaving the segment date range still incorrect.  I looked at using unload, but it requires the load ID, and it appears that the load ID is assigned for a whole load and not by individual documents therefore it would unload all of the documents for a load ID.  We load several thousands of documents at one time.

Well there is a workaround, we have thought about it for some customer, but never implemented it yet.
Please be careful if you want to use this idea, and test it, test it, test it, and again test it!!!
And as Justin often says: Backup !!!

So the idea is the following:

Simple version, not so dangerous

- Find the Load ID associated to the document you want to delete
- Look how many documents are in this Load ID
   If only one (this is the document you want to delete) -> unload the LoadID
   If more than one -> arsdoc delete

Now a more dangerous version:

- Find the Load ID associated to the document you want to delete
- Look how many documents are in this Load ID
   If only one (this is the document you want to delete) -> unload the LoadID
   If more than one ->
      - arsdoc delete
      - export all documents from this LoadID (it will export only what is in the Segment) (arsdoc get -cg....)
      - unload the LoadID
      - import the exported data (arsload -X G ....)

And now with this second version you will have the desired behaviour.

But again... if you want to do it. Please test it, test it, test it... and again test it.

I know it's a lot of warning, but if you loose data, then nobody will be happy.

Cheers,
Alessandro

896

MP Server / Re: Convert AFP to PDF on AIX

« on: January 25, 2011, 05:38:10 AM »

Well, we do have AFP2PDF for Windows, but not AIX.  Not sure where to get the AIX version ... I do not see it on Passport Advantage.

Silly question..., but how did you get AFP2PDF? Do you have a license by IBM or a IBM Business Partner?

You should ask the same people who've selled you this license for Windows.
They should be able to give/sell you the AIX version.

From what I've seen in Switzerland, the AFP2PDF (or AFP2WEB) is licensed by CPU, and/or by Server...
You need to check how it is for you.

Best regards,
Alessandro

897

Other / Re: arsdoc delete

« on: January 25, 2011, 05:34:27 AM »

Hi RStockton,

Well I don't know for CMOD 8.5, but "arsdoc delete" deletes only the index in the library server and nothing more.
Meaning it does not remove the Load ID in TSM, it does not adjust Segment date range.

Best regards,
Alessandro

898

z/OS Server / Re: you know a possibility to change the segment field in the application group?

« on: January 21, 2011, 09:22:06 AM »

Hi Egon,

But if you both state that the segment field shall not be touched I think it's just a topic lessns learned.

Sadly... yes it's a lessons learned...

What you could do, is to store all the new documents from this year in a new Application Group, and migrate slowly your old data to the new structure piece by piece.
It will take time, and will be nearly transparent for your users.

Cheers,
Alessandro

899

MP Server / Re: Convert AFP to PDF on AIX

« on: January 21, 2011, 09:18:34 AM »

Hi,

So if you have the AFP2PDF Transform software install on your AIX server, then you can find the software "afp2pdf" and launch it to convert from AFP to PDF:

Code: [Select]

$ ./afp2pdf 
Invalid input file specified

Usage: ./afp2pdf [-a] [-e] [-f] [-g] [-i] [-l] [-m] [-n] [-o] [-p] [-r] [-s] [-t] [-u] [-v] inputfile
   -a <perms>      Encryption permissions pcsa
                   (p=no printing, c=no changes,
                    s=no selecting, a=no adding notations)
   -e <password>   Encryption Owner Password
   -f <file>       Formdef file
   -g <time stamp> Create Time Stamp
   -i <file>       Conversion options file
   -l              Force all messages to file
   -m              Linearize PDF
   -n <path>       Location of font directory
   -o <file>       Output file name
   -p <page>       Transform a single page (number) in the document
   -r <file>       Resource group file
   -s <time stamp> Sign Time Stamp
   -t <turn>       Page orientation ( 0 | 90 | 180 | 270 )
   -u <password>   Encryption User Password
   -v <file>       ImageMap file

Does it help?

Cheers,
Alessandro

900

z/OS Server / Re: you know a possibility to change the segment field in the application group?

« on: January 20, 2011, 11:27:08 AM »

Hi Egon,

Well... the way it is, I would not recommend to change the "Segment Field" directly in the database. The SQL to change would be trivial, but then you have a problem with all the segment already in place and old data, all the parameters in Application Group, Segment, arsload tables... which all are dependend on the field which was selected at the beginning.
And probably you'll have other strange behaviour like in the cache, and maybe lots of other things I don't have yet in mind...

For me the most clean and secure way to really change a "Segment field" would be to export all your data, and reimport to a new Application Group with the correct data model.
That could be a very long effort depending on how much data you have stored already and in which archiving storage the data are stored (like tapes) for this export-import.

Cheers,
Alessandro