07-18-2011 01:59 AM
I'm experimenting with the Intra Cluster Communications calls, we're looking at making some legacy software cluster aware and the ICC calls seem like a useful ser of tools. Anyway, I cannot seem to fathom out the exact set of parameters required for the connect/disconnect AST routine when using the ICC_OPEN_ASSOC. The program crashes wih an access violation (both attached).
I'm using OpenVMS V8.3-1H1 on an RX2660, the problem occurs with Pascal versions V6.0-111 and V6.1-119. I've attached (with any luck) the required files.
The server sits there quite happyily until a connection event occurs, at which point it bombs up. I've tried various combinations of paramters for the AST routine but with no change.
Hope someone can help.
Solved! Go to Solution.
07-18-2011 03:01 AM
According to the prototype in starlet. it'll go as a CLASS_S so I'll assume its passed by descriptor. This method seems to work for other system service calls from Pascal and certainly doesn't seem to cause any errors in the call to ICC_OPEN_ASSOC (it returns SS$_NORMAL).
07-18-2011 02:40 PM
I've used ICC quite a lot, and very successfully. It's an excellent mechanism, but the coding can be a bit obscure. I'd also warn that you need to be at up-to-date patch levels, as there were some system crashing bugs in ICC a few years back. Here's a sample call from my MACRO32 code (oh, and note that several of the system supplied macros for ICC routines are badly defined and don't work! Unlikely to be the case for Pascal). This looks pretty much equivalent to your procedure call.
$ICC_OPEN_ASSOC_S - ASSOC_NAME=ServerName,- ; Class S descriptor ASSOC_HANDLE=icc_assoc_handle,- ; long word by reference init to 0 LOGICAL_NAME=ServerName,- ; same descriptor as above LOGICAL_TABLE=ICC$REGISTRY_TABLE, -; Class S descriptor "self string" CONN_RTN=ICC_ConnEvent,- ; routines by reference DISC_RTN=ICC_DisconnEvent,- RECV_RTN=ICC_Receive
Notice that your ACCVIO is occuring in YOUR code, not in $ICC_OPEN_ASSOC. It's in the prologue of your connection_event routine (line 30). I suspect it's because you've declared all the arguments as VALUE not VAR, so the Pascal prologue is attempting to create local stack copies of all the arguments. I'd have to think about it harder to work it out exactly what the declarations should be, but for a first pass, I'd just declare everything as VAR LONG, set a break point in the routine and examine what gets passed in.
Here's my ICC_ConnEvent routine
.ENTRY ICC_ConnEvent,^M<R2,R3,R4,R5,R6,R7,R8,R9,R10,R11> ArgList EvtTyp ConnHandle DataLen DataBuf ReplyLen PID UserName CMPL EvtTyp_Arg(AP),#ICC$C_EV_CONNECT BNEQ ICC_AbortConnect BLBS icc_finish,ICC_RejectConnect MOVAB ServerName,R9 MOVL DataBuf_Arg(AP),R8 MOVL DataLen_Arg(AP),R7 CMPC3 R7,(R8),@DSC$A_POINTER(R9) BNEQ ICC_RejectConnect MOVZWL accept_w_len,R3 CMPL R3,ReplyLen_arg(AP) BGTR ICC_RejectConnect GetStruc clcx,R10 MOVL PID_Arg(AP),clcx_l_pid(R10) Copy #clcx_k_maxuser,@UserName_Arg(AP),clcx_t_user(R10) CLRL clcx_l_eos(R10) CALL ServerNewClientContext (R10) InsertQueueTail clcx_queue R10 $ICC_ACCEPT_S CONN_HANDLE=ConnHandle_Arg(AP),USER_CONTEXT=R10 - ACCEPT_BUF=accept_t_buf,ACCEPT_LEN=R3 INCL ICC_ConnectCount RET ICC_RejectConnect: $ICC_REJECT_S CONN_HANDLE=ConnHandle_Arg(AP) RET ICC_AbortConnect: MOVL #SS$_ABORT,R0 Abort #^A/CONN/
07-18-2011 05:21 PM - edited 07-18-2011 05:25 PM
Rereading my code, I notice that several of the arguments to the AST routines are passed by immediate value. So your routines will need to deal with that. I don't think Pascal has a way to describe an incoming argument as passed by immediate value, so you'll probably have to hack it as a reference argument and use IADDRESS to fetch the argument value. You definitely WON'T be able to define them as VALUE parameters (in the Pascal) sense, as the prologue will ACCVIO when it attempts to copy the argument values to stack temporaries (exactly what you're seeing).
This will be necessary for arguments EVENT_TYPE, CONN_HANDLE, DATA_LEN, P5 and P6.
The DATA_BFR and P7 arguments are NOT CLASS_S descriptors, they're just pointers to text.
Let me know if you have trouble making this work. I'll have a stab at a Pascal declaration.
07-19-2011 12:11 AM
Thanks for the hints, making all the parameters UNSIGNED and passing by reference does the trick. IADDRESS can then be used to examine the values. I will worry about the string parameters at some other time. Not sure I need to worry about them at the moment, although something like C_STR_T mechanism may be the route to go.
07-21-2011 11:01 PM
I realise you've found a solution but FYI here is how I did it in my own code (part of the SOPHAST product we sell).
Function Connection_AST (event_type : [immediate,long] unsigned;
conn_handle : [immediate,long] unsigned;
data_len : [immediate,long] unsigned;
var data_buff : [unsafe] SOPHAST_R_Command;
reply_buflen : [immediate,long] unsigned;
client_pid : [immediate] ICC_PID;
var username : [readonly] ICC_Username_Buffer
) : integer;
I've found ICC to be interesting & powerful but also very frustrating until you get the hang of it.
08-01-2011 03:02 AM
I often threaten to use COBOL, just to wind the management up. Its bad enough trying to find programmers willing to learn Pascal, they would all prefer to the Visual methods, we can get any number of VB/C/C++/C# programmers but you get insurrection if they're asked to work on VMS or Unix.
Still, the more examples of this kind of stuff the better.
02-18-2012 09:04 AM
Does anyone have a program example in fortran using icc$ modules ?
I always receive a return status of 0 instead of 1.
I suppose that something's wrong in my code.
02-18-2012 10:39 AM - edited 02-18-2012 11:14 AM
The general behavior implies you're not synchronizing correctly somewhere; seeing a zero usually means the operation hasn't been called for some reason, or that the AST hasn't completed. (But without seeing where you're getting that zero from, a specific answer isn't feasible.)
Please post your (apparently buggy?) Fortran code; a reproducer. (By posting your existing Fortran code, folks can start by reviewing existing (and non-functional) Fortran code for potential errors and issues. And we've all written our share of source code bugs over the years, too.)
And FWIW, there's a Pascal example call already posted in this thread, if you haven't seen that.
(I'd start your own thread with this, as this doesn't seem to be the exactly same as the ICC Pascal question you're starting with; you're not able to manage ths thread, and you're also effectively burying your Fortran question.)