Peter Prymmer wrote:
"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).
You all have convinced me that most of this stuff does not belong added
to vmsish. Setting/retrieving the posix_exit and the
delete_all_versions settings may still be a fit for the vmsish module.
For the file specification related stuff, it appears that VMS::Filespec
is the place to put it for logical reasons, and also a place to expose a
few of the DECC feature set/test functions.
The default routines added to the Filespec.pm will only return values
that are proper for classic and older expected VMS behavior and not
allow them to be modified.
Just about every other script that needs a change to support ODS-5 is
already referencing routines in VMS::Filespec, and most of the behavior
changes are in Filespec, cwd, and pathtools, and MakeMaker.
It appears that the routines that need to know about the newer VMS
features can do a version test on Filespec.pm to see if the routines are
supported and then use those routines to set their VMS behavior.
That way updated modules can still be used with older modules, with the
restriction that unless all modules are up to the current revision, the
newer VMS behaviors will not work correctly, the same as they do not
work correctly now.
The new routines in Filespec.pm will be overridden by VMS.C when it
supports those features, otherwise what they return will match what is
expected with older Perls.
If a VMS::Config extension is created, it could have the some of the
same methods with the same over rides.
An update to VMS::Filespec is something that I can do easily and I think
in a manner that allows forward and backward compatibility.
I should have a sample update to VMS::Filespec.pm available for
inspection soon.
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.
My desire is to be able to activate the ODS-5 support and re-run all the
Perl tests and have them produce the correct results, and also to be
able to set the VMS CRTL in a report filenames as UNIX mode, and re-run
all the tests again and have them still work.
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 have no plans to add any xs extensions for this. What I have not
determined is if there is a desire to emulate any of the newer VMS
behaviors on non-VMS platforms. If not, then default values can be
returned for all routines, and attempting to change them will simply
return that the value was not changed.
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.
The reason I want to use an existing VMS:: module is that the other
places that need to see these changes are are probably already including
it, so that the changes to them are less disruptive.
Early in the module where it is testing for $^O, I can add the
additional feature tests that are needed.
It may be proper later on to add a new xs extension. vms.c can overlay
that as well as continuing to do so for VMS::Filespec.
I have not notice any modules for manipulating logical names, and have
also noticed that while the $ENV{} allows this, the $ENV{} features that
are documented on VMS will make changes in the logical name tables that
would be very surprising to someone that did not read it in detail.
<snip>
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.
The problem is that hindsight is 20/20. There is no way to predict what
features are important to have in such a module at the time it is
urgently needed to be available.
Perhaps an os_settings.pm module with methods that can be overridden or
added to just like pathtools does now.
I would expect such a module to be very volatile for a while until
everything that needs to be there gets moved there. After all, until
there is a conflict, no one will know that something should be updated.
And each setting would really have at least three possible values:
Default setting.
Initial setting.
Minimum setting that is always available.
Current setting.
Maximum limit on what could be set.
Default is what the environment naturally supplies before any
initialization files or scripts or environment variables.
Initial is after any initialization scripts, files or environment
variables have been processed.
The others should be obvious.
Making such a think work would require that as platform dependent
features are found that an attempt be made to quantify them as an
os_setting, which may require updating the os_setting module in addition
to the other module.
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.
I will take a look at that for storing the length information.
-John
[EMAIL PROTECTED]
Personal Opinion Only
