Re: Oracle APPC - anyone used it

From: Dave Dargo <ddargo_at_us.oracle.com>
Date: 9 Feb 1995 16:35:43 GMT
Message-ID: <3hdg8v$eme_at_dcsun4.us.oracle.com>


a-cha <adrian_at_a-cha.demon.co.uk> writes:

>What is performance like using APPC? We will need to achieve a very
>quick response to queries. The idea is that our Forms 4gl application
>will fire off queries using APPC to a credit check agency that uses
>SNA LU6.2 as athe communications path. If we do this while there is
>a TeleSales session going, we have to do this while a customer is
>on the telephone.
>
>The link between us and the credit agency is a 64kbps leased line,
>so I hope this wont get full, but I am concerned about the time
>taken on the RS/6000 which runs the APPC gateway to setup and
>execute the LU6.2 conversation.

Your issue will not be the gateway or the RS/6000. I'm not sure about your network. I can describe a simple application and configuration:

Sun SQL*Plus --> TCP/IP --> 7.0.16.4 on AIX --> PG4APPC --> CICS/MVS

Executing a SQL*Plus script that calls a stored procedure on the RS/6000 which passes a 6 byte customer record to a CICS COBOL program. The CICS COBOL program looks up a customer record from the sample VSAM file (I believe FILEA) and returns the record to SQL*Plus.

This is on our internal development machines and network (which are quite busy). Depending on how busy everthing is, it may take 1 - 2 seconds to execute the initial transaction (i.e. get CICS swapped in, establish the conversation etc.) Subsequent executions are always sub-second and are quite often sub 1/10 second. Basically, not much more time than to process the VTAM messages.

Your actual response times are going to be related to the complexity of your CICS (if that's your TP monitor) application and your network. You are unlikely to find the issue to be in the PG4APPC.

Subsequent executions of the above described transaction each establish a new conversation. Performance is not an issue.

Dave (ddargo_at_us.oracle.com) Received on Thu Feb 09 1995 - 17:35:43 CET

Original text of this message