INFO-VAX Mon, 29 Sep 2008 Volume 2008 : Issue 525 Contents: Re: EFI Console 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 OT: USA the fleecing of USA banks by Wall Street Re: OT: USA the fleecing of USA banks by Wall Street Re: OT: USA the fleecing of USA banks by Wall Street Re: OT: USA the fleecing of USA banks by Wall Street Re: OT: USA the fleecing of USA banks by Wall Street Re: OT: USA the fleecing of USA banks by Wall Street Re: OT: USA the fleecing of USA banks by Wall Street 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 creates .RND files? ---------------------------------------------------------------------- Date: Sun, 28 Sep 2008 20:27:58 -0500 From: Jeff Subject: Re: EFI Console Message-ID: Tom Linden wrote: > John, maybe you know, when in the efi shell, the prompt always appears in the > same location in the window (connected from TTA0 on an alpha to the 232 console > port of the 2600) and overwrites what was there. How do you get it to properly > scroll, and turn off the annoying reverse video. xchar off -Jeff ------------------------------ Date: Sun, 28 Sep 2008 10:54:56 -0700 (PDT) From: AEF Subject: Re: Enhancing DCL, was: Re: How do I add 2 letters to a long Message-ID: <192218fb-968d-4eaf-870a-b25981e7dc46@f36g2000hsa.googlegroups.com> On Sep 28, 11:56 am, clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote: > 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. This is my key desire as to what DCL can't do that you say bash can. Once I mention this, bash becomes only indirectly relvant, even though this *is* relevant to the discussion as the thread evolves. > >> >> 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 don't know why. I brought it up as a separate desire and that I'd simply be happy even if I could just run (DCL's!) RECALL command from within a command procedure so that I could use FILTER with it. The "just" part means that I'm not talking about the whole shebang that you brought up, but just a part of it. Let's go to the videotape (this is a reference to a sporstcaster on a local New York City TV station who always says that immediately before they show each clip from a sports game): You wrote: "Automatic retention of command history, including the automatic merging of just the new commands from that session into the command history file. "Tab based filename completion. "Command history searching is much more elegant in bash. Hit Ctrl-R, type a few characters found anywhere in the command, which starts an immediate search through the command history, and just keep hitting Ctrl-R until the required command is found." My reply was the following: "> > Automatic retention of command history, including the automatic merging of > > just the new commands from that session into the command history file. " Command history retention in files has security implications. "I'd be quite happy with being [sic] with just being able to use RECALL/OUT in a command procedure. This way I could use my FILTER command procedure search [sic] for strings in the recall buffer. "Yeah, let me guess: security implications. " So as far as "history retention" is concerned, I was just saying that I'd be happy for VMS Engineering to just simply rewrite the RECALL command and/or DCL so as to allow me to run RECALL from within a command procedure. Then you went on and on about bash in response to this, which I didn't ask about and don't care about for this question as it is not directly relevant. > >> 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. But DCL treats it as such! I'm simply asking why. Why the *difference*? Forget about bash for a minute. It's not relevant to this question! If you don't know the answer then please simply just say so. Please don't repeat "security"; I've got that part already. But "security" applies to *both* cases, and DCL does it in only one of the two cases, so you're not answering the question. Whenever I ask this question, (i.e. why you can't run RECALL from within a command procedure), people always respond with "it's a security issue". Fine. But how are the "security implications" different bewteen running RECALL from a DCL prompt and running the same from within a command procedure, since the resulting output is the same? What's the difference? The result is the same. The security issue is the same. So why was one case (apparently, if not certainly) designed to not work while the other clearly does? I don't know how to make this question any clearer, any more explicit, any more plainly, any more to the point. For the purposes of this question, I'm asking about DCL, not bash. I can, however, make the question more succinct: Why does the DCL command RECALL work at a prompt, but not from within a command procedure; even though the result, and hence the security issue, is the same? > > 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. > :-) Except that in many cases it doesn't. It should, though, protect the users from itself! > 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. And running the DCL command RECALL from within a command procedure was designed to not work. Even if it's not the original motivation of the thread, I'm brining it up as a separate question. And your issue with bash is similarly not the original point of the thread either but is brought up as a separate, though related, point. The original motivation was a poster wanting help with editing commands that are so long, they wrap. Your bringing up bash is just as "off-thread" as my bringing up the issue with RECALL. > >> 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. Fine. I'm simply asking what the motivation might be for one of those things that DCL can't do. While that doesn't involve bash directly, it *is* relevant to this discussion; just as bash doesn't directly involve the original poster's problem. You want DCL to do blah, blah, blah. . .blah and I'm just saying that I'd be thrilled even if only a certain PART of one of those blah's were made to work. > >> 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. Fine, but you already made that point in a previous post. I'm no asking about that. > > 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. It wasn't ambiguous; it was the converse of what you meant. > > Simon. > > -- > Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP > Microsoft: Bringing you 1980's technology to a 21st century world AEF ------------------------------ Date: 28 Sep 2008 13:28:38 -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: In article <192218fb-968d-4eaf-870a-b25981e7dc46@f36g2000hsa.googlegroups.com>, AEF writes: > On Sep 28, 11:56 am, clubley@remove_me.eisner.decus.org-Earth.UFP > (Simon Clubley) wrote: >> >> 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 don't know why. I brought it up as a separate desire and that I'd > simply be happy even if I could just run (DCL's!) RECALL command from > within a command procedure so that I could use FILTER with it. The > "just" part means that I'm not talking about the whole shebang that > you brought up, but just a part of it. > I misunderstood what your FILTER routine was doing. >> >> 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. > > But DCL treats it as such! I'm simply asking why. Why the > *difference*? Forget about bash for a minute. It's not relevant to > this question! If you don't know the answer then please simply just > say so. Please don't repeat "security"; I've got that part already. > But "security" applies to *both* cases, and DCL does it in only one of > the two cases, so you're not answering the question. > I see the confusion now about security. I was responding to the suggestion made early on in the thread by someone else that storing command history within a file is a security risk. I thought you were continuing that line of enquiry. You on the other hand were discussing security in the context of having been told that recall/out can't be implemented within a command procedure because it's a security problem. That's an interesting comment and it would be interesting to know from VMS Engineering why they consider it a security issue. I can only think that they are concerned that a user could be tricked into running a command procedure that could capture their commands and mail them somewhere without the user knowing. However, I can think of far more dangerous things that such a command procedure could do. 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 17:36:57 -0400 From: JF Mezei Subject: Re: Enhancing DCL, was: Re: How do I add 2 letters to a long Message-ID: <48dffa00$0$3375$c3e8da3@news.astraweb.com> Simon Clubley wrote: > 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 Not if your command procedure has code such as: $recall/output=temp.tmp $append temp.tmp mycommands.dat $sort mycommands.dat mycommands.dat/noduplicates (ok, you might have to deal with cases where your file grows to be bigger than what VMS supports for RECALL/INPUT :-) But even with such a thing, an abnormal termination of your session would not update the stored file, it would only be updated with a "normal" termination that ends up calling your procedure before doing the logout command. Yes, the Unix way is more elegant. There should be some way to turn it off when doing a security related session if it were implemented on VMS. ------------------------------ Date: Sun, 28 Sep 2008 17:12:19 -0400 From: JF Mezei Subject: OT: USA the fleecing of USA banks by Wall Street Message-ID: <48dff42a$0$1527$c3e8da3@news.astraweb.com> This is very OT, but I'd like some feedback from intelligent people... It wasn't so long ago that Russia essentially transfered the assets from Yukos Oil to some other oil company. This past Thursday, instead of lending money to Washington Mutual like it has done to the Wall Street banks over the last couple of months, the FDIC seized assets of Washington Mutual and immediatly gave them to Chase Manhattan (or whatever it is called this week with all the mergers it has had). The 1.9 billion Chase paid for the WaMu bank's assets went to FDIC. Washington Mutual shareholders were left to hold worthless stock because the FDIC did not arrange for a sale of the bank to Chase, they transfered assets. (This is different from the wall street emergency mergers such as Bear Stearns where BS shareholders will get money and will get to approve the deal). Am I the only one who is highly suspicious of this transaction ? Looks to me that Washington is acting solely in the interest of a few Wall Street Casino establishements (because of their good frienships with Washington). WaMu had grown from a small regional bank that was no threath to Wall Street into a sizeable bank that was stealing customers. And Chase found a very easy and cheap way to kill off a competitor and get its assets. About a week and a half ago, rumours of WaMu not doing well started to surface. I heard it on the BBC, so this wasn't just "local" rumours. Obviously, this causes a run on on the bank. Shouldn't the SEC investigate this ? Obviously, it would be politically impossible for the SEC to find that Chase started those rumours. And the timing of this also fits nicely with Bush's "if you don't approve the 700 billion packlage to help the wall street casino before sunday night, the whole USA banking system will crumble". Having a large bank fail just before this greatly helps motivate the congress/senate to pass that bill and makes it easier to convince the population of the needs to give a 700 billion gift to Wall Street (but not lend 16 billion to WaMu to ride through a temporary patch of bad time). BTW, it is highly irresponsible for a president/prime minister to announce that the country's banking system will crumble in 3 days if they don't approve his project. This is a self fulfilling prophecy thing because the rest of the world and the USA investors would immediatly pull their money from USA banks on sunday night/monday morning and cause it to crumble. So USA legislators have no choice but to pass that bill now. ------------------------------ Date: Sun, 28 Sep 2008 22:47:17 +0100 From: Mark McIntyre Subject: Re: OT: USA the fleecing of USA banks by Wall Street Message-ID: JF Mezei wrote: > This past Thursday, instead of lending money to Washington Mutual like > it has done to the Wall Street banks over the last couple of months, the > FDIC seized assets of Washington Mutual No it didn't. > and immediatly gave them to Chase Manhattan No it didn't. > (or whatever it is called this week with all the mergers > it has had). It hasn't been called Chase Manhattan for a decade or so. > The 1.9 billion Chase paid for the WaMu bank's assets went > to FDIC. No it didn't. > > Washington Mutual shareholders were left to hold worthless stock because > the FDIC did not arrange for a sale of the bank to Chase, they > transfered assets. Thats untrue. The shareholders are left with worthless stock because the company stock was worthless at the time of the sale. I'm not sure you understand the difference between having no money and having no assets. > Am I the only one who is highly suspicious of this transaction ? Possibly but you're far from the only one who doesn't understand whats happened. For the record, JPMorgan Chase bought WaMu holding company in an auction organised by the FDIC, following the failure of the previous attempt by GS to find buyers. WaMu's shareprice had dropped from over $45 to under $2 by that stage, and were eventually trading at $0.16. The 1.9Bn raised will go to pay off Wamu's creditors first, then outstanding bills, finally shareholders. > WaMu had grown from a small regional bank that was no threath to Wall > Street into a sizeable bank that was stealing customers. Oh, great - a conspiracy theory. ------------------------------ Date: Sun, 28 Sep 2008 18:26:42 -0400 From: JF Mezei Subject: Re: OT: USA the fleecing of USA banks by Wall Street Message-ID: <48e0053d$0$9653$c3e8da3@news.astraweb.com> Mark McIntyre wrote: > JF Mezei wrote: >> This past Thursday, instead of lending money to Washington Mutual like >> it has done to the Wall Street banks over the last couple of months, the >> FDIC seized assets of Washington Mutual > > No it didn't. I can't seem to find it now, but yesterday, there were documents on the FDIC web site that clearly and unequivocably stated that the FDIC had SEIZED the assets of Wamu And sold them to Chase. (ok, JPMorganChase to make you happy, but it is really Chase) >> and immediatly gave them to Chase Manhattan > > No it didn't. Well, the transaction was pretty quick since the seizure of assets and announcement of their sale to Chase was done on the same day. > It hasn't been called Chase Manhattan for a decade or so. And HP's stock hasn't traded as "HP" for a while too, and despite its stockl tiocker having remnants of Compaq, there is no remnant of Compaq within HP's management structure. Compaq was fully assimilated into HP. Just because some bank mergers had strong enough egos to result in the two names surviving doesn't mean that functionally, both banks remain intact within the new structure. When Chemical Bank bought Manufacturer's Hanover Bank, the later name was dropped. When Chemical bought Chase, it dropped its own name in favour of the more well known Chase Manhattan Bank. But it was Chemical's upper management that stayed, although Chase's operations were retained. But when Chemical Bank (now called Chase) bought JP Morgan, the Jp Morgan folks managed to have their name survive. When the small Nations Bank bought Bank of America, they of course kept the far more well known Bank of America name. But many of the functions > Thats untrue. The shareholders are left with worthless stock because the > company stock was worthless at the time of the sale. I'm not sure you > understand the difference between having no money and having no assets. Rumours of WaMu not doing well started a week or two ago. The current $0.16 share value is due to the FDIC seizure, the stock is still trading. It was at about $2.00 before FDIC intervened. The point here is that for Wall Street banks, the Feds more than willingly loaned money to help them, but in the case of west coast based bank, it pounced on it. > For the record, JPMorgan Chase bought WaMu holding company in an auction > organised by the FDIC, following the failure of the previous attempt by > GS to find buyers. How come none of the documents on FDIC or WaMu web sites speak of a auction ? When was such an auction held ? How come WaMu shareholders have no seay in the matter whereas shsraeholder of Bear Strearns get to approve the deal and debated whether they would get more money by liquidating it or selling to Chase. > $2 by that stage, and were eventually trading at $0.16. The 1.9Bn raised > will go to pay off Wamu's creditors first, then outstanding bills, > finally shareholders. And had the FDIC waited an extra weekend before acting, WaMu would have been able to draw on some of the 700 billion gift to banks and its stock would have gone way back up. ------------------------------ Date: 28 Sep 08 18:52:07 EDT From: cook@wvnvms.wvnet.edu (George Cook) Subject: Re: OT: USA the fleecing of USA banks by Wall Street Message-ID: In article <48dff42a$0$1527$c3e8da3@news.astraweb.com>, JF Mezei writes: > This is very OT, but I'd like some feedback from intelligent people... > > It wasn't so long ago that Russia essentially transfered the assets from > Yukos Oil to some other oil company. > > This past Thursday, instead of lending money to Washington Mutual like > it has done to the Wall Street banks over the last couple of months, the > FDIC seized assets of Washington Mutual and immediatly gave them to > Chase Manhattan (or whatever it is called this week with all the mergers > it has had). The 1.9 billion Chase paid for the WaMu bank's assets went > to FDIC. > > Washington Mutual shareholders were left to hold worthless stock because > the FDIC did not arrange for a sale of the bank to Chase, they > transfered assets. (This is different from the wall street emergency > mergers such as Bear Stearns where BS shareholders will get money and > will get to approve the deal). > > Am I the only one who is highly suspicious of this transaction ? Looks > to me that Washington is acting solely in the interest of a few Wall > Street Casino establishements (because of their good frienships with > Washington). > > WaMu had grown from a small regional bank that was no threath to Wall > Street into a sizeable bank that was stealing customers. And Chase found > a very easy and cheap way to kill off a competitor and get its assets. > > About a week and a half ago, rumours of WaMu not doing well started to > surface. I heard it on the BBC, so this wasn't just "local" rumours. > Obviously, this causes a run on on the bank. Shouldn't the SEC > investigate this ? Obviously, it would be politically impossible for the > SEC to find that Chase started those rumours. > > And the timing of this also fits nicely with Bush's "if you don't > approve the 700 billion packlage to help the wall street casino before > sunday night, the whole USA banking system will crumble". Having a large > bank fail just before this greatly helps motivate the congress/senate to > pass that bill and makes it easier to convince the population of the > needs to give a 700 billion gift to Wall Street (but not lend 16 billion > to WaMu to ride through a temporary patch of bad time). > > > BTW, it is highly irresponsible for a president/prime minister to > announce that the country's banking system will crumble in 3 days if > they don't approve his project. This is a self fulfilling prophecy thing > because the rest of the world and the USA investors would immediatly > pull their money from USA banks on sunday night/monday morning and cause > it to crumble. So USA legislators have no choice but to pass that bill now. 1. Never use intelligence as an explanation when stupidity will suffice. If Wall Street and Washington were even half as smart as your conspiracy theories require, we wouldn't be on the brink of a global financial collapse. 2. The situation is worse than most dare say out loud. Anyone who understands the functioning of monetary systems knows that money is little more than an illusion and that monetary and financial systems are nothing more than very large, very elaborate houses of cards. The US financial house of cards very nearly totally collapsed about ten days ago (the global house of cards would have come down soon after). 3. Fortunately, unlike during the collapse which caused the Great Depression (which we only escaped from by having a major war), the US government appears ready to do whatever is needed. 4. The collapse started with the subprime debacle which turned out to be much worse than anyone initially thought (instead of "irrational enthusiasm," Greenspan should have said "total mass insanity.") Since then Washington has been shoring up the house by moving cards from the sturdier parts to the weaker parts (a little like rearranging the deck chairs on the Titanic) and by making more cards (aka "printing money"). 5. Bush can either do pretty much exactly what he is doing, or he can go down in history as Herbert Hoover II. As far as who to blame in Washington, the Democrats are every bit as much at fault as the Republicans. 6. WaMu's so called assets are going to cause Chase to absorb around $35 billion in bad debt if I recall the numbers correctly. There is only so much bad debt Chase, Bank of America and foreign banks can take on. If too many large banks fail, there will be no one left to absorb them. George Cook ------------------------------ Date: 28 Sep 08 19:05:10 EDT From: cook@wvnvms.wvnet.edu (George Cook) Subject: Re: OT: USA the fleecing of USA banks by Wall Street Message-ID: In article <48e0053d$0$9653$c3e8da3@news.astraweb.com>, JF Mezei writes: > And had the FDIC waited an extra weekend before acting, WaMu would have > been able to draw on some of the 700 billion gift to banks and its stock > would have gone way back up. Once the bank run was well underway, WaMu was dead meat. It may have been possible to lock WaMu's doors (including stopping all its Fed and interbank transfers), but I suspect that would have sent massive shock waves thru the house of cards not to mention that WaMu's depositors would have no access to their deposits for the duration (possibly causing a financial panic in the population). No, you kill a badly wounded animal as soon as possible before the commotion panics the herd. George Cook ------------------------------ Date: Mon, 29 Sep 2008 01:02:40 +0000 (UTC) From: moroney@world.std.spaamtrap.com (Michael Moroney) Subject: Re: OT: USA the fleecing of USA banks by Wall Street Message-ID: cook@wvnvms.wvnet.edu (George Cook) writes: >In article <48e0053d$0$9653$c3e8da3@news.astraweb.com>, JF Mezei writes: >> And had the FDIC waited an extra weekend before acting, WaMu would have >> been able to draw on some of the 700 billion gift to banks and its stock >> would have gone way back up. >Once the bank run was well underway, WaMu was dead meat. It may have >been possible to lock WaMu's doors (including stopping all its Fed >and interbank transfers), but I suspect that would have sent massive >shock waves thru the house of cards not to mention that WaMu's >depositors would have no access to their deposits for the duration >(possibly causing a financial panic in the population). When Lehman Brothers failed, people started withdrawing their savings from WaMu, even though with FDIC their money wasn't in danger. By the time the FDIC took over, about 10% of their savings had been withdrawn. A literal run on the bank. The run was fueled by rumors WaMu was in trouble, and this turned out to be a self-fulfilling prophesy. ------------------------------ Date: Sun, 28 Sep 2008 18:04:05 -0700 (PDT) From: AEF Subject: Re: OT: USA the fleecing of USA banks by Wall Street Message-ID: <048321c5-953b-4d54-a9f5-b198d308227d@d1g2000hsg.googlegroups.com> On Sep 28, 7:52 pm, c...@wvnvms.wvnet.edu (George Cook) wrote: > In article <48dff42a$0$1527$c3e8...@news.astraweb.com>, JF Mezei writes: > > > > > This is very OT, but I'd like some feedback from intelligent people... > > > It wasn't so long ago that Russia essentially transfered the assets from > > Yukos Oil to some other oil company. > > > This past Thursday, instead of lending money to Washington Mutual like > > it has done to the Wall Street banks over the last couple of months, the > > FDIC seized assets of Washington Mutual and immediatly gave them to > > Chase Manhattan (or whatever it is called this week with all the mergers > > it has had). The 1.9 billion Chase paid for the WaMu bank's assets went > > to FDIC. > > > Washington Mutual shareholders were left to hold worthless stock because > > the FDIC did not arrange for a sale of the bank to Chase, they > > transfered assets. (This is different from the wall street emergency > > mergers such as Bear Stearns where BS shareholders will get money and > > will get to approve the deal). > > > Am I the only one who is highly suspicious of this transaction ? Looks > > to me that Washington is acting solely in the interest of a few Wall > > Street Casino establishements (because of their good frienships with > > Washington). > > > WaMu had grown from a small regional bank that was no threath to Wall > > Street into a sizeable bank that was stealing customers. And Chase found > > a very easy and cheap way to kill off a competitor and get its assets. > > > About a week and a half ago, rumours of WaMu not doing well started to > > surface. I heard it on the BBC, so this wasn't just "local" rumours. > > Obviously, this causes a run on on the bank. Shouldn't the SEC > > investigate this ? Obviously, it would be politically impossible for the > > SEC to find that Chase started those rumours. > > > And the timing of this also fits nicely with Bush's "if you don't > > approve the 700 billion packlage to help the wall street casino before > > sunday night, the whole USA banking system will crumble". Having a large > > bank fail just before this greatly helps motivate the congress/senate to > > pass that bill and makes it easier to convince the population of the > > needs to give a 700 billion gift to Wall Street (but not lend 16 billion > > to WaMu to ride through a temporary patch of bad time). > > > BTW, it is highly irresponsible for a president/prime minister to > > announce that the country's banking system will crumble in 3 days if > > they don't approve his project. This is a self fulfilling prophecy thing > > because the rest of the world and the USA investors would immediatly > > pull their money from USA banks on sunday night/monday morning and cause > > it to crumble. So USA legislators have no choice but to pass that bill now. > > 1. Never use intelligence as an explanation when stupidity will > suffice. If Wall Street and Washington were even half as smart > as your conspiracy theories require, we wouldn't be on the brink > of a global financial collapse. > > 2. The situation is worse than most dare say out loud. Anyone > who understands the functioning of monetary systems knows that > money is little more than an illusion and that monetary and financial > systems are nothing more than very large, very elaborate houses > of cards. The US financial house of cards very nearly totally > collapsed about ten days ago (the global house of cards would > have come down soon after). > > 3. Fortunately, unlike during the collapse which caused the Great > Depression (which we only escaped from by having a major war), > the US government appears ready to do whatever is needed. > > 4. The collapse started with the subprime debacle which turned out > to be much worse than anyone initially thought (instead of > "irrational enthusiasm," Greenspan should have said "total mass > insanity.") Since then Washington has been shoring up the house by > moving cards from the sturdier parts to the weaker parts (a little > like rearranging the deck chairs on the Titanic) and by making more > cards (aka "printing money"). > > 5. Bush can either do pretty much exactly what he is doing, or he can > go down in history as Herbert Hoover II. As far as who to blame > in Washington, the Democrats are every bit as much at fault as the > Republicans. > > 6. WaMu's so called assets are going to cause Chase to absorb around > $35 billion in bad debt if I recall the numbers correctly. There > is only so much bad debt Chase, Bank of America and foreign banks > can take on. If too many large banks fail, there will be no one > left to absorb them. > > George Cook Thanks for the great summary, but just for the record, Greenspan called it "irrational exuberance". This, of course, became an instant classic. AEF AEF ------------------------------ Date: Sun, 28 Sep 2008 14:33:35 -0700 (PDT) From: davidpryce123@yahoo.com.au Subject: Re: USB device development on DS10 via Belkin f5U220 - OpenVMS 8.3 with 7.3-1 SR Message-ID: <57260f99-ac5d-469c-9a2a-00ed3b3ee69e@r15g2000prh.googlegroups.com> Hi List, Thanks for your answers. Some great pointers in there. BTW I have VMS 8.3 and the device is FTDI RS232R. I want to write a user space USB driver and the UGDRIVER looks ideal. The one thing I am unsure of is to do with the Belkin card I have. Can I use all five USB ports on the card? Thanks David ------------------------------ Date: Sun, 28 Sep 2008 21:19:52 -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: <08092821195218_20202860@antinode.info> From: davidpryce123@yahoo.com.au > The one thing I am unsure of is to do with the Belkin card I have. > Can I use all five USB ports on the card? I don't see why not. To convince yourself, move some device around from hole to hole, and watch what UCM SHOW EVENTS says. The OHA0 and OHB0 devices do not correspond to individual connectors on the card. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Sun, 28 Sep 2008 23:50:47 -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:57260f99-ac5d-469c-9a2a-00ed3b3ee69e@r15g2000prh.googlegroups.com... > Hi List, > > Thanks for your answers. Some great pointers in there. > > BTW I have VMS 8.3 and the device is FTDI RS232R. I want to write a > user space USB driver and the UGDRIVER looks ideal. > > The one thing I am unsure of is to do with the Belkin card I have. > > Can I use all five USB ports on the card? > I thought I made it clear that all 5 port work. Some go to the first OHCI controller the rest go to the other. Also don't be surprised if you plug you FTDI RS232 device in that it get claimed by the O.S. In V8.3 for both Alpha and IA64 we ship drivers and configuration data for the FTDI 232 controller. It should show up as TXC0. Forrest ------------------------------ Date: Sun, 28 Sep 2008 23:54: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: "JF Mezei" wrote in message news:48dff60a$0$1527$c3e8da3@news.astraweb.com... > forrret.kenney@hp.com_nospam wrote: > >> 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. > > Just a comment: > > If no further serious development is to be made on the USB services on > Alpha VMS, perhaps VMS engineering could convince their management it > should be OK to release those files so that those who wish to develop > their own could. The USB driver code is common and other than a small number of conditionals for alpha console support for the GS1280 and ES47 what gets compiled for IA64 gets compiled for Alpha. As much as possible it will remain that way for as long as I have any say in the USB code stream. Forrest ------------------------------ Date: Sun, 28 Sep 2008 17:20:20 -0400 From: JF Mezei Subject: Re: USB device development on DS10 via Belkin f5U220 - OpenVMS 8.3 with 7.3-1 SR Message-ID: <48dff60a$0$1527$c3e8da3@news.astraweb.com> forrret.kenney@hp.com_nospam wrote: > 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. Just a comment: If no further serious development is to be made on the USB services on Alpha VMS, perhaps VMS engineering could convince their management it should be OK to release those files so that those who wish to develop their own could. ------------------------------ Date: Sun, 28 Sep 2008 18:41:03 -0700 From: VMS is Virus Free Subject: Re: What creates .RND files? Message-ID: <0bc0e4lcg5sibk77vo92rlhh8v9rlute76@4ax.com> On Fri, 26 Sep 2008 08:27:23 -0700 (PDT), Rich Jordan wrote: >On Sep 25, 3:20 pm, VMS is Virus Free wrote: >> On Wed, 24 Sep 2008 13:58:42 -0500, VMS is Virus Free >> >> >> >> wrote: >> >We have a VMS V8.3 system running Multinet and Oracle Rdb. Other than >> >Rdb, it is pretty much a run-of-the-mill VMS system. When analyzing >> >our disks, we found there to be a bunch of .RND;1 files, just one >> >each, in everyone's top level directory. Each file is exactly 2 blocks >> >long. A dump shows just random binary values. So, true to its name, it >> >does look like random data. >> >> >We connect to the system with both telnet and SSH from Windows systems >> >(PuTTY and CRT) and from other VMS system. There is even some SET HOST >> >activity still going on as we continue to support LAT. >> >> >I seem to recall from somewhere in the past the Rdb created these >> >files as pat of its normal operations. I also know that SSH likes to >> >have a random seed here an there. I've Googled this condition but did >> >not find anything definite. >> >> >This is mostly curiosity as to where they come from. Any ideas? >> >> We have traced this so far the SSL connections during times of high >> activity and concurrent SSL connections. Since the SSL files are SSL >> related, there's probably a bug in the code that handles this part of >> the connection. > >Key generation in general (PGP, OpenSSL) involves either reading in >random input or using a random input file. Perhaps this is debris >from that activity. > >I have a 2-block long file under my login directory on our (OpenVMS >V7.3-2, TCPIP V5.4 eco 7) system called [.ASRG-OPENSSL]RANDOM.RND;1 >created in 2002. Thats about the time we were playing with OpenSSL >for a project. What we have found so far: - Quiet times, one job: one RND file gets created and cleaned up - Busy, multiple concurrent jobs: .RND files get left behind (or lost) We have not yet traced down the cause; we only know that heavy activity with SSL connections causes the issue. It gets stranger when the .RND;1 file gets up to .RND;32767. Tought to find; easy to provide load, hard to simulate randomness of heavy load. A work in progres... ------------------------------ End of INFO-VAX 2008.525 ************************