Nicht zu verwechseln mit VXRexx.
VRexx ist ein (ur)altes Rexx-Addon (aka DLL), mit der man einfache Dialoge programmieren kann. Keine IDE so wie VispoRexx oder VRexx, sondern eine schnelle und vor allem sehr schlanke Möglichkeit, Kommandozeilenprogramme mit etwas GUI-Komfort auszustatten.
Vor zig Jahren hatte ich mir einige solcher Tools mal programmiert. Aber seit Jahren nicht mehr benutzt, bis auf heute. Und muß feststellen: sie laufen nicht mehr.
Weiß jemand, ob es so etwas wie Unverträglichkeiten der VRexx.dll mit "moderner" AOS-Umgebung gibt?
Danke,
Lutz W.
Problem mit VRexx
Erste blöde Frage: bist du sicher, dass die VREXX DLL und auch das VREXX Daemonprogramm (!!!) auf LIBPATH bzw. PATH gefunden werden ?
Ich bezweifle, dass das mit ArcaOS zu tun hat. Die haben REXX mäßig sicher nichts geändert.
Außerdem ist es so meine ich auch nicht möglich mehrere VREXX Skripte parallel laufen zu lassen, dass VREXX "Design" ist glaube ich nicht multi-prozess (ich denke da an das VREXX Daemonprogramm) mäßig ausgelegt (nur so zur Info).
Ich bezweifle, dass das mit ArcaOS zu tun hat. Die haben REXX mäßig sicher nichts geändert.
Außerdem ist es so meine ich auch nicht möglich mehrere VREXX Skripte parallel laufen zu lassen, dass VREXX "Design" ist glaube ich nicht multi-prozess (ich denke da an das VREXX Daemonprogramm) mäßig ausgelegt (nur so zur Info).
Die VREXX.DLL wird gefunden (über "set beginlibpath=xxxx").
Von einem VREXX-Daemon weiß ich nichts. Wäre mir neu.
Es gibt ein Programm namens vrexx.exe, das ruft aber lediglich die vrexx.inf auf.
Und in dieser vrexx.inf steht beschrieben, wie man die VRexx-Funktionen nutzt: Man muß zuallerst in seinem Rexx-Programm die Funktion vinit() aufrufen, und zum Schluß vexit().
Stimmt, steht auch so ähnlich beschrieben im vrexx.inf. Aber sowas mache ich ja auch nicht. Ich starte von der Befehlszeile aus meine rexx.cmd, mit eingebetteten VRexx-Funktionsaufrufen. Alles ganz seriell, prozedural.
Es ist ja auch nicht so, dass ich neu mit VRexx anfange. Ich habe 30 Jahre alte (!) Skripte, die damals liefen. Und heute endet die vinit-Funktion mit dem aussagefähigen Returncode "ERROR" ...
Bist du sicher, dass es da ein VRexx-Daemonprogramm gibt?
Gruß,
Lutz W.
Problem gelöst!
Statt "set beginlibpath" vor jedem Aufruf habe ich jetzt die vrexx.dll in den LIBPATH (gem config.sys) aufgenommen. Und der Spuk ist vorbei.
Habe zwar keine Ahnung, wie das zusammenhängt. Aber egal. Alles läuft jetzt, wie vor 30 Jahren
Gruß,
Lutz W.
Statt "set beginlibpath" vor jedem Aufruf habe ich jetzt die vrexx.dll in den LIBPATH (gem config.sys) aufgenommen. Und der Spuk ist vorbei.
Habe zwar keine Ahnung, wie das zusammenhängt. Aber egal. Alles läuft jetzt, wie vor 30 Jahren
Gruß,
Lutz W.
Mit "Multi-Prozess"meinte ich: du kannst nicht zwei REXX Skripte gleichzeitig ausführen, die beide VRexx benutzen.DonLucio hat geschrieben: ↑Fr 1. Sep 2023, 16:29Die VREXX.DLL wird gefunden (über "set beginlibpath=xxxx").
Von einem VREXX-Daemon weiß ich nichts. Wäre mir neu.
Es gibt ein Programm namens vrexx.exe, das ruft aber lediglich die vrexx.inf auf.
Und in dieser vrexx.inf steht beschrieben, wie man die VRexx-Funktionen nutzt: Man muß zuallerst in seinem Rexx-Programm die Funktion vinit() aufrufen, und zum Schluß vexit().
Stimmt, steht auch so ähnlich beschrieben im vrexx.inf. Aber sowas mache ich ja auch nicht. Ich starte von der Befehlszeile aus meine rexx.cmd, mit eingebetteten VRexx-Funktionsaufrufen. Alles ganz seriell, prozedural.
Es ist ja auch nicht so, dass ich neu mit VRexx anfange. Ich habe 30 Jahre alte (!) Skripte, die damals liefen. Und heute endet die vinit-Funktion mit dem aussagefähigen Returncode "ERROR" ...
Bist du sicher, dass es da ein VRexx-Daemonprogramm gibt?
Gruß,
Lutz W.
"vrexx.exe" ist das VRexx-Daemonprogramm. Dieses Programm wird soweit ich mich erinnern kann von der DLL gestartet und stellt eben die PM Fenster dar weil du einen PM Prozess und damit ein PM Programm brauchst um Fenster zu zeichnen. REXX selbst läuft ja unter cmd.exe und das ist ein Kommandozeilenprogramm.
Die Beschränkung, daß nur eine VREXX-nutzende Prozedur aus dem gleichen CMD aufgerufen werden konnte, bestand bei der Version 1.0. Mit der Version 1.1 sollte dies behoben sein.
Stimmt, mit Version 1.1 kann man auch mehrere VREXX Skripte parallel ausführen.