Gary writes:
> What is happening is that if a UDC command calls another UDC which
> comes before it in the UDC file, it does not recognise that UDC. This
> used to work fine on the 937, is there a solution for this problem.
As far as I know, UDCs have always worked such that if you have a file
with two UDCs in it (A and B, with A appearing first in the file),
A can call B, but B cannot call A (unless "OPTION RECURSION" is on).
UDCs have worked that way since at least MPE V. The primary reason
for this is to allow you to write a UDC that encapsulates an existing
MPE command of the same name:
...
****************
abortjob jobnum
tellop I am aborting job !jobnum
abortjob !jobnum
****************
...
To allow such a UDC to work, the UDC-name lookup code said: let's start
looking for the name of a given command AFTER the point in the UDC file
where I currently am "executing". Thus, while executing the abortjob
UDC above, the search for the "tellop" and "abortjob" commands begin
after the second row of "****" above. If "tellop" isn't found in the
UDC file (starting at that point), then the next UDC file (if any) is
examined, then the next, etc., until all remaining UDC files have been
examined. Then, built-in commands are checked, then command files.
(Note: this is easy to check...try it out)
So, if you had the case where a later UDC was successfully calling an
earlier UDC *IN THE SAME FILE*, then the later UDC must have had
"option recursion" on.
Here is a sample UDC file, with UDCs: A, B, RA, RB. A calls B, B tries
to call A (and fails). RA calls RB, RB tries to call RA (and succeeds,
because it has OPTION RECURSION).
a
echo udc A
b
************
b
echo udc B
a
************
ra
echo udc RA
rb
************
rb
option recursion
echo udc RB
ra
***********
Now, if your commands were actually command files, and not UDCs, on the 937
and were now UDCs...that would also explain the difference.
Similarly, if the two UDCs in question were in separate files (and the files
were in the opposite order), that would also explain the difference.
--
Stan Sieler [log in to unmask]
http://www.allegro.com/sieler.html
|