Wollogong TCP/IP stack - VMS

This is a discussion on Wollogong TCP/IP stack - VMS ; In article , billg999@cs.uofs.edu (Bill Gunshannon) writes: > > Does anyine remember if Eunice had fork()? > Eunice had a csh and some things that could be done as cover routines to VMS, but a working fork() would require modifying ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 36 of 36

Thread: Wollogong TCP/IP stack

  1. Re: Eunice (was: Wollogong TCP/IP stack)

    In article <62j5q2F23lvvgU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
    >
    > Does anyine remember if Eunice had fork()?
    >


    Eunice had a csh and some things that could be done as cover routines
    to VMS, but a working fork() would require modifying the VMS kernel's
    I/O subsystem.

    Which is why the C RTL doesn't have a true fork(), either.


  2. Re: Eunice (was: Wollogong TCP/IP stack)

    Bob Koehler wrote:
    > In article <62j5q2F23lvvgU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
    >
    >>Does anyine remember if Eunice had fork()?
    >>

    >
    >
    > Eunice had a csh and some things that could be done as cover routines
    > to VMS, but a working fork() would require modifying the VMS kernel's
    > I/O subsystem.
    >


    Not necessarily! It depends on the implementation. Fork() could record
    the current I/O state of all the open channels, pass it to the spawned
    process, and during startup, replicate the i/o state. To do this it would
    probably have to bypass RMS and VMS file and record locking and roll its
    own io subsystem (using QIOs), which would also have to be part of its
    Unix-emulating I/O library. Or, in a totally different approach, it could
    not spawn separate VMS processes at all with fork(), but use its own
    internal scheduler and data structures to track which "processes" owned
    which I/O resources. (The second approach is basically running a virtual
    Unix machine within a single VMS process.) Both these approaches have
    significant resource and performance implications, but both could be
    done without touching the VMS kernel.


    > Which is why the C RTL doesn't have a true fork(), either.
    >



    --
    John Santos
    Evans Griffiths & Hart, Inc.
    781-861-0670 ext 539

  3. Re: Eunice (was: Wollogong TCP/IP stack)

    John Santos wrote:
    > Bob Koehler wrote:
    >
    >> In article <62j5q2F23lvvgU1@mid.individual.net>, billg999@cs.uofs.edu
    >> (Bill Gunshannon) writes:
    >>
    >>> Does anyine remember if Eunice had fork()?
    >>>

    >>
    >>
    >> Eunice had a csh and some things that could be done as cover routines
    >> to VMS, but a working fork() would require modifying the VMS kernel's
    >> I/O subsystem.
    >>

    >
    > Not necessarily! It depends on the implementation. Fork() could record
    > the current I/O state of all the open channels, pass it to the spawned
    > process, and during startup, replicate the i/o state. To do this it would
    > probably have to bypass RMS and VMS file and record locking and roll its
    > own io subsystem (using QIOs), which would also have to be part of its
    > Unix-emulating I/O library. Or, in a totally different approach, it could
    > not spawn separate VMS processes at all with fork(), but use its own
    > internal scheduler and data structures to track which "processes" owned
    > which I/O resources. (The second approach is basically running a virtual
    > Unix machine within a single VMS process.) Both these approaches have
    > significant resource and performance implications, but both could be
    > done without touching the VMS kernel.
    >
    >
    >> Which is why the C RTL doesn't have a true fork(), either.
    >>

    >
    >


    A Unix developer has to fork in order to sneeze! VMS developers have
    gotten along without fork without noticeable difficulty.


  4. Re: Eunice (was: Wollogong TCP/IP stack)

    In article , John Santos writes:
    >
    > Not necessarily! It depends on the implementation. Fork() could record
    > the current I/O state of all the open channels, pass it to the spawned
    > process, and during startup, replicate the i/o state.


    Which would fail since VMS by default opens many I/O channels for
    exclusive access.

    Yes, you could achieve the affect by emulating an entire UNIX kernel
    inside on process, except that then everyone who logged onto EUNICE
    would see themselves as having a separate virtual machine.

    When you logged onto EUNICE, you got a csh prompt and some UNIX-like
    libraries, not you own machine.


  5. Re: Eunice (was: Wollogong TCP/IP stack)

    In article ,
    koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
    > In article , John Santos writes:
    >>
    >> Not necessarily! It depends on the implementation. Fork() could record
    >> the current I/O state of all the open channels, pass it to the spawned
    >> process, and during startup, replicate the i/o state.

    >
    > Which would fail since VMS by default opens many I/O channels for
    > exclusive access.
    >
    > Yes, you could achieve the affect by emulating an entire UNIX kernel
    > inside on process, except that then everyone who logged onto EUNICE
    > would see themselves as having a separate virtual machine.
    >
    > When you logged onto EUNICE, you got a csh prompt and some UNIX-like
    > libraries, not you own machine.


    That was the part I couldn't remember. I thought there was more to it than
    just a shell and commands because that wouldn't result in it being so slow.
    If it was merely a shell and commadns then doing an "ls" under "csh" should
    not have been any slower than doing a "dir" under "DCL". But it was.
    Painfully slower!! That was the reason most people I knew abandoned it in
    favor of getting their own small Unix systems (like CT Miniframe, Tandy-6000.
    Sage, etc.)

    But, looking back at your second paragraph. In this day of
    "virtualization". Is this not a possible solution to the
    "How do I run OpenOffice under VMS" question? Surely the
    systems are fast enough today that better than acceptable
    performance could be delivered. Of course, this comes back
    to my past comments on The Software Tools Virtual Operating
    System project. Maybe this is another of those things which
    wasn't practical at the time it started but technology has now
    caught up to it.

    bill


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

  6. Re: Eunice

    Bob Koehler wrote:
    > In article , John Santos writes:
    >
    >>Not necessarily! It depends on the implementation. Fork() could record
    >>the current I/O state of all the open channels, pass it to the spawned
    >>process, and during startup, replicate the i/o state.

    >
    >
    > Which would fail since VMS by default opens many I/O channels for
    > exclusive access.


    VMS doesn't open any channels if you don't let it... As I hinted at in
    the part you snipped out, you need to include the necessaries in the
    unix-emulating i/o library that is also part of your package. You
    don't need a complete unix virtual machine in the process. If someone
    goes behind your back and accesses VMS files (or other I/O) directly,
    then fork() wouldn't work, but that same code would definitely *not*
    work on any Unix system either.


    > Yes, you could achieve the affect by emulating an entire UNIX kernel
    > inside on process, except that then everyone who logged onto EUNICE
    > would see themselves as having a separate virtual machine.
    >


    No, the separate VMS processes running the unix emulator could co-operate.
    They wouldn't all have to be running inside one process to do so. (They
    would have to share a lot of information, though.)

    Emulating an entire unix system within a single VMS process was the 2nd
    option that I described.

    > When you logged onto EUNICE, you got a csh prompt and some UNIX-like
    > libraries, not you own machine.


    I wasn't saying Eunice worked this way (or either of these ways, since
    there were 2 of them), but that it was possible to implement a unix-like
    fork() without messing around with the VMS kernel. I vaguely remember
    encountering Eunice in some previous millennium, but I don't think I ever
    actually did any work using it, probably just a demo or helping a friend
    with something. I have no idea how it worked under the hood.

    --
    John Santos
    Evans Griffiths & Hart, Inc.
    781-861-0670 ext 539

  7. Re: Eunice (was: Wollogong TCP/IP stack)


    "Bill Gunshannon" wrote in message
    news:62nvojF23m54kU2@mid.individual.net...
    > In article ,
    > koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
    > > In article , John Santos

    writes:
    > >>
    > >> Not necessarily! It depends on the implementation. Fork() could

    record
    > >> the current I/O state of all the open channels, pass it to the spawned
    > >> process, and during startup, replicate the i/o state.

    > >
    > > Which would fail since VMS by default opens many I/O channels for
    > > exclusive access.
    > >
    > > Yes, you could achieve the affect by emulating an entire UNIX kernel
    > > inside on process, except that then everyone who logged onto EUNICE
    > > would see themselves as having a separate virtual machine.
    > >
    > > When you logged onto EUNICE, you got a csh prompt and some UNIX-like
    > > libraries, not you own machine.

    >
    > That was the part I couldn't remember. I thought there was more to it

    than
    > just a shell and commands because that wouldn't result in it being so

    slow.
    > If it was merely a shell and commadns then doing an "ls" under "csh"

    should
    > not have been any slower than doing a "dir" under "DCL". But it was.
    > Painfully slower!! That was the reason most people I knew abandoned it in
    > favor of getting their own small Unix systems (like CT Miniframe,

    Tandy-6000.
    > Sage, etc.)
    >
    > But, looking back at your second paragraph. In this day of
    > "virtualization". Is this not a possible solution to the
    > "How do I run OpenOffice under VMS" question? Surely the
    > systems are fast enough today that better than acceptable
    > performance could be delivered. Of course, this comes back
    > to my past comments on The Software Tools Virtual Operating
    > System project. Maybe this is another of those things which
    > wasn't practical at the time it started but technology has now
    > caught up to it.
    >
    > bill
    >
    >
    > --
    > Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
    > billg999@cs.scranton.edu | and a sheep voting on what's for dinner.
    > University of Scranton |
    > Scranton, Pennsylvania | #include


    1) What could the Software Tools Virtual OS project do right that the
    various POSIX people didn't? On paper it ought to be a whole load easier to
    get a set of *specifications* approved, and leave the implementation to
    others, but that didn't quite happen with POSIX in the way it did with (say)
    the Internerd RFCs.

    2) Whither DEC's own VMS Posix? Surely whatever it did with fork would be
    the definitive implementation for use on VMS???

    3) Processors have indeed got faster, and virtualisation more widely used,
    but that relies in part on not having to emulate the non-privileged
    instruction set in the guest environment. Surely you're not suggesting a
    return to SoftPC-class setups where every instruction requires emulation, or
    even FX!32 -class setups where every group of instructions needs on-the-fly
    translation? Although processors have got faster, software has got also
    fatter/slower (at least the stuff which the big names try to push), and in
    my experience today's low/mid-range PCs doing run of the mill stuff don't
    actually *feel* that much faster than something from five or ten years ago.

    4) CT Miniframe, thank you, I think that was the name of the rather unstable
    68k/System V implementation I referred to a few days back. A couple of other
    reasons this wasn't preferred over VMS were (1) the VMS software development
    environment, especially once the V4 debugger came out (2) our Miniframe was
    68010 based and therefore iirc it didn't do demand paged virtual memory,
    just swapping. Even when compared with a lowly VAX11/725, the Miniframe was
    the loser (the OS on this box may not have been CT's own CTIX, because ours
    was going to be rebadged by Gould once the bugs had been ironed out)



  8. Re: Eunice

    In article <3_Dxj.9180$xg6.871@trnddc07>, John Santos writes:
    >
    > VMS doesn't open any channels if you don't let it...


    If you don't go through the VMS kernel, you aren't going to open any,
    either.


  9. Re: Wollogong TCP/IP stack

    Stanley F. Quayle wrote:
    > On 25 Feb 2008 at 19:04, Bob Blum wrote:
    >> What version of Wollongong are they running?

    > How can they tell? (I have no access, it being a classified system.)
    >
    >> I have a copy of the Attachmate PathWay 3.1 documentation and CD. It
    >> supports UCX emulation, and still appears to use the TWG$* logicals and
    >> directories.

    > I'd be interested in getting a copy of what you have. Please call me at 888-VAX-VMS-8 to
    > discuss.
    >
    >> What version of VMS are they running?

    > V5.5-2H4 (and, yes, they're stuck on that version)


    Go with Multinet then.
    You can get the latest version and still have it run on 5.5-2


    >
    > --Stan Quayle
    > Quayle Consulting Inc.
    >
    > ----------
    > Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX
    > 8572 North Spring Ct., Pickerington, OH 43147 USA
    > stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html
    > "OpenVMS, when downtime is not an option"
    >
    >


  10. Re: Eunice (was: Wollogong TCP/IP stack)

    Stanley F. Quayle wrote:
    > On 26 Feb 2008 at 13:55, Richard B. Gilbert wrote:
    >> If you WANT Unix, why not just USE Unix?????

    >
    > It's not a question of wanting Unix -- it's a question of all those useful open-source
    > pieces (Firefox, Apache, Samba, etc.) being able to compile natively on VMS. We need
    > these things on VMS to be "relevant" [ie, saleable] in today's world.


    Compaq Secure Web Server(apache), CSWB Compaq Secure Web Browser
    (Mozilla), samba and the HP version of it run on VMS.

    >
    > As for the system I set up using GNV, it was a way to get the Unix guys on VMS quickly.
    > And there be no need for a learning curve if vi/emacs and some other tools were
    > available. We purists, of course, would use the more-powerful DCL environment...
    >
    > fork -- there are like 16 requirements for fork to work like it does in *nix. Right now,
    > VMS can do something like 5 of them. No problem, if you only need those 5. But most
    > *nix programmers don't restrict themselves to VMS's 5, even if they could. Why would
    > they?
    >
    > HP's not supporting the port of OpenOffice to VMS [darn!], but there's an "issuelist" of
    > things that need to be in VMS to make it work. Check out http://www.oooovms.dyndns.org/
    > for the details...
    >
    > --Stan Quayle
    > Quayle Consulting Inc.
    >
    > ----------
    > Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX
    > 8572 North Spring Ct., Pickerington, OH 43147 USA
    > stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html
    > "OpenVMS, when downtime is not an option"
    >
    >


  11. Re: Eunice (was: Wollogong TCP/IP stack)

    On 29 Feb 2008 at 14:46, Jim Mehlhop wrote:
    > Compaq Secure Web Server(apache), CSWB Compaq Secure Web Browser (Mozilla),
    > samba and the HP version of it run on VMS.


    True enough. But each of those programs required a big effort to port. If VMS had
    better Unix support, that would just be a quick compile away.

    And what about client stuff? HP's making a big deal about samba -- but they only ported
    the server side. Why can't I mount a samba share on my VMS box??

    --Stan Quayle
    Quayle Consulting Inc.

    ----------
    Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX
    8572 North Spring Ct., Pickerington, OH 43147 USA
    stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html
    "OpenVMS, when downtime is not an option"



  12. Re: Wollogong TCP/IP stack

    On 29 Feb 2008 at 14:40, Jim Mehlhop wrote:
    > Go with Multinet then.
    > You can get the latest version and still have it run on 5.5-2


    Or UCX -- I have the appropriate savesets.

    The big question is how Wollongong-specific they made their code. That could be a nasty
    port to get to anything else...

    --Stan Quayle
    Quayle Consulting Inc.

    ----------
    Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX
    8572 North Spring Ct., Pickerington, OH 43147 USA
    stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html
    "OpenVMS, when downtime is not an option"



  13. Samba as a client (was Re: Eunice )

    Stanley F. Quayle wrote:
    >
    > And what about client stuff? HP's making a big deal about samba -- but they only ported
    > the server side. Why can't I mount a samba share on my VMS box??


    For the same reason that you can not mount one on HP-UX, AIX, TRU-64.

    It is documented at the samba.org website.

    The smbmount program exists only for LINUX and BSD UNIX variants. The
    smbmount program requires changes to the internals of the platforms, and
    the developers of smbmount do not have access to those.

    Doing smbmount may be doable on VMS, if you were to write a file system
    ACP. It would have to access the TCP/IP stack in exec mode, and you
    would need something to map UICs and Identifiers to Microsoft GUIDS for
    usernames and group names.

    -John
    wb8tyw@qsl.network
    Personal Opinion Only

  14. Re: Samba as a client (was Re: Eunice )

    "John E. Malmberg" wrote in
    news:vMiyj.57067$yE1.13177@attbi_s21:

    > Stanley F. Quayle wrote:
    >>
    >> And what about client stuff? HP's making a big deal about samba --
    >> but they only ported the server side. Why can't I mount a samba
    >> share on my VMS box??

    >
    > For the same reason that you can not mount one on HP-UX, AIX,
    > TRU-64.
    >
    > It is documented at the samba.org website.
    >
    > The smbmount program exists only for LINUX and BSD UNIX variants.
    > The smbmount program requires changes to the internals of the
    > platforms, and the developers of smbmount do not have access to
    > those.
    >
    > Doing smbmount may be doable on VMS, if you were to write a file
    > system ACP. It would have to access the TCP/IP stack in exec mode,
    > and you would need something to map UICs and Identifiers to
    > Microsoft GUIDS for usernames and group names.
    >
    > -John
    > wb8tyw@qsl.network
    > Personal Opinion Only
    >


    I'm not real clear on what you're saying. On and old version of Samba,
    maybe 1.7.9 on VMS, I was able to use smbmount to a Windows 2000 server
    share and read and write files. It broke with Windows 2003 server.

  15. Re: Samba as a client (was Re: Eunice )

    Tad Winters wrote:
    > "John E. Malmberg" wrote in
    > news:vMiyj.57067$yE1.13177@attbi_s21:
    >> It is documented at the samba.org website.
    >>
    >> The smbmount program exists only for LINUX and BSD UNIX variants.
    >> The smbmount program requires changes to the internals of the
    >> platforms, and the developers of smbmount do not have access to
    >> those.

    >
    > I'm not real clear on what you're saying. On and old version of Samba,
    > maybe 1.7.9 on VMS, I was able to use smbmount to a Windows 2000 server
    > share and read and write files. It broke with Windows 2003 server.


    I think you were referring to smbclient, which is a command line utility
    to transfer files from Microsoft Windows and samba servers to a host.

    If someone has ported smbmount to VMS, I think I would have heard of it.

    As I have not looked at the HP offering for over a year and a half, I do
    not know if it is in the package.

    I know of no reason that the current smbclient could not run on VMS.
    Before I left HP, I had completed the code to make select() work on both
    sockets and terminals, which is needed for smbclient. With out that
    code, or special VMS code, smbclient times out connections while waiting
    at a command prompt.

    The routines to make select() and poll() work on terminals, x11 and
    pipes in addition to sockets is also in the glib port at
    ftp.encompasserve.org/gnv .

    -John
    wb8tyw@qsl.network
    Personal Opinion Only

  16. Re: Samba as a client (was Re: Eunice )

    "John E. Malmberg" wrote in
    news:SOpyj.4662$TT4.943@attbi_s22:

    > Tad Winters wrote:
    >> "John E. Malmberg" wrote in
    >> news:vMiyj.57067$yE1.13177@attbi_s21:
    >>> It is documented at the samba.org website.
    >>>
    >>> The smbmount program exists only for LINUX and BSD UNIX variants.
    >>> The smbmount program requires changes to the internals of the
    >>> platforms, and the developers of smbmount do not have access to
    >>> those.

    >>
    >> I'm not real clear on what you're saying. On and old version of
    >> Samba, maybe 1.7.9 on VMS, I was able to use smbmount to a Windows
    >> 2000 server share and read and write files. It broke with Windows
    >> 2003 server.

    >
    > I think you were referring to smbclient, which is a command line
    > utility to transfer files from Microsoft Windows and samba servers
    > to a host.


    Yes, that's right. It's been so long since I used it, I'd forgotten the
    name.

    [..snip..]
    >
    > -John
    > wb8tyw@qsl.network
    > Personal Opinion Only
    >



+ Reply to Thread
Page 2 of 2 FirstFirst 1 2