Re: OpenVMS - Remot emailbox (Decnet)

From: Jean Mertens (jmertens_at_skynet.be)
Date: 07/15/03

  • Next message: John Gemignani, Jr.: "Re: iSCSI anyone?" 
    Date: Tue, 15 Jul 2003 05:33:12 +0200

    What is surprising is that the following is working:

    1) From NodeA $CREMBX mail box NODEA_MBX (logical name) as permanent
    2) Define proxy on NodeA user A to point to NodeB user B
    3) From NodeB in DCL
    DCL>OPEN/WRITE tmp NodeB::NODEA_MBX
    DCL> WRITE tmp "hello there this is remote node B"
    DCL> CLOSE tmp

    NodeA receives in NODEA_MBX the string : hello there this is remote node B

    The same works with pure Fortran Open and Write if the file name is
    NodeB::"NODEA_MBX" with the mail box logical name
    between to double quotes.

    It must be an undocumented VMS feature ....

    Thanks anyway. I'll go and try the tas to task

    "Carl Perkins" <carl@gerg.tamu.edu> a écrit dans le message de
    news:14JUL200320364419@gerg.tamu.edu...
    > "Jean Mertens" <jmertens@skynet.be> writes...
    > }"Bob Koehler" <koehler@eisner.nospam.encompasserve.org> a écrit dans le
    > }message de news:S5k3Eex0ySxf@eisner.encompasserve.org...
    > }> In article <3f12c6e7$0$271$ba620e4c@reader0.news.skynet.be>, "Jean
    > }Mertens" <jmertens@skynet.be> writes:
    > }> > Using SYS$CREMBX, how to connect to a mailbox on another node
    (OpenVMS)
    > }> > (using Fortran preferrably)
    > }> > or using regular OPEN Fortran statement in order to send mail box
    > }messages
    > }> > that are quite long ?
    > }>
    > }> Standard VMS mailboxes are not network accessable. Try DECnet
    > }> mailboxes instead.
    > }>
    > }What is a Decnet Mailbox as opposed to the one created with SYS$CREMBX ?
    >
    > Jumping in here...
    >
    > I'm not sure why it is sometimes called that, as it isn't really a mailbox
    > as such. In some respects the data reading and writing is very similar.
    >
    > SYS$CREMBX creates a "mailbox" which is an MBAx: type device. It's
    > essentially a chunk of memory that you can write to and read from via
    > the mailbox drivers. As such, it is specific to the system it is on
    > and there is no network access to it (unless you program a network
    > server process that accesses it).
    >
    > A "DECnet mailbox" isn't just a mailbox. In fact it isn't a mailbox in
    > the MBAx: device sense at all, although there are mailboxes involved -
    > one is used for the network command data at each end. The network driver
    > writes various pieces of info to this, such as notification of new link
    > requests, link failure, etc.
    >
    > }Is this the mailbox to return network information defined with
    > }LIB$ASN_WTH_MBX ?
    >
    > That function does do that - when used to connect to the "_NET:" device
    > (which is the DECnet device template) the mailbox that this produces is
    > the network command mailbox I mentioned above.
    >
    > This routine really is just a shortcut to do in one step what is normally
    > done in two steps (sys$crembx and sys$assign).
    >
    > }Where to find doc (VMS manual ?)
    > }
    > }Do you have an example in Fortran or C ?
    >
    > You are probably looking for what is known as non-transparent task-to-task
    > DECnet communications. This is analogous to TCP/IP communications but
    > perhaps a tad easier. The documentation for this used to be in the
    Networking
    > manual (volume 5A of the system management set, if you happen to have
    > access to the old printed documentation from a couple of versions back).
    > I checked Google and it now appears to be in chapter 8 of the manual
    > located here:
    >
    > h71000.www7.hp.com/doc/73final/documentation/pdf/DECNET_OVMS_NET_MAN.PDF
    >
    > There is an example of the non-transparent sort of thing in the
    SYS$EXAMPLES
    > directory. The various DB_*.C files are involved, with the actual network
    > stuff being in DB_SERVER.C and DB_REQUESTER.C (as the server and client).
    > These examples are aparently the basis for most programs written to use
    > this and are fairly complete in showing you how to do things - as I recall
    > the client does it's IO sunchronously and the server does it mostly
    > asynchronously, also demonstrating how to use IO completion ASTs to
    > handle the asynch IO.
    >
    > I don't know what exactly you are trying to do. You might actually be
    > able to get by with the "transparent" version instead of the
    "nontransparent"
    > version. This basically runs something on a remote system on demand. For
    > this you can specify a .com file to execute on the remote node just buy
    > doing an open on something like
    > node"username password"::task=my_proceedure
    > which will run my_proceedure.com from the default login directory of the
    > username you specified on the node you specified. That can send back data
    > by writing to sys$net, or receive data by reading from sys$net. As both
    > are the same, you have to be careful if you want to communicate in both
    > directions (I've never botherd doing so - not that I've ever used this
    > transparent DECnet for much).
    >
    > Here is a brief and not incredibly clear example of the use of transparent
    > DECent communications:
    >
    > $ set noverify
    > $ if p1 .eqs. "" then goto server
    > $ location = "''p1'""''p2' ''p3'""::""task=sq"""
    > $ type 'location
    > $ exit
    > $server:
    > $ define/user sys$output sys$net
    > $ show process/quota
    > $ exit
    >
    > This is both the client and the server (you could separate them if
    > you wanted, but this way is more tidy).
    >
    > Put it in the default login directory of an account. If you have that
    > directory as your current default directory and do this:
    >
    > $ @sq.com node username password
    >
    > specifying the correct data for the 3 parameters, it will not jump to
    > the server section, staying in the client section it will connect to
    > node and run the same sq.com file in a process owned by the specfied
    > username. On the server end it will jump to the server section in the
    > code where it will send back the process quotas for the process in which
    > it is running. Back on the client end, the data will be read and
    displayed.
    > Not real exciting, but it works. It cheats somewhat by not using explicit
    > open and read statments in the client part, instead relying on the TYPE
    > command do do these things for you.
    >
    > If I had a more clear example, I'd have used it. This is the only one
    > I could find laying around.
    >
    > The "non-transparent" version requires you to do all the setup, monitoring
    > of the command mailbox for messages, and shutdown manually. Note that all
    > the reads and writes are done with sys$qio[w] rather than native language
    > read and write calls. In return for the added complexity, you can have
    > a process declare itself to be a DECnet object to which connections can
    > be made (so any connection to "TASK=MY_OBJECT_NAME" is handled by it).
    > This is similar to a process declaring itself to be the handler for all
    > TCP/IP connections to a specific port number (via the listen() routine).
    >
    > I get the impression that I'm not explaining any of this very well.
    > Maybe someone else will do better.
    >
    > Anyhow, if you need to write to a mailbox on anyother system, you have to
    > create a server that runs on that system which will accept data over the
    > network and write it to the mailbox. This can be done via DECnet or via
    > TCP/IP (or UDP/IP if you don't mind loosing the occasional packet) or
    > any other networking software available to you.
    >
    > Note that if what you areally mean by "mailbox" is "the place where e-mail
    > is stored" rather than the VMS specific meaning of the term, then this has
    > probably not been very useful to you.
    >
    > --- Carl

  • Next message: John Gemignani, Jr.: "Re: iSCSI anyone?"

    Relevant Pages

    • Re: OpenVMS - Remot emailbox (Decnet)
      ... }> Standard VMS mailboxes are not network accessable. ... }What is a Decnet Mailbox as opposed to the one created with SYS$CREMBX? ... stuff being in DB_SERVER.C and DB_REQUESTER.C. ...
      (comp.os.vms)
    • Re: Slow Response Times
      ... you're going to see a mailbox labeled "System Mailbox" with some ... excessive amount of messages on the server. ... To throw another curve into the mix, some of the users are complaining ... the network in general being slower than usual. ...
      (microsoft.public.backoffice.smallbiz2000)
    • Re: Outlook very slow to sync with Exchange 2003
      ... Not a network issue. ... want on the server and have NO issues with speed. ... trying to download messages... ... >> can literally take a full day to download an offline cache of the mailbox ...
      (microsoft.public.exchange2000.general)
    • Re: Recipient Update Service unable to see DC?
      ... network or with that server? ... Side bit of info I forgot in the first post: it is Exchange 2003 sp2 all ... running on Server 2003 sp1 one set of updates our of date. ... of them and was the first not to create the mailbox. ...
      (microsoft.public.exchange.admin)
    • Re: Fully parallel Scheme-based language w/ evaluator
      ... Windows Server 2003 and networks in simple - and irreverent - terms. ... If networking really is a big deal, ... Concepts and Terminology in Part I, and The Design and Deployment of Network ...
      (comp.lang.misc)
    Loading