[Info-vax] The Magnificent 7 (Or as Jose would say "1")

[Richard Maher]

Hi CY,

<christery at gmail.com> wrote in message
news:cfe9a3e6-51b9-4176-92fd-d6a6d15c0646 at j8g2000yql.googlegroups.com...
> Ahh, we already have a special working solution based on DecNet, that
> is not possible to get 100% communication with (with reasonable cost/
> time) when purchasing
> newer systems. (DecNet isnt that wiedly spread)

Ok, if you're using DECnet at present then you'll find a shift to TCP/IP's
"INETd" as transparent as you can get. (NB: One will be stream oriented and
the other had record boundries.) INETd is very simple and AFAIK available
everywhere.
>
> ABB:s VIP (really just socket comm) is used.  (And on PLC level I
> accept that, OPC can be used to get a standard for interfacing)
> But its a bit more handy to say "use xxx product" from M$ and its
> "free" to answer the Q on how to communicate when they are building on
> windows.

Sorry, don't understand ABB:s, VIP, PLC, or OPC.

Are you needing all the baggage of a "Message *Queue*" (store-and-forward)
or do you just need task-to-task communication Windows-to-VMS?

>
> The Microsoft MTS (yes we had one or two) is not there anymore in my
> scope,
> but to interface our RDB/ACMS  (and much code written in F90, yuck - I
> like C) with something-else without latency would be great, the
> problem is it sholudnt
> cost a lot and be native for windows programmers (.NET).

This looks reasonably straight forward to me: -
http://msdn.microsoft.com/en-us/library/system.net.sockets.aspx
(Although Java docs is spartan at times, at least you can find
methods/attributes a lot easier than MSDN!)

The main question you have to ask yourself is "Are we happy having one VMS
process for each Windows client?". If the answer is yes then stick to INETd
(aka Auxillary server on VMS). There are examples in ucx$examples and I can
provide additional examples if you'd like. The best news is that it'll cost
you no more!

The fact that you're using ACMS suggests that you might want a M:1
relationship between clients and servers and, like others, you've found
ACMS-client offerings in this space to be bollocks. But this is where your
"it shouldn't cost a lot" goes out the window. If you want Transparent
Network Communications and Muti-Threading, Client Authentication,
Transactional Data Integrity, and Performance, all with no additional
software required on your client platform(s), then do I have a product for
you! (But it won't be cheap.)

>They dont
> like to fiddle around with bits and bytes. (I think anyway) Give them
> a float and tell them it can be in G-float or
> IEEE and they don understand the question.. Integers in motorola style
> or intel style... and so on.

When you say they're .NET Programmers do you really mean ASP or ASP .NET?

Endianness shouldn't be an issue with Intel but just swap bytes in the
Fortran/C if you have to and send floating-point numbers as ascii
exponential notation (and see no more rounding errors than is normal with
floating-point crap)

>
> //CY
>
> >
> > (BTW, what's wrong with some "TCP/IP thingy"? Functional requirements?)
> >

PS. The other option is to stick with what self-serving HP/VMS wankers have
forced on the VMS community for twenty years and that's Green-Screens and
FTP! Just stick your head in any VMS shop and ask them if their middleware
is FTP or ,at "best" ODBC :-(

ONC/RPC, DCE/RPC, ACMSxp, ACMS/Desktop/WebConnector, RTR, D/BMQ,
BridgeWorks, COM, SOAP/Toolkit, Axis2, WSIT, JAVA, gSOAP, just to name a
few. Come on CY, do you have any idea just how many license-payer dollars
have been pissed up against the wall by VMS employees on this party of the
century? How dare you find all these offerings as useless as every other VMS
developer!

Don't worry, looks like the after-party is rocking-on with AMQP and ZeroMQ.
Constant churn is the name of the game, but don't worry VMS will be long
gone before they run out of crappy *nix freeware to implement :-(