1 INFO-VAX	Fri, 12 May 2000	Volume 2000 : Issue 264       Contents:
 alpha problem ! Re: Anyone using Decimage Editor?  Re: big Fortran data file  Re: big Fortran data file  Re: big Fortran data file  Re: big Fortran data file  Re: big Fortran data file  Re: big Fortran data file  Re: big Fortran data file  Re: big Fortran data file  Re: big Fortran data file % Booting a Vax 4090 from Infoserver CD  comparative TCP/IP tests Re: comparative TCP/IP tests Re: comparative TCP/IP tests DECserver 90M boot file  Re: DECserver 90M boot file  Re: DS700 question...  Re: DS700 question... - FS: Compaq external DLT drive(15/30GB) ; $350 * FS: DEC TZ877 7-tape DLT Autoloader ; $850/ Re: ftp.decus.org is back up!  And running VMS! % How to share a VMS disk drive with NT ) Re: How to share a VMS disk drive with NT % Re: Is "The GNU on VMS Project" dead?  Re: LMF weirdness  Re: LMF weirdness 
 NEED I.D.?4 Re: Problem with Seagate disk on VAXstation 4000 VLCG SAMBA for VMS - Was Re: Suggest a better file serving solution than NT? / sharing large amounts of data between processes 3 Re: sharing large amounts of data between processes 3 Re: sharing large amounts of data between processes 3 Re: sharing large amounts of data between processes 	 smbclient 
 Re: smbclient / Suggest a better file serving solution than NT? 3 Re: Suggest a better file serving solution than NT? 3 Re: Suggest a better file serving solution than NT? 3 Re: Suggest a better file serving solution than NT? 3 Re: Suggest a better file serving solution than NT? 3 Re: Suggest a better file serving solution than NT? 3 Re: Suggest a better file serving solution than NT? 3 Re: Suggest a better file serving solution than NT?  Re: System Boot Hangs.! Re: Thanks Hoff (re SDL),  but...  Re: the latest billybox virus  Re: the latest billybox virus  threads  Re: threads 0 Urgent PCSI problem while updating DCLTABLES.EXE4 Re: Urgent PCSI problem while updating DCLTABLES.EXE/ Re: What's a fair price for a TZ877 autoloader?  Re: Which VAX to buy? " Re: Wildfire and the future of VMS" Re: Wildfire and the future of VMS" Re: Wildfire and the future of VMS" Re: Wildfire and the future of VMS" Re: Wildfire and the future of VMS  F ----------------------------------------------------------------------  % Date: Fri, 12 May 2000 05:29:39 +0000 , From: Joseph Antony <tonijoe@rediffmail.com> Subject: alpha problem@ Message-ID: <20000512052939.26807.qmail@newmail6.rediffmail.com>  . This is a multi-part message in MIME format...   ------------=_958109379-26806-0  Content-Type: text/plain Content-Disposition: inline         Please find attached the problem   joe             1 _________________________________________________   1 Get Your Free Email At, http://www.rediffmail.com  ------------=_958109379-26806-0 = Content-Type: application/octet-stream; name="alpha_exec.doc" 6 Content-Disposition: inline; filename="alpha_exec.doc"! Content-Transfer-Encoding: base64   < 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAB< AAAAIQAAAAAAAAAAEAAAIwAAAAEAAAD+////AAAAACAAAAD/////////////< ////////////////////////////////////////////////////////////< ////////////////////////////////////////////////////////////< ////////////////////////////////////////////////////////////< ////////////////////////////////////////////////////////////< ////////////////////////////////////////////////////////////< ////////////////////////////////////////////////////////////< ////////////////////////////////////////////////////////////< ////////////////////////////////////////////////////////////< ////////////////////////////////////////////////////////////< ///////////////////////spcEANyAJBAAA8BK/AAAAAAAAEAAAAAAABAAA< AAcAAA4AYmpialUWVRYAAAAAAAAAAAAAAAAAAAAAAAAJBBYAHg4AADd8AAA3< fAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAA< AAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAKgAAAAA< AAAAqAAAAKgAAAAAAAAAqAAAAAAAAACoAAAAAAAAAKgAAAAAAAAAqAAAABQA< AAAAAAAAAAAAANwAAAAAAAAAegEAAAAAAAB6AQAAAAAAAHoBAAAAAAAAegEA< AAwAAACGAQAADAAAANwAAAAAAAAAmQMAALYAAACeAQAAAAAAAJ4BAAAAAAAA< ngEAAAAAAACeAQAAAAAAAJ4BAAAAAAAAngEAAAAAAACeAQAAAAAAAJ4BAAAA< AAAAGAMAAAIAAAAaAwAAAAAAABoDAAAAAAAAGgMAAAAAAAAaAwAAAAAAABoD< AAAAAAAAGgMAACQAAABPBAAAIAIAAG8GAAAaAQAAPgMAABUAAAAAAAAAAAAA< AAAAAAAAAAAAqAAAAAAAAACeAQAAAAAAAAAAAAAAAAAAAAAAAAAAAACeAQAA< AAAAAJ4BAAAAAAAAngEAAAAAAACeAQAAAAAAAD4DAAAAAAAA/gEAAAAAAACo< AAAAAAAAAKgAAAAAAAAAngEAAAAAAAAAAAAAAAAAAJ4BAAAAAAAAUwMAABYA< AAD+AQAAAAAAAP4BAAAAAAAA/gEAAAAAAACeAQAALgAAAKgAAAAAAAAAngEA< AAAAAACoAAAAAAAAAJ4BAAAAAAAAGAMAAAAAAAAAAAAAAAAAAP4BAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAngEAAAAAAAAYAwAAAAAAAP4BAAAaAQAA/gEAAAAAAAAAAAAAAAAAABgD< AAAAAAAAqAAAAAAAAACoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAMAAAAAAACeAQAA< AAAAAJIBAAAMAAAAIHUouHO5vwHcAAAAngAAAHoBAAAAAAAAzAEAACIAAAAY< AwAAAAAAAAAAAAAAAAAAGAMAAAAAAABpAwAAMAAAAJkDAAAAAAAAGAMAAAAA< AACJBwAAAAAAAO4BAAAQAAAAiQcAAAAAAAAYAwAAAAAAAP4BAAAAAAAAvAAA< ABIAAADOAAAADgAAAKgAAAAAAAAAqAAAAAAAAACoAAAAAAAAAKgAAAAAAAAA< AgDZAAAARmVicnVhcnkgMTEsIDIwMDANDUluIHJlcGx5IHRvIHlvdXIgZmF4< LCBJIGhhdmUgc29tZSBvdGhlciBxdWVzdGlvbnMgYW5kIGluZm9ybWF0aW9u< LiBGaXJzdCBvZiBhbGwsIHRoZSBsaW5raW5nIG1ldGhvZG9sb2d5IHRoYXQg< d2FzIHVzZWQgb24gdGhlIEFscGhhIHdhcyByZWNvbW1lbmRlZCBieSBEaWdp< dGFsIGF0IHRoZSB0aW1lIHdlIGRldmVsb3BlZCB0aGlzIHByb2R1Y3QgaW4g< MTk5Mi4gVGhpcyB3YXMgYWJvdXQgdGhlIHRpbWUgdGhlIEFscGhhIG1hY2hp< bmUgd2FzIGZpcnN0IHJlbGVhc2VkIGFuZCB3YXMgcnVubmluZyB2ZXJzaW9u< IDEuNSBvZiBPcGVuVk1TLiBTaW5jZSB0aGVuLCB3ZSBoYXZlIHVwZ3JhZGVk< IHRvIHZlcnNpb24gNy4xIG9mIE9wZW5WTVMgYW5kIHdvbmRlciBpZiB0aGVy< ZSBoYXZlIGJlZW4gYW55IG5ldyBtZXRob2RvbG9naWVzIHRoYXQgd2Ugc2hv< dWxkIHVzZSBmb3IgbGlua2luZy4gSSB3YXNuknQgc3VyZSBmcm9tIHlvdXIg< ZmF4IHdoZXRoZXIgeW91IHdlcmUgZWx1ZGluZyB0byBhbm90aGVyIHdheSBv< ZiBsaW5raW5nIHRoZXNlIGV4ZWN1dGFibGVzIHRvIG1ha2UgaXQgd29yayBs< aWtlIHRoZSBWQVggb3IgdGhhdCB0aGlzIGlzc3VlIGlzIGluaGVyZW50IHRv< IHRoZSBBbHBoYS4gUGxlYXNlIHByb3ZpZGUgYW55IG90aGVyIGluZm9ybWF0< aW9uIHlvdSBtYXkgaGF2ZSBpbiByZWdhcmRzIHRvIHRoZSBsaW5raW5nIG9m< IGV4ZWN1dGFibGVzIG9uIHRoZSBBbHBoYS4NDQ1UaGFuayB5b3UsDQtNYXJu< aWUgR3JlZW4NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAA< BwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAABAAQAABIEAAATBAAA5QYAAOYGAADnBgAA8gYAAAAHAAD9< AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA< AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAcABAAAAAcAAP0AAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQEAAEB< ARwAH7DQLyCw4D0hsAgHIrAIByOQoAUkkKAFJbAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAFAAPAAoAAQBpAA8AAwAAAAAAAAAAADgAAEDx< /wIAOAAMAAYATgBvAHIAbQBhAGwAAAACAAAAGABPSgIAUUoCAF9IAQRtSAkE< c0gJBHRICQQAAAAAAAAAAAAAAAAAAAAAAAA8AEFA8v+hADwADAAWAEQAZQBm< AGEAdQBsAHQAIABQAGEAcgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAAAA< AAAAAAAAAAAAAAADAAAFAAAOAAAGAP////8BAAAABCD//wEAoHqZAAAAAAAA< AAAAAAMAAAAAAAAAAAAAAAASAAAAEwAAAOUCAADmAgAA5wIAAPICAAACAwAA< mAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAA< AAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACA< mAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAAAQAAAAHAAAE< AAAAAAQAAAAHAAAFAAAAAAQAAAAHAAAGAAAAAAAAAD0BAABEAQAAdQEAAHwB< AADzAgAA+QIAAAIDAAAHABwABwAcAAcAHAAHAAAAAADRAQAA/gEAAAUCAAB8< AgAAAgMAAAcABwA6AAcABwAAAAAA/wIAAAIDAAAEAAcA//8GAAAADABNAGEA< cgBpAG4AZQAgAEcAcgBlAGUAbgAWAEMAOgBcAFQARQBNAFAAXABhAGwAcABo< AGEAXwBlAHgAZQBjAC4AZABvAGMADABNAGEAcgBpAG4AZQAgAEcAcgBlAGUA< bgAuAEMAOgBcAFcASQBOAE4AVABcAFAAcgBvAGYAaQBsAGUAcwBcAHcAaQBz< AGUAXABQAGUAcgBzAG8AbgBhAGwAXABhAGwAcABoAGEAXwBlAHgAZQBjAC4A< ZABvAGMADABEAEkATgBLAEEAUgAgAFAAQQBUAEUATAAcAEQAOgBcAHMAaABh< AHIAZQBkAFwAagBvAGUAXABhAGwAcABoAGEAXwBlAHgAZQBjAC4AZABvAGMA< /0ABgAEBJgEAACYBAACgJ9IBIAIBACYBAAAAAAAAJgEAAAAAAAACEAAAAAAA< AAAAAwAAUAAACABAAAD//wEAAAAHAFUAbgBrAG4AbwB3AG4A//8BAAgAAAAA< AAAAAAAAAP//AQAAAAAA//8AAAIA//8AAAAA//8AAAIA//8AAAAAAwAAAEcW< kAEAAAICBgMFBAUCAwSHOgAAAAAAAAAAAAAAAAAA/wAAAAAAAABUAGkAbQBl< AHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYCBQcAAAAA< AAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEAAAILBgQC< AgICAgSHOgAAAAAAAAAAAAAAAAAA/wAAAAAAAABBAHIAaQBhAGwAAAAiAAQA< cQiIGADw0AIAAGgBAAAAAKBKRUagSkVGAAAAAAMABAAAAG8AAAB5AgAAAQAB< AAAABAADEAUAAAAAAAAAAAAAAAEAAQAAAAEAAAAAAAAAJAMA8BAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApQbAB7QAtACA< ADIwAAAAAAAAAAAAAAAAAAAJAwAAAAAAAAcAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAACC< AQAAAAAAMoMRAPAQAN8DAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< //8SAAAAAABGAEMAOgBcAFcASQBOAE4AVABcAFAAcgBvAGYAaQBsAGUAcwBc< AHcAaQBzAGUAXABBAHAAcABsAGkAYwBhAHQAaQBvAG4AIABEAGEAdABhAFwA< TQBpAGMAcgBvAHMAbwBmAHQAXABUAGUAbQBwAGwAYQB0AGUAcwBcAE4ATwBS< AE0AQQBMAC4ARABPAFQAEgBBAHIAZQAgAFkAbwB1ACAAcwB1AHAAcgBpAHMA< ZQBkACAAPwAJAEIAaQByAHQAaABkAGEAeQAgAAgAQgBpAHIAdABoAGQAYQB5< AAAAAwBMAFMASwAMAEQASQBOAEsAQQBSACAAUABBAFQARQBMAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAECgIAAAAAAAAAAAAAAAAAAAAAAAEA< AADghZ/y+U9oEKuRCAArJ7PZMAAAAMgBAAARAAAAAQAAAJAAAAACAAAAmAAA< AAMAAAC0AAAABAAAAMgAAAAFAAAA1AAAAAYAAADoAAAABwAAADQBAAAIAAAA< RAEAAAkAAABcAQAAEgAAAGgBAAAKAAAAhAEAAAwAAACQAQAADQAAAJwBAAAO< AAAAqAEAAA8AAACwAQAAEAAAALgBAAATAAAAwAEAAAIAAADkBAAAHgAAABMA< AABBcmUgWW91IHN1cHJpc2VkID8AAB4AAAAKAAAAQmlydGhkYXkgAHByHgAA< AAQAAABMU0sAHgAAAAkAAABCaXJ0aGRheQAAcHIeAAAAQQAAAFNoYW5rYXIn< cyBCaXJ0aGRheSBmYWxscyBvbiAyNXRoIEp1bHkuICBEb24ndCBGb3JnZXQg< dG8gd2lzaCBoaW0AAC4AHgAAAAcAAABOb3JtYWwAJx4AAAANAAAARElOS0FS< IFBBVEVMAHRoZB4AAAACAAAAMwBOSx4AAAATAAAATWljcm9zb2Z0IFdvcmQg< OS4wAGZAAAAAABgNjwAAAABAAAAAAJQTtXO5vwFAAAAAAJQTtXO5vwEDAAAA< AQAAAAMAAABvAAAAAwAAAHkCAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoCAAAAAAAAAAAAAAAAAAAAAAAB< AAAAAtXN1ZwuGxCTlwgAKyz5rjAAAAAIAQAADAAAAAEAAABoAAAADwAAAHAA< AAAFAAAAiAAAAAYAAACQAAAAEQAAAJgAAAAXAAAAoAAAAAsAAACoAAAAEAAA< ALAAAAATAAAAuAAAABYAAADAAAAADQAAAMgAAAAMAAAA5wAAAAIAAADkBAAA< HgAAABAAAABDSEFNUFMgU09GVFdBUkUAAwAAAAUAAAADAAAAAQAAAAMAAAAJ< AwAAAwAAAKAKCQALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4Q< AAABAAAAEwAAAEFyZSBZb3Ugc3VwcmlzZWQgPwAMEAAAAgAAAB4AAAAGAAAA< VGl0bGUAAwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAA< BwAAAP7///8JAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAA/v///xEAAAAS< AAAAEwAAABQAAAAVAAAAFgAAABcAAAD+////GQAAABoAAAAbAAAAHAAAAB0A< AAAeAAAAHwAAAP7////9////IgAAADUAAAD+////JQAAACYAAAAnAAAAKAAA< ACkAAAAqAAAANAAAACwAAAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAA< JAAAAP7///9AAAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/< AAAAQQAAAEQAAABCAAAAQwAAAP7////+////////////////////////////< ////////////////////////////////////////////////////////////< ////////////////////////////////////////////////////////////< ////////////////////////////////////////////////////////////< ////////////////////////////////////////////////////////////< //////////////////////////////////////////////////9SAG8AbwB0< ACAARQBuAHQAcgB5AAAAAADABAAAAIEICBIAAADgBAAAAIEICN4AAAD4BAAA< AIEICBgAAADYBQAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYA< AAAAAIEIBSIAAAAgdSi4c7m/ATYAAACAGQAAAIEIBTEAVABhAGIAbABlAAAA< AACABgAAAIEIBRgAAABgBwAAAIEIAwIAAAB4BwAAAIAJAgAAAAD/////AIAJ< BAAAAAAOAAIB////////////////AIAJAAAAAAD/////BIEIAAIAAACIBwAA< AIAJAAAAAAD/////CAAAAAAQAACQBwAAVwBvAHIAZABEAG8AYwB1AG0AZQBu< AHQAAAAIACYAAADYBwAAAIEIACYAAAAACAAAAIEIADIAAAAoCAAAAIEIABoA< AgEQAAAA//////////9wCAAAAIEIAAIAAACQCAAAAIEIAAoAAACYCAAAAIEI< CB4AAAAAAAAAABAAAAIAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0A< YQB0AGkAbwBuAAAAAIEIAA4AAADwCAAAAIEIABgAAAAACQAAKAACAQIAAAAE< AAAA/////wIAAADICQAABIEIAAIAAADQCQAAAIAJAAAAAAD/////IoEIABAA< AAAAEAAAAIEIAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBu< AGYAbwByAG0AYQB0AGkAbwBuAAAAAIEIAAoAAAA4AAIB////////////////< AIEIAAIAAADYCgAAAIEIAAoAAADgCgAAAIEICB4AAADwCgAAGAAAAAAQAAAQ< CwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAAD///////////////8AAAAAAAAA< AAAAAAAAAAAAAAAAAICEDrhzub8BIHUouHO5vwFkACAAeAA4ACAAPQBWAEIA< QQAAAGgAZQBuAA0ACgAgACAAIAAgAHgAMQAwACAAPQAgAE0AcwBnAEIAbwB4< ACgAIgBEAGkAZAAgAFkACAABAP//////////CQAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAgIQOuHO5vwEgdSi4c7m/AXQAaABkAGEAeQAgAFQAaABpAHMARABv< AGMAdQBtAGUAbgB0AAAACgBFAG4AZAAgAEkAZgANAAoARQBuAGQAIABTAHUA< YgANAAoADQAaAAIB/////woAAAD/////CgANAAoADQAKAA0ACgANAAoADQAA< AAAAAAAAAAAAAAAAAAAAKwAAAL4ZAAAKAA0AAQAAAAIAAAD+////BAAAAP7/< //8GAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAA< ABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAA< HAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAn< AAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAAMQAAADIA< AAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAA< AD4AAAA/AAAAQAAAAP7///9CAAAAQwAAAEQAAABFAAAARgAAAEcAAABIAAAA< /v///0oAAABLAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAAAFMAAABU< AAAAVQAAAFYAAABXAAAAWAAAAFkAAABaAAAA/v///1wAAAD+/////v///18A< AABgAAAAYQAAAGIAAABjAAAA/v///2UAAAD+////////////////////////< ////////////////////////////////////////////////////////////< //////////////////////////////////////////////////////////8A< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/////wAAAYqwAEF0< dHJpYnV0AGUgVkJfTmFtAGUgPSAiVGhpAHNEb2N1bWVuEHQiDQoKjEJhcwEC< jDFOb3JtYWwCLhlWQ3JlYXRhBGJsAWBGYWxzZQEMllByZWRlY2wSYQAGSWQA< eFRydYENIkV4cG9zZRQcAFRlbXBsYXRlIERlcml2FSRDdcBzdG9taXoEhwNj< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWAQAEAAEAAJYFAADkAAAA< 6gEAAMQFAADSBQAAKhkAAAAAAAABAAAAJIYmhgAA//+jAQAAiAAAALYA//8B< AQAAAAD/////AAAAAP//PAD//wAAj4BvoI8l1BGKBAAIx+nUd4GAb6CPJdQR< igQACMfp1HcAAAAAAAAAAAAAAAAAAAAAAQAAAI6Ab6CPJdQRigQACMfp1HcQ< AAAAAwAAAAUAAAAHAAAA//////////8BAQgAAAD/////eAAAAAiOgG+gjyXU< EYoEAAjH6dR3j4BvoI8l1BGKBAAIx+nUd///AAAAAE1FAAD///////8AAAAA< //8AAAAA//8BAQAAAADfAP//AAAAAP//////////////////////////////< ////////////////////////////////////////////////////////////< ////////////////////////////////////////////////////////////< //////////////////////8oAAAAAgBTIv////8AAAEAUxD/////AAABAFMi< /////wAAAAA2Iv////8AAP//AQEAAAAAAQAoADEATgBvAHIAbQBhAGwALgBU< AGgAaQBzAEQAbwBjAHUAbQBlAG4AdAAJAAAA/////wEBIAMAAAKA/v//////< EAD//ygAAAACAf//AAAAAAAAAAD//////////wAAAAAdAAAAJQAAAP////9I< AAAAAoP+//////8IAP//YAAAAAAA////////AAAAAP//////////AAAAAB0A< DAAlAAAAgqASAv/////+////kAAAAAIA///+////AAAAAP//////////AAAA< AB0ADAAlAAAAQIQcAv//////////DAD//wAAAAAZACNDQIQeAv//////////< DAD//wAAAABPFwAxQIQgAv//////////DAD//wAAAAAeADEAYIQiAv//////< ////CwD//wAAAABTS1RPQIQkAv//////////DAD//wAAAAAgAHIuYIQmAv//< ////////CQD//wAAAADzCAAAQIQoAv//////////DAD//wAAAAAgYnBzQIQq< Av//////////DAD//wAAAABMT0cAYIQsAv//////////AgD//wAAAAAggE5v< YIQuAv//////////BwD//wAAAAAbADIAQIQwAv//////////DAD//wAAAABw< AAAAQIQyAv//////////DAD//wAAAAAggH5kQIQ0Av//////////DAD//wAA< AADkjEkAQIQ2Av//////////DAD//wAAAAAAMgC4YIQ4Av//////////CAD/< /wAAAAAAAAAAQJQ6Av//////////TAD//wAAAAAAAAAADBE8AlgCAAD/////< AAAAAP//////////AAAAAAAAAAD/////AAAAAP///////////////wgACAAA< AJQAAAIAAAwRXAKYAgAA/////wAAAAD//////////wAAAAAAAAAA/////wAA< AAD///////////////8xADEAAACUAAAAAAAMEaYC2AIAAP////8AAAAA////< //////8AAAAAAAAAAP////8AAAAA////////////////FQAVAAAAlAAAAAAA< DBHAAv//////////AAAAAP//////////AAAAAAAAAAD/////AAAAAP//////< /////////0kASQAAAJQAAAAAAP/////gAAAABAAEAAAAAQAAAAAAAAAAABgC< AAD//////////wAAAAD//////////9gCAAD//////////wAAAAD/////////< //////9oAAAAOAAAAAAAAAAAAAAAQAAEAAAAAAD8A/wD////////////////< /////////////wgAAQAwAAAAQq1ROgwAASQAKgBcAFIAZgBmAGYAZgAqADAA< NwAzAGEANQAxAGEAZQAyADMA3wEAAAAAAP////80AAAABgAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAA/soBAJ0AAIAIABoAAAAAAAAAAIAIAA4AAAAgAAAAAIAIABQAAAAwAAAA< AIAIAAgAAABIAAAAAIAIACAAAABQAAAAAIAIACAAAABwAAAAIoEIAAYAAACQ< AAAAAIEIAkIAAACYAAAAAIEIBBoAAADgAAAAAIEIBBIAAAAAAQAAAIEIBCYA< AAAYAQAAAIEIBAoAAABAAQAAAIEIAgIAAABQAQAABIEIAAIAAABYAQAAIoEI< AAYAAABgAQAAAIEIAAQAAABoAQAAAIEIABwAAABwAQAAAIEIABwAAACQAQAA< AIEIACYAAACwAQAAAIEIACYAAADYAQAAAIEIADIAAAAAAgAAAIEIAAoAAAA4< AgAAAIEIAA4AAABIAgAAAIEIAA4AAABYAgAAAIEIABgAAABoAgAAAIEIBEwA< AACAAgAAAIEIBDgAAADQAgAAAIEIBAwAAAAIAwAAAIEICDQAAAAYAwAAAIEI< BAIAAABQAwAAAIEICEwAAABYAwAAAIEIBAIAAACoAwAAAIEIAAIAAACwAwAA< AIEIAAoAAAC4AwAAAIEIBCIAAADIAwAAAIEIAAoAAADwAwAAAIEIBCIAAAAA< BAAAAIEIAAIAAAAoBAAAAIAJAAAAAAD/////AIEYAEQAAAAwBAAAAIAJAAAA< AAD/////AIEIBgoAAAB4BAAAAIEICAwAAACIBAAAAIEICCIAAACYBAAAAIEI< CB4AAADABAAAAIEICBIAAADgBAAAAIEICN4AAAD4BAAAAIEICBgAAADYBQAA< AIEIBgIAAADwBQAAAIEIBBgAAAD4BQAAAIEIBQwAAAAQBgAAAIEIBSIAAAAg< BgAAAIEIBR4AAABIBgAAAIEIBRIAAABoBgAAAIEIBd4AAACABgAAAIEIBRgA< AABgBwAAAIEIAwIAAAB4BwAAAIAJAgAAAAD/////AIAJBAAAAAD/////AIEI< AAIAAACABwAAAIAJAAAAAAD/////BIEIAAIAAACIBwAAAIAJAAAAAAD/////< IoEIAAYAAACQBwAAAIEIABwAAACYBwAAAIEIABwAAAC4BwAAAIEIACYAAADY< BwAAAIEIACYAAAAACAAAAIEIADIAAAAoCAAAAIEIAAoAAABgCAAAAIEIBB4A< AABwCAAAAIEIAAIAAACQCAAAAIEIAAoAAACYCAAAAIEICB4AAACoCAAAAIEI< AAIAAADICAAAAIAJAAAAAAD/////AIEIAAoAAADQCAAAAIEIAA4AAADgCAAA< AIEIAA4AAADwCAAAAIEIABgAAAAACQAAAIEIAKwAAAAYCQAAAIEIAAIAAADI< CQAABIEIAAIAAADQCQAAAIAJAAAAAAD/////IoEIAAYAAADYCQAAAIEIABwA< AADgCQAAAIEIABwAAAAACgAAAIEIACYAAAAgCgAAAIEIACYAAABICgAAAIEI< ADIAAABwCgAAAIEIAAoAAACoCgAAAIEIBB4AAAC4CgAAAIEIAAIAAADYCgAA< AIEIAAoAAADgCgAAAIEICB4AAADwCgAAAIEIAAIAAAAQCwAAAIAJAAAAAAD/< ////AIEIAAoAAAAYCwAAAIEIAA4AAAAoCwAAAIEIAA4AAAA4CwAAAIEIABgA< AABICwAAAIEIBDgAAABgCwAAAIEIAAIAAACYCwAABIEIAAIAAACgCwAAAIAJ< AAAAAAD/////AIAJAAAAAAD/////AIAJAAAAAAD/////AIAJAAAAAAD/////< AIAJAAAAAAD/////AIAJAAAAAAD/////AIAJAAAAAAD/////AIAJAAAAAAD/< ////AIAJAAAAAAD/////AIAJAAAAAAD/////AIAJAAAAAAD/////AIAJAAAA< AAD/////AIAJAAAAAAD/////AIAJAAAAAAD/////AIAJAAAAAAD/////AIAJ< AAAAAAD/////AIAJAAAAAAD/////AIAJAAAAAAD/////AIAJAAAAAAD/////< AIAJAAAAAAD/////AIAJAAAAAAD/////AIAJAAAAAAD/////AIAJAAAAAAD/< ////AIAJAAAAAAD/////AIAJAAAAAAD/////AIAJAAAAAAD/////AIAJAAAA< AAD/////AIAJAAAAAAD/////AIAJAAAAAAD/////AIAJAAAAAAD/////AIAJ< AAAAAAD/////AIAJAAAAAAD/////AIAJAAAAAAD/////AIAJAAAAAAD/////< AIAJAAAAAAD/////AIAJAAAAAAD/////AIAJAAAAAAD/////AIAJAAAAAAD/< ////AIAJAAAAAAD/////AIAJAAAAAAD/////AIAJAAAAAAD/////AIAJAAAA< AAD/////AIAJAAAAAAD/////AIAJAAAAAAD/////AIAJAAAAAAD/////AIAJ< AAAAAAD/////AIAJAAAAAAD/////AIAJAAAAAAD/////AIAJAAAAAAD/////< AIAJAAAAAAD/////AIAJAAAAAAD/////AIAJAAAAAAD/////AIAJAAAAAAD/< /////////wEBsAsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAXwBfAFMAUgBQAF8AMgAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAgH/////< //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAtAAAAAAAAABfAF8AUwBSAFAAXwAzAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAACAQ0AAAAHAAAA////< /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAABCAAAA< AAAAAF8AVgBCAEEAXwBQAFIATwBKAEUAQwBUAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIA////////////////AAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQAAAOEOAAAAAAAAZABp< AHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAgAAgH///////////////8AAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBAAAA8AEAAAAAAAByVYAAAAAAAAAA< gAAAAIAAAAAAAAAAHgAAAAkAAAAAAAAACQAAAAAAAwAwAAAAAAAAAAAAAAAA< AAAAAQABAAAAAQCRBQAAAAAAALkFAAAAAAAA4QUAAAAAAAAJAAAAAQACAGkF< AAAAAAAACAADADQAAAAJBgAAAAAAAGEAAAAAAAEAMQYAAAAAAAD/////////< //////8AAP////////////////////8AAPgAYAAAfwAAAAAAAAAAAAAAAAAA< AAByVYAAAAAAAAAAgAAAAIAAAAAAAAAAEAAAAAkAAAAAAAIA//////////8A< AAAAQAAAAAQAAAAAAAAAbgAAfwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMxhbgAA< AQD/CQQAAAkEAADkBAEAAAAAAAAAAAABAAUAAgAcASoAXABHAHsAMAAwADAA< MgAwADQARQBGAC0AMAAwADAAMAAtADAAMAAwADAALQBDADAAMAAwAC0AMAAw< ADAAMAAwADAAMAAwADAAMAA0ADYAfQAjADQALgAwACMAOQAjAEMAOgBcAFAA< UgBPAEcAUgBBAE0AIABGAEkATABFAFMAXABDAE8ATQBNAE8ATgAgAEYASQBM< AEUAUwBcAE0ASQBDAFIATwBTAE8ARgBUACAAUwBIAEEAUgBFAEQAXABWAEIA< QQBcAFYAQgBBADYAXABWAEIARQA2AC4ARABMAEwAIwBWAGkAcwB1AGEAbAAg< AEIAYQBzAGkAYwAgAEYAbwByACAAQQBwAHAAbABpAGMAYQB0AGkAbwBuAHMA< AAAAAAAAAAAAAAAADAEqAFwARwB7ADAAMAAwADIAMAA5ADAANQAtADAAMAAw< ADAALQAwADAAMAAwAC0AQwAwADAAMAAtADAAMAAwADAAMAAwADAAMAAwADAA< NAA2AH0AIwA4AC4AMQAjADAAIwBjADoAXABQAHIAbwBnAHIAYQBtACAARgBp< AGwAZQBzAFwATQBpAGMAcgBvAHMAbwBmAHQAIABPAGYAZgBpAGMAZQBcAE8A< ZgBmAGkAYwBlAFwATQBTAFcATwBSAEQAOQAuAE8ATABCACMATQBpAGMAcgBv< AHMAbwBmAHQAIABXAG8AcgBkACAAOQAuADAAIABPAGIAagBlAGMAdAAgAEwA< aQBiAHIAYQByAHkAAAAAAAAAAAAAAAAAuAAqAFwARwB7ADAAMAAwADIAMAA0< ADMAMAAtADAAMAAwADAALQAwADAAMAAwAC0AQwAwADAAMAAtADAAMAAwADAA< MAAwADAAMAAwADAANAA2AH0AIwAyAC4AMAAjADAAIwBDADoAXABXAEkATgBE< AE8AVwBTAFwAUwBZAFMAVABFAE0AXABTAFQARABPAEwARQAyAC4AVABMAEIA< IwBPAEwARQAgAEEAdQB0AG8AbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAEgAq< AFwAQwBOAG8AcgBtAGEAbAASACoAXABDAE4AbwByAG0AYQBsAAOz9TkFAAAA< AAAAAAoBKgBcAEcAewAyAEQARgA4AEQAMAA0AEMALQA1AEIARgBBAC0AMQAw< ADEAQgAtAEIARABFADUALQAwADAAQQBBADAAMAA0ADQARABFADUAMgB9ACMA< MgAuADEAIwAwACMAYwA6AFwAUAByAG8AZwByAGEAbQAgAEYAaQBsAGUAcwBc< AE0AaQBjAHIAbwBzAG8AZgB0ACAATwBmAGYAaQBjAGUAXABPAGYAZgBpAGMA< ZQBcAE0AUwBPADkALgBEAEwATAAjAE0AaQBjAHIAbwBzAG8AZgB0ACAATwBm< AGYAaQBjAGUAIAA5AC4AMAAgAE8AYgBqAGUAYwB0ACAATABpAGIAcgBhAHIA< eQAAAAAAAAAAAAAAAAABAAIABAAEAgAABgIBAAgCAAAKAgEAEAL///////8A< AAAA//8AAEKtUToMAP///////////////////////wAA////////////////< //////////////////////////////////////////8BAAAAAAAAAAAAAAAA< AAAAAAAAACSGAQAYAFQAaABpAHMARABvAGMAdQBtAGUAbgB0ABQAMAA3ADMA< YQA1ADEAYQBlADIAMwD//xMCGABUAGgAaQBzAEQAbwBjAHUAbQBlAG4AdAD/< /yaGAAAAAAAAAAIAAAAwGQAA////////AQEgAgAA////////////////////< ////////////////////////////////////////////////////////////< ////////////////////////////////////////////////////////////< ////////////////////////////////////AAIAAP//////////////////< ////////////////////////////////////////////////////////////< ////////////////////////////////////////////////////////////< ////////////////////////////////////////////////////////////< ////////////////////////////////////////////////////////////< ////////////////////////////////////////////////////////////< ////////////////////////////////////////////////////////////< ////////////////////////////////////////////////////////////< ////////////////////////////////////////////////////////////< //+MgG+gjyXUEYoEAAjH6dR3/////wEAAAD/////YAAAAIAAAAAAAGABYQD/< ACQyAAAEBFdvcmS1axAAAwRWQkH34hAABQRXaW4xNsF+EAAFBFdpbjMyB38Q< AAMETWFjs7IQAAQEVkJBNq0jEAAIBFByb2plY3QxChcQAAYEc3Rkb2xlk2AQ< AAcEUHJvamVjdC2uEAAMBFRoaXNEb2N1bWVudDyeEAAJgAAA/wMDAF9FdmFs< dWF0ZRjZEAAGAE5vcm1hbN/YEAAGhAgA/wMDAE9mZmljZRV1EAAIBERvY3Vt< ZW50atMQAAKECAD/AwMAeDG+XxAAAoQIAP8DAwB4Mr9fEAAChAgA/wMDAHgz< wF8QAAKECAD/AwMAeDTBXxAAAoQIAP8DAwB4NcJfEAAChAgA/wMDAHg2w18Q< AAKECAD/AwMAeDfEXxAAAoQIAP8DAwB4OMVfEAADhAgA/wMDAHgxNinrEAAC< hAgA/wMDAHg5xl8QAAOECAD/AwMAeDEwI+sQAAOECAD/AwMAeDExJOsQAAOE< CAD/AwMAeDEyJesQAAOECAD/AwMAeDEzJusQAAOECAD/AwMAeDE0J+sQAAOE< CAD/AwMAeDE1KOsQAAiECAD/AwMAQXV0b09wZW7ZKhAACABEYXRlRGlmZqHq< EAAKAEdldFNldHRpbmcG9RAABABUaW1lq78QAA6AAAD/AwEAQWN0aXZlRG9j< dW1lbnTTXBAABoAAAP8DAQBTaGFwZXP7PBAACIAAAP8DAQBBY3RpdmF0ZZd8< EAAJgAAA/wMBAFNlbGVjdGlvblquEAAHgAAA/wMBAEhvbWVLZXm3mxAABIAA< AP8DAwBVbml0gZ8QAAeAAAD/AwEAd2RTdG9yeeMmEAALgAAA/wMBAENvbW1h< bmRCYXJzChwQAAiAAAD/AwMAQ29udHJvbHPMSxAAB4AAAP8DAQBWaXNpYmxl< ttMQAAeAAAD/AwEAT3B0aW9uc6eTEAAQgAAA/wMBAFNhdmVOb3JtYWxQcm9t< cHTKvBAADoQIAP8DAwBEb2N1bWVudF9DbG9zZTdcEAAJgAAA/wMBAFZCUHJv< amVjdE9oEAAMgAAA/wMDAFZCQ29tcG9uZW50cwonEAAEAEl0ZW3XehAADoAA< AP8DAQBOb3JtYWxUZW1wbGF0ZXGsEAAKgAAA/wMDAENvZGVNb2R1bGXhHBAA< BIAAAP8DAQBGaW5kbvAQABKAAAD/AwEAQ29uZmlybUNvbnZlcnNpb25zE7QQ< AA+AAAD/AwEAVmlydXNQcm90ZWN0aW9ub0QQAAMATm93JboQAAMARGF5pIIQ< AAUATW9udGibBBAAC4AAAP8DAQBBcHBsaWNhdGlvbqUqEAAHgAAA/wMBAENh< cHRpb24QeBAABgBNc2dCb3iXUhAABwB2Ylllc05vHZ0QAAUAdmJZZXNhPxAA< BgB2YkNyTGavrBAACgB2YkNyaXRpY2FsK30QAAWAAAD/AwMATGluZXO6zhAA< DIAAAP8DAwBDb3VudE9mTGluZXMhXBAACoAAAP8DAQBTYXZlRm9ybWF064gQ< ABCAAAD/AwEAd2RGb3JtYXREb2N1bWVudIS4EAAQgAAA/wMBAHdkRm9ybWF0< VGVtcGxhdGUCZRAABYAAAP8DAQBTYXZlZGTJEAALgAAA/wMDAERlbGV0ZUxp< bmVzDIMQAA2AAAD/AwMAQWRkRnJvbVN0cmluZ5SOEAAHgAAA/wMBAERpYWxv< Z3OKyhAAF4AAAP8DAQB3ZERpYWxvZ0ZpbGVTdW1tYXJ5SW5mb6a6EAAFgAAA< /wMDAFRpdGxl8n4QAAeAAAD/AwEAU3ViamVjdFJQEAAGgAAA/wMBAEF1dGhv< cvyPEAAIgAAA/wMBAENhdGVnb3J5tFwQAAiAAAD/AwMAS2V5d29yZHMEVBAA< CIAAAP8DAQBDb21tZW50c8MpEAAHgAAA/wMBAEV4ZWN1dGVZzRAABIAAAP8D< AQBTYXZlktAQAAyECAD/AwMARG9jdW1lbnRfTmV3O0UQAASAAAD/AwEARm9u< dFUQEAAEgAAA/wMBAFNpemXu+xAACoAAAP8DAQBDb2xvckluZGV40+MQAAeA< AAD/AwEAd2RHcmVlbmKNEAAJgAAA/wMBAEFuaW1hdGlvbpvnEAAWgAAA/wMB< AHdkQW5pbWF0aW9uU3BhcmtsZVRleHTYshAAC4AAAP8DAQBJbnNlcnRBZnRl< cnE1EAAIgAAA/wMBAE1vdmVEb3duzJ0QAAiAAAD/AwEAd2RTY3JlZW6xHRAA< BQBDb3VudDB2EAAGgAAA/wMBAHdkQXV0b0tWEAAPgAAA/wMBAHdkQW5pbWF0< aW9uTm9uZXowEAANhAgA/wMDAERvY3VtZW50X09wZW7BiRAAAv//AQFUAAAA< ////////FgIDAP//GAIEAP//////////AAIBAP//AgIAAP//////////////< ////////////////////////////DgICAP//EAL/////EwIAAA0ADQAOAAAA< AQASAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAHssYABAAQAAAABADAqAgKQCQBwFAZIAwCCAgBk5AQEAAcA< HABQcm9qZWN0BVEAKAAAQAIUBgIUPa0CCgcCbAEUCAYSCQISgEKtUToMAAwC< ShI8AgoWAAFyc3RkEG9sZT4CGXMAdAAAZABvAGwAZVAADQBmACVcAAMqAFxH< ezAwMDIwsDQzMC0ACAQEQwAKAwIOARIwMDQ2fSMAMi4wIzAjQzoAXFdJTkRP< V1MAXFNZU1RFTVwAU1RET0xFMi4QVExCIwAIIEF1AHRvbWF0aW9uBwBeAAKD< RE5vcm1hCmyDRE6AQnIAbQCiYYBFDgAggBEJgAEYKlxDAxIKBgOz9Qg5BQCD< IU9mZmkKY4RmT4BgZgBpACpjgmaPgB+FgiFHewAyREY4RDA0QwAtNUJGQS0x< MIAxQi1CREU1gGZUQUGAZDSABTKFZmMEOlyAuWdyYW0gAEZpbGVzXE1pAGNy< b3NvZnQgBQM2XAQDTVNPOS4QRExMIw0QIDkuEDAgT2IB2yBMaWBicmFyeYBD< AAEPEYLsAQATwgEkhhkBAmFUaGlzRG9jAHVtZW50RwAYEcAJVABogDFzAEQR< AEVjAHWARWUAblWAahrOCzLaCxzAEgAUAEhCATEChTAZACwAHkICAQUswiEm< hioiQggrQgEQQgEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ< AAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAASQAAAF8EAAAAAAAAXwBfAFMAUgBQAF8AMQAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAgALAAAA< CAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABb< AAAAYgAAAAAAAABQAFIATwBKAEUAQwBUAHcAbQAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAACAP//////////////< /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF0AAAApAAAA< AAAAAFAAUgBPAEoARQBDAFQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAIBBgAAAA4AAAD/////AAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXgAAAG0BAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAByVYAAAACAAAAAgAAAAIAAAAAB< AAB+fQAAfwAAAAAKAAAACQAAAAAAAAD///////////////8AAAAA/////wMA< AAkBAwAAAAAAAAkGAAAAAAAACAAAAAAAAQBwAAB/AAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAFRoaXNEb2N1bWVudABUAGgAaQBzAEQAbwBj< AHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABJRD0ie0Ew< NkY4MDkwLTI1OEYtMTFENC04QTA0LTAwMDhDN0U5RDQ3N30iDQpEb2N1bWVu< dD1UaGlzRG9jdW1lbnQvJkgwMDAwMDAwMA0KTmFtZT0iUHJvamVjdCINCkhl< bHBDb250ZXh0SUQ9IjAiDQpWZXJzaW9uQ29tcGF0aWJsZTMyPSIzOTMyMjIw< MDAiDQpDTUc9IjFDMUVCMEQ2RDBGNkQ0RjZENEY2RDRGNkQ0Ig0KRFBCPSIz< ODNBOTRFNzk1RTc5NUU3Ig0KR0M9IjU0NTZGODFFMDgzQjA5M0IwOUM0Ig0K< DQpbSG9zdCBFeHRlbmRlciBJbmZvXQ0KJkgwMDAwMDAwMT17MzgzMkQ2NDAt< Q0Y5MC0xMUNGLThFNDMtMDBBMEM5MTEwMDVBfTtWQkU7JkgwMDAwMDAwMA0K< DQpbV29ya3NwYWNlXQ0KVGhpc0RvY3VtZW50PTAsIDAsIDAsIDAsIEMNCgAA< AAAAAAAAAAAAAAAAAAAAAAABAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABG< GAAAAE1pY3Jvc29mdCBXb3JkIERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAA< AFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgEBAAAAEQAAAP////8AAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABkAAAAagAAAAAAAABPAGIA< agBlAGMAdABQAG8AbwBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAFgABAP///////////////wAAAAAAAAAAAAAAAAAA< AAAAAAAAIHUouHO5vwEgdSi4c7m/AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA< AAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAA=  ! ------------=_958109379-26806-0--G   ------------------------------  # Date: Thu, 11 May 2000 20:56:21 GMT / From: Hans.Bachner@altavista.net (Hans Bachner)A* Subject: Re: Anyone using Decimage Editor?+ Message-ID: <391b1df9.10141372@news.aon.at>A  8 cvwd@my-deja.com wrote on Tue, 09 May 2000 22:48:31 GMT:  D >Is anyone using Decimage Editor, or know where I can optain a copy?F >I need to take .GIF and .JPG Images and convert them to .DDIF so thatE >I can display them using the CDA Viewer on my VAX and Alpha Systems.A  N If it's just about displying the images, you could use Netscape Navigator PlusN (current version V3.03b, soon to be followed by Mozilla/Netscape V6) or XV (on8 the Freeware CD). Or do you need DDIF for other reasons?    : ---------------- speaking only for myself ---------------- Hans Bachner Compaq Computer AustriaA+ Compaq Customer Services - Software SupportI E-Mail: Hans.Bachner@compaq.comI   ------------------------------   Date: 11 May 2000 18:34:41 GMT* From: helbig@astro.rug.nl (Phillip Helbig)" Subject: Re: big Fortran data file. Message-ID: <8feug1$69l$1@info.service.rug.nl>  ? In article <8feigf$2b5$1@news.enteract.com>, "Dale A. Dellutri"I  <ddellutr@enteract.com> writes:   G >It's hard to make any useful comments without more details.  There areAF >many approaches, including even the use of global sections, depending9 >on exactly what is being done here.  So, some questions:/ >/7 >1. How often will you re-compute the data?  Just once,A" >forever?  Once a week? day? hour?  H Just once.  Perhaps add some more in the future if a finer grid is more C accurate than interpolation (which I doubt, as it's pretty smooth).A  > >2. How often will you run the application that uses the data?  I Say, 30--40 times in the next couple of years.  Each run is several days I of CPU time.  A >3. What proportion of the data will it use when it runs?  All of ! >it?  Half?  A tiny amount (<5%)?A  C Difficult to say.  Maybe 30%.  The first 4 variables have all their/D values used.  The fifth one is (in a greatly simplified explanation)F essentially automatically chosen by an integration routine.  (Three ofF these values must be calculated every time the integrand is evaluated,H and it's 4 or 5 integrals nested, so we're talking tight inner loop hereD and probably many values are calculated more than once---even if not; though, it still might be worth it to pre-calculate them.) J  G >4. If it uses just a small part of the data, will subsequent runs tend/5 >the use data in the same area?  In a different area?J   Difficult to say (see above).J   ------------------------------   Date: 11 May 2000 18:43:00 GMT* From: helbig@astro.rug.nl (Phillip Helbig)" Subject: Re: big Fortran data file. Message-ID: <8feuvk$69l$2@info.service.rug.nl>  F In article <11MAY200011515614@gerg.tamu.edu>, carl@gerg.tamu.edu (Carl Perkins) writes: A   >helbig@astro.rug.nl writes...H >}In article <11MAY200008520469@gerg.tamu.edu>, carl@gerg.tamu.edu (Carl >}Perkins) writes: A >} AI >}>Additional speed improvements could be gotten by storing more than oneAE >}>value per record and using a subroutine to get the value you want A >} AK >}Actually, the first four variables are stepped through sequentially, and AG >}the fifth variable is used in a more-or-less random order.  Thus, it   >AE >The "random order" is a problem, then. This would be an argument forAE >breaking it into two files, one sequential access for the 4 that areAD >always used sequentially, and one direct access file for the other.  H I wasn't clear here.  f = f(v,w,x,y,z).  Thus, a five-dimensional array F with dimensions of (200,100,10,60,A) where A varies between 1 and 599.E (Thus, the array is half-full since the average value of A is 300).  AD Thus, each value depends on all 5 variables, but the first four are ( stepped through in order in the program.  I >}would make sense to put all of these values (between 1 and 599) in one A >AD >Do you mean that the randomly used value only has up to 599 cases?    Yes.   >IfAF >so, then reading it in all at once into an array with 599 elements is >the way to go.A   Right.  K >}record.  Once this record is in memory, the computation time is probably AH >}comparable to the time to read the next record so I/O won't be a real 
 >}bottleneck.A > H >I thought the idea was to get it to go *faster* than computing it every >time? A  I I meant the computation time by the program which uses these values, not A+ computation time for the values themselves.A  D >It's a "standard" VAX extension from the F77 era. Since most modernG >F77 (and probably F90 - I don't know about F95) compilers support mostAC >of the VAX extensions, it is probably a common thing. It's hard toAC >say if any given implementation would have it. I was assuming thisAD >would run under OpenVMS (what with this being comp.os.vms and all),H >and both the old VAX F77 and newer Alpha F90 compilers have it (I don't? >have F95 to check it, but it certainly has something similar).A  H I work on VMS, but a) other folks might want to run this and b) I might B have to use some other machines to get all the stuff done in time.  I >Two reasons, really. First: Less overhead in the I/O. It obviously takesAI >less processing to read fixed length records than it is to read variableAL >length records. (Not much, I'm sure - just using the first two bytes of theH >record to determine how much of the chunk of data read from the disk isI >part of the needed record instead of always using the same value. RMS is/J >also rather heavily optimised so it shouldn't be noticable unless you areI >reading a *lot* of records, which you are.) Second: It also uses 2 bytesAK >less disk space per record than a variable record length file. If you wereAM >using 4 byte data, one data element per record, then the 2 bytes of variableAH >length data per record would increase the size of the file by 50%. MoreL >sensibly for the above data, even at 16 bytes per record it is 12.5% extra.H >Since the data is naturally going to end up in uniform chunks, it makesL >sense to store it the same way - there is no variation in the record length: >so you don't need to store it as variable length records.  H The value of A above is 10 times the value of z, which ranges from 1 to H 60.  Thus, at the fourth level, the record length would increase from 1 + to 599 four-byte units for each value of z.g   ------------------------------    Date: 11 May 2000 21:28:20 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>B" Subject: Re: big Fortran data fileH Message-ID: <y4n1lwdgyz.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  $ Earl Lakia <lakia@ipact.com> writes:  ; > I would opt for a program that would map a global sectionw> > with a backing RMS file.  Calculate all your number into theD > global section and update the section to the file.  All subsequent; > users could then create & map the global section with theQB > RMS backing file.  With the introduction of the address variable7 > in FORTRAN and C, mapping the global section is easy.w  H Yes, that's the way to go - presuming you're using VMS with a version >6N (I think V7 introduced the new page table setup that obviates VIRTUALPAGECNT).L Also, have a look at the asynchronous paging capabilities introduced in V7.2J (IIRC) - that's the only thing that otherwise is missing from the VM-based, approach compared to doing the I/O yourself.   	Jan   ------------------------------   Date: 11 May 2000 19:52:37 GMT* From: helbig@astro.rug.nl (Phillip Helbig)" Subject: Re: big Fortran data file. Message-ID: <8ff325$7od$1@info.service.rug.nl>  H In article <y4n1lwdgyz.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>,A Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>A writes:   D Most followups have commented on various Fortran solutions, with or > without VMS-specific extensions, or using global sections etc.  F One thing I hadn't thought through was the fact that the array is onlyH half full, since the range of the last index depends on the value of theF previous one.  Thus, I could halve the space by using the indices as a3 record number or whatever and using direct access. /  D What about just doing it straightforwardly and let the fact that theA whole file won't fit into memory be handled by the Virtual Memory/I System?  Would folks expect this to be more or less efficient than doing /I things by hand?  I guess a disadvantage is that more disk space would be /8 needed since the page file would have to be quite large.   ------------------------------   Date: 11 May 2000 20:39:21 GMT0 From: "Dale A. Dellutri" <ddellutr@enteract.com>" Subject: Re: big Fortran data file- Message-ID: <8ff5pp$10qg$1@news.enteract.com>/  , On 11 May 2000 19:52:37 GMT, in comp.os.vms,,  Phillip Helbig <helbig@astro.rug.nl> wrote:  E Phil, I've gathered together below your notes and answers in a numberXA of different posts in this thread.  My comments are interspersed.h  6 Phil Helbig wrote in a number of posts in this thread:H >We're talking about 1.5 GB or so of data, i.e. 360 million values to be
 >computed.  > (*)Further on, you say that the first four variables have 200,? 100, 10 and 60 values respectively.  That's 12 million values. /? Then you say that the fifth variable has between 1 and 599 with5? 300 as an average.  That's 3600 million values, not 360 millionQA values, or about 15GB.  Do you have a large enough disk?  Or willA you be forced to go to tape?  J >Actually, the first four variables are stepped through sequentially, and F >the fifth variable is used in a more-or-less random order.  Thus, it H >would make sense to put all of these values (between 1 and 599) in one J >record.  Once this record is in memory, the computation time is probably G >comparable to the time to read the next record so I/O won't be a real W >bottleneck.  > So you already know that I/O time won't be a bottleneck.  ThisA probably means that using a disk-file-backed global section won'tU4 help either, and will make the program VMS-specific.  8 >>1. How often will you re-compute the data?  Just once,# >>forever?  Once a week? day? hour?3I >Just once.  Perhaps add some more in the future if a finer grid is more ED >accurate than interpolation (which I doubt, as it's pretty smooth).? >>2. How often will you run the application that uses the data?DJ >Say, 30--40 times in the next couple of years.  Each run is several days 
 >of CPU time.A  ? So I/O really won't matter.  So keep the file simple.  And readA it sequentially.  H >The application uses the values in a certain order and I can precomputeF >them in this order.  Should I make one large file and let the virtualG >memory system take care of the fact that it won't all fit into memory,AI >keeping in mind that the values are accessed in the order they are used,RG >or should I split it up into smaller files?  Should I used a formatted G >or unformatted file?  (Four places are enough precision, so the sizes H2 >would be about the same.)  Indexed or sequential?  < I'd keep it in one large file (not one large array), but I'dC write it out and read it in one record at a time.  Thus there would2' be no memory (virtual or real) problem.W  @ Use unformatted _data_ if you are going to use portable floating< point (IEEE) format. Unformatted FORTRAN reads and write areA faster than formatted and avoid possible rounding errors on inputS? and output. Or did you mean an "unformatted" file format; i.e.,A@ fixed 512 byte records.  I wouldn't do this unless I knew that I= had to share this file with a non-Compaq FORTRAN program on a3@ non-VMS system.  I'd just use a standard FORTRAN variable-length record format.  > I don't see how indexed will be of any use since you will read every record in order.  H > One thing I hadn't thought through was the fact that the array is onlyJ > half full, since the range of the last index depends on the value of theH > previous one.  Thus, I could halve the space by using the indices as a5 > record number or whatever and using direct access. H  F Since you are going to use all the values of the first four variables,C you will read all the records.  Sequential access is best since youA> will use them in a "predefined order" (as you said elsewhere).8 Neither indexed nor direct acces will give you any help.  F > What about just doing it straightforwardly and let the fact that theC > whole file won't fit into memory be handled by the Virtual MemoryAK > System?  Would folks expect this to be more or less efficient than doing AK > things by hand?  I guess a disadvantage is that more disk space would be A: > needed since the page file would have to be quite large.  F Yes, a straightforward sequential "read one record at a time" is best.F The whole file doesn't have to fit in memory.  You said elsewhere (see> below) that the first four are stepped through in order in theE program.  Once you have the results of the function, you use them oneAB at a time, right?  And you only need to keep one at a time, right?  I >I wasn't clear here.  f = f(v,w,x,y,z).  Thus, a five-dimensional array AG >with dimensions of (200,100,10,60,A) where A varies between 1 and 599.AF >(Thus, the array is half-full since the average value of A is 300).  E >Thus, each value depends on all 5 variables, but the first four are A) >stepped through in order in the program.A   See (*) comments above.A  C So if I understood all this, I can finally respond to this comment:A  F >This is with Compaq Fortran 95 on ALPHA/VMS.  At the moment, I have aD >choice between a 255/233 with 64 MB or a 3000/600 with 192 MB.  I'mF >assuming the processor speed, not the memory size, will determine theG >speed if things are set up correctly with regard to the large file (orAF >many smaller files, as the case might be).  The application otherwise? >needs very little memory and does very little I/O, just numberA >crunching.   @ Yes.  Go with the faster processor.  You _definitely_ have a CPU> speed bottleneck.  You may also have a disk space problem, but@ that's another matter.  But even if you're forced to go to tape,B you _still_ don't have an I/O bottleneck.  Or a memory bottleneck.  @ And just out of curiosity, is this a cool astronomy application?= I'm an amateur astronomer.  Will I eventually read about thisA in Astronomy or Sky & Tel?   -- A& Dale Dellutri -- ddellutr@enteract.com   ------------------------------    Date: 11 May 2000 13:36:38 -07000 From: Richard Maine <maine@altair.dfrc.nasa.gov>" Subject: Re: big Fortran data file1 Message-ID: <ue8zxgn7s9.fsf@altair.dfrc.nasa.gov>A  , helbig@astro.rug.nl (Phillip Helbig) writes:  F > What about just doing it straightforwardly and let the fact that theC > whole file won't fit into memory be handled by the Virtual Memory0K > System?  Would folks expect this to be more or less efficient than doing CK > things by hand?  I guess a disadvantage is that more disk space would be D: > needed since the page file would have to be quite large.  C Virtual memory paging is usually more efficient than you are likelylA to manage with traditional file I/O.  Of course, in both cases, aD@ bit of thought on organization can do wonders.  For example, you< don't want to end up having to pull in tiny parts of lots of0 different "pages" instead of big parts of a few.  @ The main reason I posted, however, is to suggest that you may beB thinking in older standards of size.  These things change over theA years.  I notice you talking about files of hundreds of megabytesAD ad being "quite large".  In the paragraph quoted above, for example,C you seem to be worrying about the amount of disk space required forAA a program of a few hundred megabytes.  A few hundred megabytes isA; about 1% of what is today a quite modest-sized disk (18gb).A  A Indeed a few hundred megabytes is only a modest amount of memory.   = Perhaps the application might be anticipated to grow over theA= next few years.  Such things happen.  But I'd say that if youAC are spending a lot of time worrying about disk paging for somethingAC of only a fgew hundred megabytes, you are designing for yesterday'sAB systems instead of today's.  Sometimes one has to do this, as whenB you have to work with old existing equipment or for other reasons.@ But sometimes its just because you are slow to mentally adapt to@ current environments - I've certainly been caught on such thingsA on occasion myself - things change fast enough to make it an easyn trap to fall into.  B So perhaps it doesn't apply to you.  But at least take a moment toE consider whether just getting more memory might obviate some (clearly3C not all) of the issues you are concerned about.  At current prices,n? memory tends to be cheaper than program development - certainlyo1 in "small" quantities like hundreds of megabytes.i  D Afraid I don't know anything worth pasisng along about the technicalA details of how to do you sharing under VMS.  I'll leave that part3G of the questions to others.  There seems to be lively enough discussion) of it.   -- d
 Richard Maine  maine@altair.dfrc.nasa.gov   ------------------------------   Date: 11 May 2000 21:48:00 GMT* From: helbig@astro.rug.nl (Phillip Helbig)" Subject: Re: big Fortran data file. Message-ID: <8ff9qg$9up$1@info.service.rug.nl>  @ In article <8ff5pp$10qg$1@news.enteract.com>, "Dale A. Dellutri"  <ddellutr@enteract.com> writes:   - >On 11 May 2000 19:52:37 GMT, in comp.os.vms,r- > Phillip Helbig <helbig@astro.rug.nl> wrote:n >aF >Phil, I've gathered together below your notes and answers in a numberB >of different posts in this thread.  My comments are interspersed. >n7 >Phil Helbig wrote in a number of posts in this thread:dI >>We're talking about 1.5 GB or so of data, i.e. 360 million values to be1 >>computed.i >y? >(*)Further on, you say that the first four variables have 200,?@ >100, 10 and 60 values respectively.  That's 12 million values. @ >Then you say that the fifth variable has between 1 and 599 with@ >300 as an average.  That's 3600 million values, not 360 millionB >values, or about 15GB.  Do you have a large enough disk?  Or will >you be forced to go to tape?   H I'm limiting myself to 1/10 the total for the time being.  :-)  The ten = in the third variable don't have to be used at the same time.   A >And just out of curiosity, is this a cool astronomy application?    Yes.  > >I'm an amateur astronomer.  Will I eventually read about this >in Astronomy or Sky & Tel?r   Maybe.  C A final comment.  For the time being, it is true that the stuff is vH essentiallyb being read sequentially.  In the longer term, I might want . it all, at least virtually, in memory at once.   ------------------------------   Date: 11 May 2000 21:50:49 GMT* From: helbig@astro.rug.nl (Phillip Helbig)" Subject: Re: big Fortran data file. Message-ID: <8ff9vp$9up$2@info.service.rug.nl>  ? In article <ue8zxgn7s9.fsf@altair.dfrc.nasa.gov>, Richard Maine-% <maine@altair.dfrc.nasa.gov> writes: 1  A >The main reason I posted, however, is to suggest that you may beuC >thinking in older standards of size.  These things change over theiB >years.  I notice you talking about files of hundreds of megabytesE >ad being "quite large".  In the paragraph quoted above, for example, D >you seem to be worrying about the amount of disk space required forB >a program of a few hundred megabytes.  A few hundred megabytes is< >about 1% of what is today a quite modest-sized disk (18gb).  D It's not the disk space so much as the time to read it just to do a  simple test or whatever.  B >Indeed a few hundred megabytes is only a modest amount of memory.  0 I have a modest machine (64 MB) on my desk.  :-|  > >Perhaps the application might be anticipated to grow over the >next few years.     Definitely.e   ------------------------------  % Date: Thu, 11 May 2000 20:26:17 -0500 , From: "Glenn C. Everhart" <Everhart@GCE.com>" Subject: Re: big Fortran data file' Message-ID: <391B1768.565A27DC@GCE.com>(   Try hashing...   Earl Lakia wrote:  > ; > I would opt for a program that would map a global section > > with a backing RMS file.  Calculate all your number into theD > global section and update the section to the file.  All subsequent; > users could then create & map the global section with the9B > RMS backing file.  With the introduction of the address variable7 > in FORTRAN and C, mapping the global section is easy.  > C > I have small C program routine that maps a global section using a.A > RMS backing page file.  To create the file, use the  Create/fdli > something like the following:  > C > IDENT   "27-JAN-1999 13:11:52   OpenVMS ANALYZE/RMS_FILE Utility"  >  > SYSTEM) >         SOURCE                  OpenVMSp >  > FILE% >         ALLOCATION              275 % >         BEST_TRY_CONTIGUOUS     yesl# >         CLUSTER_SIZE            9v$ >         CONTIGUOUS              no# >         EXTENSION               0n$ >         FILE_MONITORING         no# >         GLOBAL_BUFFER_COUNT     0sB >         NAME                    "bf_regions:iastatus_Region.pag", >         ORGANIZATION            sequential' >         OWNER                   [1,1]wQ >         PROTECTION              (system:RWED, owner:RWED, group:RE, world:RWED)l >  > RECORD% >         BLOCK_SPAN              yesn1 >         CARRIAGE_CONTROL        carriage_returne' >         FORMAT                  fixed % >         SIZE                    512b > Q > /******************************************************************************r >  File Name : MAP_IMAGE.C >  Author    : M. Huttingeru > J >  Purpose   : Opens an RMS file and maps it into the user's address space >  >  Revision History: > ? >     10-JUL-96   M. Huttinger    Ported over from IQR Softwareo > 
 >  Arguments:  >  >     name:   filename >     type:   descriptor >     access: by reference > % >     Name of RMS file that is mapped  >  >     name:   regionname >     type:   descriptor >     access: by reference >  >     Name of the region to map: >  >     name:   va >     type:   longword array >     access: by reference > G >     Pointer to the start of an eight longword array. Will contain thehE >     virtual address start/end, FAB and RAB start and end addresses.  >  >     name:   access >     type:   longword >     access: by value > 7 >     Access for mapping mode: 0=readonly, 1=read/writei >  >     name:   system >     type:   longword >     access: by value > A >     System or group global section selection: 0=group, 1=systemr >  >  Abstract: > D > This routine opens an RMS file and maps it into the user's address > space. > Q > *******************************************************************************90 > * Header files, externals, macros, definitionsQ > ******************************************************************************/j > #include <descrip.h> > #include <rms> > #include <starlet> > #include <secdef>  > #include <stdio> >  > struct mapping_array > {r6 >   int region_va[2];     /* where region is mapped */0 >   int fabrab_va[2];     /* fab and rab v.a. */ > }; > Q > /******************************************************************************c > * Global variablesQ > ******************************************************************************/i > Q > /******************************************************************************F	 > * EntryCQ > ******************************************************************************/' > 2 > int map_image(  struct dsc$descriptor *filename,4 >                 struct dsc$descriptor *regionname,, >                 struct mapping_array *map, >                 int access,2 >                 int system)g > { Q > /******************************************************************************. > * Local Variable Definition-Q > ******************************************************************************/l, > int alloc_size; /* how much to allocate */< > struct rabdef *rab;     /* pointer to RAB of image file */< > struct fabdef *fab;     /* pointer to FAB of image file */5 > struct namdef *nam;     /* pointer to NAMe block */u
 > int status;  > int flags; > int space[2] = {0,0};r >  > /*- > * First find some space for the FAB and RABt > */ > % > alloc_size= sizeof(struct rabdef) +n; >                 sizeof(struct fabdef); /* size of each */y > 2 >                         /* round up to a page */+ > status=sys$expreg((alloc_size + 511)/512,u' >                   &map->fabrab_va[0],s >                   0, >                   0);c > F > if(status%2 == 0)return(status);  /* tell the fellow the bad news */ >  > /*" > * Now create the FAB and the RAB > */ > * > fab= (struct fabdef*) map->fabrab_va[0];: > rab= (struct rabdef*) (int) fab + sizeof(struct fabdef); > ? > *fab= cc$rms_fab;           /* a lot of runtime code to    */d; > *rab= cc$rms_rab;       /* initialize these structures */- >  > /* > * Define FAB values1 > */ >  > fab->fab$b_fac = FAB$M_BIO | >                  FAB$M_PUT |0 >                  FAB$M_GET ; /* file access */ > E > fab->fab$l_fna = filename->dsc$a_pointer;  /* point to file name */.E > fab->fab$b_fns = filename->dsc$w_length;   /* length of filename */eE > fab->fab$l_fop = FAB$M_UFO;                 /* file open options */sG > fab->fab$b_rfm = FAB$C_FIX;                 /* Record format fixed */a > fab->fab$b_shr = >                  FAB$M_UPI|o >                  FAB$M_GET|6% >                          FAB$M_PUT|* >                  FAB$M_UPD|iE >                  FAB$M_DEL;                /* file sharing flags */'G > fab->fab$w_mrs=512;                            /* size of a record */1 > F > rab->rab$l_fab = fab;                      /* point to rab to fab */3 > rab->rab$w_usz=512;     /* user buffer address */u5 > rab->rab$l_rop= RAB$M_BIO;  /* Mark as block i/o */t >  > /* > * Open the filee > */ >   > status = sys$open (fab, 0, 0); > if(status%2 == 0)u > {n, >   printf("  MAP_IMAGE> failure to open "); >   return (status); > }  >  > /*% > * Create and map the global section. > */ > O > if(map->region_va[0] != 0)      /* User has somewhere to map this already? */  >    flags= 0; > else >    flags= SEC$M_EXPREG;b > E > if(system != 0)                 /* System global or group global */s( >    flags |= SEC$M_SYSGBL | SEC$M_GBL ; > else >    flags |= SEC$M_GBL; > < > if(access != 0)flags |= SEC$M_WRT;      /* Write access */ > * > status=sys$crmpsc(map,      /* inaddr */3 >                   map,              /* retaddr */a7 >                   0,                /* access mode */c1 >                   flags,            /* flags */e7 >                   regionname,       /* region name */ 1 >                   0,                /* ident */t4 >                   0,                /* rel page */3 >                   fab->fab$l_stv,   /* channel */l6 >                   0,                /* page count *// >                   0,                /* vbn */r0 >                   0,                /* prot */+ >               0);               /* pfc */m >  > #ifdef DEBUG_t > if(status%2)< >     printf("\n  MAP_IMAGE> region mapped at: %08X, %08X ",2 >            map->region_va[0],map->region_va[1]); > else1 >     printf("\n  MAP_IMAGE> failed: %d",status);o > #endif >  > return (status); >  > }  /* Module end */e >  > Phillip Helbig wrote:  > L > > I have a program where the bottleneck is computing a certain quantity asI > > a function of 5 variables.  However, this quantity can be computed in K > > advance at leisure.  I'm thinking of precomputing this and then reading K > > the file into the program and using a lookup table/interpolation ratherRK > > than computing the values on the fly.  Especially useful, perhaps, if IoJ > > run the application more than once, but even in this minimal case it's > > probably worth it. > >IK > > The application uses the values in a certain order and I can precomputepI > > them in this order.  Should I make one large file and let the virtualvJ > > memory system take care of the fact that it won't all fit into memory,L > > keeping in mind that the values are accessed in the order they are used,J > > or should I split it up into smaller files?  Should I used a formattedI > > or unformatted file?  (Four places are enough precision, so the sizesh5 > > would be about the same.)  Indexed or sequential?e > >wI > > This is with Compaq Fortran 95 on ALPHA/VMS.  At the moment, I have alG > > choice between a 255/233 with 64 MB or a 3000/600 with 192 MB.  I'miI > > assuming the processor speed, not the memory size, will determine the J > > speed if things are set up correctly with regard to the large file (orI > > many smaller files, as the case might be).  The application otherwise B > > needs very little memory and does very little I/O, just number > > crunching. > >sK > > We're talking about 1.5 GB or so of data, i.e. 360 million values to beg
 > > computed.t > >sL > > I asked a similar question a few months ago.  I've decided to ask again,J > > since there didn't seem to be a consensus in the answers and since I'm6 > > finally getting around to actually doing this now. > >YK > > If it turns out to be too slow, I might compute it on a faster machine.e- > > Thus, I'd like to stick to standard code.f > >fI > > The question of one large or several smaller files is mainly relevanteJ > > for the application which will USE the data, i.e. I could in principleJ > > calculate the stuff in several smaller files (which I would have to doH > > if I split things up among several machines) and combine them later.J > > Things would be easier, though, if one large file could be used in all > > circumstances. > >r > > --Q > > Phillip Helbig                       Email .............. helbig@astro.rug.nlIQ > > Kapteyn Instituut                    Email ................. helbig@man.ac.ukVQ > > Rijksuniversiteit Groningen          Tel. ................... +31 50 363 4067tQ > > Postbus 800                          Fax .................... +31 50 363 6100tQ > > NL-9700 AV Groningen                 Web ... http://www.astro.rug.nl/~helbig/  > >e9 > > My opinions are not necessarily those of my employer.  > >sR > > <A HREF=" http://gladia.astro.rug.nl:8000/helbig/hire/hire.html ">HIRE ME!</A> >  > -- > Earl D. Lakia 2 > Senior Staff Engineer         Web: www.ipact.com6 > Snail Mail:                   Email: lakia@ipact.com > IPACT Inc.3 > 260 S. Campbell St.           Phone: 219-464-7212' > Valparaiso, IN 46383   ------------------------------  % Date: Thu, 11 May 2000 21:46:58 +0200r2 From: "Dr. Otto Titze" <titze@ikp.tu-darmstadt.de>. Subject: Booting a Vax 4090 from Infoserver CD3 Message-ID: <391B0E32.E75C58E4@ikp.tu-darmstadt.de>t   Hi all.-  B how can I boot an OS VMS CD on an InfoServer for a complete system
 generationF from a VAX WS 4060? I know how to do this for every Alpha but I looked throughuG all my older documentation and found nothing. In the VMS_Install manuali< on the OS CD e.g. 6.2 there is only an example for a VAX6000 (B/r5:100/x:../d:...)   F I never neded this before because my older workstation came with a FIS system7 or smaller ones I added as satellites to my cluster... d  G I did this several times with Alphas but of course this doesn't help meo here very much.d  : Just for completeness, ist the boot command the same for a MV4500, MV3800?u9 I don't know if I would need this sometimes infuture too.t   Thanks and regards   Otto  ,  -------------------------------------------, | Dr. Otto Titze, Kernphysik TUD           |, | Schlossgartenstr. 9, D-64289 Darmstadt   |, | titze@ikp.tu-darmstadt.de                |, | Tel: +49(6151)16-2916,FAX:16-4321        |,  -------------------------------------------   ------------------------------   Date: 11 May 2000 22:59:43 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)! Subject: comparative TCP/IP testsh, Message-ID: <8ffe0v$qr3@gap.cco.caltech.edu>  I How well do the basic transports of the various TCP/IP stacks for OpenVMSa work?   I Hard to tell these days since we don't have Digital Review around anymoretI to do this sort of test for us.  However, I've done a bit of testing withdK Netpipe 2.3, which runs on a variety of platforms.  It is a very low level wK test - it just measures bandwidth versus packet size.  I ran this primarilyrG between DS10 systems, with a few others thrown in.  For the results andl details look in the directory: r  -   http://seqaxp.bio.caltech.edu/www/vmstcpip/t  7 and start with the AAAREADME.TXT file there.  Also see:   ;   http://seqaxp.bio.caltech.edu/www/vmstcpip/COMPARISON.GIFe   Things I learned:e  K 1.  In this test Multinet has severe problems handling packets larger than cI 8K.  Ok, that's just this one test, but the results fit all too well witheB previous tests of FTP and SMB clients which in some instances wereG miserably slow going to a Multinet system.   (Look in deja for previousmG tests I've done that demonstrate this.)  If you look closely you'll seedF that there is a faint echo of this effect even in the test of Multinet? against itself through localhost (compare DS10MULTINETSELF withg DS10MULTINETRH52INTEL).t  I 2.  Neither Multinet nor TCP/IP services can handle a packet bigger than yI 64K.  Sounds like the QIO limit.  One can only wonder what they do when aTD packet bigger than this hits them!  (Compaq, since there's already aJ replacement for QIOs around, can't we please be rid of this 16 bit limit?)  K 3.  Netpipe will not run in either direction between a VMS machine (either RB stack) and Red Hat 6.2 on a DS10.  Both stacks gave the same errorK messages. I could not run the test between two Multinet systems, apparentlyeI because of some copy protection mechanism in Multinet which prevented thesJ second system, which had a "borrowed" license, from communicating with theG first system.  The second system would ping/telnet to the other systemsn though.   G 4.  The tests run through localhost indicate a huge speed advantage foroK RH62 over TCP/IP Services, and even more so over Multinet.   It's a log loglJ plot so the differences look smaller than they are.  Example:  at a packet' size of 1021 bytes the performance is: 6     286.960019  Linux "   112.216778  VMS, TCP/IP services    90.652512  VMS, Multinet   J That is, for this sort of internal operation, Linux is more than 2X fasterC than TCP/IP services and more than 3X faster than Multinet. This isiI all on identical hardware and never touches the network outside the box.  K This tells me that there's a lot of room for improvement somewhere - eithereH in the stacks or possibly in OpenVMS itself.  I think this is definitelyK worth looking into since programs using these sorts of internal connectionsnI are common, and performance enhancements in this transport should show upo  immediately in these programs.        H I'll be the first to admit that performance testing network stacks isn'tJ what I've been trained to do, but nobody else is doing it.   So if Compaq J or Process would like to put up their own tests, I'll be happy to look at K them.  But don't leave Linux out, since at least by this test it appears to8 be the best of the lot.r   Regards,   David Mathog mathog@seqaxp.bio.caltech.edu ? Manager, sequence analysis facility, biology division, Caltech i   ------------------------------  % Date: Thu, 11 May 2000 19:21:04 -0500d) From: "John E. Malmberg" <wb8tyw@qsl.net>o% Subject: Re: comparative TCP/IP tests 7 Message-ID: <001101bfbba7$fb5caab0$020a0a0a@xile.realm>r  : David Mathog <mathog@seqaxp.bio.caltech.education> writes: > K > 2.  Neither Multinet nor TCP/IP services can handle a packet bigger than uK > 64K.  Sounds like the QIO limit.  One can only wonder what they do when ai$ > packet bigger than this hits them!  ; Is not the maximum packet size negotiated by the TCP stack?    -Johns wb8tyw@qsl.network   ------------------------------  % Date: Thu, 11 May 2000 17:51:24 -0700a9 From: Clemens Wermelskirchen <wermelsk@SLAC.Stanford.EDU>p% Subject: Re: comparative TCP/IP testsv6 Message-ID: <391B558C.F48B78C7@ssrl.slac.stanford.edu>  H Keep in mind that TCP does not handle packets. It handles a byte stream.A The network packet size is much smaller anyways and, assuming theeH network packets arrive fast enough, they might get assembled into largerK I/O blocks returned to the application. The 64k QIO limit is irrelavant for  TCP/IP.c   Clemensl   "John E. Malmberg" wrote:   < > David Mathog <mathog@seqaxp.bio.caltech.education> writes: > >uL > > 2.  Neither Multinet nor TCP/IP services can handle a packet bigger thanM > > 64K.  Sounds like the QIO limit.  One can only wonder what they do when aC& > > packet bigger than this hits them! > = > Is not the maximum packet size negotiated by the TCP stack?n >. > -Johna > wb8tyw@qsl.network   ------------------------------  # Date: Thu, 11 May 2000 18:34:16 GMT / From: "Richard L. Dyson" <rick-dyson@uiowa.edu>Z  Subject: DECserver 90M boot file( Message-ID: <391AB6D8.A624DF7@uiowa.edu>  > I have an old DECserver 90M that is requesting to get a MOP or
 BOOTP/TFTPE load of it's operating software (MNENG3), but there is none availableGF currently.  The server should have a copy of MNENG2 in it's flash RAM.  G It is not "falling back" to that version (or it got cleared...) and theA6 console just shows me it is looping with the requests.  G Is there anyway I can tell it to use MNENG2 instead of "3" and thus use H the one it already has?  Some console terminal key combo to break out ofE the boot load loop and allow some low level commands (like SET SERVERe SOFTWARE MNENG2) to be sent?   Thanks!s
 Rick Dyson -- aH Richard L. Dyson                                    rick-dyson@uiowa.eduH  _   _      _____                http://www-pi.physics.uiowa.edu/~dyson/H | | | |    |_   _|   Systems Analyst                     O: 319/335-1879H | | | | of   | |     The University of Iowa            FAX: 319/335-17536 | \_/ |     _| |_    Department of Physics & Astronomy-  \___/     |_____|   Iowa City, IA 52242-1479    ------------------------------  % Date: Thu, 11 May 2000 23:34:27 +0400 4 From: "Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU>$ Subject: Re: DECserver 90M boot file0 Message-ID: <391B0B43.C49EC80F@SMTP.DeltaTel.RU>   Did you try to reset DS90M?s   Richard L. Dyson wrote:  > @ > I have an old DECserver 90M that is requesting to get a MOP or > BOOTP/TFTPG > load of it's operating software (MNENG3), but there is none availablewH > currently.  The server should have a copy of MNENG2 in it's flash RAM. > I > It is not "falling back" to that version (or it got cleared...) and theN8 > console just shows me it is looping with the requests. > I > Is there anyway I can tell it to use MNENG2 instead of "3" and thus useuJ > the one it already has?  Some console terminal key combo to break out ofG > the boot load loop and allow some low level commands (like SET SERVERn > SOFTWARE MNENG2) to be sent? > 	 > Thanks!m > Rick Dyson > --J > Richard L. Dyson                                    rick-dyson@uiowa.eduJ >  _   _      _____                http://www-pi.physics.uiowa.edu/~dyson/J > | | | |    |_   _|   Systems Analyst                     O: 319/335-1879J > | | | | of   | |     The University of Iowa            FAX: 319/335-17538 > | \_/ |     _| |_    Department of Physics & Astronomy/ >  \___/     |_____|   Iowa City, IA 52242-1479t   -- s Regards.F +.....................pure personal opinion..........................+B     Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM- 	Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035tG +............ Frying only on VMS, flying only by Su-27  .............+
n   ------------------------------  # Date: Thu, 11 May 2000 22:28:55 GMTi( From: Terry Kennedy <terry@gate.tmk.com> Subject: Re: DS700 question...' Message-ID: <FuF2G7.I1v@spcuna.spc.edu>-  ; Carlc Internet Services <carlc@iname-nospammen.com> writes:M# >     The DS700 is at this version:q >.7 > DECserver 700-08 V1.1C BL46A-13  LAT V5.1  ROM V3.4-9I >eN >     It is to old or maybe there is a new version that can allow it to handle > the 19200 baud correctly?s  E   That's the obsolete DECserver 700 software. The current software is 9 DECserver Network Access Software (current version 2.3A):   , Network Access SW V2.3A for DS700-08 BL47-60  G   However, it's unlikely that this is a software issue - poke around inw the port config first.  - 	Terry Kennedy             http://www.tmk.comr5         terry@tmk.com             Jersey City, NJ USA.   ------------------------------  % Date: Thu, 11 May 2000 19:30:27 -0400./ From: "Joe H. Gallagher" <dtrwiz@ix.netcom.com>t Subject: Re: DS700 question...( Message-ID: <391B428F.86D@ix.netcom.com>   Carlc Internet Services wrote: >  > Hi COMP.OS.VMS,. > @ >     I'm trying to use a fax software connected to a multitech @ > modem via a LATs connection on our vax. When I use the Emulex A > NETQUE server, it works fine... When I use the DS700, it doesnt @ > work correctly (I'm getting lines in the faxes). I've checked > > the port setups, and they look as identical as an Emulex to  > Digital can get. > # >     The DS700 is at this version:o > 7 > DECserver 700-08 V1.1C BL46A-13  LAT V5.1  ROM V3.4-9r > < >     It is to old or maybe there is a new version that can . > allow it to handle the 19200 baud correctly? >  >     Thanks in advance./ >     Carl C. (ccouric at fhp dash mfg dot com)   > "lines in the faxes" is a clear sign of flow control problems.  < Make sure that the DECserver 700 and the FAXing software are< set up the same way.  If you are using Xon/Xoff flow control@ on both and it still doesn't work, try it with CTS flow control.  ; We just went thru the same problem to set up FAXing with a e> Multitech MT2834, DECserver 700, VAX/VMS V7.2, and WCF FAXing 	 software.r   Joe H. Gallagher   ------------------------------  % Date: Thu, 11 May 2000 23:37:55 -0400e$ From: Kent Rankin <krankin@usit.net>6 Subject: FS: Compaq external DLT drive(15/30GB) ; $350( Message-ID: <391B7C93.E28D8A53@usit.net>  2 	The unit is located in Knoxville, TN, 37922-3449.  C 	It is in an external Compaq case(3300-series storage option, to beo, precise), and has two micro-DB50 connectors.  / 	Please send any questions that you might have.p     							Thanks, 							Kent Rankin   ------------------------------  % Date: Thu, 11 May 2000 23:36:09 -0400c$ From: Kent Rankin <krankin@usit.net>3 Subject: FS: DEC TZ877 7-tape DLT Autoloader ; $850m( Message-ID: <391B7C29.5BAD9B8A@usit.net>  2 	The unit is located in Knoxville, TN, 37922-3449.  H 	It is a seven tape(DLT III) autoloader with centronics SCSI connectors. 	s/ 	Please send any questions that you might have.m    
 						Thanks,n 						Kent Rankini   ------------------------------   Date: 11 May 2000 17:08:22 CDT= From: wayne@tachysoft.xxx.302774.killspam.0140 (Wayne Sewell)r8 Subject: Re: ftp.decus.org is back up!  And running VMS!. Message-ID: <BsoxkLk2$Et4@tachxxsoftxxconsult>  b In article <%czS4.487$s4.49075@petpeeve.ziplink.net>, "David Cressey" <david@dcressey.com> writes:B > I don't know if this is helpful or not,  but I succeeded once inJ > reconstituting a BACKUP save set,  that had been FTP'd to a Unix system,G > stored there for redistribution,  and then FTP'd to another VMS site.b > I > The file, as received had RMS records that were fixed length, 512 bytesa > long.q > M > It was a matter of multiplying 63 by 512,  and using that number to set the- > RMS recordN > length attribute in the received file.  63 is some sort of magic number,  by > default, for BACKUP. > M > Figuring out how to reset the RMS record length attribute without writing agJ > program involved some fairly tedious and obscure research in DCL and RMS > documentation. > N > Once the change was made,  presto!  BACKUP/LIST showed an error free saveset > file,  and BACKUPwJ > was perfectly happy restoring the files.  I did a few trials with  files* > that I could compare with the originals,I > and in all the tests I did,  not one bit was lost!  Of course,  I can't0) > guarantee you that 63 blocks per recordrF > is universal among BACKUP savesets.  It isn't.  But it's widespread. >  > I hope this helps someone. >   M Sounds as if you went to a hell of a lot of work that could have been avoided C by reading the faq.  This has been discussed here many, many times.a      < ------------------------------------------------------------/ MGMT20.  How do I fix a corrupt BACKUP saveset?p  E   BACKUP savesets can be corrupted by FTP file transfers and by toolsJC   such as zip (particularly when the zip tool has not been asked to.F   save and restore OpenVMS file attributes or when it does not supportF   OpenVMS file attributes), as well as via other means of corruptions.  D   If you have problems with the BACKUP savesets after unzipping themF   or after an FTP file transfer, you can try restoring the appropriate$   saveset attributes using the tool:  *     $ @RESET_BACKUP_SAVESET_ATTRIBUTES.COM  C   This tool is available on the OpenVMS Freeware (in the [000TOOLS]aD   directory).  The Freeware is available at various sites -- see theF   Freeware location listings elsewhere in the FAQ -- and other similar0   tools are also available from various sources.  E   In various cases (note that not all savesets use the default recorda+   size!), the following command might work:i  I     $ SET FILE/ATTRIBUTES=(RFM:FIX,MRS:32256,LRL:32256,RAT:NONE) file.bck   K   Also see the "SITE VMS", /FDL, and various other file-attributes options  G   available in various FTP tools.  (Not all available FTP tools support    any or all of these options.)a  I   Browser downloads (via FTP) and incorrect (binary or ascii FTP transferEL   modes) are notorious for causing RMS file corruptions.  You can sometimes J   help encourage the browser to select the correct FTP transfer type code    via RFC1738:       ftp://host/url?type=binary   					[Stephen Hoffman]  < ------------------------------------------------------------    9   The OpenVMS FAQ is archived in the following locations:s  :     http://www.openvms.digital.com/wizard/openvms_faq.html9     ftp://ftp.digital.com/pub/Digital/dec-faq/OpenVMS.txt 1     ftp://ftp.digital.com/pub/Digital/dec-faq/vmst:     ftp://rtfm.mit.edu/pub/usenet/news.answers/dec-faq/vms,     comp.answers and news.answers newsgroups  A   Other internet FAQs are generally available in these locations:o  ,     comp.answers and news.answers newsgroups%     ftp://rtfm.mit.edu/pub/usenet/...   ?   User-created HTML versions of the OpenVMS FAQ are located at:r       http://www.kjsl.com/vmsfaq'     http://eisner.decus.org/vms/faq.htma       -- eO =============================================================================== M Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxx : http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-)sO =============================================================================== C Jake Blues: "Sell me your children!  How much for the little girl?"*   ------------------------------  + Date: Thu, 11 May 2000 16:31:40 -0400 (EDT)* From: AppleAndPC@aol.com. Subject: How to share a VMS disk drive with NT) Message-ID: <5a.505cfee.264c72ac@aol.com>m  M Is there a way to map a VMS share or drive to make it available for both VMS=m1  users and NT users without the use of Pathworks?eM Some of our departments share files under both platforms and are not familia= M r with FTP and scripts will not do because file locations and names vary als=*M o we have been experiencing lots of problems with the Pathworks licensing (s=*M erver 5.0F and client 6 & 7) we are also implementing the Windows 2000 works=*M tations and we can=92t upgrade the VMS to a higher version to upgrade Pathwo=*( rks because of some applications issues!8 VMS cluster running OpenVMS 6.2, UCX 4.2, and DECnet 6.1 Any help is appreciated. Thanxt   ------------------------------  % Date: Thu, 11 May 2000 16:53:27 -0400a" From: Dan Sugalski <dan@sidhe.org>2 Subject: Re: How to share a VMS disk drive with NT8 Message-ID: <4.3.1.0.20000511165220.0250d7c0@24.8.96.48>  4 At 04:31 PM 5/11/00 -0400, AppleAndPC@aol.com wrote:J >Is there a way to map a VMS share or drive to make it available for both 5 >VMS users and NT users without the use of Pathworks?e    H SAMBA and NFS will both do this. SAMBA's better on the NT side since it I makes the VMS box look like an NT fileserver, while NFS makes both sides e reasonably Unixy.t     					Dan  L ----------------------------------------------------------------------------L Dan Sugalski                          General and VMS-specific perl training
 dan@sidhe.org >                                       Mail me for more details   ------------------------------  % Date: Thu, 11 May 2000 20:52:13 -0600 ) From: Roger Tucker <roger.tucker@mci.com> . Subject: Re: Is "The GNU on VMS Project" dead?' Message-ID: <391B71DD.248D406C@mci.com>h  . Also check out the site "GNV - GNU's Not VMS!" http://gnv.sourceforge.net/   6 GNV includes most of the GNU products including a BASHD shell, make,  and many other Unix utilities.  I think all we need is< an autoconfig and most Unix software would port to VMS usingF the standard Unix build scripts.  At least that's the goal.  We shouldG all help out this effort where we can and all the linux software shouldB" easily port to VMS when it's done.   Rudolf Wingert wrote:    > Hello, >fJ > I was on the official "The GNU on VMS Project" WEB page and did see thatL > the last change was at 1997. Three year ago it a long time. Is the project > dead?  >   > TIA and regards Rudolf Wingert   ------------------------------  # Date: Thu, 11 May 2000 19:29:08 GMT  From: Ed.Wilts@merrillcorp.com Subject: Re: LMF weirdness) Message-ID: <8ff1lf$n2s$1@nnrp1.deja.com>   6 In article <8femj2$pbv$2@mailint03.im.hou.compaq.com>,&   hoffman@xdelta.zko.dec.nospam wrote: >iD > In article <8feee6$vu3$1@nnrp1.deja.com>, Ed.Wilts@merrillcorp.com writes:o? > :I'm getting stumped by some licensing issues (technical, not/E > :business).  I've got some VMSCLUSTER and VOLSHAD licenses that areeG > :getting loaded on systems that they're not supposed to be loaded on. G > :Specifically, all of these licenses have a /INCLUDE that is supposedu to, > :restrict the license to a specific hosts. > E >   If you have more than one license database around, make sure thatgE >   every license PAK is registered (the same way) in every database.  >e1 >    Hoff (Stephen) Hoffman   OpenVMS Engineeringl  D We do have more than one database, and that's what I'm trying to getG away from - this has caused us more grief than what it gained, and I amLF trying to migrate to a single common database.  I do know that on moreG than one occasion we've had more than one system using the same licensed out of different databases.,  > Does LMF actually read the contents of another systems licence? database?  What's it really doing, or is this something I'm nota supposed to know?    Thanks,i	    .../Ed     & Sent via Deja.com http://www.deja.com/ Before you buy.*   ------------------------------  % Date: Thu, 11 May 2000 16:14:02 -0500 ) From: "John E. Malmberg" <wb8tyw@qsl.net>  Subject: Re: LMF weirdness7 Message-ID: <1aea01bfbb8d$d5b64ba0$020a0a0a@xile.realm>   . Ed Wilts <Ed.Wilts@merrillcorp.company> wrote:  8 > In article <8femj2$pbv$2@mailint03.im.hou.compaq.com>,( >   hoffman@xdelta.zko.dec.nospam wrote: > > J > > In article <8feee6$vu3$1@nnrp1.deja.com>, Ed.Wilts@merrillcorp.company	 > writes:]A > > :I'm getting stumped by some licensing issues (technical, not%G > > :business).  I've got some VMSCLUSTER and VOLSHAD licenses that areeI > > :getting loaded on systems that they're not supposed to be loaded on.cI > > :Specifically, all of these licenses have a /INCLUDE that is supposede1 > > :to restrict the license to a specific hosts.t > >uG > >   If you have more than one license database around, make sure thattG > >   every license PAK is registered (the same way) in every database.m > >g3 > >    Hoff (Stephen) Hoffman   OpenVMS Engineeringi >oF > We do have more than one database, and that's what I'm trying to getI > away from - this has caused us more grief than what it gained, and I amaH > trying to migrate to a single common database.  I do know that on moreI > than one occasion we've had more than one system using the same licensef > out of different databases.m >r@ > Does LMF actually read the contents of another systems licenceA > database?  What's it really doing, or is this something I'm noto > supposed to know?d  K As near as I can tell, LMF only reads the contents of the databases on your  local node.o  J For SIP licenses keys on a cluster, (VMSCLUSTER,VAXCLUSTER,DECNET,VOLSHAD,K etc) you must have enough license units loaded each node for all units that  are members of the cluster.M  J It only checks at the product startup time.  This means that configuration5 errors may only be apparent with certain boot orders.e  G For example, consider a cluster with three MicroVAX IIs.  Say that each ' MicroVAX II requires 230 license units.y  I To boot the first system and get VMScluster software running, it needs to L read from the LMF file, valid license VMSCLUSTER license keys for 230 units.  H For the second system, in order for to start the VMScluster software, itE needs to read from the LMF file, 230 more license units to add to thet6 existing 230 units in the cluster, for a total of 460.  H For the third system, it will need to have a total of 890 license units.    G Where things become interesting is when you have one of the nodes beinge9 licensed for END-NODE decnet, and two for Routing DECNET.f  I In this case, the end-node DECNET requirements are 230 license units, ande3 the routing node DECNET requirements are 640 units.v  G In this case, if you are running separate license databases, things may > appear to work well.  Now what happens with a common database?  I Experimentation has shown that /INCLUDE option does not work with the SIPaJ class of licenses.  All SIP license keys found for a given name are loadedK unless /EXCLUDE prevents them.  It may be that if there is only one key fory5 a specific license name, that the /INCLUDE will work.2    H So with a common database, the first MicroVAX booted will attemp to loadL both the END-NODE and Routing license units and will succeed.  It has stolenL one of the routing node license keys.  This means that the third system will+ not have licenses for DECNET when it boots.w    K In this case you must exclude the two systems that are licensed for ROUTINGOK DECNET from the END-NODE license key.  And you must exclude the system thataF is licensed for END-NODE from both of the ROUTING DECNET license keys.  B The /INCLUDE seems to work for layered products, where it prevents. non-included systems from taking the licenses.  J It gets real fun when you are mixing NET-APP-SUP-nnn licenses, and various% DECNET and UCX licenses in a cluster.    -Johny wb8tyw@qsl.network   ------------------------------  % Date: Fri, 12 May 2000 07:37:20 +0200  From: mey51@cesnet.cz (Dave) Subject: NEED I.D.?)F Message-ID: <200005121077CAA44718@fgtyuikj9o.village.telecomitalia.it>   INTERNATIONAL DRIVER'S LICENSE   Need a new driver's license?=20_  ! Too many points or other trouble?i  - Want a license that can never be suspended=20e or revoked?   ) Want ID for nightclubs or hotel check-in?f  / Avoid tickets, fines, and mandatory driver's=201
 education.  - Protect your privacy, and hide your identity.t  , The United Nations gave you the privilege to1 drive freely throughout the world! (Convention=20u1 on International Road Traffic of September 19,=20 * 1949 & World Court Decision, The Hague,=20 Netherlands, January 21, 1958)  0 Take advantage of your rights.  Order a valid=200 International Driver's License that can never=20 be suspended or revoked.   Confidentiality assured.   CALL NOW!!!=20   1-937-586-9313=20         rem--  filebox87@techie.com=20R   773360822877869486348847 =E9=01:F   ------------------------------  % Date: Fri, 12 May 2000 07:52:56 +0800c- From: David B Sneddon <dbsneddon@bigpond.com>n= Subject: Re: Problem with Seagate disk on VAXstation 4000 VLCI+ Message-ID: <391B47D8.FFBD9F3E@bigpond.com>n   "Bart Z. Lederman" wrote:t > ] > In article <3919EFBA.B1BE5090@bigpond.com>, David B Sneddon <dbsneddon@bigpond.com> writes:  > >aL > >It is not a duplicate ID, I install the disk internally and terminate the. > >SCSI - this is the only device on the SCSI. > >> > >i > >show config gives mea > >       A/1/0r > >       A/1/1t > >        ... > >       A/1/7  > >like it sees 8 devices. > A > This is indeed one of the common symptoms of having two devices- > with the same ID.   < There is only ONE device, SCSI ID 1, the controller ID is 6.  <E > >The disk was removed from a functioning VAXstation 4000-90 and was1 > >fine in that box. > C > Some VAX systems have the controller at ID 7, while some have the'B > ID at 6, and the VLC is one of them.  If your disk is at ID 6 itA > could have worked in the 4000-90 but still give you problems inrA > the VLC.  Try changing it's ID to 0 or 1 and see if that helps.e@ > (Also check to see that none of the little jumpers that select= > the ID didn't drop off or come lose when you moved the diska > from one system to another.)  D None of the jumpers have come loose or fallen off, the ID was set toE 1 since I already had a 0 and 4 on the VLC.  As I stated before, this C problem happens even when this disk is the ONLY device on the SCSI.   2 The question I really want to get an answer for is7 "what does the 0034 value mean in ?? 110 10 SCSI 0034".r >  > --* >  B. Z. Lederman   Personal Opinions Only     --   Regards, Dave. I -------------------------------------------------------------------------iI David B Sneddon (dbs)  OpenVMS Systems Programmer   dbsneddon@bigpond.comeI DBS software at ...   http://www.users.bigpond.com/dbsneddon/software.htmSI "Life is what happens to you while you're busy making other plans" Lennon-   ------------------------------  % Date: Thu, 11 May 2000 23:08:25 -0500k) From: "John E. Malmberg" <wb8tyw@qsl.net>nP Subject: SAMBA for VMS - Was Re: Suggest a better file serving solution than NT?7 Message-ID: <00bc01bfbbc7$b9aef440$020a0a0a@xile.realm>n  / Glenn C. Everhart <Everhart@GCE.company> wrote:o   > Dan Sugalski wrote:w= > Speeds running SAMBA will vary considerably. The oplocks in @ > Samba 2.0.3 should make it faster by far than the old version.  G Oplocks are not present in the SAMBA-VMS 2.0.3 release.  They require aR' working fcntl() locking implementation.C  K I do have it apparently working in my port of SAMBA 2.0.6.  As I get closer K to placing something at my ftp site, I may need to prioritize what featuresL are implemented.   Among the features implemented:s   OPLOCKS mentioned earlier. Share locking.' Encrypted Passwords on the SMBD server.iD Logging can be redirected to any valid file specification, including SYS$OUTPUT.@6 Shares with 12 levels of directories on ODS-2 volumes.D File attributes can be associated with file extension in many cases.  D Note: the UNIX samba 2.0.6 opens all files on a read-write share forK read/write, and this updates the modification dates. This is expected to beiI fixed in a future release of the UNIX samba code.  My  VMS implementationUG also does this.  RMS locking also seems to require the file be open ford write.    G As of now I do not have implemented, in the order I am working on them:M  @ Any feature that requires an external DCL command like Printing.8 Conversion of the setuid() call to use persona services.# Plain-text passwords on the Server.a@ Some options are hardwired that should be done by logical names. OpenVMS/VAX 7.1 build.$ Packaging binaries for distribution.> Packaging of sources and build instructions for self builders.I Investigation of the NOTEPAD issue of containing text beyond logical EOF.o   Samba 2.0.7 builda ODS-5 support.# Case Preserved filenames for ODS-2.r% Fix for timeout problem in smbclient.  True READLINE support.E Conversion of share locking to directly use distributed lock manager.tL Conversion of some of the features that call external DCL command procedures to use system service calls.+ ODS-2 shares with 15 levels of directories.a@ tdb library routines implemented using native RMS indexed files.    K As this is a spare-time unfunded project, I can give no commitments on whena% I will have something usable to post.t  G This port is mainly using a wrapper for the DEC C run time library that-L either modifies existing routines or provides additional routines, such as a fcntl() that uses RMS locking.E The run-time library is written to allow ports of other programs fromaL UNIX/LINUX to VMS and should work with versions of VMS from 5.5-2 on upward.  J This run time library contains some code from the previous SAMBA-VMS code,L and some routines from other VMS freeware.  I have been keeping track of who
 to credit.  J There are only a few small modifications to the base UNIX SAMBA version soG it should be easier to keep current.  The current UNIX SAMBA release isR 2.0.7.  L If there are features that can be lived without or if there is some interestK in a partial release for people that want to do some testing, please let me % know.  And I will try to accommodate.s   -Johne wb8tyw@qsl.network   ------------------------------   Date: 11 May 2000 19:13:25 GMT* From: helbig@astro.rug.nl (Phillip Helbig)8 Subject: sharing large amounts of data between processes. Message-ID: <8ff0ol$77b$1@info.service.rug.nl>  H This is related to a completely different problem than my last few "big E file" posts.  However, some of the responses hint that the solutions F might be similar.   G Imagine a program which needs several hundred MB of memory, which needs D to be updated (new items entered, perhaps some sort of sorting, someE items deleted, some modified) once a minute or so.  In principle, the C program could update itself, but it might be better to have anothereE program do this.  Thus, one needs some memory (global section?) to beeD shared between processes, which might be run by completely different? users.  I have used logicals to transfer data between processessF (creating a special table for this), but this is probably not the best2 approach if one adds, say, 1 kB per minute or so.   H Since I have a third program which really needs to access the same data E simultaneously (say, once every few minutes), the global section (if  A that's what it is) seems the best way to go.  The amount of data eE prevents updating it on disk, restarting the program with fresh data / read from the disk etc..  H In contrast to my previous "big file" posts, the main point here is not I the size, but the on-the-fly updating.  Also, this will only ever run on  I VMS, so I might be willing to use some non-standard VMS-specific Fortran =I for this.  (There are related DCL procedures interacting with this, so I n? don't mind doing things in DCL.)  I really have practically no aG experience exchanging data in RAM between processes.  Where's the best aI place to learn about this?  It would be nice to do everything in Fortran = and/or DCL.=   ------------------------------   Date: 11 May 2000 23:08:57 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)< Subject: Re: sharing large amounts of data between processes, Message-ID: <8ffei9$qr3@gap.cco.caltech.edu>  [ In article <8ff0ol$77b$1@info.service.rug.nl>, helbig@astro.rug.nl (Phillip Helbig) writes:t >aH >Imagine a program which needs several hundred MB of memory, which needsE >to be updated (new items entered, perhaps some sort of sorting, somea4 >items deleted, some modified) once a minute or so.   H While you can probably get what you want with global sections, a ramdiskI might also be worth considering.  Then you could use the usual Fortran IO)J and a record oriented solution and it would still run reasonably quickly.    Regards,   David Mathog mathog@seqaxp.bio.caltech.edu ? Manager, sequence analysis facility, biology division, Caltech     ------------------------------  % Date: Thu, 11 May 2000 20:41:41 -0600-) From: Roger Tucker <roger.tucker@mci.com>0< Subject: Re: sharing large amounts of data between processes' Message-ID: <391B6F64.E48193E3@mci.com>   J There are several ways to do this on VMS.  We currently map about 2-4 gigs in memory usingeJ a shared global section with shared PTEs that map to physical memory.  You can create thistI memory using SYSMAN to REGISTER the memory and even zero it at boot time.F
 Updates toJ the memory may need to be serialized with a VMS lock, or your own mutexes, load/lock/storerA instructions, or interlocked PAL code routines, depending on your  performance requirements$ and how much data you need to share.  I See chapters 16,17 of the OpenVMS Programming Concepts manual and sectionp 19.3.4I for using global sections.  Also see the System Services Reference manuale for the routines.-I http://www.openvms.compaq.com:8000/72final/5841/5841pro_contents_006.htmle  I Good performance of message passing can also be done using VMS mailboxes.aK For faster performance and less overhead, a global section can be used with- the correctS synchronization methods.  I Also the IPC$routines can be used for communications and the applications,
 don't even+ have to be on the same node in the cluster.   I I hope that helps get you started.  If you want additional help you mighti need to hireL someone to help you, but all the VMS documentation is on the web and most if not  all of this is in there.  I > Imagine a program which needs several hundred MB of memory, which needs,F > to be updated (new items entered, perhaps some sort of sorting, someG > items deleted, some modified) once a minute or so.  In principle, thesE > program could update itself, but it might be better to have another-G > program do this.  Thus, one needs some memory (global section?) to beWF > shared between processes, which might be run by completely differentA > users.  I have used logicals to transfer data between processesoH > (creating a special table for this), but this is probably not the best3 > approach if one adds, say, 1 kB per minute or so.r >sI > Since I have a third program which really needs to access the same datasF > simultaneously (say, once every few minutes), the global section (ifB > that's what it is) seems the best way to go.  The amount of dataF > prevents updating it on disk, restarting the program with fresh data > read from the disk etc.s >oI > In contrast to my previous "big file" posts, the main point here is notnJ > the size, but the on-the-fly updating.  Also, this will only ever run onJ > VMS, so I might be willing to use some non-standard VMS-specific FortranJ > for this.  (There are related DCL procedures interacting with this, so I@ > don't mind doing things in DCL.)  I really have practically noH > experience exchanging data in RAM between processes.  Where's the bestJ > place to learn about this?  It would be nice to do everything in Fortran
 > and/or DCL.t   ------------------------------  % Date: Fri, 12 May 2000 00:44:40 -0400 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>< Subject: Re: sharing large amounts of data between processes/ Message-ID: <391B8C30.C5F875C3@vl.videotron.ca>y   Roger Tucker wrote:-K > Also the IPC$routines can be used for communications and the applicationsM > don't even- > have to be on the same node in the cluster.g  J Do you mean the $ICC routines, or are there other types of routines called $IPC ?   ------------------------------  % Date: Thu, 11 May 2000 13:33:28 -0600 - From: "Rowell, Bradley" <browell@STATE.MT.US>  Subject: smbclientR Message-ID: <018C4C169A5CD211B84808002BB29C640365FC1E@doaisd02003.mdt.state.mt.us>  J Does anyone know of any commercially supported smbclient type applications* for VMS that do encrypted user validation?  & -------------------------------------- Bradley G. Rowellt$ Montana Department of Transportation browell@state.mt.ush' ---------------------------------------    ------------------------------  % Date: Thu, 11 May 2000 15:26:11 -0500a) From: "John E. Malmberg" <wb8tyw@qsl.net>a Subject: Re: smbclient7 Message-ID: <1ac701bfbb87$26b86120$020a0a0a@xile.realm>g  5 Bradley Rowell <browell@STATE.MT.UnitedStates> wrote:o  L > Does anyone know of any commercially supported smbclient type applications, > for VMS that do encrypted user validation?  L I do not know of any commercially supported versions, but the existing 2.0.3: smbclient for OpenVMS should do encrypted user validation.   -Johnu wb8tyw@qsl.network   ------------------------------  # Date: Thu, 11 May 2000 18:48:17 GMTe3 From: "Gord Coulman" <nospam_gcoulman@ccinet.ab.ca>t8 Subject: Suggest a better file serving solution than NT?9 Message-ID: <RfDS4.9238$%u6.495514@news1.telusplanet.net>n  K I know this is a bit off topic, but my primary NT file server is driving merG nuts with unexplained system hangs and I need to repair/replace it withsJ something approaching the reliability of my OpenVMS machine.  I am open toJ all suggestions, not just another NT box, although the clients are all WinJ 98 and other NT servers, which narrows things a bit.  I have run Pathworks, in the past, but I'm not going back there...    Awaiting your collective wisdom,   Gord.u  I Present system: custom built, NT4.0 SP6A, ASUS dual PIII/600 1GB ECC RAM,eI 9GB mirrored system disk, 140 GB RAID using 18GB Seagate 7200 RPM drives,3H Ultra wide Mylex 3ch RAID controller with battery backup, dual redundantK power supply, dual 3COM 780 load balancing NICs, Diskeeper (latest), McAfee 4 (latest), Undelete (latest), ATI PCI 2MB video card.  K Services:  PDC, file services only (print, backup, and application servicest on different servers)c  K Environment:  about 200 users in a semi-isolated location, heavy multimedia K file i/o.  Typical CPU usage below 30% during peak hours.  Switched 100Mbitu Ethernet (3Com).  K Symptoms:  becomes unresponsive.  Needs power-off reset to reboot.  HappenstH every couple of days at random intervals.  No blue screen, no entries inH event log.  No entries in Mylex log.  Desktop freezes, usually including mouse.  I Repair efforts so far:  New RAM, new CPUs, new NICs (problem seemed to golH away after this, now it's back), more cooling (very cool now), shut down5 Diskeeper, Undelete, McAfee.  Problem is still there.y  F Repair efforts soon:  New video card, replace NICs with Intel, replace& motherboard, replace whole damn thing.   ------------------------------  % Date: Thu, 11 May 2000 15:14:58 -0400s" From: Dan Sugalski <dan@sidhe.org>< Subject: Re: Suggest a better file serving solution than NT?8 Message-ID: <4.3.1.0.20000511151150.02512550@24.8.96.48>  . At 06:48 PM 5/11/00 +0000, Gord Coulman wrote:L >I know this is a bit off topic, but my primary NT file server is driving meH >nuts with unexplained system hangs and I need to repair/replace it withK >something approaching the reliability of my OpenVMS machine.  I am open toeK >all suggestions, not just another NT box, although the clients are all WinfK >98 and other NT servers, which narrows things a bit.  I have run Pathworksl- >in the past, but I'm not going back there...t  4 * VMS running NFS with NFS clients on the NT systems * VMS running SAMBA0 * Anything else running SAMBA)  L It wouldn't surprise me if a PalmPilot running Linux with a SAMBA client is H more reliable than an NT box, though there's the issue of storage space  there...  I However, as many folks will (or at least should, in the interest of full sL disclosure) point out, NT *is* damn stable as a file/print serving platform J if that's all that particular box is doing. If you have a pure file/print I machine falling over dead with any regularity then you've probably got a   hardware problem.r  G Don't let this stop you from using it as an excuse to yank the NT box, b
 though... :-)9   					Dan  L ----------------------------------------------------------------------------L Dan Sugalski                          General and VMS-specific perl training
 dan@sidhe.orgd>                                       Mail me for more details   ------------------------------  # Date: Thu, 11 May 2000 19:31:42 GMT64 From: "Michael D. Ober" <mdo.@.wakeassoc.com.nospam>< Subject: Re: Suggest a better file serving solution than NT?E Message-ID: <yUDS4.51589$g4.1427762@newsread2.prod.itd.earthlink.net>   F Verify you are running DK 5.03, not an earlier version.  Once a lockupK begins, does the system start responding again if you wait long enough.  IfiL it does, set Diskeeper to run at night only.  Multimedia files are large, soB don't do anything during the day that can interfere with file i/o.@ Diskeeper 4 will cause long delays in system responsiveness whenL moving/defragging 100+Mb files.  Also, switch to the base VGA video drivers.I Many video drivers are buggy and will cause system lockups - yes, even ifhI they came out of the box.  MS doesn't write many drivers beyond the basicII VGA drivers.  Your symptoms would tell me to look at Diskeeper, which youg0 appear to have done, and then the video drivers.  I NT is flat out a better file server than VMS/Samba when serving files for H Win9x boxes.  VMS/NFS may be better for serving files to Unix boxes, but5 would require additional software on the Win9x boxes.i  1 Our NT PDC is just as reliable as our VMS system.e  
 Mike Ober.  > "Gord Coulman" <nospam_gcoulman@ccinet.ab.ca> wrote in message3 news:RfDS4.9238$%u6.495514@news1.telusplanet.net...vJ > I know this is a bit off topic, but my primary NT file server is driving meI > nuts with unexplained system hangs and I need to repair/replace it witheL > something approaching the reliability of my OpenVMS machine.  I am open toL > all suggestions, not just another NT box, although the clients are all WinL > 98 and other NT servers, which narrows things a bit.  I have run Pathworks. > in the past, but I'm not going back there... >d" > Awaiting your collective wisdom, >- > Gord.- >-K > Present system: custom built, NT4.0 SP6A, ASUS dual PIII/600 1GB ECC RAM,rK > 9GB mirrored system disk, 140 GB RAID using 18GB Seagate 7200 RPM drives,dJ > Ultra wide Mylex 3ch RAID controller with battery backup, dual redundantF > power supply, dual 3COM 780 load balancing NICs, Diskeeper (latest), McAfee6 > (latest), Undelete (latest), ATI PCI 2MB video card. >qD > Services:  PDC, file services only (print, backup, and application services > on different servers)0 >0B > Environment:  about 200 users in a semi-isolated location, heavy
 multimediaE > file i/o.  Typical CPU usage below 30% during peak hours.  Switchedc 100Mbitl > Ethernet (3Com). >aD > Symptoms:  becomes unresponsive.  Needs power-off reset to reboot. Happens J > every couple of days at random intervals.  No blue screen, no entries inJ > event log.  No entries in Mylex log.  Desktop freezes, usually including > mouse. >IK > Repair efforts so far:  New RAM, new CPUs, new NICs (problem seemed to gohJ > away after this, now it's back), more cooling (very cool now), shut down7 > Diskeeper, Undelete, McAfee.  Problem is still there.  >tH > Repair efforts soon:  New video card, replace NICs with Intel, replace( > motherboard, replace whole damn thing. >v >  >d >c   ------------------------------  % Date: Thu, 11 May 2000 15:11:34 -0500s) From: "John E. Malmberg" <wb8tyw@qsl.net>2< Subject: Re: Suggest a better file serving solution than NT?. Message-ID: <shm4keikcp153@corp.supernews.com>  < Gord Coulman <nospam_gcoulman@ccinet.ab.ca> wrote in message3 news:RfDS4.9238$%u6.495514@news1.telusplanet.net...iJ > I know this is a bit off topic, but my primary NT file server is driving meI > nuts with unexplained system hangs and I need to repair/replace it withqL > something approaching the reliability of my OpenVMS machine.  I am open toL > all suggestions, not just another NT box, although the clients are all WinL > 98 and other NT servers, which narrows things a bit.  I have run Pathworks. > in the past, but I'm not going back there...  H Do not judge the current versions of Pathworks by the previous versions.K Pathworks 6.0x and later integrate smoothly with Windows NT.  (Strong Hint:-I Put them in their own resource domain with no accounts that trusts the NTn account domain.)  J Pathworks Server 6.0x and later no longer requires any special software on the clients.  E However it does appear for some reason that Pathworks may give slowerr= performance than NT based on ancedotal reports on comp.os.vmsf  K > Present system: custom built, NT4.0 SP6A, ASUS dual PIII/600 1GB ECC RAM,.K > 9GB mirrored system disk, 140 GB RAID using 18GB Seagate 7200 RPM drives,wJ > Ultra wide Mylex 3ch RAID controller with battery backup, dual redundantF > power supply, dual 3COM 780 load balancing NICs, Diskeeper (latest), McAfee6 > (latest), Undelete (latest), ATI PCI 2MB video card.  D > Services:  PDC, file services only (print, backup, and application services > on different servers)M  I 1st sanity check:  Make sure that the logged in profile does not have any L external network connections (file and print shares) mapped to other serversE on a WAN.  You would not believe what a small network bottleneck will. silently do to a server.  B > Environment:  about 200 users in a semi-isolated location, heavy
 multimediaE > file i/o.  Typical CPU usage below 30% during peak hours.  Switcheda 100Mbitt > Ethernet (3Com).  9 Make sure that your ethernet duplex settings are correct.l  D > Symptoms:  becomes unresponsive.  Needs power-off reset to reboot. HappensaJ > every couple of days at random intervals.  No blue screen, no entries inJ > event log.  No entries in Mylex log.  Desktop freezes, usually including > mouse.  K I would recommend having some network monitoring equipment handy, and checki% the counters on your networking hubs.l  5 You may be having some intermittant network problems.t  J Do not worry too much about what perfmon says.  You have a dual processor,F and the some of the counters are not processor interlocked.  Not quiteK suitable for random number generation though.  I was not able to get a list = of what counters could be relied on, so good luck if you can.e  K > Repair efforts so far:  New RAM, new CPUs, new NICs (problem seemed to gorJ > away after this, now it's back), more cooling (very cool now), shut down7 > Diskeeper, Undelete, McAfee.  Problem is still there.e   Search Technet.e  1 Call Microsoft, and all of your hardware vendors.c  - Use the resource kit to turn off a processor.o   -John  wb8tyw@qsl.network   ------------------------------  % Date: Thu, 11 May 2000 15:13:51 -0500i) From: "John E. Malmberg" <wb8tyw@qsl.net>i< Subject: Re: Suggest a better file serving solution than NT?/ Message-ID: <shm4on2ikcp151@corp.supernews.com>g  D If you have M$soft SMS, check to see if packages are scheduled to be) delivered at any time around these hangs.k   -John  wb8tyw@qsl.network   ------------------------------  # Date: Thu, 11 May 2000 20:15:58 GMTn/ From: Hans.Bachner@altavista.net (Hans Bachner) < Subject: Re: Suggest a better file serving solution than NT?* Message-ID: <391b1444.7653324@news.aon.at>  P "Gord Coulman" <nospam_gcoulman@ccinet.ab.ca> wrote on Thu, 11 May 2000 18:48:17 GMT:   <snip> >  I have run Pathworksn- >in the past, but I'm not going back there...h  C How far in the past? Maybe you should give Advanced Server a try...e  P Samba with 200 clients might have performance problems - I don't have first handL experience, but have heard several times that it's a great system in a small$ network, but doesn't scale too well.    : ---------------- speaking only for myself ---------------- Hans Bachner Compaq Computer Austria.+ Compaq Customer Services - Software Support  E-Mail: Hans.Bachner@compaq.comw   ------------------------------  # Date: Thu, 11 May 2000 23:54:54 GMT 3 From: "Gord Coulman" <nospam_gcoulman@ccinet.ab.ca>i< Subject: Re: Suggest a better file serving solution than NT?9 Message-ID: <iLHS4.9332$%u6.505026@news1.telusplanet.net>m  I Thanks for the input so far.  The NT box crashed three times today.  I amIJ switching all important services over to another NT box tonight and I just! changed out the video card, FWIW.h  J I hate to just change out components and try to fix this by the process ofK elimination, but without any kind of crash dump or log entries, that's what:K I'm reduced to.  Next is the motherboard.  I'm not looking forward to that,gH since NT positively hates having the motherboard changed.  Will keep you
 posted....   Gord.    ------------------------------  % Date: Thu, 11 May 2000 20:28:07 -0500 , From: "Glenn C. Everhart" <Everhart@GCE.com>< Subject: Re: Suggest a better file serving solution than NT?' Message-ID: <391B17D7.6CB030E5@GCE.com>e   Dan Sugalski wrote:e; Speeds running SAMBA will vary considerably. The oplocks inM> Samba 2.0.3 should make it faster by far than the old version.; Also the tricks one uses to speed writing in VMS will help.c/ The frag avoider is one. Tuning RMS is another.r   > 0 > At 06:48 PM 5/11/00 +0000, Gord Coulman wrote:N > >I know this is a bit off topic, but my primary NT file server is driving meJ > >nuts with unexplained system hangs and I need to repair/replace it withM > >something approaching the reliability of my OpenVMS machine.  I am open to M > >all suggestions, not just another NT box, although the clients are all Win M > >98 and other NT servers, which narrows things a bit.  I have run Pathworksh/ > >in the past, but I'm not going back there...m > 6 > * VMS running NFS with NFS clients on the NT systems > * VMS running SAMBAu > * Anything else running SAMBAo > M > It wouldn't surprise me if a PalmPilot running Linux with a SAMBA client isoI > more reliable than an NT box, though there's the issue of storage spacei
 > there... > J > However, as many folks will (or at least should, in the interest of fullM > disclosure) point out, NT *is* damn stable as a file/print serving platformmK > if that's all that particular box is doing. If you have a pure file/print J > machine falling over dead with any regularity then you've probably got a > hardware problem.  > H > Don't let this stop you from using it as an excuse to yank the NT box, > though... :-)e > - >                                         Dann > N > ----------------------------------------------------------------------------N > Dan Sugalski                          General and VMS-specific perl training > dan@sidhe.orgi@ >                                       Mail me for more details   ------------------------------  # Date: Thu, 11 May 2000 18:35:33 GMTa8 From: Veli =?iso-8859-1?Q?K=F6rkk=F6?= <korkko@decus.fi> Subject: Re: System Boot Hangs.t( Message-ID: <391AEC31.925A3563@decus.fi>  D What was the system disk on VAX 6000? If the system is not clusteredB and the system was local (in the sense of RA disk  behind KDB50 or= KDM70 controller vs anything in DSSI or behind HSC/HSJ), theni$ maybe you have SCSSYSTEMID set to 0.  B In this case you cannot boot from DSSI disk. In order to boot fromC DSSI disk (as well anything behind CI) one needs SCSSYSTEMID set tor NON-ZERO value.x  6 What are actual messages seen during the boot attempt?   _velit   David B Sneddon wrote: > & > "Samson, Hugh (PiC at Alcoa)" wrote: > >n
 > > Folks, > > O > > Thanks for the replies, but I'm still making no further progress re booting  > > the 4200.. > >mK > > 1). The stabackit kit was built in the normal manner, NO files had beene( > > deleted that should have been there.M > > 2). I did actually use "USE DEFAULT", not "SET DEFAULT" at the chevrons -o > > sorry, a typo...D > > 3). Restore command was "Backup/image/log $1$MIA5:DIA0_IMAGE.BCK > > $1$DIA1112:".  > M > > 4). The restore finished with a succesfull message, both with and without- > > restoring the pagefile.  > F > You couldn't restore it without the pagefile and have it work.  ThatD > would require a non-image restore which would be unlikely to boot. > 8 > What are the hardware configurations of BOTH machines? > * > > 5). The 6610 was not a cluster member.M > > 6). The pagefile on the 6610 was located on the system disk, so it is not- > > waiting for disk mounts. > >o3 > > ** Insert purely personal opinion disclaimer **u > >- > > Hugh Samson- > >- >  > --
 > Regards, > Dave.-K > -------------------------------------------------------------------------lK > David B Sneddon (dbs)  OpenVMS Systems Programmer   dbsneddon@bigpond.com6K > DBS software at ...   http://www.users.bigpond.com/dbsneddon/software.htm>K > "Life is what happens to you while you're busy making other plans" Lennonp   ------------------------------  % Date: Thu, 11 May 2000 22:30:59 -0400f& From: Mickalide <mickalide@empire.net>* Subject: Re: Thanks Hoff (re SDL),  but...* Message-ID: <391B6CE3.3044FF8B@empire.net>  1 The CMS SDL files are now provided with CMS v4.0.-   -Jim-e   Hoff Hoffman wrote:8  { > In article <X%yS4.59511$WF.3320525@bgtnsc04-news.ops.worldnet.att.net>, "John Nixon" <jorlnixon@worldnet.att.net> writes:gO > :Why do we need to rely on SDL from the FREEWARE disk to make a product whicht" > :we bought (CMS) work correctly? >d/ >   Good question.  I don't have a good answer.d >nK > :Isn't there a way to get the SDL functionality from the VMS that we paidp > :for?h >.F >   I would encourage a formal request to the Customer Support Center. >n? >   I have informally passed the request along to the CMS team.i > I >   Some background: I asked the CMS team to provide the SDL file a whileiI >   back as I was not fond of the (official) CMS-supported and documented H >   technique for resolving the CMS symbols, as this involves explicitlyG >   linking against the CMSSHR image to pull in the symbols.  I greatlyoK >   prefer using the more typical include files for the symbol definitions,lM >   and these are not available with CMS -- which is why I asked for the SDL.2 >vG > :Can you tell me where the SDL functionality is documented in the VMSi > :documentation?n >fE >   It is not.  SDL is documented only on the OpenVMS Freeware.  (ThecE >   SDL/NOPARSE tool is latent on the OpenVMS kit, but is itself also  >   not documented.) >ME >   Some background: OpenVMS Engineering is dependent on SDL for most-E >   of the definitions needed to build OpenVMS itself, as well as thes6 >   creation of the customer-visible definition files. > J > :But I do thank you for pointing me to the freeware disk for now.  I was2 > :completely stuck trying to help the programmer. >l6 >   That CMS "requires" SDL was also a surprise to me. >nP >  --------------------------- pure personal opinion ---------------------------N >    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------    Date: 11 May 2000 21:51:14 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>:& Subject: Re: the latest billybox virusH Message-ID: <y4hfc4dfwt.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  ; Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:   A > Unless the system manager has purposefully loosened security oni5 > your VMS system, ordinary users cannot read SYSUAF.e  ( Reading RIGHTLIST will do in most cases.   	Jan   ------------------------------    Date: 11 May 2000 22:06:59 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>c& Subject: Re: the latest billybox virusH Message-ID: <y4em78df6k.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  ) "Bill Todd" <billtodd@foo.mv.com> writes:u  N > My fault:  I should have said "Microsoft could help by setting up a *second*N > intermediate cautionary dialog box...", since there's already one containingC > a virus warning that you have to pass through before executing anl
 > attachment.l  I But that box is almost useless, because it's analogous to "The Little BoytK that Called `Wolf'." Doesn't is have a "permanent disable" tick-box? If so,dJ most users will tick it after the third or fifth time it comes up in total4 disregard for the contents of file it is looking at.   	Jan   ------------------------------   Date: 11 May 2000 19:14:02 GMT* From: helbig@astro.rug.nl (Phillip Helbig) Subject: threads. Message-ID: <8ff0pq$77b$3@info.service.rug.nl>  I This is completely unrelated to my other two posts (at least, the reason gD for asking is completely unrelated).  Where can I find a beginner's E introduction to threaded programming on VMS (if possible in Fortran)?1   ------------------------------  % Date: Thu, 11 May 2000 15:50:55 -0400:" From: Dan Sugalski <dan@sidhe.org> Subject: Re: threads8 Message-ID: <4.3.1.0.20000511154657.00eb02c0@24.8.96.48>  0 At 07:14 PM 5/11/00 +0000, Phillip Helbig wrote:I >This is completely unrelated to my other two posts (at least, the reasonaD >for asking is completely unrelated).  Where can I find a beginner'sF >introduction to threaded programming on VMS (if possible in Fortran)?   Well, _Guide to DECThreads_ B (http://www.openvms.compaq.com:8000/72final/6493/6101pro.html) is C reasonably good, though I don't know I'd go so far as to call it a eK beginner's introduction. Since threads on VMS use the POSIX interface, you  I might want to try O'Reilly's _Pthreads programming_ or _Programming with hF POSIX Threads_ from Addison-Wesley. (Both have the advantage of being  written by DEC folks, FWIW)d  N They've got a C slant, but pretty much everything threaded does at this point.   					Dan  I --------------------------------------"it's like this"-------------------i2 Dan Sugalski                          even samurai? dan@sidhe.org                         have teddy bears and event;                                       teddy bears get drunka   ------------------------------  % Date: Thu, 11 May 2000 22:09:16 +0200v> From: "Jean-Franois Marchal" <jean-francois.marchal@x9000.fr>9 Subject: Urgent PCSI problem while updating DCLTABLES.EXEI2 Message-ID: <8ff3ur$6e9$1@s2.feed.news.oleane.net>  4 Here is a log of 2 unsucessfull patch installations.0 Each of them fails while updating DCLTABLES.EXE.B The last install has leaved a DCLTABLES.EXE file with 0 blocks ... I would appreciate any help ...t   Jean-Franois Marchalt X9000 - LYON    : $ product install vms721_pcsi /source=SYS$SYSROOT:[SYSMGR]  ( The following product has been selected:E     DEC AXPVMS VMS721_PCSI V1.0            Patch (maintenance update)    Do you want to continue? [YES]    Configuration phase starting ...  J You will be asked to choose options, if any, for each selected product and for8A any products that may be installed to satisfy software dependencye
 requirements.A  5 DEC AXPVMS VMS721_PCSI V1.0: OpenVMS V7.2-1 PCSI V1.0e  7 * This product does not have any configuration options.e   Execution phase starting ...  7 The following product will be installed to destination:tH     DEC AXPVMS VMS721_PCSI V1.0            DISK$SX9010_SYS:[VMS$COMMON.]   Portion done: 0%...10%...30%5 %PCSI-I-PRCOUTPUT, output from subprocess follows ...-  %SYSTEM-W-ENDOFFILE, end of file; %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual  address=FFFFFFFFFFFF& FFFF, PC=0000000000032D4C, PS=0000001B  = %PCSI-E-MODREPLERR, error replacing module PRODUCT in library  DISK$SX9010_SYS:[S$ YS0.SYSCOMMON.][SYSLIB]DCLTABLES.EXEI -SYSTEM-F-ACCVIO, access violation, reason mask=!XB, virtual address=!XH,k PC=!XH , PS=!XL" %PCSI-E-OPFAILED, operation failedH Terminating is strongly recommended.  Do you want to terminate? [YES] no Portion done: 50%...90%...100%  ) The following product has been installed:-E     DEC AXPVMS VMS721_PCSI V1.0            Patch (maintenance update).  5 DEC AXPVMS VMS721_PCSI V1.0: OpenVMS V7.2-1 PCSI V1.0e  -     VMS721_PCSI-V0100 Release notes availablem    6         Release notes for the VMS721_PCSI V1.0 kit are.          available in the SYS$HELP: directory.  H %PCSIUI-I-COMPWERR, operation completed after explicit continuation from errors $ product show utility: POLYCENTER Software Installation utility version: V7.2-1085     Product Configuration File (PCF) support level: 1h3     Product Description File (PDF) support level: 5 ,     Product Text File (PTF) support level: 2 $ product sho histL ----------------------------------- ----------- ----------- ---------------- ----I PRODUCT                             KIT TYPE    OPERATION   DATE AND TIMEeL ----------------------------------- ----------- ----------- ---------------- ----G DEC AXPVMS VMS721_PCSI V1.0         Patch       Install     11-MAY-2000r 21:39:55G DEC AXPVMS VMS721_PCSI V1.0         Patch       Install     11-MAY-2000r 21:37:42G DEC AXPVMS CCAGENTRA200 V2.2-503    Full LP     Install     11-APR-2000  21:11:23G DEC AXPVMS SWCC V2.1-133            Full LP     Install     11-APR-2000  21:04:29G DEC AXPVMS ODL V2.1                 Platform    Install     04-JAN-2000  07:36:50G CPQ AXPVMS MOZILLA C5.0             Full LP     Install     22-DEC-1999n 17:56:00G DEC AXPVMS BNU V2.1                 Full LP     Install     14-DEC-1999r 16:21:58G DEC AXPVMS HYPERHELP V5.1-2         Full LP     Install     14-DEC-1999p 16:21:58G DEC AXPVMS NS_NAV_EXPORT V3.0-3     Full LP     Install     14-DEC-1999e 16:21:58G DEC AXPVMS ODL V2.1                 Platform    Install     14-DEC-1999f 16:21:58G DEC AXPVMS DFU V2.6                 Full LP     Install     13-OCT-1999t 21:26:04G DEC AXPVMS FORRTL V7.2-1            Full LP     Install     21-SEP-1999r 17:34:03G DEC AXPVMS FORTRAN V7.2-1           Full LP     Install     21-SEP-1999t 17:34:03G DEC AXPVMS DECNET_OSI V7.2-1        Full LP     Install     21-SEP-1999h 14:35:13G DEC AXPVMS DWMOTIF V1.2-5           Full LP     Install     21-SEP-1999c 14:35:13G DEC AXPVMS OPENVMS V7.2-1           Platform    Install     21-SEP-1999a 14:35:13G DEC AXPVMS TCPIP V5.0-10            Full LP     Install     21-SEP-1999. 14:35:13G DEC AXPVMS VMS V7.2-1               Oper System Install     21-SEP-1999  14:35:13L ----------------------------------- ----------- ----------- ---------------- ----   18 items found $g3 $ product instal VMS721_UPDATE /source=sys$manager:   ( The following product has been selected:E     DEC AXPVMS VMS721_UPDATE V1.0          Patch (maintenance update)o    Do you want to continue? [YES] y    Configuration phase starting ...  J You will be asked to choose options, if any, for each selected product and forbA any products that may be installed to satisfy software dependencye
 requirements.i  9 DEC AXPVMS VMS721_UPDATE V1.0: OpenVMS V7.2-1 UPDATE V1.0   7 * This product does not have any configuration options.a  0     Installing this patch kit requires a reboot.    ?     The images in this kit will not fully take effect until thee?     system  is rebooted.  Compaq  strongly  recommends that youe?     reboot your system immediately after installation  of  thisJ     kit.  B     If you have other nodes in your VMS cluster, they must also be@     rebooted in order to make use of the new image(s).  If it isC     not possible or convenient to reboot the entire cluster at this--     time, a rolling re-boot may be performed.y    "     Do you want to continue? [YES]   Execution phase starting ...  7 The following product will be installed to destination:nH     DEC AXPVMS VMS721_UPDATE V1.0          DISK$SX9010_SYS:[VMS$COMMON.]H %PCSI-I-RETAIN, file [SYSEXE]PCSI$MAIN.EXE was not replaced because file from kit t has lower generation numberNK %PCSI-I-RETAIN, module PRODUCT was not replaced because module from kit hasl lowe r generation numberTH %PCSI-I-RETAIN, file [SYSLIB]DCLTABLES.TEMPLATE was not replaced because file fru" om kit has lower generation numberL %PCSI-I-RETAIN, file [SYSLIB]PCSI$SHR.EXE was not replaced because file from kit0  has lower generation numberL %PCSI-I-RETAIN, file [SYSUPD]PCSI.CLD was not replaced because file from kit has   lower generation number  . Portion done: 0%...10%...20%...30%...40%...50%5 %PCSI-I-PRCOUTPUT, output from subprocess follows ...-  %SYSTEM-W-ENDOFFILE, end of file; %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual  address=FFFFFFFFFFFF& FFFF, PC=0000000000032D4C, PS=0000001B  < %PCSI-E-MODREPLERR, error replacing module BACKUP in library DISK$SX9010_SYS:[SY.# S0.SYSCOMMON.][SYSLIB]DCLTABLES.EXEiI -SYSTEM-F-ACCVIO, access violation, reason mask=!XB, virtual address=!XH,s PC=!XH , PS=!XL" %PCSI-E-OPFAILED, operation failedE Terminating is strongly recommended.  Do you want to terminate? [YES]o no* Portion done: 60%...70%...80%...90%...100%  ) The following product has been installed:tE     DEC AXPVMS VMS721_UPDATE V1.0          Patch (maintenance update)o  9 DEC AXPVMS VMS721_UPDATE V1.0: OpenVMS V7.2-1 UPDATE V1.0w  /     VMS721_UPDATE-V0100 Release notes availablem    8         Release notes for the VMS721_UPDATE V1.0 kit are.         available in the SYS$HELP: dirrectory.    %     Cover Letters for superseded kits-    C         Cover Letters for kits superseded by the VMS721_UPDATE V1.0t&         kit are contained in the file:  9                 VMS721_UPDATE-V0100_SUPERSEDED_CVRLET.TXT1  +         located in the SYS$HELP: directory.     H %PCSIUI-I-COMPWERR, operation completed after explicit continuation from errors $f) $ dir sys$library:dcl*.exe /date/size=alle   Directory SYS$COMMON:[SYSLIB]   = DCLTABLES.EXE;100          0/0        11-MAY-2000 21:26:57.75r= DCLTABLES.EXE;99        1024/1026     11-MAY-2000 21:24:38.91I= DCLTABLES.EXE;98        1024/1026     27-APR-2000 18:34:07.13    ------------------------------  % Date: Fri, 12 May 2000 00:03:54 +0200a> From: "Jean-Franois Marchal" <jean-francois.marchal@x9000.fr>= Subject: Re: Urgent PCSI problem while updating DCLTABLES.EXEr2 Message-ID: <8ffalo$8h6$1@s2.feed.news.oleane.net>   The pcsi file was corrupted ...h= I downloaded a new kit, restored the previous DCLTABLES file, . and everything as been reinstalled correctly !, Thanks to Henry wou suggested the corruption% as being the cause of the problem ...A   Jean-Franois Marchalu X9000 - LYON    I "Jean-Franois Marchal" <jean-francois.marchal@x9000.fr> wrote in messagex, news:8ff3ur$6e9$1@s2.feed.news.oleane.net...6 > Here is a log of 2 unsucessfull patch installations.2 > Each of them fails while updating DCLTABLES.EXE.D > The last install has leaved a DCLTABLES.EXE file with 0 blocks ...! > I would appreciate any help ...i >  > Jean-Franois Marchalr > X9000 - LYON >l > < > $ product install vms721_pcsi /source=SYS$SYSROOT:[SYSMGR] >a* > The following product has been selected:G >     DEC AXPVMS VMS721_PCSI V1.0            Patch (maintenance update)  >   > Do you want to continue? [YES] >n" > Configuration phase starting ... >-L > You will be asked to choose options, if any, for each selected product and > for C > any products that may be installed to satisfy software dependency  > requirements.  > 7 > DEC AXPVMS VMS721_PCSI V1.0: OpenVMS V7.2-1 PCSI V1.0- >-9 > * This product does not have any configuration options.o >5 > Execution phase starting ... >>9 > The following product will be installed to destination:2J >     DEC AXPVMS VMS721_PCSI V1.0            DISK$SX9010_SYS:[VMS$COMMON.] >c > Portion done: 0%...10%...30%7 > %PCSI-I-PRCOUTPUT, output from subprocess follows ...o" > %SYSTEM-W-ENDOFFILE, end of file= > %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual  > address=FFFFFFFFFFFF( > FFFF, PC=0000000000032D4C, PS=0000001B > ? > %PCSI-E-MODREPLERR, error replacing module PRODUCT in libraryE > DISK$SX9010_SYS:[S& > YS0.SYSCOMMON.][SYSLIB]DCLTABLES.EXEK > -SYSTEM-F-ACCVIO, access violation, reason mask=!XB, virtual address=!XH,) > PC=!XH
 > , PS=!XL$ > %PCSI-E-OPFAILED, operation failedJ > Terminating is strongly recommended.  Do you want to terminate? [YES] no  > Portion done: 50%...90%...100% > + > The following product has been installed: G >     DEC AXPVMS VMS721_PCSI V1.0            Patch (maintenance update)A >"7 > DEC AXPVMS VMS721_PCSI V1.0: OpenVMS V7.2-1 PCSI V1.0. > / >     VMS721_PCSI-V0100 Release notes availableM >: >08 >         Release notes for the VMS721_PCSI V1.0 kit are0 >          available in the SYS$HELP: directory. >uJ > %PCSIUI-I-COMPWERR, operation completed after explicit continuation from > errors > $ product show utility< > POLYCENTER Software Installation utility version: V7.2-1087 >     Product Configuration File (PCF) support level: 1m5 >     Product Description File (PDF) support level: 5.. >     Product Text File (PTF) support level: 2 > $ product sho histL > ----------------------------------- ----------- ----------- -------------- -- > ----K > PRODUCT                             KIT TYPE    OPERATION   DATE AND TIME-L > ----------------------------------- ----------- ----------- -------------- -- > ----I > DEC AXPVMS VMS721_PCSI V1.0         Patch       Install     11-MAY-2000e
 > 21:39:55I > DEC AXPVMS VMS721_PCSI V1.0         Patch       Install     11-MAY-2000 
 > 21:37:42I > DEC AXPVMS CCAGENTRA200 V2.2-503    Full LP     Install     11-APR-2000 
 > 21:11:23I > DEC AXPVMS SWCC V2.1-133            Full LP     Install     11-APR-2000c
 > 21:04:29I > DEC AXPVMS ODL V2.1                 Platform    Install     04-JAN-2000 
 > 07:36:50I > CPQ AXPVMS MOZILLA C5.0             Full LP     Install     22-DEC-1999n
 > 17:56:00I > DEC AXPVMS BNU V2.1                 Full LP     Install     14-DEC-1999l
 > 16:21:58I > DEC AXPVMS HYPERHELP V5.1-2         Full LP     Install     14-DEC-1999s
 > 16:21:58I > DEC AXPVMS NS_NAV_EXPORT V3.0-3     Full LP     Install     14-DEC-1999 
 > 16:21:58I > DEC AXPVMS ODL V2.1                 Platform    Install     14-DEC-1999m
 > 16:21:58I > DEC AXPVMS DFU V2.6                 Full LP     Install     13-OCT-1999t
 > 21:26:04I > DEC AXPVMS FORRTL V7.2-1            Full LP     Install     21-SEP-1999m
 > 17:34:03I > DEC AXPVMS FORTRAN V7.2-1           Full LP     Install     21-SEP-1999 
 > 17:34:03I > DEC AXPVMS DECNET_OSI V7.2-1        Full LP     Install     21-SEP-1999o
 > 14:35:13I > DEC AXPVMS DWMOTIF V1.2-5           Full LP     Install     21-SEP-1999R
 > 14:35:13I > DEC AXPVMS OPENVMS V7.2-1           Platform    Install     21-SEP-1999i
 > 14:35:13I > DEC AXPVMS TCPIP V5.0-10            Full LP     Install     21-SEP-1999w
 > 14:35:13I > DEC AXPVMS VMS V7.2-1               Oper System Install     21-SEP-1999t
 > 14:35:13L > ----------------------------------- ----------- ----------- -------------- -- > ---- >( > 18 items found > $o5 > $ product instal VMS721_UPDATE /source=sys$manager:  >o* > The following product has been selected:G >     DEC AXPVMS VMS721_UPDATE V1.0          Patch (maintenance update)e > " > Do you want to continue? [YES] y >s" > Configuration phase starting ... >dL > You will be asked to choose options, if any, for each selected product and > fornC > any products that may be installed to satisfy software dependency  > requirements.r > ; > DEC AXPVMS VMS721_UPDATE V1.0: OpenVMS V7.2-1 UPDATE V1.0- >-9 > * This product does not have any configuration options.f >S2 >     Installing this patch kit requires a reboot. >z >dA >     The images in this kit will not fully take effect until the:A >     system  is rebooted.  Compaq  strongly  recommends that youuA >     reboot your system immediately after installation  of  this 
 >     kit. >@D >     If you have other nodes in your VMS cluster, they must also beB >     rebooted in order to make use of the new image(s).  If it isE >     not possible or convenient to reboot the entire cluster at thiss/ >     time, a rolling re-boot may be performed.l >  >m$ >     Do you want to continue? [YES] >- > Execution phase starting ... >09 > The following product will be installed to destination:aJ >     DEC AXPVMS VMS721_UPDATE V1.0          DISK$SX9010_SYS:[VMS$COMMON.]J > %PCSI-I-RETAIN, file [SYSEXE]PCSI$MAIN.EXE was not replaced because file	 > from ki@ > t has lower generation numbertI > %PCSI-I-RETAIN, module PRODUCT was not replaced because module from kite hasa > lowe > r generation numberiJ > %PCSI-I-RETAIN, file [SYSLIB]DCLTABLES.TEMPLATE was not replaced because	 > file fro$ > om kit has lower generation numberI > %PCSI-I-RETAIN, file [SYSLIB]PCSI$SHR.EXE was not replaced because fileh from > kitl >  has lower generation numberJ > %PCSI-I-RETAIN, file [SYSUPD]PCSI.CLD was not replaced because file from kitm > hasm >  lower generation number >h0 > Portion done: 0%...10%...20%...30%...40%...50%7 > %PCSI-I-PRCOUTPUT, output from subprocess follows ...2" > %SYSTEM-W-ENDOFFILE, end of file= > %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtuals > address=FFFFFFFFFFFF( > FFFF, PC=0000000000032D4C, PS=0000001B >(> > %PCSI-E-MODREPLERR, error replacing module BACKUP in library > DISK$SX9010_SYS:[SYe% > S0.SYSCOMMON.][SYSLIB]DCLTABLES.EXEiK > -SYSTEM-F-ACCVIO, access violation, reason mask=!XB, virtual address=!XH,e > PC=!XH
 > , PS=!XL$ > %PCSI-E-OPFAILED, operation failedG > Terminating is strongly recommended.  Do you want to terminate? [YES]b > no, > Portion done: 60%...70%...80%...90%...100% >H+ > The following product has been installed:oG >     DEC AXPVMS VMS721_UPDATE V1.0          Patch (maintenance update)e >e; > DEC AXPVMS VMS721_UPDATE V1.0: OpenVMS V7.2-1 UPDATE V1.0  >g1 >     VMS721_UPDATE-V0100 Release notes availableG >e > : >         Release notes for the VMS721_UPDATE V1.0 kit are0 >         available in the SYS$HELP: dirrectory. >  >w' >     Cover Letters for superseded kitsr >i >oE >         Cover Letters for kits superseded by the VMS721_UPDATE V1.0t( >         kit are contained in the file: >_; >                 VMS721_UPDATE-V0100_SUPERSEDED_CVRLET.TXT  >e- >         located in the SYS$HELP: directory.  >W > J > %PCSIUI-I-COMPWERR, operation completed after explicit continuation from > errors > $n+ > $ dir sys$library:dcl*.exe /date/size=all' >i > Directory SYS$COMMON:[SYSLIB]  >a? > DCLTABLES.EXE;100          0/0        11-MAY-2000 21:26:57.75 ? > DCLTABLES.EXE;99        1024/1026     11-MAY-2000 21:24:38.91 ? > DCLTABLES.EXE;98        1024/1026     27-APR-2000 18:34:07.13- >- >  >a   ------------------------------  % Date: Thu, 11 May 2000 20:18:06 +0100r. From: mpatt644 <mpatt644@netscapeonline.co.uk>8 Subject: Re: What's a fair price for a TZ877 autoloader?4 Message-ID: <391B076E.B434A1DA@netscapeonline.co.uk>  	 Not much.a  F 	It Depends if you're buying or selling. I'm in the UK and in NovemberA '99 I had 4 of these, with lots of other bits & pieces  (VAX6610,oE VAX6620, 8 HSJ40'S, 2 HSJ50's , numerous RZ26 & 28's, and a couple of B TZ887's) to get rid of. 2 resellers  I approached wouldn't give meF anything for it, eventually I found someone to take the lot for 8000,D but that was only because they specifically wanted the HSJ50's and I refused to split the stuff up.        Kent Rankin wrote: > N >         Just trying to find out what a good price for a TZ877 autoloader is. > N >         Basically a 7-tape DLT III autoloader by DEC, in case anyone reading > isn't familiar.. > 9 >                                                 Thanks,n= >                                                 Kent Rankind > G > P.S. - An email'ed carbon copy would be wonderful if at all possible.    ------------------------------  % Date: Thu, 11 May 2000 20:25:42 -0500-, From: "Glenn C. Everhart" <Everhart@GCE.com> Subject: Re: Which VAX to buy?' Message-ID: <391B1746.269C544F@GCE.com>e  > I agree that the 4000-60 is a good Vax to buy. However I would= suggest looking into cheap alphas also. A dec 3000LX like thee= ones offered here a few days back is faster and runs the fullB' 64 bit apps. VMS runs on more than VAX.v Glenn Everhart  ) yyyc186.illegaltospam@flashcom.net wrote:S > 5 > In <3917E220.FCB75242@bornholm-gym.dk>, on 05/11/00rE >    at 07:19 AM, Jonas Nielsen <Jonas-Nielsen@bornholm-gym.dk> said:0 > K > I would recommend the 4000-60 if it has any disks.  The 3100 will be slow2K > enough to make you go postal when running DEC Windows.  Besides, the SCSIV? > will be proprietary DEC SCSI of old, not SCSI-II or SCSI-III.o > F > I got my 3500 for carrying it away.  Then I spent $5k putting biggerF > disks, 15 user DEC BASIC license on it and a fresh open VMS license. >  > Roland >  > >Hi theret > D > >Im a young UNIX-freak, who has become a bit interested in the VMSK > >operating system :-). So, i want a VAX and i have been offered some usedp	 > >VAXen:  > $ > >Digital VAXstation 3100/M76 - SPX > >Digital VAXstation 4000 - 60F5 > >Digital VAXserver 3100 (Scsi disk Ext. SCSI udtag)- > 8 > >and a Digital Storage Expansion (99 MB Disk + CD-ROM) > F > >Basically, i just want to learn OpenVMS, DECwindows a little bit ofJ > >system administration, and perhaps some programming. I thought it wouldE > >be a good idea to buy the Storage Expansion as well, so that i cann@ > >install programs and newer releases of OpenVMS on the system. > K > >So i ask you guys, (since i know nothing about VAX), which configuration5/ > >would you suggest? The VS4000 or VS3100-M76?:@ > >And finally and very important :-), what should i pay for it? > ) > >Any help would be greatly appreciated!  >  > >Kind Regards, > >Jonas Nielsen
 > >Denmark >  > --= > -----------------------------------------------------------1F > yyyc186@flashcom.net              To Respond delete ".illegaltospam"8 >                             MR/2 Internet Cruiser 1.52: >                             For a Microsoft free univers= > -----------------------------------------------------------9   ------------------------------  # Date: Thu, 11 May 2000 18:59:25 GMT 0 From: "Terry C. Shannon" <shannon@world.std.com>+ Subject: Re: Wildfire and the future of VMSt& Message-ID: <FuEsA8.4zs@world.std.com>  ' <jlahman@LTVSteel.com> wrote in messager2 news:852568DC.005765FF.00@notesnta.LTVSteel.com...H > I just received an invitation to attend the Wildfire announcement next week.uD > However, as I read the articles linked to the invitation, I became	 concerned I > since these articles only talk about how Wildfire will enhance Compaq's  positionK > in the Unix market.  There was no mention of VMS (even though VMS runs on  > wildfire). >nI > So, what is the future of VMS on wildfire?  When I attend this wildfireS< > announcement next week, will I only hear about Tru64 Unix? >-  J I should hope not. Bear in mind that WildFire is the platform that OpenVMS Galaxy was designed for!   ------------------------------  % Date: Thu, 11 May 2000 16:01:51 -0400 * From: Clair Grant <grant@evms.zko.dec.com>+ Subject: Re: Wildfire and the future of VMSc0 Message-ID: <391AD96F.65DB5E00@evms.zko.dec.com>   Paul Sture wrote:e > 3 > Do you have any comments on the following articledR > http://www.theregister.co.uk/000511-000008.html "Compaq prevented from using the > Wildfire name"?S  A "WildFire" is a project name internal to the company. It is not aeG product name. The product name is GSxxx; xxx depends on the size of thee machine.     --   Clair Grantg VMS Exec Group Project Leadera COMPAQ Computer Corporationt 110 Spit Brook Rd. Nashua, NH  03062o   ------------------------------  % Date: Thu, 11 May 2000 16:09:30 -0400 * From: Clair Grant <grant@evms.zko.dec.com>+ Subject: Re: Wildfire and the future of VMS 0 Message-ID: <391ADB3A.690B3639@evms.zko.dec.com>   jlahman@LTVSteel.com wrote:o > E > > I have seen most of the official announcement material and VMS isb > > prominently mentioned. > M > Thanks for your response.  Am I to assume that VMS will be mentioned at the  > wildfire announcement?   Yes.     --   Clair GrantS VMS Exec Group Project LeaderS COMPAQ Computer CorporationP 110 Spit Brook Rd. Nashua, NH  03062E   ------------------------------  % Date: Thu, 11 May 2000 17:31:36 -0400P0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>+ Subject: Re: Wildfire and the future of VMSn/ Message-ID: <391B26AC.3AAE657B@vl.videotron.ca>M   re: VMS and wildfire.c  L If the event is designed to attract the media, then the presentation will beN focused on the technology and unix. They will most certaintly mention LINUX inK there just to help boost the Compaq stock price. They would not mention VMSmE much because that would make Compaq look bad since to the media it is3! pointless to push a dead product.o  N If the event is to be aimed at customers, then VMS may not be taboo and CompaqI may in fact include it without being ashamed of talking about VMS. But atF* best, VMS and UNIX will get equal billing.    H If this is a media event and VMS is featured prominently, then I will beG impressed. If CNN talks about it in its business news, I will be doubly J impressed. If CNN not only talks about how Alpha is faster than Intel, butK also how reliable VMS is, I may have a heart attack and die a happy man :-)a :-) :-) :-) :-) :-)o   ------------------------------  # Date: Fri, 12 May 2000 03:46:17 GMTs7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>h+ Subject: Re: Wildfire and the future of VMSP- Message-ID: <391B7F9A.1ED764E5@earthlink.net>M   Clair Grant wrote: >  > jlahman@LTVSteel.com wrote:e > > P > > I just received an invitation to attend the Wildfire announcement next week.P > > However, as I read the articles linked to the invitation, I became concernedT > > since these articles only talk about how Wildfire will enhance Compaq's positionM > > in the Unix market.  There was no mention of VMS (even though VMS runs onn > > wildfire). > >oK > > So, what is the future of VMS on wildfire?  When I attend this wildfire > > > announcement next week, will I only hear about Tru64 Unix? > >tB > > Again, I am greatly disappointed in the way Compaq treats VMS. > C > I have seen most of the official announcement material and VMS is  > prominently mentioned.   To quote my 5th grade teacher:   "Be specific, cite examples".-   -- - David J. Dachterar dba DJE Systems:" http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/e   ------------------------------   End of INFO-VAX 2000.264 ************************