I write a lot of VAX/VMS programs that change mode to Exec, to get their work done. Lots of interesting VMS data structures are visible (and some are changeable) when you are in Exec mode.
When your program is working with these data structures, it's only natural to want to display some of the results. You could collect the data in Exec mode, and return to User node to output it, and that's what a lot of folks do. But that can be a pain in the sitz-platz, switching back and forth all the time. Instead , I don't return to User mode to do that, I just open a file or call lib$put_output (which uses RMS for its IO) and output the data, while still in Exec mode
"But wait!" many of you are thinking, while you clutch your pearls and recoil in horror. "You can't do RMS IO from Exec mode!!!" Suffused with a sense of their superiority, people (often otherwise very knowledgeable people) often attempt to correct me about my ignorant transgressions, of using RMS where it's not welcome. After all, EVERYONE knows that Executive mode is reserved for the workings of RMS - it doesn't make sense for a user's program to do RMS operations in that mode - it would hit its head on the ceiling! Or something...
But here's the shocking, but, for some reason, not very well known fact - using RMS while in Exec mode is perfectly fine, documented and supported. In the "OpenVMS Record Management Services Manual", section 2.5, it says...
2.5 Allowable Program Execution Modes
RMS should not be called from kernel mode, from executive AST mode, or from executive mode when executive-mode ASTs are disabled.
This spells out when you CAN'T use RMS. This list of places you can't use RMS DOES NOT include non-AST, AST enabled EXEC mode - and that's how I use it. On a serious note - if you can find any documentation from DEC, COMPAQ, HP or even VSI to the contrary on this issue - I'd sure like to hear about it.
I don't know how the urban legend, that you can't use RMS while in EXEC mode, got started - but, boy howdy, I can sure tell you it is widespread. I'm thinking about quoting that RMS manual section in all of the code that I distribute, that uses this technique, to try and cut down on the number of times I have to argue the issue.
Really, if the complainers would stop and think a minute, they'd realize VMS is riddled with examples of RMS activity initiated and performed while in Exec mode. SYS$GETUAI and SYS$PUTUAI for instance, or the opening of process permanent files.
So, if you spot this occurring in any of my programs, save your breath - I don't need to be "educated" about this.
Interestingly enough, a few test programs have shown me that RMS file IO and lib$put_output work from Kernel mode as well - but this is documented as not supported, and not a good idea, so I don't do it and don't recommend it. But, if you want to see what it's like, just change the $cmexec_s call in the example program to $cmkrnl_s...it seems to work just fine...
Anyway, here's an example program.
rmsfromexec.mar
To use, first make sure you have CMEXEC priv, and then...
$ mac rmsfromexec
$ link rmsfromexec
$ run rmsfromexec
Command me>testfilename.txt
You'll see the contents of the input file on your screen, and it will be copied to a file called data.dat. The file IO will have been done in EXEC mode, and the skies didn't split. Since it does change mode, however, I have to include a disclaimer- use at your own risk - file IO from EXEC mode is documented and supported, but, no program is perfect.
