On 10/10/2017 12:20 PM, Steve Smith wrote:
D*** it, I used to know that! Great catch.
Rewind all that about CC=1. In *this* case, purely from a technical POV.
On Tue, Oct 10, 2017 at 3:14 PM, Tony Harminc <t...@harminc.com> wrote:
So it's the table *output* characters that are matched against the
character in R0 - not the input. For TROT that character is a 16-bit
one, and your hex table is only 512 bytes long, is sparse, and is not
going to contain 0000 or any of the other 65279 values you could
choose arbitrarily to avoid ending prematurely with CC=1.
Actually, that clarification is worth the cost of this exercise. So in
this particular case, so long as R0 isn't any of the obvious
two-character values C'00' - C'FF' it should work!
I'm guessing our "rogue cowboy" ex-employee didn't realize that either
or he wouldn't have bothered to go to so much trouble to subvert
OPTABLE(YOP) to unnecessarily set M3=1. He could have left M3=0 and
simply done XGR R0,R0 to avoid a stop character match.
So nothing has changed except that (by pure blind luck) this particular
code fragment works in the field. Haha! Even a stopped clock is right
twice a day... :-D
I like Paul Gilmartin's idea of a LOCTR with non-overlay attribute. Any
DC at a location below the highest-known value for that LOCTR would
trigger a diagnostic. I might be able to issue my own MNOTE in a macro I
could OPSYN for DC if I could detect the current location and
highest-allocated location in my current LOCTR. Unfortunately, I don't
remember seeing &SYSxxxxx symbols containing those values. Perhaps
requesting such symbols would be a first step RFE. Something like
&SYSLOC_CURLOC and &SYSLOC_HWMLOC could come in handy for other uses as
well...
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/
