TSM strange behaviour after upgrade

[Michel de Kraker]

Hi all,

This weekend i upgraded CMOD 8.4 to 8.5 and TSM version 5.5.7 to version 7.1.1.100

Before the upgrade everytime a document was archived i saw in the TSM activitylog:
ANR0406I Session 3038 started for node ODNODE (DATALOAD) (Tcp/Ip 192.168.1.10(48842).(SESSION:3038951)
DATALOAD is the CMOD user we use for loading documents with arsload.

After the upgrade , i am not seeing the same message in the TSM actlog.

I checked TSM and saw that documents are being archived to ondemand.:

tsm: ARCHIVE>select * from archives where NODE_NAME='ODNODE' and FILESPACE_NAME='/UXB' and LL_NAME='790926JAAA'

     NODE_NAME: ODNODE
FILESPACE_NAME: /UXB
  FILESPACE_ID: 1
          TYPE: FILE
       HL_NAME: /DOC/
       LL_NAME: 790926JAAA
     OBJECT_ID: 42472944
  ARCHIVE_DATE: 2015-09-15 11:18:55.000000
         OWNER:
   DESCRIPTION: IBM OnDemand
    CLASS_NAME: DEFAULT

But the strange thing is that this is not being logged in tsm activity log. Is this maybe an known issue with the TSM API?

Anyone any thoughts on this?

Kind regards,

Michel.

[Alessandro Perucchi]

Hello Michel,

one question that has nothing to do with your original question, why did you upgrade to CMOD 8.5 instead of V9.X?
V8.5 will be out of support in April 2016, meaning you will need to do a second upgrade soon.

Concerning your question and TSM, maybe this has something to do with the TSM logs, where you might need to change something somewhere to see these messages too.
That's just an idea, but I don't know how to do it! :-D

[Michel de Kraker]

Hi Alessandro,

Good question regarding why not go to 9.5. This is a long story , i will not bother you with that :-)
May 2016 we plan to upgrade to 9.5.

I also installed the TSM 7.1.1.4 client filesets. Could this maybe too new for CMOD 8.5 talking to TSM 7.1.1.100?


Michel.

[Justin Derrick]

It sounds like TSM might not be logging this information anymore by default.  I haven't played with TSM 7.1.x very much, but maybe it's like DB2, in that there's a "DIAGLEVEL" parameter (like the one in DB2) that determines exactly how much logging happens.

-JD.

[Michel de Kraker]

extra info.

when say 30 documents are archived to tsm , then the first load action gives ANR0406I message in TSM actlog but the other 29 documents there is no record of in TSM actlog. But documents are still being archived to TSM because i query:

TSM:
select LL_name from archives where archive_date like '2015-09-16%'

the LL_name is both in cache and in tsm.
So this seems ok , but i still find it worrying because i cannot depend anymore on the activity log.

I raised a PMR at IBM , will keep you posted.

[Michel de Kraker]

one more thing.....

There is this userexit. Is this exit the bridge between arssockd and tsm?

/usr/lpp/ars/bin/exits/arssmtsm

Could this be a problem with the arssmtsm user exit?

Thx

Michel.

[Michel de Kraker]

Did another test today.

Every morning around 1000 files are archived to ondemand. Each file is loaded individually towards ondemand with the ARSLOAD command.
What is see is that when the first load starts it gets an session at the TSM server. The other loads with a new arsload process do not get another TSM session but use (as it seems) the same session id as the first load.

Here an example of 2 query sessions executed at the TSM server.
Session id is 6217 and as you can see, Bytes Recv is for the same session id increasing.
Maybe this is new behaviour (more effecient) with TSM 7.1. Is it possible someone can do at test at their own environment and share the outcome?

IBM Tivoli Storage Manager
Command Line Administrative Interface - Version 7, Release 1, Level 1.4
(c) Copyright by IBM Corporation and other(s) 1990, 2015. All Rights Reserved.

Session established with server ARCHIVE: AIX
  Server Version 7, Release 1, Level 1.100
  Server date/time: 09/17/15   06:37:06  Last access: 09/17/15   06:32:09

ANS8000I Server command: 'q ses'.

  Sess     Comm.      Sess         Wait       Bytes       Bytes     Sess        Platform     Client Name
Number     Method     State        Time        Sent       Recvd     Type
------     ------     ------     ------     -------     -------     -------     --------     ------------------
 1,508     Tcp/Ip     Run          0 S        1.3 M         203     Admin       AIX          ADMIN
 2,125     Tcp/Ip     Run          0 S        1.1 M         203     Admin       AIX          ADMIN
 2,145     Tcp/Ip     Run          0 S        1.1 M         203     Admin       AIX          ADMIN
 6,217     Tcp/Ip     IdleW        0 S      209.0 K       9.8 M     Node        ONDEMAND     ODNODE
 6,663     Tcp/Ip     Run          0 S          148         233     Admin       AIX          ADMIN

ANS8002I Highest return code was 0.

IBM Tivoli Storage Manager
Command Line Administrative Interface - Version 7, Release 1, Level 1.4
(c) Copyright by IBM Corporation and other(s) 1990, 2015. All Rights Reserved.

Session established with server ARCHIVE: AIX
  Server Version 7, Release 1, Level 1.100
  Server date/time: 09/17/15   06:37:08  Last access: 09/17/15   06:32:09

ANS8000I Server command: 'q ses'.

  Sess     Comm.      Sess         Wait       Bytes       Bytes     Sess        Platform     Client Name
Number     Method     State        Time        Sent       Recvd     Type
------     ------     ------     ------     -------     -------     -------     --------     ------------------
 1,508     Tcp/Ip     Run          0 S        1.3 M         203     Admin       AIX          ADMIN
 2,125     Tcp/Ip     Run          0 S        1.1 M         203     Admin       AIX          ADMIN
 2,145     Tcp/Ip     Run          0 S        1.1 M         203     Admin       AIX          ADMIN
 6,217     Tcp/Ip     IdleW        0 S      209.5 K       9.9 M     Node        ONDEMAND     ODNODE
 6,664     Tcp/Ip     Run          0 S          148         233     Admin       AIX          ADMIN

ANS8002I Highest return code was 0.

[Alessandro Perucchi]

With CMOD V8.5.0.6, there is a TSM Connection Pooling in place in order to optimize the TSM connections and tries to make everything faster.

There is a way to deactivate this TSM Connection Pooling. But I cannot find the reference anymore.
If someone in the forum finds the reference again, that would be nice! And like that you might try to disable it and check if you see something different.

[Michel de Kraker]

Thx Alessandro,

You mean this one?

http://www.odusergroup.org/forums/index.php?topic=1035.0

REgards,

Michel.

[Alessandro Perucchi]

Yes, but this reference miss the option to deactivate the TSM connection pooling.
There is a option to add in ars.ini or ars.cfg... but I don't remember which one, and what was the name of the option.

If I find it I will post it... or if someone has it... then I hope he will post it too !

[Michel de Kraker]

Ok Alessandro,

but would there be a reason to deactivate TSM pooling? Loading documents is now extremely fast.

Regards

Michel.

[Alessandro Perucchi]

Hello Michel,

I found the option:

ARS_TSM_MAX_SESSION_POOL=0

in ars.cfg.

Why should one have that option activated? Here is the full explanation : http://www-01.ibm.com/support/docview.wss?uid=swg21627793

I have no idea if that would help or not in your case. Maybe it would be good to see if that has any impact in your case.
I suppose not, but who knows!

[Michel de Kraker]

Hi Alessandro

Checked the document. I am not using mutiple storage nodes.
So i leave it this way.

Thx for your reactions on this topic.

Kind regards,

Michel.