INFO-VAX Thu, 06 Jan 2005 Volume 2005 : Issue 11 Contents: 'Intel Thinks OpenVMS V8.2 is Swell ' Re: A MUST READ! Re: build problem with socket lib and latest VMS Re: C File sharing issue with multiple writers Re: C File sharing issue with multiple writers Re: Comp.os.vms netiquette Re: Comp.os.vms netiquette Re: Comp.os.vms netiquette Re: Comp.os.vms netiquette Re: Comp.os.vms netiquette Re: Comp.os.vms netiquette Re: Comp.os.vms netiquette Re: Comp.os.vms netiquette Re: Comp.os.vms netiquette Re: DS10L using laptop drives. Re: DS10L using laptop drives. Re: DS10L using laptop drives. Re: DS10L using laptop drives. Re: Emulation of an Alpha server running OpenVMS Re: Emulation of an Alpha server running OpenVMS Re: Emulation of an Alpha server running OpenVMS Re: Emulation of an Alpha server running OpenVMS Re: Emulation of an Alpha server running OpenVMS Re: Emulation of an Alpha server running OpenVMS Re: Emulation of an Alpha server running OpenVMS Re: Emulation of an Alpha server running OpenVMS Re: Emulation of an Alpha server running OpenVMS Re: Emulation of an Alpha server running OpenVMS Re: Emulation of an Alpha server running OpenVMS Re: Emulation of an Alpha server running OpenVMS Re: Emulation of an Alpha server running OpenVMS Re: Emulation of an Alpha server running OpenVMS Re: Emulation of an Alpha server running OpenVMS Re: Emulation of an Alpha server running OpenVMS Re: Emulation of an Alpha server running OpenVMS Re: Has anyone heard if any of our customers have been hurt by the tidal wave in Re: Help - SYSUAF and $SETUAI on UAI$_USER_DATA field Re: Help - SYSUAF and $SETUAI on UAI$_USER_DATA field Re: Help - SYSUAF and $SETUAI on UAI$_USER_DATA field Re: How to get Tape Tools to recognize terminfo database? HPLJ tray selection problem from OVMS V7.3-1 IA64 news (january 18th) Interesting article about RDB Re: More on Tru64 Re: More on Tru64 Re: need help in decoding VAXstation 4000/60 console error message Re: need help in decoding VAXstation 4000/60 console error message Re: Need help with user-written routine in SOR$ Re: TCP/IP mailing problem Re: TCP/IP mailing problem Re: TCP/IP mailing problem Re: Writing drivers for USB devices ?, was: Re: What's the state of USB Re: Writing drivers for USB devices ?, was: Re: What's the state of USB Re: Writing drivers for USB devices ?, was: Re: What's the state of USB 2. WRUG Meeting - January 18, 2005 ---------------------------------------------------------------------- Date: 5 Jan 2005 12:28:10 -0800 From: "mas" Subject: 'Intel Thinks OpenVMS V8.2 is Swell ' Message-ID: <1104956890.743561.90540@f14g2000cwb.googlegroups.com> http://www.shannonknowshpc.com/stories.php?story=05/01/04/6450070 http://www.investorshub.com/boards/read_msg.asp?message_id=5012753 ------------------------------ Date: 5 Jan 2005 13:48:32 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: A MUST READ! Message-ID: <88UsYG1x7CtU@eisner.encompasserve.org> And for those who did not check the headers, the relevant one was present: > X-Complaints-To: groups-abuse@google.com Please don't just get annoyed about off-topic posts - Complain ! ------------------------------ Date: Wed, 05 Jan 2005 22:15:47 GMT From: hoff@hp.nospam (Hoff Hoffman) Subject: Re: build problem with socket lib and latest VMS Message-ID: In article <00A3D6A8.1790BD61@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG writes: :I don't see why these other modules should be called out with error. This looks to be a problem within the TCP/IP Services headers; what version and ECO of TCP/IP Services is in use here? (Do you have tcpip$examples:in6.h around, or is this the version from the TLB?) (Apologies on not reading your message in detail; I've a few other things going on right now...) There were header file updates to in6.h in TCP/IP Services V5.5; I do not know if those updates are related to this. Do also re-install the C compiler if that has not been done since the most recent OpenVMS upgrade, as this step rebuilds various of the libraries -- this might not clear this particular problem, but it has been seen to clear various stale definitions. There might be a workaround for this around, too; this looks to be an incompatibility with the TCP/IP Services declarations and the structure-level padding. ---------------------------- #include ----------------------------- For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq --------------------------- pure personal opinion --------------------------- Hoff (Stephen) Hoffman OpenVMS Engineering hoff[at]hp.com ------------------------------ Date: Wed, 05 Jan 2005 17:23:08 -0500 From: Dave Froble Subject: Re: C File sharing issue with multiple writers Message-ID: <41DC68CC.8010202@tsoft-inc.com> Hein wrote: > "Kannan" wrote in message > news:1104893260.841985.178950@z14g2000cwz.googlegroups.com... > > >>There is a file Oracle configuration Repository (a streamlf mode file >>on VMS Cluster file system), which has resources registered by a daemon >>process that can run on multiple nodes and share this common file. At >>any point of time one will be a master which can write into this OCR. >> > > Are you talkign about an oracle owned and controlled file, if so, you shoudl > probably not muck with that except through Oracle API's. If it is your file, > and you have this applicaiton level lock protocol, then you do not need rms > to control the file sharing, and you may consider not using record mode > > That > > >>The open call I am using to open this file in shared mode is the >>following >>open((const char >> >> > *)filename,O_RDWR|O_DSYNC,"ctx=rec","rfm=stmlf","shr=get,put,upd","rop=rea") > ; > > The lock for read is suspect. > I would encourage you to use set file /stat and moni rms, to verify record > mode is used. > I'd further use ANAL/RMS show proce/rms=(fab,rab) after the open and > /rms=(fab,fsb) after some operations (with the file marked for stats). > > >>and the writes and reads on the file is done using pwrite and pread C >> > runtime calls, > >>which reads/writes based on offset information. >> > > I only know of fread and fwrite, no pread/pwrite. Please explain. > > >>And I am doing fsync call after every pwrite , so that the data gets >> > written to > >>the disk immediately. >> > > If RMS file sharing is properly activated, then any put will go through to > the disk, and the sync in redundant. > > > >>Now for some reason if the Daemon 2 exits/crashes, the file size on VMS >>gets truncated to 1040 blocks essentially corrupting this file. >> > > Sounds like 'truncate on put' might have been active, > Or, RMS is simply deferring the EOF update. > Again... ANAL/SYS but now: show proces/rms=SFSB > > Daemon 2 might need to re-open with full sharing to get RMS to communicate > the in-memory EOF value. > Daemon 2 migth want to open SHR=UPD, FAC=GET to make sure it never wants to > update EOF. > > >>now if daemon 1 exits and daemon 2 attempts to read beyond 1040 blocks, >>it gets an error >> > > That suggests deamon 2 did truncate after daemon 1 appended. > > I would recommend calling RMS directly for these kind of jobs. > Yes, it is more porting work, but so much clearer as to what will happen. > > fwiw, > Hein. > > > I'd agree with all that Hein has written. But I'd also suggest that if working through RMS is causing problems, using QIO and the locking routines directly might work better for you. Dave ------------------------------ Date: Wed, 05 Jan 2005 22:49:24 -0600 From: "Craig A. Berry" Subject: Re: C File sharing issue with multiple writers Message-ID: In article <41dc1169$1@usenet01.boi.hp.com>, "Hein" wrote: > "Kannan" wrote in message > news:1104893260.841985.178950@z14g2000cwz.googlegroups.com... > > > There is a file Oracle configuration Repository (a streamlf mode file > > on VMS Cluster file system), which has resources registered by a daemon > > process that can run on multiple nodes and share this common file. At > > any point of time one will be a master which can write into this OCR. > > Are you talkign about an oracle owned and controlled file, if so, you shoudl > probably not muck with that except through Oracle API's. Given his return address, he may well be implementing an Oracle API. > That > > > The open call I am using to open this file in shared mode is the > > following > > open((const char > > > *)filename,O_RDWR|O_DSYNC,"ctx=rec","rfm=stmlf","shr=get,put,upd","rop=rea") > ; > > The lock for read is suspect. Yes, what does it mean to lock a record for read when it's not a record-oriented file? The RMS parameters to the CRTL routines are quite handy, but it's pretty easy to pass parameters that are incompatible with what the CRTL is doing. > I would encourage you to use set file /stat and moni rms, to verify record > mode is used. > I'd further use ANAL/RMS show proce/rms=(fab,rab) after the open and > /rms=(fab,fsb) after some operations (with the file marked for stats). > > > and the writes and reads on the file is done using pwrite and pread C > runtime calls, > > which reads/writes based on offset information. > > I only know of fread and fwrite, no pread/pwrite. Please explain. pwrite and pread are part of the POSIX standard and were added to the CRTL in version 7.3-2 (and perhaps available on earlier systems via ECO). They are like write() and read() except they add another argument which is the offset in the file at which data is to be read or written. In essence a pwrite is like doing an lseek() and then a write() except the file pointer is not changed in the process. Something stirs in my memory about fixes in CRTL ECOs to lseek() and/or fseek(), so there could well be something relevant to pwrite()/pread() even if the ECO doesn't explicitly say so. In other words, be sure all CRTL ECOs are current. Other than that, follow Hein's diagnostic advice. ------------------------------ Date: Wed, 5 Jan 2005 14:08:17 -0500 From: Wayne Sewell Subject: Re: Comp.os.vms netiquette Message-ID: <00A3D6B8.77A2DCAD.5@tachysoft.com> >From: "Hein" >X-Newsgroups: comp.os.vms >Subject: Re: Comp.os.vms netiquette >Date: Wed, 5 Jan 2005 11:36:21 -0500 > > >"Jeff Cameron" wrote in message >news:BE0078F5.3A9C%JCam90502@jcameron.com... >> >> What is the accepted etiquette for the comp.os.vms board concerning >> advertising commercial software for OpenVMS systems? > >I would suspect it is officially discouraged, but it is infinitely more >appropriate then the recent 'young men' and piramid scheme 'but this one >works' topics, and various other rants. > >It will be just one more ignore for some and a possibly welcome reprieve >for others. > Just be aware that potential customers may be pissed off, especially if you go overboard with it. For instance, I wouldn't buy anything from Island Computers if they were the only vendor on earth. They have been bombarding the newsgroup with incessant advertising for years. Wayne =============================================================================== Wayne Sewell, Tachyon Software Consulting (281)812-0738 wayne@tachysoft.com http://www.tachysoft.com/www/tachyon.html and wayne.html =============================================================================== Larry(sniffing):"I smell something awful." Moe:"Yeah, well don't brag about it." ------------------------------ Date: Wed, 05 Jan 2005 13:56:36 -0800 From: Tom Crabtree Subject: Re: Comp.os.vms netiquette Message-ID: <-r6dnWA53YT-_0HcRVn-vg@sunset.net> > > Just be aware that potential customers may be pissed off, especially if you go > overboard with it. For instance, I wouldn't buy anything from Island Computers > if they were the only vendor on earth. They have been bombarding the newsgroup > with incessant advertising for years. > Wayne: It's too bad you feel that way about Island Computers. I've bought quite a few Alpha's from them (at least 10 PWS 500AU's over the last few years), and have never had a bad experience with them (which is more than I can say for DEC/Compaq/HP). I could praise them, but I fear it would fall on deaf ears. Dave T., if you're listening (and I know you are...), Happy New Year, pip, pip, cheerio and all that rot. ;-) So, Wayne. It's funny you should complain about Island's occasional advertising, but you don't mention JF Mezei and his flock of "ardent admirers" with all their topical and informational cross posts. Not that I'm picking on JF, but he's certainly gained the attention and admiration of someone or something not of this world. Tom Crabtree ------------------------------ Date: Wed, 05 Jan 2005 17:19:57 -0500 From: Dave Froble Subject: Re: Comp.os.vms netiquette Message-ID: <41DC680D.8030604@tsoft-inc.com> Wayne Sewell wrote: >>From: "Hein" >>X-Newsgroups: comp.os.vms >>Subject: Re: Comp.os.vms netiquette >>Date: Wed, 5 Jan 2005 11:36:21 -0500 >> > >> >>"Jeff Cameron" wrote in message >>news:BE0078F5.3A9C%JCam90502@jcameron.com... >> >>>What is the accepted etiquette for the comp.os.vms board concerning >>>advertising commercial software for OpenVMS systems? >>> >>I would suspect it is officially discouraged, but it is infinitely more >>appropriate then the recent 'young men' and piramid scheme 'but this one >>works' topics, and various other rants. >> >>It will be just one more ignore for some and a possibly welcome reprieve >>for others. >> >> > > Just be aware that potential customers may be pissed off, especially if you go > overboard with it. For instance, I wouldn't buy anything from Island Computers > if they were the only vendor on earth. They have been bombarding the newsgroup > with incessant advertising for years. And they've been exceeding helpful at times. We're all in this together. It would be best if we all were pulling in the same direction. Possibly Island could have been helpful when you were trolling ebay for some parts? Dave ------------------------------ Date: Wed, 5 Jan 2005 17:10:13 -0500 From: Wayne Sewell Subject: Re: Comp.os.vms netiquette Message-ID: <00A3D6D1.E2511691.5@tachysoft.com> >NNTP-Posting-Date: Wed, 05 Jan 2005 15:55:47 -0600 >Date: Wed, 05 Jan 2005 13:56:36 -0800 >From: Tom Crabtree >User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 > Netscape/7.1 (ax) >X-Accept-Language: en-us, en >MIME-Version: 1.0 >X-Newsgroups: comp.os.vms >Subject: Re: Comp.os.vms netiquette >So, Wayne. It's funny you should complain about Island's occasional >advertising, If it was occasional, it wouldn't be so much of an issue. >but you don't mention JF Mezei and his flock of "ardent >admirers" with all their topical and informational cross posts. Not >that I'm picking on JF, but he's certainly gained the attention and >admiration of someone or something not of this world. I blame the psychos and not JF. Whatever he does is outside of the newsgroup, so it's their fault that the crap shows up here. It's basically just a different form of spam. Fortunately, it is fairly easy to filter. Unlike Island, JF has no control of inappropriate shit being posted to the newsgroup. =============================================================================== Wayne Sewell, Tachyon Software Consulting (281)812-0738 wayne@tachysoft.com http://www.tachysoft.com/www/tachyon.html and wayne.html =============================================================================== Larry(sniffing):"I smell something awful." Moe:"Yeah, well don't brag about it." ------------------------------ Date: Wed, 5 Jan 2005 17:53:50 -0500 From: Wayne Sewell Subject: Re: Comp.os.vms netiquette Message-ID: <00A3D6D7.F9E1658F.11@tachysoft.com> >From: Dave Froble >X-Newsgroups: comp.os.vms >Subject: Re: Comp.os.vms netiquette >Date: Wed, 05 Jan 2005 17:19:57 -0500 >Wayne Sewell wrote: > >>>From: "Hein" >>>X-Newsgroups: comp.os.vms >>>Subject: Re: Comp.os.vms netiquette >>>Date: Wed, 5 Jan 2005 11:36:21 -0500 >>> >> >>> >>>"Jeff Cameron" wrote in message >>>news:BE0078F5.3A9C%JCam90502@jcameron.com... >>> >>>>What is the accepted etiquette for the comp.os.vms board concerning >>>>advertising commercial software for OpenVMS systems? >>>> >>>I would suspect it is officially discouraged, but it is infinitely more >>>appropriate then the recent 'young men' and piramid scheme 'but this one >>>works' topics, and various other rants. >>> >>>It will be just one more ignore for some and a possibly welcome reprieve >>>for others. >>> >>> >> >> Just be aware that potential customers may be pissed off, especially if you go >> overboard with it. For instance, I wouldn't buy anything from Island Computers >> if they were the only vendor on earth. They have been bombarding the newsgroup >> with incessant advertising for years. > >And they've been exceeding helpful at times. > >We're all in this together. It would be best if we all were pulling in the same >direction. Possibly Island could have been helpful when you were trolling ebay >for some parts? Why is Island the only vendor who is allowed to advertise here in comp.os.vms? Lots of us have vms-related products to sell. Lots of us have contributed to the newgroup. Lots of us have been helpful on occasion. Yes, we are all in this together. All of us care about the future of vms and want to provide vms-only solutions. If Island is allowed to use the newsgroup for sales and marketing, all the rest of us should also be allowed to do so. Either no one should be allowed to advertise, or everyone should be allowed to advertise. Wayne =============================================================================== Wayne Sewell, Tachyon Software Consulting (281)812-0738 wayne@tachysoft.com http://www.tachysoft.com/www/tachyon.html and wayne.html =============================================================================== Larry(sniffing):"I smell something awful." Moe:"Yeah, well don't brag about it." ------------------------------ Date: Thu, 06 Jan 2005 00:35:01 GMT From: "FredK" Subject: Re: Comp.os.vms netiquette Message-ID: "Wayne Sewell" wrote in message news:00A3D6D7.F9E1658F.11@tachysoft.com... > > Why is Island the only vendor who is allowed to advertise here in comp.os.vms? > They are not. > Lots of us have vms-related products to sell. > Then by all means, do so. Here or other. > Lots of us have contributed to the newgroup. > Yup. Some more noise than signal. > Lots of us have been helpful on occasion. > Yup. > Yes, we are all in this together. All of us care about the future of vms and > want to provide vms-only solutions. > Very cool. > If Island is allowed to use the newsgroup for sales and marketing, all the rest > of us should also be allowed to do so. > FEEL FREE. Really. Please. > Either no one should be allowed to advertise, or everyone should be allowed to > advertise. > As long as it is in some way VMS-related - I don't think you will hear any complaints. Island Computer has a business. Some of that business is to the die hard hobbyist. They get systems in, they let people know about it. They are hard up for a part or a system, they also let people know about it. I haven't really heard anyone ever say something bad about them here. So yes. FEEL FREE to let us know what you have to sell. I suppose if it becomes some daily repetetive thing - then people will see it as abuse. But when you have something new, or every once in a while you want to get it back out there - do it. Perhaps someone can start a monthly post that collects a bunch of them if nothing changes. ------------------------------ Date: Wed, 05 Jan 2005 19:43:45 -0500 From: JF Mezei Subject: Re: Comp.os.vms netiquette Message-ID: <1104971601.d51ca97be9a6fdaa75f587a47882d1db@teranews> Wayne Sewell wrote: > Why is Island the only vendor who is allowed to advertise here in comp.os.vms? > > Lots of us have vms-related products to sell. There are acceptable and unacceptable ways to advertise on a newsgroup. As long as the thrust is to announce availability of a product, and is not done overtly and not at a high frequency, it is acceptable to me. When VMS lost all its publications (remember Digital Review ?), the VMS marketplace lost its advertising channels. So making the availability of a product known here is a positive thing., as long as it is presented in a professional manner. ------------------------------ Date: 5 Jan 2005 22:09:24 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Comp.os.vms netiquette Message-ID: In article , "FredK" writes: > As long as it is in some way VMS-related - I don't think you will hear any > complaints. > > Island Computer has a business. Some of that business is to the die hard > hobbyist. They get systems in, they let people know about it. They are > hard up for a part or a system, they also let people know about it. I > haven't really heard anyone ever say something bad about them here. A while ago, Fred, back when I was complaining about Island, they were spamming the newsgroup with offers of PCs for sale.* I have not seen an off-topic post from them in a long time. * I would have complained just as loudly if it was Macintoshes, sailing gear or anything else non-VMS that I happen to care about. ------------------------------ Date: Thu, 06 Jan 2005 00:04:57 -0500 From: Dave Froble Subject: Re: Comp.os.vms netiquette Message-ID: <41DCC6F9.2080002@tsoft-inc.com> Wayne Sewell wrote: >>From: Dave Froble >>X-Newsgroups: comp.os.vms >>Subject: Re: Comp.os.vms netiquette >>Date: Wed, 05 Jan 2005 17:19:57 -0500 >> > > >>Wayne Sewell wrote: >> >> >>>>From: "Hein" >>>>X-Newsgroups: comp.os.vms >>>>Subject: Re: Comp.os.vms netiquette >>>>Date: Wed, 5 Jan 2005 11:36:21 -0500 >>>> >>>> >>>>"Jeff Cameron" wrote in message >>>>news:BE0078F5.3A9C%JCam90502@jcameron.com... >>>> >>>> >>>>>What is the accepted etiquette for the comp.os.vms board concerning >>>>>advertising commercial software for OpenVMS systems? >>>>> >>>>> >>>>I would suspect it is officially discouraged, but it is infinitely more >>>>appropriate then the recent 'young men' and piramid scheme 'but this one >>>>works' topics, and various other rants. >>>> >>>>It will be just one more ignore for some and a possibly welcome reprieve >>>>for others. >>>> >>>> >>>> >>>Just be aware that potential customers may be pissed off, especially if you go >>>overboard with it. For instance, I wouldn't buy anything from Island Computers >>>if they were the only vendor on earth. They have been bombarding the newsgroup >>>with incessant advertising for years. >>> >>And they've been exceeding helpful at times. >> >>We're all in this together. It would be best if we all were pulling in the same >>direction. Possibly Island could have been helpful when you were trolling ebay >>for some parts? >> > > Why is Island the only vendor who is allowed to advertise here in comp.os.vms? > > Lots of us have vms-related products to sell. > > Lots of us have contributed to the newgroup. > > Lots of us have been helpful on occasion. > > Yes, we are all in this together. All of us care about the future of vms and > want to provide vms-only solutions. > > If Island is allowed to use the newsgroup for sales and marketing, all the rest > of us should also be allowed to do so. > > Either no one should be allowed to advertise, or everyone should be allowed to > advertise. > > Wayne > =============================================================================== > Wayne Sewell, Tachyon Software Consulting (281)812-0738 wayne@tachysoft.com > http://www.tachysoft.com/www/tachyon.html and wayne.html > =============================================================================== > Larry(sniffing):"I smell something awful." Moe:"Yeah, well don't brag about it." > I'd welcome some information on available products. What would be nice, though I don't know a mechinism for doing such, would be a monthly post with vendor, a short (25 words) description of a product, and a URL for more info. I'd welcome such in the sig of such vendors. Otherwise, I don't know what's available, and when I want something I have to start searching without any clues whether it exists, or where to find it. Change the 'I' to 'all VMS users' and it's still appropriate. Dave ------------------------------ Date: 5 Jan 2005 19:41:02 GMT From: healyzh@aracnet.com Subject: Re: DS10L using laptop drives. Message-ID: John E. Malmberg wrote: > I have not looked at the cabinet of a DS10L to see of there is any way > to mount the laptop IDE or other drives, nor do I know if the cabinet > would take the heat. > I also have not heard of anyone repacking a DS10L in a larger case to > have more drive bays. That would probably void any warrantee on the unit. I've got a friend that has done some major work on the cooling of his DS10L so that it will run quieter. I've yet to see the modifications he's made, but I gather he has the fans running slower, and has cut a hole above the CPU to vent heat out directly. For DS10L's that are being used as Hobbyist machines, there are probably several things that can be done to improve the cooling as long as the system doesn't have to remain a true 1U system. I would tend to suspect that this would likely also improve the life of the system. Personally, I'd dump the Powerstorm, and put a good SCSI card in there with an external disk box rather than think about trying to fit laptop drives. Zane ------------------------------ Date: 5 Jan 2005 12:32:07 -0800 From: jordan@ccs4vms.com Subject: Re: DS10L using laptop drives. Message-ID: <1104957127.525151.186200@c13g2000cwb.googlegroups.com> > Personally, I'd dump the Powerstorm, and put a good SCSI card in there with > an external disk box rather than think about trying to fit laptop drives. That would rather defeat his purpose, I believe; he's using the system as on OpenGL workstation... ------------------------------ Date: Wed, 05 Jan 2005 18:00:59 -0500 From: Dave Froble Subject: Re: DS10L using laptop drives. Message-ID: <41DC71AB.8080100@tsoft-inc.com> jordan@ccs4vms.com wrote: >>Personally, I'd dump the Powerstorm, and put a good SCSI card in >> > there with > >>an external disk box rather than think about trying to fit laptop >> > drives. > > That would rather defeat his purpose, I believe; he's using the system > as on OpenGL workstation... > > Use the DS10L as a compute system running OpenGL, and add another system that can provide adequate storage. An older system should do Ok, an Alpha, or even a VAX. Use DECnet for access, or if that's not adequate, cluster the systems. If anyone is going to bitch about price, old VAXstations and old Alphas are rather cheap, and sometimes "free to the first person who will haul it away". Dave ------------------------------ Date: Wed, 5 Jan 2005 23:09:18 +0000 (UTC) From: klewis@OMEGA.MITRE.ORG (Keith A. Lewis) Subject: Re: DS10L using laptop drives. Message-ID: Dave Froble writes in article <41DC71AB.8080100@tsoft-inc.com> dated Wed, 05 Jan 2005 18:00:59 -0500: >Use the DS10L as a compute system running OpenGL, and add another system that >can provide adequate storage. An older system should do Ok, an Alpha, or even a >VAX. Use DECnet for access, or if that's not adequate, cluster the systems. > >If anyone is going to bitch about price, old VAXstations and old Alphas are >rather cheap, and sometimes "free to the first person who will haul it away". I use a $200 Linux system I bought from Wal-mart for storage. NFS rules. --Keith Lewis klewis {at} mitre.org The above may not (yet) represent the opinions of my employer. ------------------------------ Date: Wed, 05 Jan 2005 13:16:37 -0500 From: JF Mezei Subject: Re: Emulation of an Alpha server running OpenVMS Message-ID: <41DC2EFD.312B803F@teksavvy.com> "Stanley F. Quayle" wrote: > Hardly "legacy" -- Alpha systems are still being built, and will be > for at least 2 years. Well, an architecture whose EOL has been annoucned officially is pretty well legacy, even if there remains a strong possibility that Alpha's life may be extended beyond what Carly would have hoped. > There's no Alpha emulator in the CHARON series (there's a PDP-11 > emulator, too), What I need is an Alpha emulator running on my all mighty Microvax II :-) The problem with the VAX-VMS emulators is that they rely on a VAX version of VMS which receives very little improvements anymore. May be good for legacy applications, but not good for new applications. As long as there remains a sizeable VAX userbase, new features added to Alpha (or whatever successor platform) but not to VAX are moot since application writers wishing to serve all VMS users can't really use those new features. ------------------------------ Date: 5 Jan 2005 13:49:40 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Emulation of an Alpha server running OpenVMS Message-ID: In article <10to2l7d12r5ab7@corp.supernews.com>, Andrew Robert writes: > Good morning, > > I anticipate retirement of my legacy Alpha OpenVMS systems in the near > future. > > I've reviewed the Charon-VAX and Simh VAX emulators and they are nice > but they appear to emulate the VAX/VMS environment only. > > I need to be able to emulate a full Alpha system. Why ? If you need it, keep it running. Otherwise, save the electricity. ------------------------------ Date: Wed, 05 Jan 2005 15:09:27 -0500 From: Andrew Robert Subject: Re: Emulation of an Alpha server running OpenVMS Message-ID: <10toib0edlmjc40@corp.supernews.com> Larry Kilgallen wrote: > In article <10to2l7d12r5ab7@corp.supernews.com>, Andrew Robert writes: > >>Good morning, >> >>I anticipate retirement of my legacy Alpha OpenVMS systems in the near >>future. >> >>I've reviewed the Charon-VAX and Simh VAX emulators and they are nice >>but they appear to emulate the VAX/VMS environment only. >> >>I need to be able to emulate a full Alpha system. > > > Why ? If you need it, keep it running. Otherwise, save the electricity. I'd love to keep them running but I will shortly be forced to move the hardware out due to computer room space considerations. Things are rather tight and I have Unix/Windows Admin people circling my servers like vultures. :) A couple GS-140's and their associated ESA12000 racks are not what I would call foot-print minimal. The other thing is nobody wants to spend money on the beasts anymore. -- Thank you, Andrew Robert E-mail: arobert@townisp.com Ur: http://shardservant.no-ip.info:8080 ------------------------------ Date: Wed, 05 Jan 2005 13:17:22 -0700 From: "Barry Treahy, Jr." Subject: Re: Emulation of an Alpha server running OpenVMS Message-ID: <41DC4B52.7030000@MMaz.com> JF Mezei wrote: >"Stanley F. Quayle" wrote: > > >>There's no Alpha emulator in the CHARON series (there's a PDP-11 >>emulator, too), >> >> > >What I need is an Alpha emulator running on my all mighty Microvax II :-) > > Boy, I'd hate to see your build times :-P -- Barry Treahy, Jr E-mail: Treahy@MMaz.com Midwest Microwave, Inc. Phone: 480/314-1320 Vice President & CIO FAX: 480/661-7028 ... but it's a DRY HEAT! ------------------------------ Date: Wed, 05 Jan 2005 21:32:00 +0100 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= Subject: Re: Emulation of an Alpha server running OpenVMS Message-ID: <41DC4EBF.7B22D1D7@aaa.com> Andrew Robert wrote: > > I'd love to keep them running but I will shortly be forced to move the > hardware out due to computer room space considerations. > > Things are rather tight and I have Unix/Windows Admin people circling my > servers like vultures. :) Isn't there anything running on them ? How come you have "a couple GS-140's" and still you have a few "Unix/Windows Admin people" that decides about your facilities ? > > A couple GS-140's and their associated ESA12000 racks are not what I > would call foot-print minimal. > > The other thing is nobody wants to spend money on the beasts anymore. What about those "owning" the applications they are running ? Doesn't your company make any money out of those apps ? What does the owners of those apps say about it ? Or is it that you actualy aren't running anything on your Alpha's ? Why keep them then ? It all seems just silly to me... /Jan-Erik. ------------------------------ Date: 5 Jan 2005 20:44:18 GMT From: healyzh@aracnet.com Subject: Re: Emulation of an Alpha server running OpenVMS Message-ID: Andrew Robert wrote: > A couple GS-140's and their associated ESA12000 racks are not what I > would call foot-print minimal. > The other thing is nobody wants to spend money on the beasts anymore. If you've that kind of hardware, there is no way you could get that kind of performance at this time via emulation (assuming an emulator existed, which it doesn't). Zane ------------------------------ Date: 5 Jan 2005 13:30:41 -0800 From: "DL Phillips" Subject: Re: Emulation of an Alpha server running OpenVMS Message-ID: <1104960641.151495.45510@f14g2000cwb.googlegroups.com> Andrew Robert wrote: > > A couple GS-140's and their associated ESA12000 racks are not what I > would call foot-print minimal. > > The other thing is nobody wants to spend money on the beasts anymore. > > They're probably fully deprecited, too. You can get GS140 power with less money and footprint today. Check out this link to the Alpha performance comparison chart. It's showing Tru64 (I didn't find one for OpenVMS) but the relationships should be the same even if the numbers are different. Find your GS140 here and see what newer box you can get that will do the job. < http://h18002.www1.hp.com/alphaserver/performance/perf_by_perf.html > .. .. -Doug ------------------------------ Date: Wed, 05 Jan 2005 15:27:57 -0500 From: "Stanley F. Quayle" Subject: Re: Emulation of an Alpha server running OpenVMS Message-ID: <41DC077D.17809.33BD3247@localhost> On 5 Jan 2005 at 13:16, JF Mezei wrote: > What I need is an Alpha emulator running on my all mighty Microvax II > :-) An emulation of a 64-bit system on a 32-bit system would be incredibly slow. > The problem with the VAX-VMS emulators is that they rely on a VAX > version of VMS which receives very little improvements anymore. That wasn't true until very recently. Please note that the new VMS roadmaps don't mention VAX anymore. > May be good for legacy applications, but not good for new applications. Make that "great" for legacy applications [Shameless Plug Alert!] Actually, I write new applications all the time that run on VAX, Alpha, and now Itanium. > As long as there remains a sizeable VAX userbase, new features added > to Alpha (or whatever successor platform) but not to VAX are moot > since application writers wishing to serve all VMS users can't really > use those new features. What features do you need? And could you get to them by clustering with a small, cheap, Alpha? --Stan Quayle Quayle Consulting Inc. ---------- Stanley F. Quayle, P.E. N8SQ +1 614-868-1363 8572 North Spring Ct., Pickerington, OH 43147 USA stan-at-stanq-dot-com http://www.stanq.com ------------------------------ Date: Wed, 05 Jan 2005 21:58:27 GMT From: hoff@hp.nospam (Hoff Hoffman) Subject: Re: Emulation of an Alpha server running OpenVMS Message-ID: <7qZCd.5167$kk7.2464@news.cpqcorp.net> In article <10to2l7d12r5ab7@corp.supernews.com>, Andrew Robert writes: :I anticipate retirement of my legacy Alpha OpenVMS systems in the near :future. The AlphaServer GS140 series boxes are fairly old, and replacement Alpha systems and storage may be (would be?) rather smaller. As others have mentioned, there is presently no Alpha emulator available, and a move to a smaller and speedier Alpha, or a move to a OpenVMS I64 box -- and significant cost savings within these I64 boxes could be realized here -- might well be an option. Emulation is not presently an option for Alpha environments. The AEST package is available for translation of Alpha images (and of any previously-translated VAX images in present use on the Alpha systems) for re-use of existing user-mode applications on OpenVMS I64; for re-use of Alpha code on I64 where the original source code was lost. (For those applications with source code available, the migration is generally expected to be a rebuild-and-go, with details of this and architecture-specific considerations available in the V8.2 migration documentation.) ---------------------------- #include ----------------------------- For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq --------------------------- pure personal opinion --------------------------- Hoff (Stephen) Hoffman OpenVMS Engineering hoff[at]hp.com ------------------------------ Date: Wed, 05 Jan 2005 17:47:02 -0500 From: JF Mezei Subject: Re: Emulation of an Alpha server running OpenVMS Message-ID: <1104964605.efadd8aedbf60101c8fb3f94044f6d6e@teranews> "Barry Treahy, Jr." wrote: > >What I need is an Alpha emulator running on my all mighty Microvax II :-) > > > > > Boy, I'd hate to see your build times :-P Not bad if the emulator has drivers to access some additional memory (say 1 gig) and perhaps a QBUS board that incorporates 4 EV7 CPU :-) (So the emaulator would have to fit in the 16 meg limit of the MVII, but the emulatoed programs woudln't have to reside in there). Consider the environmental benefits of not having to throw out all that metal and boards from my all Mighty Microvax II :-) ------------------------------ Date: Wed, 05 Jan 2005 17:54:30 -0500 From: Dave Froble Subject: Re: Emulation of an Alpha server running OpenVMS Message-ID: <41DC7026.4060506@tsoft-inc.com> Andrew Robert wrote: > Larry Kilgallen wrote: > >> In article <10to2l7d12r5ab7@corp.supernews.com>, Andrew Robert >> writes: >> >>> Good morning, >>> >>> I anticipate retirement of my legacy Alpha OpenVMS systems in the >>> near future. >>> >>> I've reviewed the Charon-VAX and Simh VAX emulators and they are nice >>> but they appear to emulate the VAX/VMS environment only. >>> >>> I need to be able to emulate a full Alpha system. >> >> >> >> Why ? If you need it, keep it running. Otherwise, save the electricity. > > > > I'd love to keep them running but I will shortly be forced to move the > hardware out due to computer room space considerations. If the systems are still providing service to users, then I'd have to ask, do you have different classes of users? Why aren't the VMS users at least equal to other users? What is running on the systems? > Things are rather tight and I have Unix/Windows Admin people circling my > servers like vultures. :) A good double barrel 12 guage works good on vultures. :-) > A couple GS-140's and their associated ESA12000 racks are not what I > would call foot-print minimal. How about an ES40/ES45? A DS15 or DS25? If you have sizable ESA12000 racks, then you've got lots of storage. Is it still important to the users? If it's older stuff, with small disks, then replacing with 36 or 72 GB disks or such would reduce the storage footprint significantly. Might not help with access speed. Don't know a lot about storage anymore. > The other thing is nobody wants to spend money on the beasts anymore. I'd think the costs on old hardware could be significant. The question is, are they questioning the amount, or just don't want to spend anything on VMS anymore? Pretty tough for people to offer suggestions when they don't know your situation. Perhaps you could provide adequate details and some good suggestions may appear. Dave ------------------------------ Date: Wed, 05 Jan 2005 18:03:15 -0500 From: JF Mezei Subject: Re: Emulation of an Alpha server running OpenVMS Message-ID: <1104965576.bc8d4ca21345488b73b3a743144b5be7@teranews> > > I'd love to keep them running but I will shortly be forced to move the > > hardware out due to computer room space considerations. What hasn't been said is wthere the VMS systems have lost application after application to newer platforms. In such a case, the existing hardware infrastructure may be overblown for the remaining demand. And if the plan is to phase out those remaining VMS apps "soon", then spending money for new (smaller) Alphas may be difficult to justify. The solution may lie more in financial restructuring. For instance, sell the big box and lease a new smaller Alpha box. The lease payments may end up being less than maintenance of the older bigger box, and it wouldn't require special budget to purchase a new box. ------------------------------ Date: Wed, 05 Jan 2005 18:08:55 -0500 From: Dave Froble Subject: Re: Emulation of an Alpha server running OpenVMS Message-ID: <41DC7387.6080001@tsoft-inc.com> JF Mezei wrote: > "Barry Treahy, Jr." wrote: > >>>What I need is an Alpha emulator running on my all mighty Microvax II :-) >>> >>> >>> >>Boy, I'd hate to see your build times :-P >> > > > Not bad if the emulator has drivers to access some additional memory (say 1 > gig) and perhaps a QBUS board that incorporates 4 EV7 CPU :-) > > (So the emaulator would have to fit in the 16 meg limit of the MVII, but the > emulatoed programs woudln't have to reside in there). > > Consider the environmental benefits of not having to throw out all that metal > and boards from my all Mighty Microvax II :-) > You need an elephant to stomp on that antique! No, I forget how they built the boxes back then. The elephant couldn't hurt it. I've got to feel that the only reason you're still running that thing is nostalgia. Even a VAXstation 4000 would be a hugh improvement. Dave ------------------------------ Date: Wed, 05 Jan 2005 19:06:24 -0500 From: Andrew Robert Subject: Re: Emulation of an Alpha server running OpenVMS Message-ID: <10tp074sgafgh27@corp.supernews.com> > > I'd think the costs on old hardware could be significant. The question > is, are they questioning the amount, or just don't want to spend > anything on VMS anymore? > > Pretty tough for people to offer suggestions when they don't know your > situation. Perhaps you could provide adequate details and some good > suggestions may appear. > > Dave > The reason why the budget is not there is because the applications resident on the VMS systems are being migrated off. The VMS systems will not be hosting users but simply serving as a historical data repository while that data is also migrated off and validated. Primarily, the issue revolves around some Oracle RDB Server databases and some vendor proprietor y database structures. Speed isn't really an issue because this is strictly for archive and an occassional report, not production. I looked at the Oracle side of things on a VAX but the latest VAX version does not match the version level in production. Even if it did, I still have the vendor proprietor y stuff to worry about. Management doesn't want to spend 1 cent on the hardware or associated service contracts so my choices are somewhat limited. It isn't the Unix/Windows people that are the issue but Senior Management trying to consolidate space. We recently shutdown one of our data centers so they need a place to put things. Even with server consolidation and such, it is tight. -- Thank you, Andrew Robert E-mail: arobert@townisp.com Ur: http://shardservant.no-ip.info:8080 ------------------------------ Date: Wed, 05 Jan 2005 19:37:30 -0500 From: JF Mezei Subject: Re: Emulation of an Alpha server running OpenVMS Message-ID: <1104971229.30fbc963aef979a7d1341df7d0cfdeef@teranews> Dave Froble wrote: > You need an elephant to stomp on that antique! No, I forget how they built the > boxes back then. The elephant couldn't hurt it. Correct. It was built like a tank, with multiple layers of thick metal. Interestingly, once you remove its Princess Lea ears and a backside extension, it makes for a very nice 19" rtack on wheels with a power supply/distribution at the base. > I've got to feel that the only reason you're still running that thing is > nostalgia. Even a VAXstation 4000 would be a hugh improvement. Actually, I have a whole bunch of serial ports on it with full modem control and have a variety of devices attached to it, and even as an MVII, it handles many background tasks nicely and even runs ALL-In-1 (down to single user :-). It also acts as a storage device for workstation and backup for my mac. If I won the lottery, of course, t woudl be replaced by some alpha, and some terminal servers to replace serial ports (I need fewer now than before). But migration would not be overnight due to all the software I have that assumes TX terminal ports (setting speed etc which is not allowed with LAT). ------------------------------ Date: Thu, 06 Jan 2005 00:12:48 -0500 From: Dave Froble Subject: Re: Emulation of an Alpha server running OpenVMS Message-ID: <41DCC8D0.3030305@tsoft-inc.com> JF Mezei wrote: > Dave Froble wrote: > >>You need an elephant to stomp on that antique! No, I forget how they built the >>boxes back then. The elephant couldn't hurt it. >> > > Correct. It was built like a tank, with multiple layers of thick metal. > Interestingly, once you remove its Princess Lea ears and a backside extension, > it makes for a very nice 19" rtack on wheels with a power supply/distribution > at the base. > > > >>I've got to feel that the only reason you're still running that thing is >>nostalgia. Even a VAXstation 4000 would be a hugh improvement. >> > > Actually, I have a whole bunch of serial ports on it with full modem control > and have a variety of devices attached to it, and even as an MVII, it handles > many background tasks nicely and even runs ALL-In-1 (down to single user :-). > It also acts as a storage device for workstation and backup for my mac. > > If I won the lottery, of course, t woudl be replaced by some alpha, Forget the lottery. I bet you could get a VAXstation 4000 model 60 off EBAY for no more than $50. A model 90, or an AlphaStation 200 would be nicer. Keep the MVII for the ports and storage. Don't run anything, compiles and such, on it. It'll help your blood pressure. > and some > terminal servers to replace serial ports (I need fewer now than before). But > migration would not be overnight due to all the software I have that assumes > TX terminal ports (setting speed etc which is not allowed with LAT). > ------------------------------ Date: Thu, 06 Jan 2005 01:56:09 -0500 From: JF Mezei Subject: Re: Emulation of an Alpha server running OpenVMS Message-ID: <41DCE0D7.3CA857F7@teksavvy.com> Dave Froble wrote: > no more than $50. A model 90, or an AlphaStation 200 would be nicer. Keep the > MVII for the ports and storage. Don't run anything, compiles and such, on it. > It'll help your blood pressure. I've long given up compiling on the all mighty microvax II. Buit I still have to link some programs on it due to it having all-in-1 and message router and not my other boxes. My Teenage all mighty microvax II should be turning adult this coming may. Yep 18 year old ... its in the prime of its life :-) :-) :-) :-) :-) ------------------------------ Date: Wed, 5 Jan 2005 23:07:25 -0500 From: "John Smith" Subject: Re: Has anyone heard if any of our customers have been hurt by the tidal wave in Message-ID: <2KmdnUcEdvfnJEHcRVn-sQ@igs.net> susan_skonetski@hotmail.com wrote: > The BBC does much better news but we do not get he BBC here which I > miss very much since I moved from the UK. Sue, If you have one version or another of a 'media player' on a non-VMS machine [I don't think anyone makes one (or open sources one) for VMS], you can get the BBC World Service on streaming audio via the web. ------------------------------ Date: Wed, 05 Jan 2005 19:55:47 GMT From: John Reagan Subject: Re: Help - SYSUAF and $SETUAI on UAI$_USER_DATA field Message-ID: <7DXCd.5153$sk7.98@news.cpqcorp.net> Lorin Ricker wrote: > > b) Looked for asynchronous and volatile data issues/problems, and > I've used all available Pascal attributes and directives to be sure > that I'm not being tripped up by this sort of thing. No change in > behavior. I'm pretty darn sure that compiler-optimization issues are > not at fault here. Thanks. :-) > > * Do $GET/SETUAI honor the logical name "SYSUAF" to redirect > operations to test-copies of SYSUAF.DAT, or are these RTL routines > "hard-wired" to the official system instance in SYS$SYSTEM? I've certainly moved SYSUAF.DAT out of SYS$SYSTEM before. The logicals have to be /SYSTEM/EXEC. For just playing with a local SYSUAF.DAT for fun, I believe the services will follow your logical. Define your SYSUAF logical and use AUTHORIZE to see if you can read/write it. It uses the same interfaces. Beyond that, I have no real advice. -- John Reagan HP Pascal/{A|I}MACRO for OpenVMS Project Leader Hewlett-Packard Company ------------------------------ Date: Wed, 5 Jan 2005 17:46:02 -0500 From: "Hein" Subject: Re: Help - SYSUAF and $SETUAI on UAI$_USER_DATA field Message-ID: <41dc6e5e$1@usenet01.boi.hp.com> "Lorin Ricker" wrote in message news:14nmt0peo98q2rvcdfu8noj7evb7e0pd6q@4ax.com... > I'm at my wit's end trying to find & fix some buggy behavior in a > utility program I've written which uses the system RTL routines : > The data I'm attempting to get/put in the UAI$_USER_DATA field is > interpreted as a counted-string of ASCII, basically an image of a > Pascal VARYING string simply laid into that field-area. fwiw... the actual storage in the record is also as counted string, but can also be derived from the records size minus start offset. A little odd that. This should be stranspararent to the program through $setuai. The offset is where the user data starts is stored in the second word in the record (UAF$W_USRDATOFF) This value really should be 0 or 644 (UAF$K_FIXED). It is cleared when a zero length user_data is stored. It is set to the current record size if it was zero on $setuai entry Best I can tell that current record size should pretty much be 644 in that case. To analyze you want to DUMP/RECOR=(STAR:xx,COUN=1) SYSUAF The easiest way to find the record number is SEARC/NUM/FORM=NON SYSUAF 'problem_usersname Notably check that second 16 bit word, and then the contents of the offset it points to. The first byte there should really equal to the record size minus that offset. Now compare a problem account with a working one. You may well be able to 'fix' broken usernames with dcl through careful usage of something along the lines of: $UNTESTED, UNSUPPORTED, DOUBLECHECK. $convert/share/stat sysuaf sysuaf.just_in_case $open/read/write/share=write uaf sysuaf $read/key=&problem_username uaf record $show symb record $record[16,16]=0 $record = f$extr(0,644,record) $write/update/symb uaf record $UNTESTED, UNSUPPORTED, DOUBLECHECK, > We encode application-specific and timezone information on a per-user/account > basis so that we can reasonably represent date/time fields in an Rdb > database for users across the country. Any chance you are trying to store exactly 255 bytes? The code looks a little suspect for that, but is probably fine. It the problem with user_data longer then 127? (signed vs unsigned byte?) Below you'll find a C test program. Define as foreing command, or put in DCL$PATH. Provide username as first argument. It will always display user_data if found, and will set if new data provided as second argument Pass empty string ("") to clear. Check target record with $open/read/write/share=write uaf sysuaf $read/nolock/key=&username uaf record $write sys$output f$len(record) $close uaf hopt this helps some, Hein. #include stdio #include string #include uaidef #define ckstat(x) if (((stat = x) & 7) != 1) SYS$EXIT(stat) main(int nargs, char **args) { static char usrbuf[256]; unsigned long stat, SYS$SETUAI(), SYS$GETUAI(), SYS$EXIT(), iosb[2]; unsigned short usrlen; struct {unsigned long len; char *addr;} username; struct { unsigned short buflen, itmcod; void *bufadr; unsigned short *rsladr; } itmlst[] = { { sizeof(usrbuf), UAI$_USER_DATA, usrbuf, &usrlen }, { 0, 0, 0, 0 }}; if (nargs < 2) { printf("Usage: %s username [userdata]\n",*args); SYS$EXIT(1); } username.addr = *++args; username.len = strlen(*args); ckstat(SYS$GETUAI(0, 0, &username, itmlst, 0, 0, 0)); usrbuf[usrlen]=0; printf ("usrlen=%d, usrdat='%s'\n",usrlen,usrbuf); if (nargs > 2) { itmlst[0].bufadr = *++args; itmlst[0].buflen = strlen(*args); SYS$EXIT(SYS$SETUAI(0, 0, &username, itmlst, 0, 0, 0)); } } ------------------------------ Date: Thu, 6 Jan 2005 00:28:06 -0500 From: "Hein RMS van den Heuvel" Subject: Re: Help - SYSUAF and $SETUAI on UAI$_USER_DATA field Message-ID: <41dccc8c$1@usenet01.boi.hp.com> "Hein" wrote in message news:41dc6e5e$1@usenet01.boi.hp.com... > > "Lorin Ricker" wrote in message news:14nmt0peo98q2rvcdfu8noj7evb7e0pd6q@4ax.com... > > I'm at my wit's end trying to find & fix some buggy behavior in a > > utility program I've written which uses the system RTL routines : > > You may well be able to 'fix' broken usernames with dcl through careful > usage of something along the lines of: : I think I now fully understand this problem. It looks like it will only happen if someone has mucked directly with SYSUAF. Specifically if someone simply grew a sysuaf record outside the SETUAI API (perhaps in a simplistic attempt to add user_data :-) Basically the usrdatoff offset field in each sysuaf record has to be 0 or 644 or you'll be in trouble. You can clear the problem with the DCL hack from my prior reply, or by simply and cleanly using SETUAI to set zero length USER_DATA. For example by passing "" as second argument to the C program from my prior reply. Here is a simple script to identify 'broken' sysuaf records: $open/read/share=write uaf sysuaf $loop: $read/nolock/end=done uaf record $offset = f$cvsi(16,16,record) $if offset.ne.0 .and. offset.ne.644 then - write sys$output f$len(record)," ",f$extr(4,12,record)," ", offset $goto loop $done: $close uaf And here is a simple example to corrupt a 'clean' (with no user_data to start) sysuaf record : $ open/read/write/share=write uaf sysuaf $ read/key=test uaf record $ record = record + " " $ write/update/symbol uaf record $close uaf Cheers, Hein. ------------------------------ Date: Wed, 05 Jan 2005 21:23:49 -0600 From: David J Dachtera Subject: Re: How to get Tape Tools to recognize terminfo database? Message-ID: <41DCAF45.3FCB184B@comcast.net> Alan Winston - SSRL Central Computing wrote: > > In article <41DB56A9.DABF2726@comcast.net>, David J Dachtera writes: > >Alan Winston - SSRL Central Computing wrote: > >> > >> In article <41DAD3B8.4030304@csdco.com>, John Nebel writes: > >> John -- > >> > >> (Sorry for top-posting; it seems to make more sense here.) > >> > >> Thanks so much for this! I foolishly followed the advice in the online manual, > >> and didn't look through the installed directory for a readme. > >> > >> This got the LTT tool running right away. (And I see that my drives fail > >> testing, but I don't see why.) > > > >If you could post clearer details of what you did and the effect it had, > >I personally would appreciate it, and perhaps others, but I can't speak > >for them. > > > > I defined USR to point to a top-level sys$sysdevice:[usr] and installed > a terminfo database several steps down that tree. This didn't enable LTT to > find terminfo. > > The advice John gave me (included below) let LTT find a terminfo and start up. > > Is that what you were asking? > > >That said, last time I inquired, LTT was only alpha-quality, not yet in > >full beta release. > > It certainly seems kind of flaky (features in the menu that turn out to be > unsupported, etc), but I didn't see any warnings on it when I found it on the > hp web site. No, there never have been any warnings, AFAIK. Then again, it was not openly publicized, either. A CSC support person "let the cat out of the bag", that's the only reason I discovered it. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ ------------------------------ Date: 5 Jan 2005 14:11:31 -0800 From: "denny" Subject: HPLJ tray selection problem from OVMS V7.3-1 Message-ID: <1104963091.385838.304870@c13g2000cwb.googlegroups.com> Greetings, I have written setup modules for HPLJ printers (4100, 4200) that select paper from tray 2 or from tray 3. Initially, these were set up so I could select plain paper (tray 3) or 3-hole punch (tray 2)for text-only documents. This scheme has worked fine for over a year, so I have confidence in the setup modules. Now, the users want to print white or colored paper with bar coded information. The setup modules (in a text library in sys$library) are included in two different forms called pcl_t2_port_full ! full size, 80 x 66, portrait, tray 2 (RESET,OR_PORT,LPI_6,PITCH_10,SIMPLEX,TRAY_2) pcl_t3_port_full ! same but tray 3. (RESET,OR_PORT,LPI_6,PITCH_10,SIMPLEX,TRAY_3) I then init 2 queues (for convenience), one with each of these forms as default. Put colored paper in tray 2. Send regular print jobs. Those sent to tray 2 come out blue while those sent to tray 3 come out white. So far so good. Now I send a document that includes bar coded information. The document generator is a piece of COBOL that knows how to awaken the bar code DIMM, HP Part #36596DT. When I send bar-code documents to a non-tray specific printer, it works as expected. However, when I want to select trays, there is a problem. The form used is called PCL_T%_DEfault_pcl, and consists of these modules (ok, its not quite a default form): pcl_T3_DEFAULT_PCL = (RESET,TRAY_3) PCL_T2_DEFAULT_PCL = (RESET,TRAY_2) The bar code comes out as bar code, but now, paper is only selected from tray 3, no matter what I do! Does anyone have experience trying to select trays while using the HP DIMM? Any suggestions would be appreciated. Thanks denny ------------------------------ Date: Wed, 05 Jan 2005 18:11:19 -0500 From: JF Mezei Subject: IA64 news (january 18th) Message-ID: <1104966063.aa58e7c7058eb7b82dada4cb52beb649@teranews> from: > http://news.com.com/Itanium--one+step+forward%2C+one+back/2100-1006_3-5513805.html?tag=nefd.top titled: Itanium: one step forward, one step back. Januray18, HP is to announce a faster IA64 chip for its biggest boxes (I assume Superdome). (So the Terry Shannon prediction of something happening on Jan 18 is the above). (It is the new IA64 with 9 meg of cache instead of 6). Also, Microsoft officially widthdraws Windows workstation from IA64. relevant paragraph: ## A single Itanium server can run not just HP-UX and Windows, but also Linux, and soon, HP's rarely used but highly regarded OpenVMS operating system that currently runs on another chip family headed for extinction, Alpha. Finally, HP is moving its super-high-end NonStop line from MIPS processors to Itanium. ## ------------------------------ Date: 5 Jan 2005 23:38:45 GMT From: Phaeton Subject: Interesting article about RDB Message-ID: <343c45F43bv1iU1@individual.net> Another news item stating the obvious : http://itmanagement.earthweb.com/datbus/article.php/3452301 Cheers, Csaba ------------------------------------------------------------------------- CSABA I. HARANGOZO |d|i|g|i|t|a|l| phaeton at iinet dot net dot au ------------------------------------------------------------------------- EARTH::AUSTRALIA:[SYDNEY]HARANGOZO.CSABA;1, delete? [N]: One-seventh of your life is spent on Monday. ------------------------------ Date: Wed, 05 Jan 2005 17:06:11 -0500 From: JF Mezei Subject: Re: More on Tru64 Message-ID: <1104962156.b72d55d49ff4d97c0939f2348caae158@teranews> Bill Gunshannon wrote: > Huh?? I can not imagine any way that postscript resembles Report > Writer any more than printf did. You can code a postscript prologue which will take your raw data and format it and print headers etc etc. This way, your 2G language doesn't need a report writer since it just needs to spew out raw data. OK, so you do need to write a postscript program to setup your report. The advantage is that you can have multipel postscript programs that read the same data and generate different output. > Considering how many times and for how long this had to be done > int he real world, I can't believe there isn't a published, well > tested way of doing precisely this in COBOL. Possibly today's COBOL is able to build strings such asn textual representation fo large numbers. But v=back in the 1980s, that wasn't the case. You couldn't address individual > idea of code re-use!) (Actually, I think there is a relatively simple > way to do the above in COBOL, but I would need to look at a reference > newer than my ANSI-74 text to refresh my memory. :-) ok, so how would you: 05 FIRST PIC X(30) value 'Three'. 05 SECOND PIC X(30) value 'Thousand'. 05 THIRD PIC X(60) value spaces. result in THIRD having the value "Three Thousand" in today's cobol ????? ------------------------------ Date: 6 Jan 2005 02:11:58 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: More on Tru64 Message-ID: <343l3eF478fnkU1@individual.net> In article <1104962156.b72d55d49ff4d97c0939f2348caae158@teranews>, JF Mezei writes: > Bill Gunshannon wrote: >> Huh?? I can not imagine any way that postscript resembles Report >> Writer any more than printf did. > > You can code a postscript prologue which will take your raw data and format it > and print headers etc etc. This way, your 2G language doesn't need a report > writer since it just needs to spew out raw data. > > OK, so you do need to write a postscript program to setup your report. The > advantage is that you can have multipel postscript programs that read the same > data and generate different output. > >> Considering how many times and for how long this had to be done >> int he real world, I can't believe there isn't a published, well >> tested way of doing precisely this in COBOL. > > Possibly today's COBOL is able to build strings such asn textual > representation fo large numbers. But v=back in the 1980s, that wasn't the > case. You couldn't address individual > >> idea of code re-use!) (Actually, I think there is a relatively simple >> way to do the above in COBOL, but I would need to look at a reference >> newer than my ANSI-74 text to refresh my memory. :-) > > ok, so how would you: > > 05 FIRST PIC X(30) value 'Three'. > 05 SECOND PIC X(30) value 'Thousand'. > 05 THIRD PIC X(60) value spaces. > > result in THIRD having the value "Three Thousand" in today's cobol ????? Don't know about "today's cobol", but in ANSI-74 it would have been: STRING FIRST, SPACE, SECOND DELIMITED BY SIZE INTO THIRD. 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: Wed, 5 Jan 2005 21:52:36 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: need help in decoding VAXstation 4000/60 console error message Message-ID: In article , "John Smith" writes: > >> it seems that (at least) disk 3 is broken > > > > Thanks. After a few power cycles (always leaving the power off for a > > couple of minutes), the VAXstation booted (which it is set to do > > automatically if it can) and the disk is now mounted on all 3 nodes in > > the cluster and is working fine. > > > May be a thermal fault. Have you opened the case and blown all the > accumulated dust away? Good idea. I suppose I should do that from time to time. ------------------------------ Date: Wed, 5 Jan 2005 18:58:53 -0500 From: "John Smith" Subject: Re: need help in decoding VAXstation 4000/60 console error message Message-ID: Phillip Helbig---remove CLOTHES to reply wrote: > In article , "John Smith" > writes: > >>>> it seems that (at least) disk 3 is broken >>> >>> Thanks. After a few power cycles (always leaving the power off for >>> a couple of minutes), the VAXstation booted (which it is set to do >>> automatically if it can) and the disk is now mounted on all 3 nodes >>> in the cluster and is working fine. >> >> >> May be a thermal fault. Have you opened the case and blown all the >> accumulated dust away? > > Good idea. I suppose I should do that from time to time. I have found that *anything* with a fan eventually coats the insides with a thick layer of dust. Some of my systems run 15C-25C cooler after cleaning. I had some earlier model disk drives that wouldn't reboot unless they were cooled significantly after they were powered off. ------------------------------ Date: Wed, 5 Jan 2005 19:14:11 -0500 From: "Neil Rieck" Subject: Re: Need help with user-written routine in SOR$ Message-ID: wrote in message news:1104809219.123603.315000@z14g2000cwz.googlegroups.com... > Hi, everyone, I hope someone can help with this... > > OS: OpenVMS 7.3 > System: Alpha > Language: BASIC > > I'm trying to write a user-written routine for the user_equal parameter > in SOR$BEGIN_SORT. I have to pass the routine by reference, so it has > to be an external routine to use LOC. Also, Sort/merge calls the > routine with 5 reference arguments ADRS1, ADRS2, LENG1, LENG2, CNTX, > which are the addresses of the two records to compare, pointers to word > structures containing length information, and the context longword. In > the user-written routine, I want to compare a non-sort-key field of the > two records and select which of the two to discard based on those > values. I will always keep one and discard the other. > > Here's what I think I need to do -- > > Main module: > ... > EXTERNAL LONG FUNCTION FN_SORT_EQ% > ... > SORT_EQ% = LOC(FN_SORT_EQ%) > ... > STATUS% = SOR$BEGIN_SORT(SORT.BUF,LRL%,,,,SORT_EQ%,,SRTTYPE%) > ... > > External function module: > FUNCTION LONG FN_SORT_EQ% (STRING REC_1 BY REF, STRING REC_2 BY REF, > WORD LEN_1 BY REF, WORD LEN_2 BY REF, LONG CTX) > EXTERNAL WORD SOR$_DELETE1, SOR$_DELETE2 > IF SEG$(REC_1, 350%, 358%) < SEG$(REC_2, 350%, 358%) THEN > FN_SORT_EQ% = SOR$_DELETE1 > ELSE > FN_SORT_EQ% = SOR$_DELETE2 > END IF > END FUNCTION > > The outcome I wish is that if the REC_1 field < the REC_2 field, REC_1 > is discarded, otherwise REC_2 is discarded. > > Is this correct? I think I'm missing something (or perhaps several > things). The 3rd and 4th arguments passed to the function are supposed > to be pointers to word structures containing length information, but I > don't have a clue what those structures consist of. I don't really care > what's in them because I don't need them - the records I am comparing > will always be the same length, but I'm not certain if I can just not > declare them and they would be ignored. Is this even close or am I > completely misunderstanding the VMS docs? > > Thanks in advance, > Cheryl > I never like to use the external statement for anything other than linking to stuff I wrote. The first two (if not all) of following lines should be used to make sure OpenVMS stuff gets declared properly. %include "$sordef" %from %library "sys$library:basic$starlet" %include "sor$routines" %from %library "sys$library:basic$starlet" %include "$dscdef" %from %library "sys$library:basic$starlet" %include "$fabdef" %from %library "sys$library:basic$starlet" When done this way, you'll get important compiler warnings for passing longs where VMS wants words or bytes. etc. * * * * * On a different note, if SRTTYPE% represents the "context" parameter in the above example, you'll need a third comma before it to make the call to SOR$BEGIN_SORT work properly * * * * * I've posted a reasonably complete solution here: http://www3.sympatico.ca/n.rieck/demo_vms/basic-sort-demo.zip Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/links/cool_openvms.html ------------------------------ Date: Thu, 06 Jan 2005 10:57:35 +1300 From: Martin Hunt Subject: Re: TCP/IP mailing problem Message-ID: On Wed, 05 Jan 2005 07:28:23 +0100, labadie wrote: >Martin Hunt a écrit : >> VMS V7.3 on VAX, TCP/IP Services for OpenVMS VAX Version V5.3 - ECO 2 >> >> Well, the emails go out, but the "To:" address is being partly >> translated to upper case, which some recipients object to. >> >> For example: >> >> $ Mail nl: "abc@w.x.y" > >apply the last Tcpip Eco, and try to triple the quotes, so > $ Mail nl: """abc@w.x.y""" What do you mean by the latest ECO? I can't find anything later than ECO 2. Trebling the quotes has no effect, and I have tried various combinations. I also notice that the domain part of the address always gets converted to lower case, even when entered in upper case. Very strange. --- Martin Hunt Systems Administrator Fairfax New Zealand Limited Wellington New Zealand ------------------------------ Date: Wed, 5 Jan 2005 21:58:11 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: TCP/IP mailing problem Message-ID: In article , Martin Hunt writes: > VMS V7.3 on VAX, TCP/IP Services for OpenVMS VAX Version V5.3 - ECO 2 > > Well, the emails go out, but the "To:" address is being partly > translated to upper case, which some recipients object to. > > For example: > > $ Mail nl: "abc@w.x.y" > > When it gets to the recipient, the address appears as ABC@x.y.z (only > the first part is translated to upper case). They should not object, since according to the RFC it shouldn't matter. ------------------------------ Date: Thu, 06 Jan 2005 16:32:10 +1300 From: Martin Hunt Subject: Re: TCP/IP mailing problem Message-ID: On Thu, 06 Jan 2005 10:57:35 +1300, Martin Hunt wrote: >Trebling the quotes has no effect, and I have tried various >combinations. I also notice that the domain part of the address always >gets converted to lower case, even when entered in upper case. Very >strange. I've just found that it works if I send mail to SMTP%"""a@b.c""" I need to do a bit more testing to make sure this will work for sending to multiple address, addresses in logical names, etc. --- Martin Hunt Systems Administrator Fairfax New Zealand Limited Wellington New Zealand ------------------------------ Date: 5 Jan 2005 13:06:19 -0600 From: clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) Subject: Re: Writing drivers for USB devices ?, was: Re: What's the state of USB Message-ID: <$k3Y5j8v3rdS@eisner.encompasserve.org> In article <41DC30F5.C3E8CD38@hp.com>, Forrest Kenney writes: > > At the present time there are no plans to document the USB > driver stack or provide a way to customers to write a USB device > driver. It a choice between having time to actively develop and > maintain the code base or get all the pieces into the kit and > documentation developed. Right now adding USB 2.0 and fixing bugs have > a higher priority. > > To fully document writing a USB device driver would require > chapters for the HID support driver, the USB support driver, the driver > interface to the USB Configuration manager process, and the HUB driver. > > What might happen is a driver for the USB space something like > GK driver for SCSI. It would allow support of USB devices that are > not part of the HID device class without writing a driver. You could > easily control many USB device that way. I am working on a proposal > for doing this at the present time and will present it to management > for approval. No promises there is more USB stuff to work on than > I have time to get done. Writing a and documenting a single generic > USB driver would be much simpler than documenting all the stuff to > write a random USB device driver. > Thanks for the feedback. If you cannot document the full USB infrastructure and add support for general customer written USB device drivers, then having something like the GK driver could still be useful in some cases, so I for one would look forward to seeing that. If you obtain management approval, do you have any ideas how long it would be before we see a GK type driver for USB ? Thanks for any information, Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: The Standard Oil Company of the 21st century ------------------------------ Date: Wed, 05 Jan 2005 14:26:49 -0500 From: Forrest Kenney Subject: Re: Writing drivers for USB devices ?, was: Re: What's the state of USB Message-ID: <41DC3F79.A4C934B9@hp.com> It would not ship until V8.3 if it gets approved, and I have time to do it for V8.3. There are two big if's there USB is only one part of my job. Forrest Simon Clubley wrote: > > In article <41DC30F5.C3E8CD38@hp.com>, Forrest Kenney writes: > > > > At the present time there are no plans to document the USB > > driver stack or provide a way to customers to write a USB device > > driver. It a choice between having time to actively develop and > > maintain the code base or get all the pieces into the kit and > > documentation developed. Right now adding USB 2.0 and fixing bugs have > > a higher priority. > > > > To fully document writing a USB device driver would require > > chapters for the HID support driver, the USB support driver, the driver > > interface to the USB Configuration manager process, and the HUB driver. > > > > What might happen is a driver for the USB space something like > > GK driver for SCSI. It would allow support of USB devices that are > > not part of the HID device class without writing a driver. You could > > easily control many USB device that way. I am working on a proposal > > for doing this at the present time and will present it to management > > for approval. No promises there is more USB stuff to work on than > > I have time to get done. Writing a and documenting a single generic > > USB driver would be much simpler than documenting all the stuff to > > write a random USB device driver. > > > > Thanks for the feedback. > > If you cannot document the full USB infrastructure and add support for > general customer written USB device drivers, then having something like > the GK driver could still be useful in some cases, so I for one would > look forward to seeing that. > > If you obtain management approval, do you have any ideas how long it would > be before we see a GK type driver for USB ? > > Thanks for any information, > > Simon. > > -- > Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP > Microsoft: The Standard Oil Company of the 21st century ------------------------------ Date: Wed, 5 Jan 2005 19:00:55 -0500 From: "John Smith" Subject: Re: Writing drivers for USB devices ?, was: Re: What's the state of USB 2. Message-ID: Forrest Kenney wrote: > At the present time there are no plans to document the USB > driver stack or provide a way to customers to write a USB device > driver. It a choice between having time to actively develop and > maintain the code base or get all the pieces into the kit and > documentation developed. Right now adding USB 2.0 and fixing bugs > have a higher priority. > > To fully document writing a USB device driver would require > chapters for the HID support driver, the USB support driver, the > driver interface to the USB Configuration manager process, and the > HUB driver. > > What might happen is a driver for the USB space something like > GK driver for SCSI. It would allow support of USB devices that are > not part of the HID device class without writing a driver. You could > easily control many USB device that way. I am working on a proposal > for doing this at the present time and will present it to management > for approval. No promises there is more USB stuff to work on than > I have time to get done. Writing a and documenting a single generic > USB driver would be much simpler than documenting all the stuff to > write a random USB device driver. That's what advertising and marketing does ...it increases sales and profits so VMS Engineering has money to hire additional staff to do these things since VMS is not open source. ------------------------------ Date: Wed, 05 Jan 2005 23:46:47 GMT From: "Joe H. Gallagher" Subject: WRUG Meeting - January 18, 2005 Message-ID: <41DC7C59.B8627E4A@ix.netcom.com> . Announcing January 18th Meeting Western Reserve Users Group (Northeast Ohio) Local User Group of Encompass (almost usual time and usual place) If you are going to attend the LUG meeting on January 18th, please RSVP to this message or to dtrwiz at ix dot netcom dat com We would like to get an estimate of the number who will attend so we can have the appropriate number of slices of pizza. Please RSVP before noon on the day of the meeting. Topic: Information Lifecycle Management Information Lifecycle Management (ILM) is all the rage these days. It's hard to find a storage vendor that is not touting their ILM strategy to the market. With all of the hype, one might think that ILM was a new concept, and that users had never been able to intelligently manage data in the past. Of course, that is not true; the concept of ILM has existed for years. One aspect of ILM, the ability to "tier" storage resources, where data is migrated to specific resources according to defined policies, is common in mainframe environments (HSM). This aspect of ILM has been practiced to a lesser extent in open systems environments; however, other ILM practices are common, even though they may not have been called "ILM solutions". Today, the term ILM covers a wide range of data analysis, management, migration, protection, and archiving processes. Today ILM implies a level of automation and end-to-end integration of processes that did not exist in the past. Ruth's talk will discuss what ILM is today and what HP has to offer in managing your data throughout its lifecycle -- specifically the newest solution, RISS, Reference Information Storage Systems. Speaker: Ruth Kalamasz, Agilysys< Solon, OH Ruth Kalamasz is a Strategic Technology Consultant with Agilysys (formerly Pioneer-Standard Electronics). She has been in the IT industry for over 20 years with the last 10 years concentrated on storage. Over the years, she has given talks at local and national DECUS (Encompass) events, and for various other organizations. She has worked with several vendors, Agilysys being a reseller, but also as a liason to the technical community where she has assisted with certification development for several vendor tests. Prior to working in technical pre-sales, Ruth was in Agilysys' IS department. Through the many aspects of her involvement in systems management, she had acquired practical experience which she still uses today when working with customers. Ruth is a past secretary and past chairperson of WRUG, the local user group of Encompass. Topic: HP Update Rich wiil review the Roadmaps and update us on Alpha (the last chip update), Integrity, VAX (what's going end of service life), and OpoemVMS (a new version will be out soon). Speaker: Rich Pearlman, HP, Pittsburgh, PA Rich Pearlman, a 27 year veteran with Digital Equipment, Compaq and now HP, is a Solutions Architect specializing in HP’s Business Critical Servers and Networked Storage Systems. Rich has spent most of this time delivering product and strategy presentations to a wide variety of audiences. Prior to working for HP, Rich spent 5 years doing systems programming at Carnegie Mellon University in an IBM mainframe environment. Rich holds a BS in Applied Mathematics and an MS in Information Science. Rich is the counterpart for the WRUG (Encompass LUG) and the NEORUG (Interex LUG). Other activities at the meeting: If someone volunteers to take over leadership of the LUG, there will be an election. Date: Tuesday, January 18, 2005 Time: 4:00 to 7:00 PM  Location: Park Center Plaza III Lower Level conference room 6050 Oak Tree Blvd. Independence, OH 44131 (Call Rich's cell phone at 412-999-6427 if you get lost) Map: See URL on the Web site Directions: From the area of the interchange of I-480 and I-77, go south and take the Rockside Road exit.  At the bottom of the ramp, turn right (west) on Rockside.  Go west two blocks (second light); turn left (south) on Oak Tree Blvd.   See the LUG's web page at http://eisner.decus.org/lugs/wrug/ Future LUG meetings are scheduled for: Currently, there are no future meetings planned or scheduled. See you January 18th. Joe H. Gallagher Former WRUG LUG Chair dtrwiz at ix dot netcom dot com ------------------------------ End of INFO-VAX 2005.011 ************************