Hi Peter and John, I have not had a look at the logicals piece in quite a while. I ran into a design issue, because I felt that the interface needed to be changed, and I got stuck worrying about how to make the change so it wouldn't break earlier users...
Unfortunately, I probably can't get back to this for another month or two. I would like to return to this, as well as an assortment of VMS:: modules. I use them, and I know what is needed for several improvements, and updates to the take advantage of current versions of perl and VMS. I also have on my plate the vmsperl website maintenance, and you all know I've dropped that. Hopefully, I will get back to all of this before the end of November. Finally, I do hope to set up vmsperl.com as a useful resource. Good intentions and all that. Best, Carl Friedberg Comet & Company 165 William St 9 NY NY 10038 www.comets.com (212) 233-5470 > -----Original Message----- > From: Peter Prymmer [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 27, 2005 5:02 PM > To: John E. Malmberg > Cc: Craig A. Berry; Nicholas Clark; perl5-porters@perl.org; > vmsperl@perl.org > Subject: Re: Proposed vmsish changes. > > "John E. Malmberg" <[EMAIL PROTECTED]> wrote on 09/26/2005 02:45:51 PM: > > > 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. > > There is one: VMS::Logical, but it is not on CPAN (yet). > Carl Friedberg adopted it and was going to put it there. > I can email you a copy if you'd like to see it. > > > 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. > > Indeed, and that also makes it tricky to add run time feature > getters to > an existing pragmatic module. > > > 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. > > Consider the DCL difference between commands such as: > > set file /version_limit=0 <filespec> > set file /version_limit=32767 <filespec> > > I would not be surprised if a future update to RMS raises > the value 32767 by some amount. What happens to a binary perl > built on VMS V 8.x then run on VMS V 8.y where y > x? > > So what is obvious and what is subject to debate? What is subject > to vendor upgrades? Some parameters on some operating systems are at > the whim of the OS vendor. Negative numbers may have special meaning > for certain parameters and be illegal for others. Octal, decimal, or > hexadecimal numbers may or may not be allowed,... > > Peter Prymmer > >
