Probleme mit dem TMS

Direkt zum Seiteninhalt

Probleme mit dem TMS

Veröffentlicht von SAP Corner in SAP Basis · 1 Juni 2022
Tags: TMS
Im Laufe der Jahre bin ich immer mal über Probleme mit dem Transportsystem gestoßen. Hier sind meine gesammelten Notizen dazu, die ebenfalls über etliche Jahre hinweg zusammengestellt wurden. Daher treten ggf. einige Probleme nicht mehr auf, und ggf. gibt es für einige Probleme auch inzwischen andere Lösungen.
Wie auch immer, wenn Sie auf eines der hier genannten Probleme stoßen sollten oder eine bestimmte Fragestellung zum TMS haben, können Ihnen die Information hoffentlich nützlich sein. Los geht's...
Konflikt CTC=1 / clientALL
Der Support Package Manager stellt Transporte mit clientALL in die Importqueue. Diese können bei gesetzter CTC-Option (mandantenspezifische Importqueue) manuell nicht wieder aus der Importqueue gelöscht werden.
Lösung: über RSBDCOS0 tp-Aufruf mit temporärer Überlagerung des CTC-Paramters ("-D CTC=0"):
tp delfrombuffer SAPKIPZE43 <SID pf=<Domänenprofildatei> "-D CTC=0"
TMS bleibt stehen
Wenn das TMS "stehenbleibt" (z.B. beim Lesen der Importqueue, beim Weiterleiten eines Auftrages, beim Löschen eines TA aus der Importqueue oder beim Prüfen kritischer Transportobjekte): TP-Systemprotokoll einsehen. Dort sind vermutlich solche Meldungen vorhanden:
WARNING: \\....\<SID>.LOB is already in use (118), I'm waiting 5 sec (20200823110008).
(z.B. beim Weiterleiten eines Auftrages)
oder
WARNING: /usr/sap/trans.<SID>/tmp/<TA-Nr.>.<SID> is already in use (8), I'm waiting 5 sec ....
(beim Prüfen kritischer Transportobjekte)
Entweder ist die Datei eine Leiche aus einem vorangegangenen abgebrochenen tp-Prozess oder es laufen mehrere konkurrierende Prozesse gleichzeitig. Die Prozess-ID steht in der Datei. Wenn der Prozess noch läuft, sollte im Transportmonitor und im Transportverzeichnis (\tmp\) geprüft werden, ob der Prozess tatsächlich noch etwas tut. Wenn sich weder im Transportmonitor noch im tmp-Verzeichnis etwas tut, kann der Prozess abgebrochen werden, anschließend kann die Datei gelöscht werden. Siehe auch SAP-Hinweis 12746.
TA lässt sich nicht importieren: RC 242, "Because of serialization..."
Bei einem Abbruch des vorigen Transportes bleibt ggf. eine Semaphoren-Datei liegen. Die ist zu finden im Verzeichnis <DIR_TRANS>/serial mit dem Name <SID>SEMA.GLB. In dieser Datei ist die Prozess-ID des tp-Prozesses enthalten, die die Semaphoren-Datei erzeugt hat. Sollte der Prozess nicht mehr laufen, kann die Semaphoren-Datei gelöscht werden.
Überprüfung, ob der Prozess noch läuft:
Unix: auf BS-Ebene mit "ps -ef |grep <PID>"
NT / Win2K: da weiß ich nichts besseres als ST06 -> "Erste 40 CPU-Prozesse"
Sollte der Prozess noch laufen (neuerer Zeitstempel in der Semaphoren-Datei? Bewegung im tmp-Verzeichnis?), aber anscheinend nichts mehr tun, muss er beendet werden, anschließend kann die Semaphoren-Datei gelöscht werden.
Transport hängt ewig / bricht ab mit RC 12 im Schritt "Move Nametabs"
Sollte der Schritt "Move Nametabs" ewig laufen, sollte zunächst geprüft werden, ob der Job tatsächlich noch läuft (Job RDDMNTAB -> in SM37 den Status prüfen). Ggf. ist der Prozess inzwischen gestorben.  
Zunächst gilt es, den verursachenden Transport herauszufinden. Nachdem das Serialisierungs-Problem (voriges Problem) behoben ist, müssen die Transportaufträge in kleinen Portionen eingespielt werden. Bei einem TA tritt das Problem dann ggf. wieder auf. Ggf. tauchen im SysLog ORA-0060-Meldungen auf (Deadlock auf Tabelle D010...).
Die Ursache liegt vermutlich darin, dass der Transport eine Struktur oder Tabelle ändert, die an zahlreichen bzw. zentralen Stellen verwendet wird. Welche Strukturen / Tabellen das sind, kann evtl. über Einsicht in die Datei "P<JJMMDD>.<SID>" im \tmp-Verzeichnis in DIR_TRANS ermittelt werden. Der Import führt dazu, dass zum einen der Transportprozess, aber auch etliche Anwender, die ein abhängiges Objekt gerade in der Anwendung verwenden, eine Neugenerierung / Aktivierung veranlassen. Hier ist die Gefahr eines Deadlocks entsprechend gross. Abhilfe kann schaffen, die Strukturen / Tabellen des Transportauftrages in der SE11 manuell zu aktivieren. Auch hier können jedoch Deadlocks auftreten -> neu versuchen.
Import bricht ab mit RC=234 ("uncaught internal error")
OSS-Hinweise 526600 und 0400042 treffen nicht zu.
Im TP-Syslog taucht folgende Meldung auf:
HALT 20031125140801
ERROR: uncaught internal error in database interface
ERROR: EXIT(16) -> process ID is: 242654
Ursache: ein zu importierender Transportauftrag ist in der Importqueue doppelt vorhanden. Das kann durch irrtümliche Ablehnung im QA-Arbeitsvorrat und anschließender Weiterleitung ans Zielsystem passieren.
Lösung: doppelte Einträge in Importqueue entfernen.
Meldung "transport order ... exists already with different contents."
Meldung "ERROR <Transportauftrag> <SID> I 0016 20200209210918 ..." im TP-SysLog bzw. im Transportprotokoll durch Meldung
transport order ... exists already with different contents.                          
===> HALT: If you are sure that this is ok, use umode 1 to overwrite it. Please contact the SAP support.
Ursache: vermutlich wurden bereits früher Transporte gleichen Namens, aber mit anderen Inhalten in das System importiert.
Lösung: tja, was Besseres weiß ich nicht:
Entweder den Ratschlag mit umode 1 befolgen (also Import auf BS-Ebene mit tp import) oder aber die E07*-Tabellen um den / die angemeckerten TA(s) bereinigen (löschen). Die Tabellen sind diese:
E070, E070A, E070C, E070CREATE, E070DEP, E070L, E070M, E070P, E070TC, E071, E071C, E071E, E071K, E071KF, E071KFINI, E071L, E07T.
Die Tabellen sind nicht direkt verwaltbar, aber mit Tools wie "Shortcut for SAP systems" ist es möglich.
Im TMS fehlt der Import-Button
Vermutlich existieren Transportaufträge ohne Zielmandant in der Importqueue. Diese markieren und einen Zielmandanten zuweisen.
Importmonitor voller Leichen
Kann beim Abbruch von tp entstehen. Wenn man riesige Mengen von Transporten gestartet hat, findet sich im Importmonitor für jeden TA ein Eintrag, die nur mühsam auf manuellem Wege gelöscht werden können.
Lösung: die zugrundeliegende Tabelle ist "TPSTAT". Über SE14 kann man die Tabelleninhalte löschen  (Datenbanktabelle löschen, Datenbanktabelle anlegen). Die SE14 ist immer etwas heikel. Mit "Shortcut for SAP systems" ist es ebenfalls, und auch mit etwas mehr Kontrolle und Flexibilität möglich.
Bei TMS-Konfiguration falsche Domäne angeben, System wartet jetzt irrtümlicherweise auf Aufnahme in Domäne
TMS-Konfiguration kann jetzt im Dialog nicht mehr gelöscht werden. Ehe man jetzt lange wartet, dass derjenige, der die fälschlicherweise angegebene TMS-Domäne verwaltet, einen wieder rausschmeißt: Eintrag in Tabelle TMSMCONF löschen (mit "Shortcut for SAP systems" leicht möglich). Dann kann man das TMS wieder neu konfigurieren.
Transportaufträge verbleiben mit Status "Import läuft" (LKW-Symbol) oder mit Status "Import eingeplant" (Uhr-Symbol), obwohl kein Transport läuft. Erneutes Importieren ist nicht möglich (Fehlermeldung "Transport läuft bereits", CREATE_ENQUEUE_FAILED).
Dieser Fehler kann auftreten, wenn a) ein schwerwiegender Fehler beim Import aufgetreten ist oder b) Transporte per Batch eingeplant wurden, der Job ("TMS...") aber nicht oder nicht fehlerfrei gelaufen ist.
In der Tabelle TMSTLOCKP und/oder TMSTLOCKR wurden a) vom Import-Prozess oder b) zum Zeitpunkt der Einplanung des Batch-Jobs Sperreinträge für die eingeplanten Transportaufträge eingestellt, die nur durch den Import der jeweiligen Transportaufträge aus der Tabelle wieder entfernt werden.
Lösung: mit "Shortcut for SAP systems" die Tabelleninhalte löschen.
Transportschritte laufen nicht an / laufen endlos. Im TP-Syslog stehen Fehlermeldungen mit "Background jobs cannot be started.".
ERROR: System <SID>. Warning.        20011030140113 :
ERROR:       The following call returned with exit code 4:
ERROR:        sapevt.exe SAP_TRIGGER_RDDIMPDP -t name=<SID>
ERROR:       Background jobs cannot be started.
ERROR:       Please check trace file dev_evt.
ERROR:       (This warning is harmless if no further warnings follow.
Wahrscheinlich trifft hier SAP-Hinweis 449270 zu. Eine schnelle Umgehung des Problems wäre die Durchführung der Transporte (bzw. das Einspielen der Support Packages bzw. PlugIn's) auf dem Server, der die Batch-Prozesse zur Verfügung stellt (also gezielt auf dem Server anmelden).  
Im QA-Arbeitsvorrat fehlen die Schaltflächen für Genehmigen und Ablehnen
In dem Fall gibt es Transportwege mit unterschiedlichen Mandanten. Wenn man einen Filter auf den zu bearbeitenden Mandanten setzt, stehen die Schaltflächen für Genehmigen und Ablehnen wieder zur Verfügung. Wenn man mal richtig die Augen aufmacht, sieht man auch einen entsprechenden Hinweis in der Fußzeile (hatte aber diverse Male anscheinend die Augen nicht richtig offen... ).
Abbruch (Returncode 12) im Schritt "Tabellenumsetzung"
Ursache ist eine Änderung in einer Tabelle, bei der die Daten nicht umgesetzt werden konnten.
Die betroffene Tabelle bekommt man über das Einsehen der Transportprotokolle heraus. Dort sieht man dann z.B. so etwas:
  Auftrag: Umsetzen Table ZSD_IQ_WVE (DDIC/14.01.19/13:48)
  Programm wurde abgebrochen (Job: RDDGEN0L, Nr.: 13480201)     
Im Datenbank-Utility (SE14) für die Tabelle sieht man dann die abgebrochene Umsetzung ebenfalls. Dort kann man dann eine Fortsetzung der Umsetzung versuchen und bekommt auch etwas mehr Informationen. Ggf. hilft auch ein Blick in die für die Umsetzung angelegte Kopie (Tabellenname mit Prefix "QCM8"). Nachdem die Umsetzung erfolgreich war, muss der Transportauftrag nochmal eingespielt werden (wobei vorher wahrscheinlich noch das Problem "TA lässt sich nicht importieren: RC 242, 'Because of serialization...'" auftritt, -> siehe weiter oben). Durch die vorweggenommene Umsetzung muss (für die Tabelle) dann nicht nochmal eine Umsetzung erfolgen.
Das Löschen abgelehnter Transporte aus der Importqueue funktioniert nicht
Das geht nicht über die normale Löschfunktion sondern nur über "Zusätze" -> "Importierte Aufträge löschen". Da werden dann aber auch alle importierten Aufträge gelöscht (auch die mit Status "steht nochmal zum Import an").
Weiterleiten eines Auftrages funktioniert nicht
Verschiedene Fälle, treten auf bei Systemen mit unterschiedlichen Transportgruppen / Verzeichnissen / Betriebssystemen:
1.: Meldung "Transportqueue muss abgeglichen werden"
Ursache ist wohl ein Schiefstand in der Importqueue bzw. in der internen Abbildung der Importqueue in den einzelnen Systemen.
Vorgehensweise zur Behebung:
    1. TMS-Konfiguration auf Domäne neu verteilen und aktivieren
    2. Transportwege-Konfiguration auf Domäne neu verteilen und aktivieren
    3. Auf allen beteiligten Systemen: "Zusätze" -> "Alle Importqueues aktualisieren"
2.: Transport erscheint in Ziel-Importqueue, aber data- und cofile werden nicht übertragen
Für die Feststellung, ob Dateien übertragen werden müssen, wird anscheinend nicht die Existenz im Filesystem sondern ein Flag in der Importqueue des Zielsystems geprüft. Auch hier ist ein Schiefstand der Importqueue die Ursache. In dem Fall müssen data- und cofile manuell ins Zielverzeichnis kopiert werden.
3.: Beim Import in ein vorgelagertes System werden keine / nicht alle Transportaufträge in die Importqueue des Folgesystems gestellt.
Das vorgelagerte System hat eine andere Version der Importqueue des Folgesystems als das Folgesystem. Das lässt sich auch daran feststellen, dass die Dateien in den buffer-Verzeichnissen unterschiedlich sind (unterschiedliche Länge).
Behebung: Dateien auf dem vorgelagerten System phyikalisch aus dem buffer-Verzeichnis löschen, anschließend "Zusätze" -> "Alle Importqueues aktualisieren".
tp-Befehle (addtobuffer etc.) scheitern mit Fehlermeldung "invalid syntax for tp-call"
Das kann auch daran liegen, dass entweder der einzufügende TA in der Importqueue schon vorhanden ist oder aber der nach "after" bzw. "before" angegebene TA in der Importqueue nicht vorhanden ist.
-> ein Blick ins TP Systemlog ist hilfreich. Dort taucht dann ggf. so etwas auf:
ERROR: Inserting an already existing buffer entry is not supported!
oder
ERROR: Corresponding entry (<Transportauftrag>,<Mandant>) not found.  
tp-Befehle (addtobuffer etc.) scheitern mit Fehlermeldung "missing param"
Ein tp-Befehl scheitert mit dieser Fehlermeldung:
TOOLS: Highest return code of single steps was: 0
ERRORS: Highest tp internal error was: 0208       
tp finished with return code: 208                 
meaning:                                          
 error in TPPARAM (param missing, unknown,...)   
Leider schweigt sich die Fehlermeldung über den fehlenden Parameter aus. Wenn das Anhängen von Transporten / Weiterleiten über das STMS funktioniert, sollte man einen Blick in die Datei <TRANSDIR>\log\ULOG* werfen, dort werden die tp-Befehle protokolliert. Ggf. werden dort weitere Parameter mitgegeben. Wenn man das beim tp-Befehl genauso macht, klappt es. In diesem Beispiel hier wird explizit der Parameter transdir noch mitgegeben.
tp addtobuffer <Transportauftrag> <SID> client=<Mandant> pf=\\...\sapmnt\trans\bin\TP_DOMAIN_<TMS-Domäne>.PFL -dtransdir=<Transportverzeichnis gemäß DIR_TRANS>
Import bricht ab beim Schritt "Import anwendungsdefinierter Objekte"
Im Importprotokoll wird ein Abbruch von Programm RDDDIC1L ausgewiesen, und im Jobprotokoll, auf das verwiesen wird, steht folgendes:
Job wurde gestartet
Step 001 gestartet (Programm RDDDIC1L, Variante , Benutzername DDIC)
Programm RDDDIC1L läuft im Mandanten <Mandant>
Keine Berechtigung zum Lesen der Datei /usr/sap/trans..../data/<Datafile>
Job wurde abgebrochen
-> das heißt, im Mandanten fehlt dem DDIC-User die Berechtigung für S_DATASET. Tja, der DDIC sollte und muss halt SAP_ALL haben, und all die Bemühungen der Sicherheitsfanatiker, SAP_ALL auf Teufel komm raus zu eliminieren, scheitern spätestens beim DDIC.
Import hängt beim Schritt "Import anwendungsdefinierter Objekte"
Im TP-Syslog steht ständig folgendes:
ERROR: System <SID>. Warning.        20180213194537 :                                          
ERROR:       Background job not running properly. Function: D  Jobcount: 19383701  Status: P.
ERROR:       Please check the system. Use transactions SM21, SM37, SM50.                     
ERROR:       (This warning is harmless if no further warnings follow.)
Der Job RDDDIC1L (zuständig für den Import anwendungsdefinierter Objekte) läuft überhaupt nicht los. Ein erneutes Einplanen der TMS-Jobs mit RDDNEWPP bringt eine Fehlermeldung, und im Syslog taucht dann der entscheidende Tip auf:
EF2 BP_STEPLIST_EDITOR: ungueltige Stepwerte ( Step 1 ) entdeckt. Grund:
EFV > Benutzer DDIC ist auf Grund seines Typs nicht einplanbar          
EFN BP_JOB_EDITOR: Job RDDIMPDP_CLIENT_011 ist ungültig. Grund:         
EFT > Step 1 enthält ungültige Werte
Der Benutzertyp des DDIC war auf "Kommunikation". Die Änderung auf "System" hat Abhilfe geschaffen. Eigenartigerweise ist der DDIC in allen anderen Systemen / Mandanten ebenfalls vom Typ Kommunikation, ohne dass Probleme auftraten.
Dieser Fehler tauchte bei einem System mit neuerem Support Package Stand (51) als den anderen auf, ggf. gibt es durch das Support Package das Problem.
Import von Transporten läuft nicht, TMS-Monitor zeigt dauernd "Initialization complete, start working now"
Das TMS-Systemlog bringt keinerlei neue Einträge, auch nicht von den letzten Importversuchen.
-> In AL11 mal nachsehen, ob im log- oder im tmp-Verzeichnis eine Datei "SLOG<MMDD>.<SID>.LOC" mit älterem Zeitstempel liegengeblieben ist. Das scheint eine Sperrdatei für das TMS-Systemlog zu sein. -> Löschen
Import-All bricht ab mit Fehlermeldung "Internal error getting container, RC= 4"
Das einmalige Aufsetzen eines Import-All-Jobs mit anschließender Änderung auf einen periodischen Job über die SM37 funktioniert so nicht. Die Periodizität muss direkt bei der Einplanung im STMS gesetzt werden. Siehe auch SAP-Hinweis 398589.
Importierte Workbench-Objekte sind trotz erfolgreichem Import nicht in den Entwicklungsklassen sichtbar
Jobs EU_PUT und EU_REORG nochmal laufen lassen bzw. die entsprechenden Programme nochmal starten. Die laufen i.d.R. 1x täglich. Ein Lauf nach dem Import sollte den Effekt bereinigen.
Weitere Ansätze zur Fehlerhebung:
Importqueue:
  • Importqueue prüfen
  • Transport-Tool prüfen
  • TMS-Konfiguration:
  • Transportgruppen prüfen

Weiterhin gibt es etliche Log-Dateien, in denen ggf. auch noch nähere Infos zu Fehlern enthalten sind.
  • TP-Systemlog (<Transportverzeichnis>\log\SLOG*)
  • TP-Alerts
  • <Transportverzeichnis>\log\ALOG*
  • <Transportverzeichnis>\log\ULOG*
  • <DIR_HOME-Verzeichnis>\dev_tp (Einsehen sinnvoll z.B. bei Meldungen wie "ERROR: see tp's stdout (Standard Out may not be available)")

Es gibt auch noch den SAP-Hinweis 13807, der generelle Informationen zur Analyse von Problemen des TMS beinhaltet.
Tabellen im TMS-Umfeld:
  • TRJOB Jobkennung für Koordination Batch-ABAP/UNIX für Transporte
  • TBATG Steuertabelle für Tabellenumsetzung in Batch
  • TRBAT Kommunikationstabelle für Transportsteuerung
  • TMSBUFREQ TMS Manager: Transportaufträge in Transportpuffer
  • TMSTLOCKR TMS TP: Sperrtabelle für Einzelimporte -> LKW-Symbol in Importqueue
  • TMSTLOCKP TMS TP: Sperrtabelle für Projektimporte -> LKW-Symbol in Importqueue
  • sowie weitere TMS*-Tabellen
Löschen von ggf. hängengebliebenen Einträgen in Tabelle TBATG:
Auf keinen Fall in SE14 über "Datenbanktabelle löschen" und "Datenbanktabelle anlegen"! In der SE14 wird die TBATG gelesen (egal welche Tabelle man damit bearbeiten will). Ist die Tabelle gelöscht, bricht die SE14 mit Kurzdump ab, und das war's dann mit der TBATG - keine neue Anlage der Tabelle mehr möglich, weil die SE14 immer abbricht.
-> Stattdessen Löschen von Sätzen der TBATG über den Menüpunkt "DB-Aufträge" -> "Per Import erstellte". Oder "Shortcut for SAP systems" verwenden.
Umsetzung von Pool-Tabellen in Transparente Tabellen:
In den technischen Eigenschaften (SE13) gibt es dafür das Flag "Transform to transparent table“. Setzt man das und sichert/aktiviert die Tabelle, wird nach einem Transportauftrag verlangt, in den der Objektkatalogeintrag LIMU TABT (Tabellenname) reingeschrieben wird.
Das reicht aber nicht aus, damit die Tabelle in nachgelagerten Systemen dann nach dem Import auch umgesetzt wird! Dafür muss die Tabellendefinition (R3TR TABL (Tabellenname)) in den Transportauftrag eingehängt werden.
Periodischer Import All in einen Mandanten
Sollte nicht ins Quellsystem der Transporte durchgeführt werden (die Idee existiert immer wieder mal für eine Belieferung eines Sandbox-Mandanten auf dem Entwicklungssystem). Begründung: Workbench-Objekte, die sich derzeit wieder in Arbeit befinden, werden durch Import freigegebener TA's mit älterem Stand überschrieben. Und irgendwelche anderen Effekte gibt's dann auch noch.
Einplanung: über "Import All" Button in der Importqueue. Funktioniert nur, wenn TMS-Parameter NO_IMPORT_ALL != 1 für das System definiert ist. Ggf. umschalten, verteilen, Job einplanen, wieder zurückschalten. Über SM36, Report TMS_BCI_START_SERVICE geht's nicht, weil der Import-All bestimmte Einträge in TMS-Steuertabellen voraussetzt (TMSBCIJOY).
Oder aber (z.B. wenn die TMS-Konfiguration nicht in eigener Hand liegt): der STMS-Transaktion einen nicht gesetzten TMS-Parameter NO_IMPORT_ALL vorgaukeln. Dazu in STMS vor dem Aufruf der Importqueue (oder vor dem Auffrischen der Importqueue) das Debugging einschalten, dann im Debug-Mode einen Breakpoint bei Unterprogramm STATUS_IMPORT_QUEUE in Programm SAPLTMSU_IQ setzen. Dort dann Einzelausführung bis zur Abfrage von Feld gs_impbuf-no_imp_all, den Feldinhalt dann löschen. Dann erscheint der "Import All" Button und kann verwendet werden.
Übrigens kann man einen Import-All auch auf einen Mandanten und/oder ein CTS-Projekt einschränken: in der Importqueue einen entsprechenden Filter für die Anzeige setzen und dann den Import-All einplanen.
Die Periodizität muss übrigens direkt hier gesetzt werden. Eine einmalige Einplanung eines Import-All mit anschließender Änderung auf einen periodischen Job über die SM37 führt zum Abbruch mit Joblog-Meldung "Internal error getting container, RC= 4". Siehe dazu SAP-Hinweis 398589.
Periodischer Import All bei vorgeschaltetem QA-System
Das funktioniert nicht ohne eine spezielle Konfiguration mit einem virtuellen System (Import_all scheitert, weil Transporte in der Importqueue noch nicht genehmigt sind). Lösung: siehe SAP-Hinweis 313991.
Löschung von TA's eines oder mehrerer Projekte aus der Importqueue
geht mit Programm RSTMS_DEL_PROJECT_FROM_QUEUE (sollte auch im Batch funktionieren).
Weiterleitung von genehmigten TA's
Programm RSTMS_DIST_APPROVED_REQUESTS
Wer hat einen bestimmten Transportauftrag importiert?
Das (u.a.) steht in der Tabelle TPLOG, Einsicht über SE16. Selektion: SYDATE von / bis, CLIENT = Importmandant, CMDSTRING = "IMPORT*<TA-Nummer>*"
Oder: mit AL11 in DIR_TRANS/log/ALOGjjkw.SID nachsehen.
Oder: in der Importhistorie "Bearbeiten" -> "Mehr anzeigen" wählen.
Welcher Transportauftrag hat Tabelleneinträge geändert / gelöscht?
Transaktion SE03, "Objekte in Aufträgen/Aufgaben suchen". Dann mehrere Möglichkeiten abklappern:
R3TR TDAT (Tabellenname) Customizing: Tabelleninhalte
R3TR TABU (Tabellenname) Tabelleninhalt
R3TR VDAT (Viewname) Viewpflege: Daten
Bei der Suche nach Daten aus Viewpflege müssen die Views nacheinander abgeklappert werden, in denen die Tabelle verwendet wird (Verwendungsnachweis in SE11 -> Verwendung in Views).
Erklärung der tp-Fehlercodes
Aufruf von tp mit EXPLAINRC <RC> pf=<TMS-Parameter-Datei>, also z.B. so für Erklärung tp-Fehler 152:
/...sapmnt/exe/tp explainrc 152 pf=/...trans/bin/TP_DOMAIN_<SID>.PFL
Statusanzeige Transportsystem
Transaktion SE07
(Automatische) Übertragung der Transportdateien zwischen Transportgruppen (Queue-Abgleich)
mit Report RSTMSTIQ. Nur nötig, wenn das vorgeschaltete System einer anderen Transportgruppe zugeordnet ist.
Parameter: Transportgruppe des in der TMS-Konfiguration vorgelagerten Systems eintragen und alle Markierungen setzen.
Variante SAP_LOC_GROUPS tut's i.d.R. aber auch.
Änderung eines bereits freigegebenen Transportauftrages
mit Report RDDIT076
Massenfunktion für Rollentransport:
(Aufnahme von Rollen in Transportaufträgen)
Programm PFCG_MASS_TRANSPORT
Weitere ggf. nützliche Programme:
(im Einzelfall zu prüfen, etliche Programme werden im STMS-Umfeld über die entsprechenden Funktionen aufgerufen)

  • /SDF/CMO_TR_CHECK   Prognose von transportbezogenen Fehlern, bevor die Aufträge in ein Zielsystem importiert werden. -> siehe SAP-Hinweis 2475591 - Report für Transportprüfung.
  • RDDKOR60  Anzeige von After-Import-Methoden (entweder für einen einzelnen Auftrag oder für alle Objekte). Die Methoden sind auch in Tabelle OBJM ersichtlich, oder in Transaktion SOBJ > BC-Set-Kompatibilität.
  • RSTMS_ACTIVATE_ALL_REQUESTS TMS: inaktive Aufträge einer Importqueue aktivieren
  • RSTMS_CHANGE_DOMAIN_NAME TMS: Name der Transportdomäne ändern
  • RSTMS_DEL_PROJECT_FROM_QUEUE TMS: Alle Aufträge zu einem Projekt aus Importqueue löschen
  • RSTMS_DISPLAY_CTS_ALERTS TMS: CTS-Alerts anzeigen
  • RSTMS_DIST_APPROVED_REQUESTS TMS: Genehmigte Aufträge Weiterleiten
  • RSTMS_IMPORT_MONITOR TMS: Importübersicht anzeigen
  • RSTMS_IMPORT_OVERVIEW TMS: Importübersicht anzeigen
  • RSTMS_IMPORT_QUEUE TMS: Importqueue anzeigen
  • RSTMS_IMPORT_TRACKING TMS: Importübersicht anzeigen
  • RSTMS_ORGANIZER_WEBUI TMS: Start Transport Organizer Web UI
  • RSTMS_QUALITY_ASSURANCE TMS: QA Arbeitsvorrat anzeigen
  • RSTMS_SYSTEM_OVERVIEW TMS: Systemübersicht anzeigen
  • RSTMS_TRANSPORT_PATH TMS: Importübersicht anzeigen
  • RSTMS_UPLOAD_TP_PROFILE TMS: tp-Profil lesen und Konfiguration am Controller anpassen
  • RSTMS_WORKFLOW_INBOX TMS: Importqueue anzeigen
  • RSTMSAMO TMS: Alert Monitor
  • RSTMSCBU TMS: Importqueue prüfen
  • RSTMSCDI TMS: Transportverzeichnis prüfen
  • RSTMSCOL TMS: Importqueues in lokale Puffer lesen
  • RSTMSCON TMS: RFC-Verbindungen monitoren
  • RSTMSDIC TMS: Konfiguration anzeigen
  • RSTMSIMP TMS: Aufträge der Importqueue importieren
  • RSTMSQADEL TMS: Korrekturprogramm für QA-Vorrat (siehe SAP-Hinweis 716009 - TMS-QA: Löschen von Aufträgen aus dem QA-Arbeitsvorrat)
  • RSTMSTIQ TMS: Importqueue aus fremder Gruppe übertragen
  • RSTMSTOC TMS: Transport-Objektlisten prüfen
  • RSTMSTPL TMS: tp-Systemlog anzeigen
  • RSTMSTPP TMS: tp-Parameter anzeigen
  • RSTMSTPT TMS: tp-Schnittstelle prüfen
  • RSWBO_ADJUST_REQUEST_TARGETS Korrigiert Auftragsziele nach Umbau der Systemlandschaft
  • RSWBO_AUX_PROJECT Arbeiten mit CTS-Projekten ohne IMG
  • RSWBO_CHECK_TLOCK Konsistenzprüfung der Sperrtabelle
  • RSWBO_CURRENT_PROJECT Arbeiten mit CTS-Projekten ohne IMG
  • RSWBO_DELETE_SAPNAMES oder RSWBOSOS SAPNAMES-Datei eines Benutzers löschen
  • RSWBO_OBJCAT Objektkatalogeinträge ändern
  • RSWBO004 Systemänderbarkeit setzen
  • RSWBO005 Globales Customizing Transport Organizer
  • RSWBO0052 Globales Customizing Transport Organizer
  • RSWBO006 Auftragsattribute anzeigen/ändern
  • RSWBO010 Selektion von Objekten
  • RSWBO011 Freigabe im Hintergrund (wahlweise mit Objektprüfungen)
  • RSWBO019 Modification Browser
  • RSWBO020 Reparierte Objekte anzeigen
  • RSWBO040 Objekte in Aufträgen/Aufgaben suchen
  • RSWBO050 Objekte in Aufträgen/Aufgaben analysieren
  • RSWBO051 Objektkatalogeinträge von Objekten eines Auftrags ändern
  • RSWBO052 Objektkatalogeinträge ändern
  • RSWBO053 Objektkatalogeinträge von Objekten eines Auftrags anzeigen
  • RSWBO054 Umzugstransport rückgängig machen
  • RSWBO055 Pakete anzeigen/ändern
  • RSWBO060 Objekte in einen Transportauftrag aufnehmen
  • RSWBO070 Objektlisten vereinigen
  • RSWBO071 Aufträge mergen (für Hintergrundverarbeitung)
  • RSWBO072 Objektlisten vereinigen (Darstellung als Liste)
  • RSWBO080 Aufruf der erweiterten Tabellenpflege für Namensraumtabellen
  • RSWBO081 Namensräume anzeigen/ändern
  • RSWBO084 Anpassung der Namensraumrollen für SAP-interne Systeme
  • RSWBO085 Namensraum: Direkte Aktivierung (Übernahme in Laufzeittabelle)
  • RSWBO088 Selektion von unbestätigten Reparaturen (zu freigegebenen Aufträgen)
  • RSWBO095 Protokolle CTO anzeigen
  • RSWBO099 Objekte entsperren (Expertentool)
  • RSWBO111 Aufruf der erweiterten Tabellenpflege für Namenskonventionen (V_TR
  • RSWBO112 Namenskonventionen anzeigen/ändern
  • RSWBO113 Namensraum-Infosystem
  • RSWBO113_DATA Namensraum-Info-System, Include globale Daten
  • RSWBO113_LISTE Namensraum-Infosystem, Include Objektliste
  • RSWBO113_NAME Namensraum-Infosystem, Include Objektnamen
  • RSWBO113_NCONV Namensraum-Infosystem, Include Namenskonventionen
  • RSWBO113_NSPACE Namensraum-Infosystem, Include Namensräume
  • RSWBO114 Aufruf der Viewpflege für Namenskonventionen (CTRESNAME)
  • RSWBO230 Löschen von Upgrade Commandfiles (Release 3.0 und höher)
  • RSWBO301 Nummernvergabe bei Aufträgen: Freies Intervall suchen
  • RSWBODBC Installationsnachbereitung Datenbankkopie
  • RSWBODVC Pakete suchen
  • RSWBOINS SE06 für Installation im Batch
  • RSWBOINST_CLEAN Initialization of CTS
  • RSWBOSDR Aufträge suchen
  • RSWBOSOS Hotline Tools (Auftragskopf bearbeiten, Objekte entsperren, ADO-Import ausführen, SAPNAMES-Datei eines Benutzers löschen, Noteditor, Namensräume anzeigen/ändern (erweitert))
  • RSWBOUP1 Eigene Upgrade-Phase für WBO-Anpassungen
QA-Arbeitsvorrat
steht in den Tabellen TMSQWLF, TMSQNOTES, TMSQWL, TMSQLASTWL
Wird der QA-Vorrat aus einem Nicht-QA-System heraus aufgefrischt, erscheinen inzwischen (im QA-System) gelöschte Transporte erneut. Dafür gibt es ein Korrekturprogramm (siehe SAP-Hinweis 716009 - TMS-QA: Löschen von Aufträgen aus dem QA-Arbeitsvorrat).
Bei einem System-Refresh sollten solche Tabellen aber ohnehin vorher gesichert und nachher wieder eingespielt werden - entweder per PCA-Tool oder mit "Shortcut for SAP systems".
Auftragsattribute verwalten (Definition, als obligatorisch bestimmen etc.)
Programm RSWBO006





Es gibt noch keine Rezension.
0
0
0
0
0
Zurück zum Seiteninhalt