| Title: | "ASK THE WIZARDS" |
| Moderator: | QUARK::LIONEL |
| Created: | Mon Oct 30 1995 |
| Last Modified: | Mon May 12 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 1857 |
| Total number of notes: | 3728 |
Return-Path: "VMS001::WWW"@vms001.das-x.dec.com Received: by vmsmkt.zko.dec.com (UCX V4.1-12, OpenVMS V6.2 VAX); Fri, 28 Mar 1997 15:45:21 -0500 Received: from vms001 by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id PAA14189; Fri, 28 Mar 1997 15:38:09 -0500 (EST) Date: Fri, 28 Mar 1997 15:40:48 -0500 Message-Id: <[email protected]> From: "VMS001::WWW"@vms001.das-x.dec.com (28-Mar-1997 1540) To: [email protected], [email protected], [email protected] Subject: Ask the Wizard: '[email protected]' X-VMS-To: [email protected] Remote Host: (null) Browser Type: NCSA Mosaic for the X Window System/2.4 libwww/2.12 modified Remote Info: <null> Name: Stephen R. Ernst Email Address: [email protected] CPU Architecture: VAX and Alpha Version: v 6.2 Questions: a couple of questions: I read FAQ decw-8. I have an lk411-b01 KB and I cannot get the double <> key (next to Z) to transmit anything on my 400 4/233 running vms 6.2. I tried to find the .exe file that axpdriv06_061 would apply to. I analy/im/pat sys$system:*term*.exe but decw$terminal and _create reported no patches. there are a lot of *driv* files in sys$ldr but none with AXP in the name. would that patch (applied to which image) fix this problem? Again, having checked the WIZ and the FAQ I still have the following question: We recently bought several Pinnaclemicro Apex 4.2 GB optical disk drives. These drives will attach (unmodified) to SGI, IBM-pc and MAC computers (using the 512byt/sector formatted disk cartridges. I tried to attach it to this alpha. The unit was recognized by the console (it echoed the above description of the drive) and appeared as dk300 when I "show dev dk " . However when I attempted to initialize a cartridge I got a media off line or media not mounted errormessage. the error log only logged one error: invalid mode sense data returned. I ran the scsi_info program and got a 48 block file of stuff that doesn't mean much to me. some of the sense mode messages say the data is "savable yes" and some say no. However , the problem boils down to this: is this just another of an on-going problem with DEC's constantly changing interpretation (or application) of the scsi standard. How can a semi-conscious individual hope to read such an info-dump and conclude which resistor pak needs to be changed. Don't tell me to consult the manufactorer because they refuse to even consider supporting the dec computers( like many many other mfgr's). It is true that DEC has not ever claimed to have tested these drives and doesn't claim that they even might work or ever be supported. On the other hand we live in a mix and match world and there are a lot of competitors that will help to get cutting edge tecnology to work on their systems. Please don't give me the software engineers pat answer. RE: how many software engineers does it take to screw in a light bulb? None. Its a hardware problem. It seems that I am tantalizingly close and if possible would love to use this on our alpha server 2000. Thanks Steve Ernst
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1726.1 | DECterm; SCSI Device Integration and Testing | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Mon Apr 28 1997 11:51 | 33 |
The <> key is controlled from the DECterm options-keyboard menu, and from the session manager keyboard type selection. Please make certain the correct selections have been made in both places. -- Contact Pinnacle Micro for assistance with the integration and the testing of the Apex drive under OpenVMS. As a wizard, I have performed a number of Q-bus, UNIBUS, SCSI bus and various other-bus device integrations, and have even occasionally bled directly onto the cutting edge. And as one familiar with device integration and testing, assuring that a device will operate as expected (particularly under the I/O load that can be generated by OpenVMS Alpha) is a non-trivial and potentially quite costly affair. The SCSI mode sense data has been one area of the SCSI interface that various SCSI vendors have omitted entirely, have returned unusual (and sometimes erroneous) data -- OpenVMS needs this mode sense data to map to the device, and OpenVMS was apparently one of the first operating systems to use the 10-byte mode sense command. For basic debugging information, see the SYS$ETC:SCSI_INFO tool and see the system error logs. Between the two, information on what mode sense data is being returned will be available. If the mode sense is incorrect, contact Pinnacle support. If the mode sense is valid, contact DIGITAL support. DIGITAL has made a number of changes to better accommidate third-party SCSI devices when error(s) can be resolved or improvements can be made in OpenVMS, and DIGITAL has encountered a number of third-party devices with SCSI interface implementation errors. | |||||