INFO-VAX Mon, 04 Jun 2007 Volume 2007 : Issue 304 Contents: RE: Anyone know why the Alpha market is so so quiet? Can't connect to OPA0 on XP1000 Re: Can't connect to OPA0 on XP1000 Re: Can't connect to OPA0 on XP1000 Re: HP wasting millions of dollars on itanium! Re: HP wasting millions of dollars on itanium! Re: HP wasting millions of dollars on itanium! Re: HP wasting millions of dollars on itanium! RE: HP wasting millions of dollars on itanium! Re: HP wasting millions of dollars on itanium! Re: HP wasting millions of dollars on itanium! Re: Paging and process state Re: Paging and process state Re: Paging and process state Re: Paging and process state Re: SYSMAN problem Re: Whom administers openvmshobbyist.org forums? ---------------------------------------------------------------------- Date: Mon, 4 Jun 2007 10:17:29 -0400 From: "Koska, John C. \(LNG-ALB\)" Subject: RE: Anyone know why the Alpha market is so so quiet? Message-ID: To add to my prior response,...because it works! :) jck John Koska Matthew Bender & Co., Inc. 1275 Broadway Albany, NY 12204 (518)-487-3255 (518)-487-3136 FAX Jkoska@bender.com John.C.Koska@lexisnexis.com =20 ------------------------------ Date: Mon, 04 Jun 2007 08:02:15 -0700 From: "Tom Linden" Subject: Can't connect to OPA0 on XP1000 Message-ID: I normally connect from a W2K box through hyperterm to OPA0 (the top connector) but am not getting a response. Is something missing from my settings? I have the console set to serial. Hyperterm is set to 9600-8-N-1 Terminal: _OPA0: Device_Type: Unknown Owner: No Owner Input: 9600 LFfill: 0 Width: 80 Parity: None Output: 9600 CRfill: 0 Page: 24 Terminal Characteristics: Interactive Echo Type_ahead No Escape No Hostsync TTsync Lowercase No Tab Wrap Scope No Remote No Eightbit Broadcast No Readsync No Form Fulldup No Modem No Local_echo No Autobaud No Hangup No Brdcstmbx No DMA No Altypeahd Set_speed No Commsync Line Editing Overstrike editing No Fallback No Dialup No Secure server No Disconnect No Pasthru No Syspassword No SIXEL Graphics No Soft Characters No Printer Port Numeric Keypad No ANSI_CRT No Regis No Block_mode No Advanced_video No Edit_mode No DEC_CRT No DEC_CRT2 No DEC_CRT3 No DEC_CRT4 No DEC_CRT5 No Ansi_Color VMS Style Input -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Mon, 04 Jun 2007 16:57:53 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Can't connect to OPA0 on XP1000 Message-ID: <00A68A30.6DA05B1F@SendSpamHere.ORG> In article , "Tom Linden" writes: > > >I normally connect from a W2K box through hyperterm to OPA0 >(the top connector) but am not getting a response. > >Is something missing from my settings? I have the console >set to serial. Hyperterm is set to 9600-8-N-1 > >Terminal: _OPA0: Device_Type: Unknown Owner: No Owner > > Input: 9600 LFfill: 0 Width: 80 Parity: None > Output: 9600 CRfill: 0 Page: 24 > >Terminal Characteristics: > Interactive Echo Type_ahead No Escape > No Hostsync TTsync Lowercase No Tab > Wrap Scope No Remote No Eightbit > Broadcast No Readsync No Form Fulldup > No Modem No Local_echo No Autobaud No Hangup > No Brdcstmbx No DMA No Altypeahd Set_speed > No Commsync Line Editing Overstrike editing No Fallback > No Dialup No Secure server No Disconnect No Pasthru > No Syspassword No SIXEL Graphics No Soft Characters No Printer Port > Numeric Keypad No ANSI_CRT No Regis No Block_mode > No Advanced_video No Edit_mode No DEC_CRT No DEC_CRT2 > No DEC_CRT3 No DEC_CRT4 No DEC_CRT5 No Ansi_Color > VMS Style Input From another source connected to the Alpha, can you $ SET HOST/DTE OPA0: ? If you can, use your PeeCee and see if you can talk back and forth between the two connections. You can also see if OPA0: is working by putting a short on pins 2 and 3 of the OPA0: connector (TX and RX lines). If you connect with $ SET HOST/DTE OPA0: and type with 2-3 shorted, you should see what you type echoed back. Similarly, you could do the same with the PeeCee. Make sure you can communication on both before persuing further. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" ------------------------------ Date: Mon, 04 Jun 2007 10:14:50 -0700 From: "Tom Linden" Subject: Re: Can't connect to OPA0 on XP1000 Message-ID: On Mon, 04 Jun 2007 09:57:53 -0700, VAXman- <@SendSpamHere.ORG> wrote: > In article , "Tom Linden" > writes: >> >> >> I normally connect from a W2K box through hyperterm to OPA0 >> (the top connector) but am not getting a response. >> >> Is something missing from my settings? I have the console >> set to serial. Hyperterm is set to 9600-8-N-1 >> >> Terminal: _OPA0: Device_Type: Unknown Owner: No Owner >> >> Input: 9600 LFfill: 0 Width: 80 Parity: None >> Output: 9600 CRfill: 0 Page: 24 >> >> Terminal Characteristics: >> Interactive Echo Type_ahead No Escape >> No Hostsync TTsync Lowercase No Tab >> Wrap Scope No Remote No Eightbit >> Broadcast No Readsync No Form Fulldup >> No Modem No Local_echo No Autobaud No Hangup >> No Brdcstmbx No DMA No Altypeahd Set_speed >> No Commsync Line Editing Overstrike editing No Fallback >> No Dialup No Secure server No Disconnect No Pasthru >> No Syspassword No SIXEL Graphics No Soft Characters No Printer >> Port >> Numeric Keypad No ANSI_CRT No Regis No >> Block_mode >> No Advanced_video No Edit_mode No DEC_CRT No DEC_CRT2 >> No DEC_CRT3 No DEC_CRT4 No DEC_CRT5 No >> Ansi_Color >> VMS Style Input > > From another source connected to the Alpha, can you $ SET HOST/DTE OPA0: > ? > If you can, use your PeeCee and see if you can talk back and forth > between > the two connections. You can also see if OPA0: is working by putting a > short on pins 2 and 3 of the OPA0: connector (TX and RX lines). If you > connect with $ SET HOST/DTE OPA0: and type with 2-3 shorted, you should > see what you type echoed back. Similarly, you could do the same with the > PeeCee. Make sure you can communication on both before persuing further. > I put the other end into TTA0 on a DS10L and was able to connect to it so either the settings on Hyperterm (VT100) 9600-8-N-1 are wrong or it has packed up. Maybe I will reboot it, it is W2K afterall -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Mon, 04 Jun 2007 09:05:08 +0200 From: Dirk Munk Subject: Re: HP wasting millions of dollars on itanium! Message-ID: JF Mezei wrote: > Arne Vajhøj wrote: > >> I just doubt that HP or the ISV's are that interested in porting. > > > If VMS were to be ported to the 8086 architecture, it would send a very > strong signal that HP is serious about growing VMS. It would also put > VMS on a platform whose future is not in question. It would be on an > equal footing with Linux, Solaris and Windows as well as many other > operating systems. > > Like it or not, IA64 has been plagued by rumours of its demise even > before Merced first booted Windows which is one reason the announcement > of porting VMS to IA64 was so poorly received. > > For all its technical weaknesses, the 8086 has market share and an > assured future. > > The saying used to be: Nobody has ever been fired for choosing IBM > > The saying is now: Nobody will be fired for porting to the 64 bit 8086 > architecture. > > > And right now, HP's refusal to port VMS to a viable platform is also > interpreted as HP abandonning VMS and allowing key ISVs like Cerner to > drop ou of VMS. > > HP has no duty to help Intel's financials. HP has a duty to its own > shareholders and its own customers. Don,t force customers to a platform > they don,t want just because you want to please Intel's CEO. No doubt OpenVMS could be ported to a number of CPU architectures. The point is that HP is building big iron for HP-UX based on IA64. OpenVMS is graciously allowed to run on the same iron. HP will never design enterprise servers based on another CPU just for OpenVMS. Porting OpenVMS to any other CPU would send out the message that HP no longer believes in the future of IA64. That in turn means that HP-UX has no future, since porting HP-UX to another CPU would be far more difficult. Guess what would happen to the HP shares when it becomes clear that HP-UX has no future...... We all agree that HP has maneuvered itself in a cul de sac with the IA64. If you want to look for a way out, you have to look for a way out for HP-UX. With some luck, HP will allow OpenVMS to use the same way out. Sad but true I'm afraid. ------------------------------ Date: Mon, 4 Jun 2007 10:49:03 +0000 (UTC) From: david20@alpha2.mdx.ac.uk Subject: Re: HP wasting millions of dollars on itanium! Message-ID: In article , Ron Johnson writes: >On 06/03/07 16:38, JF Mezei wrote: >> Arne Vajhøj wrote: >> >>> I just doubt that HP or the ISV's are that interested in porting. >> >> >> If VMS were to be ported to the 8086 architecture, it would send a very >> strong signal that HP is serious about growing VMS. It would also put >> VMS on a platform whose future is not in question. It would be on an >> equal footing with Linux, Solaris and Windows as well as many other >> operating systems. > >I *guarantee* you that VMS, Linux, Solaris and WNT will *never* be >ported to the 8086. > >Never. > >Ever. > Ron, We have had that argument with JF for the last couple of years. Just translate 8086 to x86-64 whenever he posts about it in the context of modern systems. Since JF hasn't responded to discussion , bribes (of chocolate bars) or threats (baseball bats :) ) it seems unlikely he will stop using 8086 now. David Webb Security team leader CCSS Middlesex University >-- >Ron Johnson, Jr. >Jefferson LA USA > >Give a man a fish, and he eats for a day. >Hit him with a fish, and he goes away for good! ------------------------------ Date: Mon, 04 Jun 2007 03:59:43 -0700 From: etmsreec@yahoo.co.uk Subject: Re: HP wasting millions of dollars on itanium! Message-ID: <1180954783.145278.270840@o5g2000hsb.googlegroups.com> JF, You complain that nobody's porting to IA64 because nobody believes in it. Porting to ANOTHER different platform is likely to drop even more applications and, therefore, solutions along the way. Whether you call it (incorrectly) 8086 or x86 or x86-64, it isn't going to make it any more attractive to the companies that write the applications that customers want to run. There's a fundamental issue here that people miss: When VAX was launched, the whole solution came from Digital - the hardware, the OS and all the applications that ran on them. Applications got lost (dropped) on the port to Alpha. More have been lost since, so the portfolio of both hird party applications and (now) HP supplied applications is much smaller. Moving to IA64 is claimed to have been responsible for losing more so moving to x86-64 is likely to mean that even more of the few remaining get lost. In other words, you might have a fine operating system on x86-64, but you'll have next to no applications to run on it. Whether the cost of the hardware is nil or not. Customers don't want to run VMS because it's VMS. Customers want to have the features that the applications and environment provide, whether that be high availability, high reliability or just that their application is only available on there. Just think of IA64 as the new Alpha. Steve On 4 Jun, 08:27, JF Mezei wrote: > Dirk Munk wrote: > > Porting OpenVMS to any other CPU would send out the message that HP no > > longer believes in the future of IA64. > > If the commitment to IA64 is truly there, then the world would react > just like it did for Sparc. Initial rumours of Sparc being abandonned, > but then people realising that there are still Sparcs being produced and > Sparcs still having an edge over 8086s. > > HP can initially position VMS on 8086 for the low to midrange, and IA64 > for the high end computing, and this would fit very well with the policy > since 2004 of relegating IA64 to only high end computing. > > If the commitment to IA64 isn't really there, then the quicker HP leaves > that sinking ship, the better. > > > That in turn means that HP-UX has > > no future, since porting HP-UX to another CPU would be far more > > difficult. > > Consider that Apple was able to move to the 8086, also a different > endianness. And consider that HP is already working on virtualising the > HP-UX hosting capabilities, so it is quite possible that an 8086 > instance of HP-UX could provide a virtualised PaRisc environment (aka > emulator) for the apps that do not yet exist natively on 8086. Apple's > Rosetta deals with endianness change in a very smart way with regards to > reading data from files etc. > > > Guess what would happen to the HP shares when it becomes > > clear that HP-UX has no future...... > > Since the move to IA64 will result in 30% drop in installed base of > enterprise customers, I say that HP has nothing to lose and everything > to gain by moving to industry standard architecture. > > Prior to June 25 2001, I would not have had that opinion. But since > then, IA64 has been nothing but a heavy boat anchor on VMS and HP-UX > because customers never like migrations, especially when 3rd party > software isn't going to make it to the new platform. > > > IA64. If you want to look for a way out, you have to look for a way out > > for HP-UX. With some luck, HP will allow OpenVMS to use the same way > > out. Sad but true I'm afraid. > > HP-UX may morph into Linux with HP then selling support and > middleware/SIP such as system management tools, their pale attempt at > clustering, virtualised environments etc). VMS (and NSK) will remain > with their unique capabilities. ------------------------------ Date: Mon, 4 Jun 2007 11:10:53 +0000 (UTC) From: david20@alpha2.mdx.ac.uk Subject: Re: HP wasting millions of dollars on itanium! Message-ID: In article , Dirk Munk writes: >JF Mezei wrote: >> Arne Vajhøj wrote: >> >>> I just doubt that HP or the ISV's are that interested in porting. >> >> >> If VMS were to be ported to the 8086 architecture, it would send a very >> strong signal that HP is serious about growing VMS. It would also put >> VMS on a platform whose future is not in question. It would be on an >> equal footing with Linux, Solaris and Windows as well as many other >> operating systems. >> >> Like it or not, IA64 has been plagued by rumours of its demise even >> before Merced first booted Windows which is one reason the announcement >> of porting VMS to IA64 was so poorly received. >> >> For all its technical weaknesses, the 8086 has market share and an >> assured future. >> >> The saying used to be: Nobody has ever been fired for choosing IBM >> >> The saying is now: Nobody will be fired for porting to the 64 bit 8086 >> architecture. >> >> >> And right now, HP's refusal to port VMS to a viable platform is also >> interpreted as HP abandonning VMS and allowing key ISVs like Cerner to >> drop ou of VMS. >> >> HP has no duty to help Intel's financials. HP has a duty to its own >> shareholders and its own customers. Don,t force customers to a platform >> they don,t want just because you want to please Intel's CEO. > >No doubt OpenVMS could be ported to a number of CPU architectures. > >The point is that HP is building big iron for HP-UX based on IA64. >OpenVMS is graciously allowed to run on the same iron. HP will never >design enterprise servers based on another CPU just for OpenVMS. > >Porting OpenVMS to any other CPU would send out the message that HP no >longer believes in the future of IA64. That in turn means that HP-UX has >no future, since porting HP-UX to another CPU would be far more >difficult. Guess what would happen to the HP shares when it becomes >clear that HP-UX has no future...... > Isn't that already clear ? David Webb Security team leader CCSS Middlesex University >We all agree that HP has maneuvered itself in a cul de sac with the >IA64. If you want to look for a way out, you have to look for a way out >for HP-UX. With some luck, HP will allow OpenVMS to use the same way >out. Sad but true I'm afraid. > ------------------------------ Date: Mon, 4 Jun 2007 11:37:15 -0400 From: "Main, Kerry" Subject: RE: HP wasting millions of dollars on itanium! Message-ID: > -----Original Message----- > From: etmsreec@yahoo.co.uk [mailto:etmsreec@yahoo.co.uk] > Sent: June 4, 2007 7:00 AM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: HP wasting millions of dollars on itanium! >=20 > JF, >=20 > You complain that nobody's porting to IA64 because nobody believes in > it. Porting to ANOTHER different platform is likely to drop even more > applications and, therefore, solutions along the way. >=20 > Whether you call it (incorrectly) 8086 or x86 or x86-64, it isn't > going to make it any more attractive to the companies that write the > applications that customers want to run. >=20 > There's a fundamental issue here that people miss: > When VAX was launched, the whole solution came from Digital - the > hardware, the OS and all the applications that ran on them. > Applications got lost (dropped) on the port to Alpha. More have been > lost since, so the portfolio of both hird party applications and (now) > HP supplied applications is much smaller. Moving to IA64 is claimed > to have been responsible for losing more so moving to x86-64 is likely > to mean that even more of the few remaining get lost. >=20 > In other words, you might have a fine operating system on x86-64, but > you'll have next to no applications to run on it. Whether the cost of > the hardware is nil or not. >=20 > Customers don't want to run VMS because it's VMS. Customers want to > have the features that the applications and environment provide, > whether that be high availability, high reliability or just that their > application is only available on there. >=20 > Just think of IA64 as the new Alpha. >=20 > Steve >=20 While discussion of which HW platform is the best always make for great newsgroup discussions, lets not forget the realities of what the real world is facing: - there is a huge, huge glut of available CPU cycles in almost all med to large Cust environments. Hence, discussions with CIO's on newer and faster boxes which will further increase this glut are not likely going to meet with much enthusiasm. Number one target (by far - likely in 70% range) for server consolidation initiatives is Wintel x86 environments. - If one breaks down the importance of the various layers to Cust's, it would likely be something like this: App's (65%), OS (25%), HW (10%). The App's often take advantage of the OS's functionality and features. Lets face it, yes, the HW is important, but not as much as the App's or the OS.=20 - remember all the hot benchmarking discussions from 3-4 years ago? Guess what - most of these servers are now running between 10-25% busy in peak times. Yes, there are some environments that are performance sensitive, but these are in the minority. So, did it really matter whether server was 10-20% faster than the other? [see previous point on layers importance breakdown] Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20 OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: Mon, 04 Jun 2007 12:04:14 -0400 From: "Richard B. Gilbert" Subject: Re: HP wasting millions of dollars on itanium! Message-ID: <466437FE.7030202@comcast.net> Main, Kerry wrote: >>-----Original Message----- >>From: etmsreec@yahoo.co.uk [mailto:etmsreec@yahoo.co.uk] >>Sent: June 4, 2007 7:00 AM >>To: Info-VAX@Mvb.Saic.Com >>Subject: Re: HP wasting millions of dollars on itanium! >> >>JF, >> >>You complain that nobody's porting to IA64 because nobody believes in >>it. Porting to ANOTHER different platform is likely to drop even more >>applications and, therefore, solutions along the way. > - remember all the hot benchmarking discussions from 3-4 years ago? > Guess what - most of these servers are now running between 10-25% busy > in peak times. Yes, there are some environments that are performance > sensitive, but these are in the minority. So, did it really matter > whether server was 10-20% faster than the other? [see previous point on > layers importance breakdown] > If your servers are 25% loaded, you are in fat city! OTOH, if your servers are running at 90% load and you have to hire a couple of thugs to kill people who start ad hoc queries. . . . Been there, done that. Upgrading a pair of 4100s loaded at 80-90% to a pair of ES40s running at 30% was a massive relief! They said they wanted machines to last three years; the ES40s were still running five years later. ------------------------------ Date: Mon, 04 Jun 2007 13:45:11 -0400 From: Bill Todd Subject: Re: HP wasting millions of dollars on itanium! Message-ID: Ron Johnson wrote: > On 06/03/07 00:43, Bill Todd wrote: >> Ron Johnson wrote: > [snip] >>> >>> How is this better/different than AMD's Direct Connect Architecture >>> and HORUS Interconnect? >> >> 1. AMD's on-chip memory controller does not IIRC support as much >> memory per chip, > > They *could* but there's no need yet in their target market. I think you'll find that the amount of RAM that an Opteron can support is limited by the number of chips its drivers can drive, not by something more easily modified. IIRC the reason that EV7 can support as much as it does it the ability of RDRAM to be chained without adding to the load on the processor drivers (and, for that matter, its ability to run a given amount of RAM from a significantly smaller number of pins, allowing EV7 to support IIRC 5 separate banks of RAM vs. Opteron's two banks - though it's been a while and I may have garbled some of the terminology). > >> as much memory bandwidth per chip (though I'd have to check >> to see where their recent migration to DDR-2 changed this), or >> (mirrored or parity) redundant memory. > > No parity RAM? I think that's wrong. No, you just read it wrong: I said no *redundant* (mirrored or parity) RAM (i.e., RAM with sufficient redundancy to recover from arbitrarily large errors), as distinct from lacking *parity checks on data validity* (without sufficient redundancy to recover from errors). One of the knocks against early > x86-64 chips was that they *needed* parity RAM, which slowed adoption in > the home & small-office markets. That doesn't sound right: IIRC Opteron supported ECC RAM from Day 1 (and Opteron came out before the more consumer-oriented Athlon64). But Intel's copycat x86-64 chips may have come out first in consumer versions, so it's possible that *they* didn't support ECC RAM for some period. - bill ------------------------------ Date: Mon, 04 Jun 2007 06:13:55 -0700 From: etmsreec@yahoo.co.uk Subject: Re: Paging and process state Message-ID: <1180962835.806237.296700@n4g2000hsb.googlegroups.com> On 2 Jun, 19:46, JF Mezei wrote: > IanMiller wrote: > > by looking at the process you may be altering its state. > > Shirley the VMS engineers had been able to overcome the Eisenburg > principle when they designed VMS ? > > What good is the SHOW PROC/CONT's "State" if the mere act of looking at > its state changes it ? Do you mean Heisenburg? ------------------------------ Date: Mon, 04 Jun 2007 10:39:18 -0400 From: "Richard B. Gilbert" Subject: Re: Paging and process state Message-ID: <46642416.1040309@comcast.net> etmsreec@yahoo.co.uk wrote: > On 2 Jun, 19:46, JF Mezei wrote: > >>IanMiller wrote: >> >>>by looking at the process you may be altering its state. >> >>Shirley the VMS engineers had been able to overcome the Eisenburg >>principle when they designed VMS ? >> >>What good is the SHOW PROC/CONT's "State" if the mere act of looking at >>its state changes it ? > > > Do you mean Heisenburg? > Obviously you never met Shirley Eisenberg! ;-) ------------------------------ Date: 4 Jun 2007 11:04:28 -0500 From: briggs@encompasserve.org Subject: Re: Paging and process state Message-ID: In article <6e206$46612b0a$cef8887a$14680@TEKSAVVY.COM>, JF Mezei writes: > Mozilla got sluggish (really sluggish). > > So I do a SHOW PROC MOZILLA/CONT and then type Q to see its quotas. > > The huge PGFLQUO is down to 0% (due to Mozilla's multiple memory leaks). > > However when I try to do stuff in Mozilla, the process state in the SHOW > PROC/CONT seems to be more in HIB and sometimes COM while the Mozilla > window is huffing and puffing and taking forever to do anything. I can > see the pagefile drive light being a steady green indicating lots of > page file acces happening. (we are talking many seconds of wait for > Mozilla to load a new NNTP text message for instance). > > Shouldn't the process state be in PFW or some other nasty state while > the process is busy reading and writing pages from the page file ? A process that has run out of page file quota will throw errors when asked to expand process memory. It won't be page faulting as a result of running out of quota. A process that is accessing a page and waiting on a disk read I/O to fetch the page contents from disk and thereby make it valid will go into PFW. A process that is accessing a page and waiting on a disk write I/O to take a page off the modified page list because the free list is empty will go into RWMPB (Resource Wait, Modified Pagewriter Busy). RWMPB is a classic symptom of a system that has gone into a "page file hang" when the page files aren't big enough. Note well, RWMPB kicks in when you run out of page file system wide. NOT when you run out of PGFLQUOTA in a single process. Processes don't write pages to backing store themselves. They just discard dirty pages to the modified page list and wait for the modified page writer to flush them to disk. [Though $UPDSECW can put you into LEF if you want to do your modified page writing more explicitly] A process that is trying to access a page but has been victimized by the swapper will go into COMO. So the answer is "yes". If a process is waiting on paging I/O, it should be in some "nasty" state. It won't be HIB and it certainly won't be COM. > If Mozilla was being slowed by a bogged down DECW$SERVER process, > wouldn't its state be in LEF while it is waiting for X commands to be > acknowledged by the server ? My internals background predates kernel threads, so take at least some of the following with a grain of salt. In a single-threaded application it's fine to wait for I/O in LEF state. You can afford to stall the entire process waiting on an I/O. But in a multi-threaded application you may have half a dozen threads waiting on half a dozen I/O operations that may or may not be associated with half a dozen event flags. You can't afford to put the whole process into an LEF state waiting on a particular event flag from a particular I/O operation from a particular thread. One design approach for this is to use the completion AST on each I/O operation to signal when the operation has finished. When a thread needs to do I/O, it queues the operation, specifies a completion AST and returns control to the thread scheduler so that another thread can be selected for execution. [The programmer probably just invokes a routine from the thread library to do this]. If the thread scheduler has no other threads that are eligible for execution, it will call HIBER() and put the main process to sleep. When the I/O completes and the completion AST fires, that AST will call $WAKE(,) to awaken the main process. After the AST is complete, control returns to the thread scheduler which selects the thread which has become eligible to run and starts running it. The effect of this is that you'll see the main process in HIB state whenever all of its threads are waiting on I/O. And you'll see it in COM (or COMO) state whenever at least one of its threads is eligible to execute. You'll also see it in COM (or COMO) when completion AST's are running or when the thread scheduler is trying to figure out what to do next. You won't see it in COM state just because you're busy watching it with $ SHOW PROC /CONT. ------------------------------ Date: Mon, 4 Jun 2007 17:19:26 +0000 (UTC) From: moroney@world.std.spaamtrap.com (Michael Moroney) Subject: Re: Paging and process state Message-ID: briggs@encompasserve.org writes: >A process that is trying to access a page but has been victimized by the >swapper will go into COMO. COMO means a process wants to execute, but has been swapped out by the swapper. >You won't see it in COM state just because you're busy watching it >with $ SHOW PROC /CONT. $GETJPI (which lies underneath SHOW PROC /CONT, as well as $ SHOW SYSTEM) has to execute in the mode of the target process to get certain info. Doing this means the process will be inswapped if swapped out, hence the "Heisenberg" references earlier. $GETJPI can also specify not to do an inswap and therefore not get the info as an option. This is why a $ SHOW SYSTEM shows "-- swapped out --" for an outswapped process rather than show its CPU time and other things. ------------------------------ Date: Mon, 4 Jun 2007 09:34:39 -0400 From: "Richard Whalen" Subject: Re: SYSMAN problem Message-ID: "Keith Parris" wrote in message news:f3phi8$slb$1@usenet01.boi.hp.com... : > > In bridged networks, nodes discover each other and services are advertised > by periodic transmission of multicast packets. Nodes interested in these > multicasts tell their LAN adapters to listen for those specific multicast > addresses. (IP, for reasons I can't fathom, uses the Broadcast-to-All > address on Ethernet, instead of a private Multicast address as used by VMS > clusters, LAT, DECnet, etc., thus forcing all stations to receive its > packets whether they wanted them or not!) > : This changes with IPv6. The adapter now listens to a multicast address that is determined by the adapter's address. This allows other nodes to determine the address to send the multicast to and limits the number of systems that must process the message to those that are potentially interested in it. ------------------------------ Date: Mon, 04 Jun 2007 09:07:37 -0700 From: davidc@montagar.com Subject: Re: Whom administers openvmshobbyist.org forums? Message-ID: <1180973257.837064.78340@n4g2000hsb.googlegroups.com> On Jun 3, 4:06 am, Dan Foster wrote: > I am in need of contacting a forum administrator for openvmshobbyist.org > to resolve a minor technical issue, but there is no contact information > listed anywhere on the forums, nor even a name, other than the > omnipotent 'Board Administrator'. :-) > > If someone knows whom administers that site, please contact me privately > or post here -- doesn't matter. > > Thanks! > > -Dan The person you would be looking for would be me. But it's good to hear your problem is resolved. Just a note, though, I've modified the forum software to require javascript to Register for the board. This confuses the spamming bots enough to virtually eliminate clutter. Once you're registered, you can resume your normal javascript-free experience. ------------------------------ End of INFO-VAX 2007.304 ************************