INFO-VAX Mon, 13 Aug 2007 Volume 2007 : Issue 442 Contents: Re: Alpha/Integrity Dead Pool Re: Alpha/Integrity versions of VMS. Backup save set compression Re: Backup save set compression Re: decnet startup failing DECServer wiring Re: DECServer wiring Re: DECServer wiring Re: DECServer wiring Re: DECServer wiring Free to good home. Microvaxes, Vaxstations, Alphas Re: Hobbyist licenses - is the server down? Re: Integrity Workstations? Re: Is this Address really Illegal? Re: Oldest Alpha for upgrade to Integrity Re: TCP/IP Source files and or BGDRIVER help Re: TCP/IP Source files and or BGDRIVER help Re: TCP/IP Source files and or BGDRIVER help Re: TPU on MAC OS-X ? Re: TPU on MAC OS-X ? Re: TPU on MAC OS-X ? Re: TPU on MAC OS-X ? Re: TPU on MAC OS-X ? RE: Wonderful things happen to an OS when it has an internal champion Re: Wonderful things happen to an OS when it has an internal champion Re: Wonderful things happen to an OS when it has an internal champion Re: Wonderful things happen to an OS when it has an internal champion Re: Wonderful things happen to an OS when it has an internal champion Re: Wonderful things happen to an OS when it has an internal champion Re: Wonderful things happen to an OS when it has an internal champion Re: Wonderful things happen to an OS when it has an internal champion Re: Wonderful things happen to an OS when it has an internal champion Re: X Window Servers ---------------------------------------------------------------------- Date: Mon, 13 Aug 2007 10:44:04 -0400 From: "FredK" Subject: Re: Alpha/Integrity Dead Pool Message-ID: "JF Mezei" wrote in message news:6b1e6$46bde1e8$cef8887a$8043@TEKSAVVY.COM... > Stephen Hoffman wrote: I love JF's twisted logic. Don't buy Integrity servers. Wait for a couple years to see if someone else bought Integrity servers. Of course, if everyone were to take the same path - we will get JF's wish. Fortunately, lots of people are buying them. Intel and HP have committed to Itanium long term. HP-UX, VMS and NSK are committed to Itanium. MS and Windows are committed to it. We have a strong Linux program for Integrity. ------------------------------ Date: Mon, 13 Aug 2007 16:59:38 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: Alpha/Integrity versions of VMS. Message-ID: In article <0Ae4IDmkJFDu@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > The only "last" that I can see is the possibility that 7.3 might be > the last for VAX, but I have good reason to doubt that. Can you elaborate? If there is to be a VMS for VAX after 7.3, do you have any idea what version of TCPIP will be available for it? ------------------------------ Date: Mon, 13 Aug 2007 11:13:35 -0400 From: "Scott Greig" Subject: Backup save set compression Message-ID: Hello all: The Alpha 8.3 patch site lists a new Backup patch (VMS83A_BACKUP-V0300) that describes a fix for a problem concerning the use of the /Journal switch and the /Data_Format=Compressed switch. The /Data_Format switch???!!!??? So, I tried it out - and achieved a 67% compression rate for the output save set (138087 blocks with compression, 412461 blocks without.) HELP BACKUP does not mention this switch. My question - when was this implemented, and how reliable is the output save set? Cheers, Scott ------------------------------ Date: Mon, 13 Aug 2007 08:37:07 -0700 From: IanMiller Subject: Re: Backup save set compression Message-ID: <1187019427.414101.51830@g4g2000hsf.googlegroups.com> This was part of V8.3. the compression is performed using a port of ZLIB Reliability? Ask the person who implemented it who has been known to post here. ------------------------------ Date: Mon, 13 Aug 2007 14:36:24 +0200 From: "Ferry Bolhar" Subject: Re: decnet startup failing Message-ID: <1187008585.718347@proxy.dienste.wien.at> "Peter 'EPLAN' LANGSTOeGER" > And DECnet Phase5 aka DECnet-OSI aka DECnet-Plus has also no problem > starting after TCPIP Unless when running with phase-IV-compatible addresses enabled. Greetings, Ferry -- > -- > Peter "EPLAN" LANGSTOEGER > Network and OpenVMS system specialist > E-mail peter@langstoeger.at > A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ------------------------------ Date: Mon, 13 Aug 2007 08:42:39 -0700 From: "Tom Linden" Subject: DECServer wiring Message-ID: Planning to use a DECserver to connect the consoles on a mixed cluster, to which end I will need cable that go from MMJ to DB9. Maybe just best to use MMJ-MMJ cables and DB9 adapters? Now from the FAQ In making up an MMJ-DB9 cable, do you know how the two remaining pins Are wired? I assume they are CTS and RTS. ________________________________________________________________ Table 14-5 DEC MMJ Pin-out Pin_____Description____________________________________ 1 Data Terminal Ready (DTR) 2 Transmit (TXD) 3 Transmit Ground (TXD-) 4 Receive Ground (RXD-) 5 Receive (RXD) _________6_______Data_Set_Ready_(DSR)___________________________ +------------------+ | 1 2 3 4 5 6 | +------------+ ++ +____+ ** is this the orientation as seen FROM THE RECEPTACLE, i.e., looking at the end of the cable? The BC16E-nn (where the "-nn" indicates the cable length) cabling and keying "flips over" or "crosses- over" the signal wires, and this allows all DECconnect MMJ connections to be wired identically; the ends of the BC16E are symmetrical and fully interchangeable, and allows either end of the cable to be connected either to the terminal or to the host. Specifically, the BC16E-nn cross-over wiring looks like this: Terminal Host Host MMJ MMJ DB9 DTR 1 --->---------->----------->--- 6 DSR -------------> 6 TXD 2 --->---------->----------->--- 5 RXD -------------> 2 3 ------------------------------ 4 4 ------------------------------ 3 RXD 5 ---<----------<-----------<--- 2 TXD <------------- 3 DSR 6 ---<----------<-----------<--- 1 DTR <------------- 4 Table 14-6 PC DB9 Pin-out Pin_____Description____________________________________ 1 Data Carrier Detect (DCD) 2 Received Data 3 Transmit Data 4 Data Terminal Ready (DTR) 5 Ground 6 Data Set Ready (DSR) 7 Request To Send (RTS) 8 Clear To Send _________9_______floating_______________________________________ -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Mon, 13 Aug 2007 12:07:33 -0400 From: "David Turner, Island Computers" Subject: Re: DECServer wiring Message-ID: <13c10e6sbe96407@news.supernews.com> Use the H8571J In stock for $11 each DT "Tom Linden" wrote in message news:op.twz8ldu4hv4qyg@murphus.linden... > Planning to use a DECserver to connect the consoles on a mixed cluster, to > which end I will need cable that go from MMJ to DB9. Maybe just best to > use MMJ-MMJ cables and DB9 adapters? > > Now from the FAQ > > In making up an MMJ-DB9 cable, do you know how the two remaining pins Are > wired? I assume they are CTS and RTS. > ________________________________________________________________ > Table 14-5 DEC MMJ Pin-out > > Pin_____Description____________________________________ > > 1 Data Terminal Ready (DTR) > 2 Transmit (TXD) > 3 Transmit Ground (TXD-) > 4 Receive Ground (RXD-) > 5 Receive (RXD) > _________6_______Data_Set_Ready_(DSR)___________________________ > > +------------------+ > | 1 2 3 4 5 6 | > +------------+ ++ > +____+ > > ** is this the orientation as seen FROM THE RECEPTACLE, i.e., looking at > the end of the cable? > > The BC16E-nn (where the "-nn" indicates the cable > length) cabling and keying "flips over" or "crosses- > over" the signal wires, and this allows all DECconnect > MMJ connections to be wired identically; the ends of > the BC16E are symmetrical and fully interchangeable, > and allows either end of the cable to be connected > either to the terminal or to the host. Specifically, > the BC16E-nn cross-over wiring looks like this: > > > Terminal Host Host > MMJ MMJ DB9 > > DTR 1 --->---------->----------->--- 6 DSR -------------> 6 > TXD 2 --->---------->----------->--- 5 RXD -------------> 2 > 3 ------------------------------ 4 > 4 ------------------------------ 3 > RXD 5 ---<----------<-----------<--- 2 TXD <------------- 3 > DSR 6 ---<----------<-----------<--- 1 DTR <------------- 4 > > > Table 14-6 PC DB9 Pin-out > > Pin_____Description____________________________________ > > 1 Data Carrier Detect (DCD) > 2 Received Data > 3 Transmit Data > 4 Data Terminal Ready (DTR) > 5 Ground > 6 Data Set Ready (DSR) > 7 Request To Send (RTS) > 8 Clear To Send > _________9_______floating_______________________________________ > > > > -- > PL/I for OpenVMS > www.kednos.com ------------------------------ Date: Mon, 13 Aug 2007 12:09:00 -0400 From: "David Turner, Island Computers" Subject: Re: DECServer wiring Message-ID: <13c10gud151n538@news.supernews.com> Oh And $2 per meter for the BC16E cables -- David B Turner Island Computers US Corp 2700 Gregory St, Suite 180 Savannah GA 31404 T: 877-6364332 x201 Intl: 001 912 447 6622 E: dturner@islandco.com F: 912 201 0402 W: http://www.islandco.com "Tom Linden" wrote in message news:op.twz8ldu4hv4qyg@murphus.linden... > Planning to use a DECserver to connect the consoles on a mixed cluster, to > which end I will need cable that go from MMJ to DB9. Maybe just best to > use MMJ-MMJ cables and DB9 adapters? > > Now from the FAQ > > In making up an MMJ-DB9 cable, do you know how the two remaining pins Are > wired? I assume they are CTS and RTS. > ________________________________________________________________ > Table 14-5 DEC MMJ Pin-out > > Pin_____Description____________________________________ > > 1 Data Terminal Ready (DTR) > 2 Transmit (TXD) > 3 Transmit Ground (TXD-) > 4 Receive Ground (RXD-) > 5 Receive (RXD) > _________6_______Data_Set_Ready_(DSR)___________________________ > > +------------------+ > | 1 2 3 4 5 6 | > +------------+ ++ > +____+ > > ** is this the orientation as seen FROM THE RECEPTACLE, i.e., looking at > the end of the cable? > > The BC16E-nn (where the "-nn" indicates the cable > length) cabling and keying "flips over" or "crosses- > over" the signal wires, and this allows all DECconnect > MMJ connections to be wired identically; the ends of > the BC16E are symmetrical and fully interchangeable, > and allows either end of the cable to be connected > either to the terminal or to the host. Specifically, > the BC16E-nn cross-over wiring looks like this: > > > Terminal Host Host > MMJ MMJ DB9 > > DTR 1 --->---------->----------->--- 6 DSR -------------> 6 > TXD 2 --->---------->----------->--- 5 RXD -------------> 2 > 3 ------------------------------ 4 > 4 ------------------------------ 3 > RXD 5 ---<----------<-----------<--- 2 TXD <------------- 3 > DSR 6 ---<----------<-----------<--- 1 DTR <------------- 4 > > > Table 14-6 PC DB9 Pin-out > > Pin_____Description____________________________________ > > 1 Data Carrier Detect (DCD) > 2 Received Data > 3 Transmit Data > 4 Data Terminal Ready (DTR) > 5 Ground > 6 Data Set Ready (DSR) > 7 Request To Send (RTS) > 8 Clear To Send > _________9_______floating_______________________________________ > > > > -- > PL/I for OpenVMS > www.kednos.com ------------------------------ Date: Mon, 13 Aug 2007 12:11:08 -0400 From: "Richard B. Gilbert" Subject: Re: DECServer wiring Message-ID: <46C0829C.9030808@comcast.net> Tom Linden wrote: > Planning to use a DECserver to connect the consoles on a mixed cluster, > to which end I will need cable that go from MMJ to DB9. Maybe just best > to use MMJ-MMJ cables and DB9 adapters? > > Now from the FAQ > > In making up an MMJ-DB9 cable, do you know how the two remaining pins > Are wired? I assume they are CTS and RTS. > ________________________________________________________________ > Table 14-5 DEC MMJ Pin-out > > Pin_____Description____________________________________ > > 1 Data Terminal Ready (DTR) > 2 Transmit (TXD) > 3 Transmit Ground (TXD-) > 4 Receive Ground (RXD-) > 5 Receive (RXD) > _________6_______Data_Set_Ready_(DSR)___________________________ > > +------------------+ > | 1 2 3 4 5 6 | > +------------+ ++ > +____+ > > ** is this the orientation as seen FROM THE RECEPTACLE, i.e., looking > at the end of the cable? > > The BC16E-nn (where the "-nn" indicates the cable > length) cabling and keying "flips over" or "crosses- > over" the signal wires, and this allows all DECconnect > MMJ connections to be wired identically; the ends of > the BC16E are symmetrical and fully interchangeable, > and allows either end of the cable to be connected > either to the terminal or to the host. Specifically, > the BC16E-nn cross-over wiring looks like this: > > > Terminal Host Host > MMJ MMJ DB9 > > DTR 1 --->---------->----------->--- 6 DSR -------------> 6 > TXD 2 --->---------->----------->--- 5 RXD -------------> 2 > 3 ------------------------------ 4 > 4 ------------------------------ 3 > RXD 5 ---<----------<-----------<--- 2 TXD <------------- 3 > DSR 6 ---<----------<-----------<--- 1 DTR <------------- 4 > > > Table 14-6 PC DB9 Pin-out > > Pin_____Description____________________________________ > > 1 Data Carrier Detect (DCD) > 2 Received Data > 3 Transmit Data > 4 Data Terminal Ready (DTR) > 5 Ground > 6 Data Set Ready (DSR) > 7 Request To Send (RTS) > 8 Clear To Send > _________9_______floating_______________________________________ > > > Definitely best to use the DB-9 <--> MMJ adapters, but first you have to find the right adapter. There are at least two ways of wiring a DB-9; one for PC's (and Alphas??) and another for VAXen. ------------------------------ Date: Mon, 13 Aug 2007 09:46:58 -0700 From: etmsreec@yahoo.co.uk Subject: Re: DECServer wiring Message-ID: <1187023618.923415.252280@19g2000hsx.googlegroups.com> Tom Linden wrote: > Planning to use a DECserver to connect the consoles on a mixed cluster, to > which end I will need cable that go from MMJ to DB9. Maybe just best to > use MMJ-MMJ cables and DB9 adapters? > > Now from the FAQ > > In making up an MMJ-DB9 cable, do you know how the two remaining pins Are > wired? I assume they are CTS and RTS. > ________________________________________________________________ > Table 14-5 DEC MMJ Pin-out > > Pin_____Description____________________________________ > > 1 Data Terminal Ready (DTR) > 2 Transmit (TXD) > 3 Transmit Ground (TXD-) > 4 Receive Ground (RXD-) > 5 Receive (RXD) > _________6_______Data_Set_Ready_(DSR)___________________________ > > +------------------+ > | 1 2 3 4 5 6 | > +------------+ ++ > +____+ > > ** is this the orientation as seen FROM THE RECEPTACLE, i.e., looking at > the end of the cable? > It's probably a stupid question, but... Does it matter whether it's from the receptacle or the cable if you get pin 6 nearest to the tab? ------------------------------ Date: Mon, 13 Aug 2007 09:46:38 +0100 From: Elliott Roper Subject: Free to good home. Microvaxes, Vaxstations, Alphas Message-ID: <130820070946381392%nospam@yrl.co.uk> I have a pile of old kit waiting to go to the tip. Phillip Helbig, as he grabbed the best stuff, convinced me I should mention what's left in case anyone wants it. Microvaxes: 1 x 3100 90 4 x 3100 80 1 x 3100 10 (might be a 20) Vaxstations 5 x 4000 60 5 x 4000 VLC 1 x 3100 76 1 x 3100 38 SPX Alphastations 1 x Jensen 3 x 200 4/100 (1 has NT boot ROM. It is probably busted) 1 x 3000 (in poor state) Other stuff 2 x Decserver 200 MC 7 x VRT17-HA 2 x VRT16-HA 2 x VRC16-HA 5 x VT420 3 x VT320 1 x VT520 (most of the VTs are green, some amber) 1 x Storage expansion BA42A SZ12 various monitor and SCSI cables, power cables All of the machines had enough memory to run VMS with Motif and DECnet. Some had more. But not a lot. It used to be expensive stuff remember? First come first served. Take as much or as little as you like. It is at my house in Hayfield, which is about 15 miles SE of Manchester. UK I need the space by 8-Sep-2007. The dregs will be dumped before then. Just about all of it was working when it was switched off. It has since been stored in a Portakabin inside my barn. Not too damp. I have removed all the disks from all the machines. Some of them, I can't remember which, had sort-of sensitive customer data. Sorry. -- To de-mung my e-mail address:- fsnospam$elliott$$ PGP Fingerprint: 1A96 3CF7 637F 896B C810 E199 7E5C A9E4 8E59 E248 ------------------------------ Date: Sun, 12 Aug 2007 23:34:45 -0700 From: etmsreec@yahoo.co.uk Subject: Re: Hobbyist licenses - is the server down? Message-ID: <1186986885.099297.271850@l70g2000hse.googlegroups.com> On 13 Aug, 03:20, David J Dachtera wrote: > etmsr...@yahoo.co.uk wrote: > > > Hiya, > > > I've just tried getting some new license paks from the hobbyist site > > but, although it takes all my details and apparently validates them, > > no licenses have appeared in my email. > > > Anyone got any ideas whether they are having problems? > > > Licenses were for a VAXstation, an AlphaServer and the layered > > products. > > Any clues from your ISP's spam filters? > > -- > David J Dachtera > dba DJE Systemshttp://www.djesys.com/ > > Unofficial OpenVMS Marketing Home Pagehttp://www.djesys.com/vms/market/ > > Unofficial Affordable OpenVMS Home Page:http://www.djesys.com/vms/soho/ > > Unofficial OpenVMS-IA32 Home Page:http://www.djesys.com/vms/ia32/ > > Unofficial OpenVMS Hobbyist Support Page:http://www.djesys.com/vms/support/ If it was their spam filters I wouldn't get any notice of it, but I've not had issues with licenses being held up before. Normally they're in my inbox within minutes. :o( ------------------------------ Date: Mon, 13 Aug 2007 10:45:41 -0400 From: "FredK" Subject: Re: Integrity Workstations? Message-ID: "JF Mezei" wrote in message news:61d11$46bdea97$cef8887a$11034@TEKSAVVY.COM... > etmsreec@yahoo.co.uk wrote: >> Sound cards sound a bit pointless on VMS after all then... > > Tell that to air traffic controllers, or idustrial machines that use > sounds to communicate with the operator whose eyes are focused on the > products being produced and not on some LCD display. > Gee. VMS is used in ATC applications, and sound has never been a requirement. But you are the expert. ------------------------------ Date: 13 Aug 2007 12:16:35 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Is this Address really Illegal? Message-ID: <5ib0d3F3ofu86U1@mid.individual.net> In article <015801c7dd35$a8932810$2802a8c0@charonlap>, "Peter Weaver" writes: >>... >> depends on how it is implemented. In any event, being as the domain ends >> in ".cn" complaining is a waste of time and in many cases, for me, has >> resulted in an increase in the number of attacks from that block rather >> than a decrease. Nowadays, depending on where and what the attacking >> block is, I may block them at my firewall, but I never complain as it >> is totally ineffective and can easily result in bigger problems. >>... > > Bill, I always complain when someone attacks my system because if you ingore > the problem then you are part of the problem. Twenty years ago I would have agreed with you. But today, all you really do is let them know they found a real machine. > > I have never seen an increase in attacks because of a complaint, but I have > had positive feedback. I have never had a positive response. In most cases, I received not so much as an acknowledgement and, as I said, int he worst case the attacks increased, probably because they then knew they had a live one!! > Sending an abuse report only takes seconds and it > feels good when you get a reply that some Unix box was hacked into. It takes longer than seconds just to look it up and frequently they are buried so deep in holding companies it take considerably longer. And, especially in the case of Pacific Rim sites, it isn't a hacked box, (unix or VMS :-) it is a deliberate and fully supported attack. Feel free to advertise your machines to the enemy, I feel much better not acknowledging them and when necessary, blocking them completely. It's just like SPAM. It needs to be treated the same. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Mon, 13 Aug 2007 08:41:49 -0700 From: tadamsmar Subject: Re: Oldest Alpha for upgrade to Integrity Message-ID: <1187019709.710397.207640@w3g2000hsg.googlegroups.com> On Aug 10, 3:06 pm, bro...@cuebid.zko.hp.nospam (Rob Brooks) wrote: > tadamsmar writes: > > Does the AlphaStation 400, AlphaServer 800 and the DS10 support VMS > > 8.3 or some version that Integrity also supports? > > Yes > > > I was wondering if I can upgrade my older Alphas to a common version > > with Integrity. > > Is there a web page that shows what hardware will run what versions of > > VMS? > > While there have been a few VAX models that have been dropped along the way, > no Alpha hardware has been dropped from support. In this context, I'm talking > about models that were properly sold with VMS, not oddball things like the > multia, or the early EV3-based systems. I know you are wrong about this from my direct experience. The first Alpha we bought was an AXP 150 sold with VMS from DEC. I ended up surplussing it since it was dropped by 7.3.2. I think it may have been delivered with NT on it, but DEC sold us the system and the media. > > I think you are making this task seem much harder than it really is. > > -- > > Rob Brooks MSL -- Nashua brooks!cuebid.zko.hp.com ------------------------------ Date: Mon, 13 Aug 2007 18:04:54 +0800 From: "Richard Maher" Subject: Re: TCP/IP Source files and or BGDRIVER help Message-ID: Hi Jim, > If they are delivered in the order they were declared, and they are both > user mode ASTs, one is going to execute and complete before the other > always, The question is "Can one start before the other has been queued" not the bloody obvious. > That is, > if the driver maintains IPL and queues both, or drops IPL in between > queuing the first and the second, *the end result to the target process > is the same.* Bullshit! > Or am I missing something? Yes you are. Richard. "Jim Duff" wrote in message news:46bfbf4b$1@dnews.tpgi.com.au... > Richard Maher wrote: > > Hi, > > > > Is the BGDRIVER source code available as part of the VMS source listing kit? > > I don't recall ever seeing them, and believe the answer to be no, but either > > way could someone help with the following question. > > > > To set the scene, I have a server Socket with both OOB and READ attention > > ASTs declared on it and the client has just disconnected their side of the > > link. Now, those of you who may have done this know that UCX (and Multinet) > > fire both the OOB and READ attention ASTs in the order they were last > > declared in, but what I dearly'd love to know is: - > > > > After receiving the non-inlined OOB does UCX stay at raised IPL until *both* > > the READATTN AST and the OOBATTN AST have been queued? In otherwords, is AST > > delivery disabled temporarily (throught elevated IPL or other means) so that > > the first AST does not gain control, start executing, and possibly complete > > *before* the second (OOB or READ) attention AST has been queued? > > > > [snip] > > If they are delivered in the order they were declared, and they are both > user mode ASTs, one is going to execute and complete before the other > always, as ASTs at the same mode cannot interrupt each other. That is, > if the driver maintains IPL and queues both, or drops IPL in between > queuing the first and the second, the end result to the target process > is the same. Or am I missing something? > > Jim > -- > www.eight-cubed.com ------------------------------ Date: Mon, 13 Aug 2007 22:39:45 +1000 From: Jim Duff Subject: Re: TCP/IP Source files and or BGDRIVER help Message-ID: <46c05112@dnews.tpgi.com.au> Richard Maher wrote: > Hi Jim, > >> If they are delivered in the order they were declared, and they are both >> user mode ASTs, one is going to execute and complete before the other >> always, > > The question is "Can one start before the other has been queued" not the > bloody obvious. > >> That is, >> if the driver maintains IPL and queues both, or drops IPL in between >> queuing the first and the second, *the end result to the target process >> is the same.* > > Bullshit! > >> Or am I missing something? > > Yes you are. > If I'm missing something, perhaps you could try pointing out what that something is instead of going into instant rant mode and chucking invective around. Your ranting gets you high blood pressure (or perhaps not, perhaps you just enjoy it), but it sure doesn't do anything to make people want to keep helping you. I pointed out that two user mode ASTs to the same target process can't interrupt each other, no matter how the driver queues them. Unless you do something unsupported (like switch to kernel mode in the first AST to see if the second AST has been queued and then taking a different code path), I don't see how you BS comment applies. I posted to see if I could get further information from you to see if I could help. Unfortunately, I couldn't. Jim. -- www.eight-cubed.com ------------------------------ Date: Mon, 13 Aug 2007 09:01:30 -0700 From: Bob Gezelter Subject: Re: TCP/IP Source files and or BGDRIVER help Message-ID: <1187020890.089152.58620@o61g2000hsh.googlegroups.com> On Aug 12, 7:12 pm, "Richard Maher" wrote: > Hi, > > Is the BGDRIVER source code available as part of the VMS source listing kit? > I don't recall ever seeing them, and believe the answer to be no, but either > way could someone help with the following question. > > To set the scene, I have a server Socket with both OOB and READ attention > ASTs declared on it and the client has just disconnected their side of the > link. Now, those of you who may have done this know that UCX (and Multinet) > fire both the OOB and READ attention ASTs in the order they were last > declared in, but what I dearly'd love to know is: - > > After receiving the non-inlined OOB does UCX stay at raised IPL until *both* > the READATTN AST and the OOBATTN AST have been queued? In otherwords, is AST > delivery disabled temporarily (throught elevated IPL or other means) so that > the first AST does not gain control, start executing, and possibly complete > *before* the second (OOB or READ) attention AST has been queued? > > Pretty straight forward eh? I'm reasonably confident the answer is yes but > then that could imply some sort of sequential scan through the ASTs that > need to be delivered, and it could be argued that the FIFO delivery seems to > contradict this. > > Cheers Richard Maher Richard, I would recommend extreme caution. For starters, the synchronization of "raising IPL" only works on a uniprocessor, some form of interlock (e.g., spinlocks) would be needed on a multiprocessor system. While it could be done this way, I do not see why it would HAVE to be done this way. Second, I would not recommend basing code on this type of presumption. The driver may change from release to release. When I have to deal with similar situations, I use status fields in my own data structures to deal with the possibilities of events occurring in an unexpected order. Done properly, I have never had a problem. - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: Mon, 13 Aug 2007 08:59:31 +0200 From: Martin Krischik Subject: Re: TPU on MAC OS-X ? Message-ID: <46c00153$1@news.post.ch> Craig A. Berry schrieb: >> What I meant is "SPAWN /NoWait Eve /Interface=DecWindows" or "SPAWN /NoWait >> LSEdit /Interface=DecWindows". As an old time user you might consider it >> strange but for learning you way around a new Editor drop down menu are >> indeed very helpfull. > > I couldn't find this documented anywhere, but if you want black text on > a white background in the Motif version of EVE/TPU, do the following: > $ copy/log sys$library:eve.dat sys$login: > > Edit the eve.dat in your login directory and add the following two > lines: > > Tpu*foreground: black > Tpu*background: white > > Add the following line to your login.com: > > $ DEFINE TPU$DEFAULTS SYS$LOGIN:EVE.DAT > > Run your login.com or log out and log back in again. The next time you > do EDIT/DISPLAY=M, you'll see your black text on a white background. Thanks, I added it to our company internal Wiki - might be helpfull. Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com ------------------------------ Date: Mon, 13 Aug 2007 09:02:30 +0200 From: Martin Krischik Subject: Re: TPU on MAC OS-X ? Message-ID: <46c00206$1@news.post.ch> Paul Raulerson schrieb: >> If you want TPU to colorize your text, you can write the TPU code to >> do it. Yes, it can be done on color capable displays. The fact that >> no one has bothered has to do with the value of using a superior >> editor and superior programming languages that don't need such crutches. > > Occams Razor: > > Perhaps the fact nobody has "bothered" to do is because it is viewed as > primitive and people just go use another editor, or are driven to use another > platform which does support more user friendly tools. > > Or you may be right. > Most likely both - depending on when the user started to use VMS. Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com ------------------------------ Date: Mon, 13 Aug 2007 13:39:42 +0200 From: "P. Sture" Subject: Re: TPU on MAC OS-X ? Message-ID: In article <131899468.539oBBZa67@linux1.krischik.com>, Martin Krischik wrote: > P. Sture wrote: > > > In article <2721714.3M88bkd2e5@linux1.krischik.com>, > > Martin Krischik wrote: > > > >> > >> I never got Eve or LsEdit to display Black on Bright White - at least not > >> with the DecWindows interface. Both use some ugly green from the Motif > >> colour scheme. > > > > Are you using traditional DECwindows or CDE? I did manage once to get > > block on white for DECTerm sessions in CDE, though by trial and error > > using the color sliders. > > Getting DecTerm to display black in bright white is not at all difficult. It > mostly works the same way you get Xterm to display black in bright white. > Just the name for the configuration file is different (DecW$DecTerminal.dat > or so). Or you use the master configuration file DecW$XDefaults.Dat. > > What I meant is "SPAWN /NoWait Eve /Interface=DecWindows" or "SPAWN /NoWait > LSEdit /Interface=DecWindows". As an old time user you might consider it > strange but for learning you way around a new Editor drop down menu are > indeed very helpfull. Understood. It can be easy to forget what it is like for a new user. > >> Apart from that: those in our team who want the named features either use > >> Vim or Ms-Windows UltraEdit (copying the sources back and forth from > >> VMS). > > > Trust me. If you had been using either EDIT/EDT or TPU with the EDT > > keypad for as long as many of us here have, you'd be transferring > > Windows files to a VMS system to do your editing, not the other way > > around! (And yes, I have used UltraEdit on Windows, though I preferred a > > similar offering called TextPad myself.) > > I believe you. Sure for an old time user both editors must be great as they > come with a propper scripting language and after 20 years or so you must > have a few 1000 lines of TPU code to make your live easy. > It may surprise you, but I don't have lots of TPU code. I long ago decided to keep to just a few key shortcuts. I was doing a lot of troubleshooting on customer systems, so made sure I could work on vanilla installations. Incidentally, the same goes for DCL. A former colleague told me a tale of trying to work on a brand new system, and he'd forgotten how to work on VMS without his own customizations! His solution was to write an assembler program to transfer his stuff across a serial line... :-) -- Paul Sture Sue's OpenVMS bookmarks: http://eisner.encompasserve.org/~sture/ovms-bookmarks.html ------------------------------ Date: Mon, 13 Aug 2007 13:58:15 +0200 From: "P. Sture" Subject: Re: TPU on MAC OS-X ? Message-ID: In article , "Craig A. Berry" wrote: > In article <131899468.539oBBZa67@linux1.krischik.com>, > Martin Krischik wrote: > > > P. Sture wrote: > > > > > In article <2721714.3M88bkd2e5@linux1.krischik.com>, > > > Martin Krischik wrote: > > > Getting DecTerm to display black in bright white is not at all difficult. It > > mostly works the same way you get Xterm to display black in bright white. > > Just the name for the configuration file is different (DecW$DecTerminal.dat > > or so). Or you use the master configuration file DecW$XDefaults.Dat. > > Since it's a user preference, you might want to have lines like the > following in your user-specific file rather than assuming everyone > wants the same system-wide setting: > > $ search sys$login:decw$terminal_default.dat foreground,background > DECW$TERMINAL.main.terminal.background: White > DECW$TERMINAL.main.terminal.foreground: Black > > > > What I meant is "SPAWN /NoWait Eve /Interface=DecWindows" or "SPAWN /NoWait > > LSEdit /Interface=DecWindows". As an old time user you might consider it > > strange but for learning you way around a new Editor drop down menu are > > indeed very helpfull. > > I couldn't find this documented anywhere, but if you want black text on > a white background in the Motif version of EVE/TPU, do the following: > > $ copy/log sys$library:eve.dat sys$login: > > Edit the eve.dat in your login directory and add the following two > lines: > > Tpu*foreground: black > Tpu*background: white > > Add the following line to your login.com: > > $ DEFINE TPU$DEFAULTS SYS$LOGIN:EVE.DAT > > Run your login.com or log out and log back in again. The next time you > do EDIT/DISPLAY=M, you'll see your black text on a white background. > > > >> Apart from that: those in our team who want the named features either use > > >> Vim or Ms-Windows UltraEdit (copying the sources back and forth from > > >> VMS). > > You may want to look into NetBeans or Distributed NetBeans if the goal > is to edit OpenVMS files in an environment that has all the pointy, > clicky, plugin-aware. color-enabled features and that runs on OpenVMS or > other platforms or (in the case of the distributed version) OpenVMS in > conjunction with other platforms: > > http://h71000.www7.hp.com/openvms/products/ips/netbeans/ > > There is also jEdit. Not sure about Eclipse, but there are likely > other options if you go looking for them. > > > > Trust me. If you had been using either EDIT/EDT or TPU with the EDT > > > keypad for as long as many of us here have, you'd be transferring > > > Windows files to a VMS system to do your editing, not the other way > > > around! > > HP's NetBeans project has a widget they call the old-timers' plug-in -- > no wait, they actually call it the "EDT Editor Keybindings Module": > > http://h71000.www7.hp.com/openvms/products/ips/netbeans/modules.html#edt > > I've never used it, but it's supposed to work anywhere you run NetBeans > (i.e., not just on OpenVMS). Thanks for the tips Craig. Much appreciated (in spite of the reference to "old-timers" :-) ) -- Paul Sture Sue's OpenVMS bookmarks: http://eisner.encompasserve.org/~sture/ovms-bookmarks.html ------------------------------ Date: Mon, 13 Aug 2007 17:13:34 +0200 From: Martin Krischik Subject: Re: TPU on MAC OS-X ? Message-ID: <46c0751f$1@news.post.ch> P. Sture schrieb: > It may surprise you, but I don't have lots of TPU code. I long ago > decided to keep to just a few key shortcuts. I was doing a lot of > troubleshooting on customer systems, so made sure I could work on > vanilla installations. > > Incidentally, the same goes for DCL. A former colleague told me a tale > of trying to work on a brand new system, and he'd forgotten how to work > on VMS without his own customizations! His solution was to write an > assembler program to transfer his stuff across a serial line... :-) Yes you always have to balance between working faster with good customization and been able to work on a vanilla system. For me: I just created a "fast installation pack" to get me up an running on a new system in no time. Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com ------------------------------ Date: Mon, 13 Aug 2007 10:19:42 +0000 From: "Main, Kerry" Subject: RE: Wonderful things happen to an OS when it has an internal champion Message-ID: -----Original Message----- > From: Paul Raulerson [mailto:paul@raulersons.com] > Sent: August 9, 2007 12:28 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Wonderful things happen to an OS when it has an internal > champion > > > [snip] > > Even though there are some very large VMS sites out there (I'm > impressed) I'm not sure that VMS is the target of choice for VL > environments. I am willing to be convinced otherwise. :) > As a further follow-up to this reply, here is a sample quote that is availa= ble online: http://h71028.www7.hp.com/ERC/downloads/5982-9831EN.pdf "We recently ported the complete software of the Eurex Exchange, which cons= ists currently of 5 million lines of source code, to OpenVMS on HP Integrity servers. We a= re currently porting the Xetra cash market software as well. OpenVMS on Integrity server= s will enable us to introduce a new infrastructure with the same operating system in a cost-= efficient manner." - Gerd Koebschall, Director, Head of Department XETRA/EUREX Operations Deutsche B=F6rse Systems AG" [snip] Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT) OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: Mon, 13 Aug 2007 14:02:06 +0200 From: Michael Kraemer Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: JF Mezei schrieb: > My response was that to learn a new OS, you > need good documentation. As an end-user or as an admin/developer ? Do you need a grey wall of documentation to use a Mac ? > His answer means that it is fairly well known that VMS has good > documentation. Should new owners of VMS wish to market VMS, perhaps that > is one key aspect they could target since it seems to be a known force > for VMS and would definitely strike a raw nerve to those trying Linux out. If I'd want to just try something out, I would not be inclined to wade through tons of documentations first. ------------------------------ Date: Mon, 13 Aug 2007 10:39:03 -0400 From: JF Mezei Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: <3737c$46c06d09$cef8887a$30364@TEKSAVVY.COM> Michael Kraemer wrote: > Do you need a grey wall of documentation to use a Mac ? Out of the box, no. But if you want to program on a MAC, having printed documentation on the OS-X systems services would be great. And if you want to customise a mac, you need a utility which is the equivalent of regedit on windows, and you need to find out which file contains the item you need to add/change and what item to add/change. And right now, it appears that the community is the documentation as it learns little undocumented tricks on how to customize a menu for instance. Hunting for it takes time and you are never sure if it is possible or not. ------------------------------ Date: Mon, 13 Aug 2007 04:34:39 -0700 From: sapienzaf Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: <1187004879.970298.248440@q75g2000hsh.googlegroups.com> Kerry, Each of the case studies you posted are about European installations. Are there no SMB sites in the U.S. that HP can use as references? Speaking as someone that absolutely adores OpenVMS and tries to make a living from it, I can tell you that I'm having a hard time finding SMB companies that need my services. I've had numerous conversations where the IT manager says something like, "yeah, we're phasing out our OpenVMS systems". They are moving to Windows or some flavor of Unix. Whatever message you think HP is sending the SMB market is just not getting there. When I hear about a small business in Texas that is moving a home-grown VAX software solution to a home-grown Windows/ Access solution then I know the message about OpenVMS' future isn't being heard. They are in the middle of a five-year porting project and I can't help but think, "why?". Even moving to an obsolete Alpha box would have been less expensive, but instead they decided Windows was their best answer. What is HP's message to them? Since large companies (Bayer, Pfizer, JP Morgan, Deutsche, Ford, Keyspan, and on and on) don't seem interested in dealing with a one- man operation such as myself then I'm left with trying to uncover the remaining small/medium business OpenVMS sites and pitch to them. They are not easy to find. (An unrelated issue is that it appears many small companies are no longer interested in outsourcing their day-to- day software or systems administration work to a consultant/ contractor.) So, while I'm happy to see Europe doing so well and somehow getting the HP (and Oracle RDB) message it's frustrating to me that the U.S. efforts seem to have stagnated. Where are the SMB case studies on this continent? What about stories of new OpenVMS wins (not just upgrades, that is) in the SMB market? ------------------------------ Date: Mon, 13 Aug 2007 13:56:35 +0200 From: Michael Kraemer Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: Tom Linden schrieb: > I would not > have characterized 68K aqs orthogonal, It has/had one of the "most orthogonal" instruction sets out there. ------------------------------ Date: Mon, 13 Aug 2007 14:08:10 +0200 From: Michael Kraemer Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: Paul Raulerson schrieb: > > Nope - I meant more like a Vax. An ancestor of the PowerPC chip is the 680x0 > line, Nope, the PPC has nothing in common with the 68k, except Motorola being one of its parent companies. PPC inherited the bus interface from (now dead) Motorola's own 88k RISC chips, and they made sure that PPC would be able to exist in the embedded space as a successor to the 68k. > so you find the way registers are used and such more like the Vax than > > like the PC. Also, more like a mainframe, but for slightly different > reasons. PPC instruction set reminds me much more of x86 and S/370, except for the wealth of registers. 68k is more VAX-like, i.e. extremely CISCish. ------------------------------ Date: Mon, 13 Aug 2007 14:14:26 +0200 From: Michael Kraemer Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: JF Mezei schrieb: > It is just a bunch of idiots who priced VMS out of the workstation > market and then looking at statistics, decided that nobody wanted VMS > for workstations and stopped developping the very apps that could have > made VMS grow. > When you look at how efficient VMS is compared to Windows (in terms of > memory usage, process control etc), VMS would make a great workstation > OS had the owners not decided to stop developping apps on VMS. VMS lost the workstation game not against Windows, but against the RISC Unices. This was as early as 1990, when VAXstations were a lot more expensive but less powerful than their RISC counterparts. ------------------------------ Date: Mon, 13 Aug 2007 07:16:52 -0500 From: Ron Johnson Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: On 08/13/07 07:08, Michael Kraemer wrote: > Paul Raulerson schrieb: > >> >> Nope - I meant more like a Vax. An ancestor of the PowerPC chip is the >> 680x0 >> line, > > Nope, the PPC has nothing in common with the 68k, except Motorola being > one of its parent companies. PPC inherited the bus interface from > (now dead) Motorola's own 88k RISC chips, and they made sure that > PPC would be able to exist in the embedded space as a successor to the 68k. > >> so you find the way registers are used and such more like the Vax than >> >> like the PC. Also, more like a mainframe, but for slightly different >> reasons. > > PPC instruction set reminds me much more of x86 and S/370, > except for the wealth of registers. 68k is more VAX-like, i.e. > extremely CISCish. I've read that it was PDP-11-like. -- 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, 13 Aug 2007 13:49:37 -0400 From: "John Smith" Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: <5b487$46c099b2$cef882e2$11754@TEKSAVVY.COM-Free> sapienzaf wrote: > Kerry, > > Each of the case studies you posted are about European installations. > Are there no SMB sites in the U.S. that HP can use as references? > > Speaking as someone that absolutely adores OpenVMS and tries to make a > living from it, I can tell you that I'm having a hard time finding SMB > companies that need my services. I've had numerous conversations > where the IT manager says something like, "yeah, we're phasing out our > OpenVMS systems". They are moving to Windows or some flavor of Unix. > > Whatever message you think HP is sending the SMB market is just not > getting there. When I hear about a small business in Texas that is > moving a home-grown VAX software solution to a home-grown Windows/ > Access solution then I know the message about OpenVMS' future isn't > being heard. They are in the middle of a five-year porting project > and I can't help but think, "why?". Even moving to an obsolete Alpha > box would have been less expensive, but instead they decided Windows > was their best answer. What is HP's message to them? They may be motivated by the fact that there is an army of IVS's who DO write apps that run on Windows and can easily (more or less) or even transparently augment the Windows environment with user (or administrative/ops) functions that are still command line or non-existent in the VMS world courtesy of the long neglect of the ISV and cusomer base in VMS-land (no advertising / no marketing = no new customers to speak of and a declining install base). > > Since large companies (Bayer, Pfizer, JP Morgan, Deutsche, Ford, > Keyspan, and on and on) don't seem interested in dealing with a one- > man operation such as myself then I'm left with trying to uncover the > remaining small/medium business OpenVMS sites and pitch to them. They > are not easy to find. (An unrelated issue is that it appears many > small companies are no longer interested in outsourcing their day-to- > day software or systems administration work to a consultant/ > contractor.) For some of these larger organizations, you have to hookup with a larger partner who is a 'contractor of record' who can then hire you and skim off a piece of your action. > > So, while I'm happy to see Europe doing so well and somehow getting > the HP (and Oracle RDB) message it's frustrating to me that the U.S. > efforts seem to have stagnated. Where are the SMB case studies on > this continent? What about stories of new OpenVMS wins (not just > upgrades, that is) in the SMB market? Ditto. -- OpenVMS - The never-advertised operating system with the dwindling ISV base. ------------------------------ Date: Mon, 13 Aug 2007 14:43:05 +0200 From: "P. Sture" Subject: Re: X Window Servers Message-ID: In article , Kilgallen@SpamCop.net (Larry Kilgallen) wrote: > In article , "P. Sture" > writes: > > > Next time have a few CDs containing the Gettysburg Address handy? :-) > > In MacOS Keynote format. And when they call to tell you they can't read it, claim that it's perfectly readable on your system, and send exactly the same thing again. :-) If that doesn't give them a taste of their own medicine, try BACKUP/ENCRYPT? -- Paul Sture Sue's OpenVMS bookmarks: http://eisner.encompasserve.org/~sture/ovms-bookmarks.html ------------------------------ End of INFO-VAX 2007.442 ************************