Conference rocks::dec_edi

Robert,

DEC/EDI  will try to send up to 64k buffers. i.e. if you have data larger
than that it will go right up to that level.

Perhaps process could not handle it. If necessary we can do cut
down buffers - but it requires a code change.

Do a test with smaller documents and then work up.

Mark

    Mark,
    
    At the point this error is occurring, we weren't trying to send a
    document.  I had entered a bogus trade command which should have failed
    with an file not found, but never got that far.
    
    I'll see what OBB had to say and possibly have the customer contact
    their TCP/IP software provider and see what they say.
    
    Thanks,
    
    -Robert

Mark,
 
    I received the following from a contact on the OBB support team.  Based
    on this, I think I will need to do an escalation.
    
    Thanks,
    
    -Robert
----------------------------------------------------------------------
I took a look at the note file entry. There is a maximum transfer/buffer size
that is dependent on the network transport or operating system used. I believe
that TCPware must have a maximum packet size of 64K. The unfortunate thing
is that it is up to the application to make sure any data it is sending does
not exceed the 64K limit, if it does it must break up the data in to 64K 
chunks. In your case, EDI or the EDI application is not doing a good job of
this (and most likely did not realize the it needed to). I am sure that
someone in the notes file will confirm this.
    

ahh yes - I just remembered, We always send back 64k regardless
of the actual amount of data.

We need the rules from OBB Engineering.

Mark

    I'm not out of stupid questions yet, not by a longshot!
    
    This customer is now trying to switch from IP to DECnet...he can set
    the server to use DECnet only, but the client must be able to use both.  
    
    We can get the IMF started up on the server with a trade call from the
    client, and we connect via DECnet, but for some reason the validation
    inside DEC/EDI appears to try to validate the request using the IP
    nodename of the client.  IE,
    
    VAXB, vaxb.prd.wcus is the client using IP and DECnet
    WCEDI1 is the server using DECnet only
    
    I've verified that the proper proxies are in place.
    
    With an entry for VAXB only in the node registry on the server, when
    doing a TRADE POST from the client we get a DEC/EDI user not
    authorized.  If we add an entry for vaxb.prd.wcus, we get a server
    error.  Looking at the trace, we can see no problems in the log for the
    first scenario.  For the second scenario, it is trying to use the IP
    node name to make a callback to the client and failing for obvious
    reasons.
    
    My question is why is EDI trying to use the vaxb.prd.wcus node name for
    validation?  My guess is that this nodename is passed from the client
    to the server, but I don't know where we are getting it from.  If so,
    how do I get it to use the DECnet node name?
    
    Thanks,
    -Robert

    Robert,
    
    DEC/EDI obtains the clients hostname via ObjectBroker...ObjectBroker is
    supposed to shield us from the underlying transport so we have no idea
    whether the name is a DECnet or tcp/ip name, we just use what we are
    given.
    
    Graham