>>Carl said: This [subroutine malfunction] is because subroutines in XyWrite 3 that end with a right guillemet will malfunction. I think that that explanation is not quite right. I did some code tracing of XyWrite with a debugger once up on a time, when checking why a subroutine definition wasn't "taking." What I found was that when scanning, particularly after seeing a <SU or <SV opening sequence (where '<' means left guillemet), the first thing that the code does is scan forward to find the matching right guillemet. The scanning is "smart" in the sense that it realizes there may be nested < ... > sequences, so it accounts for those and continues scanning until the "matching" guillemet is found. However, every string being scanned by XyWrite always has a length, and XyWrite must stop the scan when the length count countdown says "end of string." The problem is, relative to stopping the scan based on length, XyWrite has a bug, and the count stops scanning 1 byte sooner than it should. If the ending guillemet is not found because of that, then I believe that what happens is that the scanner treats the opening guillemet like any character, passes it along like any other byte, and continues scanning as if the opening guillemet wasn't there. So, at least for awhile, everything just looks like text to be passed along in the same way that the scanner passes along any text. But, not all subroutines are defined in the context of a string where the count terminates the count 1 byte early. For example, when scanning a subroutine definition that is being scanned within an outer subroutine definition, the countdown context is still the that of the outer subroutine as the inner subroutine is being scanned, and the count down context goes way beyond the end of the inner subroutine. The problem is, when you put the code in a S/G, and say "now execute that code" from the S/G, that establishes a new end of string count context that ends at the end of the S/G content. The only bug that exists in the code is the routine that scans forward before doing anything else, to find the matching guillemet for the inner subroutine. When it comes to actually processing the string later so as to execute the code, there is no counting error, and everything executes just fine. So, IMO, the source of the problem is not associated having a subroutine where that "ends with a right guillemet." Rather, it comes from putting a block of code in a context where a new, "inner" region is identified which has its own length count, which is the case if you construct code in a S/G and try to execute it from there. IMO, the reason that XyWrite got out of the door with that bug still active is because most subroutines, particularly in the earlier, simpler world, were LDPMed into a Save/Get from a file that has an EOF character at its tail end. That EOF is included within the S/G holding the subroutine, and is includes in its length calculation. So the EOF char ups the length count by one, and the problem is hidden. Or, to put it another way, the EOF in the S/G serves the same function as the 'NO' function does, when you add it to the end -- it ups the relevant length count. I don't like the idea of an EOF character, because they interfere with concatenating files, among other things, and I once wrote a program the removes them from a file by decreasing the file length by 1. At one time, a made a pass at removing the EOF of most of my .PM files. Probably half of them then failed, the next time they got loaded into XyWrite. But, the solution you propose works fine. But I think the reason is a bit different than what you said. Wally Bass