This would, in turn, generate a short dump:

My initial thought was that this was a TemSe issue, meaning it was a true BASIS issue.  Upon further examination, I came to the conclusion that it was actually a security/access issue.  The user did not have create rights for TemSe.  Find the Role path Basis: Administration -> TemSe: Actions on TemSe objects -> TemSe: Action ID for Authorization and make sure that the user has the value “CRE” (for create).

It is possible to add transport requests to the buffer, and even import them via the CLI (Command Line Interface).  Keep in mind, whenever working on an instance at the OS level, you should be logged in as [sid]adm.

To add transports to the buffer:
tp addtobuffer [transport number] [SID] Client=[client number] pf=/usr/sap/trans/bin/TP_DOMAIN_[DOMAIN_SID].PFL

If I wanted to add transport number DV1K907046 to the buffer for Q01 client 400 and the transport domain controller was DV1 the string would look like this:
tp addtobuffer DV1K907046 Q01 Client=400 pf=/usr/sap/trans/bin/TP_DOMAIN_DV1.PFL

To import transports via CLI:
tp pf=/usr/sap/trans/bin/TP_DOMAIN_[DOMAIN_SID].PFL import [transport number] [SID] U128 client=400

Since I’ve added DV1K907046 to the buffer, I can now import it with this string:
tp pf=/usr/sap/trans/bin/TP_DOMAIN_DV1.PFL import DV1K907046 Q01 U128 client=400

It is also possible to create shell or batch scripts from these commands to do multiple transports at one time. I’ve found that this is when CLI tp management is most effective.
Using your favorite text editor, simply “stack” the commands ontop of each other:

tp addtobuffer DV1K907046 Q01 Client=400 pf=/usr/sap/trans/bin/TP_DOMAIN_DV1.PFL
tp addtobuffer DV1K907047 Q01 Client=400 pf=/usr/sap/trans/bin/TP_DOMAIN_DV1.PFL
tp addtobuffer DV1K907048 Q01 Client=400 pf=/usr/sap/trans/bin/TP_DOMAIN_DV1.PFL
....

Then save as either a .sh for Unix or .bat for Windows.

The batching approach works for both adding to the buffer and for actual import. It’s best to seperate each task (addtobuffer in one script, import in another).

Q2Q3Y6XJM37U

Office/Excel 2003:

Open Excel

Tools -> macro -> security

Security Level tab:
make sure level is set to “medium”

Trusted Sources tab:
Check the box beside “Trust access to visual basic project.”

Office 2007:

Click the Office button.  Click Excel Options.

Click on Trust Center -> Trust Center Settings

Check the box beside “Trust access to VBA project object model”

Close Excel and try to view your report again.  The workbook should no longer be blank and it should be populated with the correct data.

Scenario:

Our SAP servers are running on HP-UX hosts with Oracle 10g databases. Recently, the client underwent SPS application to production servers. The process called for the stopping of scheduled jobs during update. The jobs were to be restarted as directed by team leads. When a request to restart job was executed, it was unable to be completed because the required job had “disappeared”. The job in this scenario was over 100 steps with different programs and variants being executed. Due to time constraints and the possibility of incorrect data entry, manually recreating the job in SM36 was not an option.

It is possible to extract a job definition directly out of the tables in which it is stored and then reinsert it into another instance (i.e. copy the job definition from your Q box and drop it back in Production). For demonstration purposes we will call our source server Q01 and our destination server P01. The job used in this example will be OUR_LOST_JOB.

NOTE: The steps used in this tip may utilize commands that access and modify data in ways not explicitly endorsed by SAP. Therefore, the use of this tip should be done at your own risk.

1. In Q01 verify that OUR_LOST_JOB is available by looking for it in SM37 or searching table TBTCP via SE16.
2. Log into the Q01 unix host as q01adm ( <sid>adm ).
3. Using your preferred text editor, create a file named ‘sm37exp.r3tr and enter the following statements adjusting entries to match your landscape:Export
client=[source client]
file=’SM37export’
select * from tbtco where JOBNAME=‘OUR_LOST_JOB’
select * from tbtci where JOBNAME=‘OUR_LOST_JOB’
select * from tbtcp where JOBNAME=‘OUR_LOST_JOB’
select * from tbtcs where JOBNAME=‘OUR_LOST_JOB’
select * from btcctl where JOBNAME=‘OUR_LOST_JOB’
select * from btcsev where JOBNAME=‘OUR_LOST_JOB’
select * from btcuev where JOBNAME=‘OUR_LOST_JOB’
select * from btcsed where JOBNAME=‘OUR_LOST_JOB’
select * from btcued where JOBNAME=‘OUR_LOST_JOB’
select * from btcevtjob where JOBNAME=‘OUR_LOST_JOB’
select * from btcdelay where JOBNAME=‘OUR_LOST_JOB’
4. As q01adm, execute the following command:
   R3trans –u 8 –w sm37exp.log sm37exp.r3tr
   This string creates the SM37export file which contains the actual job definitions, as well as sm37exp.log. Review the log to ensure a successful export (warnings are OK).
5. Copy the SM37export file to P01 p01adm home directory (/home/p01adm) and make sure to chmod 777 to grant full permissions.
6. Login to the P01 CI unix host as p01adm
7. Use your favored text editor to create the file ‘sm37imp.r3tr’ with the following contents:
   import
client=[destination client]
file=’SM37export’
buffersync=yes
8. Execute the following command in /home/p01adm:
   R3trans –u 8 –w sm37imp.log sm37imp.r3tr
9. Check the log to see if the import was successful
10. Log into P01 and search for OUR_LOST_JOB via SM37. It should be under status: Finished.
11. To recreate the job in “scheduled” status, execute menu “Job->copy”

The job has now been copied and is in status: “Scheduled”. From here you can either manually release the job or reschedule it for its proper frequency.

Scenario:

Our SAP servers are running on HP-UX hosts with Oracle 10g databases. Recently, the client underwent SPS application to production servers. The process called for the stopping of scheduled jobs during update. The jobs were to be restarted as directed by team leads. When a request to restart job was executed, it was unable to be completed because the required job had “disappeared”. The job in this scenario was over 100 steps with different programs and variants being executed. Due to time constraints and the possibility of incorrect data entry, manually recreating the job in SM36 was not an option.

It is possible to extract a job definition directly out of the tables in which it is stored and then reinsert it into another instance (i.e. copy the job definition from your Q box and drop it back in Production). For demonstration purposes we will call our source server Q01 and our destination server P01. The job used in this example will be OUR_LOST_JOB.

NOTE: The steps used in this tip may utilize commands that access and modify data in ways not explicitly endorsed by SAP. Therefore, the use of this tip should be done at your own risk.

1. In Q01 verify that OUR_LOST_JOB is available by looking for it in SM37 or searching table TBTCP via SE16.
2. Log into the Q01 unix host as q01adm ( <sid>adm ).
3. Using your preferred text editor, create a file named ‘sm37exp.r3tr and enter the following statements adjusting entries to match your landscape:

   Export
client=[source client]
file=’SM37export’
select * from tbtco where JOBNAME=‘OUR_LOST_JOB’
select * from tbtci where JOBNAME=‘OUR_LOST_JOB’
select * from tbtcp where JOBNAME=‘OUR_LOST_JOB’
select * from tbtcs where JOBNAME=‘OUR_LOST_JOB’
select * from btcctl where JOBNAME=‘OUR_LOST_JOB’
select * from btcsev where JOBNAME=‘OUR_LOST_JOB’
select * from btcuev where JOBNAME=‘OUR_LOST_JOB’
select * from btcsed where JOBNAME=‘OUR_LOST_JOB’
select * from btcued where JOBNAME=‘OUR_LOST_JOB’
select * from btcevtjob where JOBNAME=‘OUR_LOST_JOB’
select * from btcdelay where JOBNAME=‘OUR_LOST_JOB’

4. As q01adm, execute the following command:
   R3trans –u 8 –w sm37exp.log sm37exp.r3tr
   This string creates the SM37export file which contains the actual job definitions, as well as sm37exp.log. Review the log to ensure a successful export (warnings are OK).
5. Copy the SM37export file to P01 p01adm home directory (/home/p01adm) and make sure to chmod 777 to grant full permissions.
6. Login to the P01 CI unix host as p01adm
7. Use your favored text editor to create the file ‘sm37imp.r3tr’ with the following contents:
   import
client=[destination client]
file=’SM37export’
buffersync=yes

8. Execute the following command in /home/p01adm:
   R3trans –u 8 –w sm37imp.log sm37imp.r3tr
9. Check the log to see if the import was successful
10. Log into P01 and search for OUR_LOST_JOB via SM37. It should be under status: Finished.
11. To recreate the job in “scheduled” status, execute menu “Job->copy”

The job has now been copied and is in status: “Scheduled”. From here you can either manually release the job or reschedule it for its proper frequency.

GuiXT is a SAPGUI plug-in that is selected during the launch pad install.  If you don’t select it during the initial install, you can run the installer again and select only GuiXT.

If everything is working correctly when you open a GUI session, you will see “Activate GuiXT” under the “Customize Local Layout” menu.

WARNING:
Neither the author of this article nor DataXstream can be held responsible if the reader breaks the registry while making this correction.  Whenever working inside the registry, it is good practice to take a full back-up before continuing.  Also break up any keys before directly editing them.

To open the registry editor click ‘Start’->’Run’ and enter regedit.

The registry editor window appears:

To take a full back-up of the registry, click ‘File’->’Export’ while ‘My Computer’ is highlighted:

Save the file somewhere you won’t forget and with a name you will easily recognize:

With the full backup, we can now feel safe as we make our changes.  Drill down through the tree starting with
HKEY_CURRENT_USER\Software\SAP\SAGUI Front\SAP Frontend \Server\Adminstration.
Look for a key titled DisappearItems.  If it exists, export by following the previous steps with just that key highlighted, then delete the key.

The option ‘Activate GuiXT’ should now be available in the Customize layout menu.

Another issue that I’ve seen with GuiXT in regards to LoadRunner is LR not being able to find the GuiXT Dynamic Link Library (.dll) when excuting a test script.  The fix is easy; Copy ‘guixt.dll’ from the directory path C:\Program Files\SAP\FrontEnd\SAPgui\ to C:\WINDOWS\system32\.

These fixes assume that you have administrative access to your computer.  If you do not, please contact your IT/Help Desk department to either gain admin rights or have a tech follow these steps for you.