1 INFO-VAX	Thu, 05 Oct 2000	Volume 2000 : Issue 557       Contents:( CA7 on VAX: Which Polycenter tool? (end), Re: CA7 on VAX: Which Polycenter tool? (end)$ RE: Compaq and docs about retired HW$ Re: Compaq and docs about retired HW$ Re: Compaq and docs about retired HW Compaq.com - OpenVMS Systems  RE: Compaq.com - OpenVMS Systems  Re: Compaq.com - OpenVMS Systems* Experianced Net user needed for a Question' Re: Getting Compaq to advertise OpenVMS ' RE: Getting Compaq to advertise OpenVMS ' Re: Getting Compaq to advertise OpenVMS ' RE: Getting Compaq to advertise OpenVMS % Re: getting group name from UIC value 
 heap manager?  Heroix RoboMon and others ....3 Re: Looking for 10BACKUP and DUMPER for VMS system. 3 Re: Looking for 10BACKUP and DUMPER for VMS system. " Re: Looks like I need help again!!" Re: Looks like I need help again!! Make $50,000 in 90 Days! Maximum record size in pipes  Re: Maximum record size in pipes  Re: Maximum record size in pipes Newbie help please Re: Newbie help please Re: NTP with UCX 4.26 Re: openVMS v7.1 VAX with Dump off System Disk feature Re: PF keys 3 Re: Register values for DEFBOO.COM (boot from tape)  Removing devices from system1 Re: Seeking info/prices for OpenVMS and hardware. 1 Re: Seeking info/prices for OpenVMS and hardware. 1 Re: Seeking info/prices for OpenVMS and hardware. & Re: Shark x Penguin : The OpenVMS Logo& RE: Shark x Penguin : The OpenVMS Logo& RE: Shark x Penguin : The OpenVMS Logo! Re: Sun Hardware problems persist  TCP/IP 5.0A ECO Appears  Re: TCP/IP 5.0A ECO Appears  Re: TCP/IP 5.0A ECO Appears  Re: TCP/IP 5.0A ECO Appears  Re: TCP/IP 5.0A ECO Appears  Re: TCP/IP 5.0A ECO Appears  Re: TCP/IP 5.0A ECO Appears  Re: TCP/IP 5.0A ECO Appears  Re: TCP/IP 5.0A ECO Appears  Re: TCP/IP 5.0A ECO Appears # Re: TCPIP v5.0A corrupted LRU queue / Re: Thinking of switching from Multinet to UCX. / Re: Thinking of switching from Multinet to UCX. * time to consolidate the TCP/IP work on VMS. Re: time to consolidate the TCP/IP work on VMS Re: VMS Mail - Sending binaries  Re: VMS Mail - Sending binaries  Re: volume set copying. 4 Re: What exactly happens when a terminal dissappears4 Re: What exactly happens when a terminal dissappears& Re: Why does TYPE/TAIL sometimes fail?  Why has Compaq retired DECnet ??$ Re: Why has Compaq retired DECnet ??$ Re: Why has Compaq retired DECnet ??$ Re: Why has Compaq retired DECnet ??$ RE: Why has Compaq retired DECnet ??$ Re: Why has Compaq retired DECnet ??$ Re: Why has Compaq retired DECnet ??$ Re: Why has Compaq retired DECnet ??$ Re: Why has Compaq retired DECnet ??$ Re: Why has Compaq retired DECnet ??$ Re: Why has Compaq retired DECnet ??$ Re: Why has Compaq retired DECnet ??$ Re: Why has Compaq retired DECnet ??$ Re: Why has Compaq retired DECnet ??$ Re: Why has Compaq retired DECnet ??' Re: www.networks.digital.com retired... ' RE: www.networks.digital.com retired... ' Re: www.networks.digital.com retired... ' Re: www.networks.digital.com retired... ' Re: www.networks.digital.com retired... ' Re: www.networks.digital.com retired... ' Re: www.networks.digital.com retired... ( xml library xerces on openvms and deccxx, Re: xml library xerces on openvms and deccxx  F ----------------------------------------------------------------------  % Date: Thu, 05 Oct 2000 08:26:09 +0200 0 From: Didier Morandi <Didier.Morandi@Easynet.fr>1 Subject: CA7 on VAX: Which Polycenter tool? (end) * Message-ID: <39DC1F00.EA5A857D@Easynet.fr>   Didier Morandi wrote:  > G > I'm supposed to teach the "CA7 OpenVMS operations management utility"  > next week. > 1 > ?   (this is a "?", not a dialup line noise :-)  > G > Ages ago, I remember a DEC product suite called Polycenter, with many I > utilities. Most of them have been sold to Computer Associate and became G > part of the Unicenter TNG offer. Today, OpenVMS Polycenter is, as you & > may know, the new name of VMSINSTAL. > E > I asked some (good) friends at COMPAQ, none know about CA7/OpenVMS. E > So I went to CA and I have been told that there is a CA7 operations  > management tool for... MVS.     E I finally got in touch with the end user. They do use this product on G VMS and they have a set of four printed documents from CA (in English):    CA-7 for VAX installation guide  CA-7 for VAX Reference Manual  CA-7 for VAX Users Guide CA-7 for VAX Messages Guide    All dated August 1992.  F Now, the question (again): What is the Polycenter serie product hiddenF behind? CA doesn't know, doesn't even remember the product (probably a member of TNG today).    Thanks,    D.   ------------------------------  % Date: Thu, 05 Oct 2000 19:51:08 +0010 % From: paddy.o'brien@zzz.tg.nsw.gov.au 5 Subject: Re: CA7 on VAX: Which Polycenter tool? (end) 5 Message-ID: <01JUZNHVYZ8Y00516Y@tgmail.tg.nsw.gov.au>    Didier Morandi wrote:   G >Now, the question (again): What is the Polycenter serie product hidden G >behind? CA doesn't know, doesn't even remember the product (probably a  >member of TNG today).    J Do they mean that they were **given** a damned good polycentre product by L Digital and they cannot remember the name under which they tried to screw a N fortune out of all of us suckers who actually made use of the Digital product M and who would have loved similar functionality at a reasonable (not CA) cost?    That sentence is too long!!!   Regards, Paddy   Paddy O'Brien, Transmission Development, 
 TransGrid, PO Box A1000, Sydney South,  NSW 2000, Australia    Tel:   +61 2 9284-3063 Fax:   +61 2 9284-3050& Email: paddy.o'brien@zzz.tg.nsw.gov.au  M Either "\'" or "\s" (to escape the apostrophe) seems to work for most people, ; but that little whizz-bang apostrophe gives me little spam.    ------------------------------  % Date: Thu, 05 Oct 2000 08:46:43 +0200 6 From: "Dijk, Jeroen van" <Jeroen.vandijk@getronics.nl>- Subject: RE: Compaq and docs about retired HW M Message-ID: <2795B75EF003D311801A00A0C906B511A2AE00@cucexec.gbc.getronics.nl>   6 My thoughts are that the job of DECUS is to make sure.D That those documentation, firmware and other old stuff keeps public.8 I don't care if that is on the site of DECUS or Compaq. 8 But Compaq is the one the makes money with VAX support.   a It is in interest of the owners of the old vax's (read: customers of Compaq or members of DECUS)  Y to keep the second hand market alive and if Compaq and/or DECUS is cleaning up old stuff. ' Then they are killing that market.         -----Original Message-----/ From: Bernd Eckstein [mailto:B.Eckstein@cli.de] # Sent: donderdag 5 oktober 2000 7:27  To: Info-VAX@Mvb.Saic.Com ) Subject: Compaq and docs about retired HW     : As we all know, there is no more www.networks.digital.com,& very few about the Old Iron (VAXen) at/ http://www5.compaq.com/alphaserver/vax/archive/ 
 and so on.  B Isn't that a job for DECUS, to make a deal with compaq and dnpg toB take over all that old webdocu and firmware and and to bring it to the public ?  B It's nice to aquire a DS700, but how to use without a WWENG1.SYS ?  F So please guys at DECUS, you are the people with the compaq-connection> (of course I'm member of Decus ;-) can't you bring help to the community ?    Any feedback ?   --  H Microsoft broke Volkswagen`s world record: VW only made 22 million bugs!  ( Mit freundlichen Gruessen / Best regardsC B.Eckstein, CLI GmbH - mailto:B.Eckstein@cli.de - http://www.cli.de C Matthiashofstr. 28, D-52064 Aachen - Fon: +49 241 47051-0, Fax: -89    ------------------------------  % Date: Thu, 05 Oct 2000 05:51:48 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> - Subject: Re: Compaq and docs about retired HW , Message-ID: <39DC4F2D.E4C93A03@videotron.ca>   Bernd Eckstein wrote: D > Isn't that a job for DECUS, to make a deal with compaq and dnpg toD > take over all that old webdocu and firmware and and to bring it to > the public ?  M I agree entirely. All retired documentation and software shoudl automatically < be made available to DECUS on the web or in some other form.   ------------------------------  % Date: Thu, 05 Oct 2000 09:40:38 -0700 + From: "Barry Treahy, Jr." <Treahy@mmaz.com> - Subject: Re: Compaq and docs about retired HW ( Message-ID: <39DCAF06.F41784E8@mmaz.com>  N Yes, absolutely, but the question is how much of this important material (VMS,O DECnet, Golden Eggs from something a little order than last week) has been lost L due to the myopic vision of Compaq and their attempts to Wintel the world to death.  M I was a Digital loyalist, almost to a fault, and at the same time never cared O much for Compaq and how they operated.  I still use and believe VMS is the best P OS available, but to be honest, I do as little as possible to rely on Compaq andQ will never spend a dime with Compaq for anything but VMS related products.  To be P honest, that hositility I have for Compaq is a barrier that someday will make it  impossible to continue with VMS.  O By Compaq pretending that branding didn't matter, that the VMS sheep would fall 9 in-line behind their Wintel goats, was a major mistake...    Just my two cents.   Barry    JF Mezei wrote:    > Bernd Eckstein wrote: F > > Isn't that a job for DECUS, to make a deal with compaq and dnpg toF > > take over all that old webdocu and firmware and and to bring it to > > the public ? > O > I agree entirely. All retired documentation and software shoudl automatically > > be made available to DECUS on the web or in some other form.   --  ? Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIO   A E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028    ------------------------------  % Date: Thu, 05 Oct 2000 15:23:23 +0100 9 From: "Miller, Daniel" <Daniel.Miller@Nightfreight.co.uk> % Subject: Compaq.com - OpenVMS Systems A Message-ID: <017BBD86A4F6D3118D640020182FB53D04A09F@NF-HOUSE-NT1>   J This message is in MIME format. Since your mail reader does not understand< this format, some or all of this message may not be legible.  ' ------ =_NextPart_000_01C02ED7.D23ECE20  Content-Type: text/plain   Hi everyone,  G Had a look at the info about v7.3, and i was interested by what appears E to be an odbc package included with the os.  Ive found some more info E which seems to indicate that a license for v7.2-1 is all thats needed F and you can download this software without upgrading to v7.3.  Trouble+ is i cant see where you can download from!    
 Daniel Miller  Nightfreight Plc      H http://www.openvms.compaq.com/ebusiness_without_compromise/fact/CONNECT. HTML&  <<Compaq.com - OpenVMS Systems.url>>   ' ------ =_NextPart_000_01C02ED7.D23ECE20 ' Content-Type: application/octet-stream; ( 	name="Compaq.com - OpenVMS Systems.url"  Content-Disposition: attachment;, 	filename="Compaq.com - OpenVMS Systems.url"  	 [DEFAULT] T BASEURL=http://www.openvms.compaq.com/ebusiness_without_compromise/fact/CONNECT.HTML   [InternetShortcut]P URL=http://www.openvms.compaq.com/ebusiness_without_compromise/fact/CONNECT.HTML Modified=C0567ABAD72EC00110   ) ------ =_NextPart_000_01C02ED7.D23ECE20--    ------------------------------  % Date: Thu, 05 Oct 2000 10:52:38 -0400 ' From: Dan Allen <daniel.allen@nist.gov> ) Subject: RE: Compaq.com - OpenVMS Systems @ Message-ID: <NEBBIALHDHJMJINPGMOACELKCKAA.daniel.allen@nist.gov>  L MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEggORQ29uL dGVudC1UeXBlOiB0ZXh0L3BsYWluOw0KCWNoYXJzZXQ9Imlzby04ODU5LTEiDQpDb250ZW50LVRyL YW5zZmVyLUVuY29kaW5nOiA3Yml0DQoNCg0KDQpJdCBhcHBlYXJzIHRvIGJlIGF2YWlsYWJsZSBmL cm9tIHRoZSBhdHR1bml0eSB3ZWJzaXRlJ3MgZG93bmxvYWQgcGFnZS4NCg0KPiAtLS0tLU9yaWdpL bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNaWxsZXIsIERhbmllbCBbbWFpbHRvOkRhbmllbC5NL aWxsZXJATmlnaHRmcmVpZ2h0LmNvLnVrXQ0KPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAwNSwgL MjAwMCAxMDoyMyBBTQ0KPiBUbzogSW5mby1WQVhATXZiLlNhaWMuQ29tDQo+IFN1YmplY3Q6IENvL bXBhcS5jb20gLSBPcGVuVk1TIFN5c3RlbXMNCj4NCj4NCj4gSGkgZXZlcnlvbmUsDQo+DQo+IEhhL ZCBhIGxvb2sgYXQgdGhlIGluZm8gYWJvdXQgdjcuMywgYW5kIGkgd2FzIGludGVyZXN0ZWQgYnkgL d2hhdCBhcHBlYXJzDQo+IHRvIGJlIGFuIG9kYmMgcGFja2FnZSBpbmNsdWRlZCB3aXRoIHRoZSBvL cy4gIEl2ZSBmb3VuZCBzb21lIG1vcmUgaW5mbw0KPiB3aGljaCBzZWVtcyB0byBpbmRpY2F0ZSB0L aGF0IGEgbGljZW5zZSBmb3IgdjcuMi0xIGlzIGFsbCB0aGF0cyBuZWVkZWQNCj4gYW5kIHlvdSBjL YW4gZG93bmxvYWQgdGhpcyBzb2Z0d2FyZSB3aXRob3V0IHVwZ3JhZGluZyB0byB2Ny4zLiAgVHJvL dWJsZQ0KPiBpcyBpIGNhbnQgc2VlIHdoZXJlIHlvdSBjYW4gZG93bmxvYWQgZnJvbSENCj4NCj4gL RGFuaWVsIE1pbGxlcg0KPiBOaWdodGZyZWlnaHQgUGxjDQo+DQo+DQo+IGh0dHA6Ly93d3cub3BlL bnZtcy5jb21wYXEuY29tL2VidXNpbmVzc193aXRob3V0X2NvbXByb21pc2UvZmFjdC9DT05ORUNUL Lg0KPiBIVE1MDQo+ICA8PENvbXBhcS5jb20gLSBPcGVuVk1TIFN5c3RlbXMudXJsPj4NCj4NCgAAL AAAAADGCAsYwggLCAgEBMIGoMIGbMQswCQYDVQQGEwJVUzERMA8GA1UECBMITWFyeWxhbmQxFTATL BgNVBAcTDEdhaXRoZXJzYnVyZzE3MDUGA1UEChMuTmF0aW9uYWwgSW5zdGl0dXRlIG9mIFN0YW5kL YXJkcyBhbmQgVGVjaG5vbG9neTENMAsGA1UECxMEU0RDVDEaMBgGA1UEAxMRU0RDVCBQcm90b3R5L cGUgQ0ECCAS9NckAAABaMAkGBSsOAwIaBQCgggFzMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwL HAYJKoZIhvcNAQkFMQ8XDTAwMTAwNTE0NTIzOFowIwYJKoZIhvcNAQkEMRYEFCRZV287UCk5dR5NL Ee/gxkAWsWPnMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGL BSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIG5BgkrBgEEAYI3EAQxL gaswgagwgZsxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhNYXJ5bGFuZDEVMBMGA1UEBxMMR2FpdGhlL cnNidXJnMTcwNQYDVQQKEy5OYXRpb25hbCBJbnN0aXR1dGUgb2YgU3RhbmRhcmRzIGFuZCBUZWNoL bm9sb2d5MQ0wCwYDVQQLEwRTRENUMRowGAYDVQQDExFTRENUIFByb3RvdHlwZSBDQQIIBL01yQAAL AFowDQYJKoZIhvcNAQEBBQAEgYAapz4WfgdF72CDsmw9SdvHQCKZBiOQvEDjFLY0OdXXGPXD5zg1L K5NpinYwXswyC9WRaZ/rEnxGCRZhKgh4nx/7dMQ+OuJJTonLbgj6CDeEV/yoLzcL9OLpCL02orBu8 xWUM9UKE/vXY/cLp2Y2AC0a39tDVSfv5qyM+qUm/0pIZnAAAAAAAAA==   ------------------------------  $ Date: Thu, 5 Oct 2000 11:29:55 -04004 From: "John L Ferguson" <John.L.Ferguson@compaq.com>) Subject: Re: Compaq.com - OpenVMS Systems 6 Message-ID: <8ri6ui$a9v$1@mailint03.im.hou.compaq.com>  J Unfortunately, the web pages for the download are lagging behind the otherH posted information for V7.3.  The pages will be up in the next few days, hopefully tomorrow.   G What we are providing is a subset of Attunity Connect 3.0 (formerly ISG K Navigator) with JDBC, ODBC, and XML client APIs and ODBC, XML, and Oracle8i 	 adapters.   
 John Ferguson  OpenVMS eBusiness  John.L.Ferguson@compaq.com   Miller, Daniel wrote in message 8 <017BBD86A4F6D3118D640020182FB53D04A09F@NF-HOUSE-NT1>...
 >Hi everyone,  > H >Had a look at the info about v7.3, and i was interested by what appearsF >to be an odbc package included with the os.  Ive found some more infoF >which seems to indicate that a license for v7.2-1 is all thats neededG >and you can download this software without upgrading to v7.3.  Trouble + >is i cant see where you can download from!  >  >Daniel Miller >Nightfreight Plc  >  > I >http://www.openvms.compaq.com/ebusiness_without_compromise/fact/CONNECT.  >HTML & > <<Compaq.com - OpenVMS Systems.url>> >    ------------------------------  # Date: Thu, 05 Oct 2000 09:48:35 GMT  From: bigsuma@home.com3 Subject: Experianced Net user needed for a Question 2 Message-ID: <T7YC5.11468$cP6.9139@news.uswest.net>  5 Help me make some cash and you too...and your pals!!!   J I WILL SHARE ANY REFFERALS OVER 100 with anyone that emails and asks me!!!  / http://www.alladvantage.com/go.asp?refid=BNO052  eywdjkseyrve   ------------------------------   Date: 5 Oct 2000 09:16:05 -0500 , From: koehler@eisner.decus.org (Bob Koehler)0 Subject: Re: Getting Compaq to advertise OpenVMS+ Message-ID: <vxMz6dbKgA1i@eisner.decus.org>   ] In article <8rg7q6$cku@usenet.pa.dec.com>, sander@vmsbiz.enet.dec.com (Warren Sander) writes:  > A > 	Coming.. after the annoucement stuff more 7.3 stuff will be up ` > 	but there is http://www.openvms.compaq.com/ebusiness_without_compromise/fact/openvms-v73.html >   .    Forbidden - by rule.  HTTP status code: 403  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporation = Hubble Space Telescope Payload  | Federal Sector, Civil Group E  Flight Software Team           | please remove ".aspm" when replying    ------------------------------  % Date: Thu, 05 Oct 2000 09:00:23 -0400 ' From: Dan Allen <daniel.allen@nist.gov> 0 Subject: RE: Getting Compaq to advertise OpenVMS@ Message-ID: <NEBBIALHDHJMJINPGMOAKELHCKAA.daniel.allen@nist.gov>  $  No problem getting there from here.   > -----Original Message-----5 > From: Bob Koehler [mailto:koehler@eisner.decus.org]h+ > Sent: Thursday, October 05, 2000 10:16 AMh > To: Info-VAX@Mvb.Saic.ComE2 > Subject: Re: Getting Compaq to advertise OpenVMS >  > _ > In article <8rg7q6$cku@usenet.pa.dec.com>, sander@vmsbiz.enet.dec.com (Warren Sander) writes:- > > C > > 	Coming.. after the annoucement stuff more 7.3 stuff will be upeb > > 	but there is http://www.openvms.compaq.com/ebusiness_without_compromise/fact/openvms-v73.html > >  > 0 >    Forbidden - by rule.  HTTP status code: 403 > H > ----------------------------------------------------------------------A > Bob Koehler                     | Computer Sciences CorporationD? > Hubble Space Telescope Payload  | Federal Sector, Civil GroupMG >  Flight Software Team           | please remove ".aspm" when replyingp >  >    ------------------------------  " Date: Thu, 5 Oct 2000 13:53:14 GMT- From: "Richard D. Piccard" <piccard@ohio.edu>p0 Subject: Re: Getting Compaq to advertise OpenVMS( Message-ID: <39DC87C8.1CC28195@ohio.edu>  h The openvms-v73.html file is littered with user-hostile HTML.  In particular, someone looking at it withc an 800 x 600 screen, still a quite common size, cannot view the interesting text without horizontal c scrolling because it is in a <TABLE width=800>, which does not allow for the window borders, scroll  bars, etc..o  g Worse, those of us who use Macintosh systems with relic laser printers cannot print any of the pages inmf portrait mode, for easier reading, because most of the page has a width of at least 600 pixels (525 is5 the practical maximum for platform-neutral printing).e                               RDP/     Warren Sander wrote:   > [snip]  ! > |>* No link to VMS 7.3 featurese > H >         Coming.. after the annoucement stuff more 7.3 stuff will be upg >         but there is http://www.openvms.compaq.com/ebusiness_without_compromise/fact/openvms-v73.htmlo >l > [snip]   > |> >  > --D > ------------------------------------------------------------------8 > Warren Sander                        OpenVMS MarketingF > Compaq Computer Corporation          Work:  warren.sander@compaq.comD > 200 Forest Street MR01-3/J1          Personal: sander@ultranet.com5 > Marlboro, MA 01752                   (508) 467-4875 7 >    My opinions are my own and I only speak for myselfr0 >           Read http://www.openvms.digital.com/D > ------------------------------------------------------------------   --B ==================================================================B Dick Piccard                           Academic Technology ManagerB piccard@ohio.edu                                 Computer ServicesB http://oak.cats.ohiou.edu/~piccard/                Ohio University   ------------------------------  % Date: Thu, 05 Oct 2000 08:12:00 -0700 1 From: "Farrell, Michael" <MFarrell@voltdelta.com>e0 Subject: RE: Getting Compaq to advertise OpenVMSO Message-ID: <7DF45F22D904D31192EE00805F578DF207F1B2@ny-exchange1.maintech1.com>s  L I got into that URL but the display spreads itslef out wider than a standard screen size.  F To read it I have to slide the horizontal scroll bar back and forth.  : Also it won't print completely so its of little use here.    (I use Netscape 4.7).-   Mike Farrell   > -----Original Message-----@ > From:	koehler@eisner.decus.org [SMTP:koehler@eisner.decus.org]+ > Sent:	Thursday, October 05, 2000 10:16 AM  > To:	Info-VAX@Mvb.Saic.Com52 > Subject:	Re: Getting Compaq to advertise OpenVMS > G > In article <8rg7q6$cku@usenet.pa.dec.com>, sander@vmsbiz.enet.dec.come > (Warren Sander) writes:" > > C > > 	Coming.. after the annoucement stuff more 7.3 stuff will be upi > > 	but there isrL > http://www.openvms.compaq.com/ebusiness_without_compromise/fact/openvms-v7 > 3.html > >  > 0 >    Forbidden - by rule.  HTTP status code: 403 > H > ----------------------------------------------------------------------A > Bob Koehler                     | Computer Sciences Corporationo? > Hubble Space Telescope Payload  | Federal Sector, Civil GroupeG >  Flight Software Team           | please remove ".aspm" when replyingy   ------------------------------   Date: 5 Oct 2000 00:39 CST' From: carl@gerg.tamu.edu (Carl Perkins)7. Subject: Re: getting group name from UIC value, Message-ID: <5OCT200000391281@gerg.tamu.edu>  / "Gerke Grashuis" <g.grashuis@kpn.com> writes... A }Have a look at the f$context lexical (more specific the argumentd }"selection_item")2 }Item GRP and MEM give you the needed information. }  }Gerke.   F It is probably just as easy, if not easier, to change the two relevant lines of his code to this:   $ group = uic/%X10000@ $ member = uic - group*%X10000  H This is assuming that the numerical UIC isn't intended to ba an "opaque"J value, i.e. one thay may change without warning in future versions of VMS.9 This seems to be a fairly reasonable assumption (so far).C  A (Also, keep in mind that the UIC group and member vaules that youeE see in AUTHORIZE are displayed in octal, not decimal. This could saveo, some "why don't they match" type confusion.)   --- Carl  J }Jean-Franois Marchal <jean-francois.marchal@x9000.fr> schreef in artikel& }<8reu4b$a89$1@reader1.imaginet.fr>... }> Bonjour  tousl }> eH }> I need to check the group name of the current user within SYLOGIN.COMD }> The group may not be named, but in this case, I can use something }> of the form GROUP_12345 . }> 0 }> Just beginning with ... }> t }> $ NAMED_UIC = f$user()-/ }> $ if f$element(0,",NAMED_UIC).eqs.NAMED_UIC)n }> $   theno# }> $   NAME = NAMED_UIC - "[" - "]"e1 }> $   UIC = f$identifier (NAME,"NAME_TO_NUMBER")u }> $   GROUP = ??????g }> $   MEMBER = ??????
 }> $ endif }> -= }> How should I extract group and member from the uic value ?0 }>   }> Cordialemente }> Jean-Franois Marchal   ------------------------------  $ Date: Thu, 5 Oct 2000 13:07:59 +0200- From: "Rob Eisink" <rob_eisink@essentium.com>b Subject: heap manager?* Message-ID: <8rhni3$312f$1@beast.euro.net>       Hi,t  H I'm looking for a heap manager for OpenVMS Alpha. Is there any? Any good suggestion?        thanks,D     Robo   ------------------------------  % Date: Thu, 05 Oct 2000 13:21:59 -0300n) From: fabio_compaq@ep-bc.petrobras.com.bre' Subject: Heroix RoboMon and others ....UL Message-ID: <OFCB2D6F3C.E7BD9C2F-ON8325696F.0059733C@ep-bc.petrobras.com.br>  K I must plan what are the products the company will buy next year to help ine the managementJ of the OpenVMS servers. What do you know about Heroix RoboMon ??? It works as youI expect ? I accept suggestions of other GOOD products. My applications are  10%  client/server and 90% based on VT.  G But the big problem of buying OpenVMS software here in my country is weq dont have a reseller
 sometimes.   Regards, Fabio C.t   ------------------------------  ! Date: Thu, 05 Oct 00 06:38:30 GMT  From: jmfbahciv@aol.comw< Subject: Re: Looking for 10BACKUP and DUMPER for VMS system.+ Message-ID: <8rhio7$9rp$1@bob.news.rcn.net>S  6 In article <1MSC5.6470$wx5.219286@news2.giganews.com>,4    Timothy Stark <sword7@grace.speakeasy.org> wrote:
 >Hello folks:g >lH >I am looking for 10BACKUP and DUMPER software to access PDP-10 tapes onG >VAX/VMS system.  I had searched some ftp sites for them but can't findsG >them.  Do anyone have a listing of ftp sites that have VAX/VMS stuffs?p  < There was a magtape (or something) that had a whole slew of ; software to _help_ all the mainframe customers to "convert"e9 to <ptui>VMS.  Now I can't remember the idiotic buzz word.5 that the marketing types called it.  Anyway, the tapeo3 should have had the files that you asked for on it.r  6 While I'm thinking about it, if you say INTERCHANGE to< BACKUP, it will read DUMPER tapes just fine.  You just won't4 get any structure and directory info with the files.  7   ...Just in case you didn't know that :-)...I'm havingo4 a real difficult time trying to remember what comes 7 automatically for us.  I haven't had to teach -10 stuff-7 to a <bleeb> (don't wish to offend you ;-)) since 1972.0   /BAH     /BAH    ' Subtract a hundred and four for e-mail.:   ------------------------------  % Date: Thu, 05 Oct 2000 06:20:00 -0400>+ From: Tim Shoppa <shoppa@trailing-edge.com>m< Subject: Re: Looking for 10BACKUP and DUMPER for VMS system.1 Message-ID: <39DC1D90.5CCD06F7@trailing-edge.com>l   Timothy Stark wrote: >  > Hello folks: > I > I am looking for 10BACKUP and DUMPER software to access PDP-10 tapes onoH > VAX/VMS system.  I had searched some ftp sites for them but can't findH > them.  Do anyone have a listing of ftp sites that have VAX/VMS stuffs?  < Zip files containing these are now linked to from the PDP-10 software archive home page:h  "   http://pdp-10.trailing-edge.com/  @ In particular, see the links that now take you to DUMPER.ZIP and
 10BACKUP.ZIP.a   Tim. (shoppa@trailing-edge.com)n   ------------------------------   Date: 5 Oct 2000 10:42:55 GMTh' From: david20@alpha2.mdx.ac.uk (D.Webb)i+ Subject: Re: Looks like I need help again!! 0 Message-ID: <8rhlvf$2ed$1@aquila.news.mdx.ac.uk>  ` In article <8rful0$1ivm$1@info.cs.uofs.edu>, bill@triangle.cs.uofs.edu (Bill Gunshannon) writes:@ >Feeling so proud of myself for fixing this (with a lot of help)> >I decided it was time to venture in to the world of Clusters.> >Especially if faculty are actually going to consider using myB >machines.  So I did my first cluster config.  On reboot, MultinetB >didn't come back up.  I got a console message saying "INTSTKPAGES? >needed to be atleast 10 and was only set to 6."  A look in the-= >manual said fix it in MODPARAMS.DAT.  So I did.  And another0> >reboot gave me the same thing.  So, the other alternative wasA >SYSMAN.  So I ran it according tot he book and made the necesary1@ >change and rebooted.  And I got the same message again.  Hmmmm.@ >What is wrong with tis picture??  So I read further in the bookA >and it talks about SYSGEN.  But it says don;t use it, use SYSMAN_? >or MODPARAMS.DAT, but only use SYSGEN as a last resort.  Well, @ >seemed like a last resort to me.  5 commands later I reboot andD >everything is back to normal.  Anybody care to try and explain what? >I might have done wrong that made MODPARAMS,DAT and SYSMAN nota >work??n >e   Bill,o  J Did you run AUTOGEN after making the changes to SYS$SYSTEM:MODPARAMS.DAT ?  G MODPARAMS.DAT is just a text file which is read by the Autogen program.   M SYSGEN is the underlying utility that allows you to change system parameters. O However SYSGEN has one major weak point. Many system parameters work in concert N with others. Hence if you are not careful repeatedly changing system parameterL values with SYSGEN can lead to a seriously misconfigured system as different settings conflict.I The AUTOGEN utility does some sanity checking and makes sure that all theON required parameters are changed in a consistent manner. It then uses SYSGEN to make the changes.c  L Autogen can also use feedback from the running system to tune the system for your workload.   For further details see-   @SYS$UPDATE:AUTOGEN HELP    
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------  % Date: Thu, 05 Oct 2000 14:35:04 +0200a% From: Paul Sture <paul.sture@ubs.com>H+ Subject: Re: Looks like I need help again!!a' Message-ID: <39DC9198.2247577E@ubs.com>W   Bill Gunshannon wrote: > 3 > In article <3OCT00.16230821@feda34.fed.ornl.gov>,N0 >  Dave Greenwood <greenwoodde@ornl.gov> writes: > |>: > |>   I'll agree with disabling the out-of-date licenses. > |> > " > That's what it turned out to be. > K > |> Er - at the risk of suggesting the trivial - what does SHOW TIME show?W > C > Because of the apparent confusion between the behavior and what IVE > could read in the PAKS, this was the first thing I thought of.  ThelE > clock was off by one hour, which wouldn't have caused this problem,m5 > but does point to an apparent problem with EST/EDT.h > H Aha. I'll bet the date was out by 364 or 366 days too (or should that beF 365/367, being a leap year?). Known problem when upgrading VAXes sinceH at least the 6.2 upgrade. In fact, when I did the 7.2 upgrade on my homeG VAX, the date jumped back to one day off the current date, but in 1998.z -- H
 Paul Sture Zrich   ------------------------------  % Date: Thu, 05 Oct 2000 03:30:56 -0500G& From: Webmaster <emoore2927@yahoo.com>! Subject: Make $50,000 in 90 Days!w5 Message-ID: <200010050831.DAA02064@mail.datasync.com>D  H RGVhciBGcmllbmQsDQoNClRoaXMgcmVhbGx5IHdvcmtzISAgSGF2ZSB0aGUgZmFpdGgsIGRvH bid0IG1pc3MgdGhpcyBvcHBvcnR1bml0eS4gIEdldCANCmludm9sdmVkIGFsc28sIGFuZCBpH dCB3aWxsIHdvcmsgZm9yIHlvdSBhcyBpdCBkb2VzIGZvciB1cyEhIQ0KDQpUaGlzIGVtYWlsH IGNvbnRhaW5zIHRoZSBFTlRJUkUgUExBTiBvZiBob3cgWU9VIGNhbiBtYWtlICQ1MCwwMDAgH b3INCm1vcmUgaW4gdGhlIG5leHQgOTAgZGF5cyBzaW1wbHkgc2VuZGluZyBlbWFpbCENCg0KH U2VlbSBpbXBvc3NpYmxlPyAgIEp1c3QgcmVhZCBvbiBhbmQgc2VlIGhvdyBlYXN5IHRoaXMgH aXMuLg0KDQpEdWUgdG8gdGhlIHBvcHVsYXJpdHkgb2YgdGhpcyBsZXR0ZXIgb24gdGhlIEluH dGVybmV0LCBhIG1ham9yIG5pZ2h0bHkgDQpuZXdzIHByb2dyYW0gcmVjZW50bHkgZGV2b3RlH ZCBhbiBlbnRpcmUgc2hvdyB0byB0aGUgaW52ZXN0aWdhdGlvbiBvZiB0aGUgcHJvZ3JhbSANH CmRlc2NyaWJlZCBiZWxvdyB0byBzZWUgaWYgaXQgcmVhbGx5IGNhbiBtYWtlIHBlb3BsZSBtH b25leS4NCg0KVGhlIHNob3cgYWxzbyBpbnZlc3RpZ2F0ZWQgd2hldGhlciBvciBub3QgdGhlH IHByb2dyYW0gd2FzIGxlZ2FsLiBUaGVpciANCmZpbmRpbmdzIHByb3ZlZCB0aGF0IHRoZXJlH IGFyZSBhYnNvbHV0ZWx5IG5vIGxhd3MgcHJvaGliaXRpbmcgdGhlIHBhcnRpY2lwYXRpb24gH DQppbiB0aGUgcHJvZ3JhbS4NClRoaXMgaGFzIGhlbHBlZCB0byBzaG93IHBlb3BsZSB0aGF0H IHRoaXMgaXMgYSBzaW1wbGUsIGhhcm1sZXNzIGFuZCBmdW4gDQp3YXkgdG8gbWFrZSBzb21lH IGV4dHJhIG1vbmV5IGF0IGhvbWUuDQoNClRoZSByZXN1bHRzIGhhdmUgYmVlbiB0cnVseSByH ZW1hcmthYmxlLiBTbyBtYW55IHBlb3BsZSBhcmUgDQpwYXJ0aWNpcGF0aW5nIHRoYXQgdGhvH c2UgaW52b2x2ZWQgYXJlIGRvaW5nIG11Y2ggYmV0dGVyIHRoYW4gZXZlciBiZWZvcmUuIFNpH bmNlIA0KZXZlcnlvbmUgbWFrZXMgbW9yZSBhcyBtb3JlIHBlb3BsZSB0cnkgaXQgb3V0LCBpH dHMgYmVlbiB2ZXJ5IGV4Y2l0aW5nLg0KDQpZb3Ugd2lsbCB1bmRlcnN0YW5kIG9uY2UgeW91H IHRyeSBpdCB5b3Vyc2VsZiENCg0KKioqKioqKioqIFRIRSBFTlRJUkUgUExBTiBJUyBIRVJFH IEJFTE9XICoqKioqKioqKg0KDQoqKiogUHJpbnQgVGhpcyBOb3cgRm9yIEZ1dHVyZSBSZWZlH cmVuY2UgKioqDQoNCiQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkH JCQkJCQkJA0KDQpJZiB5b3Ugd291bGQgbGlrZSB0byBtYWtlIGF0IGxlYXN0ICQ1MCwwMDAgH aW4gbGVzcyB0aGFuIDkwIGRheXMhDQoNClBsZWFzZSByZWFkIHRoaXMgcHJvZ3JhbS4uLlRIH RU4gUkVBRCBJVCBBR0FJTiEhDQoNCiQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkH JCQkJCQkJCQkJCQkJCQkJA0KDQpUSElTIElTIEEgTEVHSVRJTUFURSwgTEVHQUwsIE1PTkVZH IE1BS0lORyBPUFBPUlRVTklUWSEhDQoNCkl0IGRvZXMgTk9UIHJlcXVpcmUgeW91IHRvIGNvH bWUgaW50byBjb250YWN0IHdpdGggcGVvcGxlIG9yIG1ha2Ugb3IgDQp0YWtlIGFueSB0ZWxlH cGhvbmUgY2FsbHMuIEp1c3QgZm9sbG93IHRoZSBpbnN0cnVjdGlvbnMsIGFuZCB5b3Ugd2lsH bCBtYWtlIA0KbW9uZXkuDQpUaGlzIHNpbXBsaWZpZWQgZS1tYWlsIG1hcmtldGluZyBwcm9nH cmFtIHdvcmtzIHBlcmZlY3RseSAxMDAlIEVWRVJZIA0KVElNRSENCg0KRS1tYWlsIGlzIHRoH ZSBzYWxlcyB0b29sIG9mIHRoZSBmdXR1cmUuIFRha2UgYWR2YW50YWdlIG9mIHRoaXMgDQp2H aXJ0dWFsbHkgZnJlZSBtZXRob2Qgb2YgYWR2ZXJ0aXNpbmcgTk9XISEhIFRoZSBsb25nZXIgH eW91IHdhaXQsIHRoZSBtb3JlIHBlb3BsZSANCndpbGwgYmUgZG9pbmcgYnVzaW5lc3MgdXNpH bmcgZW1haWwuIEdldCB5b3VyIHBpZWNlIG9mIHRoaXMgYWN0aW9uISEhDQp+fn5+fn5+fn5+H fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn4NCg0KSGVsbG8gLSBNeSBuH YW1lIGlzIEpvaG5hdGhvbiBSb3Vya2UsIEknbSBmcm9tIFJob2RlIElzbGFuZC4NCg0KVGhlH IGVuY2xvc2VkIGluZm9ybWF0aW9uIGlzIHNvbWV0aGluZyBJIGFsbW9zdCBsZXQgc2xpcCB0H aHJvdWdoIG15IA0KZmluZ2Vycy4NCkZvcnR1bmF0ZWx5LCBzb21ldGltZSBsYXRlciBJIHJlH LXJlYWQgZXZlcnl0aGluZyBhbmQgZ2F2ZSBzb21lIHRob3VnaHQNCmFuZCBzdHVkeSB0byBpH dC4NCg0KVHdvIHllYXJzIGFnbywgdGhlIGNvcnBvcmF0aW9uIEkgd29ya2VkICBmb3IgdGhlH IHBhc3QgdHdlbHZlIHllYXJzDQpvd24tIHNpemVkIGFuZCBteSBwb3NpdGlvbiB3YXMgZWxpH bWluYXRlZC4gQWZ0ZXIgdW5wcm9kdWN0aXZlIGpvYg0KaW50ZXJ2aWV3cywgSSBkZWNpZGVkH IHRvIG9wZW4gbXkgb3duIGJ1c2luZXNzLiBPdmVyIHRoZSBwYXN0IHllYXIsDQpJIGluY3VyH cmVkIG1hbnkgdW5mb3Jlc2VlbiBmaW5hbmNpYWwgcHJvYmxlbXMuIEkgb3dlZCBteSBmYW1pH bHksIA0KZnJpZW5kcyBhbmQgY3JlZGl0b3JzIG92ZXIgJDM1LDAwMC4gVGhlIGVjb25vbXkgH d2FzIHRha2luZyBhIHRvbGwgb24gbXkNCmJ1c2luZXNzIGFuZCBJIGp1c3QgY291bGRuJ3QgH c2VlbSB0byBtYWtlIGVuZHMgbWVldC4gSSBoYWQgdG8gcmVmaW5hbmNlDQphbmQgYm9ycm93H IGFnYWluc3QgbXkgaG9tZSB0byBzdXBwb3J0IG15IGZhbWlseSBhbmQgc3RydWdnbGluZyANH CmJ1c2luZXNzLg0KDQpBVCBUSEFUIE1PTUVOVCBzb21ldGhpbmcgc2lnbmlmaWNhbnQgaGFwH cGVuZWQgaW4gbXkgbGlmZS4gSSBhbQ0Kd3JpdGluZyB0byBzaGFyZSB0aGUgZXhwZXJpZW5jH ZSBpbiBob3BlcyB0aGF0IHRoaXMgY291bGQgY2hhbmdlIHlvdXIgDQpsaWZlIEZPUkVWRVIgH IEZJTkFOQ0lBTExZJCQkISEhDQoNCkluIG1pZCBEZWNlbWJlciwgSSByZWNlaXZlZCB0aGlzH IHByb2dyYW0gaW4gbXkgZS1tYWlsLiBTaXggbW9udGhzDQpwcmlvciB0byByZWNlaXZpbmcgH dGhpcyBwcm9ncmFtIEkgaGFkIGJlZW4gc2VuZGluZyBhd2F5IGZvciBpbmZvcm1hdGlvbg0KH b24gdmFyaW91cyBidXNpbmVzcyBvcHBvcnR1bml0aWVzLiBBbGwgb2YgdGhlIHByb2dyYW1zH IEkgcmVjZWl2ZWQsIGluIG15DQpvcGluaW9uLCB3ZXJlIG5vdCBjb3N0IGVmZmVjdGl2ZS4gH VGhleSB3ZXJlIGVpdGhlciB0b28gZGlmZmljdWx0IGZvciBtZSANCnRvIGNvbXByZWhlbmQgH b3IgdGhlIGluaXRpYWwgaW52ZXN0bWVudCB3YXMgdG9vIG11Y2ggZm9yIG1lIHRvIHJpc2sgH dG8gc2VlDQppZiB0aGV5IHdvdWxkIHdvcmsgLiBCdXQgYXMgSSB3YXMgc2F5aW5nLCBpbiBEH ZWNlbWJlciBvZiAxOTk3IEkgDQpyZWNlaXZlZCB0aGlzIHByb2dyYW0uIEkgZGlkbid0IHNlH bmQgZm9yIGl0LCBvciBhc2sgZm9yIGl0LCB0aGV5IGp1c3QgZ290IG15IA0KbmFtZSBvZmYgH YSBtYWlsaW5nIGxpc3QuDQoNClRIQU5LIEdPT0RORVNTIEZPUiBUSEFUISEhIEFmdGVyIHJlH YWRpbmcgaXQgc2V2ZXJhbCB0aW1lcw0KdG8gbWFrZSBzdXJlIEkgd2FzIHJlYWRpbmcgaXQgH Y29ycmVjdGx5LiBJIGNvdWxkbid0IGJlbGlldmUgbXkgZXllcyEgDQpIZXJlIHdhcyBhIE1PH TkVZIE1BS0lORyBNQUNISU5FICEgIEkgY291bGQgc3RhcnQgaW1tZWRpYXRlbHkNCndpdGhvH dXQgYW55IGRlYnQuDQoNCkxpa2UgbW9zdCBvZiB5b3UgSSB3YXMgc3RpbGwgYSBsaXR0bGUgH c2tlcHRpY2FsIGFuZCBhIGxpdHRsZSB3b3JyaWVkIA0KYWJvdXQgdGhlIGxlZ2FsIGFzcGVjH dHMgb2YgaXQgYWxsLiBTbyBJIGNoZWNrZWQgaXQgb3V0IHdpdGggdGhlIFUuUy5Qb3N0IE9mH ZmljZSgxLTgwMC03MjUtMjE2MSANCjI0LWhycykgYW5kIHRoZXkgY29uZmlybWVkIHRoYXQgH aXQgaXMgaW5kZWVkIGxlZ2FsISANCkFmdGVyIGRldGVybWluaW5nIHRoZSBwcm9ncmFtIHdhH cyBMRUdBTCBJIGRlY2lkZWQgIldIWSBOT1QhPyE/PyINCg0KSW5pdGlhbGx5IEkgc2VudCBvH dXQgMTAsMDAwIGUtbWFpbHMuIEl0IGNvc3QgbWUgYWJvdXQgJDE1IGZvciBteSB0aW1lIA0KH b24tbGluZS4gIFRoZSBncmVhdCB0aGluZyBhYm91dCBlLW1haWwgaXMgdGhhdCBJIGRvbid0H IG5lZWQgYW55IG1vbmV5IGZvciANCnByaW50aW5nIHRvIHNlbmQgb3V0IHRoZSBwcm9ncmFtH LCBhbmQgYmVjYXVzZSBJIGFsc28gc2VuZCB0aGUgcHJvZHVjdCAocmVwb3J0cykgDQpieSBlH LW1haWwsIG15IG9ubHkgZXhwZW5zZSBpcyBteSB0aW1lLg0KDQpJbiBsZXNzIHRoYW4gb25lH IHdlZWssIEkgd2FzIHN0YXJ0aW5nIHRvIHJlY2VpdmUgb3JkZXJzIGZvciBSRVBPUlQgIzEuH DQpCeSBKYW51YXJ5IDEzLCBJIGhhZCByZWNlaXZlZCAyNiBvcmRlcnMgZm9yIFJFUE9SVCAjH MS4gWW91ciBnb2FsIGlzIHRvDQoiUkVDRUlWRSBhdCBsZWFzdCAyMCBPUkRFUlMgRk9SIFJFH UE9SVCAjMSBXSVRISU4gMiBXRUVLUy4NCklGIFlPVSBET04nVCwgU0VORCBPVVQgTU9SRSBQH Uk9HUkFNUyBVTlRJTCBZT1UgRE8uDQoNCk15IGZpcnN0IHN0ZXAgaW4gbWFraW5nICQ1MCwwH MDAgaW4gOTAgZGF5cyB3YXMgZG9uZS4gQnkgSmFudWFyeSAzMCwgSSANCmhhZCByZWNlaXZlH ZCAxOTYgb3JkZXJzIGZvciBSRVBPUlQgIzIuIFlvdXIgZ29hbCBpcyB0byAiUkVDRUlWRSBBH VCBMRUFTVA0KMTAwKyBPUkRFUlMgRk9SIFJFUE9SVCAjMiBXSVRISU4gMiBXRUVLUy4gSUYgH Tk9ULCBTRU5EDQpPVVQgTU9SRSBQUk9HUkFNUyBVTlRJTCBZT1UgRE8uDQoNCk9OQ0UgWU9VH IEhBVkUgMTAwIE9SREVSUywgVEhFIFJFU1QgSVMgRUFTWSwNCg0KUkVMQVgsIFlPVSBXSUxMH IE1BS0UgWU9VUiAkNTAsMDAwIEdPQUwuIg0KDQpXZWxsLCBJIGhhZCAxOTYgb3JkZXJzIGZvH ciBSRVBPUlQgIzIuIDk2IG1vcmUgdGhhbiBJIG5lZWRlZC4gIFNvIEkgc2F0IA0KYmFjayBhH bmQgcmVsYXhlZC4gQnkgTWFyY2ggMSwgb2YgbXkgZS1tYWlsaW5nIG9mIDEwLDAwMCwgSSAgH cmVjZWl2ZWQgJDU4LDAwMCANCiB3aXRoIG1vcmUgY29taW5nIGluIGV2ZXJ5IGRheS4gSSBwH YWlkIG9mZiBBTEwgbXkgZGVidHMgYW5kIGJvdWdodCBhIG11Y2ggDQpuZWVkZWQgbmV3IGNhH ciENCg0KUGxlYXNlIHRha2UgeW91ciB0aW1lIHRvIHJlYWQgdGhpcyBwbGFuLCBJVCBXSUxMH IENIQU5HRSBZT1VSIExJRkUNCkZPUkVWRVIkISEhIFJlbWVtYmVyLCBpdCB3b24ndCB3b3JrH IGlmIHlvdSBkb24ndCB0cnkgaXQuIFRoaXMgcHJvZ3JhbSANCmRvZXMgd29yaywgYnV0IHlvH dSBtdXN0IGZvbGxvdyBpdCBFWEFDVExZISAgRXNwZWNpYWxseSB0aGUgcnVsZXMgb2Ygbm90H IA0KdHJ5aW5nIHRvIHBsYWNlIHlvdXIgbmFtZSBpbiBhIGRpZmZlcmVudCBwbGFjZS4gIEl0H IHdvbid0IHdvcmsgYW5kIHlvdSdsbCBsb3NlIA0Kb3V0IG9uIGEgbG90IG9mIG1vbmV5ISBJH biBvcmRlciBmb3IgdGhpcyBwcm9ncmFtIHRvIHdvcmssIHlvdSBtdXN0IG1lZXQgeW91ciANH CmdvYWwgb2YgMjArIG9yZGVycyBmb3IgUkVQT1JUICMxLCBhbmQgMTAwKyBvcmRlcnMgZm9yH IFJFUE9SVCAjMiBhbmQgeW91IHdpbGwNCm1ha2UgJDUwLDAwMCBvciBtb3JlIGluIDkwIGRhH eXMuDQoNCkkgQU0gTElWSU5HIFBST09GIFRIQVQgSVQgV09SS1MhISEgSWYgeW91IGNob29zH ZSBub3QgdG8gcGFydGljaXBhdGUgaW4gdGhpcyBwcm9ncmFtLCANCkkgYW0gc29ycnkuIEl0H IHJlYWxseSBpcyBhIGdyZWF0IG9wcG9ydHVuaXR5IHdpdGgNCmxpdHRsZSBjb3N0IG9yIHJpH c2sgdG8geW91LiBJZiB5b3UgY2hvb3NlIHRvIHBhcnRpY2lwYXRlLCBmb2xsb3cgdGhlIHByH b2dyYW0NCmFuZCB5b3Ugd2lsbCBiZSBvbiB5b3VyIHdheSB0byBmaW5hbmNpYWwgc2VjdXJpH dHkuIElmIHlvdSBhcmUgYSBmZWxsb3cgYnVzaW5lc3MgDQpvd25lciBhbmQgYXJlIGluIGZpH bmFuY2lhbCB0cm91YmxlIGxpa2UgSSB3YXMsIG9yIHlvdSB3YW50IHRvIHN0YXJ0IHlvdXIgH b3duIA0KYnVzaW5lc3MsIGNvbnNpZGVyIHRoaXMgYSBzaWduIC4gSSBESUQhICQkDQoNClNpH bmNlcmVseSwNCkpvaG5hdGhvbiBSb3Vya2UNCn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+H fn5+fn5+fn5+fn5+fn5+fn5+fn5+fg0KDQpBIFBFUlNPTkFMIE5PVEUgRlJPTSBUSEUgT1JJH R0lOQVRPUiBPRiBUSElTIFBST0dSQU06DQoNCkJ5IHRoZSB0aW1lIHlvdSBoYXZlIHJlYWQgH dGhlIGVuY2xvc2VkIHByb2dyYW0gYW5kIHJlcG9ydHMsIHlvdSBzaG91bGQNCmhhdmUgY29uH Y2x1ZGVkIHRoYXQgc3VjaCBhIHByb2dyYW0sIGFuZCBvbmUgdGhhdCBpcyBsZWdhbCwgY291H bGQgbm90IA0KaGF2ZSBiZWVuIGNyZWF0ZWQgYnkgYW4gYW1hdGV1ci4gTGV0IG1lIHRlbGwgH eW91IGEgbGl0dGxlIGFib3V0IG15c2VsZi4gIEkgDQpoYWQgYSBwcm9maXRhYmxlIGJ1c2luH ZXNzIGZvciAxMCB5ZWFycy4gVGhlbiBpbiAxOTc5IG15IGJ1c2luZXNzIGJlZ2FuIA0KZmFsH bGluZyBvZmYuDQpJIHdhcyBkb2luZyB0aGUgc2FtZSB0aGluZ3MgdGhhdCB3ZXJlIHByZXZpH b3VzbHkgc3VjY2Vzc2Z1bCBmb3IgbWUsIGJ1dCANCml0IHdhc24ndCB3b3JraW5nLiBGaW5hH bGx5LCBJIGZpZ3VyZWQgaXQgb3V0LiBJdCB3YXNuJ3QgbWUsIGl0IHdhcyB0aGUgDQplY29uH b215LiAgSW5mbGF0aW9uIGFuZCByZWNlc3Npb24gaGFkIHJlcGxhY2VkIHRoZSBzdGFibGUgH ZWNvbm9teSB0aGF0IGhhZCBiZWVuIA0Kd2l0aCB1cyBzaW5jZSAxOTQ1Lg0KDQpJIGRvbid0H IGhhdmUgdG8gdGVsbCB5b3Ugd2hhdCBoYXBwZW5lZCB0byB0aGUgdW5lbXBsb3ltZW50IHJhH dGUuLi4gDQpiZWNhdXNlIG1hbnkgb2YgeW91IGtub3cgZnJvbSBmaXJzdCBoYW5kIGV4cGVyH aWVuY2UuIFRoZXJlIHdlcmUgbW9yZSBmYWlsdXJlcyANCmFuZCBiYW5rcnVwdGNpZXMgdGhhH biBldmVyIGJlZm9yZS4gVGhlIG1pZGRsZSBjbGFzcyB3YXMgdmFuaXNoaW5nLiBUaG9zZSANH CndobyBrbmV3IHdoYXQgdGhleSB3ZXJlIGRvaW5nIGludmVzdGVkIHdpc2VseSBhbmQgbW92H ZWQgdXAuIFRob3NlIHdobyBkaWQNCm5vdCwgaW5jbHVkaW5nIHRob3NlIHdobyBuZXZlciBoH YWQgYW55dGhpbmcgdG8gc2F2ZSBvciBpbnZlc3QsIHdlcmUgDQptb3ZpbmcgZG93biBpbnRvH IHRoZSByYW5rcyBvZiB0aGUgcG9vci4gQXMgdGhlIHNheWluZyBnb2VzLCAiVEhFIFJJQ0ggH R0VUDQpSSUNIRVIgQU5EIFRIRSBQT09SIEdFVCBQT09SRVIuIiAgVGhlIHRyYWRpdGlvbmFsH IG1ldGhvZHMgb2YNCm1ha2luZyBtb25leSB3aWxsIG5ldmVyIGFsbG93IHlvdSB0byAibW92H ZSB1cCIgb3IgImdldCByaWNoIiwgaW5mbGF0aW9uIA0Kd2lsbCBzZWUgdG8gdGhhdC4NCg0KH WW91IGhhdmUganVzdCByZWNlaXZlZCBpbmZvcm1hdGlvbiB0aGF0IGNhbiBnaXZlIHlvdSBmH aW5hbmNpYWwgZnJlZWRvbSANCmZvciB0aGUgcmVzdCBvZiB5b3VyIGxpZmUsIHdpdGggIk5PH IFJJU0siIGFuZCAiSlVTVCBBIExJVFRMRSBCSVQgT0YgRUZGT1JULiINCllvdSBjYW4gbWFrH ZSBtb3JlIG1vbmV5IGluIHRoZSBuZXh0IGZldyBtb250aHMgdGhhbiB5b3UgaGF2ZSBldmVyH IA0KaW1hZ2luZWQuDQpJIHNob3VsZCBhbHNvIHBvaW50IG91dCB0aGF0IEkgd2lsbCBub3QgH c2VlIGEgcGVubnkgb2YgdGhpcyBtb25leSwgbm9yIA0KYW55b25lIGVsc2Ugd2hvIGhhcyBwH cm92aWRlZCBhIHRlc3RpbW9uaWFsIGZvciB0aGlzIHByb2dyYW0uDQoNCkkgaGF2ZSByZXRpH cmVkIGZyb20gdGhlIHByb2dyYW0gYWZ0ZXIgc2VuZGluZyB0aG91c2FuZHMgYW5kIHRob3VzH YW5kcyANCm9mIHByb2dyYW1zLiBGb2xsb3cgdGhlIHByb2dyYW0gIEVYQUNUTFkgQVMgSU5TH VFJVQ1RFRC4gRG8gbm90DQpjaGFuZ2UgaXQgaW4gYW55IHdheS4gSXQgd29ya3MgZXhjZWVkH aW5nbHkgd2VsbCBhcyBpdCBpcyBub3cuDQoNClJlbWVtYmVyIHRvIGUtbWFpbCBhIGNvcHkgH b2YgdGhpcyBleGNpdGluZyByZXBvcnQgdG8gZXZlcnlvbmUgeW91IGNhbg0KdGhpbmsgb2YuH IE9uZSBvZiB0aGUgcGVvcGxlIHlvdSBzZW5kIHRoaXMgdG8gbWF5IHNlbmQgb3V0IDUwLDAwH MC4uLmFuZCANCnlvdXIgbmFtZSB3aWxsIGJlIG9uIGV2ZXJ5b25lIG9mIHRoZW0hIFJlbWVtH YmVyIHRob3VnaCwgdGhlIG1vcmUgeW91IHNlbmQgDQpvdXQsIHRoZSBtb3JlIHBvdGVudGlhH bCBjdXN0b21lcnMgeW91IHdpbGwgcmVhY2guDQoNClNvIG15IGZyaWVuZCwgSSBoYXZlIGdpH dmVuIHlvdSB0aGUgaWRlYXMsIGluZm9ybWF0aW9uLCBtYXRlcmlhbHMgYW5kDQpvcHBvcnR1H bml0eSB0byBiZWNvbWUgZmluYW5jaWFsbHkgaW5kZXBlbmRlbnQuDQoNCklUIElTIFVQIFRPH IFlPVSBOT1chICBETyBJVCAhDQp+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+H fn5+fn5+fn5+fn5+fn4NCg0KQmVmb3JlIHlvdSBkZWxldGUgdGhpcyBwcm9ncmFtIGZyb20gH eW91ciBpbiBib3gsIGFzIEkgYWxtb3N0IGRpZCwgdGFrZSANCmEgbGl0dGxlIHRpbWUgdG8gH cmVhZCBpdCBhbmQgUkVBTExZIFRISU5LIEFCT1VUIElULiBHZXQgYSBwZW5jaWwgYW5kIGZpH Z3VyZSBvdXQgDQp3aGF0IGNvdWxkIGhhcHBlbiB3aGVuIFlPVSBwYXJ0aWNpcGF0ZS4gRmlnH dXJlIG91dCB0aGUgd29yc3QgcG9zc2libGUNCnJlc3BvbnNlIGFuZCBubyBtYXR0ZXIgaG93H IHlvdSBjYWxjdWxhdGUgaXQsIHlvdSB3aWxsIHN0aWxsIG1ha2UgYSBsb3QgDQpvZiBtb25lH eSENCllvdSB3aWxsIGRlZmluaXRlbHkgZ2V0IGJhY2sgd2hhdCB5b3UgaW52ZXN0ZWQuIEFuH eSBkb3VidHMgeW91IGhhdmUgDQp3aWxsIHZhbmlzaCB3aGVuIHlvdXIgZmlyc3Qgb3JkZXJzH IGNvbWUgaW4uDQoNCiQkJCAgSVQgV09SS1MhISEgICQkJA0KDQpKb2R5IEphY29icw0KUmljH aG1vbmQsIFZBDQp+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+H fn5+fn4NCg0KSEVSRSdTIEhPVyBUSElTIEFNQVpJTkcgUFJPR1JBTSBXSUxMIE1BS0UgWU9VH DQpUSE9VU0FORFMgT0YgRE9MTEFSJCQkJCEhISENCg0KVGhpcyBtZXRob2Qgb2YgcmFpc2luH ZyBjYXBpdGFsIFJFQUxMWSBXT1JLUyAxMDAlIEVWRVJZICBUSU1FLg0KSSBhbSBzdXJlIHRoH YXQgeW91IGNvdWxkIHVzZSB1cCB0byAkNTAsMDAwIG9yIG1vcmUgaW4gdGhlIG5leHQgOTAgH ZGF5cy4NCkJlZm9yZSB5b3Ugc2F5ICJCVUxMLi4uICIsIHBsZWFzZSByZWFkIHRoaXMgcHJvH Z3JhbSBjYXJlZnVsbHkuDQpUaGlzIGlzIG5vdCBhIGNoYWluIGxldHRlciwgYnV0IGEgcGVyH ZmVjdGx5IGxlZ2FsIG1vbmV5IG1ha2luZyANCmJ1c2luZXNzLg0KDQpBcyB3aXRoIGFsbCBtH dWx0aS1sZXZlbCBidXNpbmVzc2VzLCB3ZSBidWlsZCBvdXIgYnVzaW5lc3MgYnkgcmVjcnVpH dGluZyANCm5ldyBwYXJ0bmVycyBhbmQgc2VsbGluZyBvdXIgcHJvZHVjdHMuIEV2ZXJ5IHN0H YXRlIGluIHRoZSBVU0EgYWxsb3dzIHlvdSB0bw0KcmVjcnVpdCBuZXcgbXVsdGktbGV2ZWwgH YnVzaW5lc3MgcGFydG5lcnMsIGFuZCB3ZSBzZWxsIGFuZCBkZWxpdmVyIGEgDQpwcm9kdWN0H IGZvciBFVkVSWSBkb2xsYXIgcmVjZWl2ZWQuDQoNCllPVVIgT1JERVJTIENPTUUgQlkgTUFJH TCBBTkQgQVJFIEZJTExFRCBCWSBFLU1BSUwsDQpzbyB5b3UgYXJlIG5vdCBpbnZvbHZlZCBpH biBwZXJzb25hbCBzZWxsaW5nLiBZb3UgZG8gaXQgcHJpdmF0ZWx5IGluIA0KeW91ciBvd24gH aG9tZSwgc3RvcmUgb3Igb2ZmaWNlLiBUaGlzIGlzIHRoZSBFQVNJRVNUIG1hcmtldGluZyBwH bGFuIGFueXdoZXJlIQ0KSXQgaXMgc2ltcGx5IG9yZGVyIGZpbGxpbmcgYnkgZW1haWwhDQoNH CioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqH KioqKioNClRoZSBwcm9kdWN0IGlzIGluZm9ybWF0aW9uYWwgYW5kIGluc3RydWN0aW9uYWwgH bWF0ZXJpYWwsIGtleXMgIHRvICB0aGUgDQpzZWNyZXRzIGZvciBldmVyeW9uZSBvbiAgdG8gH b3BlbiB0aGUgZG9vcnMgdG8gdGhlIG1hZ2ljIHdvcmxkIG9mIEUtQ09NTUVSQ0UgLA0KdGhlH IGluZm9ybWF0aW9uIGhpZ2h3YXksIHRoZSB3YXZlIG9mIHRoZSBmdXR1cmUgIQ0KDQpQTEFOH IFNVTU1BUlk6DQoNCigxKSBZb3Ugb3JkZXIgdGhlIDQgcmVwb3J0cyBsaXN0ZWQgYmVsb3cgH ICgkNSBlYWNoKSAgVGhleSBjb21lIHRvIHlvdSANCmJ5IGVtYWlsLg0KDQooMikgIFNhdmUgH YSBjb3B5IG9mIHRoaXMgZW50aXJlIGxldHRlciBhbmQgcHV0IHlvdXIgbmFtZSBhZnRlciBSH ZXBvcnQgDQojMSBhbmQgbW92ZSB0aGUgb3RoZXIgbmFtZXMgZG93bi4NCg0KKDMpICBVc2UgH YW55IG9mIHRoZSBodW5kcmVkcyBvZiBidWxrIGVtYWlsIHNlcnZpY2VzIChzZWFyY2ggZm9yH ICJCdWxrIA0KRW1haWwiKWFuZCBoYXZlIHRoZW0gc2VuZCAyNSwwMDAgLSA1MCwwMDAgZW1hH aWxzIGZvciB5b3UgKGFib3V0ICQ0OSspDQoNCig0KSAgT3JkZXJzIHdpbGwgY29tZSB0byB5H b3UgYnkgcG9zdGFsIG1haWwgLSAgc2ltcGx5IGVtYWlsIHRoZW0gdGhlIA0KUmVwb3J0IHRoH ZXkgb3JkZXJlZC4NCg0KICAgICBMZXQgbWUgYXNrIHlvdSAtIGlzbid0IHRoaXMgYWJvdXQgH YXMgZWFzeSBhcyBpdCBnZXRzPw0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqH KioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQpCeSB0aGUgd2F5IHRoZXJlIGFyZSBvH dmVyIDUwIE1JTExJT04gZW1haWwgYWRkcmVzc2VzIHdpdGggbWlsbGlvbnMgbW9yZQ0Kam9pH bmluZyB0aGUgSW50ZXJuZXQgZWFjaCB5ZWFyIHNvIGRvbid0IHdvcnJ5IGFib3V0ICJydW5uH aW5nIG91dCIgb3IgDQoic2F0dXJhdGlvbiIuDQpQZW9wbGUgYXJlIHVzZWQgdG8gc2VlaW5nH IGFuZCBoZWFyaW5nIHRoZSBzYW1lIGFkdmVydGlzZW1lbnRzIGV2ZXJ5IGRheSANCm9uIHJhH ZGlvL1RWLiBIb3cgbWFueSB0aW1lcyBoYXZlIHlvdSByZWNlaXZlZCB0aGUgc2FtZSBwaXp6H YSBmbHllcnMgb24gDQp5b3VyIGRvb3I/IFRoZW4gb25lIGRheSB5b3UgYXJlIGh1bmdyeSBmH b3IgcGl6emEgYW5kIHlvdSBvcmRlciBvbmUuIFNhbWUgDQp0aGluZyB3aXRoIHRoaXMgbGV0H dGVyLiBJIHJlY2VpdmVkIHRoaXMgbGV0dGVyIG1hbnkgdGltZXMgLSB0aGVuIG9uZSBkYXkgH SSANCmRlY2lkZWQgaXQgd2FzIHRpbWUgdG8gdHJ5IGl0IQ0KDQoqKioqKioqKioqKioqKioqH KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQpZT1UgQ0FOH IFNUQVJUIFRPREFZIC0gSlVTVCBETyBUSEVTRSBFQVNZIFNURVBTOg0KDQpTVEVQICMxLiAgH T1JERVIgVEhFIEZPVVIgUkVQT1JUUw0KDQpPcmRlciB0aGUgZm91ciByZXBvcnRzIHNob3duH IG9uIHRoZSBsaXN0IGJlbG93ICh5b3UgY2FuJ3Qgc2VsbCB0aGVtIGlmIA0KeW91IGRvbid0H IG9yZGVyIHRoZW0pLiAtLSBGb3IgZWFjaCByZXBvcnQsIHNlbmQgJDUuMDBDQVNILCB0aGUgH TkFNRSAmIE5VTUJFUg0KT0YgVEhFIFJFUE9SVCBZT1UgQVJFICBPUkRFUklORywgWU9VUiBFH LU1BSUwgQUREUkVTUywgYW5kDQpZT1VSIE5BTUUgJiBSRVRVUk4gQUREUkVTUyAgdG8gdGhlH IHBlcnNvbiB3aG9zZSBuYW1lIGFwcGVhcnMgb24NCnRoZSBsaXN0IG5leHQgdG8gdGhlIHJlH cG9ydC4gTUFLRSBTVVJFIFlPVVIgUkVUVVJOIEFERFJFU1MgSVMgT04NCllPVVIgRU5WRUxPH UEUgSU4gQ0FTRSBPRiBBTlkgTUFJTCBQUk9CTEVNUyENCg0KV2l0aGluIGEgZmV3IGRheXMgH eW91IHdpbGwgcmVjZWl2ZSwgYnkgZS1tYWlsLCBlYWNoIG9mIHRoZSBmb3VyIA0KcmVwb3J0H cy4NClNhdmUgdGhlbSBvbiB5b3VyIGNvbXB1dGVyIHNvIHlvdSBjYW4gc2VuZCB0aGVtIHRvH IHRoZSAxLDAwMCdzIG9mDQpwZW9wbGUgd2hvIHdpbGwgb3JkZXIgdGhlbSBmcm9tIHlvdS4NH Cg0KU1RFUCAjMi4gQUREIFlPVVIgTUFJTElORyBBRERSRVNTIFRPIFRISVMgTEVUVEVSDQoNH CmEuIExvb2sgYmVsb3cgZm9yIHRoZSBsaXN0aW5nIG9mIHRoZSBmb3VyIHJlcG9ydHMuDQpiH LiBBZnRlciB5b3UndmUgb3JkZXJlZCB0aGUgZm91ciByZXBvcnRzLCBkZWxldGUgdGhlIG5hH bWUgYW5kDQphZGRyZXNzIHVuZGVyIFJFUE9SVCAjNC4gVGhpcyBwZXJzb24gaGFzIG1hZGUgH aXQgdGhyb3VnaCB0aGUgY3ljbGUuDQpjLiBNb3ZlIHRoZSBuYW1lIGFuZCBhZGRyZXNzIHVuH ZGVyIFJFUE9SVCAjMyBkb3duIHRvIFJFUE9SVCAjNC4NCmQuIE1vdmUgdGhlIG5hbWUgYW5kH IGFkZHJlc3MgdW5kZXIgUkVQT1JUICMyIGRvd24gdG8gUkVQT1JUICMzLg0KZS4gTW92ZSB0H aGUgbmFtZSBhbmQgYWRkcmVzcyB1bmRlciBSRVBPUlQgIzEgZG93biB0byBSRVBPUlQgIzIuH DQpmLiBJbnNlcnQgeW91ciBuYW1lL2FkZHJlc3MgaW4gdGhlIFJFUE9SVCAjMSBwb3NpdGlvH bi4NCg0KICAgUGxlYXNlIG1ha2Ugc3VyZSB5b3UgQ09QWSBBTEwgSU5GT1JNQVRJT04sIGV2H ZXJ5IG5hbWUgYW5kDQogICBhZGRyZXNzLCBBQ0NVUkFURUxZIQ0KDQpTVEVQICMzLiBUYWtlH IHRoaXMgZW50aXJlIGxldHRlciwgaW5jbHVkaW5nIHRoZSBtb2RpZmllZCBsaXN0IG9mIG5hH bWVzLCANCmFuZA0Kc2F2ZSBpdCB0byB5b3VyIGNvbXB1dGVyLiBNYWtlIE5PIGNoYW5nZXMgH dG8gdGhlc2UgaW5zdHJ1Y3Rpb25zLg0KTm93IHlvdSBhcmUgcmVhZHkgdG8gdXNlIHRoaXMgH ZW50aXJlIGVtYWlsIHRvIHNlbmQgYnkgZW1haWwgdG8gDQpwcm9zcGVjdHMuDQoNClJlcG9yH dCAjMSB3aWxsIHRlbGwgeW91IGhvdyB0byBkb3dubG9hZCBidWxrIGVtYWlsIHNvZnR3YXJlH IGFuZCBlbWFpbA0KYWRkcmVzc2VzIHNvIHlvdSBjYW4gc2VuZCBpdCBvdXQgdG8gdGhvdXNhH bmRzIG9mIHBlb3BsZSB3aGlsZSB5b3UgDQpzbGVlcCENClJlbWVtYmVyIHRoYXQgNTAsMDAwH KyBuZXcgcGVvcGxlIGFyZSBqb2luaW5nIHRoZSBJbnRlcm5ldCBldmVyeSBtb250aC4NCg0KH WW91ciBjb3N0IHRvIHBhcnRpY2lwYXRlIGluIHRoaXMgaXMgcHJhY3RpY2FsbHkgbm90aGluH ZyAoc3VyZWx5IHlvdSBjYW4gDQphZmZvcmQgJDIwIGFuZCBpbml0aWFsIGJ1bGsgbWFpbGluH ZyBjb3N0KS4gWW91IG9idmlvdXNseSBhbHJlYWR5IGhhdmUgYSANCmNvbXB1dGVyIGFuZCBhH biBJbnRlcm5ldCBjb25uZWN0aW9uIGFuZCBlLW1haWwgaXMgRlJFRSENCg0KVGhlcmUgYXJlH IHR3byBwcmltYXJ5IG1ldGhvZHMgb2YgYnVpbGRpbmcgeW91ciBkb3dubGluZToNCg0KTUVUH SE9EICMxOiBTRU5ESU5HIEJVTEsgRS1NQUlMIExldCdzIHNheSB0aGF0IHlvdSBkZWNpZGUgH dG8NCnN0YXJ0IHNtYWxsLCBqdXN0IHRvIHNlZSBob3cgaXQgZ29lcywgYW5kIHdlJ2xsIGFzH c3VtZSB5b3UgYW5kIGFsbCANCnRob3NlIGludm9sdmVkIGVtYWlsIG91dCBvbmx5IDIsMDAwH IHByb2dyYW1zIGVhY2guIExldCdzIGFsc28gYXNzdW1lIHRoYXQgdGhlDQptYWlsaW5nIHJlH Y2VpdmVzIGEgMC41JSByZXNwb25zZS4gVGhlIHJlc3BvbnNlIGNvdWxkIGJlIG11Y2ggYmV0H dGVyLg0KQWxzbywgbWFueSBwZW9wbGUgd2lsbCBlbWFpbCBvdXQgaHVuZHJlZHMgb2YgdGhvH dXNhbmRzIG9mIHByb2dyYW1zDQppbnN0ZWFkIG9mIDIsMDAwIChXaHkgc3RvcCBhdCAyMDAwH PykuIEJ1dCBjb250aW51aW5nIHdpdGggdGhpcyBleGFtcGxlLA0KeW91IHNlbmQgb3V0IG9uH bHkgMiwwMDAgcHJvZ3JhbXMuIFdpdGggYSAwLjUlIHJlc3BvbnNlLCB0aGF0IGlzIG9ubHkgH MTANCm9yZGVycyBmb3IgUkVQT1JUICMxLg0KDQpSRVBPUlQgIyAxDQpUaG9zZSAxMCBwZW9wH bGUgcmVzcG9uZCBieSBzZW5kaW5nIG91dCAyLDAwMHByb2dyYW1zIGVhY2ggZm9yIGEgdG90H YWwNCm9mIDIwLDAwMC4gT3V0IG9mIHRob3NlIDAuNSUsIDEwMCBwZW9wbGUgcmVzcG9uZCBhH bmQgb3JkZXIgZm9yDQoNClJFUE9SVCAjMi4NClRob3NlIDEwMCBtYWlsIG91dCAyLDAwMCBwH cm9ncmFtcyBlYWNoIGZvciBhIHRvdGFsIG9mIDIwMCwwMDAuIFRoZSAwLjUlDQpyZXNwb25zH ZSB0byB0aGF0IGlzIDEsMDAwIG9yZGVycyBmb3INCg0KUkVQT1JUICMzLg0KVGhvc2UgMSwwH MDAgc2VuZCBvdXQgMiwwMDAgcHJvZ3JhbXMgZWFjaCBmb3IgYSAyLDAwMCwwMDAgdG90YWwuH DQpUaGUgMC41JSByZXNwb25zZSB0byB0aGF0IGlzIDEwLDAwMCBvcmRlcnMgZm9yDQoNClJFH UE9SVCAjNC4NClRoYXQncyAxMCwwMDAgJDUgYmlsbHMgZm9yIHlvdS4gQ0FTSCEhIQ0KWW91H ciB0b3RhbCBpbmNvbWUgaW4gdGhpcyBleGFtcGxlIGlzICQ1MCArICQ1MDAgKyAkNSwwMDAgH Kz4gJDUwLDAwMA0KZm9yIGEgdG90YWwgb2YgJDU1LDU1MCEhIQ0KDQpSRU1FTUJFUiBGUklFH TkQsIFRISVMgSVMgQVNTVU1JTkcgMSw5OTAgT1VUIE9GIFRIRQ0KMiwwMDAgUEVPUExFIFlPH VSBNQUlMIFRPIFdJTEwgRE8gQUJTT0xVVEVMWSBOT1RISU5HDQpBTkQgVFJBU0ggVEhJUyBQH Uk9HUkFNISAgIERBUkUgVE8gVEhJTksgRk9SIEENCk1PTUVOVCBXSEFUIFdPVUxEIEhBUFBFH TiBJRiBFVkVSWU9ORSwgT1IgSEFMRg0KU0VOVCBPVVQgMTAwLDAwMCBQUk9HUkFNUyBJTlNUH RUFEIE9GIDIsMDAwLiBCZWxpZXZlIG1lLA0KbWFueSBwZW9wbGUgd2lsbCBkbyBqdXN0IHRoH YXQsIGFuZCBtb3JlIQ0KDQpNRVRIT0QgIzIgLSBQTEFDSU5HIEZSRUUgQURTIE9OIFRIRSBJH TlRFUk5FVA0KDQpBZHZlcnRpc2luZyBvbiB0aGUgSW50ZXJuZXQgaXMgdmVyeSwgdmVyeSBpH bmV4cGVuc2l2ZSwgYW5kIHRoZXJlIGFyZQ0KSFVORFJFRFMgb2YgRlJFRSBwbGFjZXMgdG8gH YWR2ZXJ0aXNlLiBMZXQncyBzYXkgeW91IGRlY2lkZSB0byBzdGFydA0Kc21hbGwganVzdCB0H byBzZWUgaG93IHdlbGwgaXQgd29ya3MuIEFzc3VtZSB5b3VyIGdvYWwgaXMgdG8gZ2V0IE9OH TFkgMTANCnBlb3BsZSB0byBwYXJ0aWNpcGF0ZSBvbiB5b3VyIGZpcnN0IGxldmVsLiAoUGxhH Y2luZyBhIGxvdCBvZiBGUkVFIGFkcyANCm9uIHRoZSBJbnRlcm5ldCB3aWxsIEVBU0lMWSBnH ZXQgYSBsYXJnZXIgcmVzcG9uc2UuKSBBbHNvIGFzc3VtZSB0aGF0IGV2ZXJ5b25lDQplbHNlH IGluIFlPVVIgT1JHQU5JWkFUSU9OIGdldHMgT05MWSAxMCBkb3dubGluZSBtZW1iZXJzLg0KH TG9vayBob3cgdGhpcyBzbWFsbCBudW1iZXIgYWNjdW11bGF0ZXMgdG8gYWNoaWV2ZSB0aGUgH U1RBR0dFUklORw0KcmVzdWx0cyBiZWxvdzoNCg0KMXN0IGxldmVsLS15b3VyIGZpcnN0IDEwH IHNlbmQgeW91ICQ1Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4kNTANCjJuZCBsH ZXZlbC0tMTAgbWVtYmVycyBmcm9tIHRob3NlIDEwICgkNSB4IDEwMCkuLi4uLi4uLi4uLi4uH JDUwMA0KM3JkIGxldmVsLS0xMCBtZW1iZXJzIGZyb20gdGhvc2UgMTAwICgkNSB4IDEsMDAwH KS4uLi4uLi4uJDUsMDAwDQo0dGggbGV2ZWwtLTEwIG1lbWJlcnMgZnJvbSB0aG9zZSAxLDAwH MCAoJDUgeCAxMCwwMDApLi4kNTAsMDAwDQoNCiQkJCQkJCAgICAgVEhJUyBUT1RBTFMgLS0tH LS0tLS0tLSQ1NSw1NTAgICAgICQkJCQkJA0KDQpBTUFaSU5HIElTTidUIElUPyAgUmVtZW1iH ZXIgZnJpZW5kcywgdGhpcyBhc3N1bWVzIHRoYXQgdGhlIHBlb3BsZQ0Kd2hvIHBhcnRpY2lwH YXRlIG9ubHkgcmVjcnVpdCAxMCBwZW9wbGUgZWFjaC4gVGhpbmsgZm9yIGEgbW9tZW50IHdoH YXQNCndvdWxkIGhhcHBlbiBpZiB0aGV5IGdvdCAyMCBwZW9wbGUgdG8gcGFydGljaXBhdGUhH IE1vc3QgcGVvcGxlIGdldCAxMDAncw0Kb2YgcGFydGljaXBhbnRzIGFuZCBtYW55IHdpbGwgH Y29udGludWUgdG8gd29yayB0aGlzIHByb2dyYW0sIHNlbmRpbmcgDQpvdXQgcHJvZ3JhbXMgH V0lUSCBZT1VSIE5BTUUgT04gVEhFTSBmb3IgeWVhcnMhDQogICAgICAgICAgICAgICAgICAgH ICAgICAgICAgICAgICBUSElOSyBBQk9VVCBJVCENCn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+H fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fg0KDQpQZW9wbGUgYXJlIGdvaW5nIHRvIGdldCBlH bWFpbHMgYWJvdXQgdGhpcyBwbGFuIGZyb20geW91IG9yIHNvbWVib2R5IGVsc2UgDQphbmQgH bWFueSB3aWxsIHdvcmsgdGhpcyBwbGFuIC0gdGhlIHF1ZXN0aW9uIGlzIC0NCg0KRG9uJ3QgH eW91IHdhbnQgeW91ciBuYW1lIHRvIGJlIG9uIHRoZSBlbWFpbHMgdGhleSB3aWxsIHNlbmQgH b3V0Pw0KDQoqICogKiAgIERPTidUIE1JU1MgT1VUISEhICogKiAqIEpVU1QgVFJZIElUIE9OH Q0UhISEgKiAqICoNCg0KKiAqIFNFRSBXSEFUIEhBUFBFTlMhISEgKioqIFlPVSdMTCBCRSBBH TUFaRUQhISEqICoNCg0Kfn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+H fn5+fn5+fn5+DQoNCkFMV0FZUyBQUk9WSURFIFNBTUUtREFZIFNFUlZJQ0UgT04gQUxMIE9SH REVSUyENCg0KVGhpcyB3aWxsIGd1YXJhbnRlZSB0aGF0IHRoZSBlLW1haWwgVEhFWSBzZW5kH IG91dCB3aXRoIFlPVVIgbmFtZSBhbmQNCmFkZHJlc3Mgb24gaXQgd2lsbCBiZSBwcm9tcHQgH YmVjYXVzZSB0aGV5IGNhbid0IGFkdmVydGlzZSB1bnRpbCB0aGV5IA0KcmVjZWl2ZSB0aGUgH cmVwb3J0IQ0Kfn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+H fn5+DQoNCkdFVCBTVEFSVEVEIFRPREFZOiAgUExBQ0UgWU9VUiBPUkRFUiBGT1IgVEhFIEZPH VVINClJFUE9SVFMgTk9XLg0KDQpOb3RlczogLS0gQUxXQVlTIFNFTkQgJDUgQ0FTSCAoVS5TH LiBDVVJSRU5DWSkgRk9SIEVBQ0gNClJFUE9SVC4gIENIRUNLUyBOT1QgQUNDRVBURUQuIE1hH a2Ugc3VyZSB0aGUgY2FzaCBpcyBjb25jZWFsZWQNCmJ5IHdyYXBwaW5nIGl0IGluIHR3byBzH aGVldHMgb2YgcGFwZXIuIE9uIG9uZSBvZiB0aG9zZSBzaGVldHMgb2YgcGFwZXIgDQp3cml0H ZToNCg0KKGEpIHRoZSBudW1iZXIgJiBuYW1lIG9mIHRoZSAgcmVwb3J0IHlvdSBhcmUgb3JkH ZXJpbmcsDQooYikgeW91ciBlLW1haWwgYWRkcmVzcywgYW5kDQooYykgeW91ciBuYW1lICYgH cG9zdGFsIGFkZHJlc3MuDQoNCg0KUkVQT1JUICMxDQoNCiJUaGUgSW5zaWRlcidzIEd1aWRlH IHRvIEFkdmVydGlzaW5nIGZvciBGcmVlIG9uIHRoZSBJbnRlcm5ldC4iDQoNCk9SREVSIFJFH UE9SVCAjIDEgRlJPTToNCg0KS2F0aGllIE1vb3JlDQoxNiBQbGFudGF0aW9uIE9ha3MgRHJpH dmUNClBpY2F5dW5lLCBNUyAgMzk0NjYNCg0KUkVQT1JUIyAyDQoNCiJUaGUgSW5zaWRlcidzH IEd1aWRlIHRvIFNlbmRpbmcgQnVsayBFLU1haWwgb24gdGhlIEludGVybmV0LiINCg0KTWF0H dCBNY0tpbm5leQ0KMTAgU291dGggQ292ZSAjMzINCldlbmF0Y2hlZSwgV0EgOTg4MDENCg0KH DQoNCg0KUkVQT1JUICMgMw0KDQoiIFRoZSBTZWNyZXRzIHRvIE11bHRpbGV2ZWwgTWFya2V0H aW5nIG9uIHRoZSBJbnRlcm5ldC4iDQoNClNDT1RUIE1BUkxPV0UNClAgTyBCT1ggMTcxNTM2H DQpJUlZJTkcsIFRYICAgNzUwMTcNCg0KDQpSRVBPUlQgIyA0DQoNCiJIb3cgdG8gQmVjb21lH IGEgTWlsbGlvbmFpcmUgdXRpbGl6aW5nIHRoZSBQb3dlciBvZiBNdWx0aWxldmVsDQpNYXJrH ZXRpbmcgYW5kIHRoZSBJbnRlcm5ldC4iDQoNCkhFTEVOIFNBTEVFQlkNCjEwMzAxIE4uIEtJH TkdTIEhXWS4gICMgMTMtNQ0KTVlSVExFICBCRUFDSCwgUy4gQy4gMjk1NzINCg0KDQoNCg0KH DQogICoqKioqKiogVElQUyBGT1IgU1VDQ0VTUyAqKioqKioqDQoNClRSRUFUIFRISVMgQVMgH WU9VUiBCVVNJTkVTUyEgQmUgcHJvbXB0LCBwcm9mZXNzaW9uYWwsIGFuZCBmb2xsb3cNCnRoH ZSBkaXJlY3Rpb25zIGFjY3VyYXRlbHkuIC0tIFNlbmQgZm9yIHRoZSBmb3VyIHJlcG9ydHMgH SU1NRURJQVRFTFkgc28gDQp5b3Ugd2lsbCBoYXZlIHRoZW0gd2hlbiB0aGUgb3JkZXJzIHN0H YXJ0IGNvbWluZyBpbiBiZWNhdXNlOiAgV2hlbiB5b3UgDQpyZWNlaXZlIGEgJDUgb3JkZXIsH IHlvdSBNVVNUIHNlbmQgb3V0IHRoZSByZXF1ZXN0ZWQgcHJvZHVjdC9yZXBvcnQuICBJdCBpH cyANCnJlcXVpcmVkIGZvciB0aGlzIHRvIGJlIGEgbGVnYWwgYnVzaW5lc3MgYW5kIHRoZXkgH bmVlZCB0aGUgcmVwb3J0cyB0byBzZW5kIG91dCANCnRoZWlyIGxldHRlcnMgKHdpdGggeW91H ciBuYW1lIG9uIHRoZW0hKSAgIC0tDQoNCkFMV0FZUyBQUk9WSURFIFNBTUUtREFZIFNFUlZJH Q0UgT04gVEhFIE9SREVSUyBZT1UNClJFQ0VJVkUuIC0tIEJlIHBhdGllbnQgYW5kIHBlcnNpH c3RlbnQgd2l0aCB0aGlzIHByb2dyYW0gLSBJZiB5b3UgZm9sbG93IA0KdGhlIGluc3RydWN0H aW9ucyBleGFjdGx5IC0gcmVzdWx0cyBXSUxMIGZvbGxvdy4gICQkJCQNCg0KDQoqKioqKioqH IFlPVVIgU1VDQ0VTUyBHVUlERUxJTkVTICoqKioqKioNCg0KRm9sbG93IHRoZXNlIGd1aWRlH bGluZXMgdG8gZ3VhcmFudGVlIHlvdXIgc3VjY2VzczoNCklmIHlvdSBkb24ndCByZWNlaXZlH IDIwIG9yZGVycyBmb3IgUkVQT1JUICMxIHdpdGhpbiB0d28gd2Vla3MsIGNvbnRpbnVlDQphH ZHZlcnRpc2luZyBvciBzZW5kaW5nIGUtbWFpbHMgdW50aWwgeW91IGRvLiBUaGVuLCBhIGNvH dXBsZSBvZiB3ZWVrcyANCmxhdGVyIHlvdSBzaG91bGQgcmVjZWl2ZSBhdCBsZWFzdCAxMDAgH b3JkZXJzIGZvciBSRVBPUlQjMi4gSWYgeW91IGRvbid0LCBjb250aW51ZSANCmFkdmVydGlzH aW5nIG9yIHNlbmRpbmcgZS1tYWlscyB1bnRpbCB5b3UgZG8uDQoNCk9uY2UgeW91IGhhdmUgH cmVjZWl2ZWQgMTAwIG9yIG1vcmUgb3JkZXJzIGZvciBSRVBPUlQgIzIsIFlPVSBDQU4NClJFH TEFYLCBiZWNhdXNlIHRoZSBzeXN0ZW0gaXMgYWxyZWFkeSB3b3JraW5nIGZvciB5b3UsIGFuH ZCB0aGUgY2FzaCB3aWxsDQpjb250aW51ZSB0byByb2xsIGluIQ0KDQpUSElTIElTIElNUE9SH VEFOVCBUTyBSRU1FTUJFUjogRXZlcnkgdGltZSB5b3VyIG5hbWUgaXMgbW92ZWQNCmRvd24gH b24gdGhlIGxpc3QsIHlvdSBhcmUgcGxhY2VkIGluIGZyb250IG9mIGEgRElGRkVSRU5UIHJlH cG9ydC4gWW91IA0KY2FuIEtFRVAgVFJBQ0sgb2YgeW91ciBQUk9HUkVTUyBieSB3YXRjaGluH ZyB3aGljaCByZXBvcnQgcGVvcGxlIGFyZQ0Kb3JkZXJpbmcgZnJvbSB5b3UuDQoNClRvIGdlH bmVyYXRlIG1vcmUgaW5jb21lLCBzaW1wbHkgc2VuZCBhbm90aGVyIGJhdGNoIG9mIGUtbWFpH bHMgb3IgDQpjb250aW51ZSBwbGFjaW5nIGFkcyBhbmQgc3RhcnQgdGhlIHdob2xlIHByb2NlH c3MgYWdhaW4hIFRoZXJlIGlzIG5vIGxpbWl0IHRvIA0KdGhlIGluY29tZSB5b3Ugd2lsbCBnH ZW5lcmF0ZSBmcm9tIHRoaXMgYnVzaW5lc3MhDQoNCkJlZm9yZSB5b3UgbWFrZSB5b3VyIGRlH Y2lzaW9uIGFzIHRvIHdoZXRoZXIgb3Igbm90IHlvdSBwYXJ0aWNpcGF0ZSBpbiANCnRoaXMgH cHJvZ3JhbS4gUGxlYXNlIGFuc3dlciBvbmUgcXVlc3Rpb24uICBBUkUgWU9VICBIQVBQWSBXH SVRIIFlPVVINClBSRVNFTlQgSU5DT01FIE9SIEpPQj8gICBJZiB0aGUgYW5zd2VyIGlzIG5vH LCB0aGVuIHBsZWFzZSBsb29rIGF0IHRoZQ0KZm9sbG93aW5nIGZhY3RzIGFib3V0IHRoaXMgH c3VwZXIgc2ltcGxlIE1MTSBwcm9ncmFtOg0KDQogIDEuICAgIE5PIGZhY2UgdG8gZmFjZSBzH ZWxsaW5nLCBOTyBtZWV0aW5ncywgTk8gaW52ZW50b3J5IQ0KICAgICAgICAgTk8gVGVsZXBoH b25lIGNhbGxzLCBOTyBiaWcgY29zdCB0byBzdGFydCEsIE5vdGhpbmcgdG8gbGVhcm4sDQogH ICAgICAgICBOTyBza2lsbHMgbmVlZGVkISAgKFN1cmVseSB5b3Uga25vdyBob3cgdG8gc2VuH ZCBlbWFpbD8pDQoNCjIuICAgICBObyBlcXVpcG1lbnQgdG8gYnV5IC0geW91IGFscmVhZHkgH aGF2ZSBhIGNvbXB1dGVyIGFuZCBJbnRlcm5ldA0KICAgICAgICAgY29ubmVjdGlvbiAtIHNvH IHlvdSBoYXZlIGV2ZXJ5dGhpbmcgeW91IG5lZWQgdG8gZmlsbCBvcmRlcnMhDQoNCjMuICAgH ICBZb3UgYXJlIHNlbGxpbmcgYSBwcm9kdWN0IHdoaWNoIGRvZXMgTk9UIENPU1QgQU5ZVEhJH TkcgVE8NCiAgICAgICAgIFBST0RVQ0UgT1IgU0hJUCEgIChFbWFpbGluZyBjb3BpZXMgb2YgH dGhlIHJlcG9ydHMgaXMgRlJFRSEpDQoNCjQuICAgIEFsbCBvZiB5b3VyIGN1c3RvbWVycyBwH YXkgeW91IGluIENBJCRIIQ0KDQpUaGlzIHByb2dyYW0gd2lsbCBjaGFuZ2UgeW91ciBMSUZFH IEZPUkVWRVIhISBMb29rIGF0IHRoZSBwb3RlbnRpYWwgZm9yDQp5b3UgdG8gYmUgYWJsZSB0H byBxdWl0IHlvdXIgam9iIGFuZCBsaXZlIGEgbGlmZSBvZiBsdXh1cnkgeW91IGNvdWxkIA0KH b25seSBkcmVhbSBhYm91dCEgSW1hZ2luZSBnZXR0aW5nIG91dCBvZiBkZWJ0IGFuZCBidXlpH bmcgdGhlIGNhciBhbmQgaG9tZSBvZiANCnlvdXIgZHJlYW1zIGFuZCBiZWluZyBhYmxlIHRvH IHdvcmsgYSBzdXBlci1oaWdoIHBheWluZyBsZWlzdXJlbHkgZWFzeSANCmJ1c2luZXNzIGZyH b20gaG9tZSENCg0KICAkJCQgICBGSU5BTExZIE1BS0UgU09NRSBEUkVBTVMgQ09NRSBUUlVFH ISAgICQkJA0KDQpBQ1QgTk9XISBUYWtlIHlvdXIgZmlyc3Qgc3RlcCB0b3dhcmQgYWNoaWV2H aW5nIGZpbmFuY2lhbCBpbmRlcGVuZGVuY2UuDQpPcmRlciB0aGUgcmVwb3J0cyBhbmQgZm9sH bG93IHRoZSBwcm9ncmFtIG91dGxpbmVkIGFib3ZlLS0NClNVQ0NFU1Mgd2lsbCBiZSB5b3VyH IHJld2FyZC4NCg0KVGhhbmsgeW91IGZvciB5b3VyIHRpbWUgYW5kIGNvbnNpZGVyYXRpb24uH DQoNClBMRUFTRSBOT1RFOiBJZiB5b3UgbmVlZCBoZWxwIHdpdGggc3RhcnRpbmcgYSBidXNpH bmVzcywgcmVnaXN0ZXJpbmcgYQ0KYnVzaW5lc3MgbmFtZSwgbGVhcm5pbmcgaG93IGluY29tH ZSB0YXggaXMgaGFuZGxlZCwgZXRjLiwgY29udGFjdCB5b3VyIA0KbG9jYWwgb2ZmaWNlIG9mH IHRoZSBTbWFsbCBCdXNpbmVzcyBBZG1pbmlzdHJhdGlvbiAoYSBGZWRlcmFsIEFnZW5jeSkNH CjEtODAwLTgyNy01NzIyIGZvciBmcmVlIGhlbHAgYW5kIGFuc3dlcnMgdG8gcXVlc3Rpb25zH Lg0KDQpBbHNvLCB0aGUgSW50ZXJuYWwgUmV2ZW51ZSBTZXJ2aWNlIG9mZmVycyBmcmVlIGhlH bHAgdmlhIHRlbGVwaG9uZSBhbmQgDQpmcmVlIHNlbWluYXJzIGFib3V0IGJ1c2luZXNzIHRhH eCByZXF1aXJlbWVudHMuIFlvdXIgZWFybmluZ3MgYXJlIGhpZ2hseSANCmRlcGVuZGVudCBvH biB5b3VyIGFjdGl2aXRpZXMgYW5kIGFkdmVydGlzaW5nLiBUaGUgaW5mb3JtYXRpb24gY29uH dGFpbmVkIG9uIHRoaXMgDQpzaXRlIGFuZCBpbiB0aGUgcmVwb3J0IGNvbnN0aXR1dGVzIG5vH IGd1YXJhbnRlZXMgc3RhdGVkIG5vciBpbXBsaWVkLiBJbiB0aGUgZXZlbnQgDQp0aGF0IGl0H IGlzIGRldGVybWluZWQgdGhhdCB0aGlzIHNpdGUgb3IgcmVwb3J0IGNvbnN0aXR1dGVzIGEgH Z3VhcmFudGVlIG9mIGFueSANCmtpbmQsIHRoYXQgZ3VhcmFudGVlIGlzIG5vdyB2b2lkLiBUH aGUgZWFybmluZ3MgYW1vdW50cyBsaXN0ZWQgb24gdGhpcyBzaXRlIGFuZCANCmluIHRoZSByH ZXBvcnQgYXJlIGVzdGltYXRlcyBvbmx5LiBJZiB5b3UgaGF2ZSBhbnkgcXVlc3Rpb25zIG9mH IHRoZSBsZWdhbGl0eSBvZiANCnRoaXMgcHJvZ3JhbSwgY29udGFjdCB0aGUgT2ZmaWNlIG9mH IEFzc29jaWF0ZSBEaXJlY3RvciBmb3IgTWFya2V0aW5nIFByYWN0aWNlcywgDQpGZWRlcmFsH IFRyYWRlIENvbW1pc3Npb24sIEJ1cmVhdSBvZiBDb25zdW1lciBQcm90ZWN0aW9uIGluIFdhH c2hpbmd0b24sIERDLg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09H PT09PT09PT09DQoNClVuZGVyIEJpbGwgcy4xNjE4IFRJVExFIElJSSBwYXNzZWQgYnkgdGhlH IDEwNXRoIFVTIENvbmdyZXNzIHRoaXMgbGV0dGVyIA0KY2Fubm90IGJlIGNvbnNpZGVyZWQgH c3BhbSBhcyBsb25nIGFzIHRoZSBzZW5kZXIgaW5jbHVkZXMgY29udGFjdCBpbmZvcm1hdGlvH biANCmFuZCBhIG1ldGhvZCBvZiByZW1vdmFsLiBUaGlzIGlzIG9uZSB0aW1lIGUtbWFpbCB0H cmFuc21pc3Npb24uIE5vIHJlcXVlc3QgZm9yIA0KcmVtb3ZhbCBpcyBuZWNlc3NhcnkuDQoNH Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQoN Cg0KDQo=   ------------------------------   Date: 5 Oct 2000 08:12:55 GMTW! From: Fred Zwarts <ZWARTS@KVI.nl>p% Subject: Maximum record size in pipesv. Message-ID: <8rhd67$i2g$1@info.service.rug.nl>  O Since the SEARCH command does not allow a combination of AND and OR conditions,o I tried a PIPE. Something like:Q  @ PIPE search inputfile string1,string2 | search sys$input string3  6 After displaying a few records that I need, it writes:  / %SEARCH-F-WRITEERR, error writing SYS$OUTPUT:.;W- -RMS-F-SYS, QIO system service request failedi4 -SYSTEM-F-MBTOOSML, mailbox is too small for request  M DIRECTORY /FULL of the input file shows that the longest record is 408 bytes.C% I verified this with a small program.u  J My conclusion is that the mailbox that is link the sys$ouput of the first N search to the sys$input of the next search cannot handle records of this size.  O I cannot find anything on record sizes in the documentation of the PIPE comand.vE What is the maximum and can it be changed, e.g., with a logical name?i   ------------------------------  # Date: Thu, 05 Oct 2000 15:47:46 GMTQ From: jgessling@my-deja.comv) Subject: Re: Maximum record size in pipesH) Message-ID: <8ri7r0$8m0$1@nnrp1.deja.com>g  
 re: Pipe sizeC  G > What is the maximum and can it be changed, e.g., with a logical name?v  > I'm not sure this is the complete answer but MPAn devices haveD a default buffer size of 256.  But I discovered that if you increase@ sysgen parameter DEFMBXMXMSG which is the default mailbox recordA size, and reboot then the MPAn devices take that value.  You willGD probably want to increase DEFMBXBUFQUO, which controls the number ofB messages a mailbox can hold.  like number of messages = QUO/MXMSG.  8 Let us know if this works with your larger record sizes.   Jimq    & Sent via Deja.com http://www.deja.com/ Before you buy.q   ------------------------------   Date: 5 Oct 2000 16:03:41 GMTF2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)) Subject: Re: Maximum record size in pipeso, Message-ID: <8ri8ot$b6f@gap.cco.caltech.edu>  R In article <8rhd67$i2g$1@info.service.rug.nl>, Fred Zwarts <ZWARTS@KVI.nl> writes:P >Since the SEARCH command does not allow a combination of AND and OR conditions,  >I tried a PIPE. Something like: >kA >PIPE search inputfile string1,string2 | search sys$input string3S >W7 >After displaying a few records that I need, it writes:C >U0 >%SEARCH-F-WRITEERR, error writing SYS$OUTPUT:.;. >-RMS-F-SYS, QIO system service request failed5 >-SYSTEM-F-MBTOOSML, mailbox is too small for requestj >2N >DIRECTORY /FULL of the input file shows that the longest record is 408 bytes.& >I verified this with a small program. >HK >My conclusion is that the mailbox that is link the sys$ouput of the first  O >search to the sys$input of the next search cannot handle records of this size.v >gP >I cannot find anything on record sizes in the documentation of the PIPE comand.F >What is the maximum and can it be changed, e.g., with a logical name?  - There's are two parameters you can mess with:h                             Default   DEFMBXBUFQUO           1056G   DEFMBXMXMSG             256k  J Unfortunately these affect ALL mailboxes and not just the one in PIPE, and@ if you really crank them up bad things may happen.  (In my case, DECwindows wouldn't start.)   J But if those files are at all large you'll get better performance writing K to a RAMdisk and then running a separate SEARCH command.  It might even be UG faster going to disk if you have the RMS parameters set correctly.  VMSQI PIPE has some sort of hand shaking problem and the performance you get islS 1/(N!), where N is the number of pipes.  (I posted these results about 8 months agon in this group.)g   Regards,   David Mathog mathog@seqaxp.bio.caltech.edug? Manager, sequence analysis facility, biology division, Caltech N   ------------------------------  # Date: Thu, 05 Oct 2000 08:43:49 GMTv From: suma@secondring.comW Subject: Newbie help pleaseu4 Message-ID: <9bXC5.24847$Nb2.582296@news.uswest.net>   Please help me out bigsuma@home.com   suma@secondring.comG evzchpqlprnvoqkiconk   ------------------------------   Date: 5 Oct 2000 13:21:24 GMTG) From: leslie@clio.rice.edu (Jerry Leslie)o Subject: Re: Newbie help pleaseD' Message-ID: <8rhv8k$ac1$2@joe.rice.edu>3   suma@secondring.com wrote: : Please help me out : bigsuma@home.com :l : suma@secondring.comu : evzchpqlprnvoqkiconk   How may we help you out ?t  ! You may want to read the VMS FAQ:i   http://www.openvms.compaq.com/  4 --Jerry Leslie     (my opinions are strictly my own)   ------------------------------  $ Date: Thu, 5 Oct 2000 23:03:52 +13004 From: "Mike Tock" <hiding_me@don't_spam.hotmail.com> Subject: Re: NTP with UCX 4.2y* Message-ID: <8rhjj5$eo2$1@news.ihug.co.nz>  K Thanks for the offer of help. I did finally manage to get it to work by notWI using DNS host entries in the NTP.CONF so it now does what I wanted it tou do.H  J As for the moving to 5.0a the jury is still out, at the moment there is no+ real need to move from ucx 4.2 at our site.y   cheers   Mike  ) <fruth@axp.abpa-tpa.com> wrote in messagep# news:8r0d0r$p3p$1@nnrp1.deja.com...G< > I've gotten NTP to work on both UCX 4.2 ECO3 and UCX 5.0A. >GA > 5.0A has a lot more functionality (NTPDATE, NTPTRACE, NTPQ, andzG > NTPDC).  However both do the primary job of keeping the computer timewC > correct just fine.  The extra functionality in 5.0A could help inw > debugging problems.w >mB > The messages show up in the UCX 4.2 log somewhat slowly; severalG > minutes passed before I saw any data.  I'll be happy to help if you'dS > like.2 >C1 > In article <wCby5.640$O7.18456@ozemail.com.au>,D> >   "Antony Wardle" <antony.wardle@nnnoospam.met.co.nz> wrote:; > > We've got it working here with the same version and 7.1s > >mG > > WOn't be upgrading (again) to 5.0a until we can get some assurancesCC > > about NFS. That aside, the rest of the machines on 5.0a seem toD" > > be working a whole lot better. > >VE > > You need 5.0a if you have any linux boxes that telnet to your vmsMA > > hosts. We found that each telnet session would use 30% of thekJ > > cpu, therefore 3 telnets, would have your whole cpu all to themselves. > >k
 > > any help?E > >K
 > > antony > >DC > > "Mike Tock" <hiding_me@don't_spam.hotmail.com> wrote in messageW( > > news:8qa6sa$p6p$1@news.ihug.co.nz... > > > Hi > > >gH > > > Has anybody got NTP to work with this version of UCX the ECO is 4. > > >gF > > > I get things to run but in the log file I don't see any messages	 > that is2 > > it6 > > > actually talking to the host I want to sync off.D > > > if I make the node a local master, then the log file puts in a	 > messagey1 > > > saying it accepted itself as the sync host.X > > >G > > >iB > > > As as an aside, is it worth upgrading from UCX 4.2 to 5.0a?? > > >J > > > Cheers
 > > > Mike > > >g > > >n > >m > >u >u >B( > Sent via Deja.com http://www.deja.com/ > Before you buy.J   ------------------------------  # Date: Thu, 05 Oct 2000 07:04:50 GMTz8 From: Veli =?iso-8859-1?Q?K=F6rkk=F6?= <korkko@decus.fi>? Subject: Re: openVMS v7.1 VAX with Dump off System Disk featureD' Message-ID: <39DB5DA3.E7C7FBD@decus.fi>i  F That's correct. The DOSD feature on VAX requires actually even booting) via CIXCD adapter thus not for your case.K   _velim  & andrew.rycroft@intrinsitech.com wrote: >  > Hi,w > H > I am trying to configure an OpenVMS VAX with v7.1 dump off system disk7 > feature. I have a VAX 4000-106 with SCSI disk drives.U > B > Has anybody had any success with this ? The documentation I have> > suggests only CI attached disks will work with this feature. >  > Appreciate any feedback. > Thanks > Andrew > ( > Sent via Deja.com http://www.deja.com/ > Before you buy.H   ------------------------------   Date: 5 Oct 2000 09:19:50 -0500G, From: koehler@eisner.decus.org (Bob Koehler) Subject: Re: PF keys+ Message-ID: <MjscmcioKI9t@eisner.decus.org>Q  i In article <39DBA6B1.C3FAFECC@gtech.com>, Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> writes:g > , > Unix telnet ? That may be more difficult !  D Generally when coming from UNIX I find it best to start xterm.  ThatE requires X, but it does a useable job of VT100 emulation and it seems2 to always be there.W  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporation3= Hubble Space Telescope Payload  | Federal Sector, Civil GroupEE  Flight Software Team           | please remove ".aspm" when replyingM   ------------------------------  % Date: Wed, 04 Oct 2000 22:05:12 -0400n' From: Derek Konigsberg <konigd@rpi.edu>U< Subject: Re: Register values for DEFBOO.COM (boot from tape)' Message-ID: <39DBE1D7.BA69C625@rpi.edu>F   Hans, H     It would be nice if you could please look on your 8550 (very similarL machine, as I understand), as I don't completely trust the set of scripts onL our console (set of boot files isn't exactly "complete").  The console we'reN using is from a different 8530, so it's not exactly configured to boot off the devices we have on our machine.T   Thanks,g	     DerekT   Hans Vlems wrote:S   > Derek, >SB > if the 8530 can boot from tape then in the same PRO380 directory9 > that holds DEFBOO.COM should be files called M*BOO.COM.w< > Either  B @<alternate com file> or rename it to DEFBOO.COM > and boot it.6 > If I can find the time I'll have a look on our 8550. >m > Hans Vlems >lM > Derek Konigsberg heeft geschreven in bericht <39DB5F19.BACE5DF7@rpi.edu>...k	 > >Hello,QK > >    We've got a VAX 8530, and need to know how to boot it from tape.  WenJ > >have a TU81+ tape drive interfaced to the machine through it's own portI > >on the back.  The way the machine boots, is rather interesting.  FirstQE > >you power it on and load the microcode from the console.  The "VAXlE > >Console" is basically a Pro380 microcomputer with it's own specialmJ > >interface to the machine.  Then, to boot the machine we run a script onK > >the console (like "DEFBOO.COM") which punches a bunch of values into theNI > >machine's registers, then loads the bootloader ("VMB.EXE"), and passesiD > >control to it.  The values you punch into the registers basicallyH > >determine what device the machine boots off of.  As we're missing theJ > >"booting from tape" portion of our console manual, we basically need toI > >know what to put in our boot command file to boot the machine from thel	 > >TU81+.V > >g
 > >Thanks, > >    Derek Konigsbergw > >    konigd@rpi.edum > >3 > >o   ------------------------------  $ Date: Thu, 5 Oct 2000 08:57:04 +0100= From: "adrian.birkett" <adrian.birkett@unneccessary.ic24.net>3% Subject: Removing devices from systeml' Message-ID: <BwWC5.2$0l6.73@news1-hme0>X   All,  	 VMS 5.5-2m Vax 4000-200  G Is it possible to remove a device that appears in the sysgen SHOW/DEV =G list?G  B I have had to remove some comms devices from a microvax 3400 and =I re-install them in the 4200. The problem is that even in MIN boot mode, =ZI I can't connect them in sysgen and it reports a "vector already in use" =C error.  $ All suggestions greatly appreciated.   Regards,   AdeJ   ------------------------------  % Date: Thu, 05 Oct 2000 11:25:02 -0400G# From: Jim Agnew <agnew@hsc.vcu.edu>F: Subject: Re: Seeking info/prices for OpenVMS and hardware.+ Message-ID: <39DC9D4E.F7FC1C28@hsc.vcu.edu>3   we use Ingres, and there are postgres, opensql that *MAY* be being ported to vms..  Ingres is from Computer associates, and they% like to price it up an dup and up....i  
 best of luck!X   Cthulhu wrote: > 4 > I was sure that it would never happen, but it did!H > My PM asked me to give infos on time/cost needed to do some testing on
 > OpenVMS. > A > I will contact ASAP local Compaq reseller, which I suppose willT< > respond with something like "OpenWHAT?", in the meanwhile: > @ > 1) Our need is a platform for ASP (that is Application ServiceF >         Provider, not the Evil One). They asked me to look for CORBAH >         compatibility. I think support for Java Servlet/JSP would be aB >         nice thing too (I hate Java, but they follow the trend). > 8 > 1a) Which are the other *DBMS avaliable beside Oracle? > ? > 2) I think I'll go for a DS10, maybe two of them to play withgF >         clustering. Or maybe I can do some significative test with aA >         self-build alpha, or even a refurbished one? Which one?h > H > 3) Where to search for license pricing? I have an hardware reseller at' >         hand, but not a software one.m >  > 4) I found the article atmC >         http://www5.compaq.com/newsroom/pr/2000/pr2000100301.htmlS1 >         interesting. How must I trust it (ehe)?l$ >         Can I obtain more details? >  >         startingly,N >            Cthulhu > -- > I >        Ph'nglui mglw'nafh Cthulhu http://www.rlyeh.it wgah'nagl fhtgan!W3 >                         <cthulhu at rlyeh dot it>m   ------------------------------   Date: 5 Oct 2000 15:24:43 GMT02 From: mathog@seqaxp.bio.caltech.edu (David Mathog): Subject: Re: Seeking info/prices for OpenVMS and hardware., Message-ID: <8ri6fr$b6f@gap.cco.caltech.edu>  R In article <8rg6kj$10o$1@kadath.deep.it>, Cthulhu <cthulhu@kadath.deep.it> writes:3 >I was sure that it would never happen, but it did!GG >My PM asked me to give infos on time/cost needed to do some testing onG	 >OpenVMS.G >W@ >I will contact ASAP local Compaq reseller, which I suppose will; >respond with something like "OpenWHAT?", in the meanwhile:C >F? >1) Our need is a platform for ASP (that is Application ServiceH> >	Provider, not the Evil One). They asked me to look for CORBA@ >	compatibility. I think support for Java Servlet/JSP would be a: >	nice thing too (I hate Java, but they follow the trend).   Will Apache do what you want?g   >G8 >1a) Which are the other *DBMS avaliable beside Oracle?	  @ The two that I know of are MIMER (www.mimer.se)  and System 1032I (www.cca-int.com). Beats me which of the 3 performs best in your intendedHJ size range.  None of the freeware SQL databases currently run on OpenVMS.    >S> >2) I think I'll go for a DS10, maybe two of them to play with> >	clustering. Or maybe I can do some significative test with a9 >	self-build alpha, or even a refurbished one? Which one?G  I You MUST buy SCSI - the EIDE disk is really slow.  Have your reseller get1H you a third party disk and have them buy the intraserver controller fromL the manufacturer.  (If you buy the controller and disk from the Q you'll pay 3X more for the same thing.)   >pG >3) Where to search for license pricing? I have an hardware reseller atl >	hand, but not a software one.G  H The OS licenses will be bundled with the system.  If you need more user 5 licenses I'd guess that you'd go directly to the Q.  H   Regards,   David Mathog mathog@seqaxp.bio.caltech.edu0? Manager, sequence analysis facility, biology division, Caltech w   ------------------------------   Date: 5 OCT 2000 16:03:44 GMTX+ From: Dave Greenwood <greenwoodde@ornl.gov>N: Subject: Re: Seeking info/prices for OpenVMS and hardware.1 Message-ID: <5OCT00.16034482@feda34.fed.ornl.gov>g  > Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> wrote: > Cthulhu wrote:B > > 1) Our need is a platform for ASP (that is Application ServiceH > >         Provider, not the Evil One). They asked me to look for CORBAJ > >         compatibility. I think support for Java Servlet/JSP would be aD > >         nice thing too (I hate Java, but they follow the trend). >  vA > There are CORBA for VMS. I can not remember the vendors though.i   TryX  9     http://www.uk.research.att.com/omniORB/omniORB.html  X  D I've not tried it myself but they claim it's been successfully builtB on VMS (alpha & VAX).  And the price is right - free under the GNU, license.  You'll need a C++ compiler though.   Dave --------------9 Dave Greenwood                Email: Greenwoodde@ORNL.GOVnH Oak Ridge National Lab        %STD-W-DISCLAIMER, I only speak for myself   ------------------------------   Date: 5 Oct 2000 12:55:55 GMTp) From: leslie@clio.rice.edu (Jerry Leslie)W/ Subject: Re: Shark x Penguin : The OpenVMS Logo2' Message-ID: <8rhtor$ac1$1@joe.rice.edu>h  ( Joseph B. Gurman (gurman@ari.net) wrote: :TJ :     Seriously, though, it wouldn't hurt if Compaq invested in an easily J : recognizable logo for OpenVMS, even if it would be too much to hope for F : that it could appear on shrink-wrapped, third-party software like a G : certain, silly, multicolor window/flag or a smirking, two-faced grin.  :b :                   Joe Gurman  E You mean "this certain, silly, multicolor window/flag or a smirking, i two-faced grin"  ? :  +   http://www.cs.huji.ac.il/~vadik/gates.jpg   4 --Jerry Leslie     (my opinions are strictly my own)   ------------------------------  % Date: Thu, 05 Oct 2000 11:05:53 -0400B: From: "Koska, John C. (LNG-MBC)" <John.C.Koska@bender.com>/ Subject: RE: Shark x Penguin : The OpenVMS LogosK Message-ID: <91A9507020DBD311992F0008C709517C545C02@MBCALBEXC00.BENDER.COM>   = Yeah, and I'd like that on a tee-shirt in the OpenVMS eStore!h   :) jck   > -----Original Message-----6 > From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca]+ > Sent: Wednesday, October 04, 2000 9:19 PMo > To: Info-VAX@mvb.saic.comn1 > Subject: Re: Shark x Penguin : The OpenVMS Logo  >  >  > Warren Sander wrote:E > > Anyway. No the shark isn't the offical OpenVMS logo [but at leastuE > > shell boy is gone] but it has found a place in the hearts of manyp* > > of our customers. I just can't use it. >  > Why can't you use it ? > @ > You just need to change the Digital to Compaq, and openVMS to  > VMS, and you'd4 > have an updated, real logo that pleases customers. >    ------------------------------  % Date: Thu, 05 Oct 2000 11:27:56 -0500a* From: WILLIAM WEBB <WWEBB1@email.usps.gov>/ Subject: RE: Shark x Penguin : The OpenVMS Logon- Message-ID: <0033000005908878000002L082*@MHS>n  7 =0ASince most of us VMS folk are, shall we say, mature-a    I'd suggest polo shirts instead.  9 Besides, that would fly on "office casual" where t-shirtsa
 would not.   WWWebb   -----Original Message-----/ From: Info-VAX-Request@Mvb.Saic.Com at INTERNET0) Sent: Thursday, October 05, 2000 11:24 AMt6 To: Webb, William W; Info-VAX@Mvb.Saic.Com at INTERNET/ Subject: RE: Shark x Penguin : The OpenVMS Logoc    = Yeah, and I'd like that on a tee-shirt in the OpenVMS eStore!s   :) jck   > -----Original Message-----6 > From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca]+ > Sent: Wednesday, October 04, 2000 9:19 PMk > To: Info-VAX@mvb.saic.comn1 > Subject: Re: Shark x Penguin : The OpenVMS Logod >l >n > Warren Sander wrote:E > > Anyway. No the shark isn't the offical OpenVMS logo [but at least E > > shell boy is gone] but it has found a place in the hearts of manyi* > > of our customers. I just can't use it. >/ > Why can't you use it ? >t? > You just need to change the Digital to Compaq, and openVMS tol > VMS, and you'd4 > have an updated, real logo that pleases customers. >=   ------------------------------   Date: 5 Oct 2000 13:00:20 -0400h/ From: jordan@lisa.gemair.com (Jordan Henderson)a* Subject: Re: Sun Hardware problems persist* Message-ID: <8ric34$mc2$1@lisa.gemair.com>  * In article <39D34F8D.52927F3E@uk.sun.com>,2 andrew harrison  <andrew.nospam@uk.sun.com> wrote:
 >jlsue wrote:  >>  6 >> On Tue, 26 Sep 2000 15:32:41 +0100, andrew harrison$ >> <andrew.nospam@uk.sun.com> wrote: >> sH >> >Sorry Kerry you havn't answered the question. You seem happy to quizD >> >me on ebays issues but when I raise etrade suddenly you clam up. >> > >> >So answer the question.a >>  E >> Oh wow!  What an incredibly ironic comment from Andrew, the artfulnC >> dodger.  How many times have others requested the same from you,i >> without result? >> r7 >The eBay outage was caused by an unapplied patch to a s9 >third party product. You can quiz me as much as you liker7 >about the product in question and I cannot answer yourt5 >questions, nor can I tell you why the patch was not a8 >applied. This is because the 3rd party app supplier and= >eBay would prefer it if Sun did not publish the information.- >-  9 Yes, yes, a third party product, a patch, we've heard alla the finger pointing before.w  7 Funny how you are so adept at finger pointing, a third u6 party product, an SRAM supplier, a customer's computer room environment...  c  5 I guess those IBM ads where they show the poor CIO ine1 dispair because they have products from column A e4 matched up with development by party B and there are8 no answers when there are problems are pretty effective.  3 Of course, you've been seen in comp.os.vms touting  8 exactly those third party products as providing database7 replication and reliability advantages that you can getQ; with OpenVMS clusters.  When there are problems, however...y  > >That being said the only place where I have seen any dispute > >about the fact that it was an unapplied patch to a 3rd party 5 >product that caused the outage is on this newsgroup.  >y  9 Whenever Sun reliability problems come up in the press ore8 by the analysts, somehow eBay comes into the discussion.  4 I wonder why?  Well, noboby can say for sure what's 6 causing all the repeated outages at eBay, but it seems there are suspicions...,  8 >Is eTrade such a different story, there is no concrete > >information about what actually caused eTrades outage, Kerry < >waves his hands and says it was only a configuration issue.A >Without answering the question as to who made the configuration a? >error and why did the error hang the cluster when most people  2 >thought that this sort of thing could not happen. >r> >In other words the kind of FUD storm raised on this newsgroup@ >over eBay had exactly the same factual basis as the allegations
 >over eTrade.o >o  > Of course, eTrade wasn't initially making hot statements aboutA how the vendor promised them that the systems were "Bulletproof".4= Also, Compaq hasn't been known to be requiring customers signe> NDAs for the apparent reason of keeping them quiet.  And, this> observation about the NDAs is not just seen in this newsgroup.  ? No matter how you try to make the eBay situation similar to thed> e*Trade situation it just doesn't wash.  Why?  Because of your< credibility.  Sun has been shown to be trying to hide their ; problems, so we continue to prod in an effort to determine c what they are.  = >The only difference is that Compaq has not been exhonerated y  @ Big lie technique at work again.  Sun hasn't been exhonerated.  @ You've been unable to provide a shred of support that Sun HW/SW 7 wasn't at base the cause of the continued eBay outages.   ? Sorry, your word on it, when you've been shown to be less-than-oE truthful about so many things, isn't good enough.  I'd provide a listg; of your misstatements and obvious lies, but you just ignoreu< them and clip them out of the replies, so I'll let people do0 their own deja research if they are interested.   > >given that eTrades outage was apparently caused by a hardware> >configuration change which had almost certainly to have been > >made by a Compaq engineer, the "configuration mistake" seems < >to have been Compaqs mistake and not eTrades or any of the ; >applications providers. In addition there is the question  = >of why a configuration change could have hung the supposedly?: >un-hangable cluster. Now personally I never thought that : >OpenVMS clusters were un-hangable but there are plenty of6 >OpenVMS boosters who would like people to think this. > ; >And some posts have been made suggesting that for example t> >eBays follow on commitment to Sun hardware has been based on 7 >Sun giving them the hardware for free. Of course theseM? >throwers of stones in glass houses have conveniently forgotten07 >that eTrade has also invested in more OpenVMS systems u< >and perhaps the only way Compaq got them to do this was to : >give them the kit :):):). Exactly the same factual basis  >as the eBay FUD good isn't it.r  < Not exactly.  When eBay reupped on Sun, there were obviously< questions about the deal, but the details were not revealed:  8  http://www.canada.cnet.com/news/0-1003-200-1882022.html   From this article:  =   Sun and eBay didn't disclose the terms of the deal--either 6;   how much the contract is worth or how long it will last. v7   "I can say that we made money on it," van Aman said. b  9 Obviously, Aman was trying to let everyone know that Sun i= made money on the deal, obviously there were questions.  Now, * why are the terms of the deal undisclosed?   >e >> What a maroon!- >> - >-0 >Really anyone outside this group following this2 >thread would I think have detected the tiny weeny5 >double standard being excercised by OpenVMS boosterse >on this group.  >u2 >Its OK to FUD Sun and anyone else with no factual3 >basis to the FUD and its even OK to get found out -! >when the FUD proves to be wrong.1  2 You haven't proved a thing, except your ability to' repeat your unsubstantiated assertions.    > 4 >But its totally out of order for someone or attack 0 >OpenVMS on the same basis even if the there is 3 >no information that currently refutes this attack.s >d  0 Poor Andrew.  He's so mistreated here.  Maybe he0 shouldn't post negative things in cov about VMS?  . It's really no surprise why one would get such- a hot reception when all that person does is o. spread anti-OpenVMS FUD in a group that is for+ discussion about OpenVMS, by OpenVMS users.   / >Are you in marketing at Compaq, perhaps an ex  - >Digital marketeer it only the impression youO# >give from this posting !! :):):):)M  + Ooooh... Calling Kerry a Digital Marketeer. , That's far more rude than calling someone an idiot, in my book.   >l >Regards >Andrew Harrison >Enterprise IT Architect   -Jordan Henderson  jordan@greenapple.comC   ------------------------------  $ Date: Thu, 5 Oct 2000 10:02:58 -0400. From: "Kenneth Randell" <kenr@datametrics.com>  Subject: TCP/IP 5.0A ECO Appears+ Message-ID: <8ri1is$4bh$1@bob.news.rcn.net>   H Well, it finally happened.  The long awaited ECO for TCP/IP Services for VMS 5.0a can be found at:r  8 http://ftp.service.digital.com/patches/.new/openvms.html   Ken Randell    ------------------------------  % Date: Thu, 05 Oct 2000 15:34:47 +0100h- From: Tim Llewellyn <tim.llewellyn@bbc.co.uk>E$ Subject: Re: TCP/IP 5.0A ECO Appears) Message-ID: <39DC9187.841245C0@bbc.co.uk>n   Kenneth Randell wrote:  J > Well, it finally happened.  The long awaited ECO for TCP/IP Services for > VMS 5.0a can be found at:a >e: > http://ftp.service.digital.com/patches/.new/openvms.html >n
 > Ken Randellr  < Hmmm, maybe the readme is there, but the links to the actual patch kits are broken.  	 Not Foundt   The requested URLle /patches/public/vms/axp/v7.1/tcp/ip/5.0a/tcp/ip/5.0a/dec-axpvms-tcpip_eco-v0500-111-4.pcsi-dcx_axpexe- was not found on this server.      --6 Tim Llewellyn, OpenVMS Infrastructure, Remarcs Project0 MedAS at the BBC, Whiteladies Road, Bristol, UK.A Email tim.llewellyn@bbc.co.uk. Home tim.llewellyn@cableinet.co.ukl  A I speak for myself only and my views in no way represent those ofh MedAS or the BBC.y   ------------------------------  # Date: Thu, 05 Oct 2000 14:48:56 GMTa+ From: Craig A. Berry <calepine@my-deja.com>4$ Subject: Re: TCP/IP 5.0A ECO Appears) Message-ID: <8ri4ck$5i6$1@nnrp1.deja.com>n  + In article <8ri1is$4bh$1@bob.news.rcn.net>,r1   "Kenneth Randell" <kenr@datametrics.com> wrote:a= > Well, it finally happened.  The long awaited ECO for TCP/IP  Services for > VMS 5.0a can be found at:a >w: > http://ftp.service.digital.com/patches/.new/openvms.html  ; Does anyone know why in the "kit applies to" section of the ? readme, it does not mention 7.2-1, but in the "ECO KIT SUMMARY"g7 it says "for TCP/IP V5.0A on OpenVMS Alpha V7.1 through B V7.2-1H1"?  I assume the omission of 7.2-1 in the former is just a typing mistake?     & Sent via Deja.com http://www.deja.com/ Before you buy.    ------------------------------  % Date: Thu, 05 Oct 2000 11:03:11 -0400.# From: sol gongola <sol@adldata.com>p$ Subject: Re: TCP/IP 5.0A ECO Appears' Message-ID: <39DC982F.58BB@adldata.com>i  A As of now the links at the bottom of the README web page are bad.pD The links have the following repeated and it should appear only once in the url.    tcp/ip/5.0a/   sol gongolaI   Kenneth Randell wrote: > J > Well, it finally happened.  The long awaited ECO for TCP/IP Services for > VMS 5.0a can be found at:  > : > http://ftp.service.digital.com/patches/.new/openvms.html > 
 > Ken Randelle   ------------------------------  % Date: Thu, 05 Oct 2000 11:13:22 -0400g# From: sol gongola <sol@adldata.com>f$ Subject: Re: TCP/IP 5.0A ECO Appears' Message-ID: <39DC9A92.6A1F@adldata.com>f  F The "tcp/ip/5.0a" is reapeated, remove one of them and the link works.   sol gongolae   Tim Llewellyn wrote: >  > Kenneth Randell wrote: > L > > Well, it finally happened.  The long awaited ECO for TCP/IP Services for > > VMS 5.0a can be found at:  > > < > > http://ftp.service.digital.com/patches/.new/openvms.html > >h > > Ken Randell  > > > Hmmm, maybe the readme is there, but the links to the actual > patch kits are broken. >  > Not Found  >  > The requested URL-g > /patches/public/vms/axp/v7.1/tcp/ip/5.0a/tcp/ip/5.0a/dec-axpvms-tcpip_eco-v0500-111-4.pcsi-dcx_axpexeo > was not found on this server.c >  > --8 > Tim Llewellyn, OpenVMS Infrastructure, Remarcs Project2 > MedAS at the BBC, Whiteladies Road, Bristol, UK.C > Email tim.llewellyn@bbc.co.uk. Home tim.llewellyn@cableinet.co.uke > C > I speak for myself only and my views in no way represent those ofe > MedAS or the BBC.o   ------------------------------  # Date: Thu, 05 Oct 2000 15:00:22 GMTu+ From: Craig A. Berry <calepine@my-deja.com>n$ Subject: Re: TCP/IP 5.0A ECO Appears) Message-ID: <8ri51v$66i$1@nnrp1.deja.com>c  ) In article <39DC9187.841245C0@bbc.co.uk>,.    tim.llewellyn@bbc.co.uk wrote:   >p> > Hmmm, maybe the readme is there, but the links to the actual > patch kits are broken. >t > Not Foundt >t > The requested URL  >wC /patches/public/vms/axp/v7.1/tcp/ip/5.0a/tcp/ip/5.0a/dec-axpvms-tcp " ip_eco-v0500-111-4.pcsi-dcx_axpexe > was not found on this server.e  G There's a goof in the link.  The "tcp/ip/5.0a" got entered twice.  Try:t  B <http://ftp1.support.compaq.com/public/vms/axp/v7.2-1/tcp/ip/5.0a/1 dec-axpvms-tcpip_eco-v0500-111-4.pcsi-dcx_axpexe>     & Sent via Deja.com http://www.deja.com/ Before you buy.d   ------------------------------  " Date: Thu, 5 Oct 2000 15:25:58 GMT- From: "Richard D. Piccard" <piccard@ohio.edu> $ Subject: Re: TCP/IP 5.0A ECO Appears( Message-ID: <39DC9D82.D0742E23@ohio.edu>  = And the VMS Patches mailing list has yet to tell us about it!(  #                                 RDP      Kenneth Randell wrote:  J > Well, it finally happened.  The long awaited ECO for TCP/IP Services for > VMS 5.0a can be found at:  > : > http://ftp.service.digital.com/patches/.new/openvms.html >e
 > Ken Randellu   --B ==================================================================B Dick Piccard                           Academic Technology ManagerB piccard@ohio.edu                                 Computer ServicesB http://oak.cats.ohiou.edu/~piccard/                Ohio University   ------------------------------  % Date: Thu, 05 Oct 2000 17:12:36 +0100e- From: Tim Llewellyn <tim.llewellyn@bbc.co.uk>2$ Subject: Re: TCP/IP 5.0A ECO Appears) Message-ID: <39DCA874.15700A89@bbc.co.uk>    sol gongola wrote:  C > As of now the links at the bottom of the README web page are bad. F > The links have the following repeated and it should appear only once
 > in the url.o >t > tcp/ip/5.0a/ >p
 > sol gongolae >e   OK, got it now, thanks     --6 Tim Llewellyn, OpenVMS Infrastructure, Remarcs Project0 MedAS at the BBC, Whiteladies Road, Bristol, UK.A Email tim.llewellyn@bbc.co.uk. Home tim.llewellyn@cableinet.co.uko  A I speak for myself only and my views in no way represent those ofs MedAS or the BBC.b   ------------------------------  % Date: Thu, 05 Oct 2000 17:25:20 +0100i- From: Tim Llewellyn <tim.llewellyn@bbc.co.uk>a$ Subject: Re: TCP/IP 5.0A ECO Appears) Message-ID: <39DCAB70.74862F55@bbc.co.uk>a   "Richard D. Piccard" wrote:D  ? > And the VMS Patches mailing list has yet to tell us about it!-  D VMS patches mailing list is a dead dodo. I did get a few Tru64 postsI thru last week (just interested) but nothing from VMS or Security since I8F subscribed months ago. Yet I tried resubscribing today and it tells me I am already subscribed :-(.   >l >t% >                                 RDP  >e > Kenneth Randell wrote: >eL > > Well, it finally happened.  The long awaited ECO for TCP/IP Services for > > VMS 5.0a can be found at:  > > < > > http://ftp.service.digital.com/patches/.new/openvms.html > >n > > Ken Randell  >  > --D > ==================================================================D > Dick Piccard                           Academic Technology ManagerD > piccard@ohio.edu                                 Computer ServicesD > http://oak.cats.ohiou.edu/~piccard/                Ohio University   --6 Tim Llewellyn, OpenVMS Infrastructure, Remarcs Project0 MedAS at the BBC, Whiteladies Road, Bristol, UK.A Email tim.llewellyn@bbc.co.uk. Home tim.llewellyn@cableinet.co.uk0  A I speak for myself only and my views in no way represent those ofM MedAS or the BBC.k   ------------------------------   Date: 5 Oct 2000 16:39:35 GMTs' From: david20@alpha1.mdx.ac.uk (D.Webb)O$ Subject: Re: TCP/IP 5.0A ECO Appears0 Message-ID: <8rias7$4nk$1@aquila.news.mdx.ac.uk>  X In article <39DC9D82.D0742E23@ohio.edu>, "Richard D. Piccard" <piccard@ohio.edu> writes:> >And the VMS Patches mailing list has yet to tell us about it! >o$ >                                RDP >f  G I actually received two copies of the notification from the VMS patcheso list.nJ I have also been receiving info on other VMS patches since I registered in August.a    
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------  $ Date: Thu, 5 Oct 2000 10:46:20 +0100* From: "Richard Brodie" <R.Brodie@rl.ac.uk>, Subject: Re: TCPIP v5.0A corrupted LRU queue, Message-ID: <8rhild$153k@newton.cc.rl.ac.uk>  I "Jean-Franois Marchal" <jean-francois.marchal@x9000.fr> wrote in message ( news:8r1cvb$5b2$1@reader1.imaginet.fr...G > after installing a new nfs server on a ds10 vms 7.2-1 and tcpip v5.0Ar > # > we get blue screens and a messageR >0F > %tcpip-e-cfs_error, error: cache_check detected corrupted LRU queue?7 > seems to be a known problem ... is there a solution ?n  , Appears to be fixed in ECO 1 for tcpip v5.0A   ------------------------------   Date: 5 Oct 2000 00:57 CST' From: carl@gerg.tamu.edu (Carl Perkins)l8 Subject: Re: Thinking of switching from Multinet to UCX., Message-ID: <5OCT200000571675@gerg.tamu.edu>  y In article <_BJC5.7219$rO1.295529@newsread1.prod.itd.earthlink.net>, "Mike Flaherty" <mflaherty2@earthlink.net> writes...oM }I double checked and I do have NAS licenses on my VAXes but all I have on myl }Alphas are... }  }ACMS-RT }BOOKBROWSER	 }DTR-USERt	 }DVNETEXTi	 }DW-MOTIFh }OPENVMS-ALPHA }OPENVMS-ALPHA-USER DEC 	 }SW-RAID5h }VMSCLUSTERC	 }MULTINETo } ) }Do an of these qualify as a UCX license?,   Nope.o  F You might check the original paperwork that came with the thing to seeD if there is a PAK that wasn't registered. (It could be the case thatE since Multinet was going to be used it wasn't deemed worth the effortc4 to load a PAK for UCX that wasn't going to be used.)   --- Carl   ------------------------------   Date: 5 Oct 2000 09:12:56 -0500 , From: koehler@eisner.decus.org (Bob Koehler)8 Subject: Re: Thinking of switching from Multinet to UCX.+ Message-ID: <UdYaq3ca6Bsj@eisner.decus.org>s  w In article <_BJC5.7219$rO1.295529@newsread1.prod.itd.earthlink.net>, "Mike Flaherty" <mflaherty2@earthlink.net> writes: N > I double checked and I do have NAS licenses on my VAXes but all I have on my > Alphas are...e > 	 > ACMS-RTm
 > BOOKBROWSERr
 > DTR-USER
 > DVNETEXT
 > DW-MOTIF > OPENVMS-ALPHAr > OPENVMS-ALPHA-USER DEC
 > SW-RAID5 > VMSCLUSTER
 > MULTINET > * > Do an of these qualify as a UCX license? >   F   No.  Perhpas the system shipped with such a license but it was neverB   loaded since Multinet was put in use.  Or perhaps the system was*   actually purchased without such license.  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporation = Hubble Space Telescope Payload  | Federal Sector, Civil GroupiE  Flight Software Team           | please remove ".aspm" when replyingr   ------------------------------   Date: 5 Oct 2000 15:09:40 GMTi2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)3 Subject: time to consolidate the TCP/IP work on VMSa, Message-ID: <8ri5jk$b6f@gap.cco.caltech.edu>   <minor rant>  I At the expense of violating the not invented here precept it would reallyaE be a good thing at this point for the Q to work out an agreement withgI Process where the latter is paid to develop and support all of the TCP/IPvH products for VMS.  The VMS market isn't all that big and it's a waste ofK effort for both the Q and Process to be developing the same software. Right H now Process has two IMAP servers, a regular one, and the heavy duty PMDF2 one.  It's just nuts for the Q to do yet another.   H You will note that in this arrangement it is Process that does the work,K and that's because they are invariably ahead of the Q in getting things outhK the door and their response to bug reports is usually very quick.   ProcessrJ could then provide a migration path from all commercial stacks to a singleG common stack.  The Q could shift the TCP/IP folks they have now over tog Process or reassign them.   J The PMDF "pine" tool would be integrated into the stack and ship standard H on all VMS systems.  This would solve most of our MIME problems once andF for all.  The PMDF server would remain a separately licensed product.   ; But it probably makes too much sense for it to ever happen.o
 </minor rant>s   David Mathog mathog@seqaxp.bio.caltech.edus? Manager, sequence analysis facility, biology division, Caltech t   ------------------------------   Date: 5 Oct 2000 16:16:00 GMTs' From: david20@alpha2.mdx.ac.uk (D.Webb)p7 Subject: Re: time to consolidate the TCP/IP work on VMS 0 Message-ID: <8ri9g0$4fd$1@aquila.news.mdx.ac.uk>  a In article <8ri5jk$b6f@gap.cco.caltech.edu>, mathog@seqaxp.bio.caltech.edu (David Mathog) writes:c
 ><minor rant>r >bJ >At the expense of violating the not invented here precept it would reallyF >be a good thing at this point for the Q to work out an agreement withJ >Process where the latter is paid to develop and support all of the TCP/IPI >products for VMS.  The VMS market isn't all that big and it's a waste of L >effort for both the Q and Process to be developing the same software. RightI >now Process has two IMAP servers, a regular one, and the heavy duty PMDFh3 >one.  It's just nuts for the Q to do yet another. h >II >You will note that in this arrangement it is Process that does the work,nL >and that's because they are invariably ahead of the Q in getting things outL >the door and their response to bug reports is usually very quick.   ProcessK >could then provide a migration path from all commercial stacks to a singletH >common stack.  The Q could shift the TCP/IP folks they have now over to >Process or reassign them. t > K >The PMDF "pine" tool would be integrated into the stack and ship standard  I >on all VMS systems.  This would solve most of our MIME problems once andlG >for all.  The PMDF server would remain a separately licensed product. c >t  L And for those who don't like PINE they could replace VMS MAIL with PMDF MAILL which is a superset of VMS MAIL which handles MIME, Attachments etc just as 6 well as PINE but still gives you a familiar interface.N (then all they would need to do is add the same functionality into DECW$MAIL).  < >But it probably makes too much sense for it to ever happen. ></minor rant>  M Of course if this was SUN we were talking about rather than Compaq they would  buy Process.  
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------  + Date: Thu, 05 Oct 2000 10:33:58 -0300 (EST)e From: becherini@vortex.ufrgs.br ( Subject: Re: VMS Mail - Sending binaries, Message-ID: <00100510335773@vortex.ufrgs.br>  O _______________________________________________________________________________h  ? . From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>i* . Subject: Re: VMS Mail - Sending binaries' . Date: Thu, 05 Oct 2000 00:01:27 +0200a . To: Info-VAX@Mvb.Saic.Comk . , . fabio_compaq@ep-bc.petrobras.com.br wrote:K . > Is there a way to send by VMS Mail  a .PDF file attached   (I have SMTPe . > configured andN . > it works fine) and extract it in Win platform ???? I am testing it and the . > binary comes in they . > body of the message . .. .  . Several possibilities: . 4 . 1)  manual encode on VMS, email and manual decode. . = . 2)  get a SMTP package on VMS that automatically translateso/ .     SEND/FOREIGN to a BASE64 MIME attachment.a .  . 3)  use FTP instead of email.l .  . Arne .   :   4)  use POP3 (outlook, messenger, pegasus, eudora, etc)        instead of email.t  =   5)  use WEBMAIL instead of email (WASD + yahmail are GREAT)m    	 	regards,e  N  _____________________________________________________________________________O |                                                                             | O | Fabio Becherini                   System & Network Manager, Webmaster UFRGS |pO |_____________________________________________________________________________|    ------------------------------   Date: 5 Oct 2000 15:03:45 GMTr2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)( Subject: Re: VMS Mail - Sending binaries, Message-ID: <8ri58h$b6f@gap.cco.caltech.edu>  x In article <OF4A725075.B6120970-ON8325696E.006E0F3D@ep-bc.petrobras.com.br>, fabio_compaq@ep-bc.petrobras.com.br writes:H >Is there a way to send by VMS Mail  a .PDF file attached   (I have SMTP >configured and-K >it works fine) and extract it in Win platform ???? I am testing it and theO >binary comes in the >body of the message . ..n  K This may be in the FAQ.  And the real answer is that the Q really needs to rI add a few whistles and bells to MAIL, as it's getting pretty old (but is / fundamentally sound.)  l    There are basically two methods.  2 1.  find the VMS version of pine and install that.  9 2.  pick up a version of MPACK and install it.  Then pickA     up a  8     http://seqaxp.bio.caltech.edu/pub/SOFTWARE/MMAIL.COM  %     MMAIL.COM takes these parameters:e  M       P1   File(s) to be mailed - they WILL be deleted!!!!  (Comma delimited)e"       P2   Address(es) to mail to.N       P3   If defined, use second mode (via port 25) instead of MULTINET mode.  
    So that  H     $ @mmail "login.com,foo.splat,whatever.txt" "nobody@nowhere.com" yes  K    would send those 3 files as attachments to the address shown through the-    port 25 method.  <    Read the notes inside the procedure for more information.    G Another posted suggested you pack things up and then use MAIL, but thatoI will NOT work, as MAIL always puts a space after the headers it supplies. H However, there is a very clever work around for that which Howard Foote D and (or?)  Rick Williams  came up with.  The trick is to put all theJ headers into the subject line so that the inevitable space won't break theG MIME headers.  First you use MPACK to make binary attachments, then do   something like:s      $ cr[0,8] = 13e    $ lf[0,8] = 10n,    $ subject = "This is a test." + cr + lf -'    _$ + "Mime-Version: 1.0" + cr + lf -O%    _$ + "Content-Type: text/enriched"c    $ write sys$output subjectf    This is a test.    Mime-Version: 1.0    Content-Type: text/enrichedD    $ mail/subject="''subject'" tt: "SMTP%""anybody@xyzcompany.com"""E    Enter your message below. Press CTRL/Z when complete, or CTRL/C toS    quit:    <bold>Sometimes</bold>s)    <x-color><param>red</param>I</x-color> &    even amaze <italic>myself</italic>!)    ctrl-Z <-- i.e., here I typed a ctrl-zy    $  K VMS 7.2 also comes with MIME but that program isn't worth bothering with at H this time since it won't let you actually send a MIME message (except to, another VMS system).  To use it I had to do      $ mime:==$sys$system:mimet    AL Still, if you like this program you could use it instead of MPACK, and mung - up MMAIL.COM to process the output from MIME.   K One other thing to be aware of.  If you have a forward set on a VMS accountoF to an SMTP mail address MIME mail will be transferred correctly to itsK final destination and will be extractable with normal MIME tools.  However,lI if you receive a message, read it, find it interesting, and then use the 0F MAIL "forward" command to send it the resulting message will be broken when received.   Regards,   David Mathog mathog@seqaxp.bio.caltech.edua? Manager, sequence analysis facility, biology division, Caltech     ------------------------------  # Date: Thu, 05 Oct 2000 07:04:48 GMTl8 From: Veli =?iso-8859-1?Q?K=F6rkk=F6?= <korkko@decus.fi>  Subject: Re: volume set copying.( Message-ID: <39DB5CB4.3F0DBD46@decus.fi>  F On image mode backup the target MUST be mounted foreign. I.e. you have to i   $ mount/foreign dkb500:h $ mount/foreign dkb600:e) $ backup/image disk$data: dkb500:,dkb600:s  @ And the final note is that on IMAGE restore (which this is after< all) of an volume set, ONE HAS TO HAVE exactly as many disks. for the target as the original volume set had.   _veli    krish wrote: > M > I am trying to take a image backup of a bound volume set onto another boundl
 > volume set.H > ! > These are the steps i followed.  > / > I have 4 disks dkb300 , dkb400, dkb500 dkb600e > > > 1 -  initialize dkb300 and dkb400 with label test0 and test1@ > 2-   initizlie    dkb500 and dkb600 with label test2 and test3 > % > 3- after that i gave a command like  > 0 >      mount/bind=data dkb300,dkb400 test0,test1 > N >     this created the bound volume set and the logical disk$date was created., >     then i create some files on that...... > K >  4 - then i mounted the target volume set with a similar command like the  > one i gave above.p > 4 >        mount/bind=datas dkb500:,dkb600 test2,test31 >        this created the target boud volume set.  > H > Now my objective is to  take a image backup of the source bound volumeJ > set(dkb300, and dkb400) to the target bound volume set( dkb500, dkb600). > H > Could somebody suggest me a command that can perform the backup of the8 > source bound volume set to the target bound voume set. > M > I have one more question, some one suggeste me to dismount the target bounddK > volumse set, after making them a volumset, and suggested me to mount themg- > foreign and issue a backup. some thing likeM > D >  after step 4,  dismount dkb500 and dkb600, and mount them foreign
 > separately.D% > and then issue a command similar tol > 8 >    backup/image/noinitialize disk$data dkb500:,dkb600: > % >   But this gives me an error saying  > H >   %BACKUP-F-IMGFILSPE, /IMAGE specification must have only device name > N >  could somebody suggest me a command to backup a volume set, and tell me how? > a mount/foreign command perform backup of a bound volume set.@ >  >   thanks in advance 
 >   -Krish >  > --B > "Courage is the price that life extracts for granting peace with > yourself."Amelia Earhart   ------------------------------  # Date: Thu, 05 Oct 2000 08:25:18 GMTl! From: michael_e_price@my-deja.comj= Subject: Re: What exactly happens when a terminal dissappears9) Message-ID: <8rhdt9$k48$1@nnrp1.deja.com>o  , In article <39DB6D12.4D50FE34@videotron.ca>,0   JF Mezei <jfmezei.spamnot@videotron.ca> wrote:F > I am not sure if this applies to the types of connections your have, but VMSoE > has the ability to keep a session in a coma for a certain amount ofS time inuA > case the user manages to reconnect (at which point, the user is, prompted if he= > wishes to reconnect to his previous session right after thep username/password F > prompt). (I beleive it is the "Disconnect" feature in SET TERMINAL). >-< Thanks - that is true but in this case the process definatlyF dissappears. What I need to know is what VMS is doing to get rid of it= and how the declared exits handlers behave in this situation.R  F I am sure we had this working some time ago and the exit handlers were= firing OK - something seems to have changed - maybe in VMS???.- maybe it is now doing what it is supposed to.u   Does anyone know??  
 TIA as alwaysS   Mike    & Sent via Deja.com http://www.deja.com/ Before you buy.d   ------------------------------  # Date: Thu, 05 Oct 2000 16:50:37 GMT 1 From: "Mark D. Jilson" <jilly@clarityconnect.com>t= Subject: Re: What exactly happens when a terminal dissappearsr2 Message-ID: <39DCB2EC.D895F7B5@clarityconnect.com>  C I can't find anything in this area.  If you have a software support C contract then I would collect the following information when one of=G these jobs hang and get the assistance of your local CSC in determiningAA where/why the job is hanging.  Also have you created a small test C program that is able to duplicate this, if so the CSC would also be  interested in it.n  G $ ! This is the SDA procedure to gather initial information on any hungA processB $ ! If on VAX do this line once.5 $ lib/ext=sys$p1_vector/out=sys$common:[sysexe]p1.stbl sys$share:starlet.olb 	 $ ANA/SYSo	 READ/EXECv READ SYS$SYSTEM:SYSDEF ! If VAXM* READ SYS$LOADABLE_IMAGES:SYSDEF ! If AlphaG READ SYS$SYSTEM:P1.STB ! If VAX and you have done the lib command above.F SET LOG {file.ext} ! Make sure to hit <CR> thru all screens to get all data, SHOW PROCESS/INDEX={pid of the hung process} SHOW PROCESS/IMAGE SHOW PROCESS/CHANNEL	 SHOW CALLi SHOW CALL/NEXT SHOW CALL/NEXT SHOW CALL/NEXTD ! For VAX take the right most address at the Return PC line from the above call frames and do EXAM/INST pc-20;40F ! For Alpha take the 8 digits to the right of the nnnnnnnn.nnnnnnnn PCE in the line Return address on stack from the above call frames and doe EXAM/INST pc-40;80  E This should get someone started.  Also obviously make sure the system A has loaded all the patch kits that apply to VMS, the RTLs and thed network stacks involved.  " michael_e_price@my-deja.com wrote: > . > In article <39DB6D12.4D50FE34@videotron.ca>,2 >   JF Mezei <jfmezei.spamnot@videotron.ca> wrote:H > > I am not sure if this applies to the types of connections your have,	 > but VMSsG > > has the ability to keep a session in a coma for a certain amount ofn	 > time inRC > > case the user manages to reconnect (at which point, the user is  > prompted if he? > > wishes to reconnect to his previous session right after thei > username/passwordpH > > prompt). (I beleive it is the "Disconnect" feature in SET TERMINAL). > >a> > Thanks - that is true but in this case the process definatlyH > dissappears. What I need to know is what VMS is doing to get rid of it? > and how the declared exits handlers behave in this situation.n > H > I am sure we had this working some time ago and the exit handlers were? > firing OK - something seems to have changed - maybe in VMS???p/ > maybe it is now doing what it is supposed to.t >  > Does anyone know?? >  > TIA as alwaysV >  > Mike > ( > Sent via Deja.com http://www.deja.com/ > Before you buy.    --  D Jilly	- Working from Home in the Chemung River Valley - Lockwood, NY0 	- jilly@clarityconnect.com			- Brett Bodine fan. 	- Mark.Jilson@Compaq.com			- since 1975 or so, 	- http://www.jilly.baka.com               -   ------------------------------   Date: 5 Oct 2000 10:22:36 GMTo* From: helbig@astro.rug.nl (Phillip Helbig)/ Subject: Re: Why does TYPE/TAIL sometimes fail?0. Message-ID: <8rhkpc$k5m$2@info.service.rug.nl>  H In article <39DBA63E.437739BE@gtech.com>, Arne =?iso-8859-1?Q?Vajh=F8j?=! <arne.vajhoej@gtech.com> writes: n   > Colin Blake wrote:\ > > TYPE/TAIL only handles records up to 512 bytes. This restriction is really only there to_ > > make dealing with VAR/VFC files easier. It really doesn't need to be there for stream filese" > > and could probably be removed. > : > It should !  That restriction is pretty over-stringent !  H I used to use this on 5.5-2 VAX.  It does some things TYPE/TAIL doesn't.  6 From ACCESS@KRDC.INT.ALCAN.CA Fri Jan  6 13:56:56 1995V Received: from INTNET.INT.ALCAN.CA by staix5.hs.uni-hamburg.de (AIX 3.2/UCB 5.64/4.03)4           id AA42160; Fri, 6 Jan 1995 13:36:07 +0100K Received: from CSG.INT.ALCAN.CA by INTNET.INT.ALCAN.CA (PMDF V4.3-13 #5323)-2  id <01HLIM6MD7V40016TV@INTNET.INT.ALCAN.CA>; Fri,!  06 Jan 1995 06:39:43 -0500 (EST)eJ Received: from KRDC.INT.ALCAN.CA by KRDC.INT.ALCAN.CA (PMDF V4.3-13 #5323)0  id <01HLILQ7YWEO8Y57PI@KRDC.INT.ALCAN.CA>; Fri,!  06 Jan 1995 06:39:31 -0500 (EST)a+ Date: Fri, 06 Jan 1995 06:35:31 -0500 (EST)qK From: Shawn Allin - Alcan KRDC Computer Services <ACCESS@KRDC.INT.ALCAN.CA>o Subject: TAIL.Cg= To: aorndorff@nhtsa.dot.gov, phelbig@staix5.hs.uni-hamburg.dee2 Message-Id: <01HLIM6FZ48A8Y57PI@KRDC.INT.ALCAN.CA> Mime-Version: 1.0e Content-Type: TEXT/PLAIN Content-Transfer-Encoding: 7BITe	 Status: Rr    Date sent:  6-JAN-1995 06:35:35         Hi,  2 I'm sending you TAIL.C.  (No Warranty implied :-))  L As you may have noticed on the list, Kenneth Fairfield corrected some of my E misconceptions about the TYPE/TAIL feature in VMS 6.1.  It certainly rI appears more powerful than I was originally led to believe.  However, if QH you, like me, aren't running VMS 6.1 yet, this is a pretty good version.  
      Regards,w        Shawn Allin      Alcan International Ltd.,      P.O. Box 8400,i      Kingston, Ont.,      Canada  K7L 5L9      (613) 541-2178e        ACCESS@KRDC.INT.Alcan.CAp  J **************************Begin TAIL.C************************************N /*****************************************************************************  - TAIL - gets the last "n" records from a file.d   V2.4 - 09/10/91    Author:r1 D. Shepperd, Atari Games, Corp. shepperd@dms.UUCPu  I This software is supplied with no warranties expressed or implied. Use at J your own risk. Neither Atari Games, Corp. nor I can be held liable for anyJ loss of data or productivity as a result of using this program. Should anyK of your users be caught or killed, the secretary will disavow any knowledge-H of your actions. This software may be copied in whole or in part without restriction.   To build this program:
 	$ CC TAIL 	$ LINK TAIL  I It was developed with Vax C 3.0 under VMS 5.1-1 although it ought to workrI with earlier and later versions of VMS. (The latest version was developed K under VMS 5.4-2 and C 3.0). Since it uses VMS's RMS for file I/O, it is note the least bit portable.y  . To run this program: Create a foreign command:      $ TAIL :== $dev:[dir]TAIL  	 and type:t  H    $ TAIL [/number] [/?] [/S] [/F] [/T secs] input_file(s) [output_file]   where:"    [] denotes optional parameters.    /? - prints a help screen.aB    /number - indicates the number in decimal of records to output.*    /S - forces TAIL to use the "safe" way.D    /F - monitors the input file and outputs records as they show up.C    /T secs - sets the monitor update rate in seconds (forces a /F).   J The /F option sets a display rate of 5 seconds. The /T option will force aE /F and sets the display rate to the number of seconds specified. Type J <return>  or some other terminator character on the terminal to advance toL the next  file if wildcards are used on input and the /F option is selected.H If  monitoring batch .LOG files, you will probably want to correlate theH monitor  rate with the batch log's SET OUTPUT_RATE parameter (normally 1 minute).  3 You can use "-" in place of "/" to delimit options.   I The defaults applied to the input file spec are "SYS$DISK:[].LOG" and the I output file defaults to SYS$OUTPUT. The input file may contain wildcards, H however, if you use wildcards on the input filename AND supply an outputH file name, only the first file in the wildcard list will be put into the= specified output file. The rest will be output to SYS$OUTPUT.B  G The /S can be used to force TAIL to read the file(s) from the beginning K rather than from the end. You would use /S if, for some reason, TAIL screwslJ up trying to figure out the record structure on variable  length files but for some reason doesn't notice.-   Design goal:  H Make a TAIL utility that can very quickly pickup the last n records of aJ batch log file (which tend to be tens of thousands of blocks long for some
 of our jobs)._  I How it works (more or less): For fixed length records, TAIL just seeks tohL the desired record and dumps the file from there. For stream record formats,F it reads from the end of the file and counts backwards the appropriateG number of terminators, then seeks to that point and dumps the file frommI there. For variable and VFC record formats, it has two modes. The default(J mode is for it to seek to the end of the file and read backwards trying toH determine record boundaries based upon some reasoning. This will usuallyL work if the records are relatively short and there are few (preferrably  no)J control characters in it. TAIL trys to figure out if it is getting screwedJ up, and sometimes it may, and will fall back to the "safer" mode if so. ItI may not notice, however, so you can force it to use the "safer" mode with,C the /S option. The "safer" mode is where it reads the file from the L beginning, recording the record file address (rfa) of each record as it goesI (modulo the number of desired lines). When it reaches the end of file, it_I backs up through the rfa table the desired number of lines, seeks to that G point and dumps the file from there. It always uses the "safer" mode onmI input files less than 128 blocks in size. In the "safer" mode, it doesn't_L use RMS $GET calls for each record. Instead it reads up to 127 blocks of theI file at a time then decodes the record structure within that 64K of data.:I This results in a substantially faster access to the end of the file than L would normally be  available with successive $GET calls. Monitor mode startsL the same way, however, once the record structure has been determined it doesJ successive $GET calls  to obtain the records added to the end of the inputD file. Due to a "feature" of RMS, the input file has to be closed andG reopened in order to gain access to data added to the end of an alreadytI opened file. Although this undoubtly adds overhead to the system (closingsJ and opening the file every few seconds) TAIL maintains the rfa of the lastK record read, so it can seek to that record to get quick access to the "new"a# records at the new end of the file.M   BUGS:i  H Nothing major has cropped up since the image was released in 4/90. SinceJ this  release has so many new features, it has at least an equal number ofE areas of  potential bugdom. Beware. Besides these new features, there I remains the old tried an true (but yet to happen to me) small possibilityoH that it could seek to a point in a variable length file that RMS doesn'tL like (only while it is NOT using the "safer" mode). This doesn't seem likelyE because I believe that RMS should like whatever record structure TAIL I decodes even if it is not the correct one. Should TAIL seek to a point in K the file that RMS doesn't like, however, one of several things might occur.rJ Probably RMS will return an "invalid record format" error. There is a slimF chance that RMS might bugcheck which would not be a nice thing to haveJ happen to you and if your SYSGEN option BUGCHECKFATAL=1, your system wouldL crash. If BUGCHECKFATAL=0, your process would be deleted. I suggest you keepJ BUGCHECKFATAL=0 and use some care if TAIL'ing binary files (or chicken out# and always use /S on binary files).n  + Does not treat: <dir>file, only: [dir]file.   H This program is getting to damn big and I can't remember how the hell it works.   Areas for improvment:c  I Currently the monitor mode does a double read of the tail end of the file L via multiple $GET's. This could be optimized by having the normal block modeF reader start where the last_rfa pointed and doing a normal "safer" wayG search from there. This would result in a performance improvment if the I file grows by at least dozens of records between monitor mode samples. IfcJ the file grows by less then a screen full of records between samples, then4 changing this probably wouldn't make any difference.  > Use async I/O and double buffering during the safe mode reads.I This might speed up the reading a little (might reduce spindle rotationaltH latency delays). Probably wouldn't make any difference on files accessed via LAVC or DECnet.o  B Accept default values via an environment variable or logical name.  M *****************************************************************************l  
 Edit History:e@ 	091091_DMS v2.4 Added a -f option (monitor) and set the default5 			number of lines to the terminal's page size. Addedi5 			some additional comments. This release has lots ofi2 			BIG changes so there's plenty of room for bugs.4    			And, as luck would have it, plenty were found.  C 	041790_DMS v2.3 Didn't notice the default input file spec had beenh2 			changed to *.* from .LOG; so I changed it back.  A 	041490_DMS v2.2 Made it only output a filename if there was morek. 			than 1 input file. Only did highlighting if7 			outputting to tty, made "maxargs" adjust dynamically 3 			instead of being #defined. Put in a help screen.a* 			Posted this version to usenet 04/14/90.  A 	031290_KAR v2.1 Kjell Arne Rekaa - EB COMDATA, NORWAY: Corrected 1 			minor error: One line less than specified with 3 			/n was displayed. Accepts wildcards on filespec.t) 			Filename displayed prior to each file.g  > 	021790_DMS v2.0 added the "read backwards" algorithm for both 			stream and variable rfm's.n   	010590_DMS v1.0	image release  L ***************************************************************************/    * #include descrip		/* descriptor details */+ #include stdio			/* for printf and stuff */s- #include rms			/* for the "real" I/O stuff */l/ #include dvidef			/* stuff for the GETDVI ss */a% #include dcdef			/* device classes */a  #include iodef			/* QIO stuff */% #include msgdef			/* mailbox stuff */ ' #include ssdef			/* completion codes */   , struct FAB inp_fab;		/* Input fab/rab/xab */ struct RAB inp_rab;  struct XABFHC inp_xab;  ) struct FAB out_fab;		/* Output fab/rab */a struct RAB out_rab;m  2 typedef struct {		/* define an item list struct */(    short length;		/* length of buffer */     short code;			/* item code */#    void *ptr;			/* ptr to buffer */o,    void *retlen;		/* ptr to return length */ } Item;u  , typedef struct {		/* Genernic IOSB struct */    short status;    short length;    long devdepend; } Iosb;b   typedef struct {&    unsigned long block;		/* block # */3    unsigned short offset;	/* offset within block */t-    unsigned short length;	/* record length */h } Rfa;  0 typedef struct {		/* VMS 64 bit quadword time */    long lsb;    long msb;
 } VMSTime;  B unsigned char inp_buf[65536-512]; /* 127 blocks of buffer space */B int the_safe_way=0;		/* If != then read var files front to back */7 int monitor;			/* if != then loop on display of tail */ ( int sec=5;			/* delay time in seconds */: int tti_chan;			/* channel to use to look for stop code */0 char tti_text[8];		/* room for terminal input */. Iosb tti_iosb;			/* IOSB for terminal input */- int tti_class;			/* SYS$INPUT device class */n. int tto_class;			/* SYS$OUTPUT device class */E int tto_page;			/* SYS$OUTPUT page size (if tto_class == DC$_TERM) */n6 int were_done;			/* if !=, signals monitor complete */6 int last_rfa_blk;		/* saved rfa of last record read */ int last_rfa_off;_  G char default_string[] = "SYS$DISK:[].LOG"; /* default input filename */p  ? Item tt_dvi[] = {		/* An item list used to get SYS$xxx class */9"    {4,DVI$_DEVCLASS,&tto_class,0},     {4,DVI$_TT_PAGE,&tto_page,0},    {0,0,0,0} };   $DESCRIPTOR(sysin,"SYS$INPUT");p! $DESCRIPTOR(sysout,"SYS$OUTPUT");M  * /* rfa stands for "record file address" */  . Rfa *rfas;			/* ptr to array of rfa structs */7 int record_count=23;		/* number of records to output */ 3 int	maxargs;		/* records size of next_file array */ ? char **next_file;		/* pts to array of char ptrs to filenames */vY VMSTime delay = {-5*10*1000*1000, /* 64 bit VMS delta time format for monitor timer... */a* 		 -1};		/* ...initialized to 5 seconds */   char *mini_help_msg[] = { B    "TAIL version 2.4, 09/10/91. D. Shepperd, shepperd@dms.UUCP\n",P    "Usage: TAIL [/record_count] [/S] [/F] [/T secs] input_file [output_file]\n",    0 };   char *help_msg[] = {-    "where: \"[]\" indicates optional data\n", ?    " \"/record_count\" is decimal number of records desired\n", 3    " \"/S\" indicates to use the \"safer\" mode\n",w?    " \"/F\" monitor tail end of file (5 second sample rate)\n", J    " \"/T secs\" monitor tail end of file with sample rate of \"secs\"\n",B    " \"input_file\" is the input filename (can have wildcards)\n",I    " \"output_file\" is output filename (bogus if wildcards on input)\n",iO    "Note that a \"-\" can be used in place of the \"/\" to delimit options.\n", R    "White space is required between all arguments (including the /T and secs).\n",J    "Options may appear in any order, but all must preceed filename(s).\n",    0 };     void mini_help() {a    char **s;F    for (s=mini_help_msg;*s;++s) fputs(*s,stderr); /* show mini help */
    return; }    void show_help() {     char **s;    mini_help();AI    for (s = help_msg;*s;++s) fputs(*s,stderr);	/* display help message */y
    return; }e   int main(int argc,char *argv[])  {/'    int param;			/* Parameter counter */!,    int err;			/* place to hold rms errors */2    int rfm;			/* loaded with record format code */    int i, files;  1    err = sys$getdviw(0,0,&sysin,&tt_dvi,0,0,0,0);>     if ((err&1) == 0) return err;    tti_class = tto_class;f  2    err = sys$getdviw(0,0,&sysout,&tt_dvi,0,0,0,0);     if ((err&1) == 0) return err;K    if (tto_class == DC$_TERM) record_count = tto_page > 2 ? tto_page-1 : 2;e  9    inp_fab = cc$rms_fab;	/* init the input fab/rab/xab */ 5    inp_fab.fab$b_shr = FAB$M_GET|FAB$M_PUT|FAB$M_UPI; +    inp_fab.fab$b_fac = FAB$M_GET|FAB$M_BRO;a    inp_rab = cc$rms_rab;    inp_rab.rab$l_ubf = inp_buf;SD    inp_rab.rab$w_usz = sizeof(inp_buf);	/* assume to read the max */    inp_xab = cc$rms_xabfhc;l<    inp_rab.rab$l_fab = &inp_fab;	/* tell rab where fab is */<    inp_fab.fab$l_xab = &inp_xab;	/* tell fab where xab is */D    inp_fab.fab$l_dna = default_string;	/* say input file defaults */0    inp_fab.fab$b_dns = sizeof(default_string)-1;  .    param = 1;			/* start looking at argv[1] */&    --argc;			/* skip the image name */1    while(1) {			/* get all the command options */i       char c,*s;       if (argc < 1) break;       s = argv[param];       c = *s++;d!       if (c == '/' || c == '-') {h 	 c = *s++;e 	 c = toupper(c);h 	 switch (c) { 	    int secs; 	    case '?': 	    case 'H': 	       show_help(); 	       return 0x10000003;  	    case 'S':		/* safer mode */ 	       the_safe_way = 1;s 	       break;1 	    case 'T':		/* set monitor rate in seconds */  	       if (*s == 0) { 		  if (--argc < 1) { 6 		     fputs("Missing delay time parameter\n",stderr); 		     mini_help();x 		     return 0x10000002;O 		  }e 		  s = argv[++param];	 	       } D 	       if (sscanf(s,"%d",&secs) != 1 || secs <= 0 || secs > 2000) {; 		  fprintf(stderr,"Invalid delay time parameter: %s\n",s);tA 		  fputs("Time value must be between 1 and 2000 secs\n",stderr);l 		  mini_help(); 		  return 0x10000002;	 	       }o' 	       delay.lsb = -secs*10*1000*1000;	H 	    /* fall through to /F to default to monitor mode if /T specified */& 	    case 'F':		/* set monitor mode */ 	       monitor = 1; 	       break;7 	    default:		/* assume the param is a record count */P@ 	       --s;		/* backup to the first char of the record count */E 	       if (sscanf(s,"%d",&record_count) != 1 || record_count <= 0) {4= 		  fprintf(stderr,"Invalid record count parameter: %s\n",s);e 		  mini_help(); 		  return 0x10000002;	 	       }Y  	 }
 	 ++param;	 	 --argc;u       } else { 	 break;       }     }D    record_count++;	/* Fix of wrong record_count. KAR - 6-mar-1990 */    if (argc < 1) {       show_help();       exit(0x10000003);y    }M    files = fgen(argv[param], &next_file, &maxargs);	/* deal with wildcards */d    if (files < 1) { /       fputs("No input file(s) found\n",stderr);r       return 0x10000002;    }    if (monitor) {5"       if (tti_class != DC$_TERM) {H 	 fputs("Cannot monitor files if SYS$INPUT is not a terminal\n",stderr); 	 monitor = 0;       } else {) 	 err = sys$assign(&sysin,&tti_chan,0,0);. 	 if ((err&1) == 0) {-S 	    fputs("Error assigning channel to SYS$INPUT, monitor mode disabled\n",stderr);  	    monitor = 0;v 	 }r5 	 que_ttiread();		/* que up a read to the terminal */        }i    }     for (i = 0; i < files; i++) {       if (files > 1) { 	 if (tto_class == DC$_TERM) {G 	    printf("\r\n	 \033[7m**************** %s ****************\033[0m",  		     next_file[i]);N
 	 } else {8 	    printf("\r\n	**************** %s ****************", 		     next_file[i]);e 	 }s       }0J       inp_fab.fab$l_fna = next_file[i];	/* input filename is next param *//       inp_fab.fab$b_fns = strlen(next_file[i]); .       if (((err=sys$open(&inp_fab))&1) == 0) {- 	 fputs("Error opening input file\n",stderr);l 	 exit(err);       }h1       if (((err=sys$connect(&inp_rab))&1) == 0) {d/ 	 fputs("Error connecting input rab\n",stderr);f 	 exit(err);       }c+       if (inp_fab.fab$b_org != FAB$C_SEQ) {o 	 char *oldtype="UNKNOWN";; 	 if (inp_fab.fab$b_org == FAB$C_REL) oldtype = "RELATIVE";i: 	 if (inp_fab.fab$b_org == FAB$C_IDX) oldtype = "INDEXED";9 	 if (inp_fab.fab$b_org == FAB$C_HSH) oldtype = "HASHED"; [ 	 fprintf(stderr,"Input file organization is %s. This program only supports SEQUENTIAL.\n",C
 		  oldtype);* 	 exit(0x10000002);        }*N       if (inp_fab.fab$b_rfm == FAB$C_UDF || inp_fab.fab$b_rfm > FAB$C_STMCR) {K 	 fputs("Input file has undefined or unsupported record format.\n",stderr);i 	 exit(0x10000002);9       }h7       out_fab = cc$rms_fab;			/* init the output fab */ J       out_fab.fab$b_bks = inp_fab.fab$b_bks;	/* make rest same as input */,       out_fab.fab$w_bls = inp_fab.fab$w_bls;,       out_fab.fab$w_deq = inp_fab.fab$w_deq;$       out_fab.fab$b_fac = FAB$M_PUT;,       out_fab.fab$b_fsz = inp_fab.fab$b_fsz;,       out_fab.fab$w_mrs = inp_fab.fab$w_mrs;,       out_fab.fab$b_rat = inp_fab.fab$b_rat;,       out_fab.fab$b_rfm = inp_fab.fab$b_rfm;       out_rab = cc$rms_rab;:@       out_rab.rab$l_fab = &out_fab;		/* tell rab where fab is */       if (--argc >= 1) {H 	 out_fab.fab$l_fna = argv[++param];	/* output filename is next param */       } else {7 	 out_fab.fab$l_fna = "SYS$OUTPUT:";	/* else default */i       }t4       out_fab.fab$b_fns = strlen(out_fab.fab$l_fna);0       if (((err=sys$create(&out_fab))&1) == 0) {. 	 fputs("Error opening output file\n",stderr); 	 exit(err);       }c1       if (((err=sys$connect(&out_rab))&1) == 0) {o0 	 fputs("Error connecting output rab\n",stderr); 	 exit(err);       }d4       rfm = inp_fab.fab$b_rfm;	/* pickup rfm code */A       last_rfa_blk = last_rfa_off = 0;	/* start at top of file */t       were_done = 0;       while (1) {. 	 long oldebk;
 	 int oldffb; E 	 oldebk = inp_xab.xab$l_ebk;	/* remember the old end of file mark */r 	 oldffb = inp_xab.xab$w_ffb; H 	 if (last_rfa_blk != 0) {		/* if we've already been through the file */B 	    err = skip_through();	/* then just start where we left off */
 	 } else {! 	    switch (inp_fab.fab$b_rfm) {  	       case FAB$C_FIX:  		  err = do_fixed(); 
 		  break; 	       case FAB$C_VAR:w 		  err = do_var();c
 		  break; 	       case FAB$C_VFC:b 		  err = do_var();_
 		  break; 	       case FAB$C_STM:  		  err = do_stream(2);e
 		  break; 	       case FAB$C_STMCR:a 		  err = do_stream(1); 
 		  break; 	       case FAB$C_STMLF:  		  err = do_stream(0); 
 		  break; 	       default: 		  err = 0x10000004;o, 		  fputs("Unknown record format\n",stderr); 		  exit(err); 	    } 	 }e 	 if ((err&1) == 0) {i 	    if (err != RMS$_EOF) {b. 	       fputs("Error reading input\n",stderr); 	       exit(err); 	    } 	 } ( 	 if (!monitor || were_done == 1) break; 	 while (!were_done) { 	    sys$schdwk(0,0,&delay,0); 	    sys$hiber();iK 	    err = sys$display(&inp_fab);	/* see if stuff has been added to file */e 	    if ((err&1) == 0) {P 	       fputs("Error doing $DISPLAY on input, monitor mode cancelled\n",stderr); 	       were_done = 1; 	       break; 	    }F 	    if (inp_xab.xab$l_ebk == oldebk && inp_xab.xab$w_ffb == oldffb) {< 	       continue;			/* eof hasn't moved, continue waiting */ 	    }X    /* This part is goofy. One would think that a simple sys$display would be all that */X    /* should be required, but nooooooo.... DEC has set some internal flags that will  */X    /* not let me read past the old end of file regardless of the fact the the eof has */X    /* moved. What's really goofy is that sys$display notices that the eof has moved   */X    /* but it won't change those internal flags. Closing/reopening the file every few  */J    /* seconds seems like an expensive proposition to me. Grrrr.			      */4 	    err = sys$close(&inp_fab);	/* close the file */ 	    if ((err&1) == 0) {7 	       fputs("Error closing the input file\n",stderr);  	       exit(err); 	    }4 	    err = sys$open(&inp_fab);	/* reopen the file */ 	    if ((err&1) == 0) {9 	       fputs("Error reopening the input file\n",stderr);e 	       exit(err); 	    }9 	    err = sys$connect(&inp_rab);	/* reconnect the rab */r 	    if ((err&1) == 0) {; 	       fputs("Error reconnecting the input rab\n",stderr);_ 	       exit(err); 	    } 	    break;r 	 }m       }n       sys$close(&inp_fab);       sys$close(&out_fab);    }     if ((err&1) != 0) return err;#    if (err != RMS$_EOF) return err;e    return SS$_NORMAL;i }o  K /**************************************************************************f?  * do_seqout - sequentially output the data from the input filet  *  * At entry:"  *	rfa_blk - starting block number3  *	rfa_off - offset within block to start of recordb  * At exit:wK  *	last_rfa_blk and last_rfa_off are set to the rfa of the last record readh'  *	input file has been dumped to output L  **************************************************************************/  K do_seqout(long rfa_blk,int rfa_off)	/* seek to desired record and output */n {i    int err,skip=0;>    if (rfa_blk == 0) rfa_blk = 1;	/* start at the beginning */X    if (rfa_blk < last_rfa_blk || (rfa_blk == last_rfa_blk && rfa_off <= last_rfa_off)) {C       rfa_blk = last_rfa_blk;			/* seek to record last displayed */        rfa_off = last_rfa_off;e$       skip = 1;				/* and skip it */    }7    inp_rab.rab$l_rfa0 = rfa_blk;	/* starting block # */e?    inp_rab.rab$w_rfa4 = rfa_off;	/* byte offset within block */ A    inp_rab.rab$b_rac = RAB$C_RFA;	/* change to RFA access mode */a=    inp_rab.rab$l_bkt = 0;		/* make sure bkt field is clear */h4    inp_rab.rab$l_rhb = inp_buf;		/* init the ptrs */Q    inp_rab.rab$l_ubf = inp_buf + inp_fab.fab$b_fsz; /* in case making VFC file */t    out_rab.rab$l_rhb = inp_buf;g3    out_rab.rab$l_rbf = inp_buf + inp_fab.fab$b_fsz; 
    while(1) {RK       last_rfa_blk = inp_rab.rab$l_rfa0;	/* save rfa of last record read */ (       last_rfa_off = inp_rab.rab$w_rfa4;3       err=sys$get(&inp_rab);		/* read the record */e       if ((err&1) == 0) {  	 if (err != RMS$_EOF) {+ 	    fputs("Error reading input\n",stderr);l 	    exit(err);M 	 }h 	 break;       }uJ       inp_rab.rab$b_rac = RAB$C_SEQ;	/* switch back to sequential reads */,       out_rab.rab$w_rsz = inp_rab.rab$w_rsz;8       if (skip == 0) {			/* if not to skip the record */8 	 if (((err=sys$put(&out_rab))&1) == 0) { /* write it */, 	    fputs("Error writing output\n",stderr); 	    exit(err);  	 }n       } 2       skip = 0;				/* at most, we skip 1 record */    }    return err; }'   char end_mark[] = "\n\r\n";k  K /**************************************************************************fH  * do_stream - figure out the record structure for one of the 3 types of  *		stream files there are.e  * At entry:2  *	type - record type. 0=stmlf, 1=stmcr, 2=stmcrlf  * At exit:hA  *	has called do_seqout with the computed block and offset of the   *	desired starting record. L  **************************************************************************/   do_stream(type)s+ int type;	/* 0=stmlf, 1=stmcr, 2=stmcrlf */y {u!    unsigned long block,rfa_blk=0;s/    int rcd_num= 0,err,rfa_off,part1=0,end_char;     unsigned char *s;  +    inp_rab.rab$l_bkt = inp_xab.xab$l_ebk+1;e    end_char = end_mark[type];P  :    while(1) {				/* as long as there's data in the file */G       if (inp_rab.rab$l_bkt <= 1) {	/* quit if we already read blk 1 */g. 	 rfa_blk = 1;			/* give 'em the whole file */ 	 rfa_off = 0; 	 break;       }*7       block = inp_rab.rab$l_bkt-(inp_rab.rab$w_usz>>9);p\       if (block == 0 || block > inp_rab.rab$l_bkt) block = 1;	/* but can't start before 1 */E       inp_rab.rab$l_bkt = block;	/* rememebr starting block number */        err = sys$read(&inp_rab);        if ((err&1) == 0) {v 	 if (err == RMS$_EOF) break;1F 	 fprintf(stderr,"Error (%08X) trying to read %d bytes at block %d\n", 		err,inp_rab.rab$w_usz,block);e 	 continue;        }M.       s = inp_rab.rab$l_ubf+inp_rab.rab$w_rsz;         if (part1) { 	 if (*--s == '\r') {l2 	    rfa_blk = block+((s+2)-inp_rab.rab$l_ubf>>9);- 	    rfa_off = ((s+2)-inp_rab.rab$l_ubf)&511; * 	    if (++rcd_num >= record_count) break; 	 }  	 ++s;       }        part1 = 0;&       while (s >= inp_rab.rab$l_ubf) { 	 if (*--s == end_char) {  	    char *nrp;n/ 	    nrp = s+1;			/* next record starts here */l( 	    if (type == 2) {		/* if strmcrlf */: 	       if (s <= inp_rab.rab$l_ubf) {	/* if on the cusp */ 		  part1 = 1;		/* defer */ # 		  break;		/* get somemore data */0	 	       }0= 	       if (*--s != '\r') {	/* else if next char is not cr */** 		  ++s;			/* then this is not a record */
 		  continue;s	 	       }a 	    }0 	    rfa_blk = block+(nrp-inp_rab.rab$l_ubf>>9);+ 	    rfa_off = (nrp-inp_rab.rab$l_ubf)&511;i* 	    if (++rcd_num >= record_count) break; 	 }	       }dA       if (rcd_num >= record_count) break;	/* we got everything */u    }%    if (rfa_blk == 0) return RMS$_EOF;d=    return do_seqout(rfa_blk,rfa_off);	/* write out records */a }a  I /************************************************************************	E  * do_varfast. This procedure trys to figure out the record structurefD  * of a variable length file while reading from the end of the file.  *  * At entry:  *	(called by do_var)   * At exit:rA  *	returns a 0 if it couldn't determine a valid record structure.m>  *	called do_seqout with a computed block and offset if it did4  *		successfuly find an appropriate record boundary.(  *	returns with RMS status in all cases.K  *************************************************************************/s   do_varfast() {	!    unsigned long block,rfa_blk=0;e1    int rcd_num= 0,err,rec_len,rfa_off,min_recsiz;n
    union {       unsigned char *s;n       unsigned short *len;       unsigned int align;     } rp;  +    inp_rab.rab$l_bkt = inp_xab.xab$l_ebk+1;e    rec_len = 0;/"    min_recsiz = inp_fab.fab$b_fsz;E    inp_rab.rab$w_usz = ((inp_xab.xab$w_lrl+3)*record_count+511)&~511;t  
    while(1) {nL       if (inp_rab.rab$l_bkt <= 1) break; /* quit if we already read blk 1 */7       block = inp_rab.rab$l_bkt-(inp_rab.rab$w_usz>>9);n\       if (block == 0 || block > inp_rab.rab$l_bkt) block = 1;	/* but can't start before 1 */E       inp_rab.rab$l_bkt = block;	/* remember starting block number */        err = sys$read(&inp_rab);s       if ((err&1) == 0) {a 	 if (err == RMS$_EOF) break;sQ 	 fprintf(stderr,"Error (%08X) trying to read %d bytes at block %d, record %d\n",/' 		err,inp_rab.rab$w_usz,block,rcd_num);v 	 continue;n       }t1       rp.s = inp_rab.rab$l_ubf+inp_rab.rab$w_rsz;,?       if ((rp.align&1) == 1) ++rp.align;	/* ffb must be even */;  J /*************************************************************************P  * The following procedure loops through the buffer picking up pairs of bytes (aM  * short) on even byte boundaries from the end. If this pair of bytes forms a;Q  * integer whose value points within 1 of the the next record or the current eof,rM  * then the pair is assumed to be the count field of a valid record and is soiQ  * recorded. It can easily get screwed up if there is binary data in the records,hN  * but for ascii files such as log files, it ought to work well enough most ofQ  * the time. The integer value represents the length of the record. If this valuetI  * is greater than the maxium record length recorded for the file (in thepQ  * XAB$W_LRL field of the XABFHC), then this routine assumes to have gotten lost,   * so it rolls over and dies.eK  *************************************************************************/a         while (1) {e 	 int len,t; 	 char *tp;l# 	 rp.s -= 2;			/* backup 2 bytes */ C 	 if (rp.s < inp_rab.rab$l_ubf) break;	/* too far, get more data */" 	 len = *rp.len;H 	 if (rec_len >= min_recsiz &&	/* if currently at or greater than min */9 	     (len == rec_len ||		/* and lengths match exactly */ * 	      (rec_len > 0 &&		/* or less by 1 */ 	       len == rec_len-1))) {eK 	    rfa_blk = block+(rp.s-inp_rab.rab$l_ubf>>9); /* remember this point */s, 	    rfa_off = (rp.s-inp_rab.rab$l_ubf)&511; 	    rec_len = 0;(* 	    if (++rcd_num >= record_count) break; 	    continue; 	 } / 	 rec_len += 2;			/* increase size of record */;F 	 if (rec_len > inp_xab.xab$w_lrl) return 0; /* we're lost, give up */       }pA       if (rcd_num >= record_count) break;	/* we got everything *//    }%    if (rfa_blk == 0) return RMS$_EOF; =    return do_seqout(rfa_blk,rfa_off);	/* write out records */a }   I /************************************************************************iG  * skip_through - this routine positions to the desired record beginingoE  * with a known starting position. It is used in monitor mode to skip(D  * records that may have been added to the input file since the last  * time it was looked at it.  *  * At entry:?  *	last_rfa_blk and last_rfa_off point to the last record read.s  * At exit:T4  *	called do_seqout with a computed block and offsetA  *	last_rfa_blk and last_rfa_off point to a new last record read.p  *J  ************************************************************************/   int skip_through() {l    int err;r-    int first_rfa=0;		/* index to first rfa *//5    int next_rfa=0;		/* index to next available rfa */b  H    if (rfas == (Rfa *)0) rfas = (Rfa *)calloc(record_count,sizeof(Rfa));=    inp_rab.rab$l_rfa0 = last_rfa_blk;	/* where we left off */=%    inp_rab.rab$w_rfa4 = last_rfa_off; A    inp_rab.rab$b_rac = RAB$C_RFA;	/* change to RFA access mode */e;    inp_rab.rab$l_bkt = 0;		/* make sure bkt field is off */r4    inp_rab.rab$l_rhb = inp_buf;		/* init the ptrs */Q    inp_rab.rab$l_ubf = inp_buf + inp_fab.fab$b_fsz; /* in case making VFC file */     while (1) {2       (rfas+next_rfa)->block = inp_rab.rab$l_rfa0;3       (rfas+next_rfa)->offset = inp_rab.rab$w_rfa4;d       next_rfa += 1;       next_rfa %= record_count;c"       if (next_rfa == first_rfa) { 	 first_rfa += 1;f 	 first_rfa %= record_count;       }	       err=sys$get(&inp_rab);       if ((err&1) == 0) {  	 if (err != RMS$_EOF) {+ 	    fputs("Error reading input\n",stderr);r 	    exit(err);  	 }  	 break;       },D       inp_rab.rab$b_rac = RAB$C_SEQ;	/* switch back to sequential */    }F    return do_seqout((rfas+first_rfa)->block,(rfas+first_rfa)->offset); }0  I /************************************************************************ E  * do_var. This procedure positions to the nth record from the end ofeD  * a file by reading the whole file into memory 127 blocks at a timeE  * and skipping through the records recording the block and offset ofu  * each as it goes.o  *  * At entry:  *  * At exit:u6  *	called do_seqout with the computed block and offsetJ  *	last_rfa_blk and last_rfa_off updated to point to the last record read.  *	returns with RMS status.mK  *************************************************************************/    do_var() {-    long block,rcd_num= 0;r    int err; -    int first_rfa=0;		/* index to first rfa */r5    int next_rfa=0;		/* index to next available rfa */     unsigned char *ebp;
    union {       char *s;       unsigned short *len;       unsigned int align;i    } rp;  L /* Unless otherwise indicated, trys to do the fast way first. If that fails,  * it'll do the hard way. */  I    if (the_safe_way == 0 && inp_xab.xab$l_ebk > (inp_rab.rab$w_usz>>9)) {i.       if ((err=do_varfast()) != 0) return err;S       fputs("Unable to determine record structure from backend of file.\n",stderr);f:       fputs("Doing it the 'safer' way instead.\n",stderr);G       inp_rab.rab$w_usz = sizeof(inp_buf);	/* assume to read the max */     }	r    rp.s = inp_rab.rab$l_ubf;    inp_rab.rab$l_bkt = 1; H    if (rfas == (Rfa *)0) rfas = (Rfa *)calloc(record_count,sizeof(Rfa));
    while(1) {)        block = inp_rab.rab$l_bkt;       err = sys$read(&inp_rab);08       inp_rab.rab$l_bkt += (inp_rab.rab$w_rsz+511) >> 9;       if ((err&1) == 0) {* 	 if (err == RMS$_EOF) break;iQ 	 fprintf(stderr,"Error (%08X) trying to read %d bytes at block %d, record %d\n", ' 		err,inp_rab.rab$w_usz,block,rcd_num);  	 continue;_       } 0       ebp = inp_rab.rab$l_ubf+inp_rab.rab$w_rsz;       while (1) {i 	 int len,t; 	 char *tp; $ 	 if ((rp.align&1) == 1) ++rp.align; 	 if (rp.s >= ebp) { 	    t = rp.s - ebp; 	    inp_rab.rab$l_bkt += t>>9;s& 	    rp.s = inp_rab.rab$l_ubf+(t&511); 	    break;a 	 }r 	 ++rcd_num; 	 len = *rp.len; 	 if (len > 32767) { 	    if (len == 0xFFFF) {R! 	       rp.s = inp_rab.rab$l_ubf;n 	       break;			/* eof */ 	    }a 	    fprintf(stderr,"Warning: Record %d (blk=0x%08X,off=0x%04X): cnt %04X greater than 0x7FFF\n", O 			rcd_num,(rp.s-inp_rab.rab$l_ubf>>9)+block,(rp.s-inp_rab.rab$l_ubf)&511,len);) 	 }  	 t = rp.s-inp_rab.rab$l_ubf; , 	 (rfas+next_rfa)->block = block + (t >> 9);$ 	 (rfas+next_rfa)->offset = t & 511;  	 (rfas+next_rfa)->length = len; 	 next_rfa += 1; 	 next_rfa %= record_count;1 	 if (next_rfa == first_rfa) { 	    first_rfa += 1; 	    first_rfa %= record_count;u 	 }. 	 rp.s += len+2;       }k    }5    if ((rfas+first_rfa)->block == 0) return RMS$_EOF;nF    return do_seqout((rfas+first_rfa)->block,(rfas+first_rfa)->offset); }a  I /************************************************************************ G  * do_fixed. This procedure positions to the nth record from the end of.C  * a fixed length record file by computing the desired rfa from theaD  * required record number, the size of the file and the size of eachF  * record. This is by far the simplest of the three decoding routines.  *  * At entry:  *  * At exit:a6  *	called do_seqout with the computed block and offsetJ  *	last_rfa_blk and last_rfa_off updated to point to the last record read.  *	returns with RMS status.yK  *************************************************************************/;  
 do_fixed() {     int reccnt;    unsigned long size,sbn;    long start,rfa_blk,rfa_off;  K    size = inp_xab.xab$l_ebk*512+inp_xab.xab$w_ffb; /* file size in bytes */a<    reccnt = size/inp_xab.xab$w_mrz;	/* total record count */9    start = reccnt - record_count;	/* starting record # */ ;    if (start < 0) start = 0;		/* can't go past beginning */=7    sbn = start*inp_xab.xab$w_mrz;	/* starting byte # */*9    rfa_blk = (sbn >> 9) + 1;		/* starting block number */)/    rfa_off = sbn & 511;			/* offset in block */ W    if (rfa_blk < last_rfa_blk || (rfa_blk == last_rfa_blk && rfa_off < last_rfa_off)) {cL       rfa_blk = last_rfa_blk;		/* don't display records already displayed */F       rfa_off = last_rfa_off+inp_xab.xab$w_mrz; /* advance 1 record */E       if (rfa_off >= 512) {		/* and adjust pointers if appropriate */n 	 rfa_off -= 512;c 	 rfa_blk += 1;o       }     }E    return do_seqout(rfa_blk,rfa_off);	/* write the end of the file */l }&  
 int tti_ast()g {/    int sts; &    if (tti_iosb.status == SS$_ABORT) {K       return SS$_NORMAL;		/* aborts are ok, since they'll happen at exit */o    }K    if (tti_iosb.status == SS$_NORMAL || tti_iosb.status == SS$_ENDOFFILE) {e3       were_done = 1;			/* signal that we're done */t/       sys$canwak(0,0);			/* cancel our schwk */r3       sys$wake(0,0);			/* wake up from our hiber */e    } else {o%       if ((tti_iosb.status&1) == 0) { 0 	 fputs("Error reading from maillbox\n",stderr); 	 exit(tti_iosb.status);       }*    }    return que_ttiread(); }l   int que_ttiread()w {     int sts;f    sts = sys$qio(	0,		/* efn */r 			tti_chan,	/* channel */ 			IO$_READVBLK,	/* function */a 			&tti_iosb,	/* iosb addr */t 			tti_ast,		/* astadr */  			0,		/* astparam */d" 			tti_text,	/* p1 (buffer ptr) */+ 			sizeof(tti_text), /* p2 (buffer size) */o! 			0,0,0,0);	/* p3-p6 not used */*      if ((sts&1) == 0) {M       fputs("unable to do QIO to SYS$INPUT, monitor mode disabled\n",stderr);l       monitor = 0;    }    return sts; }(  H /* ==============================fgen.c============================== */   #include <descrip.h>8 /* #include <rms.h>  ...defined in the program top... */   /*,  * fgen(pattern, result_array, array_length)?  *   fgen generates filenames of files, matching a VMS pattern,rK  *   the results are stored in an array, space for the strings is allocated   *   by using malloc.a  * Return values:b  *   -1	   : error in pattern=  *    0	   : no files foundeO  *   n(>0) : number of matching filenames. (Stored in result_array [0] - [n-1])e  *K  * Wildcard expansion for VMS is easy;	we just use a run-time library call.   */    fgen(pat,resarry,len)r char *pat,**resarry[];	 int *len;t {g5     struct dsc$descriptor_s file_spec, result, deflt;r     long context;_"     int count, slen, status, plen;1     char *pp, *rp, result_string[256], *strchr();*     char *fnp,**fnpp;*  *     file_spec.dsc$w_length  = strlen(pat);,     file_spec.dsc$b_dtype   = DSC$K_DTYPE_T;,     file_spec.dsc$b_class   = DSC$K_CLASS_S;"     file_spec.dsc$a_pointer = pat;  0     result.dsc$w_length	 = sizeof result_string;(     result.dsc$b_dtype	 = DSC$K_DTYPE_T;(     result.dsc$b_class	 = DSC$K_CLASS_S;)     result.dsc$a_pointer = result_string;   2     deflt.dsc$w_length	= sizeof(default_string)-1;&     deflt.dsc$b_dtype	= DSC$K_DTYPE_T;&     deflt.dsc$b_class	= DSC$K_CLASS_S;)     deflt.dsc$a_pointer = default_string;*       count = 0;     context = 0;     pp = strrchr(pat, ']'); &     if ( !pp ) pp = strrchr(pat, ':');     if ( !pp ) plen = 0;     else plen = pp - pat + 1;*     fnpp = *resarry;J     while ((status = LIB$FIND_FILE(&file_spec, &result, &context, &deflt)) 							      == RMS$_NORMAL) { 	if (count >= *len) {b 	    if (*len == 0) *len = 256;i" 	    if (*resarry == (char **)0) {2 		*resarry = (char **)malloc(*len*sizeof(char *));
 	    } else { 5 		*len += *len/2;		/* increase length by 1/2 again *//< 		*resarry = (char **)realloc(*resarry,*len*sizeof(char *)); 	    }" 	    if (*resarry == (char **)0) {, 		perror("Unable to malloc/realloc memory"); 		exit(0x10000004);  	    } 	    fnpp = *resarry + count;a 	}& 	rp = strrchr(result_string, ']') + 1;
 	if( !rp ) 		rp = result_string;e 	slen = strchr(rp, ' ') - rp;_- 	    fnp = *fnpp++ = malloc(slen + plen + 1);  	if (plen != 0)$ 	    strncpy(fnp, pat, plen);1 	strncpy(fnp + plen, rp, slen);) 	fnp[slen + plen] = '\0';n	 	++count;s     }r #ifdef DVI$_ALT_HOST_TYPE >     lib$find_file_end(&context);    /* Only on V4 and later */ #endif&     if (status == RMS$_FNF) return(0);*     if (status == RMS$_NMF) return(count);     return(-1);* }*H **************************End TAIL.C************************************   ------------------------------  % Date: Thu, 05 Oct 2000 09:23:28 +0200l6 From: "Dijk, Jeroen van" <Jeroen.vandijk@getronics.nl>) Subject: Why has Compaq retired DECnet ??eM Message-ID: <2795B75EF003D311801A00A0C906B511A2AE02@cucexec.gbc.getronics.nl>*   Hoff,u  C Could you tell use why Compaq is at this moment retiring DECnet ???l5 What is the last VMS version with DECnet support ????r         -----Original Message-----7 From: Didier Morandi [mailto:Didier.Morandi@Easynet.fr]*# Sent: donderdag 5 oktober 2000 8:36  To: Info-VAX@Mvb.Saic.Com 0 Subject: Re: www.networks.digital.com retired...     Richard Jordan wrote:; >  ../..tE > Now the bad news.  The response I got was that the Digital networksrI > site has been 'retired' and there are no plans to being it back online.*I > This site had the bulk of archived firmware, documentation, and general G > information about DEC network products (Cabletron/Enterasys/DNPG only_E > seem to have the more recent information, and have not responded tot3 > email asking about older products and downloads).u ../..r  G As I wrote here a few days ago, COMPAQ's will is to kill-and-bury (sp?)tE DECnet stuff. ALL DECnet stuff. I am currently teaching a DECnet-PlustG course in Paris. GKN denied the request from the Customer, and the onlylB resource I found to prepare my training has been the DECnet set of} OpenVMS 7.1 documentation (in English, of course :-), still available at http://www.openvms.compaq.com:8000/index.html#decnet=  
 For how long?s  F It seems that it's time to gather this stuff and create a "club" (or a4 company?) for the last DIGITAL DECnet sw engineers..  B I tell you, one day a Customer will ask COMPAQ Cust Services for a; DECnet problem, and the answer will be "migrate to TCP/IP".a   D.   ------------------------------  % Date: Thu, 05 Oct 2000 06:37:32 -0400=0 From: Jim Jennis <jjennis@discovery.fuentez.com>- Subject: Re: Why has Compaq retired DECnet ?? D Message-ID: <3.0.5.32.20001005063732.009f3e10@discovery.fuentez.com>  G Decnet being retired/scrapped??? How are also those nice clustering and ? threading features that depend on DECNET going to be supported?   I IMHO Bad decision....but then Compaq has been famous for these for years.a   Regards,   Jim       ' At 09:23 AM 10/5/2000 +0200, you wrote:( >Hoff, >bD >Could you tell use why Compaq is at this moment retiring DECnet ???6 >What is the last VMS version with DECnet support ???? >f >  >  >1 >-----Original Message----- 8 >From: Didier Morandi [mailto:Didier.Morandi@Easynet.fr]$ >Sent: donderdag 5 oktober 2000 8:36 >To: Info-VAX@Mvb.Saic.Com1 >Subject: Re: www.networks.digital.com retired...k >  >  >Richard Jordan wrote: >> k >../..F >> Now the bad news.  The response I got was that the Digital networksJ >> site has been 'retired' and there are no plans to being it back online.J >> This site had the bulk of archived firmware, documentation, and generalH >> information about DEC network products (Cabletron/Enterasys/DNPG onlyF >> seem to have the more recent information, and have not responded to4 >> email asking about older products and downloads). >../.. >eH >As I wrote here a few days ago, COMPAQ's will is to kill-and-bury (sp?)F >DECnet stuff. ALL DECnet stuff. I am currently teaching a DECnet-PlusH >course in Paris. GKN denied the request from the Customer, and the onlyC >resource I found to prepare my training has been the DECnet set of*I >OpenVMS 7.1 documentation (in English, of course :-), still available atn4 http://www.openvms.compaq.com:8000/index.html#decnet >1 >For how long? >;G >It seems that it's time to gather this stuff and create a "club" (or ar5 >company?) for the last DIGITAL DECnet sw engineers..a >nC >I tell you, one day a Customer will ask COMPAQ Cust Services for ai< >DECnet problem, and the answer will be "migrate to TCP/IP". >  >D.a >k >(8 --------------------------------------------------------7 FSC - Building Better Information Technology Solutions-s7       from the Production Floor to the Customer's Door.f8 --------------------------------------------------------5 Jim Jennis, Technical Director for Commercial SystemsB Fuentez Systems Concepts, Inc. 1 Discovery Place, Suite 2 Martinsburg, WV. 25401 USA_  # Phone: +001 (304) 263-0163 ext. 235  Fax:   +001 (304) 263-0702% Email: jjennis@discovery.fuentez.com 	        jhjennis@shentel.netr& WEB: http://www.discovery.fuentez.com/   ------------------------------  % Date: Thu, 05 Oct 2000 12:06:09 +0100	- From: Tim Llewellyn <tim.llewellyn@bbc.co.uk> - Subject: Re: Why has Compaq retired DECnet ??i) Message-ID: <39DC60A1.ED95DA12@bbc.co.uk>t   Jim Jennis wrote:t  I > Decnet being retired/scrapped??? How are also those nice clustering and=A > threading features that depend on DECNET going to be supported?  > K > IMHO Bad decision....but then Compaq has been famous for these for years.d  F I think Didier's comment is about Compaq dropping TRAINING for DECNET, not the product itself.e   >e >d
 > Regards, >  > Jime >d) > At 09:23 AM 10/5/2000 +0200, you wrote:i > >Hoff, > >kF > >Could you tell use why Compaq is at this moment retiring DECnet ???8 > >What is the last VMS version with DECnet support ???? > >g > >  > >o > >h > >-----Original Message-----o: > >From: Didier Morandi [mailto:Didier.Morandi@Easynet.fr]& > >Sent: donderdag 5 oktober 2000 8:36 > >To: Info-VAX@Mvb.Saic.Com3 > >Subject: Re: www.networks.digital.com retired...  > >o > >  > >Richard Jordan wrote: > >> > >../..H > >> Now the bad news.  The response I got was that the Digital networksL > >> site has been 'retired' and there are no plans to being it back online.L > >> This site had the bulk of archived firmware, documentation, and generalJ > >> information about DEC network products (Cabletron/Enterasys/DNPG onlyH > >> seem to have the more recent information, and have not responded to6 > >> email asking about older products and downloads). > >../.. > >&J > >As I wrote here a few days ago, COMPAQ's will is to kill-and-bury (sp?)H > >DECnet stuff. ALL DECnet stuff. I am currently teaching a DECnet-PlusJ > >course in Paris. GKN denied the request from the Customer, and the onlyE > >resource I found to prepare my training has been the DECnet set of K > >OpenVMS 7.1 documentation (in English, of course :-), still available at(6 > http://www.openvms.compaq.com:8000/index.html#decnet > >e > >For how long? > >iI > >It seems that it's time to gather this stuff and create a "club" (or a*7 > >company?) for the last DIGITAL DECnet sw engineers..m > >iE > >I tell you, one day a Customer will ask COMPAQ Cust Services for aa> > >DECnet problem, and the answer will be "migrate to TCP/IP". > >_ > >D.  > >a > >a: > --------------------------------------------------------9 > FSC - Building Better Information Technology Solutions-*9 >       from the Production Floor to the Customer's Door.u: > --------------------------------------------------------7 > Jim Jennis, Technical Director for Commercial Systemsa  > Fuentez Systems Concepts, Inc. > 1 Discovery Place, Suite 2 > Martinsburg, WV. 25401 > USA  >r% > Phone: +001 (304) 263-0163 ext. 235l > Fax:   +001 (304) 263-0702& > Email: jjennis@discovery.fuentez.com >        jhjennis@shentel.net=( > WEB: http://www.discovery.fuentez.com/   --6 Tim Llewellyn, OpenVMS Infrastructure, Remarcs Project0 MedAS at the BBC, Whiteladies Road, Bristol, UK.A Email tim.llewellyn@bbc.co.uk. Home tim.llewellyn@cableinet.co.uka  A I speak for myself only and my views in no way represent those ofi MedAS or the BBC.i   ------------------------------   Date: 5 Oct 2000 11:19:32 GMTf' From: david20@alpha2.mdx.ac.uk (D.Webb)*- Subject: Re: Why has Compaq retired DECnet ??b0 Message-ID: <8rho44$2n1$1@aquila.news.mdx.ac.uk>   In article <2795B75EF003D311801A00A0C906B511A2AE02@cucexec.gbc.getronics.nl>, "Dijk, Jeroen van" <Jeroen.vandijk@getronics.nl> writes: >Hoff, >iD >Could you tell use why Compaq is at this moment retiring DECnet ???6 >What is the last VMS version with DECnet support ???? >) >    Are they retiring Decnet ?    K Decnet certainly still runs on VMS 7.2-1 both phase IV (Decnet classic) ande Phase V (Decnet/OSI).a  = I would think that killing off DECnet would be a non-starter.t Too many systems would break.r  ' Many peoples programs use Decnet Tasks.   : I believe Digital were planning to retire Decnet Phase IV.7 However lots of people much prefer Phase IV to Phase V.k  D Hence Compaq have ended up having to support two versions of Decnet.L Therefore I could understand them wanting to force all the users to just useL one version (though it is difficult to see how they can do this without justJ dropping support for one which would upset quite a few customers whichever one they chose).M However I don't see that dropping support for Decnet totally would go down ath	 all well.r  - Are you sure this isn't just somebody's FUD ?*    
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------  % Date: Thu, 05 Oct 2000 14:46:49 +0200a6 From: "Dijk, Jeroen van" <Jeroen.vandijk@getronics.nl>- Subject: RE: Why has Compaq retired DECnet ??tM Message-ID: <2795B75EF003D311801A00A0C906B511A2AE07@cucexec.gbc.getronics.nl>    Let me rewrite my question.f   Hoff,   T Could you tell use why Compaq is at this moment downsizing the support on DECnet ???C Like stopping training on DECnet, websites with documentation, enz.   5 What is the last VMS version with DECnet support ????   U What if Compaq stops supporting DECnet, how big will be the impact on the customers? /  = Can DECnet be replaced with TCP/IP or another something else?b   -- Jeroen M.W. van Dijk  Getronics Business Continuity BV8 Error #152 - Windows not found: (C)heer (P)arty (D)ance.   ------------------------------  % Date: Thu, 05 Oct 2000 09:12:56 -0400s, From: Steve Lionel <Steve.Lionel@compaq.com>- Subject: Re: Why has Compaq retired DECnet ??f8 Message-ID: <8fvotsg4livkmnbr6cakhu2irfgjniu7ue@4ax.com>  6 On Thu, 05 Oct 2000 09:23:28 +0200, "Dijk, Jeroen van"$ <Jeroen.vandijk@getronics.nl> wrote:    D >Could you tell use why Compaq is at this moment retiring DECnet ???6 >What is the last VMS version with DECnet support ????  E Compaq has NOT retired DECnet and, to the best of my knowledge, there ' are no plans to remove it from OpenVMS.   @ Also, contrary to Didier's comments, DECnet is still widely usedF within Compaq.  What *IS* going away is routing of the DECnet protocolE between many facilities, but DECnet-over-IP (in DECnet-PLUS) makes up;	 for that.t  - Steve Lionel (mailto:Steve.Lionel@compaq.com)a Fortran Engineeringk& Compaq Computer Corporation, Nashua NH  6 Compaq Fortran web site: http://www.compaq.com/fortran   ------------------------------  % Date: Thu, 05 Oct 2000 17:09:40 +0200o0 From: Didier Morandi <Didier.Morandi@Easynet.fr>- Subject: Re: Why has Compaq retired DECnet ??s* Message-ID: <39DC99B4.D026A8C5@Easynet.fr>   Tim Llewellyn wrote: > H > I think Didier's comment is about Compaq dropping TRAINING for DECNET, > not the product itself.u  G Tim, the info I got from some anonymous source here in Paris is that itoG is the DECnet future that is very compromised because DECnet is (was) axB DIGITAL standard and COMPAQ doesn't want to keep DIGITAL souvenirs running around for ages.  A Do you know that COMPAQ in France has sent to scrap plenty of 21"p@ terminals when they closed a facility because they were labelled !d!i!g!i!t!a!l ?  @ I tried to get one for myself: no way. It's DEC stuff, it has toD disappear. I posted this info in an internal forum when I worked forF COMPAQ last year as a contractor, and I tell you that I heard about myC note... (a few days later, I was not working for COMPAQ anymore :-)    D.   ------------------------------  % Date: Thu, 05 Oct 2000 17:13:23 +0200_0 From: Didier Morandi <Didier.Morandi@Easynet.fr>- Subject: Re: Why has Compaq retired DECnet ??e* Message-ID: <39DC9A93.5F9F9C14@Easynet.fr>   "D.Webb" wrote:a  / > Are you sure this isn't just somebody's FUD ?k  E No. But COMPAQ's contributors to this forum have better be prudent if_8 they don't want to get into trouble with their managers.  F What I know is that all DECnet internal links are turned off one after2 the others, day after day, causing LOT of trouble.   D.   ------------------------------  % Date: Thu, 05 Oct 2000 17:14:42 +0200/0 From: Didier Morandi <Didier.Morandi@Easynet.fr>- Subject: Re: Why has Compaq retired DECnet ?? * Message-ID: <39DC9AE1.7C225447@Easynet.fr>   Steve Lionel wrote:l > B > Also, contrary to Didier's comments, DECnet is still widely usedH > within Compaq.  What *IS* going away is routing of the DECnet protocolG > between many facilities, but DECnet-over-IP (in DECnet-PLUS) makes upu > for that.F   Thanks for the clarification./   D.   ------------------------------  % Date: Thu, 05 Oct 2000 16:59:11 +0100 - From: Tim Llewellyn <tim.llewellyn@bbc.co.uk>*- Subject: Re: Why has Compaq retired DECnet ?? ) Message-ID: <39DCA54F.9D4522A3@bbc.co.uk>b   Didier Morandi wrote:i   > Steve Lionel wrote:  > > D > > Also, contrary to Didier's comments, DECnet is still widely usedJ > > within Compaq.  What *IS* going away is routing of the DECnet protocolI > > between many facilities, but DECnet-over-IP (in DECnet-PLUS) makes up*
 > > for that.s >r  E Does it make up for it? I always liked having redundant WAN protocolsu
 available,I eg if IP was down DECNET would work and vice versa. Especially if you aret5 relying on the network to remotely manage operations.\   >d > Thanks for the clarification.  >r > D.   --6 Tim Llewellyn, OpenVMS Infrastructure, Remarcs Project0 MedAS at the BBC, Whiteladies Road, Bristol, UK.A Email tim.llewellyn@bbc.co.uk. Home tim.llewellyn@cableinet.co.uke  A I speak for myself only and my views in no way represent those of  MedAS or the BBC.a   ------------------------------   Date: 5 Oct 2000 16:04:33 GMTt* From: helbig@astro.rug.nl (Phillip Helbig)- Subject: Re: Why has Compaq retired DECnet ?? . Message-ID: <8ri8qh$qa1$2@info.service.rug.nl>  H In article <3.0.5.32.20001005063732.009f3e10@discovery.fuentez.com>, Jim/ Jennis <jjennis@discovery.fuentez.com> writes: u  I > Decnet being retired/scrapped??? How are also those nice clustering andaA > threading features that depend on DECNET going to be supported?l  : Note that clustering per se has NOTHING TO DO WITH DECNET.   ------------------------------  + Date: Thu, 05 Oct 2000 16:31:00 +0000 (   ) 3 From: Christopher Smith <chriss@Mufasa.pubserv.com>e- Subject: Re: Why has Compaq retired DECnet ??sJ Message-ID: <Pine.LNX.4.05.10010051620100.20660-100000@Mufasa.pubserv.com>  ) On Thu, 5 Oct 2000, Didier Morandi wrote:;  I > Tim, the info I got from some anonymous source here in Paris is that itLI > is the DECnet future that is very compromised because DECnet is (was) ahD > DIGITAL standard and COMPAQ doesn't want to keep DIGITAL souvenirs > running around for ages.  H If that were true, it would be a clear indication that compaq might want6 to scrap VMS and the unix formerly known as digital...  J I hope that compaq is not that stupid -- but then, as has been pointed out6 here, they are a peesee company.  I hope you're wrong.     Chris&  O ===============================================================================>@ "My two cents"			(http://rootworks.com/twocentsworth.cgi?128562)= Christopher Smith(chriss@pubserv.com)			Prgramer^W Programmer) Prime Synergy of Champaign, IL.n% -------------------------------------/I "Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes and H weighs 30 tons, computers in the future may have only 1,000 vacuum tubes; and weigh only 1.5 tons." -- Popular Mechanics, March 1949 tO -------------------------------------------------------------------------------e   ------------------------------  % Date: Thu, 05 Oct 2000 18:01:11 +0100 - From: Tim Llewellyn <tim.llewellyn@bbc.co.uk>p- Subject: Re: Why has Compaq retired DECnet ??s( Message-ID: <39DCB3D7.1FC6F10@bbc.co.uk>   Phillip Helbig wrote:   J > In article <3.0.5.32.20001005063732.009f3e10@discovery.fuentez.com>, Jim0 > Jennis <jjennis@discovery.fuentez.com> writes: > K > > Decnet being retired/scrapped??? How are also those nice clustering and C > > threading features that depend on DECNET going to be supported?- >-< > Note that clustering per se has NOTHING TO DO WITH DECNET.  H However, it did used to (back in VMS 5.x days?) so we'll let Jim off :-) --6 Tim Llewellyn, OpenVMS Infrastructure, Remarcs Project0 MedAS at the BBC, Whiteladies Road, Bristol, UK.A Email tim.llewellyn@bbc.co.uk. Home tim.llewellyn@cableinet.co.uk   A I speak for myself only and my views in no way represent those of  MedAS or the BBC.    ------------------------------  % Date: Thu, 05 Oct 2000 13:15:16 -0400e, From: Steve Lionel <Steve.Lionel@compaq.com>- Subject: Re: Why has Compaq retired DECnet ?? 8 Message-ID: <pkdpts8f29kc0d0f689d29k6vt009ijiic@4ax.com>  2 On Thu, 05 Oct 2000 17:13:23 +0200, Didier Morandi" <Didier.Morandi@Easynet.fr> wrote:   >"D.Webb" wrote: >b0 >> Are you sure this isn't just somebody's FUD ? >rF >No. But COMPAQ's contributors to this forum have better be prudent if9 >they don't want to get into trouble with their managers.r >eG >What I know is that all DECnet internal links are turned off one afterp3 >the others, day after day, causing LOT of trouble.    Didier,o  F You are seriously misrepresenting the situation.  Yes, DECnet protocolD routing is being turned off between facilities, but DECnet itself is- still alive and well on our internal network.e  C As for managers - my manager thinks very highly of my participationMB here.  The only trouble I can see is if some employee continues to0 make false, misleading or derogatory statements.  - Steve Lionel (mailto:Steve.Lionel@compaq.com)o Fortran Engineeringd& Compaq Computer Corporation, Nashua NH  6 Compaq Fortran web site: http://www.compaq.com/fortran   ------------------------------  % Date: Thu, 05 Oct 2000 13:17:21 -0400n, From: Steve Lionel <Steve.Lionel@compaq.com>- Subject: Re: Why has Compaq retired DECnet ??c8 Message-ID: <hpdpts898l4j8miqrq6c8vss91f7s8d5se@4ax.com>  1 On Thu, 05 Oct 2000 16:59:11 +0100, Tim LlewellynE  <tim.llewellyn@bbc.co.uk> wrote:  F >Does it make up for it? I always liked having redundant WAN protocols >available,eJ >eg if IP was down DECNET would work and vice versa. Especially if you are6 >relying on the network to remotely manage operations.  B I have not seen nor heard of any problems in this regard.  In most@ cases around here, IP always works while DECnet can sometimes beC troublesome.  (This was true long before Compaq came on the scene.)t    - Steve Lionel (mailto:Steve.Lionel@compaq.com)  Fortran Engineeringn& Compaq Computer Corporation, Nashua NH  6 Compaq Fortran web site: http://www.compaq.com/fortran   ------------------------------  % Date: Thu, 05 Oct 2000 08:35:59 +0200t0 From: Didier Morandi <Didier.Morandi@Easynet.fr>0 Subject: Re: www.networks.digital.com retired...* Message-ID: <39DC214F.E18525FF@Easynet.fr>   Richard Jordan wrote:t >  ../.. E > Now the bad news.  The response I got was that the Digital networksiI > site has been 'retired' and there are no plans to being it back online.tI > This site had the bulk of archived firmware, documentation, and generaloG > information about DEC network products (Cabletron/Enterasys/DNPG onlywE > seem to have the more recent information, and have not responded to 3 > email asking about older products and downloads).f ../..   G As I wrote here a few days ago, COMPAQ's will is to kill-and-bury (sp?)fE DECnet stuff. ALL DECnet stuff. I am currently teaching a DECnet-PlusgG course in Paris. GKN denied the request from the Customer, and the onlycB resource I found to prepare my training has been the DECnet set of} OpenVMS 7.1 documentation (in English, of course :-), still available at http://www.openvms.compaq.com:8000/index.html#decnetf  
 For how long?A  F It seems that it's time to gather this stuff and create a "club" (or a4 company?) for the last DIGITAL DECnet sw engineers..  B I tell you, one day a Customer will ask COMPAQ Cust Services for a; DECnet problem, and the answer will be "migrate to TCP/IP".    D.   ------------------------------  % Date: Thu, 05 Oct 2000 09:16:23 +0200e6 From: "Dijk, Jeroen van" <Jeroen.vandijk@getronics.nl>0 Subject: RE: www.networks.digital.com retired...M Message-ID: <2795B75EF003D311801A00A0C906B511A2AE01@cucexec.gbc.getronics.nl>   N I can confirm that archives of Digital/Compaq are not longer correct a lot of ( items are pointing to the old webpages. _ Example www.compaq.com is become www8.compaq.com, but in the archive and a lot of other places - is still www.compaq.com used.,  P There is something seriously wrong at Compaq and if they are going on this way, * they will loss a lot of support contracts.S How bigger the customer how higher the chances that they will buy, but not retire. r5 If I look at the situation of the company I work for. D Here we have 20 servers in the range from VAX 3400 until Alpha ES40.       -----Original Message-----8 From: rjordan@mars.mcs.net [mailto:rjordan@mars.mcs.net]# Sent: donderdag 5 oktober 2000 7:06n To: Info-VAX@Mvb.Saic.Com , Subject: www.networks.digital.com retired...    K  As most of you probably know from recent posts, 'www.networks.digital.com'dG went off the air a few weeks ago.  Don't know about anyone else, but ofsA course I _needed_ something from that site so started sending web " feedbacks to Compaq.  Every day.    E Well they surprised me.  For the first time since the takeover, aftere@ numerous complaints about web problems, they actually responded.  C Now the bad news.  The response I got was that the Digital networksaG site has been 'retired' and there are no plans to being it back online.tG This site had the bulk of archived firmware, documentation, and generallE information about DEC network products (Cabletron/Enterasys/DNPG onlyiC seem to have the more recent information, and have not responded tok1 email asking about older products and downloads).   B In addition, any of the remaining "Search DIGITAL.COM" pages (like> the one at www.digital.com/SPD) will now fail, since they usedA cgi that was at the 'search.digital.com' site; that site has beenuC redirected to 'search.compaq.com', but apparently the cgi and otheraC support directories were not moved/ported/whatever.  The response It: got from web feedback on this one was totally nonsensical.  > As an added note; I could still get to pages listing 'archive'= network information links for digital products.  All of thesesA links pointed to networks.digital.com and are now dead.  So the Q > decided to retire a significant site without even bothering toA correct or remove the links on their own site that pointed to it.   E I just wish I could even be surprised by this kind of thing any more.   D I'm done with web feedback.  Hitting the FAQ to find names higher up> the food chain to question on the continuing 'issues' with the& website and DEC product information...   Rich Jordane rjordan@mcs.nets   ------------------------------  % Date: Thu, 05 Oct 2000 09:10:23 -0400-, From: Steve Lionel <Steve.Lionel@compaq.com>0 Subject: Re: www.networks.digital.com retired...8 Message-ID: <bcvotsoneq3ma0eegf1c5gg12e3mpbil8o@4ax.com>  6 On Thu, 05 Oct 2000 09:16:23 +0200, "Dijk, Jeroen van"$ <Jeroen.vandijk@getronics.nl> wrote:  O >I can confirm that archives of Digital/Compaq are not longer correct a lot of i) >items are pointing to the old webpages. .` >Example www.compaq.com is become www8.compaq.com, but in the archive and a lot of other places  >is still www.compaq.com used.  B www8 (or 6 or 5 or some other number) is just one of the redundant= servers.  www.compaq.com always works and should be used when  referencing links.  - Steve Lionel (mailto:Steve.Lionel@compaq.com)0 Fortran Engineeringm& Compaq Computer Corporation, Nashua NH  6 Compaq Fortran web site: http://www.compaq.com/fortran   ------------------------------   Date: 5 Oct 2000 15:47:38 GMT12 From: mathog@seqaxp.bio.caltech.edu (David Mathog)0 Subject: Re: www.networks.digital.com retired..., Message-ID: <8ri7qq$b6f@gap.cco.caltech.edu>  ^ In article <A_TC5.69$w71.4446@news.goodnet.com>, rjordan@mars.mcs.net (Richard Jordan) writes: > D >Now the bad news.  The response I got was that the Digital networksH >site has been 'retired' and there are no plans to being it back online.H >This site had the bulk of archived firmware, documentation, and generalF >information about DEC network products (Cabletron/Enterasys/DNPG onlyD >seem to have the more recent information, and have not responded to2 >email asking about older products and downloads). >q  K This is probably the result of the PC mindset at Compaq.  They figure that eL nobody could possibly still be using equipment that's more than a few years J old, because nothing the PC side of that company makes is still in serviceE at say, five years.  They simply do not understand at the appropriate.D levels that "enterprise" equipment may be in service for much longerF periods, and so they do stupid things like tossing all of the relevant) information into the dumpster (as here).    D Not coincidentally, the service organization has been going down theI tubes ever since they changed the name on it from Digital to Compaq. To atG great extent I suspect that the primary reason this happened is because2K thousands of people who might have used "Digital enterprise service" boughtwC Compaq PCs for their kids and had to return them as unfixable afterhJ struggling futilely with "Compaq service".  Service for the PCs is not theH same as the enterprise service, but if you slap the same name on them itJ confuses the issue, so if one is crap, people rightly think that the other is too.   H Mark my words - the rebadging of all things Digital to Compaq will be inI the textbooks someday as the classic example of why you do NOT replace a tC high quality brand name with a low quality one on the same product.-   Regards,   David Mathog mathog@seqaxp.bio.caltech.edu5? Manager, sequence analysis facility, biology division, Caltech RJ **************************************************************************J *                                RIP VMS                                 *J **************************************************************************   ------------------------------   Date: 5 Oct 2000 16:09:47 GMT * From: helbig@astro.rug.nl (Phillip Helbig)0 Subject: Re: www.networks.digital.com retired.... Message-ID: <8ri94b$qa1$3@info.service.rug.nl>  E In article <bcvotsoneq3ma0eegf1c5gg12e3mpbil8o@4ax.com>, Steve Lioneln" <Steve.Lionel@compaq.com> writes:   D > www8 (or 6 or 5 or some other number) is just one of the redundant? > servers.  www.compaq.com always works and should be used whenS > referencing links.  G Right, but the number shows up in the link displayed and bookmarked by F the browser.   ------------------------------  % Date: Thu, 05 Oct 2000 09:46:42 -0700 + From: "Barry Treahy, Jr." <Treahy@mmaz.com>r0 Subject: Re: www.networks.digital.com retired...( Message-ID: <39DCB072.5BCF000C@mmaz.com>   David Mathog wrote:5  J > Mark my words - the rebadging of all things Digital to Compaq will be inJ > the textbooks someday as the classic example of why you do NOT replace aE > high quality brand name with a low quality one on the same product.e >C  _ Here, here!  I made a very similar post just moments ago.  Digital is dead and it's shame.  The ] roots to the tree of products have long been cut and it is simply a matter of time before thea] remaining life on the tree withers unless Compaq wakes and grafts to another foundation (rootd
 system)...   Regards,   Barryg --  ? Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIOe  A E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028a   ------------------------------  % Date: Thu, 05 Oct 2000 13:12:10 -0400a, From: Steve Lionel <Steve.Lionel@compaq.com>0 Subject: Re: www.networks.digital.com retired...8 Message-ID: <gidpts0e6bg3frtqa0tg5vjaf19gto5mol@4ax.com>  @ On 5 Oct 2000 16:09:47 GMT, helbig@astro.rug.nl (Phillip Helbig) wrote:  F >In article <bcvotsoneq3ma0eegf1c5gg12e3mpbil8o@4ax.com>, Steve Lionel# ><Steve.Lionel@compaq.com> writes: k > E >> www8 (or 6 or 5 or some other number) is just one of the redundant @ >> servers.  www.compaq.com always works and should be used when >> referencing links.t >tH >Right, but the number shows up in the link displayed and bookmarked by 
 >the browser.   E I know - but that doesn't make the www.compaq.com link "wrong", which , was the implication of the original posting.      - Steve Lionel (mailto:Steve.Lionel@compaq.com)t Fortran EngineeringD& Compaq Computer Corporation, Nashua NH  6 Compaq Fortran web site: http://www.compaq.com/fortran   ------------------------------  # Date: Thu, 05 Oct 2000 15:51:24 GMTn From: r_srinivasan@my-deja.com1 Subject: xml library xerces on openvms and deccxxP) Message-ID: <8ri81p$90s$1@nnrp1.deja.com>t   folks,  G has anyone successfully ported the xerces (xml) library to openvms with1C deccxx? I am using 5.6 of cxx on AXP/VMS 7.1 and am not able to getc clean compiles even.  > any and all suggestions including alternate libraries welcome.   thanks in advancei   regards    srinio    & Sent via Deja.com http://www.deja.com/ Before you buy.s   ------------------------------  % Date: Thu, 05 Oct 2000 17:00:37 -0000t- From: wspencer@ap.nospam.org (Warren Spencer),5 Subject: Re: xml library xerces on openvms and deccxx / Message-ID: <stpctlrd7qg60c@news.supernews.com>k  @ r_srinivasan@my-deja.com wrote in <8ri81p$90s$1@nnrp1.deja.com>:   >folks,w > H >has anyone successfully ported the xerces (xml) library to openvms withD >deccxx? I am using 5.6 of cxx on AXP/VMS 7.1 and am not able to get >clean compiles even.O >V? >any and all suggestions including alternate libraries welcome.  >d >thanks in advance >i >regards >b >srini >m >i' >Sent via Deja.com http://www.deja.com/o >Before you buy.   Srini,  G John.L.Ferguson@compaq.com should have some useful comments for you on -L this.  Last I heard, Compaq had assigned some engineers to port the xereces G XML parser to native OpenVMS.  You may wish to contact him for further q1 details, or perhaps he'll pick on on this thread.2   ws   -- 33 << What if there were no hypothetical questions? >>i   ------------------------------   End of INFO-VAX 2000.557 ************************