At 12:53 AM -0400 9/22/05, John E. Malmberg wrote: >VMS has a number of features that vary with the version of VMS, and also >features that can be enabled. > >Perl scripts running on VMS may need to know what features are enabled, or to >enable the features.
It would be great progress to have access from Perl to all of the goodies you mention. > >It appears to me that the vmsish module is the place to put these if I can >figure out how to get them all implemented. I would suggest figuring out how to get them all implemented as the first challenge and then how to access them from Perl as the second. For a number of reasons, a pragmatic module may or may not be the way to go. There are some things you should be aware of about how pragmas work. A pragma is a way of passing hints to the Perl compiler at the time it is compiling your script. It is also lexically scoped, which means that a value set in an inner scope needs to revert to the outer scope value when you exit the inner scope. A pragma implementation is worth considering for the CRTL features, though an extension might be just as good. For merely fetching global values like DCL command-line length, they should be made available in %Config if they are set at build time, or via some extension if they can vary at run-time. In some cases, an appropriate extension namespace may already exist. For example, if something is available from the native $GETSYI, it belongs in VMS::System, if from $GETJPI then VMS::Process. > >In one at least one case, I am not sure how to name the function and implement >them. > >Currently there are two "exit" modes, VMS mode, and a default mode that >returns either a success SS$_NORMAL, or SS$_ABORT for a failure. > >Another "exit" mode is needed that encodes the UNIX like status into a VMS >status code in the way that the GNV Bash shell and other C program would >expect it to be. > snip >Possibly it could be named: vmsish::use_posix_exit($value); Well, it could alternately be use vmsish 'posix_exit'; or use vmsish 'noposix_exit'; and this would have to be wired to the existing C<use vmsish 'exit';> so that setting one clears the other and vice versa. > >The other methods are: > > vmsish::decc_feature_get_index($name); > vmsish::decc_feature_get_name($index); > vmsish::decc_feature_get_value($name, $mode); > vmsish::decc_feature_set_value($name, $mode, $value); > vmsish::decc_feature_deed_to_child($value); > >The decc_feature_* methods are wrappers for the C library calls of the same >name, just exposed to make them easier for Perl scripts to use them. Except >for the decc_feature_deed_to child. All Perl scripts would need to reference >or set the C features through these methods, because internally Perl would >could cache them. > >Also some decc_feature settings have side effects on other DECC features. > >The decc_feature_deed_to_child would make any DECC features set after that >point visible to (inherited by) any child processes that used the C library. >For VMS prior to 7.3, the child processes will always inherit the settings. > >It is expected that in most cases further wrappers will be used in other Perl >modules to simplify the use of these settings, but by exposing the "raw" >interface here, it allows those wrappers to be written in Perl instead of in C. > >For example, a UNIX_FILENAME_REPORT method could be exposed in File::Spec::VMS >that actually just calls these vmsish methods under the covers. > > vmsish::dcl_present; > >Returns if the DCL shell is present. Currently Perl probably will not work >well if it was not, but food for thought for the future. > > vmsish::dcl_extended_syntax($value); > >Returns/sets if the DCL shell is set to extended syntax mode. Setting this >mode through this interface will also cause interaction with the obvious DECC >features that this complements. > > vmsish::dcl_command_line_length; > >The length of a single line DCL command. Currently 255 bytes, future 4096 >bytes on 64 bit platforms past 7.3-2. > > vmsish::dcl_command_file_line_length; > >The length of line in a DCL command file. Should be 1024 bytes for >traditional, but I suspect that the internal C code in Perl can only deal with >255 bytes. With 64 bit platforms past 7.3-2 it should be 8192. > > vmsish::dcl_symbol_value_length; > >The size that can be stored in a DCL symbol, should be 1024 bytes for VAX and >64 bit VMS before 7.3-2, and 8192 otherwise, but again, the internal C code in >Perl probably is limited to 255 characters. > > vmsish::dcl_token_length; > >This is currently limited to 255 bytes. > > vmsish::logical_name_value_length; > >This is currently limited to 255 bytes. > > vmsish::vms_pathname_length; > >The maximum length of a pathname including device name and directory names and >version number in string form. Currently limited internally in Perl to 255 >bytes. Future is 4095 bytes. This includes "quoting" characters. Internal >storage after the quoting is resolved is limited to 1024 bytes. > > vmsish::unix_pathname_length; > >The maximum length of a UNIX pathname from "/". In a UNIX pathname, the >quoting characters are not present on the external representation so it is >limited to 1024 characters. > > vmsish::vms_filename_length; > >The length of an 8 bit character set file name and extension with out the >directory or device component and including the version string. Perl currently >reserves 255 characters for this, and that is unchanged. On ODS-2 file >systems, only about 86 characters can really be used. On ODS-5 systems, 253 >characters can be used. > > vmsish::wide_filename_length; > >The length of a UCS-2 encoded filename. Currently 116 16 bit characters. I >really do not know what Perl would do with one of these, but since I was >looking up the limits, it seemed some thing to add. > >-John >[EMAIL PROTECTED] >Personal Opinion Only -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
