Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#159 Pending list for prefix macros not being processed properly

open
nobody
None
5
2007-11-26
2007-11-26
LesK
No

I've reviewed all the bugs about PREFIX and PENDING and done a lot of experimenting with 3.2 on WXP and W2K with ooRexx. As my guide to 'proper processing' I took the
Xedit Command and Macro Reference Version 3 Release 1.0
from IBM's online library.

I'm pretty sure that all the bugs I've seen, reported myself, or have waiting in the wings, all trace back to THE not implementing the prefix processing 'rules' as documented by IBM, mostly in the area of turning off pending for the macro as it is called and saving and restoring settings around the macro's execution. There may be more gory exceptions, but those are the main ones I've seen.

Please, please, PLEASE, don't take this as any disparagement against the EXCELLENT work being done on THE! It has become the lifeblood of my using the pc for anything besides email, web browsing and Quicken.

My retirement from IBM after LOTS of years using VM and Xedit has now become more exciting because of THE, ooRex and RexxLA!

Discussion

  • Logged In: YES
    user_id=254557
    Originator: NO

    Hi,

    I'm testing this with 3.3 Beta 3 and have the similar issues. I don't know about IBM explicitly documenting the rules, but it's assumed that the PENDING condition for a Prefix Macro is turned off right away when it is called. I read that the Current Line is restored automatically, I don't read that other settings are. Seems PRESERVE and RESTORE are expected for other settings.

    -- Warren Van Wyck

    I still have a VM/ESA 2.4 system available for testing.

     
  • Finn Skovgaard
    Finn Skovgaard
    2010-08-09

    rr
    rr3
    Doesn't repeat the block of lines 3 times, only once. The repeat factor isn't taken into consideration (whether using " or r)

     
  • Mark Hessling
    Mark Hessling
    2010-08-09

    THE requires the repeat factor to be supplied with the first block command entered. Type the commands in the order: rr3, rr. It doesn't matter if rr3 is below rr, its the order that the commands are entered that is important.
    I assume "rr" is your own prefix macro?

     
  • Finn Skovgaard
    Finn Skovgaard
    2010-08-10

    Yes that works. Quirky. Xedit didn't care. I've always had r defined as a synonym for " for compatibility with ISPF and because " requires using shift, at least on my keyboard.

     
  • Mark Hessling
    Mark Hessling
    2010-08-10

    Well I've wondered what XEDIT would do with "rr3" followed by "rr2". Would it repeat 3 times, 2 times, or treat these as "rr3" pending and "rr2" pending until two "rr" were entered. After all "rr" is the same as "rr1", so I needed to have a priority of which repeat count to use.

     
  • Finn Skovgaard
    Finn Skovgaard
    2010-08-10

    Well since Xedit doesn't process anything until you press enter, it's not relevant if you type one or the other first as long as both are typed before you press enter. I don't know what Xedit would do with rr2 then rr3. I can't recall ever having done that during 20 years of VM. Someone would need to try on a VM system. I guess one overrides the other.

     
  • Finn Skovgaard
    Finn Skovgaard
    2010-08-10

    Of course, even VM processes a block of commands as two iterations, so there must be a decision which repeat factor to use or whether to fail if there is a conflict.

     
  • Finn Skovgaard
    Finn Skovgaard
    2010-08-11

    Apparently, for block prefix commands, THE calls the macro in the order the commands were typed, not in line order as in Xedit. This different behaviour breaks certain macros imported from Xedit if they presume that the first call corresponds to the lowest line number. I don't know if it's possible to emulate Xedit's behaviour, but it would eliminate such breakage. It's difficult to see any advantage of using the entry order as criteria in a program emulating mainframe behaviour.

     
  • Finn Skovgaard
    Finn Skovgaard
    2010-08-15

    There is another breakage in THE's prefix command handling. A block prefix command works by the editor calling the prefix macro once for each block prefix. During the first call, the macro sets the first line as pending, so that on the second call, the macro knows where the first block command is. That is how Xedit documentation explains writing prefix macros. Trouble in THE is, if you enter one block command like hh, then press enter, it is executed once as it should, then it goes pending. When you press enter again, THE calls the macro AGAIN for the pending line. The editor should not execute a macro for a line that is marked pending.