Добрый день!

Видимо это маловероятно, но все же вдруг существует "хитрый" способ через assign получить доступ из ФМ к локальным данным в функции, вызвавшей эту функцию?

А искать не пробовали??? Очень помогает знаете ли...

А еще неплохо внимательно читать вопросы, чтобы не отвечать "а бы как".

На форуме неоднократно обсуждался вопрос доступа к глобальным переменным и с этим проблем не возникает. Но ключевое слово вопроса - локальная переменная.
Думаю, не стоит объяснять разницу между локальной и глобальной переменной. Для хранения глобальных переменных SAP использует shared область данных + для возможности динамического assign специально хранит символьные имена всех глобальных переменных с адресами их размещения в памяти. Локальные же переменные размещаются на стеке и обращение к ним идет по смещению от начала стека. При завершении работы подпрограммы или FM оператор return устаналивает указатель стека в состояние, предшествующее вызову FM, и тем самым доступ к локальной переменной теряется и при следующих вызовах ее значение затирается.
Собственно вопрос заключался в нахождении смещения локальной переменной на стеке в вызывающей функции и получения к ней доступа.

Это, возможно, было-бы применимо при описании механизмов работы С или Pascal. В АВАР, как мне думается, механизм слегка другой. Ведь, например, информация о дампе содержит стек вызова и содержимое локальных переменных различного уровня, и по именам.
Но как-то это неправильно - лазить в локальные переменные - может лучше честно отмодифицировать стандарт?

Понимаю, что неправильно, но потребность возникла в customer function в MIGO и таблица, определенная в глобал, в момент вызова этого exit, еще не заполнена нужными данными.

PS: Пример про дамп, возможно не совсем показателен, поскольку нет информации, как он формируется. Может используется исходник, всегда присутствующий в системе или промежуточный интерпретируемый byte-code. Но имена символьные имена локальных переменных конечно программе известны, ведь динамический assign работает с локальными переменными внутри FM.

Думется что в абапе локальные переменные хранятся также как и глобальные просто к ним доступ закрыт (для размышлений есть команда STATICS, рекомендую посмотреть оператор LOAD (DATA и SYMB)).

провёл небольшой эксперимент

DATA ptr POINTER.
FIELD-SYMBOLS <fs>.

PERFORM test.

IF <fs> IS ASSIGNED.
WRITE <fs>. " Сюда не попадает
ELSE.
WRITE: 'Not Assigned'. ", <fs> - Падает в дамп
SYSTEM-CALL POINTER <fs> FROM ptr.
WRITE <fs>. " НЕ падает в дамп - выводится "Y"
ENDIF.

FORM test.
DATA: x TYPE c.
x = 'Y'.
ASSIGN x TO <fs>.
SYSTEM-CALL POINTER <fs> TO ptr.
ENDFORM.

Вот собственно и ответ на ваш вопрос - через POINTER можно добраться до локальных переменных (вопрос только стоит ли так делать)

ptr - 16 байтная переменная которую можно впринципе заполнить самому и сделать. SYSTEM-CALL POINTER <fs> FROM ptr.

похоже в абапе ptr не адрес (как в C) это некоторая структура
в начале offi ofsg из load 'DATA' в конце тип, длина.. точно не помню

У меня падает, не смотря на то, что в дебаггере <fs> имеет значение 'Y'.

Вы создали переменную и получили ее адрес присоединив ее к FS в рамках своей проги.
Не понял как таким образом получить адрес локальной переменной в вызывающей программе. И даже например адрес одноименной переменной в вызывающей вызывающую программу. Вам известно только имя переменной.

В отладчике например , если на закладке вызовы встать на вызывающую прогу - все локальные переменные (вызывающей проги) видны.
Тут нужно искать какой-то класс который использует отладчик. И юзать его.

Господа, Вы подождите проверять. Похоже код не совсем корректен с точки зрения вложений.
Получается, что подпрограмма отработала, и после ее выхода идет обращение к ее внутренней переменной. В этом случае локальная переменная может быть затерта, а может быть и нет - дело случая. Но такое обращение некорректно. Наверно из-за этого и падения.

Может алгоритм, предложенный уважаемым DKiyanov и отработает, еще не проверил.

Я же спрашивал про другой уровень вложений, когда из FM1 вызывается FM2 и из него получить доступ к локальной переменной в FM1. В этом случае 100% локальная переменная в FM1 не затерта.

Именно про такой случай я и писал.

Понимаешь ли в чем причина, это обсуждалось уже не раз, и общий вывод такой, доступ к глобальным переменным чужого пула программ уже есть не хорошо, а доступ к локальным данным вообще-то из разряда а мы сейчас это дело хакнем по быстренькому, а дальше хоть трава не расти... поэтому я к таким методам отношусь, как там у Высоцкого, "ну очень отрицательно" и 100% есть другие методы чтобы не заниматься такими вещами и не делать геммороя другим кто придется после вас на поддержку этой системы.

Думаю что это не в нашей компетеции. Разработчик должен уметь предложить заказчику все варианты решения задачи. Выбирать должен заказчик. К тому же если работа с указателями относится к стандартным, документируемым возможностям SAP, то слово хакнем вообще не уместно.

Вопрос вообщем то даже не в том, хорошо или плохо, а в том - возможно ли. Я же не говорю, что пойду по этому пути, смогу принять правильное решение для будущих поколений

Перерыв помимо этого еще 2 зарубежных форума, нигде не нашел, чтобы где-то было описан способ доступа к локальной переменной.
Поэтому видимо обсуждения сводились к тому, что это плохо, а на поверку оказывается что это даже и не возможно.

Рекомендуется ознакомиться с комментариями по поводу SYSTEM-CALL. Слово "хакнем" в данном контексте более чем уместно.

Пардон, а что мешает добавить параметр для передачи этой переменной в FM2 ?