#1628 Inconsistent interfacing to THE editor

[Jochem Peelen]

Windows 8.1 64 bit
ooRexx 5.0.0 32 bit build 11858
The Hessling Editor 3.3B3, in particular command "the -p profile.the"

Situation:
a) open an administrator command line , switch to "c: \program files (x86)\ ooRexx" and make changes. In one case, resetting the archive bits of rexxtry and oorexxtry was sufficient.
b) Then open an ordinary command line (defaults to different directory) and issue "the -p profile.the"
PROBLEM: The profile is not executed (default screen format is shown) and an editor message is issued:
"Error 0052: Non-REXX macros MUST have a first line of /NOREXX/"

My profile.the is of course Rexx and basically changes THE to XEDIT mode, last change to it was 24 Feb 2018.
The problem happened multiple times with a few of the recent builds, including 11858. It never occurred with build 11845 or 11852, for example.
Another deviation from normal execution is that it takes more than 3 seconds before the dir.dir file is shown, while normally is is displayed immediately.

Now comes the embarrassing part.
Although I recreated it this morning again with 11858, I am not able to describe a reliable way to show this behaviour. After half a dozen or more uninstalls/installs/upgrades of several build versions to develop a watertight description, the problem has become elusive.
It goes without saying that nobody can act on a bug that cannot be consistenly reproduced. But something is wrong here and could (in my IT experience will) crop up again.

[Jochem Peelen]

Typo: the word NOREXX of course is within a comment. This software edited out the asterisks.

[Gil Barmwater]

I would guess that this might be related to a situation I encountered as follows: RXAPI is not running, either because it was stopped or the system was just rebooted, and then a rexx command is issued from an administrator/elevated prompt. If you then try to run a rexx command from a normal prompt, the startup time is very long and it appears that RXAPI cannot be "found". Stopping RXAPI from an elevated prompt will restore normal prompt behavior. FWIW

[Jochem Peelen]

When installing build 11861 I was able to reproduce the behaviour. Sequence of commands immediately after installing the new build:
1) open administrator command line and change to ooRexx installation directory
2) issue "the -p profile.the" to check that interaction with THE is ok (dir.dir shown in XEDIT mode)
3) leave dir.dir using qquit
4) issue "attrib -A rexxtry.rex" and "attrib -A oorexxtry.rex" to change somethig in the installation directory
5) close administrator command line window
6) open ordinary command line window
7) issue "the -p profile.the " and find that interaction with THE is broken:
It takes several seconds for THE to show dir.dir, the profile (written in Rexx) is not executed, THE shows its default screen format and THE issues the 0052 NOREXX error message as cited in this ticket.

Logoff/Logon from the used account seems to re-establish normal function.

Additional hints:
The install is an upgrade install. I have a number of own program files in the installation directory. Reason for resetting the archive bits of [oo]rexxtry.rex is to exempt both from backup of my program files.

[Jochem Peelen]

Rexx build 11861; everthing else unchaged compared to opening of this report.

This evening the bug unexpectedly showed up during ordinary work (no new installation) after creating a new subdirectory and copying 12 files to it using the Windows Explorer:
In an ordinary command line window, "the -p profile.the" resulted in the profile not being processed by ooRexx and THE error message 0052 as describe above.
From an administrator command line, the same command was processed withou bug.
The bug was reproducable. I opened/closed several command line windows one after the other, alternating between ordinary and administrator. The behaviour remained the same for both types and irrespective of the current directory: bug in ordinary command line, ok in administrator command line.
Logging off from the userid and logging on to it again removed the bug.

[Rick McGuire]

I believe this problem has probably been fixed by [#1641]

[Jochem Peelen]

After installation of builds 11891, 11892 and 11893 on three consecitive days, I can confirm that the behaviour as described in ticket 1628 did not show up on these three occasions and might have been solved by the fix to 1641.

Regards
Jochem Peelen

[Jochem Peelen]

The problem did not show up during a dozen installs of builds 11895 through 11926. I propose to close #1628 as a duplicate of #1641.

Regards
Jochem Peelen

[Erich]

Hi Jochem, good to hear.
Bug #1628 is already duplicate/pending - that's fine.

[Jochem Peelen]

The reported problem was no longer encountered when installing build 12079 on

• 32 bit ooRexx under Windows 8.1
• 64 bit ooRoss under Windows 10 1909

Doing a "quick upgrade" type of install, the uninstaller from build 12074 had no problem to remove rxapi.
I did not systematically test this with the builds I installed in the 14 months since reporting the problem. Routinely, I logged off and on before installation to make sure rxapi did not run.

Therefore I cannot tell which build brought the fix to the bug. From my perspective, the rxapi bug is fixed.

Regards
Jochem Peelen

[Jochem Peelen]

Sorry for the confusion,
the previous message was intended for bug #1627 (rxapi locked)

[Rick McGuire]

Duplicate of [#1641]