Wo steht das, dass es kein Problem ist ? Als ich die ersten Anypointer-Funktionen geschrieben hab, dachte ich, es könnte zu einem Stop führen, da es keinen DB 0 gibt.
Nötig ist das Überspringen aber sowieso nicht, da ich sie nur in DB-Bereichen einsetze.
Der Befehl "AUF" tut nichts weiter als das DB-Register zu laden, es erfolgt kein Zugriff. Man schreibt also nur Null in das DB-Register.
Zum Stopp, den du beobachtet hast, kommt es erst wenn du einen Zugriff mit dem DB-Register versuchst, also beim "U DBX"
Ganz verstehe ich den Code auch nicht.
Wenn du das AUF überspringst liest dir dein "U DBX" normalerweise aus dem DB der vor dem FC-Aufruf zuletzt geöffnet war.
Bei einem FB wäre das Verhalten dann noch mal anders, bin mir jetzt aber nicht sicher wie dort das DB-Register nach dem Aufruf steht.
Warum? Ein Zugriff über AR1 ist doch kein DB-Zugriff.
Da hängt ganz davon ab was in dem Pointer bzw. dann im AR1 als Bereichskennung drinsteht.
Würde da ein W#16#84 drinstehen würde das AUF den L D[AR1]-Zugriff tatsächlich beeinflussen.
In deinem Fall hast du aber Glück da beim FC der übergebene ANY in den Vorgänger-Lokaldaten liegt und P##Bitfeld damit die Kennung W#16#87(V) enthalten müsste.
Dabei wird dann das DB-Register ignoriert. Wenn du nen FB hättest wäre die Kennung W#16#85(DI) enthalten und der L D[AR1]-Zugriff wäre vom DB2-Register beeinflusst.
Ich meine aber auch das ein AUF immer so nahe wie möglich an den Zugriff soll.
Theoretisch kannst du dir das "U DBX[AR1]" sparen und es gegen ein " U [AR1]" tauschen. Damit erfolgt der Zugriff in Abhängigkeit von der Bereichskennung im Pointer.
Wenn dein Bitfeld in einem DB-liegt, dann müsste dein #BitfP auch die Kennung W#16#84(DB) enthalten und der Zugriff in Kombination mit dem DB-Register richtig erfolgen.
Wenn das Bitfeld nicht in einem DB sondern z.B. im Temp des Vorgängers liegt, dann müsste über W#16#87(V) auch dorthin zugegriffen werden.