|
Hi David , On the server side when a socket server is brought up ,the three initial steps which are done are BIND(), LISTEN(), and ACCEPT() . So I thought I will do all these three steps in the same procedure , so that the user has to call only one procedure to get a server up . On the client side a socket application won't need to these steps.(BIND( ) is optional on the client side ) . As the server accepts a client connection request it creates a new socket descriptor for the client (in my example it is clnSd) . This is the socket which is used to communicate with the client (send and receive) . The original socket on which the server listens (retSd in my example) is kept open to listen to new requests . So if you want to spawn a new job for each client you accept , you have to pass the socket descriptor for that client (clnSd) to the child job . So the main server job has to do a givedescriptor( ) and the child job has to do a takedescrpitor( ) . I have a small program which does this . How it works is , while spawning a new job (doing a SBMJOB) the main job passes the internal job identifier of the main job as a parameter . As the child job gets active it writes its own job identifier to a dataq on which the main job is waiting . The main job after getting the child job's internal job identifier does a givedescriptor( ) to pass the socket descriptor (clnSd) . The main job has to wait till the child job is active , because you can not give a descriptor if the other job is not active . In the child job after writing that entry to the dataq , the child job waits on a takedescrpitor( ) . After it gets the socket descriptor from takedescrpitor( ) it is independent of the main job and communicate with the client . This is not a very efficient way to do this because , if child job takes a while to get active , the server job is waiting on the dataq indefinitely . But we can have a wait time for the dataq and come back to it in intervals if we don't get anything from it in the first read . Hope this helps. Thanks -Amit David Anderson <DaveTheWiz@worldnet.att.net> on 08/17/99 08:15:38 PM Please respond to MIDRANGE-L@midrange.com To: MIDRANGE-L@midrange.com cc: (bcc: Amit Mukherjee/SMS) Subject: Re: ILE RPG SOCKET PROTOTYPES Amit, I read your article, and it was very helpful in learning sockets and ILE RPG. I'm glad you subscribe to the list, because I wanted to ask you why, in your article, you combined the BIND(), LISTEN(), and ACCEPT(), into 1 bind_tcp prototype? Say I have a Socket Server running (not literally): Server issues open, set socket options, bind, and listen. When a connection is issued against this server, doesn't it then do an accept to start a conversation with that job on a new socket from the accept? Once the accept is completed, do you know an easy way, or even not so easy, if you've already got the code, to go through the process of submitting a client job, doing the give and take descriptor thing to hand off the conversation, and then going back to listen on the original socket? That is also one of the things that I want to do. What I am actually trying to do is set up sockets so that files can be sent from an AS/400 to: Other AS/400's RS/6000's SCO Unix IBM MVS Systems Right now I use FTP to send the files, and it works pretty good, but what a pain reading through output logs to see if the transmission completed normally. Sorry I got a little long winded, but this is a learning process for me and any help is greatly appreciated. Dave Anderson SYSCO Food Services of Los Angeles, Inc Amit.Mukherjee@smed.com wrote: > There was an aricle of mine in the News/400 June99 issue about sockets > with a service program having prototypes for most of the socket functions a > socket application will need . The code is available at the news400 site. > > Thanks > > -Amit > > "Nelson C. Smith" <ncsmith@gate.net> on 08/13/99 07:51:56 PM > > Please respond to MIDRANGE-L@midrange.com > > To: MIDRANGE-L@midrange.com > cc: (bcc: Amit Mukherjee/SMS) > > Subject: Re: ILE RPG SOCKET PROTOTYPES > > -----Original Message----- > From: David Anderson <DaveTheWiz@worldnet.att.net> > To: MIDRANGE-L@midrange.com <MIDRANGE-L@midrange.com> > Date: Friday, August 13, 1999 2:54 AM > Subject: ILE RPG SOCKET PROTOTYPES > > >Does anyone have a working example of socket prototypes for > > send_file and accept_and_receive. > > > >I would rather send an entire file with one API call. > > > >I've already tried to use the links in the manual OS/400 Sockets > >Programming V4R3, but where the tell you to go doesn't exist. I don't > >mind doing it myself, so if > >someone could point me in the right direction I'd appreciate it. > > > >Thanks in advance, > > > >Dave Anderson > >Sr. Programmer/Analyst > >SYSCO Food Services of Los Angeles > > Why do we have to do it ourselves all over again if someone already has it > working good? That's why we need those shareware sites that have been > talked about here before. > > +--- > | 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 > +--- > > +--- > | 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 > +--- +--- | 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 +--- +--- | 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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.