Conference rocks::dec_edi

I have just read in note 2784.3 that the OFTP gateway does not support a PVC.

"
You're absolutely correct.  The programming interface is different
for setting up PCVs and SVCs and our OFTP Gateway is only coded
to set up SVC virtual circuits.
".

I am confused by this statement :-
my customer has been receiving transmission files from his trading partner
over a PVC and via OFTP on dec/edi (which uses PSI and DECnet/OSI software)
quite successfully on a daily basis (they do not send outgoing ones), 
so I am confused by this statement. 

The error I have reported in .1 
happens every day - but nevertheless he does receive some files.

Does the above statement refer to incoming or outgoing calls ?
Are the errors I have reported in note .1 related to the PVC statement
above ? Can somebody please clarify what is /is not supported.

regards,
Andrew

>"
>You're absolutely correct.  The programming interface is different
>for setting up PCVs and SVCs and our OFTP Gateway is only coded
>to set up SVC virtual circuits.
>".

Andrew - you seem to have answered your own question?

Mark

    So why is the customer receiving files over a PVC into dec/edi ?
    
    Andrew

Andrew,

Dave Nelson is "Mr OFTP " these days!

Mark

    PSI QIO programming interface is used in the OFTP Gateway.
    
    When setting up the virtual circuit for outbound calls, the 
    QIO system service IO$_ACCESS is used.  One of it's parameters 
    is the NCB; the Network Control Block.  For PVC circuits you 
    must specify the PVCNAM (PVC identifier) in the NCB.  We do 
    not use the PVCNAM code and do not assign a PVC identifier to the
    NCB when setting up the IO$_ACCESS call.  We use the DTE address 
    and sub-address supplied in the Connection Details.  When the DTE 
    is used the call becomes a SVC.
    
    So, based on what is stated in 2999.1, it looks like the OFTP Gateway
    is trying to send a transmission file and is unable to.  The
    system error, SYSTEM-F-FILNOTACC, means a virtual circuit does not
    exist on the channel.  This doesn't seem to effect incoming calls.
    
    For incoming calls, all that is checked is the caller's DTE 
    and the network name supplied in the incoming caller's NCB.  
    If they match a Connecton Details record then we accept the call.  
    As stated in the programming documentation, we use the incoming 
    call's NCB when accepting the call.  I believe this explains why 
    incoming calls work.

Thanks Dave. The problem has been solved (by accident !) :-

They have had problems with the archiving utility during the past
weeks due to a quota being exceeded
(many/hundreds of files had accumulated in the storage areas).

Everytime they restarted the archiving 
utility, it tried to recover from the previous failed archive 
(seems like a vicious circle).

We eventually did a manual backup/delete of the storage areas, and this
solved the archiving problem (now works ok).
Then the oftp started working ok (messages arrived in dec/edi). 
I guess the problem was with the
gateway software not being able to create/access files in the storage areas.


On the PVC issue (FYI) ...

I have traced the GAP protocol from the DEMSA to
the dec/edi machine, and the calls arriving on the PVC channel; 
everything works fine: counters get incremented; messages arrive;

e.g. using 

$ TRACE
  START/width=132/data=ascii/LIVE X25GAP
$!  START/width=132/data=ascii/LIVE ort1"traceuser user"::X25L3CHANNEL.pvc-JIT


The PVC is set up from the TP's DTE to the Demsa box's DTE: calls
arriving at the demsa are forwarded to the DEC/EDi machine
based upon the sub-address (the X25 access filter on D is set up
to match this DTE subaddress).


     A			B		C		D

Trading partner --> X25 cloud  --> DEMSA router ---> Dec/EDI machine
				   (PSI,phase IV))   (Decnet/OSI,Phase V))


When I do a $ repl/enable=network on D (OJIT3), I see the following

.
.
.
%%%%%%%%%%%  OPCOM  12-FEB-1997 11:04:44.23  %%%%%%%%%%%
Message from user SYSTEM on OJIT3
Event: Port Terminated from: Node 0:. X25 Access,
        at: 1997-02-12-12:03:21.918+01:00Iinf
        Client=X25 Server Client ojit3, 
        Remote Port=Node 0:.ojit3 X25 Access Port PORT_0004, 
        Type=Switched, 
        State=Cleared, 
        Reserved="", 
        Call Direction=Incoming, 
        Call Association=X25 Access Filter ojit3, 
        Target DTE Address=399937640003, 
        Calling DTE Address=399937500004, 
        Protocol Identifier='00000

.
.

The "type=switched" seems a SVC is used (set up) on D, even though a PVC
is set up from the TP to the Demsa.

Also, When I do an " $ mcr ncl show x25 access port * all"  on OJIT3
I see that all ports are of type switched (not permanent).

e.g.

.
.

Node 0 X25 Access Port PORT_0004
at 1997-02-12-10:50:36.200+01:00Iinf 
 
Identifiers 
 
    Name                              = PORT_0000 
 
Status 
 
    Client                            = Generic Client User Process 
                                        "Pid=00000091 Device=NWA6:"

    Remote Port                       = <Default value> 
    Type                              = Switched 
    State                             = Open 
 
Counters 
 
    Data Octets Received              = 0 
    Data Octets Sent                  = 0 
    PDUs Received                     = 0 

.
.
.

The above seems to confirm what you said Dave about PVC's and SVC's
(your explanation helped a lot).


regards,
Andrew