On 2/1, I posted a message wondering whether it was possible for
the C and Pascal challenged among us to call the Native Mode (NM)
AIFs from Compatibility Mode (CM) programs (in particular, SPL)
by using the switch subsystem. I was close to being able to do it
but seemed to be stuck with a CM -> NM address conversion
problem. Several people responded, and between their suggestions
and some old fashioned roll-up-the-shirt-sleeves, trial-and-error
programming, I was able to determine an answer. And a warning.
 
Parenthetically, the Response Center told me last fall that as
far as they could determine, no one had ever tried such a Rube
Goldberg approach, and anyway, the consensus was it would not
work. Talk about fuel for the fire!
 
Anyway, the good news is that, if necessary, you can access the
NM operating system AIFs from CM programs by using the switch
subsystem. The bad news is that it is painfully awkward,
confusing, and time consuming to write the switch stubs. The
really bad news is that in the process of trying to figure things
out, you can trash almost anything on your system, including the
system itself.
 
Unless you have a development machine to work on, you must be
extraordinarily careful. In my original post, I puzzled over the
fact that the status array returned by AIFJSGET in my test
program showed successful completion, yet the result (the value
of USERNAME) was nowhere to be found on my stack.
 
Shortly after writing the original posting, one of my system
users reported getting a message indicating a corrupt root file
in a TurboIMAGE database. Since I had never seen a corrupt root
file in 17 years of using IMAGE, this naturally peaked my
interest. The red-faced user standing in my doorway may also have
contributed to my interest.
 
Upon comparing the corrupt root file with the root file from the
previous night's backup, I discovered that the result of my
AIFJSGET was residing in the first 8 bytes of the first user
label (there are six altogether) of the corrupt root file!
 
Consider the magnitude of this. For testing purposes, I called an
AIF which in theory only does inquiries (i.e. does not update
anything), and I end up trashing a user label in a PRIV file (the
root file of a TurboIMAGE database) being accessed by someone
else. Pretty neat, huh? And scary?
 
A characteristic of the operating system AIFs (as Stan Sieler
commented on 2/2) is the need to embed multiple 64-bit virtual
addresses within a data structure to be passed to the AIF. CM
knows nothing about 64-bit virtual addresses. Since you must be
in Privilege Mode (PM) to call an AIF, passing an incorrect
address can have unpredictable, and, as seen above, potentially
catastrophic consequences. Note that the problem is caused
because you are in CM, trying to pass a NM address as part of a
data structure. You MUST use the AIF AIFCONVADDR (setting up the
switch stub for it), and use it correctly, to avoid disaster.
 
As Jerry Fochtman suspected in his post of 2/5, my example using
AIFJSGET was just that, an example that could be easily
understood. In reality, I wanted to use AIFSPFPUT to modify the
READY DATE and READY TIME of specific spoolfiles. This can not be
done using standard intrinsics. Those who are familiar with my
ramblings in HP Professional may recognize this as the print file
queue ordering problem.
 
My solution program, ALTSPFQ, has been in production for a week
now, completely integrated into the suite of UDCs we use to
control our system printers. Basically, it takes the place of the
SPOOLF command, setting priority, device and number of copies,
while re-ordering the spooler device queue to reflect the order
in which the spoolfiles are "altered". Assuming it continues to
perform as designed, and no one contributes a completely NM
version (which would be preferable), I'll contribute ALTSPFQ to
the CSL.