We are working with Level 2 Support at TSM for now. DB2 is not using the DSMI_CONFIG file at all even though the setup looks correct(comparing .profile, environment variables, dsm.opt, and dsm,sys files with other successful clients that back up to TSM from DB2). Just ran a trace to confirm that it isn't picking up the dsm.opts' file.
We did find out from Level II, That when we ran the 'db2adutl' utility (which we did see a session connect /end to the TSM Server activity log) uses the operating systems shell and not the API. Thanks for all the input from everyone that replied. Nancy Backhaus Enterprise Systems HealthNow, NY 716-887-7979 zareyna <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> 07/13/2006 09:15 AM Please respond to "ADSM: Dist Stor Manager" To: ADSM-L@VM.MARIST.EDU cc: Subject: Re: SQL2062N An error occurred while accessing media, Reason Code: "137" Hi, I have encountered this error before. What I did was to key in a new password (same password) on the client and server communication in the ISC. (under Security) and the dsmapipw works. Thanks, Regards, Zareyna Salim -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Nancy L Backhaus Sent: Wednesday, July 12, 2006 11:40 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] SQL2062N An error occurred while accessing media, Reason Code: "137" Hi Ig, We tried the following steps this morning... 1> Delete the *.pwd file for the client nodename in the /etc/security/a dsm directory.. 2> Update the password for the client nodename to a different password than the old password. (run this on the tsm server) 3> Re-Run the DSMAPIPW to generate the password on the client side When we run the 'db2adutl' command from the client - we see in the tsm server actlog a db2 session start and stop. But, when we try to run a backup from db2, we don't see any session start....and the db2 client reports the SQL2062N, 137 reason code. Noticed that the DSMAPIPW utility - doesn't appear to update the TSM.PWD on the client side (.profile) Question - Where is the DSMAPIPW password stored? Nancy Backhaus Enterprise Systems HealthNow, NY 716-887-7979 IG Coolen <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> 07/12/2006 04:49 AM Please respond to "ADSM: Dist Stor Manager" To: ADSM-L@VM.MARIST.EDU cc: Subject: Re: oddevaix:/home/archive>db2 backup db archive online use tsm SQL2062N An error occurred while accessing media, Reason Code: "137" Hi Nancy, I was just figuring this out yesterday. Had the same problem, until they changed into reason code 184. But this is what i figured out so far. In order to do online backups, your logging configuration in DB2 should be set to archive logging. But your DB2 admins will probably know about this. Next, make sure you setup all TSM_ (except TSM_PASSWORD) parameters in the DB2 database to default. Although i use PASSWORDACCESS generate, i had to set the nodes password in the database config. DB2>CONNECT TO <YOURDB>; DB2>UPDATE DATABASE CFG USING TSM_PASSWORD <YOURPW> IMMEDIATE; DB2>UPDATE DATABASE CFG USING TSM_NODENAME NULL IMMEDIATE; DB2>UPDATE DATABASE CFG USING TSM_MGMTCLASS NULL IMMEDIATE; DB2>CONNECT RESET; When you set any of the other parameters to anything but NULL, DB2 tries to apply them to the backupjob, which in return will fail. Have you rebooted the DB2 host, or restarted DB2 after setting the DSMI_* vars? Last, i would think that the DB2 user (or the user starting the backup process) cannot read the file you mention (libtsm.a). My reason codes 137 never mentioned a file (It is on Windows though). Have you checked the permissions on that file in relation to the active user? Good Luck. Gr. Ilja -----Oorspronkelijk bericht----- Van: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Namens Nancy L Backhaus Verzonden: dinsdag 11 juli 2006 20:14 Aan: ADSM-L@VM.MARIST.EDU Onderwerp: oddevaix:/home/archive>db2 backup db archive online use tsm SQL2062N An error occurred while accessing media, Reason Code: "137" TSM Server 5.3.2.2 TSM DB2 Client 5.3.0.0 DB2 8.2.0 Trying to help our DB2 Admins get a backup. I know very little about DB2, so any help is appreciated. What we have tried/verified: We can run db2adutl from the client - it was successful I see in the 'Backing Up DB2 Using TSM' book, under troubleshooting suggested for "137' error, is the incorrect password We compared the .profile with another successful db2 client - that looks correct, DSM_DIR DSMI_LOG, DSMI_DIR, and DSMI_CONFIG too. Passwordgenerate set in the options file Updated the node nodename password on the TSM Server, then regenerated the password file with db2 command dsmapipw again. ERROR: DB2Node :/home/archive>db2 backup db archive online use tsm SQL2062N An error occurred while accessing media "/home/archive/sqllib/adsm/libtsm.a". Reason code: "137". Nancy Backhaus Enterprise Systems HealthNow, NY 716-887-7979 CONFIDENTIALITY NOTICE: This email message and any attachments are for the sole use of the intended recipient(s) and may contain proprietary, confidential, trade secret or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited and may be a violation of law. If you are not the intended recipient or a person responsible for delivering this message to an intended recipient, please contact the sender by reply email and destroy all copies of the original message. =====DISCLAIMER============================================================= ==== De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen. The information contained in this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail; please delete in this case the e-mail and do not disclose its contents to any person. We don't accept liability for any errors, omissions, delays of receipt or viruses in the contents of this message which arise as a result of e-mail transmission. De Stichting Pensioenfonds ABP is gevestigd te Heerlen en ingeschreven bij de Kamer van Koophandel Zuid Limburg onder nummer 41074000 -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.10/387 - Release Date: 7/12/2006