1 INFO-VAX	Thu, 29 Jul 2004	Volume 2004 : Issue 416       Contents: Re: AlphaPC LX164 and VMS 7.3-2 ! Re: DVDwrite Version 4.0 released  Re: ES40 NIC's inactive state < Re: How to find libraries associated to message facilities ?< Re: How to find libraries associated to message facilities ?; http://www.bisexualplayground.com/welcome.php?r=jon_mary420 - Re: Is it decnet problem or Thruway problem ? ! Microsoft delays while HP dithers % Re: Microsoft delays while HP dithers % Re: Microsoft delays while HP dithers ) Re: OpenVMS Management Station -  HSZTERM  Preventing fragmentation.  Re: Preventing fragmentation.  Re: Preventing fragmentation.  Re: Preventing fragmentation.  Qt ready for OpenVMS Alpha.  Running VMS on a simulated VAX? # Re: Running VMS on a simulated VAX? # Re: Running VMS on a simulated VAX? # Re: Running VMS on a simulated VAX? ( Re: StorageWorks EVA to Windows Question Re: Supported Options 3 Re: Time to patch OpenVMS - DCE-RPC buffer overflow 3 Re: Time to patch OpenVMS - DCE-RPC buffer overflow 3 Re: Time to patch OpenVMS - DCE-RPC buffer overflow 3 Re: Time to patch OpenVMS - DCE-RPC buffer overflow 3 Re: Time to patch OpenVMS - DCE-RPC buffer overflow 3 Re: Time to patch OpenVMS - DCE-RPC buffer overflow 1 Re: Turn-key OpenVMS E-mail, web server solution? O Re: [TCPware, V73_MGMTAGENTS] Does anyone have a working installation running ?   F ----------------------------------------------------------------------  % Date: Wed, 28 Jul 2004 21:17:22 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>( Subject: Re: AlphaPC LX164 and VMS 7.3-2+ Message-ID: <41085E31.234EA6DC@comcast.net>    Tom Crabtree wrote:  >  > Bob: > F > It could run Unix, so in theory, it *should* be able to boot to VMS.  - Can you get hold of CD and try to boot it up?    D.J.D.   ------------------------------  % Date: Wed, 28 Jul 2004 20:55:17 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>* Subject: Re: DVDwrite Version 4.0 released+ Message-ID: <41085905.2BD937DA@comcast.net>    sms@antinode.org wrote:  > ; > From: David J (Just _must_waste everyone's time) Dachtera   G Y'know, I just mark some posts (even entire threads!) read and move on.    >  <djesys.nospam@comcast.net> > > / > > Machines use powers-of-two. Prove me wrong.  > 5 >    My machine has yours beat.  It uses powers of 3:  > ) >       alp $ write sys$output 3* 3* 3* 3 
 >       81  D Must be interesting calculating memory, storage, etc. capacities and+ such, pagelets sizes, page boundaries, etc.    > I >    I thought we were discussing prefixes like kilo, mega, and giga.  Do < > your machines use these?  How about pico, femto, and atto? > D >    You're a yocto-brain with far too much time to waste.  Prove me > wrong.   I think you just did.    D.J.D.   ------------------------------  % Date: Thu, 29 Jul 2004 01:49:20 +0800 , From: Paul Repacholi <prep@prep.synonet.com>& Subject: Re: ES40 NIC's inactive state0 Message-ID: <8765882fa7.fsf@k9.prep.synonet.com>  . jefflanka@volcanomail.com (Jeff Lanka) writes:  D >> You need the cards to be on independant segments or they will notE >> be inited with the correct Hware address. You need a decnet router  >> between them.  1 > The are on fully redundent independent segments    C >> Once other protocols start using the card, the address is pretty 2 >> well locked down, so you can't chop and change.  
 > Only DECnet   D And SCS, clustering? If so, when the system boots as part of initing@ the PEdriver etc, packets are sent out to discover other clusterF members.  If these come into the other Enet controller, it will not beD inited with the SCS/Decnet address. The segments must be independantB so packet on one can not be seen by the other. You can only have a router between them.  A With that config, you can have both online and active at the same  time.    --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------    Date: 28 Jul 2004 18:35:48 -0700# From: dooleys@snowy.net.au (dooley) E Subject: Re: How to find libraries associated to message facilities ? = Message-ID: <1ca82fc6.0407281735.67ce0e32@posting.google.com>   r macareux_joyeux@yahoo.fr (Denis Capart) wrote in message news:<40621c4f.0407280056.5840b862@posting.google.com>...H > One of our software generates warning and info messages with differentB > facilities but we can't determine which function call could have > generated these exceptions.  > < > The first one is "%MAT-I-PFMBSY" (page fault monitor busy)  From the maths run-time library?A > second one is "%CJATK-W-NOMSG, Message number <an hexa code>".   No idea    ------------------------------    Date: 28 Jul 2004 23:38:10 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) E Subject: Re: How to find libraries associated to message facilities ? 3 Message-ID: <cmOofK7b5av3@eisner.encompasserve.org>   c In article <1ca82fc6.0407281735.67ce0e32@posting.google.com>, dooleys@snowy.net.au (dooley) writes: t > macareux_joyeux@yahoo.fr (Denis Capart) wrote in message news:<40621c4f.0407280056.5840b862@posting.google.com>...I >> One of our software generates warning and info messages with different C >> facilities but we can't determine which function call could have  >> generated these exceptions. >>  = >> The first one is "%MAT-I-PFMBSY" (page fault monitor busy) " > From the maths run-time library?  # That seems an unlikely combination.   B >> second one is "%CJATK-W-NOMSG, Message number <an hexa code>". 	 > No idea   @ If it seems illogical for a particular message to appear in someA context then it is quite likely just binary garbage which happens % to translate to the code in question.    ------------------------------  # Date: Wed, 28 Jul 2004 18:43:22 GMT  From: "Me" <Me@here.org>D Subject: http://www.bisexualplayground.com/welcome.php?r=jon_mary4206 Message-ID: <etSNc.56986$fv.38898@fe2.columbus.rr.com>  =   http://www.bisexualplayground.com/welcome.php?r=jon_mary420          Copy and paste to browser           Cum join us    ------------------------------  + Date: Wed, 28 Jul 2004 21:51:09 +0000 (UTC) 6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)6 Subject: Re: Is it decnet problem or Thruway problem ?1 Message-ID: <newscache$ql0l1i$12p1$1@news.sil.at>   t In article <908a2e17.0407280214.41287a24@posting.google.com>, jignesh_vyas@hotmail.com (Jignesh Vyas 'Jigs') writes:D >I have defined two decnet proxy on remote note and tried to performE >thruway connect, on SYADM account it went fine but on POPR_x account  >it login failure error..  >  >Any clue ?   C Could it be that the one proxy has /DEFAULT and the other has not ?    --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  % Date: Wed, 28 Jul 2004 16:59:18 -0400 # From: "John Smith" <a@nonymous.com> * Subject: Microsoft delays while HP dithers, Message-ID: <DeadnS_YNOA7jpXcRVn-qQ@igs.net>  L http://story.news.yahoo.com/news?tmpl=story&ncid=1208&e=10&u=/cmp/20040728/t c_cmp/26100237&sid=95573650   ' Microsoft Delays Three Windows Upgrades    Tue Jul 27, 4:00 PM ET  K Microsoft has fallen behind schedule with the development of three upgrades I to Windows and is pushing back the timetable for delivering the software,  the company disclosed Tuesday.  @ Windows Server 2003 Service Pack 1, which had been scheduled forG availability later this year, is now slated for the first half of 2005. F Likewise, 64-bit "extended system" versions of Windows Server 2003 andH Windows XP (news - web sites) are being bumped to the first half of next
 year, too.  I Windows Server 2003 SP1 is intended to improve the security, reliability, @ and performance of Microsoft's flagship server operating system.  I Windows Server 2003 for 64-bit Extended Systems and Windows XP for 64-bit L Extended Systems are designed to work on computers powered by new chips fromJ Intel and Advanced Micro Devices Inc. that have the flexibility to process  in both 32-bit and 64-bit modes.  L A Microsoft spokeswoman, in an E-mail message, did not give a reason for the delay.   -----------------   G As a competitive response HP should offer Oracle or even Sybase ASE (if J carly(tm) goes down (on one knee) and makes nice with John Chen of Sybase)H as a packaged OpenVMS system, along with webserver, e-mail server, and a groupware tool.   L Throw in a few copies of the book "Don't Worry,  Be Happy - Run OpenVMS" (to
 be authored).    ------------------------------  % Date: Wed, 28 Jul 2004 19:44:44 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> . Subject: Re: Microsoft delays while HP dithers, Message-ID: <41083A6B.B241AA30@teksavvy.com>   John Smith wrote: M > Microsoft has fallen behind schedule with the development of three upgrades K > to Windows and is pushing back the timetable for delivering the software,   > the company disclosed Tuesday.  J You forgot to include the delay for the Virtual PC product which Microsoft1 purchased. (it is the Widnows emulator on MACs).    L However, there is only really one delay: the XP patch.  The other 2 productsJ depend on it, so as long as it isn't released, the other products can't be released either.  L What percentage of wintel machines run XP versus older versions of Windows ?L The problem of viri won't be solved just because Microsoft issues some patchN that applies only to one version, especiallty if a sizeable number of machineaB are running older versions that are still as vulnerable as before.   ------------------------------   Date: 29 Jul 2004 00:54:44 GMT From: healyzh@aracnet.com . Subject: Re: Microsoft delays while HP dithers+ Message-ID: <ce9hsk0ebq@enews1.newsguy.com>   . JF Mezei <jfmezei.spamnot@teksavvy.com> wrote:L > You forgot to include the delay for the Virtual PC product which Microsoft3 > purchased. (it is the Widnows emulator on MACs).    H Don't remind me, I have a G5 2x2, which means I have to wait for the new version to be able to run VPC.  N > However, there is only really one delay: the XP patch.  The other 2 productsL > depend on it, so as long as it isn't released, the other products can't be > released either.  I As far as can tell XP SP2 is just an excuse not to let the new version of K VPC out the door.  Previous versions will still run on VPC.  MS Claims it's 6 waiting as it wants to ship a more secure OS with VPC.   		Zane   ------------------------------  % Date: Wed, 28 Jul 2004 20:47:24 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>2 Subject: Re: OpenVMS Management Station -  HSZTERM+ Message-ID: <4108572C.96AC6A53@comcast.net>    Dirk Munk wrote: >  > David J Dachtera wrote:  > > Dave Baxter wrote: > > i > >>David J Dachtera <djesys.nospam@comcast.net> wrote in message news:<40FDCAB0.9F6BD4BF@comcast.net>...  > >>L > >>>No, However, it is no longer supported. It never did ship with OpenVMS. > >>> $ > >>>You can find a kit for it here: > >>> ( > >>>http://www.djesys.com/freeware/vms/3 > >>>http://www.djesys.com/freeware/vms/hszterm.zip  > >>> E > >>>However, I do not assume *ANY* responsibility for the product or L > >>>anyone's use of it. I just have the kit available for folks who want toJ > >>>try to use it. It is not supported by OpenVMS Engineering, hp Storage) > >>>Engineering or anyone else. Y.O.Y.O.  > >>>  > >>>D.J.D.  > >>P > Not only is it not supported, but AFAIK you are strongly discouraged to use itH > by OpenVMS engineering, since using it may result in data corruption !  B Careful there! See my response to Ken Fairfield in another thread.  G The issue is not HSZTERM$SCSIPAD, per se. The issue is using one of the F disk units as the communication channel instead of the virtual consoleH unit. Early HSZs and HSZ firmware did not provide a virtual console LUN;+ so, the only choice you had was a disk LUN.   F Current versions of HSZ and HSG firmware provide for a virtual consoleC LUN. HSG80 firmware V8.7-7 limits non-disk-I/O communication to the # virtual console LUN ($1$GGAxxxxx:).   H For what it may be worth, I've worked a number of sites that use HSZTERMB in batch jobs to split mirror-sets nightly - with no issues. ThoseH procedures are still running today (some are getting to be six and seven years old!).   D.J.D.   ------------------------------    Date: 28 Jul 2004 14:38:43 -0700 From: rf_vms@earthlink.net (RF) " Subject: Preventing fragmentation.= Message-ID: <9e8c2604.0407281338.5ef835c6@posting.google.com>   ; After a recent BACKUP/RESTORE, which resulted in a DFU File E fragmentation index of 0.00 (yea, down from 8+), it took less than 36 A hours for that index to fall (rise?) to ~4.8.  This is due to the D 1000s of files, both permanent and temporary, that are created dailyE during normal data processing.  It seems to me that there may be some F system setting that could help prevent or reduce this fragmentation byE "encouraging" the system to write files in a more contiguous manner.  E I'm not looking to maintain an index of excellent only to improve the D index.  I'm sure that running a defrag such as DFU will be suggestedC and I'm already doing that, but I'd like to find something that was  proactive rather than reactive.  Vitals: % Alpha OpenVMS V6.2 on DEC 3000 - M700 	 DFU v2.7a  ODS2 volume, ~37gb9 Disk init:  $init/header=2000000 /maximum=2000000 my$disk    TIA, RFITCH  Long time, not so hot, VMS user.   ------------------------------  % Date: Wed, 28 Jul 2004 15:28:38 -0700 + From: "Barry Treahy, Jr." <Treahy@MMaz.com> & Subject: Re: Preventing fragmentation.' Message-ID: <41082896.2010204@MMaz.com>   	 RF wrote:   < >After a recent BACKUP/RESTORE, which resulted in a DFU FileF >fragmentation index of 0.00 (yea, down from 8+), it took less than 36B >hours for that index to fall (rise?) to ~4.8.  This is due to theE >1000s of files, both permanent and temporary, that are created daily F >during normal data processing.  It seems to me that there may be someG >system setting that could help prevent or reduce this fragmentation by F >"encouraging" the system to write files in a more contiguous manner. F >I'm not looking to maintain an index of excellent only to improve theE >index.  I'm sure that running a defrag such as DFU will be suggested D >and I'm already doing that, but I'd like to find something that was  >proactive rather than reactive. >Vitals:& >Alpha OpenVMS V6.2 on DEC 3000 - M700
 >DFU v2.7a >ODS2 volume, ~37gb : >Disk init:  $init/header=2000000 /maximum=2000000 my$disk >    >   I You've already answered your question, your apps create and delete files  I all day.  You never identified your app, and doing so might help, but if  F you have this many 'scratch' type files daily, why don't you just put I them on their own disk and delete the contents or just reinit it nightly   or on weekends?   E Of the permanent files, if they were not dealing with expanding on a  G disk that has zillions of temporary files coming and going, that could  H help a lot but also, depending on the file structure of these permanent D files, you could consider preallocating to a large size to minimize H their need to expand and alter the users RMS extent values so that when - an extent is necessary, it is a larger chunk.   D A more basic question, however...  Are you experiencing performance @ problems that you can clearly document are being improved on by E defraging your system, or are you just creating unnecessary work for  	 yourself?    Barry    --    > Barry Treahy, Jr                       E-mail: Treahy@MMaz.com> Midwest Microwave                          Phone: 480/314-1320> Vice President & CIO                         FAX: 480/661-7028                            ------------------------------  % Date: Wed, 28 Jul 2004 19:52:34 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> & Subject: Re: Preventing fragmentation., Message-ID: <41083C40.C94F3BE0@teksavvy.com>  	 RF wrote: F > 1000s of files, both permanent and temporary, that are created dailyG > during normal data processing.  It seems to me that there may be some E > system setting that could help prevent or reduce this fragmentation   K There are way to ask the system to create indexed files in certain areas of K the disk. But generally, you let the system decide where a file is created. N Also, there are optiosn in file creation (either in FDL or as arguments to theF open calls) that require best-try-contiguous, or even contiguous only.  B What percentage of the drive is free ? Is the drive fairly full ?   I You may also want to look at the order in which the files are created and K whether files grow over the day, or if they get populated in one shot (then  move on to the next file).  N In the first case, you should pre-allocate space for the file (in arguments toM the fopen() call, or with FDL) so that even though initially it may be small, L it will already have its one big chunk fo contuguous space allocated for the& data it will get during the whole day.  I There are also RMS parameters you ca set that affect the whole system and F although i am not sure, you might be able to specify a minimum defaultN allocation for files (someone can confirm or deny this) and this might make it? easier for you sicne you wouldn't have to change applications).    ------------------------------  % Date: Wed, 28 Jul 2004 21:31:27 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>& Subject: Re: Preventing fragmentation.+ Message-ID: <4108617F.B81AB01B@comcast.net>    "Barry Treahy, Jr." wrote: >  > RF wrote:  > > > >After a recent BACKUP/RESTORE, which resulted in a DFU FileH > >fragmentation index of 0.00 (yea, down from 8+), it took less than 36D > >hours for that index to fall (rise?) to ~4.8.  This is due to theG > >1000s of files, both permanent and temporary, that are created daily H > >during normal data processing.  It seems to me that there may be someI > >system setting that could help prevent or reduce this fragmentation by G > >"encouraging" the system to write files in a more contiguous manner. H > >I'm not looking to maintain an index of excellent only to improve theG > >index.  I'm sure that running a defrag such as DFU will be suggested F > >and I'm already doing that, but I'd like to find something that was" > >proactive rather than reactive.
 > >Vitals:( > >Alpha OpenVMS V6.2 on DEC 3000 - M700 > >DFU v2.7a > >ODS2 volume, ~37gb < > >Disk init:  $init/header=2000000 /maximum=2000000 my$disk > >  > >  > J > You've already answered your question, your apps create and delete filesJ > all day.  You never identified your app, and doing so might help, but ifG > you have this many 'scratch' type files daily, why don't you just put J > them on their own disk and delete the contents or just reinit it nightly > or on weekends?  >  > [snip] > E > A more basic question, however...  Are you experiencing performance A > problems that you can clearly document are being improved on by F > defraging your system, or are you just creating unnecessary work for > yourself?   G Gotta vote with Barry on this one. Is this a performance issue? If not, G best not to chase after it. You're just spinning your wheels and making C work for yourself (o.k. if you can justify it to the boss, but...).   D Do you know the maximum scratch file size? You could try setting theG volume's /EXTENSION quantity to some multiple of the clustersize larger H than the maximum filesize. I typically use the square of the clustersize. as the /EXTENSION quantity on scratch volumes.  D Then again, if the issue is freespace fragmentation, I don't know asB there is a good strategy short of running an on-line defrag. tool.    ...if it *IS* a genuine issue...   D.J.D.   ------------------------------    Date: 28 Jul 2004 22:02:31 -0700  From: avs@ntmk.ru (Andrey Savin)$ Subject: Qt ready for OpenVMS Alpha.= Message-ID: <1e9bf32b.0407282102.16ba10ce@posting.google.com>   ; I'm done make the port Qt-free-3.2.1 (including libs Expat, % Fontconfig, Freetype2, Xtf, Xrender). E I compiled with Compaq C V6.5-001 and Compaq C V6.5-004 OpenVMS Alpha  V7.3-1.    ------------------------------  % Date: Wed, 28 Jul 2004 17:23:38 -0400 3 From: Undisclosed <nomail@dontbeaweaselspammer.com> ( Subject: Running VMS on a simulated VAX?0 Message-ID: <OomdnUlFAI_8hJXcRVn-vA@comcast.com>   what's the deal on this?  G just get SIMH, put it on my Linux box, apply to Encompass, pay $30 for  < the VAX CD's, then run OpenVMS on my nice new simulated VAX?   that simple?   ------------------------------  + Date: Wed, 28 Jul 2004 21:46:58 +0000 (UTC) % From: Dan Foster <usenet@evilphb.org> , Subject: Re: Running VMS on a simulated VAX?6 Message-ID: <slrncgg7o6.m1k.usenet@gaia.roc2.gblx.net>  e In article <OomdnUlFAI_8hJXcRVn-vA@comcast.com>, Undisclosed <nomail@dontbeaweaselspammer.com> wrote:  > what's the deal on this? > I > just get SIMH, put it on my Linux box, apply to Encompass, pay $30 for  > > the VAX CD's, then run OpenVMS on my nice new simulated VAX? >  > that simple?  & Yup. I've done just that. Works great.  F You can even avoid the $30 charge if you know someone who will let youB copy an ISO image (or mail you a CD) once you can demonstrate that you're an Encompasserve member.   G You only really need a single Encompasserve-produced VAX CD which comes B with the OS and popular layered products, although the ConDist (orC whatever it's named now) is nice to have, too, but harder to easily  obtain.    -Dan   ------------------------------  + Date: Thu, 29 Jul 2004 04:05:07 +0000 (UTC) % From: Dan Foster <usenet@evilphb.org> , Subject: Re: Running VMS on a simulated VAX?6 Message-ID: <slrncggtt8.m1k.usenet@gaia.roc2.gblx.net>  _ In article <41085F49.90E0C9DA@comcast.net>, David J Dachtera <djesys.nospam@comcast.net> wrote:  > ! > OVMS CDs are ODS, not ISO-9660.   4 Ah, yes, right you are. A slip of the mind / tongue.  H At least one PC-based CD burning software strenously objected to burningF an ODS-2 based image to CD, so had to use cdrecord under Linux to burnG my CD. Epitome of silliness, but that were the machinations required to  get the VMS machines installed.    -Dan   ------------------------------  % Date: Thu, 29 Jul 2004 01:03:30 -0400 3 From: Undisclosed <nomail@dontbeaweaselspammer.com> , Subject: Re: Running VMS on a simulated VAX?0 Message-ID: <j8Gdna90sbS1GJXcRVn-pQ@comcast.com>   Dan Foster wrote:   a > In article <41085F49.90E0C9DA@comcast.net>, David J Dachtera <djesys.nospam@comcast.net> wrote:  > ! >>OVMS CDs are ODS, not ISO-9660.  >  > 6 > Ah, yes, right you are. A slip of the mind / tongue. > J > At least one PC-based CD burning software strenously objected to burningH > an ODS-2 based image to CD, so had to use cdrecord under Linux to burnI > my CD. Epitome of silliness, but that were the machinations required to ! > get the VMS machines installed.  >  > -Dan  L I wonder if the exact CD copy style software under Windows could handle ODS.  B not much point in trying that when you can just use cdrecord or a  frontend, though.    ------------------------------  % Date: Wed, 28 Jul 2004 21:16:10 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>1 Subject: Re: StorageWorks EVA to Windows Question + Message-ID: <41085DEA.A257A62A@comcast.net>    Hal Kuff wrote:  > M > Rather than run Securepath per se, we're intertested in using a rack switch N > (maxann, San valley?) to present EVA storage to the Windows boxes... that isM > to say present 1TB of raw storage to the fibre channel switch and have that I > small switch with its internal 8 port swicth present the storage to the = > individual Windows boxes... anyone doing this? Or know how?   A Well, not me or my site, but I'll be watching to see what kind of D answers you get. I'm trying to bone up on SAN stuff due to issues at* work right now (don't ask - I won't tell).   D.J.D>   ------------------------------  # Date: Wed, 28 Jul 2004 21:46:03 GMT  From: dittman@dittman.net  Subject: Re: Supported Options3 Message-ID: <v8VNc.234$i_.128@nwrddc04.gnilink.net>   - Paul Repacholi <prep@prep.synonet.com> wrote: 3 > ghazan@ghazan.haider.name (Ghazan Haider) writes:  > B >> Just for the record (to help someone else googling for this), I! >> tried the Adaptec 29160 today.  > D >> SRM=5.8 machine=164lx. Tried adaptec 29160 and 2940uw. Both didntG >> work... ie show dev didnt show anything beside the floppy device and D >> show config|more in the PCI didnt seem to show a boot config like >> dqa0.xxx etc. > E > A 39160 *may* work. What model is your machine? A Qlogic ISP1040 is 2 > a good pick, they where a standard card pre EV6.  D Didn't the 39160 support come after the 164LX firmware was no longer updated? --   Eric Dittman dittman@dittman.net    ------------------------------  % Date: Wed, 28 Jul 2004 16:11:49 -0400 3 From: Undisclosed <nomail@dontbeaweaselspammer.com> < Subject: Re: Time to patch OpenVMS - DCE-RPC buffer overflow0 Message-ID: <jICdnTWrcJUWlZXcRVn-jQ@comcast.com>   Craig A. Berry wrote:    >> >>@Stake advisory sez -  >>H >>"A buffer overflow vulnerability was discovered in HP's implementationD >>of the DCE endpoint mapper (epmap) which listens by default on TCPD >>port 135.  Successful exploitation of this vulnerability may allowB >>an attacker to execute arbitrary commands on the targeted systemC >>with the privileges of the DCED process which is typically run as  >>the root user."  >  > J > This appears to be from the report to the vendor regarding HP-UX, which I > it turns out was already fixed before the report.  "HP's implementation E > of the DCE endpoint mapper (epmap)" almost certainly refers to the  G > HP-UX implementation.  When the report says, "vendor noted that this  G > issue effected [sic] other dced implementations," that's got to be a  D > reference to their doing due diligence with Tru64 and OpenVMS and G > discovering that they too, were susceptible to buffer overflow using  I > the same exploit, though no claim is made about what an attacker could  J > achieve.  Tru64 and OpenVMS very likely share a DCE implementation, but I > almost certainly have no common code in this area with HP-UX.  For one  C > thing, one of the affected versions of OpenVMS is 7.3, which was  . > released before the merger of HP and Compaq. > I > The @Stake folks or their vendor contact have clearly oversimplified a  H > pair of similar vulnerabilities.  It's quite common for exploits that J > yield root access on other systems to have only DOS impact on OpenVMS.  G > Until I see an explicit claim from a reliable source about impact on  G > OpenVMS, I'll reserve judgement, though the OpenVMS dced is run as a  G > detached process with some serious privileges, and crashing it could  J > (possibly) have a serious impact.  Obviously the thing to do is install I > the patch and worry later about the extent of the vulnerability you no   > longer have.  D actually, I can say now that it's not known, at least by the author.  F I read a post on a security list by the guy who found the vuln saying D that said he didn't have access to any OpenVMS system to test it on.  A hence the "may" bit re: OpenVMS he included in his original post.    ------------------------------  % Date: Wed, 28 Jul 2004 16:53:45 -0400 3 From: Undisclosed <nomail@dontbeaweaselspammer.com> < Subject: Re: Time to patch OpenVMS - DCE-RPC buffer overflow0 Message-ID: <aq6dnQq-itr9j5XcRVn-vQ@comcast.com>   Nic Clews wrote:   > Undisclosed wrote: > F >> http://www4.itrc.hp.com/service/cki/docDisplay.do?docId=HPSBOV01056 >>@ >> http://www.atstake.com/research/advisories/2004/a072204-1.txt >>A >> patch here - http://www2.itrc.hp.com/service/patch/mainPage.do  >> >> --- >>< >> hmm... seems that OVMS is NOT immune to buffer overflows. >>I >> I'll be interested in reading the Nessus NASL script to check for the  % >> vuln when it comes out in 30 days.  >>> >> damn DCE-RPC... that's the bane of Windows systems as well. >>8 >> is the DCED installed as system or kernel on OpenVMS? >  > + > That is the key, only if it is installed.  > H > As a reference to buffer overflows, work is taking place, not just in D > VMS I hasten to add, but basically if you've knowledge of the way E > program sections work, and you mark them as data areas, writeable,  H > executable or non executable (etc.), that is what is being applied to I > the stacks where buffer overflows target, i.e. that stack area outside  7 > the used (legal) area of the stack is not executable.  > E > As to VMS, the real issue here is that you end up with an imported  F > vulnerability (if XYZ is used/installed), you're vulnerable if that G > system is in such an area someone can use that attack, but the other  G > issue which applies, is that VMS is very fussy when it comes to code  I > integrity, and more often than not either the active process will fail  D > (most common) or, well to be honest I've never seen it bugcheck a B > system, but, if you know different, then post here, and include J > references ["my friend has heard that.." or "I think there's a cover-up  > over..." is not valid here]. > I > If you've generally followed other discussions about protection modes,  E > but also understood how VMS deals with data integrity (and program  A > integrity), you should have vague understanding that, actually  J > manipulating the stack execution to perform some task or other which, I G > honestly think you've of the opinion can "burst the bubble" of VMS's  K > reputation, you're taking on what can only be described as a non trivial  J > task. Most people tend to lose interest (and effort) in even attempting J > to understand the normal running operation, turning that into an attack J > which can penetrate a system whilst remaining covert is in a completely  > different league.  > I > We'll take your reason to remain anonymous as a cautious indication of  F > your inexperience with OpenVMS. Posting to this newsgroup trying to G > imply that every single installation now requires an immediate patch  E > won't do anything to earn respect, let alone be any measure of the   > reality of the situation.  > K > HP have made the appropriate notifications, we have already done what we  I > need to do with respect to our client base, I quite expect others have  C > been appropriately informed and taken appropriate actions, where  I > necessary, but, just in case you're wondering, no, we don't lose sleep  @ > over it, and hopefully I've given you a little hint as to why. >   E I think you're under some misapprehensions. Maybe I'm giving off the   wrong impression.   I as for the "EVERYONE PATCH OVMS" idea, I am not trying to give that idea  B off, I am just posting information that I thought people might be F interested in or want a heads-up on. I post vuln information on other J general IT lists when it comes up, albeit that I'm using a different name.  I the average IT'er does not read vuln mailing lists, I have no experience  8 with OpenVMS people to know what the procedure is there.  H my post was not written in a chicken little "sky is falling" mode. it's 2 "time to patch OVMS", not "PATCH NOW NOW NOW~!!!!"  F I assume that anyone with enough credentials to man a OVMS box is not G going to simply patch a box with uptime measured in years based on the  H words of a pseudo-anonymous clearly OVMS newbie on the Net... they will E evaluate things, look at the data HP is providing about it, and make   their own decisions.  I I don't patch things on my small private network without doing that, for  & instance. That's just IT common sense.  E you make references to AMD-NX/W^X/PaX/non-exec stack style work... I   know about this stuff.  F minor technical quibble, you also call it a stack overflow... well, I E don't have access to the HP page, but nothing in the @Stake advisory  F tells me that it's a stack overflow, at least that I saw. It could be  any number of other overflows.  ( as to me being out to "break OpenVMS"...  H first, I know jack about OVMS at this point, and I will be the first to J admit it. I'm trying to learn. Right now I'm fiddling around learning DCL.  I second, while I am definitely interested in learning about VMS security,  H I am also interested about learning the system and it's architecture as ? a whole. Security is just how I learn about most systems in IT.e  D third, I'm not much of a vulnerability finder. What I know about it H mostly derives from me being a practical paranoid and wanting to really 6 know the security degree of the programs I am running.  @ as for my pseudonymity, I don't get or want e-mail from Usenet, I especially with all the spambots out there, so I see no reason to use my rF mailing address, I discuss things on the appropriate group. nice spam  redirection trick, BTW.e  G I personally know nobody on this list, and nobody knows me, so my name n is mostly irrelevant.g  F no offense, but I have no idea who Nic Clewes is, and for all intents F and purposes you are pseudonymous to me, as most people on Usenet are.  G I'm not trying to piss anyone off here, or order anyone around and act   like I'm Mr. Know it All.t  - I'm just passing on info and trying to learn.n   ------------------------------  # Date: Wed, 28 Jul 2004 22:15:08 GMTf, From: Wayne Morrison <Wayne.Morrison@hp.com>< Subject: Re: Time to patch OpenVMS - DCE-RPC buffer overflow2 Message-ID: <MzVNc.6770$AU3.2931@news.cpqcorp.net>  G Although I no longer work on OpenVMS DCE, I did get involved with this aH advisory.  Here are answers to some of the questions/concerns raised in  this thread:  F DCE RPC ships as part of the base operating system.  The full DCE kit F ships as a layered product, with separate licenses for the additional  pieces.-  C DCE on OpenVMS is a direct port of the Open Group's reference code jL (R1.2.2), so it does share much of it's code with other DCE implementations.  I The @Stake advisory was for DCE on HP/UX.  The endpoint mapper mentioned  E in that advisory also exists in the OpenVMS implementation.  This is  F where the vulnerability occurs.  On OpenVMS, the endpoint mapper runs B under a special DCE identity, not the "root" listed in the @Stake C advisory.  DCE$SERVER has a couple of elevated privileges, but the e1 account is set up to prevent unauthorized access.c  E Although DCE RPC is vulnerable to the buffer overflow on OpenVMS, it _H does not allow a user to acquire special privileges nor does it allow a A system crash or corruption.  All that can happen on OpenVMS is a >H potential denial of service to some DCE RPC applications, by causing an E ACCVIO in the DCE endpoint mapper.  A simple restart of the endpoint $H mapper will resolve the problem, unless the denial of service attack is  ongoing.  E HP recommends that everyone install the patch, although only systems  E that use full DCE or DCE RPC (via applications like DCOM, the remote  D debugger, locally developed RPC apps, etc.) are candidates to see a  problem with the vulnerability.t        Wayne Morrison 3      CDSA/Secure Delivery & Kerberos Project Leader.      OpenVMS Engineering   ------------------------------  % Date: Wed, 28 Jul 2004 21:12:43 -0500r2 From: David J Dachtera <djesys.nospam@comcast.net>< Subject: Re: Time to patch OpenVMS - DCE-RPC buffer overflow+ Message-ID: <41085D1A.FC76DFAD@comcast.net>:   Undisclosed wrote: >  > David J Dachtera wrote:t > @ > > ITRC is "login required"; so, I can't explore that just now. > > > > > Anyway VMS *IS* immune to *ALL* buffer-overflow attacks... > >pL > > ...until you startup a network stack, and then the vulnerability lies inC > > the network stack and/or related facilities/utilities, not VMS.  > H > ObClintonianRemark "I guess it depends on how you define VMS". I don't' > know what the official definition is.t  H For our purposes, VMS runs quite happily without a network stack loaded.= So, that's how *I* think of it. If you add a layered product, 6 application, etc. and it breaks something, guess what?  C An understanding of the system startup process might useful at thisi point. o  H It is also interesing to note that the startup procedure on the bootableG VMS CD is really just a severely abbreviated STARTUP.COM that does only0? what is necessary to perform certian very basic functions, like E INITIALIZE-ing and MOUNTing disks and tapes, running BACKUP and PCSI,pF and so on. It never does enable interactive logins - the entire systemG is run under control of some special DCL scripts. The option to execute-G DCL commands and scripts runs as a subprocess of the "startup" process.n No network stack, ...u  J > technically, only the Linux kernel is "Linux", but people generally callJ > the core GNU software required to have a usable operating system + Linux > Kernel "Linux" as well.   C Common misnomer. Similarly, neither DCL nor the command programs it H invokes are "VMS" - they are part of the operating environment, but they are not "VMS".  J > I figured the DCE-RPC bit was included with OVMS, since it sez it's HP's > software.  > K > > So - time to clarify: are talking UCX (nka "TCP/IP Services"), Multineti, > > or TCPWare? ...which element(s) thereof? > >m
 > > D.J.D. >  > @Stake advisory sez -- > H > "A buffer overflow vulnerability was discovered in HP's implementationD > of the DCE endpoint mapper (epmap) which listens by default on TCP > port 135.   D There's your primary clue right there. On VMS, the TCP/IP stack is aD "System Integrated Product" (or is it a "layered Product"?). So, theE addition of TCP/IP to a system that can live very well without it (inaF isolation, of course) is what brings abgout the source of the topic of discussion.O  9 > Successful exploitation of this vulnerability may allowiB > an attacker to execute arbitrary commands on the targeted systemC > with the privileges of the DCED process which is typically run as  > the root user."g  D ...except that VMS has a somewhat different structure as compared to UN*X.i  & > that's a daemon running over TCP/IP.  G In VMS-ish, a detached process (i.e., not "VMS"). In VMS's case, shouldlA the image exit, the detached process will likely die, denying the ( would-be exploiter access to the system.  J > I assume the TCP/IP stack implimentation does not matter, since the vuln > is at application levels.4   I'll buy that.  F > it says "HP implimentation of DCE endpoint mapper", so you know what > software is at fault.g > 7 > what's confusing me is the mention of "root", though.w > I > I know there's no root in OVMS, so does the software run with System or  > Kernel level priviledges?u   Depends.  # > if not, then it's less important.2  @ ...but still worthy of note. Sites sensitive to such issues will@ probably want to test to see the exact reuslt in their system of attempting such an exploit.c   D.J.D.   ------------------------------  + Date: Thu, 29 Jul 2004 04:15:41 +0000 (UTC).% From: Dan Foster <usenet@evilphb.org> < Subject: Re: Time to patch OpenVMS - DCE-RPC buffer overflow6 Message-ID: <slrncgguh1.m1k.usenet@gaia.roc2.gblx.net>  _ In article <41085D1A.FC76DFAD@comcast.net>, David J Dachtera <djesys.nospam@comcast.net> wrote:  >bF >> technically, only the Linux kernel is "Linux", but people generallyH >> call the core GNU software required to have a usable operating system" >> + Linux Kernel "Linux" as well. >RE > Common misnomer. Similarly, neither DCL nor the command programs it-E > invokes are "VMS" - they are part of the operating environment, butt > they are not "VMS".u  H If explaining DCL to someone from an UNIX/UNIX-like background, the bestA way to illustrate DCL in a VMS context is to describe it as being&? conceptually and functionally similar to a UNIX shell ('command  interpreter' in VMS-speak).   H That's probably the easiest way to illustrate the command interpreter isC a part of the general operating environment, yet doesn't define them operating system itself.   -Dan   ------------------------------  % Date: Thu, 29 Jul 2004 01:00:41 -0400h3 From: Undisclosed <nomail@dontbeaweaselspammer.com>e< Subject: Re: Time to patch OpenVMS - DCE-RPC buffer overflow0 Message-ID: <j8Gdnax0sbQdGZXcRVn-pQ@comcast.com>   David J Dachtera wrote:w  J > For our purposes, VMS runs quite happily without a network stack loaded.? > So, that's how *I* think of it. If you add a layered product, 8 > application, etc. and it breaks something, guess what?   ahhh.   G I guess that's just a Unix/Windows-ism on my part, assuming the TCP/IP  $ stack is integrated with the kernel.  E > An understanding of the system startup process might useful at thisI	 > point. v > J > It is also interesing to note that the startup procedure on the bootableI > VMS CD is really just a severely abbreviated STARTUP.COM that does only-A > what is necessary to perform certian very basic functions, likeeG > INITIALIZE-ing and MOUNTing disks and tapes, running BACKUP and PCSI,eH > and so on. It never does enable interactive logins - the entire systemI > is run under control of some special DCL scripts. The option to executeeI > DCL commands and scripts runs as a subprocess of the "startup" process.- > No network stack, ...     E > Common misnomer. Similarly, neither DCL nor the command programs itsJ > invokes are "VMS" - they are part of the operating environment, but they > are not "VMS".   ok.o  F see, some people define the entire base package of the *BSD's, shell, D basic userland, and everything up to but not including X11, as "the I operating system", since they were designed to work together and provide   basic functionality.  F in the post below this, Dan Foster used the analogy of DCL being like C the user shell in Unix... well, while the shell is not part of the e9 kernel, it is considered part of the OS under the *BSD's.a  - so, VMS uses more of a minimalist definition.a    F > ...except that VMS has a somewhat different structure as compared to > UN*X.r >  > & >>that's a daemon running over TCP/IP. >  > I > In VMS-ish, a detached process (i.e., not "VMS"). In VMS's case, should C > the image exit, the detached process will likely die, denying theo* > would-be exploiter access to the system.   interesting.  B > ...but still worthy of note. Sites sensitive to such issues willB > probably want to test to see the exact reuslt in their system of > attempting such an exploit.m >  > D.J.D.   definitely.o  
 thanks David.r   I've got some reading to do.  ? incidental question - why does DCL not do tab-completion style tF completion? I would have thought it would have been a perfect fit for I VMS, given that command names are longer than Unix.. that's great from a  E newbie scrutability standpoint, but it gets annoying when you try to r type things fast.   I I know that typing abbreviations works (e.g. DIR for DIRECTORY), but I'd eI like to be sure that what I'm about to hit "Enter" on is the right thing.r   ------------------------------  + Date: Wed, 28 Jul 2004 22:50:37 +0000 (UTC)i6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER): Subject: Re: Turn-key OpenVMS E-mail, web server solution?1 Message-ID: <newscache$9c3l1i$f8p1$1@news.sil.at>e  t In article <410228d5$0$7120$db0fefd9@news.zen.co.uk>, "Alex Daniels" <AlexNOSPAMTHANKSDaniels@themail.co.uk> writes:M >OpenVMS 8.2 will be available for VAX. It has been long documented that dashr( >releases will not be available for VAX.  I Yup. But OTOH who else sees V7.3-1 and V7.3-2 as wronlgy named releases ?   / >TCP/IP Services 5.5 will be available for VAX.I  * Are you sure ? Where is V5.4 for the VAX ?   -- f Peter "EPLAN" LANGSTOEGER>% Network and OpenVMS system specialist/ E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  + Date: Wed, 28 Jul 2004 22:09:44 +0000 (UTC)t6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)X Subject: Re: [TCPware, V73_MGMTAGENTS] Does anyone have a working installation running ?1 Message-ID: <newscache$pg1l1i$84p1$1@news.sil.at>t  Z In article <2mpco6Fpp73pU1@uni-berlin.de>, "Martin Vorlaender" <mv@pdv-systeme.de> writes:$ >I started a little upgrade orgy ;-)  
 Well done ;-)   = >Now updated with all current ECOs. Especially SNMPD_V562P030 & >(as listed on the requirements page).   Got it. Since 10-Mar-2003   E >Same here. On the summary page: contact information and location allnC >show "N/A". The WBEM logfiles and the TCPware SNMP log files don't;: >show errors. I'll try to get that information by snmpget.  - What summary page ? https://localhost:2381/ ?u  D I found a warning in SYS$SPECIFIC:[WBEM.AGENTS.LOGS]CPQTHRESHOLD.LOGt 28-JUL-2004 08:34:42.75 WARNING CPQTHRESHOLDMGMT_PERSIST.C line 368: error opening sys$system:ucx$mgt_thresholds.dat 28-JUL-2004 08:34:43.37 WARNING CPQTHRESHOLDMGMT_PERSIST.C line 133: error linking sys$system:ucx$mgt_thresholds.dat and sys$system:ucx$mgt_thresholds.bak  I >> And when I switch pages I see me logged in as user (instead of admin).3 >7A >Did you grant WBEM$ADMIN to the VMS user you're logging in with?tA >Even if you were on a V3.x before, the installation guide states C >that "Installation of the kit will revoke these rights identifiersg) >unconditionally as part of the upgrade.",  G Bingo. Next bug fixed. Thanks a lot. I think, you made me forgetting to ' RTFM cause of your excellent service...a  C >> >Funny enough: the thresholds don't work with TCP/IP Services onn >> >that machine either. >>E >> I don't know what you mean with thresholds, but I do see no bettergF >> behaviour with TCPIP, too. That's why I wanted to try the CIM, too. >mI >When it works, there are small triangles on the "File System Space Used" G >and "CPU Utilization" pages above each disk/CPU bar denoting a warningd# >(yellow) and critical (red) level.   > Where ? I have "Refresh" "Device Home" "Options" and "Logout". Or do you mean in the CIM ?2  B >P.S.: a new step I've seen in the TCPware specific section of the' >installation guide is to create a file 2 >SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$VMS_SNMP_CONF.DAT  A I can't remember if its new, but I have this file since long ago.09 Though it had no "trap" line entered. Is this important ?:  < >P.P.S.: is the entry "IDS_SNMP_WRITE_COMMUNITY=noelmginkgo"< >in the file SYS$SPECIFIC:[WBEM.WEB.IM.WEBAGENT]WEBAGENT.INI. >correct? I'd assume it has to be "elmginkgo".   We'll see...   -- 8 Peter "EPLAN" LANGSTOEGERh% Network and OpenVMS system specialist~ E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------   End of INFO-VAX 2004.416 ************************ould help prevent or reduce this fragmentation by F >"encouraging" the system to write files in a more contiguous manner. F >I'm not looking to maintain an index of excellent only to improve theE >index.  I'm sure that running a defrag such as DFU will be suggested D >and I'm already doing that, but I'd like to find something that was  >proactive rather than reactive. >Vitals:& >Alpha OpenVMS V6.2 on DEC 3000 - M700
 >DFU v2.7a >ODS2 volume, ~37g02pl1.zipmc >>> 150 IMAGE retrieve of /disk$misc/decus/vmslt03b/vu/xpdf-2_02pl1.zip (11125846 bytes) started.i> >>> 226 Transfer completed.  11125674 (8) bytes transferred. <<< TYPE A >>> 200 Type A ok.
 <<< PASV? >>> 227 Entering passive mode; use PORT (198,151,12,104,7,40). <<< RETR xpdf-ann.txt.[ >>> 150 ASCII retrieve of /disk$misc/decus/vmslt03b/vu/xpdf-ann.txt (3192 bytes) started.I: >>> 226 Transfer completed.  3037 (8) bytes transferred. <<< TYPE I >>> 200 Type I ok.
 <<< PASV? >>> 227 Entering passive mode; use PORT (198,151,12,104,7,41)d <<< RETR xpdf.zip4Y >>> 150 IMAGE retrieve of /disk$misc/decus/vmslt03b/vu/xpdf.zip (560832 bytes) started.Y< >>> 226 Transfer completed.  560448 (8) bytes transferred.
 <<< PASV? >>> 227 Entering passive mode; use PORT (198,151,12,104,7,42)5# <<< RETR xscreensaver-4_14_tar.gzvj >>> 150 IMAGE retrieve of /disk$misc/decus/vmslt03b/vu/xscreensaver-4_14_tar.gz (3988709 bytes) started.= >>> 226 Transfer completed.  3988251 (8) bytes transferred.i
 <<< PASV? >>> 227 Entering passive mode; use PORT (198,151,12,104,7,43)  <<< RETR xstar.zipZ >>> 150 IMAGE retrieve of /disk$misc/decus/vmslt03b/vu/xstar.zip (266529 bytes) started.< >>> 226 Transfer completed.  265951 (8) bytes transferred.
 <<< PASV? >>> 227 Entering passive mode; use PORT (198,151,12,104,7,44)4 <<< RETR xvmsutils.zip] >>> 150 IMAGE retrieve of /disk$misc/decus/vmslt03b/vu/xvmsutils.zip (80928 bytes) started.>; >>> 226 Transfer completed.  8