Re: How can one distinguish an IDE/ATA(PI) drive from a SCSI drive?

Steven M. Schweda wrote:

Currently cdrecord uses that annoying "dev=i,j,k"

If you dig around in the source code, you'll find that the values are mapped and re-assembled into an OpenVMS device specification deep down at the bottom of the cdrecord.exe source code.


Are you using DEV$V_SCSI or DEV$M_SCSI here? (I've made this mistake...)

So far, I've just looked at DEVCHAR2 using DCL, and as I review what
I was doing, I appear to have been looking at the wrong device (an
external SCSI CD-R/RW drive instead of the internal IDE/ATAPI drive), so
dev$v_scsi may actually do what I want after all.

Macro32 and Bliss tend to like the $V. Macro32, Bliss and various other languages can and do use $M. ($V is the bit offset. $M is a bitmask.) If you use the $V bit offset within your DCL, I'll assume you are using a lexical function (eg: f$cvui) to extract the bit, or that you are using the $M value or a bit-shift of the $V value to get a bitmask) and the .AND. operator. (upon grok, do please ignore this -- but then, it's not often that an opportunity to mention f$cvui/f$cvsi comes up. :-) )

You're wading into a comparatively weak part of OpenVMS here, as OpenVMS does not provide a mechanism that reports device capabilities. (The traditional device-specific bit flags and the device type and class codes are limited in their capabilities.) You can lob SCSI commands at the device and retrieve this data yourself, but OpenVMS doesn't present this data to the user. There's no array of capabilities or features available to users from within the drivers, though the drivers do have to collect this sort of data as part of normal operations.


Do you (expect to) need to add USB to the particular fracas?

I hadn't thought about it, but I suppose that it would be a good
idea. Should I assume that a USB drive would appear as a "DN" (like
"DNA0:"), and that it should be treated as an ATAPI? Or is it all worse
than that?

ATAPI is SCSI. USB is SCSI. SAS is SCSI. "SATAPI" (which isn't in particular use as yet) is (wait for it) SCSI. And SCSI itself is, by definition, not quite SCSI. :-)

What's additionally "fun" here is that the OpenVMS driver I/O paths are (slightly) different for the IO$_DIAGNOSE paths. IIRC, DN/USB works like DQ/ATAPI here, and uses the same IO$_DIAGNOSE paths -- the biggest difference between DQ/ATAPI and DN/USB is that DN/USB does not provide timeouts.

I'm not sure that I can actually avoid always having an "i,j,k"
mapping for devices, so now would probably be a good time to add a "DN"
mapping.

The cdrecord.exe port that the HP folks provided includes mappings for these, and a command procedure wrapper. The source code should be on the Freeware. (The mappings changed somewhere in the V8.* range, too, IIRC -- the old DQ x,y,z code was bumped upwards somewhere along the line.)

The command option parsing code within cdrecord.exe doesn't lend itself to fixing this, unfortunately. Changes here are undoubtedly quite feasible, though the command-parsing support is non-trivial.


(Or to convert some of the current 8 = DQA, 9 = DQB, ... 33 =
DQZ assignments to DNA, DNB, and so on. I haven't tried more than one
USB card. Is there such a thing as a "DNBxx"? As I've never seen
anything beyond DQB on my junk, I tend to imagine that most of those DQ
assignments are useless, but perhaps an IA64 system could get an add-in
IDE card to spoil my dreams?)

There are up to four DQ devices around on various systems, and there can be DQ/IDE and DN/USB PCI adapters.

IIRC, the solution used by the SYS$MANAGER:CDRECORD.COM is to map the device values to the cdrecord.exe dev=x,y,z value. Hugely ugly, but it has the advantage of working. The other approach was to supplement the recording capabilities with the V8.3 COPY/RECORDABLE_MEDIA command, and related tools.

I'd probably look to tweak the cdrecord.exe tool to implement a vmsdev=ddcu: command option, were I going after this source code change.




.

Relevant Pages

  • Re: The possibility of vms opening up?
    ... OpenVMS Source Listings are available to those that purchase a source ... Note you get listings, not source code. ... correlate to vulnerabilities found. ...
    (comp.os.vms)
  • Re: Hobbyist and Hardware Support (was: Re: SRM memtest)
    ... The OpenVMS source listings are available for purchase on CD or DVD, ... :Is the source code for the SRM firmware available? ... :like only recognizing SCSI controllers that it knows about (and choking ... and boot support is available using the SHIP kit mechanism, ...
    (comp.os.vms)
  • Re: NT: son of VMS? (was Re: Portents of VMS death)
    ... So what if even the Pope blessed the source code for NT, ... NT and OpenVMS for that matter are a bit more than just ... code is now in the kernel I think to improve performance and ... NT's IP stack wasn't exactly ...
    (comp.os.vms)
  • Re: SRM memtest
    ... Source code licenses are available to developers, ... SRM has traditionally been provided by the Alpha hardware engineers, ... This SRM firmware is in support of OpenVMS, of course, ...
    (comp.os.vms)
  • Re: Why OpenVMS is better than linux ...
    ... > OpenVMS is the most well designed computer operating system in the ... >, built-in batch-print ... > listings of the operating system internals and source code, ...
    (comp.os.linux.security)