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

ja JohnDApps at gmail.com
Mon Mar 2 12:06:34 EST 2009


On Mar 2, 5:39 am, "Richard Maher" <maher... at hotspamnotmail.com>
wrote:
> Hi CY,
>
> <christ... 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 :-(

Do tell us, dear Richard, what the medication is that you take in
order to continue with these lovely emotional diatribes? Once we know,
we might be able to offer an alternative medication allowing you to
concentrate your energy on things more useful to the community at
large..



More information about the Info-vax mailing list