This is absoltely possible. The system function spawns off a subprocess to execute the passed in command, wth a DCL interpreter available, so if you want to execute a command procedure just prepend a @ to it, as you would running it from the command line. Backticks will also fire off a subprocess, and return the results to you. You can also, if you need to communicate with the subprocess, use open with a leading or trailing pipe, depending on whether you need to send data to or retrieve data from the subprocess. (Note that perl is more limited than normal DCL procedures in this because it inherits some of the Unix limits--if you need two-way communication you'll need to have the perl program open a mailbox and pass it into the child process as the missing handle)
Note that, because perl runs as a user-mode program, spawned subprocesses are real subprocesses and any change they make to their environment is restricted to that subprocess or its children. Normal VMS procedures where DCL command procedures alter symbols or user-mode logicals won't do much good, as their changes won't propagate to the perl process, nor stay around.
DCL runs in supervisor mode and doesn't actually spawn off subprocesses in most cases, so environment changes are persistent, which is why it works normally. And yes, we've considered rewriting perl as a supervisor-mode image, but the problems are a bit more than we'd care to tackle. (Maybe for Parrot. But, then again, maybe not... :)
There's a reasonable amount of documentation for perl on VMS as part of the standard distribution. Also see the various VMS modules on CPAN, and the VMS Perl mailing list at vmsperl@perl.org. (subscribe at vmsperl-subscribe@perl.org) | [reply]
[d/l]
[select] |
| [reply]
[d/l] |
Note that, because of case issues, that list isn't complete. (search.cpan.org has problems with archives where the files in the archive don't match the packages within those files in case) There's more here, as well as in the directories of some of the other authors pulled up by that search.
| [reply] |
I confess that I learned Perl on a VMS system. I second elian's recommendations for where to get information.
In particular, I would recommend reading the documentation perlport, as this contains some very good guidelines for writing code to run on non-Unix platforms.
I remember DCL, in fact I remember some monster .COM file I wrote before touching perl. You will find perl a refreshing change. It will run faster, be much less machine intensive as most of what you need can be done inside perl without spawning out (though you can spawn for the really difficult stuff). No 255 byte limit on strings (hurray!) No horrible doubling up of quotes.
The biggest gotcha will be in file specifications. You have a choice of syntax, as you can use Unix (POSIX) style filespec syntax with slashes, or the native VMS one. But don't mix them! A lot depends on who or what is providing you with filespecs.
The next biggest gotcha is with line termination munging and the record attributes. When it comes to line termination conventions, VMS tries to be all things to everyone, so any files you create from Perl will be STREAM_LF (unless they are binmoded).
Also note that whereas testing on VMS is included for the perl core, many CPAN modules break if they have not followed the rules in perlport. but there is a mechanism http://rt.cpan.org for reporting this to the module authors.
Good luck in your endeavours.
--
I'm Not Just Another Perl Hacker | [reply] |