"John E. Malmberg" <[EMAIL PROTECTED]> wrote on 09/22/2005 05:15:17 PM:
> Peter Prymmer wrote:
>
> : Much (not all) of this information sounds like it might do better
> : to reside in a non pragmatic module with a name like VMS::Config
> : or VMS::FeatureSet; rather than the pragmatic module intended to
> : alter run time behavior of a script and its loaded modules.
>
> It also needs to always be a part of the VMS Perl distribution after
> it gets created.
There is precedent for just such a beast: VMS::Stdio started out
as a separately downloaded distribution from CPAN. It offers
access to the ellipsis in the VMS fopen() prototype.
It is very useful to RMS programmers, and was eventually
folded into perl. It is still downloadable from CPAN for folks
who might want to install it into an older perl installation
(perhaps they rely on one that was built before VMS::Stdio
became a part of the standard perl installation).
> These are needed to fix things that are "broken" now and being worked
> around.
>
> I have a lot of "fixes" that depend on a few Perl scripts and a few
> tests having access to a subset of this information.
I think your assertion that you need switching depending on VMS
specific things like ODS-2 versus ODS-5 to ship with perl is
your desire to alter perl's own tests. That too can be done
after a VMS::Config extension is released.
It used to be the case that a script that had a:
use vmsish;
statement in it could run on Unix (I hope that is still true since it
fosters cross platform perl scripting). If that statement now
needs to load an xs extension that calls into a bunch of sys$*()
and lib$*() functions then it won't run on a non-VMS platform too well
(unless you take on the added burden of making a perl extension that
builds on all perl platforms and returns reasonable values for what you
need
in you test script modifications).
> I already pretty much know how to implement most of them, and how to
> get Perl to access them from copying other things.
>
> What I am not sure of is where to put them.
I have recommended VMS::Config and VMS::FeatureSet as possible
namespaces to use. You might wish to use something else.
VMS::* is a good pattern to use for the name that you eventually adopt.
> I do not know how to add items to %Config.
We can help on vmsperl. I have some more suggestions below.
> >>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);
>
> These need to be visible to many of the modules that are doing VMS
> specific file name manipulation, or testing POSIX compliance.
>
> Think of these as more primitive operations that allow modules like
> pathtools, filespec, and cwd to work more correctly than methods that
> the typical Perl script would need to know about. In fact I would
> recommend that most Perl scripts not use these unless they had no other
> choice.
>
> For practical use, there needs to be other methods on top of these to
> make them more usable.
>
> Right now where a Perl script is doing a test for ($^O eq 'VMS'), it may
> need to be making a test of to see if also UNIX filename mode is active.
> If so, it may not want to take the VMS behavior.
The inadequacy of $^O has long been recognized by the perl5-porters.
Some of the proposals to address it have included:
1. a new variable %^O that would contain a hash with more
information (not ever imlemented as far as I know)
2. A "more dynamic" Config module for use with C<use Config;>
equipped scripts that was thought to help out with other OS-es
multiple file system support (analogous to the ODS-2 vs ODS-5
conundrum on VMS). Such scripts could be expected to run slower.
Jarkko Hietaniemi was the advocate of this approach, but I do not
think it got too far.
But something that starts out by exploiting perl's modular
architecture can be folded into perl itself eventually if the
need is agreed upon by relevant persons.
> >> vmsish::dcl_command_line_length;
> >> vmsish::dcl_command_file_line_length;
> >> vmsish::dcl_symbol_value_length;
> >> vmsish::dcl_token_length;
> >> vmsish::logical_name_value_length;
> >> vmsish::vms_pathname_length;
> >> vmsish::unix_pathname_length;
> >> vmsish::vms_filename_length;
> >> vmsish::wide_filename_length;
>
> These can be config time values. Is there some appropriate
> uninitialized equivalent config values that I could set?
>
> Or can someone help me with adding them to the config?
There is a document on the web that might be useful to read:
http://pvhp.best.vwh.net/vms/configure_com_faq.html
it is admittedly a little old and out of date.
Peter Prymmer
