Problem with sys$icc_open_assoc and SYSPRV/SYSNAM

[ptrskg]

Hi,

I'm planning to use to ICC as comm. protocol between some processes in a cluster and my tests seems to work ok.
BUT, I need SYSPRV and SYSNAM to have it running. It is the 'open' verb that requires this and from what I see in the manual it should'nt need those.

Am I doing something wrong/odd in my coding or...?

I attach a piece of code and my environment is "HP C S7.1-013 on OpenVMS IA64 V8.3-1H1".

Thanks for any help.

Peter

[Volker Halle · Accepted solution]

Peter,

did you check the chapter titled 'Creating Intra-Cluster Communications Security Objects' in the System Manager Manual Vol. 1 ?

It refers to the ICC startup procedures and SYS$STARTUP:ICC$SYSTARTUP.TEMPLATE.

Volker.

[Hoff]

Random semi-useless comments: If this is new code, then I'd tend to look at IP sockets or other such. ICC does work and it works nicely, but it's not portable, and I really don't like writing new non-portable code if I can avoid it.

That's also a very early C compiler. V7.3 is current.

And I'd agree with Volker; that you're probably not configuring the ICC security objects before you start using ICC. This is the SYS$MANAGER:ICC$SYSTARTUP.* stuff.

[John Gillings]

Peter,

Nothing wrong in your code. Since the association you're opening has cluster wide visibility SYSPRV and SYSNAM are appropriate. Use ICC security objects to specify access for unprivileged users.

Unless portability is a specific goal, I disagree with Hoff. Portability is a laudable goal, but it's a significant added cost, and will often kill performance because you have to choose the lowest common denominator. ICC does things that sockets can't come close to in terms of flexibility and performance.

I've been using ICC heavily of late and discovered several things that you won't find in any manuals, but you really need to know. Send me mail for details (my name with at in the middle and dot com on the end).

[Richard J Maher]

Hi Peter,

In case it helps you with some event processing examples (and for all those out there that wanted to know how to do this in COBOL :-) please see attached.

The question I want answered about ICC is "Will it continue to be the API of choice for future hi-speed cluster interconnects such as infiniband, or a. n. other.?"

Wasn't $icc highly-tuned and targetted specifically at Alpha anyway?

Cheers Richard Maher

[ptrskg]

Thanks for your answers, I'll do my homework better next time!

My plan is to replace an old sharemem based IPC and in my tests ICC gives better performance than sockets.

Peter

[Ian Miller.]

ICC uses whatever the cluster interconnect is so I would it expect it to continue to do so for future cluster interconnects.

[Richard J Maher]

Hi Ian,

Sounds good. But I was expecting some sort of new Intra-Cluster Global Section C RTL, or perhaps an optimized, more hardware specific, API.

It would be nice to know if ICC will continue to be *THE* high-perfromance intra-cluster API or will merely support (in a fashion) future interconnects.

Cheers Richard Maher

[John Apps]

If you want something portable, Open Source and extremely fast (sub-millisecond), then you and others might want to take a look at http://www.zeromq.org/
We will release an OpenVMS (Integrity only) version in the next few days with C++, C and Java APIs, to be followed by Python and Perl and whatever else is available on OpenVMS not long after.
There are APIs in just about every programming language on other platforms, so one can build one's core back-end on OpenVMS -reliability, availability, scalability, security- and interface to it from whatever platform and language is desired.

We will write a short announcement here and elsewhere in the near future on the availability.

[John Gillings]

re: John Apps:

Have I missed something?

>We will release an OpenVMS (Integrity
>only) version in the next few days

>If you want something portable

Unless you want it portable between OpenVMS systems on Alpha and Integrity (and forget about VAX...)??