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)