|
Hi Scott, Thanks for your reply. If that's the case, here's what you want to do: 1) Create a buffer that's the size of your largest data structure. 2) Base all of your data structures on pointers. 3) Set a work-pointer (NOT one of the ones that the structures are based on) to the start of the buffer. 4) Receive 4-bytes to fill in the MsgCode and MsgLen parms of the structure. (do byte-swapping if necessary) 5) Based on the MsgLen parameter, receive the rest of the structure. 6) Use select/when or if/elseif on the MsgCode to determine which structure you've received, and point that structure's pointer at the start of your buffer.... 7) Do whatever you needed to do with that structure. Does that make sense? Yes. This is what I want. Can you please explain with examples as I am new to pointers in RPGLE. Scott Klement <klemscot@klements. To: RPG programming on the AS400 / iSeries com> <rpg400-l@xxxxxxxxxxxx> Sent by: cc: rpg400-l-bounces@mi Subject: Re: Socket Programming - Receive drange.com 03/24/2004 03:18 PM Please respond to RPG programming on the AS400 / iSeries Hi Lakshmi, > The program will not be able to know which structure it is > receiving.My problem is, how can I identify which structure I am > receiving in RPGLE. There's no magical solution to that. The program that's sending the structure has to have some way of telling the program that's receiving the structure which structure it is. Actually, I suspect that the "bMsgCode" part of the structure was intended to be used for this purpose. I can't say for sure, since I'm not sure how the application works... But, I would guess that the first 2 bytes identify the structure, and bytes 3-4 identify the length of data in that structure. If that's the case, here's what you want to do: 1) Create a buffer that's the size of your largest data structure. 2) Base all of your data structures on pointers. 3) Set a work-pointer (NOT one of the ones that the structures are based on) to the start of the buffer. 4) Receive 4-bytes to fill in the MsgCode and MsgLen parms of the structure. (do byte-swapping if necessary) 5) Based on the MsgLen parameter, receive the rest of the structure. 6) Use select/when or if/elseif on the MsgCode to determine which structure you've received, and point that structure's pointer at the start of your buffer.... 7) Do whatever you needed to do with that structure. Does that make sense? > My application in RPGLE sends different messages to a PC and it will not > wait for the response from a PC. After sometime, the PC will send the > response to AS/400, then the RPGLE pgm should interpret the message > (which structure it is ?) and process accordingly. So, my problem is how > will the program know the socket is received response from a PC and > which structure? I still don't understand. What is the program doing when it's not waiting for data from the client? The program isn't ending, is it? Is it waiting for input from a user? What is it doing? Normally, you wait for data on a socket in one of two ways... either by using one of the recv APIs with a blocking socket, or by using the select() API to wait until data has arrived. If you've got something else you need to do, like waiting for input from a user, then you need to switch back & forth between the user input and the wait for data. What I'd do is have the screen input signal an entry on a data queue -- then do a select() for 0.5 second, check the data queue with a 0 timeout, then go back to select() for 0.5 second, etc. When either the data queue has an entry or the select() API says there's data, you process the screen or the socket. Hopefully that makes sense... _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l. Confidentiality Caution ======================= Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Opinions, conclusions and other information in this message that is not of an official nature shall be deemed as neither given nor endorsed by SGX unless indicated by an authorised representative independent of this message.
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.