TSM 6.2 GUID Error

So when I and a co-worker were finishing up a TSM 6.2 install we ran into a problem running the tsmapipw command to set the $$_TSMDBMGR_$$ password. After investigating the error and search the web we realized the GUID was the problem and not our IP as was suggested in the following APAR.  The errors we received were:

ANR2987W Session ended because of machine GUID or local host IP
 address mismatch.
ANR0430W Session XXXX for node $$_TSMDBMGR_$$ (AIX) refused
 - node name is locked.

We tried various things and nothing seemed to correct the GUID issue. The TSM server started without any GUID related error (in fact it stated the GUID initialized successfully). So upon further searching we found this APAR that gives the solution.  What they state is that by adding the following line to the dsmserv.opt and restarting the server fixes the problem.

DBMTRUSTEDGUIDIGNORE YES

Once we added the line and restarted the TSM server the tsmapipw command ran successfully.

TSM 6.2 GUID Error

So when I and a co-worker were finishing up a TSM 6.2 install we ran into a problem running the tsmapipw command to set the $$_TSMDBMGR_$$ password. After investigating the error and search the web we realized the GUID was the problem and not our IP as was suggested in the following APAR.  The errors we received were:

ANR2987W Session ended because of machine GUID or local host IP
 address mismatch.
ANR0430W Session XXXX for node $$_TSMDBMGR_$$ (AIX) refused
 - node name is locked.

We tried various things and nothing seemed to correct the GUID issue. The TSM server started without any GUID related error (in fact it stated the GUID initialized successfully). So upon further searching we found this APAR that gives the solution.  What they state is that by adding the following line to the dsmserv.opt and restarting the server fixes the problem.

DBMTRUSTEDGUIDIGNORE YES

Once we added the line and restarted the TSM server the tsmapipw command ran successfully.

Send CSV File As Attachment

Have a report that is too big to be column output and don't like the list look of TSM 6.1? Sure you could reformat you comma delimited file for output but I'd rather send it as an attachment in their mail and let them open it in Excel. So if you have access to a Linux/UNIX server this is a simple solution I used recently and it worked great.

uuencode /tmp/tsm/stg_backup_rpt.csv /tmp/tsm/stg_backup_rpt.csv | mailx -s "TSM Servers Backup STGPool Status" "test1@mymail.com,test2@mymail.com"


There are other ways with other mail handlers (i.e. mail, mailx, sendmail, etc.) but this one was easy and worked.

Send CSV File As Attachment

Have a report that is too big to be column output and don't like the list look of TSM 6.1? Sure you could reformat you comma delimited file for output but I'd rather send it as an attachment in their mail and let them open it in Excel. So if you have access to a Linux/UNIX server this is a simple solution I used recently and it worked great.

uuencode /tmp/tsm/stg_backup_rpt.csv /tmp/tsm/stg_backup_rpt.csv | mailx -s "TSM Servers Backup STGPool Status" "test1@mymail.com,test2@mymail.com"


There are other ways with other mail handlers (i.e. mail, mailx, sendmail, etc.) but this one was easy and worked.

Select X Days Back

As you all know I have been writing and rewriting scripts for my 6.x servers and have been experiencing interesting results when I use the timestampdiff option when determining how far back a script should look. So when running my summary report query I was getting inaccurate results when using the following script:

example 1:
select schedule_name, entity, start_time, end_time, timestampdiff(16, char(end_time-start_time)) || ' ' || timestampdiff(8, char(end_time-start_time)) || ':' || timestampdiff(8, char(end_time-start_time)) || ':' || substr(cast((end_time-start_time) as char(22)),13,2) AS ELAPSED_TIME, affected from summary where activity='STGPOOL BACKUP' and timestampdiff(8, char(current_timestamp-start_time))<=24


This script would not return all the STGPOOL BACKUP jobs from the summary table. Not sure why, but I have a couple ideas. So, I found that the following is easier to use and returned the correct results.


example 2:
select schedule_name, entity, start_time, end_time, timestampdiff(16, char(end_time-start_time)) || ' ' || timestampdiff(8, char(end_time-start_time)) || ':' || timestampdiff(8, char(end_time-start_time)) || ':' || substr(cast((end_time-start_time) as char(22)),13,2) AS ELAPSED_TIME, affected from summary where activity='STGPOOL BACKUP' and start_time>(CURRENT TIMESTAMP - 10 DAYS)


So whenever you would like to query X days back I suggest example 2 for ease of use.

Select X Days Back

As you all know I have been writing and rewriting scripts for my 6.x servers and have been experiencing interesting results when I use the timestampdiff option when determining how far back a script should look. So when running my summary report query I was getting inaccurate results when using the following script:

example 1:
select schedule_name, entity, start_time, end_time, timestampdiff(16, char(end_time-start_time)) || ' ' || timestampdiff(8, char(end_time-start_time)) || ':' || timestampdiff(8, char(end_time-start_time)) || ':' || substr(cast((end_time-start_time) as char(22)),13,2) AS ELAPSED_TIME, affected from summary where activity='STGPOOL BACKUP' and timestampdiff(8, char(current_timestamp-start_time))<=24


This script would not return all the STGPOOL BACKUP jobs from the summary table. Not sure why, but I have a couple ideas. So, I found that the following is easier to use and returned the correct results.


example 2:
select schedule_name, entity, start_time, end_time, timestampdiff(16, char(end_time-start_time)) || ' ' || timestampdiff(8, char(end_time-start_time)) || ':' || timestampdiff(8, char(end_time-start_time)) || ':' || substr(cast((end_time-start_time) as char(22)),13,2) AS ELAPSED_TIME, affected from summary where activity='STGPOOL BACKUP' and start_time>(CURRENT TIMESTAMP - 10 DAYS)


So whenever you would like to query X days back I suggest example 2 for ease of use.

TSM 6.x Time Calculation

I use the summary table frequently and like to calculate the elapsed time by subtracting the END_TIME from the START_TIME. In TSM 5.x you could easily do this because the TSM DB was setup for returning a day/time when calculating those two fields, but TSM 6.x's DB2 database does not work the same way. When calculating the difference in 6.x the result looks like this:


      ENTITY: STG_V0653 -> STG_T10K_C2
  START_TIME: 2010-12-28 08:00:11.000000
    END_TIME: 2010-12-28 22:39:29.000000
ELAPSED_TIME: 143918.000000
    AFFECTED: 258
GB BACKED UP: 8814.00

You'll notice that the value given is actually in HHMMSS without the colon seperators. So my select formats the output to a more time based solution. You might ask why I didn't use timestampdiff, but the problem with the timstampdiff format is that it does not return in a time format like previous (5.x) versions. The timestampdiff would return the format calculation of either days, hours, minutes, or seconds only. So I actually worked with a friend who has a little more experience with DB2 and we came up with the following.


select schedule_name, entity, start_time, end_time, substr(cast((end_time-start_time) as char(22)),7,2) || ' ' || substr(cast((end_time-start_time) as char(22)),9,2) || ':' || substr(cast((end_time-start_time) as char(22)),11,2) || ':' || substr(cast((end_time-start_time) as char(22)),13,2) AS ELAPSED_TIME, affected from summary where activity='STGPOOL BACKUP' and timestampdiff(8, char(current_timestamp-start_time))<=24

Results:

SCHEDULE_NAME: AS_BACK_V655

ENTITY: STG_655 -> STG_10_C2

START_TIME: 2010-12-28 08:00:26.000000

END_TIME: 2010-12-29 07:40:46.000000

ELAPSED_TIME: 00 23:40:20

AFFECTED: 632

So now it shows the elapsed time as Days, Hours:Minutes:Seconds

You could eliminate the Day by removing the first calculation, but I have some storage pool backup processes that can run VERY long so I included it.