Gathered below are notes describing details of Perl 5's behavior on VMS. They are a supplement to the regular Perl 5 documentation, so we have focussed on the ways in which Perl 5 functions differently under VMS than it does under Unix, and on the interactions between Perl and the rest of the operating system. We haven't tried to duplicate complete descriptions of Perl features from the main Perl documentation, which can be found in the [.pod] subdirectory of the Perl distribution.

We hope these notes will save you from confusion and lost sleep when writing Perl scripts on VMS. If you find we've missed something you think should appear here, please don't hesitate to drop a line to [email protected].

Installation

Directions for building and installing Perl 5 can be found in the file README.vms in the main source directory of the Perl distribution..

Organization of Perl Images

Core Images

During the installation process, three Perl images are produced.Miniperl.Exe is an executable image which contains all ofthe basic functionality of Perl, but cannot take advantage ofPerl extensions. It is used to generate several files neededto build the complete Perl and various extensions. Once you'vefinished installing Perl, you can delete this image.

Most of the complete Perl resides in the shareable imagePerlShr.Exe, which provides a core to which the Perl executableimage and all Perl extensions are linked. You should place thisimage in Sys$Share, or define the logical name PerlShr totranslate to the full file specification of this image. It shouldbe world readable. (Remember that if a user has execute only accessto PerlShr, VMS will treat it as if it were a privileged shareableimage, and will therefore require all downstream shareable images to beINSTALLed, etc.)

Finally, Perl.Exe is an executable image containing the mainentry point for Perl, as well as some initialization code. Itshould be placed in a public directory, and made world executable.In order to run Perl with command line arguments, you shoulddefine a foreign command to invoke this image.

Perl Extensions

Perl extensions are packages which provide both XS and Perl codeto add new functionality to perl. (XS is a meta-language whichsimplifies writing C code which interacts with Perl, seeperlxs for more details.) The Perl code for anextension is treated like any other library module - it'smade available in your script through the appropriateuse or require statement, and usually defines a Perlpackage containing the extension.

The portion of the extension provided by the XS code may beconnected to the rest of Perl in either of two ways. In thestatic configuration, the object code for the extension islinked directly into PerlShr.Exe, and is initialized wheneverPerl is invoked. In the dynamic configuration, the extension'smachine code is placed into a separate shareable image, which ismapped by Perl's DynaLoader when the extension is used orrequired in your script. This allows you to maintain theextension as a separate entity, at the cost of keeping track of theadditional shareable image. Most extensions can be set up as eitherstatic or dynamic.

The source code for an extension usually resides in its owndirectory. At least three files are generally provided:Extshortname.xs (where Extshortname is the portion ofthe extension's name following the last ::), containingthe XS code, Extshortname.pm, the Perl library modulefor the extension, and Makefile.PL, a Perl script which usesthe MakeMaker library modules supplied with Perl to generatea Descrip.MMS file for the extension.

Installing static extensions

Since static extensions are incorporated directly intoPerlShr.Exe, you'll have to rebuild Perl to incorporate anew extension. You should edit the main Descrip.MMS or Makefileyou use to build Perl, adding the extension's name to the extmacro, and the extension's object file to the extobj macro.You'll also need to build the extension's object file, eitherby adding dependencies to the main Descrip.MMS, or using aseparate Descrip.MMS for the extension. Then, rebuildPerlShr.Exe to incorporate the new code.

Finally, you'll need to copy the extension's Perl librarymodule to the [.Extname] subdirectory under oneof the directories in @INC, where Extname is the nameof the extension, with all :: replaced by . (e.g.the library module for extension Foo::Bar would be copiedto a [.Foo.Bar] subdirectory).

Installing dynamic extensions

In general, the distributed kit for a Perl extension includesa file named Makefile.PL, which is a Perl program which is usedto create a Descrip.MMS file which can be used to build andinstall the files required by the extension. The kit should beunpacked into a directory tree not under the main Perl sourcedirectory, and the procedure for building the extension is simply

 $ perl Makefile.PL  ! Create Descrip.MMS
  $ mmk   ! Build necessary files
  $ mmk test  ! Run test code, if supplied
  $ mmk install   ! Install into public Perl tree

N.B. The procedure by which extensions are built andtested creates several levels (at least 4) under thedirectory in which the extension's source files live.For this reason if you are running a version of VMS priorto V7.1 you shouldn't nest the source directorytoo deeply in your directory structure lest you exceed RMS'maximum of 8 levels of subdirectory in a filespec. (Youcan use rooted logical names to get another 8 levels ofnesting, if you can't place the files near the top ofthe physical directory structure.)

VMS support for this process in the current release of Perlis sufficient to handle most extensions. However, it doesnot yet recognize extra libraries required to build shareableimages which are part of an extension, so these must be addedto the linker options file for the extension by hand. Forinstance, if the PGPLOT extension to Perl requires thePGPLOTSHR.EXE shareable image in order to properly linkthe Perl extension, then the line PGPLOTSHR/Share mustbe added to the linker options file PGPLOT.Opt producedduring the build process for the Perl extension.

By default, the shareable image for an extension is placed inthe [.lib.site_perl.autoArch.Extname] directory of theinstalled Perl directory tree (where Arch is VMS_VAX orVMS_AXP, and Extname is the name of the extension, witheach :: translated to .). (See the MakeMaker documentationfor more details on installation options for extensions.)However, it can be manually placed in any of several locations:

the [.Lib.Auto.Arch$PVersExtname] subdirectoryof one of the directories in @INC (where PVersis the version of Perl you're using, as supplied in $],with '.' converted to '_'), or
one of the directories in @INC, or
a directory which the extensions Perl library modulepasses to the DynaLoader when asking it to mapthe shareable image, or
Sys$Share or Sys$Library.

If the shareable image isn't in any of these places, you'll needto define a logical name Extshortname, where Extshortnameis the portion of the extension's name after the last ::, whichtranslates to the full file specification of the shareable image.

File specifications

Syntax

We have tried to make Perl aware of both VMS-style and Unix-style filespecifications wherever possible. You may use either style, or both,on the command line and in scripts, but you may not combine the twostyles within a single file specification. VMS Perl interprets Unixpathnames in much the same way as the CRTL (e.g. the first componentof an absolute path is read as the device name for the VMS filespecification). There are a set of functions provided in theVMS::Filespec package for explicit interconversion between VMS andUnix syntax; its documentation provides more details.

We've tried to minimize the dependence of Perl librarymodules on Unix syntax, but you may find that some of these,as well as some scripts written for Unix systems, willrequire that you use Unix syntax, since they will assume that'/' is the directory separator, etc. If you find instancesof this in the Perl distribution itself, please let us know,so we can try to work around them.

Also when working on Perl programs on VMS, if you need a syntaxin a specific operating system format, then you need either tocheck the appropriate DECC$ feature logical, or call a conversionroutine to force it to that format.

The feature logical name DECC$FILENAME_UNIX_REPORT modifies traditionalPerl behavior in the conversion of file specifications from Unix to VMSformat in order to follow the extended character handling rules nowexpected by the CRTL. Specifically, when this feature is in effect, the./.../ in a Unix path is now translated to [.^.^.^.] instead ofthe traditional VMS [...]. To be compatible with what MakeMakerexpects, if a VMS path cannot be translated to a Unix path, it ispassed through unchanged, so unixify("[...]") will return [...].

The handling of extended characters is largely complete in theVMS-specific C infrastructure of Perl, but more work is still needed tofully support extended syntax filenames in several core modules. Inparticular, at this writing PathTools has only partial support fordirectories containing some extended characters.

There are several ambiguous cases where a conversion routine cannotdetermine whether an input filename is in Unix format or in VMS format,since now both VMS and Unix file specifications may have characters inthem that could be mistaken for syntax delimiters of the other type. Sosome pathnames simply cannot be used in a mode that allows either typeof pathname to be present. Perl will tend to assume that an ambiguousfilename is in Unix format.

Allowing "." as a version delimiter is simply incompatible withdetermining whether a pathname is in VMS format or in Unix format withextended file syntax. There is no way to know whether "perl-5.8.6" is aUnix "perl-5.8.6" or a VMS "perl-5.8;6" when passing it to unixify() orvmsify().

The DECC$FILENAME_UNIX_REPORT logical name controls how Perl interpretsfilenames to the extent that Perl uses the CRTL internally for manypurposes, and attempts to follow CRTL conventions for reportingfilenames. The DECC$FILENAME_UNIX_ONLY feature differs in that itexpects all filenames passed to the C run-time to be already in Unixformat. This feature is not yet supported in Perl since Perl usestraditional OpenVMS file specifications internally and in the testharness, and it is not yet clear whether this mode will be useful oruseable. The feature logical name DECC$POSIX_COMPLIANT_PATHNAMES is newwith the RMS Symbolic Link SDK and included with OpenVMS v8.3, but isnot yet supported in Perl.

Filename Case

Perl follows VMS defaults and override settings in preserving (or notpreserving) filename case. Case is not preserved on ODS-2 formattedvolumes on any architecture. On ODS-5 volumes, filenames may be casepreserved depending on process and feature settings. Perl now honorsDECC$EFS_CASE_PRESERVE and DECC$ARGV_PARSE_STYLE on those systems wherethe CRTL supports these features. When these features are not enabledor the CRTL does not support them, Perl follows the traditional CRTLbehavior of downcasing command-line arguments and returning filespecifications in lower case only.

N. B. It is very easy to get tripped up using a mixture of otherprograms, external utilities, and Perl scripts that are in varyingstates of being able to handle case preservation. For example, a filecreated by an older version of an archive utility or a build utilitysuch as MMK or MMS may generate a filename in all upper case even on anODS-5 volume. If this filename is later retrieved by a Perl script ormodule in a case preserving environment, that upper case name may notmatch the mixed-case or lower-case exceptions of the Perl code. Yourbest bet is to follow an all-or-nothing approach to case preservation:either don't use it at all, or make sure your entire toolchain andapplication environment support and use it.

OpenVMS Alpha v7.3-1 and later and all version of OpenVMS I64 supportcase sensitivity as a process setting (see SET PROCESS/CASE_LOOKUP=SENSITIVE). Perl does not currently support casesensitivity on VMS, but it may in the future, so Perl programs shoulduse the File::Spec->case_tolerant method to determine the state, andnot the $^O variable.

Symbolic Links

When built on an ODS-5 volume with symbolic links enabled, Perl bydefault supports symbolic links when the requisite support is availablein the filesystem and CRTL (generally 64-bit OpenVMS v8.3 and later). There are a number of limitations and caveats to be aware of whenworking with symbolic links on VMS. Most notably, the target of a validsymbolic link must be expressed as a Unix-style path and it must existon a volume visible from your POSIX root (see the SHOW ROOT commandin DCL help). For further details on symbolic link capabilities andrequirements, see chapter 12 of the CRTL manual that ships with OpenVMSv8.3 or later.

Wildcard expansion

File specifications containing wildcards are allowed both on the command line and within Perl globs (e.g. <*.c>). Ifthe wildcard filespec uses VMS syntax, the resultant filespecs will follow VMS syntax; if a Unix-style filespec is passed in, Unix-style filespecs will be returned.Similar to the behavior of wildcard globbing for a Unix shell,one can escape command line wildcards with double quotationmarks " around a perl program command line argument. However,owing to the stripping of " characters carried out by the Chandling of argv you will need to escape a construct such asthis one (in a directory containing the files PERL.C, PERL.EXE,PERL.H, and PERL.OBJ):

 $ perl -e "print join(' ',@ARGV)" perl.*
  perl.c perl.exe perl.h perl.obj

in the following triple quoted manner:

 $ perl -e "print join(' ',@ARGV)" """perl.*"""
  perl.*

In both the case of unquoted command line arguments or in callsto glob() VMS wildcard expansion is performed. (csh-stylewildcard expansion is available if you use File::Glob::glob.)If the wildcard filespec contains a device or directory specification, then the resultant filespecs will also contain a device and directory; otherwise, device and directory information are removed. VMS-style resultant filespecs will contain a full device and directory, while Unix-style resultant filespecs will contain only as much of a directory path as was present in the input filespec. For example, if your default directory is Perl_Root:[000000], the expansion of [.t]*.* will yield filespecs like "perl_root:[t]base.dir", while the expansion of t/*/* will yield filespecs like "t/base.dir". (This is done to match the behavior of glob expansion performed by Unix shells.)

Similarly, the resultant filespec will contain the file versiononly if one was present in the input filespec.

Pipes

Input and output pipes to Perl filehandles are supported; the "file name" is passed to lib$spawn() for asynchronous execution. You should be careful to close any pipes you have opened in a Perl script, lest you leave any "orphaned" subprocesses around when Perl exits.

You may also use backticks to invoke a DCL subprocess, whose output is used as the return value of the expression. The string between the backticks is handled as if it were theargument to the system operator (see below). In this case,Perl will wait for the subprocess to complete before continuing.

The mailbox (MBX) that perl can create to communicate with a pipedefaults to a buffer size of 8192 on 64-bit systems, 512 on VAX. Thedefault buffer size is adjustable via the logical name PERL_MBX_SIZEprovided that the value falls between 128 and the SYSGEN parameterMAXBUF inclusive. For example, to set the mailbox size to 32767 use$ENV{'PERL_MBX_SIZE'} = 32767; and then open and use pipe constructs. An alternative would be to issue the command:

 $ Define PERL_MBX_SIZE 32767

before running your wide record pipe program. A larger value mayimprove performance at the expense of the BYTLM UAF quota.

PERL5LIB and PERLLIB

The PERL5LIB and PERLLIB logical names work as documented in perl,except that the element separator is '|' instead of ':'. Thedirectory specifications may use either VMS or Unix syntax.

The Perl Forked Debugger

The Perl forked debugger places the debugger commands and output in aseparate X-11 terminal window so that commands and output from multipleprocesses are not mixed together.

Perl on VMS supports an emulation of the forked debugger when Perl isrun on a VMS system that has X11 support installed.

To use the forked debugger, you need to have the default display set to anX-11 Server and some environment variables set that Unix expects.

The forked debugger requires the environment variable TERM to be xterm,and the environment variable DISPLAY to exist. xterm must be inlower case.

  $define TERM "xterm"
 
   $define DISPLAY "hostname:0.0"

Currently the value of DISPLAY is ignored. It is recommended that it be setto be the hostname of the display, the server and screen in Unix notation. Inthe future the value of DISPLAY may be honored by Perl instead of using thedefault display.

It may be helpful to always use the forked debugger so that script I/O isseparated from debugger I/O. You can force the debugger to be forked byassigning a value to the logical name <PERLDB_PIDS> that is not a processidentification number.

  $define PERLDB_PIDS XXXX

PERL_VMS_EXCEPTION_DEBUG

The PERL_VMS_EXCEPTION_DEBUG being defined as "ENABLE" will cause the VMSdebugger to be invoked if a fatal exception that is not otherwisehandled is raised. The purpose of this is to allow debugging ofinternal Perl problems that would cause such a condition.

This allows the programmer to look at the execution stack and variables tofind out the cause of the exception. As the debugger is being invoked asthe Perl interpreter is about to do a fatal exit, continuing the executionin debug mode is usually not practical.

Starting Perl in the VMS debugger may change the program executionprofile in a way that such problems are not reproduced.

The kill function can be used to test this functionality from withina program.

In typical VMS style, only the first letter of the value of this logicalname is actually checked in a case insensitive mode, and it is consideredenabled if it is the value "T","1" or "E".

This logical name must be defined before Perl is started.

Command line

I/O redirection and backgrounding

Perl for VMS supports redirection of input and output on the command line, using a subset of Bourne shell syntax:

<file reads stdin from file,
>file writes stdout to file,
>>file appends stdout to file,
2>file writes stderr to file,
2>>file appends stderr to file, and
2>&1 redirects stderr to stdout.

In addition, output may be piped to a subprocess, using the character '|'. Anything after this character on the command line is passed to a subprocess for execution; the subprocess takes the output of Perl as its input.

Finally, if the command line ends with '&', the entire command is run in the background as an asynchronous subprocess.

Command line switches

The following command line switches behave differently underVMS than described in perlrun. Note also that in orderto pass uppercase switches to Perl, you need to enclosethem in double-quotes on the command line, since the CRTLdowncases all unquoted strings.

On newer 64 bit versions of OpenVMS, a process setting nowcontrols if the quoting is needed to preserve the case ofcommand line arguments.

-i
If the -i switch is present but no extension for a backupcopy is given, then inplace editing creates a new version ofa file; the existing copy is not deleted. (Note that ifan extension is given, an existing file is renamed to the backupfile, as is the case under other operating systems, so it doesnot remain as a previous version under the original filename.)
-S
If the "-S" or -"S" switch is present and the scriptname does not contain a directory, then Perl translates thelogical name DCL$PATH as a searchlist, using each translationas a directory in which to look for the script. In addition,if no file type is specified, Perl looks in each directoryfor a file matching the name specified, with a blank type,a type of .pl, and a type of .com, in that order.
-u
The -u switch causes the VMS debugger to be invokedafter the Perl program is compiled, but before it hasrun. It does not create a core dump file.

Perl functions

As of the time this document was last revised, the following Perl functions were implemented in the VMS port of Perl (functions marked with * are discussed in more detail below):

 file tests*, abs, alarm, atan, backticks*, binmode*, bless,
  caller, chdir, chmod, chown, chomp, chop, chr,
  close, closedir, cos, crypt*, defined, delete, die, do, dump*, 
  each, endgrent, endpwent, eof, eval, exec*, exists, exit, exp, 
  fileno, flock  getc, getgrent*, getgrgid*, getgrnam, getlogin, getppid,
  getpwent*, getpwnam*, getpwuid*, glob, gmtime*, goto,
  grep, hex, ioctl, import, index, int, join, keys, kill*,
  last, lc, lcfirst, lchown*, length, link*, local, localtime, log, lstat, m//,
  map, mkdir, my, next, no, oct, open, opendir, ord, pack,
  pipe, pop, pos, print, printf, push, q//, qq//, qw//,
  qx//*, quotemeta, rand, read, readdir, readlink*, redo, ref, rename,
  require, reset, return, reverse, rewinddir, rindex,
  rmdir, s///, scalar, seek, seekdir, select(internal),
  select (system call)*, setgrent, setpwent, shift, sin, sleep,
  socketpair, sort, splice, split, sprintf, sqrt, srand, stat,
  study, substr, symlink*, sysread, system*, syswrite, tell,
  telldir, tie, time, times*, tr///, uc, ucfirst, umask,
  undef, unlink*, unpack, untie, unshift, use, utime*,
  values, vec, wait, waitpid*, wantarray, warn, write, y///

The following functions were not implemented in the VMS port, and calling them produces a fatal error (usually) or undefined behavior (rarely, we hope):

 chroot, dbmclose, dbmopen, fork*, getpgrp, getpriority,  
  msgctl, msgget, msgsend, msgrcv, semctl,
  semget, semop, setpgrp, setpriority, shmctl, shmget,
  shmread, shmwrite, syscall

The following functions are available on Perls compiled with Dec C5.2 or greater and running VMS 7.0 or greater:

 truncate

The following functions are available on Perls built on VMS 7.2 orgreater:

 fcntl (without locking)

The following functions may or may not be implemented, depending on what type of socket support you've built into your copy of Perl:

 accept, bind, connect, getpeername,
  gethostbyname, getnetbyname, getprotobyname,
  getservbyname, gethostbyaddr, getnetbyaddr,
  getprotobynumber, getservbyport, gethostent,
  getnetent, getprotoent, getservent, sethostent,
  setnetent, setprotoent, setservent, endhostent,
  endnetent, endprotoent, endservent, getsockname,
  getsockopt, listen, recv, select(system call)*,
  send, setsockopt, shutdown, socket

The following function is available on Perls built on 64 bit OpenVMS v8.2with hard links enabled on an ODS-5 formatted build disk. CRTL supportis in principle available as of OpenVMS v7.3-1, and better configurationsupport could detect this.

 link

The following functions are available on Perls built on 64 bit OpenVMSv8.2 and later. CRTL support is in principle available as of OpenVMSv7.3-2, and better configuration support could detect this.

   getgrgid, getgrnam, getpwnam, getpwuid,
    setgrent, ttyname

The following functions are available on Perls built on 64 bit OpenVMS v8.2and later.

   statvfs, socketpair

File tests
The tests -b, -B, -c, -C, -d, -e, -f,-o, -M, -s, -S, -t, -T, and -z work asadvertised. The return values for -r, -w, and -xtell you whether you can actually access the file; this maynot reflect the UIC-based file protections. Since real andeffective UIC don't differ under VMS, -O, -R, -W,and -X are equivalent to -o, -r, -w, and -x.Similarly, several other tests, including -A, -g, -k,-l, -p, and -u, aren't particularly meaningful underVMS, and the values returned by these tests reflect whateveryour CRTL stat() routine does to the equivalent bits in thest_mode field. Finally, -d returns true if passed a devicespecification without an explicit directory (e.g. DUA1:), aswell as if passed a directory.
There are DECC feature logical names AND ODS-5 volume attributes thatalso control what values are returned for the date fields.
Note: Some sites have reported problems when using the file-accesstests (-r, -w, and -x) on files accessed via DEC's DFS.Specifically, since DFS does not currently provide access to theextended file header of files on remote volumes, attempts toexamine the ACL fail, and the file tests will return false,with $! indicating that the file does not exist. You canuse stat on these files, since that checks UIC-based protectiononly, and then manually check the appropriate bits, as defined byyour C compiler's stat.h, in the mode value it returns, if youneed an approximation of the file's protections.
backticks
Backticks create a subprocess, and pass the enclosed stringto it for execution as a DCL command. Since the subprocess iscreated directly via lib$spawn(), any valid DCL command stringmay be specified.
binmode FILEHANDLE
The binmode operator will attempt to insure that no translationof carriage control occurs on input from or output to this filehandle.Since this involves reopening the file and then restoring itsfile position indicator, if this function returns FALSE, theunderlying filehandle may no longer point to an open file, or maypoint to a different position in the file than before binmodewas called.
Note that binmode is generally not necessary when using normalfilehandles; it is provided so that you can control I/O to existingrecord-structured files when necessary. You can also use thevmsfopen function in the VMS::Stdio extension to gain finercontrol of I/O to files and devices with different record structures.
crypt PLAINTEXT, USER
The crypt operator uses the sys$hash_password systemservice to generate the hashed representation of PLAINTEXT.If USER is a valid username, the algorithm and salt valuesare taken from that user's UAF record. If it is not, thenthe preferred algorithm and a salt of 0 are used. Thequadword encrypted value is returned as an 8-character string.
The value returned by crypt may be compared againstthe encrypted password from the UAF returned by the getpw*functions, in order to authenticate users. If you'regoing to do this, remember that the encrypted password inthe UAF was generated using uppercase username andpassword strings; you'll have to upcase the arguments tocrypt to insure that you'll get the proper value:
```
 sub validate_passwd {
  my($user,$passwd) = @_;
  my($pwdhash);
  if ( !($pwdhash = (getpwnam($user))[1]) ||
    $pwdhash ne crypt("\U$passwd","\U$name") ) {
  intruder_alert($name);
  }
  return 1;
  }
 
```
die
die will force the native VMS exit status to be an SS$_ABORT codeif neither of the $! or $? status values are ones that would causethe native status to be interpreted as being what VMS classifies asSEVERE_ERROR severity for DCL error handling.
When PERL_VMS_POSIX_EXIT is active (see $? below), the native VMS exitstatus value will have either one of the $! or $? or $^E orthe Unix value 255 encoded into it in a way that the effective originalvalue can be decoded by other programs written in C, including Perland the GNV package. As per the normal non-VMS behavior of die ifeither $! or $? are non-zero, one of those values will beencoded into a native VMS status value. If both of the Unix statusvalues are 0, and the $^E value is set one of ERROR or SEVERE_ERRORseverity, then the $^E value will be used as the exit code as is.If none of the above apply, the Unix value of 255 will be encoded intoa native VMS exit status value.
Please note a significant difference in the behavior of die inthe PERL_VMS_POSIX_EXIT mode is that it does not force a VMSSEVERE_ERROR status on exit. The Unix exit values of 2 through255 will be encoded in VMS status values with severity levels ofSUCCESS. The Unix exit value of 1 will be encoded in a VMS statusvalue with a severity level of ERROR. This is to be compatible withhow the VMS C library encodes these values.
The minimum severity level set by die in PERL_VMS_POSIX_EXIT modemay be changed to be ERROR or higher in the future depending on the results of testing and further review.
See $? for a description of the encoding of the Unix value toproduce a native VMS status containing it.
dump
Rather than causing Perl to abort and dump core, the dumpoperator invokes the VMS debugger. If you continue toexecute the Perl program under the debugger, control willbe transferred to the label specified as the argument todump, or, if no label was specified, back to thebeginning of the program. All other state of the program(e.g. values of variables, open file handles) are notaffected by calling dump.
exec LIST
A call to exec will cause Perl to exit, and to invoke the commandgiven as an argument to exec via lib$do_command. If theargument begins with '@' or '$' (other than as part of a filespec),then it is executed as a DCL command. Otherwise, the first token onthe command line is treated as the filespec of an image to run, andan attempt is made to invoke it (using .Exe and the processdefaults to expand the filespec) and pass the rest of exec'sargument to it as parameters. If the token has no file type, andmatches a file with null type, then an attempt is made to determinewhether the file is an executable image which should be invokedusing MCR or a text file which should be passed to DCL as acommand procedure.
fork
While in principle the fork operator could be implemented via(and with the same rather severe limitations as) the CRTL vfork()routine, and while some internal support to do just that is inplace, the implementation has never been completed, making forkcurrently unavailable. A true kernel fork() is expected in afuture version of VMS, and the pseudo-fork based on interpreterthreads may be available in a future version of Perl on VMS (seeperlfork). In the meantime, use system, backticks, or pipedfilehandles to create subprocesses.
getpwent
getpwnam
getpwuid
These operators obtain the information described in perlfunc,if you have the privileges necessary to retrieve the named user'sUAF information via sys$getuai. If not, then only the $name,$uid, and $gid items are returned. The $dir item containsthe login directory in VMS syntax, while the $comment itemcontains the login directory in Unix syntax. The $gcos itemcontains the owner field from the UAF record. The $quotaitem is not used.
gmtime
The gmtime operator will function properly if you have aworking CRTL gmtime() routine, or if the logical nameSYS$TIMEZONE_DIFFERENTIAL is defined as the number of secondswhich must be added to UTC to yield local time. (This logicalname is defined automatically if you are running a version ofVMS with built-in UTC support.) If neither of these cases istrue, a warning message is printed, and undef is returned.
kill
In most cases, kill is implemented via the undocumented systemservice $SIGPRC, which has the same calling sequence as $FORCEX, butthrows an exception in the target process rather than forcing it to call$EXIT. Generally speaking, kill follows the behavior of theCRTL's kill() function, but unlike that function can be called fromwithin a signal handler. Also, unlike the kill in some versions ofthe CRTL, Perl's kill checks the validity of the signal passed in andreturns an error rather than attempting to send an unrecognized signal.
Also, negative signal values don't do anything special underVMS; they're just converted to the corresponding positive value.
qx//
See the entry on backticks above.
select (system call)
If Perl was not built with socket support, the system callversion of select is not available at all. If socketsupport is present, then the system call version ofselect functions only for file descriptors attachedto sockets. It will not provide information about regularfiles or pipes, since the CRTL select() routine does notprovide this functionality.
stat EXPR
Since VMS keeps track of files according to a different schemethan Unix, it's not really possible to represent the file's IDin the st_dev and st_ino fields of a struct stat. Perltries its best, though, and the values it uses are pretty unlikelyto be the same for two different files. We can't guarantee this,though, so caveat scriptor.
system LIST
The system operator creates a subprocess, and passes its arguments to the subprocess for execution as a DCL command. Since the subprocess is created directly via lib$spawn(), any valid DCL command string may be specified. If the string begins with'@', it is treated as a DCL command unconditionally. Otherwise, ifthe first token contains a character used as a delimiter in filespecification (e.g. : or ]), an attempt is made to expand itusing a default type of .Exe and the process defaults, and ifsuccessful, the resulting file is invoked via MCR. This allows youto invoke an image directly simply by passing the file specificationto system, a common Unixish idiom. If the token has no file type,and matches a file with null type, then an attempt is made todetermine whether the file is an executable image which should beinvoked using MCR or a text file which should be passed to DCLas a command procedure.
If LIST consists of the empty string, system spawns aninteractive DCL subprocess, in the same fashion as typingSPAWN at the DCL prompt.
Perl waits for the subprocess to complete before continuingexecution in the current process. As described in perlfunc,the return value of system is a fake "status" which followsPOSIX semantics unless the pragma use vmsish 'status' is ineffect; see the description of $? in this document for more detail.
time
The value returned by time is the offset in seconds from01-JAN-1970 00:00:00 (just like the CRTL's times() routine), in orderto make life easier for code coming in from the POSIX/Unix world.
times
The array returned by the times operator is divided up according to the same rules the CRTL times() routine. Therefore, the "system time" elements will always be 0, since there is no difference between "user time" and "system" time under VMS, and the time accumulated by a subprocess may or may not appear separately in the "child time" field, depending on whether times() keeps track of subprocesses separately. Noteespecially that the VAXCRTL (at least) keeps track only ofsubprocesses spawned using fork() and exec(); it will notaccumulate the times of subprocesses spawned via pipes, system(),or backticks.
unlink LIST
unlink will delete the highest version of a file only; inorder to delete all versions, you need to say
```
 1 while unlink LIST;
 
```
You may need to make this change to scripts written for aUnix system which expect that after a call to unlink,no files with the names passed to unlink will exist.(Note: This can be changed at compile time; if youuse Config and $Config{'d_unlink_all_versions'} isdefine, then unlink will delete all versions of afile on the first call.)
unlink will delete a file if at all possible, even if itrequires changing file protection (though it won't try tochange the protection of the parent directory). You can tellwhether you've got explicit delete access to a file by using theVMS::Filespec::candelete operator. For instance, in orderto delete only files to which you have delete access, you couldsay something like
```
 sub safe_unlink {
  my($file,$num);
  foreach $file (@_) {
  next unless VMS::Filespec::candelete($file);
  $num += unlink $file;
  }
  $num;
  }
 
```
(or you could just use VMS::Stdio::remove, if you've installedthe VMS::Stdio extension distributed with Perl). If unlink has tochange the file protection to delete the file, and you interrupt itin midstream, the file may be left intact, but with a changed ACLallowing you delete access.
This behavior of unlink is to be compatible with POSIX behaviorand not traditional VMS behavior.
utime LIST
This operator changes only the modification time of the file (VMS revision date) on ODS-2 volumes and ODS-5 volumes without access dates enabled. On ODS-5 volumes with access dates enabled, the true access time is modified.
waitpid PID,FLAGS
If PID is a subprocess started by a piped open() (see open), waitpid will wait for that subprocess, and return its final statusvalue in $?. If PID is a subprocess created in some other way (e.g.SPAWNed before Perl was invoked), waitpid will simply check once persecond whether the process has completed, and return when it has. (IfPID specifies a process that isn't a subprocess of the current process,and you invoked Perl with the -w switch, a warning will be issued.)
Returns PID on success, -1 on error. The FLAGS argument is ignoredin all cases.

Perl variables

The following VMS-specific information applies to the indicated"special" Perl variables, in addition to the general informationin perlvar. Where there is a conflict, this informationtakes precedence.

%ENV
The operation of the %ENV array depends on the translationof the logical name PERL_ENV_TABLES. If defined, it shouldbe a search list, each element of which specifies a locationfor %ENV elements. If you tell Perl to read or set theelement $ENV{name}, then Perl uses the translations ofPERL_ENV_TABLES as follows:
- CRTL_ENV
  This string tells Perl to consult the CRTL's internal environarray of key-value pairs, using name as the key. In most cases,this contains only a few keys, but if Perl was invoked via the Cexec[lv]e() function, as is the case for CGI processing by someHTTP servers, then the environ array may have been populated bythe calling program.
- CLISYM_[LOCAL]
  A string beginning with CLISYM_tells Perl to consult the CLI'ssymbol tables, using name as the name of the symbol. When readingan element of %ENV, the local symbol table is scanned first, followedby the global symbol table.. The characters following CLISYM_ aresignificant when an element of %ENV is set or deleted: if thecomplete string is CLISYM_LOCAL, the change is made in the localsymbol table; otherwise the global symbol table is changed.
- Any other string
  If an element of PERL_ENV_TABLES translates to any other string,that string is used as the name of a logical name table, which isconsulted using name as the logical name. The normal searchorder of access modes is used.
PERL_ENV_TABLES is translated once when Perl starts up; any changesyou make while Perl is running do not affect the behavior of %ENV.If PERL_ENV_TABLES is not defined, then Perl defaults to consultingfirst the logical name tables specified by LNM$FILE_DEV, and thenthe CRTL environ array.
In all operations on %ENV, the key string is treated as if it were entirely uppercase, regardless of the case actually specified in the Perl expression.
When an element of %ENV is read, the locations to whichPERL_ENV_TABLES points are checked in order, and the valueobtained from the first successful lookup is returned. If thename of the %ENV element contains a semi-colon, it andany characters after it are removed. These are ignored whenthe CRTL environ array or a CLI symbol table is consulted.However, the name is looked up in a logical name table, thesuffix after the semi-colon is treated as the translation indexto be used for the lookup. This lets you look up successive valuesfor search list logical names. For instance, if you say
```
   $  Define STORY  once,upon,a,time,there,was
    $  perl -e "for ($i = 0; $i <= 6; $i++) " -
    _$ -e "{ print $ENV{'story;'.$i},' '}"
 
```
Perl will print ONCE UPON A TIME THERE WAS, assuming, of course,that PERL_ENV_TABLES is set up so that the logical name storyis found, rather than a CLI symbol or CRTL environ element withthe same name.
When an element of %ENV is set to a defined string, thecorresponding definition is made in the location to which thefirst translation of PERL_ENV_TABLES points. If this causes alogical name to be created, it is defined in supervisor mode.(The same is done if an existing logical name was defined inexecutive or kernel mode; an existing user or supervisor modelogical name is reset to the new value.) If the value is an emptystring, the logical name's translation is defined as a single NUL(ASCII 00) character, since a logical name cannot translate to azero-length string. (This restriction does not apply to CLI symbolsor CRTL environ values; they are set to the empty string.)An element of the CRTL environ array can be set only if yourcopy of Perl knows about the CRTL's setenv() function. (This ispresent only in some versions of the DECCRTL; check $Config{d_setenv}to see whether your copy of Perl was built with a CRTL that has thisfunction.)
When an element of %ENV is set to undef,the element is looked up as if it were being read, and if it isfound, it is deleted. (An item "deleted" from the CRTL environarray is set to the empty string; this can only be done if yourcopy of Perl knows about the CRTL setenv() function.) Usingdelete to remove an element from %ENV has a similar effect,but after the element is deleted, another attempt is made tolook up the element, so an inner-mode logical name or a name inanother location will replace the logical name just deleted.In either case, only the first value found searching PERL_ENV_TABLESis altered. It is not possible at present to define a search listlogical name via %ENV.
The element $ENV{DEFAULT} is special: when read, it returnsPerl's current default device and directory, and when set, itresets them, regardless of the definition of PERL_ENV_TABLES.It cannot be cleared or deleted; attempts to do so are silentlyignored.
Note that if you want to pass on any elements of theC-local environ array to a subprocess which isn'tstarted by fork/exec, or isn't running a C program, youcan "promote" them to logical names in the currentprocess, which will then be inherited by all subprocesses,by saying
```
 foreach my $key (qw[C-local keys you want promoted]) {
  my $temp = $ENV{$key}; # read from C-local array
  $ENV{$key} = $temp; # and define as logical name
  }
 
```
(You can't just say $ENV{$key} = $ENV{$key}, since thePerl optimizer is smart enough to elide the expression.)
Don't try to clear %ENV by saying %ENV = ();, it will throwa fatal error. This is equivalent to doing the following from DCL:
```
 DELETE/LOGICAL *
 
```
You can imagine how bad things would be if, for example, the SYS$MANAGERor SYS$SYSTEM logical names were deleted.
At present, the first time you iterate over %ENV usingkeys, or values, you will incur a time penalty as alllogical names are read, in order to fully populate %ENV.Subsequent iterations will not reread logical names, so theywon't be as slow, but they also won't reflect any changesto logical name tables caused by other programs.
You do need to be careful with the logical names representingprocess-permanent files, such as SYS$INPUT and SYS$OUTPUT.The translations for these logical names are prepended with atwo-byte binary value (0x1B 0x00) that needs to be stripped offif you wantto use it. (In previous versions of Perl it wasn'tpossible to get the values of these logical names, as the nullbyte acted as an end-of-string marker)
$!
The string value of $! is that returned by the CRTL'sstrerror() function, so it will include the VMS message forVMS-specific errors. The numeric value of $! is thevalue of errno, except if errno is EVMSERR, in whichcase $! contains the value of vaxc$errno. Setting $!always sets errno to the value specified. If this value isEVMSERR, it also sets vaxc$errno to 4 (NONAME-F-NOMSG), sothat the string value of $! won't reflect the VMS errormessage from before $! was set.
$^E
This variable provides direct access to VMS status valuesin vaxc$errno, which are often more specific than thegeneric Unix-style error messages in $!. Its numeric valueis the value of vaxc$errno, and its string value is thecorresponding VMS message string, as retrieved by sys$getmsg().Setting $^E sets vaxc$errno to the value specified.
While Perl attempts to keep the vaxc$errno value to be current, iferrno is not EVMSERR, it may not be from the current operation.
$?
The "status value" returned in $? is synthesized from theactual exit status of the subprocess in a way that approximatesPOSIX wait(5) semantics, in order to allow Perl programs toportably test for successful completion of subprocesses. Thelow order 8 bits of $? are always 0 under VMS, since thetermination status of a process may or may not have beengenerated by an exception.
The next 8 bits contain the termination status of the program.
If the child process follows the convention of C programscompiled with the _POSIX_EXIT macro set, the status value willcontain the actual value of 0 to 255 returned by that programon a normal exit.
With the _POSIX_EXIT macro set, the Unix exit value of zero isrepresented as a VMS native status of 1, and the Unix valuesfrom 2 to 255 are encoded by the equation:
```
   VMS_status = 0x35a000 + (unix_value * 8) + 1.
 
```
And in the special case of Unix value 1 the encoding is:
```
   VMS_status = 0x35a000 + 8 + 2 + 0x10000000.
 
```
For other termination statuses, the severity portion of thesubprocess's exit status is used: if the severity was success orinformational, these bits are all 0; if the severity waswarning, they contain a value of 1; if the severity waserror or fatal error, they contain the actual severity bits,which turns out to be a value of 2 for error and 4 for severe_error.Fatal is another term for the severe_error status.
As a result, $? will always be zero if the subprocess's exitstatus indicated successful completion, and non-zero if awarning or error occurred or a program compliant with encoding_POSIX_EXIT values was run and set a status.
How can you tell the difference between a non-zero status that isthe result of a VMS native error status or an encoded Unix status?You can not unless you look at the ${^CHILD_ERROR_NATIVE} value.The ${^CHILD_ERROR_NATIVE} value returns the actual VMS status valueand check the severity bits. If the severity bits are equal to 1,then if the numeric value for $? is between 2 and 255 or 0, then$? accurately reflects a value passed back from a Unix application.If $? is 1, and the severity bits indicate a VMS error (2), then$? is from a Unix application exit value.
In practice, Perl scripts that call programs that return _POSIX_EXITtype status values will be expecting those values, and programs thatcall traditional VMS programs will either be expecting the previousbehavior or just checking for a non-zero status.
And success is always the value 0 in all behaviors.
When the actual VMS termination status of the child is an error,internally the $! value will be set to the closest Unix errnovalue to that error so that Perl scripts that test for errormessages will see the expected Unix style error message insteadof a VMS message.
Conversely, when setting $? in an END block, an attempt is madeto convert the POSIX value into a native status intelligible tothe operating system upon exiting Perl. What this boils down tois that setting $? to zero results in the generic success valueSS$_NORMAL, and setting $? to a non-zero value results in thegeneric failure status SS$_ABORT. See also exit in perlport.
With the PERL_VMS_POSIX_EXIT logical name defined as "ENABLE",setting $? will cause the new value to be encoded into $^Eso that either the original parent or child exit status values 0 to 255 can be automatically recovered by C programs expecting_POSIX_EXIT behavior. If both a parent and a child exit value arenon-zero, then it will be assumed that this is actually a VMS nativestatus value to be passed through. The special value of 0xFFFF isalmost a NOOP as it will cause the current native VMS status in theC library to become the current native Perl VMS status, and is handledthis way as it is known to not be a valid native VMS status value.It is recommend that only values in the range of normal Unix parent orchild status numbers, 0 to 255 are used.
The pragma use vmsish 'status' makes $? reflect the actual VMS exit status instead of the default emulation of POSIX status described above. This pragma also disables the conversion ofnon-zero values to SS$_ABORT when setting $? in an ENDblock (but zero will still be converted to SS$_NORMAL).
Do not use the pragma use vmsish 'status' with PERL_VMS_POSIX_EXITenabled, as they are at times requesting conflicting actions and theconsequence of ignoring this advice will be undefined to allow futureimprovements in the POSIX exit handling.
In general, with PERL_VMS_POSIX_EXIT enabled, more detailed informationwill be available in the exit status for DCL scripts or other native VMS tools,and will give the expected information for Posix programs. It has not beenmade the default in order to preserve backward compatibility.
N.B. Setting DECC$FILENAME_UNIX_REPORT implicitly enables PERL_VMS_POSIX_EXIT.
$|
Setting $| for an I/O stream causes data to be flushedall the way to disk on each write (i.e. not just tothe underlying RMS buffers for a file). In other words,it's equivalent to calling fflush() and fsync() from C.

Standard modules with VMS-specific differences

SDBM_File

SDBM_File works properly on VMS. It has, however, one minordifference. The database directory file created has a .sdbm_dirextension rather than a .dir extension. .dir files are VMS filesystemdirectory files, and using them for other purposes could cause unacceptableproblems.

Revision date

Please see the git repository for revision history.

AUTHOR

Charles Bailey [email protected] Berry [email protected] Sugalski [email protected] Malmberg [email protected]

Source : perldoc.perl.org - Official documentation for the Perl programming language
Site maintained by Jon Allen (JJ) See the project page for more details
Documentation maintained by the Perl 5 Porters

(Sebelumnya) Building and installing Perl f ...

Perl for Stratus VOS (Berikutnya)

Link Bermanfaat

✺ Kuliah Online ✺ Kode Pos ✺ Kuliah Umum ✺ Kuliah Kelas Ekstensi ✺ Kuliah Jarak Jauh ✺ Kuliah Gratis Beasiswa S1 S2 ✺ Kampus Merdeka Belajar

eduNitas • Konsultan Pendidikan Tinggi (KPT) • PT. Gilland Ganesha • Gilland Group