Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with sys$icc_open_assoc and SYSPRV/SYSNAM

 
SOLVED
Go to solution
ptrskg
Frequent Advisor

Problem with sys$icc_open_assoc and SYSPRV/SYSNAM

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
10 REPLIES 10
Volker Halle
Honored Contributor
Solution

Re: Problem with sys$icc_open_assoc and SYSPRV/SYSNAM

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
Honored Contributor

Re: Problem with sys$icc_open_assoc and SYSPRV/SYSNAM

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
Honored Contributor

Re: Problem with sys$icc_open_assoc and SYSPRV/SYSNAM

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).
A crucible of informative mistakes
Richard J Maher
Trusted Contributor

Re: Problem with sys$icc_open_assoc and SYSPRV/SYSNAM

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
Frequent Advisor

Re: Problem with sys$icc_open_assoc and SYSPRV/SYSNAM

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.
Honored Contributor

Re: Problem with sys$icc_open_assoc and SYSPRV/SYSNAM

ICC uses whatever the cluster interconnect is so I would it expect it to continue to do so for future cluster interconnects.
____________________
Purely Personal Opinion
Richard J Maher
Trusted Contributor

Re: Problem with sys$icc_open_assoc and SYSPRV/SYSNAM

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
Occasional Advisor

Re: Problem with sys$icc_open_assoc and SYSPRV/SYSNAM

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.
How many beans make 5?
John Gillings
Honored Contributor

Re: Problem with sys$icc_open_assoc and SYSPRV/SYSNAM

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...)??
A crucible of informative mistakes
Richard J Maher
Trusted Contributor

Re: Problem with sys$icc_open_assoc and SYSPRV/SYSNAM

If only we had access to Oracle's DLM with the mega-lock-value-blocks that implemented cache-fusion (or so I'm reliably informed) then that *would* be worth talking about!

Yes, I did say "Oracle's". I know the irony is almost to much to bear :-(

If only the best VMS engineers hadn't been wasting their time on *nix semaphores, or the best Rdb engineers violently opposed to clustering (and anything other than Row-Cache) then maybe the story would've been different?

Transfer huge amounts of data through a cluster *as fast as possible* simply by promoting/demoting locks? I for one like it very much!!!

Still, I see Java 7 promises "New" Asynch i/o - hoorah! Best get all HP/VMS resources on it quick :-( After Java 6 presumably?

Cheers Richard Maher

PS Still struggling to see the Added-Value for VMS license-payers in poorly-performing VMS versions of *nix software that arrives 2 to 10 years late.