From: SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 29-JUL-1993 12:02:50.20 To: EVERHART CC: Subj: Re: HELP: $QIO, IO$_SENSEMODE, V24, Frame Size From: steve@dbaccess.com (Steve Suttles) X-Newsgroups: comp.os.vms Subject: Re: HELP: $QIO, IO$_SENSEMODE, V24, Frame Size Message-ID: <251@mccoy.dbaccess.com> Date: 28 Jul 93 22:27:08 GMT Organization: Cross Access Corp., Santa Clara, CA Lines: 104 X-Newsreader: TIN [version 1.1 PL8] To: Info-VAX@KL.SRI.COM X-Gateway-Source-Info: USENET Out of the mind of Andy Settle (Journeyman@spliff.demon.co.uk): > I'm looking for help.... > I'm currently writing a util to monitor our system's V24 modem ports on > the VAX; it shows send and receive speeds, CTS, DTR, DSR etc... The > program is written in C and has not caused *too* much grief. > Except that i can't seem to figure out how to get the following: > - Port Frame size (e.g 7 or 8 bit) > - Parity (e.g Odd, Even, None) > I've got a little way on the frame size setting but i'm not sure i've got > all angles covered; I've read I/O Ref' manual Terminal driver section > numerous times now (and even Device Support in desparation!), and can > even see the tt$v_altframe fields in TTDEF.H but how do i read it? > TIA. No flames, please. This is fact. Some time ago (VMS V3), I wrote a program that needed the same information. I needed to modify the settings and then set them back. At that time, there were different device drivers for each type of terminal interface. I submitted quite a few SPRs about the fact that the drivers returned results in these fields that were not suitable for use to IO$SETMODE, as was documented. Various changes resulted; new drivers, new documentation, new correspondents. The SPR process could take as much as 6 months back then, and often resulted in a response of "We will address [not necessarily fix] this in a future major release [not necessarily the next one, or even the next major one]". Since I was not willing to wait on this project, I continued to look for workarounds. I did some exhaustive analysis (tried all the settings, see what SENSEMODE returned) and found a one-to-one bit mapping that worked. I wrote code to rearrange the bits, and I was happy. UNTIL, we hooked up another modem, this time to a different type of board. Having done it before, I had all the tools handy, and it was quick work to remap the bits. Since the device type was different, I could tell which algorithm to use. I was happy once more. UNTIL, the third modem was plugged in. I got pretty good at eyeballing the results of my analysis program, and writing code on the fly. I got to thinking pretty highly of myself. UNTIL, the next release of VMS showed up with all new drivers, all of which mapped differently. A couple of days work, and our modems were all back on line. I even wrote a utility to do the eyeballing--it printed out a before mask and after mask for each bit. I figured I could make it rain if I wanted to. UNTIL, the next release of VMS showed up, with "class" and "port" drivers. I could no longer distinguish easily what kind of interface it was on. And we traded in our boards a few times, and moved modems to boards that they weren't on before, and so on. So I built the analysis into the application, and stopped submitting SPRs. As of around VMS V5.2, the following was still the "right" answer: 1) Do a sense mode. Save the results. 2) Cycle through all the possibilities, saving both what you used to set it and what was sensed. 3) Find your saved results in your chart. Use the set that generated that particular nugget. I put checks in to ensure that the bits were mapped one-to-one, but they -never- went off. There are some extra bits in the sense that are either always one or always zero, but they are unrelated to the set. Once I made this change, I didn't have to touch it again. It survived several updates to VMS, and as far as I know, they are still using the utility. On certain hardware interfaces, with RS-232 equipment on the far end that distinguishes it, the testing cycle generates some framing errors--why, I don't know; it should not if the line was idle (which was part of the context of our situation). However, since that bothered only me, I promptly learned to ignore it. I can't ship you the source code, and it's in MACRO anyways, and you wouldn't like it (but Dave, if you're lurking and also inclined to do so, you may inflict the source on this man with my blessing). So the simple answer is: You can't get there from here. You already have the complex answer that justifies this. All that's left is the theory behind the bug: Nobody tested it. These bits (specified in the set) have to be passed to hardware-dependent code which must shuffle them until they line up with the registers. That gets tested. The sense function should be the inverse, but it is consistent that the bits "forget" to be shuffled or get shuffled improperly. Since it occurred in all hardware drivers (before separation) and all port/class combinations (after separation) I suspect it is a flaw in the first driver that got cloned when the second was derived, etc, etc, and when the port/class split occurred, was taken as gospel and left alone. The shuffling properly belongs in the port driver, but I suspect it was put into the class driver, and only works right for one particular interface...which we never had. -- Steve Suttles Internet: steve@dbaccess.com Dr. DCL is IN! CROSS ACCESS Corporation UUCP: {uunet,sgiblab}!troi!steve Yo speako TECO! 2900 Gordon Ave, Suite 100 fax: (408) 735-0328 Talk data to me! Santa Clara, CA 95051-0718 vox: (408) 735-7545 HA! It's under 4 lines NOW!