- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- GNV and CRTL
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-22-2010 12:33 AM
тАО11-22-2010 12:33 AM
Environment: OpenVMS I64 V8.3-1H1 + VMS831H1I_UPDATE V8.0, HP C V7.3-019.
After fiddling a bit with the GNV sources, I took a GNU diff against the sourceforge source files and started over. To keep the SF source tree clean, I defined a GNV_ROOT consisting of GNV_SPECIFIC (my build directory) and GNV_COMMON (the SF source tree), and duplicated GNV_COMMON's directory structure in GNV_SPECIFIC. Then I SET DEFAULT GNV_ROOT:[000000], SET PROCESS/PARSE=EXTENDED/CASE=SENSITIVE, and called GNU patch with my diff file to carry over the changes to the new directory structure. Everything's fine for files like crtlsup/makefile.com or build/FEATURES.COM, but for file/file-4.09/src/compress.c patch says it can't find the input file. I traced this to a failing stat call (PCH\intuit_diff_type\%LINE 9402, errno=2 = ENOENT - No such file or directory). After some experimentation I found that to support unix paths that contain directory names with dots I have to define DECC$EFS_CHARSET. But the compress.c patch still fails under that...
Any other ideas why stat can't find this file?
TIA
Martin
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-22-2010 01:48 AM
тАО11-22-2010 01:48 AM
Re: GNV and CRTL
I don't get it...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-22-2010 09:21 AM
тАО11-22-2010 09:21 AM
Re: GNV and CRTL
Do check, since you have case sensitivity turned on, that the actual file and directory names on disk are the same as specified in the patch, e.g., that you have src.DIR;1, not SRC.DIR;1.
You might check whether you have the logical name "file" defined or try defining DECC$UNIX_PATH_BEFORE_LOGNAME. Make sure you do NOT have DECC$EFS_NO_DOTS_IN_DIRNAME defined.
I actually would have expected DECC$EFS_CHARSET to be enough in this example. Since it isn't, I would try a big hammer like:
$ define DECC$UNIX_LEVEL 30
and see what happens. You could also edit the patch to insert caret escapes, so
file/file-4.09/src/compress.c
becomes
file/file-4^.09/src/compress.c
which really shouldn't be necessary but might work.
Navigating to the subdirectory as you have done is a good one-off solution for one file, but wouldn't help if the patch had numerous files from several directories, so I hope we get to the bottom of this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-22-2010 10:18 AM
тАО11-22-2010 10:18 AM
Re: GNV and CRTL
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-22-2010 01:18 PM
тАО11-22-2010 01:18 PM
Re: GNV and CRTL
From what I read, you want to have/use GNV diff and patch. Patch seems to be missing in GNV, and your versions of these GNU tools for VMS seem to miss the necessary initialization with the DECC$ features. The above module should help or point you into the right direction..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-22-2010 01:44 PM
тАО11-22-2010 01:44 PM
Re: GNV and CRTL
http://gnv.cvs.sourceforge.net/viewvc/gnv/gnv213/crtlsup/src/vms_crtl_init.c?revision=1.1.1.1&view=markup
It looks like there is a version of GNU patch in the latest GNV:
http://gnv.cvs.sourceforge.net/viewvc/gnv/gnv213/patch/
but there have been various ports kicking around so I don't know if that's the one Martin is using.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-23-2010 06:44 AM
тАО11-23-2010 06:44 AM
Re: GNV and CRTL
thanks for the confirmation that it should have worked ;-) In detail:
I had carefully looked after the case of directory names (having been bit by that several times in this project). So yes, the whole path's case is exactly as it appears to patch:
$ dir [.gnv213.file.file-4^.09.src]compress.c
Directory DISK$BUILD:[build.gnv213.file.file-4^.09.src]
compress.c;1
Total of 1 file.
(BTW: GNV_SPECIFIC is defined as 'f$trnlnm("DISK$BUILD")'[build.gnv213.] )
I also fell into the logical name trap (though with MANPATH defined by CDE, and the man kit containing a manpath.OBJ file). But no, in this case "file" is not defined as a logical.
Re: DECC$UNIX_LEVEL : In my despair to get it to work (without testing any one of the dozens of feature logicals) I indeed set that logical to 30 once - no change.
Re: Inserting a caret into the Unix path : I tried that, though not with this patch, but in my general experiments with stat (see attached).
Re: Using vms_crtl_init / GNV's patch : I'm in the process of building the GNV environment from scratch, so no GNV utilities, please (except where the build process calls them). I have no idea where my gpatch.exe came from - it gets copied from system to system :-) Most probably it's the Freeware CD version. To trace the error, I fetched the sources from Freeware #5 and compiled it /DEBUG. So, no decc$feature_set here. BUT: the GNV environment contains FEATURES.COM which I called when setting it up. This defines a whole slew of DECC$* feature logicals. Should have the same effect, shouldn't it?
http://gnv.cvs.sourceforge.net/viewvc/gnv/gnv213/build/FEATURES.COM?revision=1.1.1.1&view=markup
(plus, of course, my definition of DECC$EFS_CHARSET).
Thanks,
Martin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-23-2010 07:46 AM
тАО11-23-2010 07:46 AM
Re: GNV and CRTL
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-23-2010 09:02 AM
тАО11-23-2010 09:02 AM
Re: GNV and CRTL
You'll need to decode the FEATURES.COM settings for your environment; that list of logical names is incomplete.
Don't turn on case sensitivity unless you absolutely need that. That switch will find filename and filename casing assumptions all over the place.
GNV has problems with mixed environments; mixing VMS file specifications and Unix path syntax is problematic. I'd suggest using (only) Unix syntax, as that path seems to be the most reliable.
Utility doesn't come from simplicity or surface aesthetics. Utility comes from forging complexity into something you can comfortably wield.
The GNV initialization code stuff establishes an lib$initialize initialization psect that sets the defaults for the executable; you can recreate this code yourself easily, and establish the defaults in a somewhat modular fashion. (This is the workaround for most of the DECC$* logical name morass.)
There are diff, patch and xxd tools in the OpenVMS vim kit over at Polarhome, if that's of interest.
I'd probably get (most of) the sourceforge svn out of the picture and run the repository with git; git-svn or a git svn clone command (if you're departing from svn) can help with that.
http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
git svn clone http://PROJECT.svn.sourceforge.net/svnroot/PROJECT PROJECT.git
There are various issues with the default GNV set-up; have a look at the environment over at DECUServe for some of the fixes and updates that can be required.
And following the same vein, the DECUServe PORTING_TO_VMS notes conference has extensive information on C portability and the DECC$* settings.
I'd hope that the GNV project will decide to start using Sourceforge as something more than a file server and to engage the community, too; it'll be interesting to learn if this is a future during that upcoming GNV session.
It's often easier to fix the file formats (switching to stream LF) and migrate the VMS files to a platform with tools for the necessary work, then haul the stuff back to VMS to build it.
Build the reproducer, too. Narrow this stuff down.
I've posted some of my adventures with GNV. Here's one:
http://labs.hoffmanlabs.com/node/1481
Here are some of the topics associated with the DECC$* logical name settings:
http://labs.hoffmanlabs.com/node/1513
http://labs.hoffmanlabs.com/node/1515
"Utility doesn't come from simplicity or surface aesthetics. Utility comes from forging complexity into something you can comfortably wield." Unfortunately and problematically, both GNV and the C Unix compatibility environment and the current code-drop use model over at Sourceforge are presently al; rather unwieldy.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-23-2010 09:50 AM
тАО11-23-2010 09:50 AM
Solution* Stolen from the VMSperl source by Martin Vorlaender
* Um, that's actually GPB'd (GNU Public Borrowed) under the terms of the
* GNU Public License.
And a few lines further down:
*
* Wrapper routines added by Craig Berry based in part on code by Charles
* Lane.
*
So what's happening is our fault :-). As Hoff said, don't assume old code will work unmodified, even (especially?) if it's your own!
More specifically, there is a my_stat() wrapper around stat() that calls a home-grown converter routine to convert a filespec in Unix syntax to VMS syntax. The converter routine contains the following line in the part that handles the directory portion of the path:
else *(cp1++) = '_'; /* fix up syntax - '.' in name not allowed */
So we're explicitly defeating any attempt to make a dot in a directory name visible to the filesystem by converting it to an underscore. Remember, the target 10 years ago was VMS 6.x and early 7.x. There was limited or no capability in the CRTL to accept Unix-style pathnames, convert between Unix and VMS syntax, etc. ODS-5 did not exist and a dot in a directory name was a hard syntax error with no features to work around that.
I think your best bet may be to start over with the GNU patch from the GNV kit (or even just the authoritative GNU sources).