|
Guillermo, With TCP/IP, you will not be using the APPC API's. Instead, you will be using Sockets. The good news is that you will no longer be dependent on the Router (CAWin, Netsoft, Wall Data, etc) and that you will not have to worry about Send Mode, Receive Mode, request to send, or any of those state type operations in APPC. The bad news is that you will have to rewrite some of your code. Sockets themselves are not horribly difficult, but they are DIFFERENT then APPC. Your first try will probably be interesting and perhaps frustrating, but after you figure them out, they tend to be a piece of cake. But if you where able to figure out APPC, Sockets will be easy. One big difference is that with APPC, you invoke/start the server side from the client. With Sockets, the server side must already be running and waiting for a connection request. The other very major difference is that sockets are NOT record oriented but stream oriented. You might send 2 256 byte buffers on one side, but receive 1 128byte buffer followed by a 256byte buffer followed by a 128byte buffer on the other side. The bytes are all in the same order as when they where sent, but the buffers might be different. It is up to you to reassemble the data into "records". This reassembly process is normally handled by adding a record length field to the very beginning of the record. This tells the app how many bytes to read. This is easyiest if the sending/receiving and other Sockets functions are well enchapsulated. Very easy to do if you are using C++ (or other OOP language), a little harder for procedural languages like RPG, C & VB. You will want to start with the "OS/400 Sockets Programing" (SC41-4422 or QBJANN01 in V3R7 Softcopy) for info on the AS/400 side and your compiler vendors documentation on "TCP/IP or Sockets" on the PC side. If you are using MSVC, then check out the CSocket class. If you want, I can send you the header files for my class (ccSocket) that I use for MSVC and the ILE/C headers I use. I can not give you the code, but I can sell it. My class not only handles stream vs record conversions as discused above, it also does compression and logging (VERY important when you need to figure out what is really happening!). The PC side is a DLL written in MSVC v5.0. The AS/400 side is in ILE/C. If you are interested in this option, send me your phone number via private Email (bcrothers@netdirect.net) and we can discuss it. Note: These class's are NOT a commercial product and as such would come "as is". However, they are imbedded in a commercial product and are "industrial strength". Regards, Bob Crothers Cornerstone Communications -----Original Message----- From: Guillermo Andrades [CPI] [SMTP:gab@cpisoftware.com] Sent: Tuesday, February 03, 1998 6:10 AM To: MIDRANGE-L@midrange.com Subject: APPC APIs in TCP/IP CAw95 Any experiences in using APPC APIs programming (or similar) in TCP/IP environment? these APIs where used to access from a Windows Program to interactive (program to program) communications, and into it to make all type of AS/400 code. i.e. using ehnappc.dll (16 bits) or e32appc.dll -or similar name- for 32 bits. the ones developed for me works but need the netsoft for 802.2. any other programming for connectivity in TCP/IP experiences wellcome! TIA. ____________________ Guillermo Andrades CPI, Madrid +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to "MIDRANGE-L@midrange.com". | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +--- uucp +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to "MIDRANGE-L@midrange.com". | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
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.