Subroutinenpool teilt Speicher mit rufendem Programm?
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
9 Beiträge
•
Seite 1 von 1
9 Beiträge
Seite 1 von 1
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
Hallo zusammen.
Mal eine Frage an die (anderen) Experten:
Kann es sein, dass sich Programme die als "Subroutinenpool" definiert sind, etwas anders verhalten als "Ausführbare Programme"?
Soweit ich bislang immer gedacht habe, betrifft dieses Flag nur, dass man das Programm nicht direkt per Submit aufrufen kann. Jetzt hab ich aber gerade festgestellt, dass scheinbar auch ein Transfer von Speicherinhalten (globale Variablen usw.) zwischen rufenden und gerufenem Programm erfolgt (ähnlich wie zwischen Dynpro und Programm), was nach meinem Verständnis ja nicht sein dürfte, weil es ja zwei getrennte Programme mit eigenen Speicherbereichen sind. Ich finde auch kein anderes Coding, das dafür verantwortlich wäre, dass die (globalen) Variablen im Subroutinenpool einen Wert beinhalten obwohl ich die Form-Routine gerade erst aufgerufen habe.
Ist meine (neue) Annahme korrekt? Wenn ja, kann mir vielleicht jemand hilfreich ans Bein treten, damit ich auch die entsprechende Abap-Hilfe-Seite zu diesem Verhalten finde? Danke.
lg ADT
Mal eine Frage an die (anderen) Experten:
Kann es sein, dass sich Programme die als "Subroutinenpool" definiert sind, etwas anders verhalten als "Ausführbare Programme"?
Soweit ich bislang immer gedacht habe, betrifft dieses Flag nur, dass man das Programm nicht direkt per Submit aufrufen kann. Jetzt hab ich aber gerade festgestellt, dass scheinbar auch ein Transfer von Speicherinhalten (globale Variablen usw.) zwischen rufenden und gerufenem Programm erfolgt (ähnlich wie zwischen Dynpro und Programm), was nach meinem Verständnis ja nicht sein dürfte, weil es ja zwei getrennte Programme mit eigenen Speicherbereichen sind. Ich finde auch kein anderes Coding, das dafür verantwortlich wäre, dass die (globalen) Variablen im Subroutinenpool einen Wert beinhalten obwohl ich die Form-Routine gerade erst aufgerufen habe.
Ist meine (neue) Annahme korrekt? Wenn ja, kann mir vielleicht jemand hilfreich ans Bein treten, damit ich auch die entsprechende Abap-Hilfe-Seite zu diesem Verhalten finde? Danke.
lg ADT
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4093 / 127 /
940
)
»
Moin a-d-t,
habe kurz 2 Testprogramme gebaut. Eins vom Typ "S" und eins vom Typ "1".
Programm "1" ruft eine Routine in Programm "S".
Wenn ich eine globale Variable in "1" habe und nicht in "S" ist sie dort auch nicht bekannt.
Wenn ich eine gleichnamige globale Variabel in "S" habe, sie beim Aufruf der Routine in "1" gefüllt ist, ist sie in "S" nicht gefüllt.
Wenn ich die globale Variable in "S" fülle, ist sie beim Rücksprung nach "1" wieder auf dem vorher in "1" bekannten Wert.
Ich kann deine Aussage also nicht nachvollziehen - es verhält sich alles so, wie von dir anfangs vermutet.
habe kurz 2 Testprogramme gebaut. Eins vom Typ "S" und eins vom Typ "1".
Programm "1" ruft eine Routine in Programm "S".
Wenn ich eine globale Variable in "1" habe und nicht in "S" ist sie dort auch nicht bekannt.
Wenn ich eine gleichnamige globale Variabel in "S" habe, sie beim Aufruf der Routine in "1" gefüllt ist, ist sie in "S" nicht gefüllt.
Wenn ich die globale Variable in "S" fülle, ist sie beim Rücksprung nach "1" wieder auf dem vorher in "1" bekannten Wert.
Ich kann deine Aussage also nicht nachvollziehen - es verhält sich alles so, wie von dir anfangs vermutet.
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
Gut, wenigstens sind wir hier der gleichen Meinung.
Heist aber leider auch, dass ich weitersuchen muss woran es liegt, dass eine Variable einen Wert hat den sie (logisch) nicht haben sollte. 😉
Heist aber leider auch, dass ich weitersuchen muss woran es liegt, dass eine Variable einen Wert hat den sie (logisch) nicht haben sollte. 😉
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von black_adept (Top Expert / 4093 / 127 /
940
)
»
Moin a-d-t,
sorg mittels "layer-aware debugging" dafür, dass du beim 1. Aufruf des Subroutinepools dort landest und dass die Variable da noch initial ist. Dann einen Watchpoint setzen und schauen, wann sie gefüllt wird.
sorg mittels "layer-aware debugging" dafür, dass du beim 1. Aufruf des Subroutinepools dort landest und dass die Variable da noch initial ist. Dann einen Watchpoint setzen und schauen, wann sie gefüllt wird.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 2):
a-dead-trousers • IHe
Danke für den Hinweis mit Layer-Aware Debugging, das SLAD-Cockpit kannte ich tatsächlich noch nicht. Man kommt immer wieder an den Punkt, an dem man weiß, dass man sehr viel nicht weiß...
Folgende Benutzer bedankten sich beim Autor IHe für den Beitrag:
black_adept
Beitrag
von black_adept (Top Expert / 4093 / 127 /
940
)
»
Moin IHe,
mir geht's gerade genau so. Kannte das SLAD-Cockpit noch gar nicht und habe ehrlich gesagt auch keinen Schimmer, was ich da machen muss. Ich meinte die Aktivierung direkt im Debugger.
mir geht's gerade genau so. Kannte das SLAD-Cockpit noch gar nicht und habe ehrlich gesagt auch keinen Schimmer, was ich da machen muss. Ich meinte die Aktivierung direkt im Debugger.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
Zwischenstand für all jene die es interessiert bzw. die noch Input geben könnten:
Es ist DEFINITIV so, dass sich die beteiligten SUBROUTINENPOOL Programme den Speicher in einem bestimmten Programm, das bei uns in einem Job läuft TEILEN. Hab alles per Debugger gecheckt. Vor dem Aufruf, innerhalb und nach Aufruf der Formroutine. Die Variablenwerte bzw. die Änderungen werden werden durchgereicht. Die Schnittstelle der Formroutinen beinhaltet keine der betroffenen Variablen.
In dem konkreten Fall ist der Aufrufsatck Report -> Subroutinenpool -> Subroutinenpool und die beiden Subroutinenpools verwenden dasselbe Inlude mit der Datendeklaration. Daher ja auch meine Vermutung, dass sich Subroutinenpools den Speicher (generell) teilen.
Aber ich kann das Verhalten nur mit diesem einen Programm nachstellen und nicht mit einem (schnell zusammengeschusterten) Testprogramm, auch nicht wenn ich es in einem Job laufen lasse.
Somit muss irgendein anderer, mir unbekannter, Mechanismus dafür sorgen, dass sich die beteiligten Programme den Speicher teilen. Ich hab auch mit dem "layer aware debugging", dirty-assign im Debugger und mit LOAD-OF-PROGRAM getestet und damit sichergestellt, dass der zweite Subroutinenpool tatsächlich erst mit dem PERFORM geladen wird und die Variable vorher noch nicht vorhanden war. Nach dem PERFORM führen Änderungen der mit dirty-assign angesprochenen Variable zu einer Änderung der Variable im aktuellen Programm und umgekehrt.
Es ist DEFINITIV so, dass sich die beteiligten SUBROUTINENPOOL Programme den Speicher in einem bestimmten Programm, das bei uns in einem Job läuft TEILEN. Hab alles per Debugger gecheckt. Vor dem Aufruf, innerhalb und nach Aufruf der Formroutine. Die Variablenwerte bzw. die Änderungen werden werden durchgereicht. Die Schnittstelle der Formroutinen beinhaltet keine der betroffenen Variablen.
In dem konkreten Fall ist der Aufrufsatck Report -> Subroutinenpool -> Subroutinenpool und die beiden Subroutinenpools verwenden dasselbe Inlude mit der Datendeklaration. Daher ja auch meine Vermutung, dass sich Subroutinenpools den Speicher (generell) teilen.
Aber ich kann das Verhalten nur mit diesem einen Programm nachstellen und nicht mit einem (schnell zusammengeschusterten) Testprogramm, auch nicht wenn ich es in einem Job laufen lasse.
Somit muss irgendein anderer, mir unbekannter, Mechanismus dafür sorgen, dass sich die beteiligten Programme den Speicher teilen. Ich hab auch mit dem "layer aware debugging", dirty-assign im Debugger und mit LOAD-OF-PROGRAM getestet und damit sichergestellt, dass der zweite Subroutinenpool tatsächlich erst mit dem PERFORM geladen wird und die Variable vorher noch nicht vorhanden war. Nach dem PERFORM führen Änderungen der mit dirty-assign angesprochenen Variable zu einer Änderung der Variable im aktuellen Programm und umgekehrt.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
Gefunden:
DATA BEGIN OF COMMON PART
Ich glaub ich spinne.
Wie dreckig ist diese Programmiersprache?
DATA BEGIN OF COMMON PART
Ich glaub ich spinne.
Wie dreckig ist diese Programmiersprache?
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag (Insgesamt 2):
Thomas R. • qyurryus
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Noch etwas, das ich nicht kannte - und auch gar nicht kennen will. Wenigstens ist es obsolet, was aber bei der Fehlersuche nicht wirklich hilft.
@Stefan:
Ich hatte mir zum Layer-aware-debugging diesen Blogbeitrag angesehen: Layer-Aware Debugging in NW 7.0 EHP2
Im SLAD-Cockpit kann man im Prinzip alles transportabel mit ein paar Extras vordefinieren, was man im Debugger auch ad hoc konfigurieren kann.
@Stefan:
Ich hatte mir zum Layer-aware-debugging diesen Blogbeitrag angesehen: Layer-Aware Debugging in NW 7.0 EHP2
Im SLAD-Cockpit kann man im Prinzip alles transportabel mit ein paar Extras vordefinieren, was man im Debugger auch ad hoc konfigurieren kann.
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
989
Views
Views
Programm als exe oder ähnliches Speicher?
von drama » 28.01.2016 08:29 • Verfasst in ABAP® für Anfänger
von drama » 28.01.2016 08:29 • Verfasst in ABAP® für Anfänger
6
Antw.
Antw.
2612
Views
Views
3
Antw.
Antw.
4069
Views
Views
Freigegben von nicht benötigtem Speicher
von a-dead-trousers » 20.12.2011 13:14 • Verfasst in ABAP® Core
von a-dead-trousers » 20.12.2011 13:14 • Verfasst in ABAP® Core
9
Antw.
Antw.
3958
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 7 Stunden von ralf.wenzel 104 / 10024
vor 7 Stunden von ralf.wenzel 104 / 10024
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 7 Stunden von ralf.wenzel 104 / 10024
vor 7 Stunden von ralf.wenzel 104 / 10024