Thursday, March 20, 2008

TP.exe (or STMS) Hangs While Importing or Adding Transports to the Buffer...

There are many reasons why TP.exe (the underlying executable that STMS calls on the OS) may hang while trying to make changes to one of the system transport buffers. The reason we came across yesterday was this: there was something corrupt inside the usr/sap/trans/tmp directory. Now, the tmp directory contains a lot of really important stuff for TP.exe, and then again it also can contain a lot of unnecessary junk. I DO NOT recommend deleting this directory. In fact, the best way to fix this is to simply rename that directory and create a new, empty tmp directory, then attempt to manipulate the buffer again with the TP.exe commands or transaction STMS. The tools will work fine with an empty tmp directory, but if you are interested in finding out what file caused this problem you can always copy the files from the original directory one-by-one and run test commands each time to single out which file is the culprit. But I don't have time for any of that. I just left the old tmp directory (now name tmp_old) in place and went about my busy little life.

Hope this helps...

DTS Packages in SQL2005...

Have DTS packages in SQL2000 and now your are upgrading to SQL2005?
I know, I know... the "correct" answer (according to Microsoft) is to migrate all DTS packages into SQL Server Integration Services packages, but... The migration tool is less than stellar, and the Microsoft Visual Studio tool is much more complex and complicated than the simple flowchart-style DTS package editor window. Unless you have a developer on hand to dedicate to the manual migration and translation of DTS packages into SSIS packages, perhaps you may want to take another route.
First, you will want to install the Microsoft SQL Server 2000 DTS Designer Component for SQL Server 2005, which can be found here: DOWNLOAD.
Next, export your DTS packages. This will create neat, simple files on the OS that you can cut and paste wherever you like.
Then, in the Microsoft SQL Server Management Studio go to the server you want to put the package on, navigate to Management -> Legacy -> Data Transformation Services, right click in the results window and select Import Package File (which you just exported in the previous step).
Finally, right click on the imported package and choose the "open" option to edit the package in the oh-so-familiar DTS Editor window.

Now you have your DTS packages on your SQL Server 2005 instance, and a warm fuzzy for knowing you haven't lost the years of blood, sweat and tears that went into creating them.

Now, if you would like to schedule these packages to run as a SQL Job, it is pretty simple.
Just create a SQL Job that calls an external command, and have it execute DTSRun.exe. If you go to a command prompt and type in DTSRun.exe -help it will give you a list of the parameters you can feed it, like what server to run it on, what user context to use and which package to execute.

Hope this helps...

Thursday, March 13, 2008

Cannot Send Transports Due to "TP Import is Running" Error...

We used to see this problem fairly frequently when we were using the command line to send all transports, but when SAP unveiled STMS this problem all but disappeared. That is until we saw it again this week. We had a scheduled transport job that started about 1 minute before we had to take down a system for emergency hardware maintenance. When we brought it back up, lo and behold the little truck was still showing on the front of our system transport queue and we could not send any new transports to that system. "TP Import is Running"

So I had to dig into the old file cabinet to find the cure.

Inside the DB there is a table called TPSTAT. This table contains information about import requests in the system. If any row has a value of 'R' in the STATUS field, TP is rendered inoperable. Change the value to 'F' or delete the row altogether in SM30 or through a SQL query at the Database level and you will be ready to go.

Upgrade to ECC 6.0 Fails at step PARCONV_UPG

If you are upgrading from 4.6c to ECC 6.0 AND are moving to BASIS SP12, you will have problems in the PARCONV_UPG phase of the upgrade. SAP recommends that you not upgrade to BASIS SP12, but rather go to that SP level either before or after the upgrade. If you are in the middle of the upgrade, then you must implement the corrections referenced in the following two notes: 1069463 and 1042435. In 1069463 you simply run a script that creates some database objects that the upgrade phase needs in order to complete, and note 1042435 is a set of changes that R3Trans.exe makes using a data file that you download.

Good Luck!

Wednesday, March 12, 2008

Change the Transport Number Range

When upgrading an SAP Environment, it is most commonly done over an extended period of time. During the process of dual maintenance it can be difficult to keep up with transport numbers for both the original system and the upgraded system. To help take the edge off a little, there is a way to tell the upgraded system to start from a higher number so that the upgrade transports are more easily identified.
You need to update the entry for TRKORR in table E070L to the next number that you want a new transport to have.
If your old DEV environment is assigning numbers in the DEVK930000 range, perhaps change the new environment to start at DEVK940000. This way you know that all transports in the DEVK940000 range are for the upgraded system.

Tuesday, March 11, 2008

I/O Device Error Using SQL Backup

Friends and Neighbors,
We recently implemented new HP Ultrium 448 stand-alone tape drives for use in our backup solution for SQLServer 2000 on Windows 2000 Advanced Server. The Ultrium 448 is slated to soon replace the Ultrium 460 (which we had deployed in our environment) so we thought we would be pro-active and deploy the new drives before the old drives reached end of life. Immediately upon installation we started getting the following errors while trying to access these drives using SQLServer:

  • “BackupMedium::ReportIoError: write failure on backup device '\\.\Tape0'. Operating system error 1117(The request could not be performed because of an I/O device error.).”

    “Executed as user: SAPDOM\SQLServer. Write on 'Tape1' failed, status = 1117. See the SQL Server error log for more details. [SQLSTATE 42000] (Error 3202) BACKUP DATABASE is terminating abnormally. [SQLSTATE 42000] (Error 3013). The step failed.”

The same drives, however, were operating just fine using Symantec BackupExec software.

To make a long story short, it turns out that the Ultrium 448 drives will run using any drivers provided by HP for the Ultrium2 family, but in order for SQLServer to recognize them they must be running with the HP Ultrium 2 drivers dated 03/02/2007 or later, and the driver installation must be followed by a system reboot (whether it prompts you to or not.)

The moral of the story: When replacing a tape device, test all products that will be accessing that device before deploying it, and figure in some downtime for reboots.

I hope this saves some of you headaches in the future.

Monday, March 10, 2008

Dual Maintenance for Upgrades

When performing and upgrade, it usually takes several months from the time the upgrade begins in the development system until the time the upgrade completes in the production system. During that time, it is often necessary to make changes in order to conduct day-to-day business, so freezing the transport system throughout the upgrade process is not practical. In order to facilitate change management during the upgrade, a process of dual maintenance must be introduced.

  1. Upgrading the Development System:
    a. Rename the 4.6c DEV system (from SAPDEV to DEVOLD) and build the ECC 6.0 DEV system on new hardware.
    b. The 4.6c DEV system will still be used to changes and transports within the 4.6c environment.
    c. Any changes made to the 4.6c DEV system will also need to be made to the ECC 6.0 DEV system, so that functionality used by the business is not lost after the upgrade. Since transports cannot be sent between a 4.6c system and an ECC 6.0 system, the changes must be manually applied to the upgrade system and saved in the transport queue for the ECC 6.0 environment until the upgraded TST system is built.
  2. Upgrading the Test System:
    a. Rename the 4.6c TST system (from SAPTST to TSTOLD) and build the ECC 6.0 TST system on new hardware.
    b. All transports created in the ECC 6.0 DEV system will need to be sent to the ECC 6.0 TST system.
  3. Upgrading the Production System:
    a. Rename the 4.6c PRD system (from SAPPRD to PRDOLD) and build the ECC 6.0 PRD system on new hardware.
    b. All transports created in the ECC 6.0 DEV and sent to the ECC 6.0 TST system will need to also be sent to the ECC 6.0 PRD system.

After the ECC 6.0 PRD System is in place and in productive use the hardware used for the 4.6c DEV and TST systems can be decommissioned and put to use elsewhere in the business. The 4.6c PRD system will need to be kept available offline for 30 days before being decommissioned.

Thursday, March 6, 2008

SAP Logical Spool Servers

A somewhat new functionality that is available for SAP printing is the concept of the Logical Spool Server. It goes a little like this: if one of your main spool server kicks the bucket, it is a very painful process to move all of the print devices to a different server in order to facilitate printing until that spool server becomes available again. The Logical Spool Server is a logical destination inside SAP that devices can be directed to which in turn directs spool requests to actual Spool Servers, including a primary and alternative server. If the primary spool server crashes, the spooling will be switched over to the alternative server. If the alternative server is also down, pushing the spooling duties onto yet another server is handled by simply modifying the Logical Spool Server rather than modifying each individual printing device. Also, the Logical Spool Server can be configured for load balancing so that print jobs are handled by either the primary or alternative server depending on the workload of either.
  • To set up a Logical Spool Server, run transaction SPAD.
  • Under the Devices/Servers tab, select the Spool Servers button.
  • Go into Change mode by selecting the "pencil" icon from the toolbar.
  • Choose the Spool Server -> Create option, name the server and select the Logical Server box and the Load Balancing box.
  • Enter your preferred mapping server and alternate server and you're done.
  • Now all you have to do is assign your print devices to this Logical Spool Server.
  • Give yourself a pat on the back.