|
|
|
|
|
|
| Author |
Message |
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
 Posted: Sun Apr 02, 2006 9:51 pm Post subject:
[patch@27669] rmsexpand/rmscopy update
|
|
|
The ODS-2 only version of mp_do_rmsexpand() was missing some updates
that were needed for using it to in place of vmsify() where it makes
sure that the output file would fit in 255 characters.
Instead of trying to keep it in sync with the ODS-5 variant, use macros
to make the one routine handle both cases.
Same thing done with RMSCOPY for consistency.
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
 |
Craig A. Berry
*nix forums Guru Wannabe
Joined: 27 May 2005
Posts: 143
|
| Posted: Sun Apr 02, 2006 10:22 pm Post subject:
Re: [patch@27669] rmsexpand/rmscopy update
|
|
|
John E. Malmberg wrote:
| Quote: | -#if __CRTL_VER >= 70000000 /* FIXME to earliest version */
+#if __CRTL_VER >= 70300000 /* FIXME to earliest version */
#include <efndef.h
#define NO_EFN EFN$C_ENF
|
Why require 7.3 for this? I think it really did come along in 7.0,
didn't it?
| Quote: | int
Perl_rmscopy(pTHX_ const char *spec_in, const char *spec_out, int preserve_dates)
{
|
This is only tangentially related, but I've often wondered whether we
should replace the RMS block transfers with something else, such as the
BACKUP API, or $IO_PERFORM calls. Or at least do a chain of $QIOs so we
don't wait until each write completes before initiating the next read
and vice versa. Anyone have experience comparing the different
approaches? Anyone have code to contribute? |
|
| Back to top |
|
|
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Mon Apr 03, 2006 12:12 am Post subject:
Re: [patch@27669] rmsexpand/rmscopy update
|
|
|
Craig A. Berry wrote:
| Quote: |
John E. Malmberg wrote:
-#if __CRTL_VER >= 70000000 /* FIXME to earliest version */
+#if __CRTL_VER >= 70300000 /* FIXME to earliest version */
#include <efndef.h
#define NO_EFN EFN$C_ENF
Why require 7.3 for this? I think it really did come along in 7.0,
didn't it?
|
I missed incorporating your change to my last patch on this. Yes, it
should be 7.0.
| Quote: | int
Perl_rmscopy(pTHX_ const char *spec_in, const char *spec_out, int
preserve_dates)
{
This is only tangentially related, but I've often wondered whether we
should replace the RMS block transfers with something else, such as the
BACKUP API, or $IO_PERFORM calls. Or at least do a chain of $QIOs so we
don't wait until each write completes before initiating the next read
and vice versa. Anyone have experience comparing the different
approaches? Anyone have code to contribute?
|
The backup API will copy all versions of a file, and I am not sure how
far back it is available. $IO_PERFORM or $QIO has the same issues where
we have to come up with the on-disk format of the EFS filename.
I have usually seen the callable convert or "FDL" routines used for this.
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
|
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Mon Apr 03, 2006 3:02 am Post subject:
Re: [patch@27669] rmsexpand/rmscopy update
|
|
|
The next patch I am testing is to add a new flag to rmsexpand to tell it
that the input file is already in VMS format, so not to waste the cycles
to vmsify it.
And then also convert cando_by_name to be cando_by_name_int() where
cando_by_name_int accepts an additional parameter that tells it that the
name is already in VMS format.
The cached name that Perl_cando is testing is already in VMS format so
it will call cando_by_name_int with that parameter set.
Next will be to start updating unixify/vmsify to better handle EFS file
specifications.
It looks like I will need a feature switch/logical name to determine if
characters with the high bit set in UNIX format file specifications are
in DECMCS format or in UTF-8 format. That will require me to convert
VTF-7 to UTF-8 and back. VTF-7 is the ASCII-HEX representation of UCS-2
prefixed with a "^U" sequence. I still do not have the conversion right
in vms.c
It seems to me that VMS file specs in VTF-7 format should be converted
to UNIX file specifications in UTF-8 format.
It also appears that the interfaces to/from perl for filenames need to
return or set the byte length and if the string is in Unicode. I have
not yet figured out how to do that.
Of course the VMS C RTL can not handle UTF-8 filenames, so all calls to
the CRTL would need UTF-8 filenames converted through rmsexpand().
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
|
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Mon Apr 03, 2006 5:04 am Post subject:
Re: [patch@27669] rmsexpand/rmscopy update
|
|
|
John E. Malmberg wrote:
| Quote: | Craig A. Berry wrote:
John E. Malmberg wrote:
-#if __CRTL_VER >= 70000000 /* FIXME to earliest version */
+#if __CRTL_VER >= 70300000 /* FIXME to earliest version */
#include <efndef.h
#define NO_EFN EFN$C_ENF
Why require 7.3 for this? I think it really did come along in 7.0,
didn't it?
I missed incorporating your change to my last patch on this. Yes, it
should be 7.0.
|
I found some more problems that were not apparent from the testing with
that patch. I had left in a hard coded macro to force use of the ODS-2
RMS macros instead of the ODS-5 macros. This apparently only caused
informationals in the build log, but did not affect the test results.
So depending on what happens in the overnight build of 27694, I may have
a better patch in the morning that has these changes and the perl_cando
optimizations.
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Sat Nov 22, 2008 1:33 pm | All times are GMT
|
|
Personal Car Finance | Mortgage Calculator | Debt Consolidation | Bad Credit Mortgages | Credit Card
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
Not Unix
»
VMS
»
vmsperl
