ICC_OPEN_ASSOC using Pascal

[Brian Reiter]

Hi Folks,

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.

cheers

Brian

[Ruslan Laishev]

Hi!

Is there . LIS files ?

[Brian Reiter]

Hi there,

There would be, but the forum software seems to dislike them.

Ah well, will try a different extension.

cheers

Brian

[Brian Reiter]

And now the listings - it has to be .TXT files not .LIS

[Ruslan Laishev]

Have you tried run under DEBUG ?

[Brian Reiter]

Yep, same thing. Access violation as soon as the AST fires.

[Ruslan Laishev]

logical_name ,
  'ICC$REGISTRY_TABLE',

Descriptors ? Or just ASCIZ string ?

[Brian Reiter]

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).

cheers

Brian

[John Gillings]

Brian,

   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/

[John Gillings · Accepted solution]

Brian,

   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.

[Brian Reiter]

Hi John

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. 

cheers

Brian

[Jeremy Begg]

Hi Brian,

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).

[Asynchronous,Check(NONE)]
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.

Regards,

Jeremy Begg

[Brian Reiter]

Hi Jeremy,

Its always good to have a number of solutions. I've found the ICC to be a very usefl tool.

cheers

Brian

[John Gillings]

"[immediate]" excellent!

(I really miss the Pascal compiler)

[Richard J Maher]

See attached COBOL example if anyone has such a requirement in the future.

[Brian Reiter]

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.

[Limage]

Hello,

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.

[Hoff]

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.)