Neu importiertes Coding wird nicht genutzt

[Cecile4804]

Hallo zusammen,


ich habe am Montag einem Kunden einen Transportauftrag zugesendet, um einen Laufzeitfehler im bisherigen Coding zu korrigieren. Er hat den TA importiert, der Laufzeitfehler war aber immer noch der Gleiche. Auch das Coding, auf das im Kurzdump verwiesen wurde, war noch das Gleiche. Springt der Kunde im Laufzeitfehler allerdings auf die Source, dann sieht er die neue Source. Ein Generieren hier oder in der SE80 hilft nicht weiter.

Das Verhalten ist im Test- und im Produktivsystem gleich (er hat es einfach mal durchgeschleust, konnte ja nicht schlechter werden ... ).

Warten auf den nächsten Tag (hat auch schon mal geholfen) hat nichts gebracht.

$SYNC im Transaktionscodefeld hat nichts gebracht, sie haben zudem nur einen Applikationsserver.

Am Wochenende waren Support Packages eingespielt worden.

Die Coding-Änderungen fanden in einem Funktionsbaustein statt. Da ich schon mal erlebt hatte, dass SAP bei "Quertransporten" [bei uns auf einem Patch-System erstellt, Kundensystem ist ja nicht in einer Queue mit uns] sich an der internen Nummerierung der Includes für Funktionsbausteine verschluckt hat, habe ich ihm einen Transport mit der ganzen Funktionsgruppe (R3TR FUGR) nachgesendet, damit alles neu generiert wird -- hat auch nichts geholfen.

Eine Suche im Netz, SMP und hier scheitert schon an einer sinnvollen Suchanfragenformulierung; es kommt immer alles mögliche andere hoch.

Ich hab dem Kunden vorgeschlagen, eine Meldung bei SAP aufzumachen; selbst wenn das klappt, wird das aber auch noch dauern.

Daher also meine Frage an Euch, was da noch die Ursache sein könnte.


Schöne Grüße,
Thomas

[Alessio37]

Hallo,

ja, kommt mir bekannt vor, dies hatten wir aber nur ein einziges mal. Aber bei uns hat die Änderung im Testsystem funktioniert, aber in der Produktion nicht!

Nochmal Transportieren war wirkungslos.

Wir haben das Coding im Entwicklungssystem geändert. Irgend was umstellen, was die Funktion unverändert lässt. Dann wurde die Änderung akzeptiert.

Ursache blieb unbekannt.

Grüße
Alex

[Cecile4804]

Hallo Alex,


ich danke Dir, das Phänomen ist also nicht völlig unbekannt.
Ich habe gestern mit dem Kunden unseren Reparaturschlüssel vor Ort eingebaut, die Transportwege angepasst usw. und dann mit ihm eine Kommentarzeile eingefügt. Das haben wir dann auf deren Schiene transportiert. Es hatte auch nicht funtioniert, das Coding kam also an, wurde aber nicht ausgeführt. Gleichzeitig dazu hat es mit deren eigenem Z-Coding funktioniert, wie wir an einem parallelen Fall feststellen konnten.

Pardon, ich hätte das hier gleich posten sollen, aber ich hatte so viel zu tun ...

Ich habe derzeit den Verdacht, dass SAP eine andere Behandlung von namensraumbasiertem Coding mit den "neuesten" Servicepacks (die sie ja am Wochenende eingespielt hatten) eingebaut hat, weswegen unser Coding jetzt anders behandlt wird als das kundeneigene.

Die Meldung an SAP erstellen wir nachher.


Schöne Grüße,
Thomas

[Tron]

Moin,
... Bei einem FUGR Problem, bei dem allein schon der Versuch einen bestimmten Baustein der Gruppe aufzurufen, zu einem Kurzdump führte, hatte uns vor ein paar Jahren Kopfweh bereitet.
Wir haben zwar letztendlich die ganze FUGR transportiert, aber vorher komplett gelöscht.
Genauer gesagt haben wir einen LÖSCHTRANSPORT erzeugt um die ganze FUGR zu löschen.
Danach die Ganze FUGR transportiert. SAP hatte keine Erklärung, da wir die ganze Historie der FUGR nicht nachvollziehen konnten.
Toi-Toi-Toi
lg Jens

[Cecile4804]

Moin Jens,


ich hatte Deine Idee gestern noch erwogen, aber bevor wir noch einen Transport dort hin schicken, warten wir erst mal ab, was SAP sagt; die Meldung ist ja inzwischen eröffnet.

Es passiert halt relativ schnell, dass es später nur noch heißt, "die brauchen für so eine kleine Änderung so viele Transportaufträge", da kann man noch so oft erklären, dass das gar nicht unser Problem ist. Es ist sowieso schon eine Schande, dass der externe Provider deren SAP-Systems nur zuschaut, obwohl er sehr wohl den Kurzdump und das abweichende Coding gesehen hat. Wie genau muss man Dienstleistern eigentlich nachweisen, dass es ihre Aufgabe ist, etwas zu tun?

Aber ich jammere jetzt nicht weiter ...


Schönen Dank,
Thomas

[Cecile4804]

Hallo,


nachdem SAP bis heute nicht auf das Ticket reagiert hat, haben wir doch den Vorschlag mit dem Löschtransport durchgeführt. Zur Sicherheit haben wir den Testfall einmal durchgespielt, immerhin hat das System gemerkt, dass die Funktionsgruppe nicht mehr da ist. Ob ein Neuimport allerdings das Neukompilieren jetzt anstößt, wissen wir nicht, weil der Kunde überraschend früher weg musste, Montag machen wir hier weiter.

Nebenbei -- ich hatte immer die Vorstellung, dass das System so vorgeht:
1. Neuer Sourcecode wird importiert.
2. Import stößt Generierung an (siehe Protokoll, darunter verstehe ich das "Kompilieren"), setzt einen neuen Zeitstempel beim Laufzeitobjekt.
3. Beim ersten Benutzen eines Dictionaryobjekts wird der Zeitstempel des Laufzeitobjekts mit dem Zeitstempel des Dictionaryobjekts verglichen und ggf. neu kompiliert.
4. Danach wird das aktuelle Laufzeitobjekt in den Rolbereich geladen.

Aber irgendwie stimmen hier die Ebenen in meiner Denke nicht, oder zur Sicherheit ist eine Redundanz da ... Nur hat das "Modell" bisher "genügt" und ich hatte mir nicht die Zeit genommen, das genauer zu analysieren. Gibt es eigentlich hierfür irgendwo eine empfehlenswerte Beschreibung?


Schöne Grüße,
Thomas

[Tron]

Moin,
nun prinzipiell ist das wohl so.
Was mir aber noch einfällt: Prüf doch mal, ob alle Sourcen der FUGR auch aktiviert sind, oder noch inaktive Fassungen in der Gruppe existieren (im Zielsystem).
Dazu mal die Tabelle REPOSRC abprüfen (SE16N). Wenn im Feld R3STATE ein I steht und es zu einer Source 2 Einträge existieren, gibt es eine (verbliebene) inaktive Fassung des Programms !
gruß Jens

[Cecile4804]

Hoi,

das ist mal eine interessante Idee, das werde ich mit dem Kunden am Montag machen!

Schönen Gruß,
Thomas

[Cecile4804]

Moin,


aaaaalso:

Löschtransport und Neuimport mit zeitlichem Abstand hatten zwar eine Wirkung, bewirkten aber keine Linderung -- wir haben das Neukompilieren gesehen, nachher kam aber immer noch der Laufzeitfehler mit der alten Source. Es gab also für den Applikationsserver immer noch keinen Grund, seinen Cache zu leeren, auch wenn das Dictionary gemerkt hat, dass es was zu tun gibt.

In der Tabelle REPOSRC gibt es nur einen einzigen Eintrag mit dem Kennzeichen "I", alle anderen haben auch wirklich "A" (Gegencheck).

Ich kann mir im Moment noch vorstellen, dass der Cacheeintrag für diese Funktionsgruppe versehentlich einen Zeitstempel in der Zukunft hat. Daher habe ich dem Kunden vorgeschlagen, zumindest den Applikationsserver des Testsystems mal neu starten zu lassen. Vielleicht können sie das ja.

Dummerweise würde das aber kaum erklären, warum das gleiche Phänomen auch auf dem Produktivsystem auftritt. Wenn ich mir überlege, ob das an unserem Transportauftrag liegt, kann ich mir nicht vorstellen, was an "Zeitinformation" aus dem ersten TA bis in den Cache überleben hätte können und jetzt mit anderen TAs nicht mehr dort hin kommen würde ... (Dabei kann ich mir nicht mal vorstellen, dass es überhaupt eine "Zeitinformation" gibt, die aus dem TA bis in den Cache kommt.)

Ich betone nochmal, dass das Phänomen mit einer parallelen Eigenentwicklung unseres Kunden nicht auftritt, aber eben mit unserer Entwicklung. Und es tritt in Test und Prod gleichermaßen auf (wenn wir auch die Tests und Ideen nicht auf dem Prod durchgeführt haben, wie ich konsequenterweise sagen muss).


Recht ratlos,
Thomas

[Cecile4804]

Moin,


der Kunde hat nun einen Neustart des Testsystems durchführen lassen, hat aber auch nichts gebracht.


Schöne Grüße,
Thomas