Re: OpenVMS - Remot emailbox (Decnet)

From: Carl Perkins (carl_at_gerg.tamu.edu)
Date: 07/15/03 

Date: 14 Jul 2003 20:36 CDT

"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

Relevant Pages

  • 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: OpenVMS - Remot emailbox (Decnet)
    ... >}> Standard VMS mailboxes are not network accessable. ... Try DECnet ... > the mailbox drivers. ... > server process that accesses it). ...
    (comp.os.vms)
  • 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)
  • Error while creating exchange 2K mailbox
    ... I am using the same code as the microsoft article "Creating a Recipient Using ... TYPE MISMATCH" error when trying to create a mailbox. ... I have implemented a test network with Windows 2003, AD, and Exchange ... Dim objContainer As IADsContainer ...
    (microsoft.public.exchange2000.development)
  • 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)
Loading