[A note about RPL argument type checking w/o bogus XLIB error messages.  -jkh]
 Author: [Joseph James Ervin]
 Date: Wed Mar 06 1991

In the course of doing some system RPL proramming, I had need to do argument
checking, so I wanted to use the RPL instructions that do this.  I had my
choice between one that said "save last RPL token" and one that said "set last
RPL token to <0h>".  I tried both.  There was a significant difference.

When I used the command that said "save last RPL token", I got a strange XLIB
number when the parameter check failed.  When I used "set last RPL token to
<0h>" the code which prints out the error message did not attempt to display
the XLIB that generated the error.

In other words, did you ever wonder how the machine knows, when you hit + with
no arguments, that it should include "+" in the error message to tell you what
command (e.g. XLIB) generated the error?  My guess is that the "last RPL
token" is just a variable somewhere into which is stored the ID of the most
recent RPL token.  When something goes wrong and an error message must be
displayed, the system will pull the saved ID out of this variable and use it in
the error message.  By using system RPL routines that say "set last RPL token
to <0h>", the system flags this variable as containing bogus data, and that it
should not be used in error messages.  I have no idea what other things this
"last RPL token" variable may be used for.

Please keep in mind that this is just my guess based on my own observations.
Oh, by the way, Bill Wickes uses the "set LAST RPL token to <0h>" in his ASC
routines.  That's why when you feed ASC bad parameters, the error message makes
no attempt to identify ASC as the command that generated the error.