INFO-VAX Sun, 28 Sep 2008 Volume 2008 : Issue 524 Contents: Re: Enhancing DCL, was: Re: How do I add 2 letters to a long Re: Enhancing DCL, was: Re: How do I add 2 letters to a long Re: Enhancing DCL, was: Re: How do I add 2 letters to a long Re: Enhancing DCL, was: Re: How do I add 2 letters to a long Re: Enhancing DCL, was: Re: How do I add 2 letters to a long USB device development on DS10 via Belkin f5U220 - OpenVMS 8.3 with 7.3-1 SRM Fi Re: USB device development on DS10 via Belkin f5U220 - OpenVMS 8.3 with 7.3-1 SR Re: USB device development on DS10 via Belkin f5U220 - OpenVMS 8.3 with 7.3-1 SR Re: USB device development on DS10 via Belkin f5U220 - OpenVMS 8.3 with 7.3-1 SR Re: USB device development on DS10 via Belkin f5U220 - OpenVMS 8.3 with 7.3-1 SR Re: USB device development on DS10 via Belkin f5U220 - OpenVMS 8.3 with 7.3-1 SR Re: What is a process' current WSxxxxx quotas ? ---------------------------------------------------------------------- Date: 28 Sep 2008 05:35:36 -0500 From: clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) Subject: Re: Enhancing DCL, was: Re: How do I add 2 letters to a long Message-ID: <2zs2SmJlhr1J@eisner.encompasserve.org> In article <5880985a-8e44-45d2-b775-147349648c4a@u65g2000hsc.googlegroups.com>, AEF writes: > On Sep 26, 8:53 pm, clubley@remove_me.eisner.decus.org-Earth.UFP > (Simon Clubley) wrote: >> In article <54c74bd9-a1c5-4df0-863f-8a5169737...@m44g2000hsc.googlegroups.com>, AEF writes: >> >> > I'd be quite happy with being with just being able to use RECALL/OUT >> > in a command procedure. This way I could use my FILTER command >> > procedure search for strings in the recall buffer. >> >> How would you handle merging the output from multiple simultaneous sessions >> (assuming that the current command history was loaded at the start of the >> session) ? > > I don't need to. And what does this have to do with placing RECALL/ > OUT= in a command procedure? I want to be able to write the > recall history buffer of my interactive session from a command > procedure. There is nothing merged from anywhere else; this is the > standard vendor-supplied DCL recall buffer we are talking about here. > As you realised later on, I'm talking about the capabilities available in bash and not DCL. I hadn't realised, since we were talking about saving command history, that your FILTER routine was designed to search through command output instead. > And where is the security problem? If I can run RECALL from a DCL > prompt, how is that different -- security-wise -- from running the > same from a command procedure? > The issue, when saving command history, is saving sensitive information in permanent form in a disk file between sessions. > > What does it mean "that the current command history was loaded at the > start of the session"? How can there be a current command history for > a session that hasn't started yet? Oh, perhaps you mean the current > version of the file that holds all the commands entered in all > previous sessions since the last time this history file was cleared? > (I forgot that Unix (or at least some shells) does that.) To me, > "current command history" means all the commands you've entered in > your current session (hence the word "current" in "current history"). > You and I have different interpretations of "current", "history", or > both. I didn't realize that "current history" meant commands that were > run in the "current" session *and* past sessions. OK. > That's correct. I'm using current to describe the current set of commands that I'm using, which will generally span more than the lifetime of a single session. I can have commands that I use all the time easily to hand within the buffer (because they are used frequently enough that they are never purged from the buffer) and commands from a current project are there waiting when I come back to it the next day. The size of the command history file has a configurable length, and the oldest commands are dropped automatically by bash when new (and recalled) commands are appended. >> In bash, only the commands entered during that session get appended to the >> command history file. > > Why would it ever be done any other way? You mean there are shells out > there, any of which reads one of these "history files" and then > immediately regurgitates what it just read, appending it to the same > "history file"? Huh? > No, there aren't to my knowledge. I was thinking about the problems that RECALL/INPUT and RECALL/OUTPUT, as currently implemented, would have if you have multiple terminal sessions open at the same time. A DCL RECALL command to load the saved history at the start of a session, followed by a command to save the history at the end of the session would have that effect unless there was some way of telling recall to only append the commands entered during that session to an existing file. >> >> The way that I handle that in bash is to unset the history filename >> variable so that the current session doesn't get written out if I've >> used security related parameters on the command line. > > What does it mean to "unset the history filename variable"? And how do > you do that so that it recognizes security-related params on the > command line? > The name of the history file to be appended to at session end is stored in an environment variable. If that variable is not defined, then the session's commands are not saved. unset is the name of a bash command to unset (delete) an environment variable. I simply issue the unset command if there's security related information that I've used that I don't want to be saved so that none of the commands from the current session get appended to the history file. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980's technology to a 21st century world ------------------------------ Date: Sun, 28 Sep 2008 06:44:21 -0700 (PDT) From: AEF Subject: Re: Enhancing DCL, was: Re: How do I add 2 letters to a long Message-ID: On Sep 28, 6:35 am, clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote: > In article <5880985a-8e44-45d2-b775-147349648...@u65g2000hsc.googlegroups.com>, AEF writes: > > > On Sep 26, 8:53 pm, clubley@remove_me.eisner.decus.org-Earth.UFP > > (Simon Clubley) wrote: > >> In article <54c74bd9-a1c5-4df0-863f-8a5169737...@m44g2000hsc.googlegroups.com>, AEF writes: > > >> > I'd be quite happy with being with just being able to use RECALL/OUT > >> > in a command procedure. This way I could use my FILTER command > >> > procedure search for strings in the recall buffer. > > >> How would you handle merging the output from multiple simultaneous sessions > >> (assuming that the current command history was loaded at the start of the > >> session) ? > > > I don't need to. And what does this have to do with placing RECALL/ > > OUT= in a command procedure? I want to be able to write the > > recall history buffer of my interactive session from a command > > procedure. There is nothing merged from anywhere else; this is the > > standard vendor-supplied DCL recall buffer we are talking about here. > > As you realised later on, I'm talking about the capabilities available in > bash and not DCL. But I'm not using bash, I'm using DCL. I simply want to be able to use the RECALL command from within a *DCL* command procedure. That's all. > I hadn't realised, since we were talking about saving command history, that > your FILTER routine was designed to search through command output instead. > > > And where is the security problem? If I can run RECALL from a DCL > > prompt, how is that different -- security-wise -- from running the > > same from a command procedure? > > The issue, when saving command history, is saving sensitive information in > permanent form in a disk file between sessions. Yes, I know that. But what's the difference between saving sensitive information when running the RECALL command at a DCL prompt compared to running it from within a command procedure? In both cases, the secret information is written to disk. So why is the former okay but not the latter? And what about if the system manager types sensitive info on the screen and then executes a Print Screen operation? Then, by the same reasoning, the Print Screen operation should also be dropped, right? In fact, again by the same reasoning, the entire RECALL command itself should be dropped! > > What does it mean "that the current command history was loaded at the > > start of the session"? How can there be a current command history for > > a session that hasn't started yet? Oh, perhaps you mean the current > > version of the file that holds all the commands entered in all > > previous sessions since the last time this history file was cleared? > > (I forgot that Unix (or at least some shells) does that.) To me, > > "current command history" means all the commands you've entered in > > your current session (hence the word "current" in "current history"). > > You and I have different interpretations of "current", "history", or > > both. I didn't realize that "current history" meant commands that were > > run in the "current" session *and* past sessions. OK. > > That's correct. I'm using current to describe the current set of commands > that I'm using, which will generally span more than the lifetime of a > single session. I can have commands that I use all the time easily to hand > within the buffer (because they are used frequently enough that they are > never purged from the buffer) and commands from a current project are > there waiting when I come back to it the next day. > > The size of the command history file has a configurable length, and the > oldest commands are dropped automatically by bash when new (and recalled) > commands are appended. > > >> In bash, only the commands entered during that session get appended to the > >> command history file. > > > Why would it ever be done any other way? You mean there are shells out > > there, any of which reads one of these "history files" and then > > immediately regurgitates what it just read, appending it to the same > > "history file"? Huh? > > No, there aren't to my knowledge. I was thinking about the problems that > RECALL/INPUT and RECALL/OUTPUT, as currently implemented, would have if > you have multiple terminal sessions open at the same time. Ah, you were talking about bash and writing about DCL RECALL, as you do below. OK. > A DCL RECALL command to load the saved history at the start of a session, > followed by a command to save the history at the end of the session would > have that effect unless there was some way of telling recall to only > append the commands entered during that session to an existing file. I just tried it and it works fine: Log in, do your stuff, RECALL/ OUT=R.TMP, log out; log in, RECALL/INPUT=R.TMP!. But if you run RECALL/ OUTPUT=R.TMP followed by RECALL/INPUT=R.TMP in the *middle* of a session, then yes, it does as you describe; it uses the KISS paradigm. Anyway, I never use RECALL/INPUT. In fact, I forgot that it even exists! I don't think I've ever wanted to read in an old RECALL buffer. And if I want to write a command to disk for future use, I use my WC program. Regardless, in this case I simply want to be able to use the RECALL command from within a command procedure. This has nothing to do with saving the RECALL buffer to be read in for another session. I have other purposes in mind. Besides my FILTER example, I'd like to have the DCL prompt contain within itself the date and time at which it appeared on the screen. This way I can automatically keep track of what happened when during a long terminal session. I can do this with a command procedure, but then I lose the ability to use the RECALL command. (No, no, no, I do *not* want a clock in the prompt; I have plenty of other "clocks". I want the equivalent of the MS-DOS command "PROMPT $D$T$G$S".) > >> The way that I handle that in bash is to unset the history filename > >> variable so that the current session doesn't get written out if I've > >> used security related parameters on the command line. > > > What does it mean to "unset the history filename variable"? And how do > > you do that so that it recognizes security-related params on the > > command line? > > The name of the history file to be appended to at session end is stored in > an environment variable. If that variable is not defined, then the session's > commands are not saved. You didn't write that. You said that when you unset the variable, the current session doesn't get written out *if* you've used secret params, which means that it *does* get written out if you *didn't* use secret commands. What you meant was the converse: If you are going to use secret params, you unset the variable first so that *no* commands in your session are written to disk. That's not the same. > > unset is the name of a bash command to unset (delete) an environment > variable. I simply issue the unset command if there's security related > information that I've used that I don't want to be saved so that none > of the commands from the current session get appended to the history file. Ah, that's what you meant, but not what you wrote last time. > > Simon. > > -- > Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP > Microsoft: Bringing you 1980's technology to a 21st century world AEF ------------------------------ Date: Sun, 28 Sep 2008 13:53:48 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: Enhancing DCL, was: Re: How do I add 2 letters to a long Message-ID: In article , AEF writes: > (No, no, no, I do *not* want a clock in the prompt; I > have plenty of other "clocks". I want the equivalent of the MS-DOS > command "PROMPT $D$T$G$S".) I'm not familiar with the MS-DOS command. What does it do? ------------------------------ Date: Sun, 28 Sep 2008 07:45:59 -0700 (PDT) From: AEF Subject: Re: Enhancing DCL, was: Re: How do I add 2 letters to a long Message-ID: On Sep 28, 9:53 am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig--- remove CLOTHES to reply) wrote: > In article > , AEF > > writes: > > (No, no, no, I do *not* want a clock in the prompt; I > > have plenty of other "clocks". I want the equivalent of the MS-DOS > > command "PROMPT $D$T$G$S".) > > I'm not familiar with the MS-DOS command. What does it do? It does what I said it does (which you omitted in your reply). I included it as an example so that we don't go through all the misunderstanding that happened the last time I brought this up. Everyone thought I wanted a clock in the prompt. NO! I want the time in the prompt to be THE TIME AT WHICH THE PROMPT APPEARED ON THE SCREEN. For example, I want to look at my session and see the following: $ SHOW TIME 28-SEP-2008 14:12:33 28 14:12:34> SHOW SYS/NET OpenVMS V6.2 on node IDS03 28-SEP-2008 14:16:05.20 Uptime 5 12:47:48 Pid Process Name State Pri I/O CPU Page flts Pages 0000008E EVL HIB 6 144 0 00:00:00.16 367 645 N 00001797 SERVER_002F LEF 6 94 0 00:00:00.36 848 332 N 28 14:16:06> SHOW MEM/SLOT System Memory Resources on 28-SEP-2008 14:17:42.86 Slot Usage (slots): Total Free Resident Swapped Process Entry Slots 70 42 28 0 Balance Set Slots 63 37 26 0 28 14:17:43> DIRECTORY/SIZE/DATE/OUT=D [*...] ! Return key pressed at 28 14:19 ! 28 14:22:03> ! Return key pressed here at 28 14:23:32 28 14:23:32> OK, here's the play-by-play: At 14:12:33 I ran the SHOW TIME command. It completed at 14:12:34, so the immediately succeeding prompt contains that time. Then a few minutes later I ran SHOW SYS/NET, which started at 14:16:05.20 and completed at 14:06:06. I can tell that by the looking at the DCL prompt that appears right after its output. Then a couple of minutes later I ran SHOW MEM/SLOT at 14:17:42.86 and the following prompt shows when that completed. The about 1 1/2 minutes later, I pressed the Return key and I can tell when that happened by looking at the resulting prompt. *** I can look at this a week later and the times would still be the same. These are timestamps, not clocks. *** Here's an actual example from an MS-DOS session: P:\>PROMPT $D$T$G$S 2008-09-28 9:41:46.02> 2008-09-28 9:41:49.49> 2008-09-28 9:41:50.22> 2008-09-2810:17:01.81> 2008-09-2810:17:02.64> 2008-09-2810:17:03.44> PROMPT $D$S$T$G$S 2008-09-28 10:17:13.03> 2008-09-28 10:17:17.73> 2008-09-28 10:17:18.19> 2008-09-28 10:17:18.67> 2008-09-28 10:17:20.17> 2008-09-28 10:17:20.67> TIME The current time is: 10:17:22.80 Enter the new time: 2008-09-28 10:17:23.89> DIR ASDFASDF.ASDF Volume in drive P is Data Volume Serial Number is FE2F-5ED9 Directory of P:\ File Not Found 2008-09-28 10:17:30.72> 2008-09-28 10:26:35.26> Notice that each prompt-time is the time at which the immediately preceding command completed. Where no command appears I simply pressed Return and the immediately succeeding prompt gives the time that the Return "command" completed. *** I can look at this a week later and the times would still be the same. These are timestamps, not clocks. *** OK, this is about as explicit as I can make it! AEF ------------------------------ Date: 28 Sep 2008 10:56:12 -0500 From: clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) Subject: Re: Enhancing DCL, was: Re: How do I add 2 letters to a long Message-ID: <7VLqo8iS5qD7@eisner.encompasserve.org> In article , AEF writes: > On Sep 28, 6:35 am, clubley@remove_me.eisner.decus.org-Earth.UFP > (Simon Clubley) wrote: >> In article <5880985a-8e44-45d2-b775-147349648...@u65g2000hsc.googlegroups.com>, AEF writes: >> >> > On Sep 26, 8:53 pm, clubley@remove_me.eisner.decus.org-Earth.UFP >> > (Simon Clubley) wrote: >> >> In article <54c74bd9-a1c5-4df0-863f-8a5169737...@m44g2000hsc.googlegroups.com>, AEF writes: >> >> >> > I'd be quite happy with being with just being able to use RECALL/OUT >> >> > in a command procedure. This way I could use my FILTER command >> >> > procedure search for strings in the recall buffer. >> >> >> How would you handle merging the output from multiple simultaneous sessions >> >> (assuming that the current command history was loaded at the start of the >> >> session) ? >> >> > I don't need to. And what does this have to do with placing RECALL/ >> > OUT= in a command procedure? I want to be able to write the >> > recall history buffer of my interactive session from a command >> > procedure. There is nothing merged from anywhere else; this is the >> > standard vendor-supplied DCL recall buffer we are talking about here. >> >> As you realised later on, I'm talking about the capabilities available in >> bash and not DCL. > > But I'm not using bash, I'm using DCL. I simply want to be able to use > the RECALL command from within a *DCL* command procedure. That's all. > I understand and I can see why we've got confused because we are thinking about two different things, but don't forget that I started this thread by talking about things that DCL was missing compared to bash so I replied with that as a frame of reference - I had initially assumed that your FILTER routine was a way of doing what I wanted to do. >> I hadn't realised, since we were talking about saving command history, that >> your FILTER routine was designed to search through command output instead. >> >> > And where is the security problem? If I can run RECALL from a DCL >> > prompt, how is that different -- security-wise -- from running the >> > same from a command procedure? >> >> The issue, when saving command history, is saving sensitive information in >> permanent form in a disk file between sessions. > > Yes, I know that. But what's the difference between saving sensitive > information when running the RECALL command at a DCL prompt compared > to running it from within a command procedure? In both cases, the > secret information is written to disk. So why is the former okay but > not the latter? > It's not. I'm talking about the act of writing sensitive commands to disk. You raised the issue of wanting to use recall/out within a command procedure and must have misinterpreted my responses as somehow saying that one way of using recall/out was ok, but the other was not. > And what about if the system manager types sensitive info on the > screen and then executes a Print Screen operation? Then, by the same > reasoning, the Print Screen operation should also be dropped, right? > In fact, again by the same reasoning, the entire RECALL command itself > should be dropped! > Now, now - that's the Microsoft approach - protect the users from themselves. :-) Seriously however, as with the decision to commit command history to disk, it's up to the user to decide how to correctly use a supplied facility. The whole point of this thread is to discuss facilities that are included as standard in shells like bash, but are not available within DCL. >> >> No, there aren't to my knowledge. I was thinking about the problems that >> RECALL/INPUT and RECALL/OUTPUT, as currently implemented, would have if >> you have multiple terminal sessions open at the same time. > > Ah, you were talking about bash and writing about DCL RECALL, as you > do below. OK. > Yes, that's right. I'm using bash as an example of the things that DCL is missing. >> A DCL RECALL command to load the saved history at the start of a session, >> followed by a command to save the history at the end of the session would >> have that effect unless there was some way of telling recall to only >> append the commands entered during that session to an existing file. > > I just tried it and it works fine: Log in, do your stuff, RECALL/ > OUT=R.TMP, log out; log in, RECALL/INPUT=R.TMP!. But if you run RECALL/ > OUTPUT=R.TMP followed by RECALL/INPUT=R.TMP in the *middle* of a > session, then yes, it does as you describe; it uses the KISS paradigm. > That's true. However, imagine having multiple terminal sessions open at the same time, all of which have had their command buffers loaded with the saved history. Now imagine that you exit each session one by one, with the logout command using recall/out to save the command history. You will end up with full multiple copies of the command history added to the file if you have a command procedure to write the resulting file to a permanent command history file. If you just write the resulting output from recall/output directly to the history file, then the contents of all sessions except the last one will be overwritten. As far as I can see, recall/out has no way of appending only the commands actually used within the current session to an existing history file. > > You didn't write that. You said that when you unset the variable, the > current session doesn't get written out *if* you've used secret > params, which means that it *does* get written out if you *didn't* use > secret commands. What you meant was the converse: If you are going to > use secret params, you unset the variable first so that *no* commands > in your session are written to disk. That's not the same. > Yes, I can see how someone who doesn't know bash would indeed parse my ambiguous statement like that. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980's technology to a 21st century world ------------------------------ Date: Sun, 28 Sep 2008 00:24:14 -0700 (PDT) From: davidpryce123@yahoo.com.au Subject: USB device development on DS10 via Belkin f5U220 - OpenVMS 8.3 with 7.3-1 SRM Fi Message-ID: <219ac3ac-3709-4575-9f4d-fcfad8b68737@a19g2000pra.googlegroups.com> Hi List, I would like to use USB devices on my hobbyist DS10 to communicate with a serial (using FTDI chipset) USB device that I have developed. I know that the built-in USB on the DS10 is not supported - what a shame.... I have seen comments that USB can work with the NEC chipset on the Belkin F5u220 card - a five port USB card. So I bought on - from clue config in anal / system I can see the Belkin card. OHA: 17 NEC OHCI USB Controller OHB: 17 NEC OHCI USB Controller 17 00021799.00E01033 (3.?) Not sure what the third device is though? From show dev I can see OHA0: Offline 0 OHB0: Offline 0 USB0: Online 0 Since the card has five ports and I can see at most three ports I have tried to figure out what ports I can use. I plugged a HP PC USB keyboard into each of the four external ports and rebooted my DS10, however none of them appears to work. I looked in UCM and with the keyboard plugged into the port furtherist from the PCI interface and I can see 28-SEP-2008 14:07:12.53 DRIVER NORMAL HUBDRIVER Message: Configured device UCM0 using driver SYS$HUBDRIVER: 28-SEP-2008 14:13:27.06 DRIVER NORMAL HUBDRIVER Message: Configured device HID0 using driver SYS$KBDDRIVER: However I cannot type into a DECWindows window using this keyboard? What do I need to do to get the keyboard to work? More importantly using the QIO interface what do I need to do to talk to the FTDI usb device. I understand the USB protocol for the device and have implement user space drivers on Linux, Mac OSX and painfully on Windows. I will use C or C++. I am familar with QIO and VMS programming. I have a Ellipse USB analyser for when the fun start..... Thanks David ------------------------------ Date: Sun, 28 Sep 2008 07:51:53 -0500 (CDT) From: sms@antinode.info (Steven M. Schweda) Subject: Re: USB device development on DS10 via Belkin f5U220 - OpenVMS 8.3 with 7.3-1 SR Message-ID: <08092807515386_20202860@antinode.info> From: davidpryce123@yahoo.com.au I assume that we'll hear from the expert before very long, but in the mean time, ... > I know that the built-in USB on the DS10 is not supported - what a > shame.... Is that still true? I thought that the built-in for the XP1000 _was_ supposed to work now. (I added cheap Chinese cards with the NEC chip to mine, so I never tried to get the built-in stuff to work.) > I have seen comments that USB can work with the NEC chipset on the > Belkin F5u220 card - a five port USB card. NEC does make more than one chip, so the actual number might matter, but let's assume... > So I bought on - from clue config in anal / system I can see the > Belkin card. > > OHA: 17 NEC OHCI USB Controller > OHB: 17 NEC OHCI USB Controller > 17 00021799.00E01033 (3.?) Not sure what the third > device is though? Around here: D000 A0 OHA: 10 NEC OHCI USB Controller 1100 A4 OHB: 10 NEC OHCI USB Controller 5200 A8 10 29280E55.00E01033 (3.à) The third thing might be the USB 2.0 interface (not yet supported?). > From show dev I can see > > OHA0: Offline 0 > OHB0: Offline 0 > USB0: Online 0 Around here: OHA0: Online 0 OHB0: Online 0 UCM0: Online 0 USB0: Online 0 > Since the card has five ports and I can see at most three ports I have > tried to figure out what ports I can use. I plugged a HP PC USB > keyboard into each of the four external ports and rebooted my DS10, > however none of them appears to work. When you say "three ports", you're talking about what? Actual USB devices show up as other things. For example: alp $ show devi /full dna Disk ALP$DNA4:, device type USB 2.0 Flash Disk , is online, file-oriented device, shareable, available to cluster, error logging is enabled. [...] > However I cannot type into a DECWindows window using this keyboard? I can't remember having tried to use a USB keyboard or mouse, so I know nothing here. > More importantly using the QIO interface what do I need to do to talk > to the FTDI usb device. I understand the USB protocol for the device > and have implement user space drivers on Linux, Mac OSX and painfully > on Windows. I believe that step one would be to get some useful stuff into SYS$SYSTEM:SYS$USER_CONFIG.DAT. For example, my OH devices are "Online" while yours are "Offline". I assume that that's related to this in my SYS$USER_CONFIG.DAT: ! Added on 07-JUL-2006 17:39:14 manually by SMS. ! device = "NEC OHCI USB Controller" name = OH driver = SYS$OHCIDRIVER adapter = PCI id = 0x00351033 boot_class = DN boot_flags = HW_CTRL_LTR, UNIT_0 flags = PORT, BOOT !!! ASSOC = UCM, USB end_device (That's on my V7.3-2 system. Some work would be needed to see what's true on my V8.3 system.) I also have an entry for USB mass storage gizmos: ! Added on 08-MAR-2006 18:26:24 manually by SMS. ! device = "USB Mass storage " ! USB mass storage class device name = dn driver = sys$dndriver adapter = none boot_flags = SYS_DEV, CREATE_DEV flags = CLASS begin_private usb_config_type = interface begin_interface interface_class = 8 ! Mass storage interface_sub_class = 6 ! Uses SCSI commands interface_protocol = 80 ! Bulk only end_interface end_private end_device And, as I recall, something similar with "interface_sub_class = 5" to deal with a Nikon COOLPIX L11 camera, but that may be only on the V8.3 system. As I understand things, you need stuff like that to get your device driver associated with a particular type of USB gizmo. Again, working from memory, I believe that there's a template UGDRIVER somewhere (on V8.3, SYS$EXAMPLES?) which might tell you something. (Google can find some interesting UGDRIVER-related things, too.) ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Sun, 28 Sep 2008 10:24:27 -0400 From: "forrret.kenney@hp.com_nospam" Subject: Re: USB device development on DS10 via Belkin f5U220 - OpenVMS 8.3 with 7.3-1 SR Message-ID: wrote in message news:219ac3ac-3709-4575-9f4d-fcfad8b68737@a19g2000pra.googlegroups.com... > Hi List, > > I would like to use USB devices on my hobbyist DS10 to communicate > with a serial (using FTDI chipset) USB device that I have developed. > > I know that the built-in USB on the DS10 is not supported - what a > shame.... > It was never supported we demoed some early USB work back in 1998 on a DS10. But for many reasons the hardware team decided to pull support for the controller. > I have seen comments that USB can work with the NEC chipset on the > Belkin F5u220 card - a five port USB card. > > So I bought on - from clue config in anal / system I can see the > Belkin card. > > OHA: 17 NEC OHCI USB Controller > OHB: 17 NEC OHCI USB Controller > 17 00021799.00E01033 (3.?) Not sure what the third > device is though? That is for the EHCI controller we do not have any plans to support the EHCI (HIGH Speed controller) on any Alpha platform. > > From show dev I can see > > OHA0: Offline 0 > OHB0: Offline 0 > USB0: Online 0 > Here is how things are supposed to work. The I/O discovery code loads the host controller driver(s). In this case OHCIDRIVER and you get one instance per controller. Then if the system start up code finds a host controler it supports it loads the USB driver (common support routines not documents) and the hub driver sys$hubdriver device code UCM0. There are only ever one instance of the HUB and USB drivers. The hub driver waits for the USB driver to init it's data structures and then links all the drivers together and get the USB BUS on each controller going. Not that if OHA or OHB do not come online there is a problem and the device startup sequence did not complete correctly. This whole sequence takes a couple of seconds. > Since the card has five ports and I can see at most three ports I have > tried to figure out what ports I can use. I plugged a HP PC USB > keyboard into each of the four external ports and rebooted my DS10, > however none of them appears to work. > All 5 ports are active. There shoule be wired to one controller and two to the other. If the EHCI controller is started they are all routined to it. It then decide if it wants to control the device (ONLY HIGH speed) if not it routes it to one of the OHCI controllers. But in this case no EHCI so three go to one and two to the other OHCI controller. > I looked in UCM and with the keyboard plugged into the port furtherist > from the PCI interface and I can see > > 28-SEP-2008 14:07:12.53 DRIVER NORMAL HUBDRIVER > Message: Configured device UCM0 using driver SYS$HUBDRIVER: > > 28-SEP-2008 14:13:27.06 DRIVER NORMAL HUBDRIVER > Message: Configured device HID0 using driver SYS$KBDDRIVER: > > However I cannot type into a DECWindows window using this keyboard? There is no supported way for you to get at the USB keyboard or mouse. Sorry that is a hard and fast restriction because there is a PS2 mouse and keyboard that is all DECWindows will use... > > What do I need to do to get the keyboard to work? > > More importantly using the QIO interface what do I need to do to talk > to the FTDI usb device. I understand the USB protocol for the device > and have implement user space drivers on Linux, Mac OSX and painfully > on Windows. What FTDI device, we have support for many of the 232 family controllers. Which leads to the question what version of VMS. > > I will use C or C++. I am familar with QIO and VMS programming. > > I have a Ellipse USB analyser for when the fun start..... > > Thanks > > David Forrest ------------------------------ Date: Sun, 28 Sep 2008 10:31:09 -0400 From: "forrret.kenney@hp.com_nospam" Subject: Re: USB device development on DS10 via Belkin f5U220 - OpenVMS 8.3 with 7.3-1 SR Message-ID: >> I know that the built-in USB on the DS10 is not supported - what a >> shame.... > > Is that still true? I thought that the built-in for the XP1000 _was_ > supposed to work now. (I added cheap Chinese cards with the NEC chip to > mine, so I never tried to get the built-in stuff to work.) The built in controller in the DS10 was never supported. Shortly after the hardware was released the firmare team made the decision to hide it from the O.S. > >> I have seen comments that USB can work with the NEC chipset on the >> Belkin F5u220 card - a five port USB card. > > NEC does make more than one chip, so the actual number might matter, > but let's assume... They make two HIGH speed chips both work, one was for the 0.95 version of the EHCI specification and one was for the 1.0. On Alpha where we only support the OHCI parts it does not make any difference. > > Again, working from memory, I believe that there's a template > UGDRIVER somewhere (on V8.3, SYS$EXAMPLES?) which might tell you > something. (Google can find some interesting UGDRIVER-related things, > too.) UGDRIVER is not a template driver, it is a way for a user to get control of a USB device and communicate with it. We have a number of examples in sys$examples as well as some I have made available over the years. There is no supported way to write a USB driver outside of confines of the OpenVMS group. We do not ship any of the include files you need to build a USB driver. Forrest ------------------------------ Date: Sun, 28 Sep 2008 12:58:16 -0400 From: "forrret.kenney@hp.com_nospam" Subject: Re: USB device development on DS10 via Belkin f5U220 - OpenVMS 8.3 with 7.3-1 SR Message-ID: > Is there some reason you can't/won't ship those include files? If you > have no plans to support USB they would seem to be without commercial > value to HP. It would seem to me to be possible to offer them as > "Unsupported, we will not be responsible. . . . Have fun playing with > them. . . ." Not sure where you got the idea we have no plans on supporting USB. I am busy writing a driver to support a new USB controller what will be in the next generation Blades. I just finished a major addition to the USB SDA extension along with better address handling and an all new help. We are still actively doing USB work. What we have no plans to do is support third party USB device drivers. There are lots of reasons, we on occasion makes big changes in key routines in the USB support layer. We have done some substantial reworking of key data structures as well. The minute we release the include files even under the not supported banner we loose the flexibility to make these changes as needed. Since 1998 I have had ONE request from a third party about writing a driver. We gave them a code drop and never heard another thing from them. So with no demand and faced with a choice of spending time documenting and formalizing all the include files, support routines, and loose to freedom to make wholesale changes at any time. I did a driver that allows anyone to control a USB device using $QIO. To date I have received zero requests for help with it or a bug report. The demand is just not there to do custom USB device support for VMS. Forrest ------------------------------ Date: Sun, 28 Sep 2008 10:56:49 -0400 From: "Richard B. Gilbert" Subject: Re: USB device development on DS10 via Belkin f5U220 - OpenVMS 8.3 with 7.3-1 SR Message-ID: forrret.kenney@hp.com_nospam wrote: >>> I know that the built-in USB on the DS10 is not supported - what a >>> shame.... >> Is that still true? I thought that the built-in for the XP1000 _was_ >> supposed to work now. (I added cheap Chinese cards with the NEC chip to >> mine, so I never tried to get the built-in stuff to work.) > > The built in controller in the DS10 was never supported. Shortly after > the > hardware was released the firmare team made the decision to hide it from the > O.S. > >>> I have seen comments that USB can work with the NEC chipset on the >>> Belkin F5u220 card - a five port USB card. >> NEC does make more than one chip, so the actual number might matter, >> but let's assume... > > They make two HIGH speed chips both work, one was for the 0.95 version > of the EHCI specification and one was for the 1.0. On Alpha where we only > support the OHCI parts it does not make any difference. > >> Again, working from memory, I believe that there's a template >> UGDRIVER somewhere (on V8.3, SYS$EXAMPLES?) which might tell you >> something. (Google can find some interesting UGDRIVER-related things, >> too.) > > UGDRIVER is not a template driver, it is a way for a user to get control > of a USB device and communicate with it. We have a number of examples > in sys$examples as well as some I have made available over the years. > > There is no supported way to write a USB driver outside of confines of > the > OpenVMS group. We do not ship any of the include files you need to build > a USB driver. > > > Forrest > > Is there some reason you can't/won't ship those include files? If you have no plans to support USB they would seem to be without commercial value to HP. It would seem to me to be possible to offer them as "Unsupported, we will not be responsible. . . . Have fun playing with them. . . ." ------------------------------ Date: Sun, 28 Sep 2008 02:12:38 -0400 From: JF Mezei Subject: Re: What is a process' current WSxxxxx quotas ? Message-ID: <48df2131$0$12393$c3e8da3@news.astraweb.com> David J Dachtera wrote: > "Main, Kerry" wrote: >> On VMS V8.3+ Alpha/Integrity - >> >> $ Show Proc x/cont >> Hit W (from memory, or Q? to flip back and forth) > > Didn't want to make any brash assumptions about his VMS version... Well, i run 8.3 on an alpha. And "Q" does provide quotas, but not the working set one. Looks a lot like show proc/quota in fact. ------------------------------ End of INFO-VAX 2008.524 ************************