RE: ILE RPG SOCKET PROTOTYPES

[Bob Crothers <bob@xxxxxxxxxxxxxx>]

Paul,

Nobody else is commenting, so here is my 2 cents:

First, by ICF programming, I assume you mean APPC with ICF files.  All 
of my experience in this area has been AS/400 to the PC world.  Never 
AS/400 to AS/400.

My sockets experience has been both PC to PC and PC to AS/400.  Again, 
never AS/400 to AS/400.

There are a couple of issues when a PC is involved that you do not 
have when doing APPC between AS/400's:

A) Blocking.  On the PC side, records are not unblocked 
automatically...not hard to do, but it must be done. With ICF, this is 
done automaticly on the AS/400 side.  With Sockets, you must 
reassemble the records on both the PC and AS/400 sides (even if you 
are doing AS/400 to AS/400).  This is a biggie.  Not hard to do, but 
if you don't do it with Sockets...your app will work fine until some 
minor change in your network architecture (there was a post just last 
week about this).

B) byte order differences.  The AS/400 is "big edian" or High order 
byte first.  Intel PC's are little edian or low order byte first. 
 APPC/ICF gives you no way to handle this.  It comes standard with 
Sockets.  A work around is to always exchange numeric data as zoned. 
 No packed or binary numbers.  This approach works well and simplifies 
the ASCII/EBCIDIC issues.

C) ASCII/EBCIDIC - which one do you use in the conversation?  This is 
an issue with both Sockets and ICF conversations.  I think it is 
easier to deal with using sockets since on the /400, you are already 
dealing with the buffers and probably have something in between your 
RPG program and the Sockets interface (a bit of "C" makes Sockets a 
LOT easier).

ICF conversations are very structured.  You must do request to send, 
send data,  request to receive, receive the request to receive, start 
receiving and then request to send (it has been awhile, so this is 
probably not 100% accurate, but the drift is correct).  Or APPC will 
blow you out of the water...big time.

On the other hand, Sockets does not enforce anything like this.  When 
you want to send, send.  When you want to receive, then receive. 
 There is of course a penalty with this "looseness".  If both sides 
are sending and neither side is receiving, you will probably deadlock 
because your conversation is messed up.  It is up to you to keep 
things right.

A very big issue is that APPC requires an SNA compatible 
network...which the Internet is NOT.  Sure, you can do things like SNA 
over IP, but those are kludges and require extra layers of 
conversion/translation.

Also, in the PC world, APPC requires Client Access.  Not nice if you 
are selling your product.

On the other hand, Sockets (TCP/IP) does NOT require any Client Access 
or any other 3rd party software except a TCP/IP stack...which ships 
with Win95/98/NT and our beloved AS/400 (V3R1 and up).

Not having Client Access in the picture alone is reason enough to use 
Sockets.  And having your program/product "Internet Ready" is 
something the marketing folks really like.

From the customer perspective, Sockets based programs are "Load & Go". 
 Anything involving Client Access (APPC) is much more complicated. 
 And if you are using Data Queues, DDM, etc, it gets MUCH worse as 
exact versions, service pack levels, etc start coming into play.

On the other hand, I have not seen a faster way to move a lot of data 
to/from an AS/400 than through a custom APPC conversation.

Which one is easier?  I think sockets is better...especially if you 
wrap the API's in a bit of C.  C is awesome at manipulating buffers, 
blocking/deblocking and stuff like that.  Use RPG to do the database 
 work (at least on the AS/400).

BTW, if all you are doing is talking to another AS/400 in the same 
room, then ICF/APPC is probably easier.  But let either side leave the 
/400 or the room, and Sockets will usually win.

Now, after all the above, I realize I did not answer your question: 
 "Which one is easier?".  If you are going AS/400 to AS/400, the 
ICF/APPC route probably is.  If a PC or the Internet is involved, then 
I would say Sockets...especially if you are not afraid of "C".  Note: 
APPC can be done with VB and no "C", but it is quite slow.

Regards,
Bob Crothers
Cornerstone Communications, LLC
www.faxserver401.com

another day done
all targets met
all systems fully operational
all customers satisfied
all staff keen and motivated
all pigs fed and ready to fly...




-----Original Message-----
From:   PaulMmn [SMTP:PaulMmn@ix.netcom.com]
Sent:   Saturday, August 14, 1999 11:56 AM
To:     MIDRANGE-L@midrange.com
Subject:        Re: ILE RPG SOCKET PROTOTYPES

How does Socket Programming compare to ICF or SAA communication 
programming?

--Paul E Musselman
PaulMmn@ix.netcom.com


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midr  
ange.com.
| Questions should be directed to the list owner/operator: 
david@midrange.com
+---

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@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
+---