On Thursday, 12/04/2008 at 03:18 EST, "Horlick, Michael" <[EMAIL PROTECTED]> wrote: > Hello Alan, > > Thanks for the info. I do have NOTN3270E specified
Then the problem is not in VM's TN3270E support! :-) > MTU sizes? I have '1500' specified in my PROFILE TCPIP. I'll check with > the client. Is there any trace on the mainframe that I can do that would > help diagnose the error? No. The MTU is an administratively-defined value based on the technology you are using. E.g. maybe it should be 1492, not 1500. Have to talk to switch admin. Actually, since you're not getting a hang condition, it is probably *isn't* MTU. One of the ways to verify that MTU is/isn't interfering is to create a file that is 80 bytes wide (RECFM F) and 24 lines long. Each line consists of 8 copies of 1234567890. XEDIT the file. This will cause more than 1492 bytes to be sent. If you get a hang, the MTU is likely the problem, particularly if XEDITing a file with just one line in it works just fine. > I didn't realize IND$FILE wasn't supported. Do you have an idea how > IND$FILE does its business and reports on errors? To the best of my knowledge the 3270 file transfer protocol isn't published. I know that IND$FILE uses some special 3270 orders that target the "data mover" in the emulator rather than the display. And that's only because I've done some tracing in the past. The *orders* used *are* published in the 3270 Display Reference or in a 3174 Functional Description. I would be getting a 3270 trace from the emulator an compare the 3270 data streams in the working and failing cases. Oh, and David's post makes me think: Verify that in the failing and non-failing cases, the alternate screen sizes are the same. I.e. the VM logo screen is 32x80 or 24x80 or whatever in either case. If they are different, then there is an issue with extended attributes in the emulator. Alan Altmark z/VM Development IBM Endicott
