On Mon, 24 Jun 2002, Jonathan S. Polacheck wrote: > > We often take protocol analyzer traces to diagnose performance problems > related to 5250 sessions. The problems seem most likely related to issues > at the AS/400 and/or the client system rather than any kind of network > latency, but we still need the trace to prove which system is hanging and > when. We, as network administrators, do not have detailed knowledge of all > the apps that are being access through 5250. If we could re-create a 5250 > screen and see it's contents at the time we observed the large delta time > in the trace, we would have a better idea of what the user was doing and > what applications were being accessed. > > We usually use Network General Distributed Sniffer Servers to take traces. > These traces can be converted to tcpdump format and view through Ethereal. > Then, the data payloads could be extracted from a given TCP (Telnet) flow. > The display is tantalizingly like getting a view of the screen output (see > attachment 5250.txt). But not really like looking at the actual screen > display, and no indication of what packet relates to what screen display You can't send attachments over the mailing list, sorry. It simply strips them out. Therefore, I haven't seen your attachment, and I'm not quite sure what you mean. > > Any suggestions? Kinda sounds like you're seeing the raw 5250 protocol. Yes? What do you define as being a "new screen", then? When the system requests input from the terminal? > > BTW, I installed your tn5250 on a Win2k system and tried to use the "debug" > option to view a trace. I got an error and, supposedly, generated a log > file. If I knew where the log file was created (it doe's not seem to be > in C:\Program Files\TN5250>) I would send it. > I don't have a Win2k system to diagnose this on.
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.