OpenVMS 8.3, GNV... one step beyond ? FUSE ? - VMS

This is a discussion on OpenVMS 8.3, GNV... one step beyond ? FUSE ? - VMS ; hello, with FUSE ( http://fuse.sourceforge.net/ ) almost anything (database, virtual file system over foreign data, data in any exotic device, etc) can be exposed as a file/directory structure to any un*x guy. now we have 8.3 and GNV with symlinks ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 36

Thread: OpenVMS 8.3, GNV... one step beyond ? FUSE ?

  1. OpenVMS 8.3, GNV... one step beyond ? FUSE ?

    hello,

    with FUSE (http://fuse.sourceforge.net/) almost anything (database,
    virtual file system over foreign data, data in any exotic device, etc)
    can be exposed as a file/directory structure to any un*x guy.

    now we have 8.3 and GNV with symlinks and mount points, how difficult
    do you think it would be to port FUSE ?
    or are symlink and mount points only a very thin structure which only
    do name translation for RMS and make FUSE as far as before ?

    TIA,
    Pierre.


  2. Re: OpenVMS 8.3, GNV... one step beyond ? FUSE ?

    Pierre wrote:
    > hello,
    >
    > with FUSE (http://fuse.sourceforge.net/) almost anything (database,
    > virtual file system over foreign data, data in any exotic device, etc)
    > can be exposed as a file/directory structure to any un*x guy.
    >
    > now we have 8.3 and GNV with symlinks and mount points, how difficult
    > do you think it would be to port FUSE ?
    > or are symlink and mount points only a very thin structure which only
    > do name translation for RMS and make FUSE as far as before ?


    VMS does not document how to add additional file systems. It may be
    possible to figure it out from the listing files, if you have them.

    What is easier is to put a wrapper around the C RTL file routines so
    that you can redirect them as needed. And that would still be a lot of
    work.

    This would allow things like GLIB and other applications to be extended
    to support those systems. Perl or Python for example.

    Symbolic links and mount points really do not do much for VMS as logical
    names can do the same thing.

    -John
    wb8tyw@qsl.network
    Personal Opinion Only

  3. Re: OpenVMS 8.3, GNV... one step beyond ? FUSE ?

    Pierre schrieb:

    > with FUSE (http://fuse.sourceforge.net/) almost anything (database,
    > virtual file system over foreign data, data in any exotic device, etc)
    > can be exposed as a file/directory structure to any un*x guy.
    >
    > now we have 8.3 and GNV with symlinks and mount points, how difficult
    > do you think it would be to port FUSE ?
    > or are symlink and mount points only a very thin structure which only
    > do name translation for RMS and make FUSE as far as before ?


    Spot the difference:

    -----------------------------------------------------------
    GDC00F::USER_DISK5:[KRISCHIKM]>bash --version
    GNU BASH, version 1.14.8(0) s4
    -----------------------------------------------------------
    ~ CYGWIN_NT-5.0 krischikm@w01iwt Wed Jul 18 13:06:18 standart
    >bash --version

    GNU bash, version 3.2.17(15)-release (i686-pc-cygwin)
    Copyright (C) 2005 Free Software Foundation, Inc.
    -----------------------------------------------------------

    Have you had a look at the GNV donwload side recently? "July 30, 2004" -
    That's almost 3 years now. Well have another spot the difference:

    -----------------------------------------------------------
    GNV - Alpha V1.6-2 July 30, 2004
    GNV - I64 V1.6-2 July 30, 2004
    -----------------------------------------------------------
    bash-1.14.7.tar.gz 29-Aug-1996 03:00 1.4M
    bash-2.05b.tar.gz 17-Jul-2002 14:56 1.9M
    bash-3.2.tar.gz 11-Oct-2006 12:11 2.4M
    -----------------------------------------------------------

    When I started the reply I did not know it is that bad. When in 2004 GNV
    1.6 was released bash 1.14 was almost 8 years old and bash 2.05 was
    already out for over 2 years.

    Honestly, if the GNV project can't even provide an up-to-date shell,
    when they bundle an 8 year old bash instead of the current version, what
    are the changes that GNV can provide a complex system like FUSE.

    So the answer to your question is: No - not one step - first we need an
    up to date GNV first and that is a very huge step.

    Martin

    PS: Last week I got a mail from a VMS advocate claiming that DCL is
    better then bash. In retrospect: If all you ever see is an 11 year old
    bash that DCL is indeed better.

    --
    mailto://krischik@users.sourceforge.net
    Ada programming at: http://ada.krischik.com

  4. Re: OpenVMS 8.3, GNV... one step beyond ? FUSE ?

    On 07/19/07 02:02, Martin Krischik wrote:
    [snip]
    >
    > PS: Last week I got a mail from a VMS advocate claiming that DCL is
    > better then bash. In retrospect: If all you ever see is an 11 year old
    > bash that DCL is indeed better.


    Mini Coopers pollute less than trucks, and so are "better". But
    when you want to haul a family and it's gear half-way across the
    country, minivans start to look a heck of a lot better.

    (Amerocentrism: it just occurred to me, though, that driving a
    family half way across Britain in a Mini Cooper wouldn't be that
    rough. London->Liverpool is only 285 crow-flies km, whereas St
    Louis->Los Angeles is 9x further.)

    --
    Ron Johnson, Jr.
    Jefferson LA USA

    Give a man a fish, and he eats for a day.
    Hit him with a fish, and he goes away for good!

  5. Re: OpenVMS 8.3, GNV... one step beyond ? FUSE ?

    In article ,
    Ron Johnson wrote:

    > On 07/19/07 02:02, Martin Krischik wrote:
    > [snip]
    > >
    > > PS: Last week I got a mail from a VMS advocate claiming that DCL is
    > > better then bash. In retrospect: If all you ever see is an 11 year old
    > > bash that DCL is indeed better.

    >
    > Mini Coopers pollute less than trucks, and so are "better". But
    > when you want to haul a family and it's gear half-way across the
    > country, minivans start to look a heck of a lot better.
    >
    > (Amerocentrism: it just occurred to me, though, that driving a
    > family half way across Britain in a Mini Cooper wouldn't be that
    > rough. London->Liverpool is only 285 crow-flies km, whereas St
    > Louis->Los Angeles is 9x further.)


    A modern Mini Cooper (BMW made) is far better. I was amazed when I saw a
    neighbor unloading furniture from his, and realized how roomy they were
    in comparison with the original.

    But when you from the US mention the word "minivan", this is what
    immediately pops into my mind:

    http://www.bobleroi.co.uk/ScrapBook/...ing/Willow.jpg

    Not quite the same thing ;-)

    --
    Paul Sture

  6. Re: OpenVMS 8.3, GNV... one step beyond ? FUSE ?

    In article ,
    "P. Sture" writes:
    > In article ,
    > Ron Johnson wrote:
    >
    >> On 07/19/07 02:02, Martin Krischik wrote:
    >> [snip]
    >> >
    >> > PS: Last week I got a mail from a VMS advocate claiming that DCL is
    >> > better then bash. In retrospect: If all you ever see is an 11 year old
    >> > bash that DCL is indeed better.

    >>
    >> Mini Coopers pollute less than trucks, and so are "better". But
    >> when you want to haul a family and it's gear half-way across the
    >> country, minivans start to look a heck of a lot better.
    >>
    >> (Amerocentrism: it just occurred to me, though, that driving a
    >> family half way across Britain in a Mini Cooper wouldn't be that
    >> rough. London->Liverpool is only 285 crow-flies km, whereas St
    >> Louis->Los Angeles is 9x further.)

    >
    > A modern Mini Cooper (BMW made) is far better. I was amazed when I saw a
    > neighbor unloading furniture from his, and realized how roomy they were
    > in comparison with the original.
    >
    > But when you from the US mention the word "minivan", this is what
    > immediately pops into my mind:
    >
    > http://www.bobleroi.co.uk/ScrapBook/...ing/Willow.jpg
    >
    > Not quite the same thing ;-)


    Your right, isn't that just an estate wagon?

    I always remember when I worked in the papermill and one of my co-workers
    walked up ro me and said he couldn't see how I could be comfortable in such
    a small car, I drove a Porsche 914 in those days. Two seater, lots of
    leg room, top comes off for even more headroom. After work I watched him
    meet his carpool and all four of them (there were full-sized american
    factory bulls) climb into a Honda Civic CVCC. For those, unfamiliar with
    that nomenclature, it's no bigger than the original Mini!! :-)

    I guess, like beauty, it's all in the eye of the beholder....

    bill

    --
    Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
    bill@cs.scranton.edu | and a sheep voting on what's for dinner.
    University of Scranton |
    Scranton, Pennsylvania | #include

  7. bash vs DCL (Was: OpenVMS 8.3, GNV... one step beyond ? FUSE ?)

    Ron Johnson schrieb:

    > On 07/19/07 02:02, Martin Krischik wrote:
    > [snip]
    >> PS: Last week I got a mail from a VMS advocate claiming that DCL is
    >> better then bash. In retrospect: If all you ever see is an 11 year old
    >> bash that DCL is indeed better.

    >
    > Mini Coopers pollute less than trucks, and so are "better". But
    > when you want to haul a family and it's gear half-way across the
    > country, minivans start to look a heck of a lot better.


    True. But I like the photo of the really old station wagon form the
    other post. It is more like a truck build somewhere in the '90th
    compared with one from last October. Which one would you trust your
    family with?

    And only today I spoke with a new colleague about the "The Tortoise and
    the Hare" in conjunction with VMS and Unix. But we had this all before
    and there is nothing we can do about it. And of course bash has it's
    weaknesses as well

    Martin

    [1] http://en.wikipedia.org/wiki/The_Tortoise_and_the_Hare
    --
    mailto://krischik@users.sourceforge.net
    Ada programming at: http://ada.krischik.com

  8. Re: OpenVMS 8.3, GNV... one step beyond ? FUSE ?

    In article , Ron Johnson writes:
    >
    > Mini Coopers pollute less than trucks, and so are "better". But
    > when you want to haul a family and it's gear half-way across the
    > country, minivans start to look a heck of a lot better.


    Does a Mini seat five? Mine would be tight in our Civic, but when
    my daughter goes off to school the minivan goes into semi-retirement.
    I won't miss the cost of filling it.


  9. Re: OpenVMS 8.3, GNV... one step beyond ? FUSE ?

    In article , "P. Sture" writes:
    >
    > But when you from the US mention the word "minivan", this is what
    > immediately pops into my mind:
    >
    > http://www.bobleroi.co.uk/ScrapBook/...ing/Willow.jpg
    >


    So what do you call this thing (URL wraps):

    http://www.dodge.com/en/caravan/inde...8&mktprgm=&pre

  10. Re: OpenVMS 8.3, GNV... one step beyond ? FUSE ?

    Martin Krischik wrote:
    > Pierre schrieb:
    >
    >
    >>with FUSE (http://fuse.sourceforge.net/) almost anything (database,
    >>virtual file system over foreign data, data in any exotic device, etc)
    >>can be exposed as a file/directory structure to any un*x guy.
    >>
    >>now we have 8.3 and GNV with symlinks and mount points, how difficult
    >>do you think it would be to port FUSE ?
    >>or are symlink and mount points only a very thin structure which only
    >>do name translation for RMS and make FUSE as far as before ?

    >
    >
    > Spot the difference:
    >
    > -----------------------------------------------------------
    > GDC00F::USER_DISK5:[KRISCHIKM]>bash --version
    > GNU BASH, version 1.14.8(0) s4
    > -----------------------------------------------------------
    > ~ CYGWIN_NT-5.0 krischikm@w01iwt Wed Jul 18 13:06:18 standart
    >
    >>bash --version

    >
    > GNU bash, version 3.2.17(15)-release (i686-pc-cygwin)
    > Copyright (C) 2005 Free Software Foundation, Inc.
    > -----------------------------------------------------------
    >
    > Have you had a look at the GNV donwload side recently? "July 30, 2004" -
    > That's almost 3 years now. Well have another spot the difference:


    You need to look at the HP GNV site. The HP maintainer has not been
    keeping the sourceforge site up to date.

    > -----------------------------------------------------------
    > GNV - Alpha V1.6-2 July 30, 2004
    > GNV - I64 V1.6-2 July 30, 2004


    GNV is now at 2.x. And adding symbolic link support was the smallest of
    the changes.

    The bash in it, even though it was old, got quite a number of
    improvements. Including a fix for a performance bug that is quite
    likely in the bash of your other platforms.

    > -----------------------------------------------------------
    > bash-1.14.7.tar.gz 29-Aug-1996 03:00 1.4M
    > bash-2.05b.tar.gz 17-Jul-2002 14:56 1.9M
    > bash-3.2.tar.gz 11-Oct-2006 12:11 2.4M
    > -----------------------------------------------------------
    >
    > When I started the reply I did not know it is that bad. When in 2004 GNV
    > 1.6 was released bash 1.14 was almost 8 years old and bash 2.05 was
    > already out for over 2 years.


    And what things are missing from the older bash that is in GNV?

    The only thing that I have seen that affects running the UNIX build
    procedures is that it is missing the "printf" built in.

    The interesting thing is that the configure scripts detect that printf
    support is missing, yet still insist on trying to use it.

    Except for those diagnostics being output during configure, I have seen
    no other problems due to the older version.

    > Honestly, if the GNV project can't even provide an up-to-date shell,
    > when they bundle an 8 year old bash instead of the current version, what
    > are the changes that GNV can provide a complex system like FUSE.


    If you mean changes, see the release notes in the current HP kit.

    If you mean chances, I would say pretty good. I have successfully
    compiled the entire UNIX SAMBA V3 pre-production tree with it. Some
    library support was missing. I also could build the SAMBA V4 tree.the
    last time I tried. Both on versions of VMS that did not have symbolic
    link support.

    I have also compiled and linked GTK+ 2.x and all of its components.

    > So the answer to your question is: No - not one step - first we need an
    > up to date GNV first and that is a very huge step.


    It may not be as huge as you would think. The problem is not in porting
    a newer bash, it is in fixing some of the generic issues that are common
    to the current GNV project that will affect future ports.

    Yes, it needs a lot of work, but right now it is good enough to handle
    most of the projects that I have thrown at it.

    The current GNV bash uses virtual memory for most of the pipes, so is no
    longer constrained by the size of a VMS mailbox.

    The CC wrapper is improved, but still is handling -d directives with
    spaces in the macro definitions incorrectly. I have seen one project
    that requires this.

    -John
    wb8tyw@qsl.network
    Personal Opinion Only

  11. Re: OpenVMS 8.3, GNV... one step beyond ? FUSE ?

    On 07/19/07 07:55, Bob Koehler wrote:
    > In article , Ron Johnson writes:
    >> Mini Coopers pollute less than trucks, and so are "better". But
    >> when you want to haul a family and it's gear half-way across the
    >> country, minivans start to look a heck of a lot better.

    >
    > Does a Mini seat five? Mine would be tight in our Civic, but when
    > my daughter goes off to school the minivan goes into semi-retirement.
    > I won't miss the cost of filling it.


    But for us that, 9 years...

    I figure we've got one more van purchase left, and I hope it's a diesel.

    --
    Ron Johnson, Jr.
    Jefferson LA USA

    Give a man a fish, and he eats for a day.
    Hit him with a fish, and he goes away for good!

  12. Re: OpenVMS 8.3, GNV... one step beyond ? FUSE ?

    Pierre wrote:

    > with FUSE (http://fuse.sourceforge.net/) almost anything (database,
    > virtual file system over foreign data, data in any exotic device, etc)
    > can be exposed as a file/directory structure to any un*x guy.


    What next, Multics? :-)

    > now we have 8.3 and GNV with symlinks and mount points, how difficult
    > do you think it would be to port FUSE ?


    Well, you could go try to port it. Or more likely, to design a parallel
    implementation for use with OpenVMS, and preferably one where the
    user-mode stuff was portable.

    > or are symlink and mount points only a very thin structure which only
    > do name translation for RMS and make FUSE as far as before ?


    It would not even occur to me to consider GNV, symlinks and mount points
    here. To add in a file system, you're working in inner mode code for at
    least some of the effort.

    There are some interesting potential security exposures here with
    user-mode file systems, too. The file system has a degree of trust in
    the contents of the volume, and that's not necessarily appropriate in a
    FUSE or similar environment. But that's fodder for another discussion.

    As for slotting in the shim to get out into the file system, there's no
    documented layer to integrate a file system into OpenVMS, which makes
    this sort of thing "interesting" -- slotting in a variant file system
    akin to NFS client is not documented, and assumptions in various
    components such as MOUNT -- you need some form of MOUNT to bring a file
    system ACP online -- can get tangled.

    There is a way to run XQP in user mode for purposes of debugging, but
    I'd not expect to see that approach used outside of OpenVMS engineering.
    Setting up for it is not difficult, but it does involve a dozen or so
    steps, and you'll usually want an XQP built with debugging enabled.

    There's nothing insurmountable here, but you're going to be hacking
    around in kernel-mode, or you're going to have to trap the existing I/O
    calls.

    And then there's the question of what you do with it all, once you have
    it all screwed together and working. Linux has a simpler view of what a
    file is -- it's a stream of bytes -- and OpenVMS and its tools tend to
    make assumptions around structures. PCSI, for instance, has trouble
    with existing ISO-9660:1988 volume structure support because of the lack
    of file system metadata in the default volume structure environment.
    (LJK has an aftermarket fix for that, and a way to tag files.)

    Everything as a device has its advantages -- OpenVMS has had some of
    that DNA in its design, dating back through to its RSX-11M parentage --
    but a degree of that simplicity has been lost over the years.

    There have been (other) approaches here, such as user-mode Linux.

    FWIW, Andy and I and others have chatted about this over the years, but
    a file system layer never got "above the fold" on the engineering
    schedule. There are a couple of file systems that would have been handy
    to integrate more directly, and there's no easy way to do that -- the
    NFS and DFS clients and some of the existing ACPs are probably the
    salient examples here, and code to the clients isn't generally available.

    I've some intro info on ACPs and on I/O posted over at the website.
    Start here:




    --
    www.HoffmanLabs.com
    Services for OpenVMS

  13. Re: bash vs DCL (Was: OpenVMS 8.3, GNV... one step beyond ? FUSE ?)

    In article <469f5b76$1@news.post.ch>,
    Martin Krischik wrote:

    > Ron Johnson schrieb:
    >
    > > On 07/19/07 02:02, Martin Krischik wrote:
    > > [snip]
    > >> PS: Last week I got a mail from a VMS advocate claiming that DCL is
    > >> better then bash. In retrospect: If all you ever see is an 11 year old
    > >> bash that DCL is indeed better.

    > >
    > > Mini Coopers pollute less than trucks, and so are "better". But
    > > when you want to haul a family and it's gear half-way across the
    > > country, minivans start to look a heck of a lot better.

    >
    > True. But I like the photo of the really old station wagon form the
    > other post. It is more like a truck build somewhere in the '90th
    > compared with one from last October. Which one would you trust your
    > family with?


    Far safety for the family in an accident I'd go for the one from last
    October, as car safety standards have improved a lot since 1959.

    Now if you mean fixing the thing with a just few spanners and a couple
    of screwdrivers, the reverse is true. Rust was shocking problem though.

    > And only today I spoke with a new colleague about the "The Tortoise and
    > the Hare" in conjunction with VMS and Unix. But we had this all before
    > and there is nothing we can do about it. And of course bash has it's
    > weaknesses as well
    >
    > Martin
    >
    > [1] http://en.wikipedia.org/wiki/The_Tortoise_and_the_Hare


    --
    Paul Sture

  14. Re: OpenVMS 8.3, GNV... one step beyond ? FUSE ?

    On Jul 19, 6:41 pm, Stephen Hoffman
    wrote:
    > Pierre wrote:
    > > with FUSE (http://fuse.sourceforge.net/) almost anything (database,
    > > virtual file system over foreign data, data in any exotic device, etc)
    > > can be exposed as a file/directory structure to any un*x guy.

    >
    > What next, Multics? :-)
    >
    > > now we have 8.3 and GNV with symlinks and mount points, how difficult
    > > do you think it would be to port FUSE ?

    >
    > Well, you could go try to port it. Or more likely, to design a parallel
    > implementation for use with OpenVMS, and preferably one where the
    > user-mode stuff was portable.
    >
    > > or are symlink and mount points only a very thin structure which only
    > > do name translation for RMS and make FUSE as far as before ?

    >
    > It would not even occur to me to consider GNV, symlinks and mount points
    > here. To add in a file system, you're working in inner mode code for at
    > least some of the effort.
    >
    > There are some interesting potential security exposures here with
    > user-mode file systems, too. The file system has a degree of trust in
    > the contents of the volume, and that's not necessarily appropriate in a
    > FUSE or similar environment. But that's fodder for another discussion.
    >
    > As for slotting in the shim to get out into the file system, there's no
    > documented layer to integrate a file system into OpenVMS, which makes
    > this sort of thing "interesting" -- slotting in a variant file system
    > akin to NFS client is not documented, and assumptions in various
    > components such as MOUNT -- you need some form of MOUNT to bring a file
    > system ACP online -- can get tangled.
    >
    > There is a way to run XQP in user mode for purposes of debugging, but
    > I'd not expect to see that approach used outside of OpenVMS engineering.
    > Setting up for it is not difficult, but it does involve a dozen or so
    > steps, and you'll usually want an XQP built with debugging enabled.
    >
    > There's nothing insurmountable here, but you're going to be hacking
    > around in kernel-mode, or you're going to have to trap the existing I/O
    > calls.
    >
    > And then there's the question of what you do with it all, once you have
    > it all screwed together and working. Linux has a simpler view of what a
    > file is -- it's a stream of bytes -- and OpenVMS and its tools tend to
    > make assumptions around structures. PCSI, for instance, has trouble
    > with existing ISO-9660:1988 volume structure support because of the lack
    > of file system metadata in the default volume structure environment.
    > (LJK has an aftermarket fix for that, and a way to tag files.)
    >
    > Everything as a device has its advantages -- OpenVMS has had some of
    > that DNA in its design, dating back through to its RSX-11M parentage --
    > but a degree of that simplicity has been lost over the years.
    >
    > There have been (other) approaches here, such as user-mode Linux.
    >
    > FWIW, Andy and I and others have chatted about this over the years, but
    > a file system layer never got "above the fold" on the engineering
    > schedule. There are a couple of file systems that would have been handy
    > to integrate more directly, and there's no easy way to do that -- the
    > NFS and DFS clients and some of the existing ACPs are probably the
    > salient examples here, and code to the clients isn't generally available.
    >
    > I've some intro info on ACPs and on I/O posted over at the website.
    > Start here:
    >
    >
    >
    >
    > --www.HoffmanLabs.com
    > Services for OpenVMS



    - to access a forein disk structure on a well known physical disk
    model, the device driver already exists and only the ACP would be
    needed , right ?
    - to access say a database as if it was an diretory tree (one 'dir'
    per table, one 'file' per row) there is no need for a device driver as
    there is no real device to manage, only translate IO call to functions
    call to access the data in the DB
    - what would be needed to access 'something' over say a network link ?
    one just have to translate IOs into function calls wich 'do something'
    over the network and answer with results formated in an acceptable
    fashion. is this the job of the ACP ?

    Pierre.


  15. Re: OpenVMS 8.3, GNV... one step beyond ? FUSE ?

    In article ,
    "John E. Malmberg" wrote:


    > I have also compiled and linked GTK+ 2.x and all of its components.


    Cool. I tried this a month or two ago with GNV 2.1 and the GTK+ "pre"
    kit I found on ftp.encompasserve.org/gnv and got some errors which I
    didn't have time to look into. Is there later or more complete work
    available?

    > The current GNV bash uses virtual memory for most of the pipes, so is no
    > longer constrained by the size of a VMS mailbox.


    The source that ships with GNV 2.1 does not include vms_vm_pipe.c. Not
    sure whether they shipped source that's out of date with respect to the
    executables or if not everything intended for the release made it in.
    Grabbing what's on encompasserve and poking around, it appears that a
    pipe is still a mailbox in this implementation. Is it just a buffering
    layer in between the reader and writer so that the write doesn't hang
    when the mailbox fills up?

    --
    Posted via a free Usenet account from http://www.teranews.com


  16. Re: OpenVMS 8.3, GNV... one step beyond ? FUSE ?

    Craig A. Berry wrote:
    > In article ,
    > "John E. Malmberg" wrote:
    >
    >>I have also compiled and linked GTK+ 2.x and all of its components.

    >
    > Cool. I tried this a month or two ago with GNV 2.1 and the GTK+ "pre"
    > kit I found on ftp.encompasserve.org/gnv and got some errors which I
    > didn't have time to look into. Is there later or more complete work
    > available?


    Not yet, I have built two incomplete versions of the GTK+ 2.x kit. That
    is, functional, but missing some features and not passing all the tests.

    I have some issues to get settled before I can continue on it.

    >>The current GNV bash uses virtual memory for most of the pipes, so is no
    >>longer constrained by the size of a VMS mailbox.

    >
    > The source that ships with GNV 2.1 does not include vms_vm_pipe.c. Not
    > sure whether they shipped source that's out of date with respect to the
    > executables or if not everything intended for the release made it in.


    I do not know either. I have not inspected the 2.1 kit to see what was
    in the source. It is possible that the new file is missing from the kit
    manifest so it was not included.

    > Grabbing what's on encompasserve and poking around, it appears that a
    > pipe is still a mailbox in this implementation. Is it just a buffering
    > layer in between the reader and writer so that the write doesn't hang
    > when the mailbox fills up?


    The implementation is to use two pipes so that the C RTL sees it as a
    pipe, but uses SYS$QIO and an AST that drain the write mailbox (pipe)
    into packets of virtual memory, and a second AST to keep feeding the
    memory packets to the mailbox that is being read.

    It would be a lot more efficient if the CRTL did this internally.

    It is close to how Perl on VMS has implemented pipes.

    There is also some cleanup code in it to deal with the other end
    (assumed to be a subprocess) disconnecting, which is specific to what
    bash needs, so the implementation in GNV bash is not totally generic.

    There still is a section of GNV bash that is using temporary files for
    pipes that I missed when I was working on it. If you look at the source
    in that section, there is a whole bunch of apparent VMS specific code
    that is actually not compiled in.

    -John
    wb8tyw@qsl.network
    Personal Opinion Only

  17. Re: OpenVMS 8.3, GNV... one step beyond ? FUSE ?

    Pierre wrote:
    >
    > - to access a forein disk structure on a well known physical disk
    > model, the device driver already exists and only the ACP would be
    > needed , right ?


    Right. The ACP needs to translate the data structure to look like what
    the VMS I/O calls expect.

    > - to access say a database as if it was an diretory tree (one 'dir'
    > per table, one 'file' per row) there is no need for a device driver as
    > there is no real device to manage, only translate IO call to functions
    > call to access the data in the DB


    The ACP translate code runs in exec or kernel mode, in effect it is
    close to being a device driver.

    The ACP needs to also handle access control to the foreign file system,
    which requires it to be run in a privileged context.

    > - what would be needed to access 'something' over say a network link ?
    > one just have to translate IOs into function calls wich 'do something'
    > over the network and answer with results formated in an acceptable
    > fashion. is this the job of the ACP ?


    Yes, if you want it to be transparent to all programs.

    The APIs needed to access the network from kernel mode or exec mode may
    be different than that for user mode.


    If you instead make a wrapper to the C RTL or similar API, then while it
    would not be transparent, for those applications that you can rebuild
    from source, you can add the functionality. The EVE/TPU editor could
    even be extended to use it as part of the file API.

    -John
    wb8tyw@qsl.network
    Personal Opinion Only

  18. Re: OpenVMS 8.3, GNV... one step beyond ? FUSE ?

    Hi John

    I wonder where my other post when. Ahh, well maybe it appears later!

    John E. Malmberg schrieb:

    > You need to look at the HP GNV site. The HP maintainer has not been
    > keeping the sourceforge site up to date.


    Got it, installed it, didn't work :-(

    -----------------------------------------------------------
    PRODUCT Install GNV /Destination=PTT_TOOLS_ODS5:[000000]
    %PCSI-E-READERR, error reading
    $1$DGA5:[USER5.][KRISCHIKM.TMP]DEC-AXPVMS-GNV-V0201-001-1.PCSI$COMPRESSED;1
    -RMS-W-RTB, 685 byte record too large for user's buffer
    %PCSI-E-OPENIN, error opening
    $1$DGA5:[USER5.][KRISCHIKM.TMP]DEC-AXPVMS-GNV-V0201-001-1.PCSI$COMPRESSED;1
    as input
    %PCSI-E-S_OPFAIL, operation failed
    %PCSIUI-E-ABORT, operation terminated due to an unrecoverable error
    condition
    -----------------------------------------------------------

    Any Ideas?

    Martin
    --
    mailto://krischik@users.sourceforge.net
    Ada programming at: http://ada.krischik.com

  19. Re: OpenVMS 8.3, GNV... one step beyond ? FUSE ?

    On Jul 20, 5:51 am, "John E. Malmberg" wrote:
    > Pierre wrote:
    >
    > > - what would be needed to access 'something' over say a network link ?
    > > one just have to translate IOs into function calls wich 'do something'
    > > over the network and answer with results formated in an acceptable
    > > fashion. is this the job of the ACP ?

    >
    > Yes, if you want it to be transparent to all programs.
    >
    > The APIs needed to access the network from kernel mode or exec mode may
    > be different than that for user mode.


    and of course, UCX (TCPIP) people have more facility than me to create
    their pseudo disk over a NFS mount (I do not want to do a pseudo disk
    over NFS mount, it's just an example )

    Pierre


  20. Re: OpenVMS 8.3, GNV... one step beyond ? FUSE ?

    In article ,
    koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote:

    > In article , "P. Sture"
    > writes:
    > >
    > > But when you from the US mention the word "minivan", this is what
    > > immediately pops into my mind:
    > >
    > > http://www.bobleroi.co.uk/ScrapBook/...ing/Willow.jpg
    > >

    >
    > So what do you call this thing (URL wraps):
    >
    >


    American idea of a minivan :-)

    More seriously, we didn't really have them until the late (ish) 1980s. I
    think the Renault Espace was the first, with Toyota next and all the
    other manufacturers following suit.

    Introduced as MPVs (Multi-Purpose Vehicles), and now known as people
    carriers. On this side of the pond they have variously complex and
    difficult to handle seating systems. If you haven't got a garage to
    leave bits of seating in, you're a bit stuck for handling bulky loads.

    A pain in the neck to follow if you're in a normal car, as they are
    difficult to see past.

    --
    Paul Sture

+ Reply to Thread
Page 1 of 2 1 2 LastLast