× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: APPC APIs in TCP/IP CAw95
  • From: Bob Crothers <bcrothers@xxxxxxxxxxxxx>
  • Date: Tue, 3 Feb 1998 09:45:30 -0000

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 thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.