|
Dave - is this a sockets program via tcp or a asynch or bisynch program via rpg or similar? In a asynch program I do with a credit card co, when they send a packet, I send back an ACK (a 1 character hex value). If they are done, they send an EOT (finish ack?) and I send a final ACK. All the signals are 1 character hex values, which when converted to ascii, equal the ascii value the other server is looking for. Below is a list of hex values I use (don't need all of them). D* communication characters d* warning: this table works with tables QASCII & QEBCDIC only D Soh S 1A inz(x'01') start of header D Stx S 1A inz(x'02') start of text D Etx S 1A inz(x'03') end of text D Etb S 1A inz(x'26') end transmit block D Enq S 1A inz(x'2D') enquiry D Syn S 1A inz(x'16') synchronization D Eot S 1A inz(x'37') end of transmit D Ack S 1A inz(x'2E') acknowledgement D Nak S 1A inz(x'3D') negative acknowledge D Fs S 1A inz(x'1C') field seperator D Plus S 1A inz(x'4E') hangup hth jim franz ----- Original Message ----- From: "Dave Snyder" <dsnyder@blcnet.com> To: <midrange-l@midrange.com> Sent: Thursday, July 25, 2002 4:41 PM Subject: Port communication problems A shot in the dark... We are having a very strange and trouble-some problem with communications with another site that I was wondering if anyone would have any insight into. The site on the other end (servers of some type) claims that they are sending us (an AS400) a Finish Acknowledgment packet when the communication is complete They then say the host should be responding with just an Acknowledgment packet, instead, the host is responding with a Reset Acknowledgment packet - this is unexpected and causing a packet to be dropped that it is not expecting. From what I understand, the Reset Acknowledgment is the Hosts way of saying that its killing communications and doesn't want to talk any more. We are on v4r5 and talking via a T1. Anybody have any ideas what might be causing something like this? Dave This is the best I could describe...does it make any sense or shed any light on our dilemma?...TM _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l or email: MIDRANGE-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.