> -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Chuck Arney > Sent: Thursday, September 22, 2005 12:10 PM > To: [email protected] > Subject: Re: HOD/HACL running on z/OS?
<snip> > > Yes, the active connection(s) is not the problem I was > bringing up. But, > when you record the information for later playback you have > to keep each > session straight so you can send the input back to the proper replay > session. This would have to be based on the client IP > address and port > number for the original session. I was thinking along the lines of a > multi-session facility. This would not be a problem if you > are supporting a > single session. Ah, true. I did not go into how to actually record each session's data stream. I would ASSuME that each session would go to a unique (UNIX?) file. If the data from every session were to go into a single file (interleaved with all the other sessions), then you'd need some "token" in the record to associate the individual records to a particular session. In this case, I would likely do an STCKE at the when I got the connection request and keep it in the same data structure as I was using to store the host<->me<->user sockets. Then every record in the file would contain this "token", the data flow direction, and the actual data. Another method would to not have a single STC doing this capture. The capture program could be written to be started via inetd (which would be the process actually doing the LISTEN on the port). When a connection request came in to the port, inetd would set up the socket, then start the actual capture process (fork()/exec()), passing it the already set up socket. In this case, there would be exactly one UNIX process for each session. It would likely be easier to write such a capture program since it would not need to be reentrant or multitasking (multi-threaded?). Of course, this method has greater CPU overhead. It is also more "UNIXy" and thus not as familar to most z/OS people. Again, if it were me, I'd likely use a unique UNIX file to log each session. To generate the unique filename, I'd likely use the output of an STCKE, translated into printable hex as part of the file name. To me, this would be easier to read/write and maintain. If everything were in one big file, then the replay program would need to be able to select one (or more) "streams" to replay. I'm not sure if each record in the file should also have a timestamp, or if just the physical order of the records would be sufficient. A plus to each record having a timestamp would be the ability to get "response time" information. This could be helpful in a non-constrainted system to compare if the program changes had any significant effect on response time. <snip> > > > -- > > John McKown > > Senior Systems Programmer > > UICI Insurance Center > > Information Technology > > > Chuck Arney > illustro Systems International, LLC > http://www.illustro.com -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
