Re: NotaBene S/G usage vs. U2

[Carl Distefano cld@xxxxxxxx]

Reply to note from Harry Binswanger  Sun, 18 Apr
2010 14:02:42 -0600

Harry:

> I've solved the concrete problem, just be renumbering the ones
> in my frame to 01 and 02 instead of 90 and 91. But it's the
> general issue I'm concerned about--how to avoid Xy-NB conflicts
> if they use S/Gs in the 80s and 90s.

I'm not a regular NB user, but, in my limited experience with it, I
haven't encountered Save/Get conflicts with U2. But I load my
XyWrite KBD file, which eliminates all calls to the AUX program
files, so I'm not a good test case. And you're right, S/G usage in
the AUX files is all over the lot.

If you don't have the time or inclination to pinpoint the actual
conflicts and fix them one by one (and heaven knows I don't), then
you could take a blunderbuss approach and HIDE *all* transient S/Gs
(01-99) within your frame $H. I emphasize "all" because you want to
protect not only the S/Gs used by $H itself, but also the S/Gs used
in any frame *called* by $H -- which could be any frame at all,
because, of course, the raison d'etre of $H is to launch frames. For
these reason, you can't pick and choose S/Gs; you've got to HIDE,
then UNHIDE, them all.

If you go this route, you need to make two changes to your frame $H:
(1) Make "JM 2.HIDE:01-99Q2 " the very first statement in the frame;
and
(2) Restructure $H so that it has a single EXit point:
JM 2.UNHIDEQ2 
Substitute  for all the other  commands in the frame.

HIDEing 01-99 should knock out 99.9% of S/G conflicts with U2 frames
(assuming, of course, that you launch U2 frames exclusively with
$H). (A conspicuous instance where this method will NOT work is when
a frame called by $H ends with , so that the flow of execution
doesn't circle back to the UNHIDE statement in $H. That's life.) The
downside to the blunderbuss is that PMs will launch and execute more
slowly (though with a fast processor you may not notice). More
important, you may encounter out-of-memory anomalies. But maybe not.
You can only try.

--
Carl Distefano
cld@xxxxxxxx