0 INFO-VAX	Thu, 10 Jan 2002	Volume 2002 : Issue 17      Contents:5 =?ks_c_5601-1987?B?SW5mby1WQVi01CC+yLPnx8+9yrTPse4/?=  Alpha Itanium Advertisment Re: Alpha Itanium Advertisment Re: Alpha Itanium Advertisment RE: Alpha Itanium Advertisment Re: Alpha Itanium Advertisment Apache CSWS POST not working... P Re: BLISS pros and cons, was: Re: historical evidence of what went	 wrong  at DEP Re: BLISS pros and cons, was: Re: historical evidence of what went	 wrong  at DEP Re: BLISS pros and cons, was: Re: historical evidence of what went  wrong   at DP Re: BLISS pros and cons, was: Re: historical evidence of what went  wrong   at DP Re: BLISS pros and cons, was: Re: historical evidence of what went  wrong   at DP Re: BLISS pros and cons, was: Re: historical evidence of what went wrong   at DEP Re: BLISS pros and cons, was: Re: historical evidence of what went wrong   at DEP Re: BLISS pros and cons, was: Re: historical evidence of what went wrong  at DECP Re: BLISS pros and cons, was: Re: historical evidence of what wentwrong at DEC a> Re: Buffer Overflows - again Was: (Re: Congratulations for the/ BUG: duplicated msg when booting 7.3 first time ! Clustering two PWS600 via a BA356 % RE: Clustering two PWS600 via a BA356 % Re: Clustering two PWS600 via a BA356 % Re: Clustering two PWS600 via a BA356 % Re: Clustering two PWS600 via a BA356 % Re: Clustering two PWS600 via a BA356 2 Re: Compaq still tries to spin Alphacide both ways2 Re: Compaq still tries to spin Alphacide both ways2 Re: Compaq still tries to spin Alphacide both ways= Re: Compaq's Board of Directors & their value to shareholders  Re: csws_php and Multinet? DCL (F$GETQUI) Problem Re: DCL (F$GETQUI) Problem Re: DCL whish list Re: DCL whish list Re: DCL wish list (of 1 item)  Re: DECpc AXP 150 and VMS. Re: DECpc AXP 150 and VMS. Re: DECpc AXP 150 and VMS. Re: DECpc AXP 150 and VMS. Re: DECpc AXP 150 and VMS. Re: DECWindows problem Re: DECWindows problemP Re: Does anyone know a way of getting version 7.2  to support the Oxygen vx1 graP Re: Does anyone know a way of getting version 7.2  to support the Oxygen vx1 gra Getting DEC ADA 3.5A to work  Re: Getting DEC ADA 3.5A to work  Re: Getting DEC ADA 3.5A to work  Re: Getting DEC ADA 3.5A to work. Re: Hey Intel, VMS is your ticket to high end!1 Re: historical evidence of what went wrong at DEC 1 Re: historical evidence of what went wrong at DEC 1 Re: historical evidence of what went wrong at DEC 1 Re: historical evidence of what went wrong at DEC 1 Re: historical evidence of what went wrong at DEC 1 Re: historical evidence of what went wrong at DEC 1 Re: historical evidence of what went wrong at DEC 1 Re: historical evidence of what went wrong at DEC 1 Re: historical evidence of what went wrong at DEC 1 Re: historical evidence of what went wrong at DEC 1 Re: historical evidence of what went wrong at DEC 1 Re: historical evidence of what went wrong at DEC 1 Re: historical evidence of what went wrong at DEC 1 Re: historical evidence of what went wrong at DEC 1 Re: historical evidence of what went wrong at DEC 1 Re: historical evidence of what went wrong at DEC 1 Re: historical evidence of what went wrong at DEC 1 Re: historical evidence of what went wrong at DEC 1 Re: historical evidence of what went wrong at DEC 1 Re: historical evidence of what went wrong at DEC 1 Re: historical evidence of what went wrong at DEC 1 Re: historical evidence of what went wrong at DEC 5 Re: How to create the Flight object in DECnet Phase V 5 Re: How to create the Flight object in DECnet Phase V 5 Re: How to create the Flight object in DECnet Phase V 0 Re: HP admits it will kill VMS if merger suceeds0 Re: HP admits it will kill VMS if merger suceeds0 Re: HP admits it will kill VMS if merger suceeds0 Re: HP admits it will kill VMS if merger suceeds HP, imaging and VMS  Re: HP, imaging and VMS  Re: HP, imaging and VMS " Re: OpenVMS 7.2 - Slow Queman ????4 Re: OpenVMS on PWS-a (was: Re: Alpha 21164 and 7.3?)5 Re: OT: Sun To Drop/Delay Intel Support For Solaris 9 5 Re: OT: Sun To Drop/Delay Intel Support For Solaris 9 5 Re: OT: Sun To Drop/Delay Intel Support For Solaris 9 5 Re: OT: Sun To Drop/Delay Intel Support For Solaris 9  Reel to Reel recorder question: Re: Samsung ordered to pay $73.5 million for mismanagement: Re: Samsung ordered to pay $73.5 million for mismanagement; Re: Steve Jobs not affraid to sell his "different" products ; Re: Steve Jobs not affraid to sell his "different" products ; Re: Steve Jobs not affraid to sell his "different" products ; Re: Steve Jobs not affraid to sell his "different" products P Re: Sv: Sv: Sv: Younger recruits versus experienced veterans ( was Re:     The dP Re: Sv: Sv: Sv: Younger recruits versus experienced veterans ( was Re:     The dP Re: Sv: Sv: Sv: Younger recruits versus experienced veterans ( was Re:     The dP Re: Sv: Sv: Sv: Younger recruits versus experienced veterans ( was Re: The demis/ TCP/IP 5.1 and DHCP and Internet/Cable provider 3 Re: TCP/IP 5.1 and DHCP and Internet/Cable provider # TCPIP programming: $QIO vs C socket H Re: UWSSs and NOSHRIMG Calling out to other shareables (Not in cookbook)B Re: VAX 4000/100 with Correctable Memory Errors resulting in crash Re: VAX in a VT-103?( Re: VMS Marketing For the General Public( Re: VMS Marketing For the General Public( Re: VMS Marketing For the General Public7 Re: Want to follow IBM model Capellas?  IBM quits pc's! # Re: what is future of VMS and alpha # Re: what is future of VMS and alpha # Re: what is future of VMS and alpha " Re: who else got the VMS brochure?" Re: who else got the VMS brochure?" Re: who else got the VMS brochure?" Re: who else got the VMS brochure?" Re: who else got the VMS brochure?; Re: [tired] PWS600au does not e7 e6 e5... anymore and hangs   F ----------------------------------------------------------------------  % Date: Thu, 10 Jan 2002 11:14:41 +0900 C From: =?ks_c_5601-1987?B?wMzHwbiuxN0=?= <webmaster@efreecall.co.kr> > Subject: =?ks_c_5601-1987?B?SW5mby1WQVi01CC+yLPnx8+9yrTPse4/?=9 Message-ID: <iss.5ad0.3c3cf8fc.52f7e.1@mx2.east.saic.com>   , This is a multi-part message in MIME format.  + ------=_NextPart_000_0117_01C0F10A.93A14C00  Content-Type: text/plain;  	charset="ks_c_5601-1987" ! Content-Transfer-Encoding: base64   H vsiz58fPvLy/5CCwx7CtvcTHsCDA/LmuILzux8649CB3d3cuZWZyZWVjYWxsLmNvLmtyIMDUH tM+02S4NCg0Kx+O29L74wMwguN7Az8C7ILq4s7uw1LXHvu4gwcu828fVtM+02S4gsc3Hz8DHH IMDMuN7Az8HWvNK0wiDAzsXNs92758DMxq4gudcgsNS9w8bHwLvF68fYIMiuurjHz7+0vcC0H z7TZLiANCsD6yPEgvO7Hzrj0sPogwPq3xcfRILChsN3AxyDBwcC6ILvzx7DAuyCxzcfPsrIgH vNKws8fPsO3A2iC43sDPwLsgurizwLTPtNkuDQq89r3FsMW6zrimIL/4x8+9w7TCILrQwLogH v6mx4rimILStt6/B1r3KvcO/wA0KICAgICAgICAgICAgICAgwMzHwbiuxN0gu+fAzMauKGh0H dHA6Ly93d3cuZWZyZWVjYWxsLmNvLmtyKbfOILnZt86wob3Dt8G46SC+xrehIMDMuczB9rimH IMWsuK/Hz7y8v+QuDQogDQogICAgICAgICAgICAgICAgICAgICAgIMGmx7DAzLnMwfa4piDFH rLivIMfPvcO46SC87sfOuPTAxyDH2LTnIMTas8q3ziC52bfOIL+ssOG1y7TPtNkgICAgDQogH ICAgDQoNCiAgIA0Kx/e057D8uK6/oSC1+7bzIMWrurTAzLXJILz2tbUgwNvAurq0wMwgILXJH ILz2tbUgwNa0wiC057SiDQrAzMfBuK7E3cDMIMfUsrIgx9W0z7TZDQogICAgIA0KDQogICANH CrjtwvcgwM618L/AtenAxyC68b7gDQogICANCg0KICAgDQrA/MXrt8kgILHZurvA+8DOIMf3H tOfBtsD9DQogICAgIA0KtOe0orq0ILnXILDtx/e+0CAgwfW788C7IL/PyK0gx8+0wr3Ex7DAH zLjnILTntKLAxyDH1bq0wfXAuLfOILi5wMwgu/2x4rTCILnps7vA5bXuIL7IurQgIL/PyK2/H obW1ICC22b7us60gvcTHsMDUtM+02SANCg0KIA0KICAgDQq5zLeuv/i80sDHIMCvvcfAuyC4H t77GILTZs+KwoyC4t8f7tPggw+nA5cC7IMiwvLrIrSC9w8WwsO0gwM69triwIMfVvLq/oSDHH yr/kx9EgseLDyrmwwfrAuyDBprD4x8+/qSDH97TnwLsgvsjBpMD7wLi3ziDA+sfPvcPFsLTCH ICC9xMewwNS0z7TZDQogICAgIA0KIA0KICAgIA0KDQogICANCsSht+Gx4rCjILHmsO0gtNm9H wyDA57nfx8+x4rW1ICC9rL/uILmrwbsNCsDPwdbAz7i4IMX1wNrHz7y8v+QhDQogICAgIA0KH DQogICANCrnZt7m5zLzSICAgN8DPwMcgIMDnud+++LTCIMSht+EgvuC80w0KDQogICAgIDZ+H N8DPIMH2vNPA+8DOIMSnwPy/5Ln9wLi3ziDH4sjEIMDnud+1ySCwobTJvLrAzCC4xb/sIMjxH udrHz7jnLCAgvcnH0SCwobfBv/LB9bD6ILnfs7+79bChIMO5u+e/68jEILHXILTZwL2zr7fOH IMfYvNIgtcu0z7TZDQq52be5ucy80rTCICCxubChsPjAzr3Dx+ggsMu757HisPwgS0FUUkm/H obytILmrwbsgyK+w5r+hILTrx9EgILmrwbux1b+hILTrx9EgwPrH17y6wLsgvcPH6MfRILDhH sPogMTAwJSCx1bvnwMcgud/AsMDMIMDOwfa1x8H2IL7KtMK02bTCIL3Dx+iw4bD6uKYgvvK+H +r3AtM+02S4NCiAgICAgIA0KIA0KICAgIA0KDQogICANCr3Jx9EgsOa/7CC48bz7se7B9iC+H 0b7GsKUgvPYgwNa0wiAgw7W9xA0KwMzHwbiuxN3AzCC4u7n6tbbAuyDAzL/rx9EgyLmx4sD7H wM4gwabHsMC7ILzSsLMgx9W0z7TZDQogICAgIA0KDQogICANCiDB9rrAICAgtb/Ax7q4sKjAH xyCz67rAueYouLu5+sH9KcC7ICDAzL/rx9Egw7W9xCDH2LzSDQogICAgILW/wMe6uLCowMwgH IMD8x8+0wiCz67rAueYouLu5+sH9KcDHIMi/tMkhISENCsH2usDAuiCwocC7v6G8rSCw3L/vH u+fAzL+hIMH2uK676r+hvK0gw7zD68fRICC9xbyxx9Egw7W/rL/4t+G4uMC7ILvnv+vHz7+pH ICCwx7CtwfXB+CzDvMH6sLO8sS4gv7W+57q4sd7AzCC1x7TCIL3Ex7DA1LTPtNkuDQoNCiAgH ICAgIA0KIA0KICAgIA0KDQogICC4tr7guri02SCy97HiIMj7tem02bTCILTjueguLi4NCrTjH uei/zcDHIMD8wO/AuyC8scb3x8+/qSDA2r3FsPogILChwbfAxyCwx7CtwLsgwfbFsL3KvcO/H wC4gICAgIA0KDQogICANCrTjueggILW2ILvns8my2yAgw7yzu8DHICC047notbbAuyC49rnbH wLi3ziC/z8D8ILnow+IhISEgDQogICAgICC047notba757PJstvAuiDI7b+swLi3ziDAzsfRH ILj2vNPAxyC047notbbAuyC067zSuq/AuLfOICC/z8D8ILnow+IgvcPFsLnHt8694SCx3bTcH IMf2u/PAuyC++L7WsO0gtOO56LimIMOzwL0gx8e/7LTCILvntvfDs7ezILTjuei4wMC7ILvzH vce9w8TRILTjuei4piCy97DUx8+0wiCx2b/4waawxb/4uK63ziC/rLG4LCDBpsG2tcggwabHH sMDMwNS0z7TZLg0KDQogICAgICANCiANCiAgICANCg0KICAgDQq/qby6utC16cDHILDtuc4uH Lg0KwMzHwbiuxN3AzCDH1LKyICDH1bTPtNkuDQogICAgIA0KDQogICANCsTdtvOw1SAgIMfHH us6z68itILjYw+e28yEhDQogICANCg0KICAgxb6+2MitwMzGriAgseK5zCzA4sa8LMHWsdmxH +g0KICAgICAgICAgICAgICAgICAgILDtuc4gILOhDQogICAgIMfHus6z68itwMcgIL/4wM7AH uiANCsfHus6zuyDE3bbzsNXAx7CovNIhDQogxN2287DVwMwgILTnvcXAxyDA/sC9wLsgwfbEH 0bXluLO0z7TZLiAgILHiucwssMu59ry4LMHWsdmx+izA4sa8Li4uLg0KwMzBpiAgsKjD38H2H ILi7sO0gDQq5zLnpIMD8ua68uiDFqbiyDQrFvr7YyK3AzMaut84gsssgwOLAuLy8v+QhIQ0K DQogICANCiANCg==  + ------=_NextPart_000_0117_01C0F10A.93A14C00  Content-Type: text/html; 	charset="ks_c_5601-1987" ! Content-Transfer-Encoding: base64   H DQo8c2NyaXB0IGxhbmd1YWdlPSJKYXZhU2NyaXB0Ij4NCjwhLS0NCmZ1bmN0aW9uIG5hX3JlH c3RvcmVfaW1nX3NyYyhuYW1lLCBuc2RvYykNCnsNCiAgdmFyIGltZyA9IGV2YWwoKG5hdmlnH YXRvci5hcHBOYW1lID09ICdOZXRzY2FwZScpID8gbnNkb2MrJy4nK25hbWUgOiAnZG9jdW1lH bnQuYWxsLicrbmFtZSk7DQogIGlmIChuYW1lID09ICcnKQ0KICAgIHJldHVybjsNCiAgaWYgH KGltZyAmJiBpbWcuYWx0c3JjKSB7DQogICAgaW1nLnNyYyAgICA9IGltZy5hbHRzcmM7DQogH ICAgaW1nLmFsdHNyYyA9IG51bGw7DQogIH0gDQp9DQoNCmZ1bmN0aW9uIG5hX3ByZWxvYWRfH aW1nKCkNCnsgDQogIHZhciBpbWdfbGlzdCA9IG5hX3ByZWxvYWRfaW1nLmFyZ3VtZW50czsNH CiAgaWYgKGRvY3VtZW50LnByZWxvYWRsaXN0ID09IG51bGwpIA0KICAgIGRvY3VtZW50LnByH ZWxvYWRsaXN0ID0gbmV3IEFycmF5KCk7DQogIHZhciB0b3AgPSBkb2N1bWVudC5wcmVsb2FkH bGlzdC5sZW5ndGg7DQogIGZvciAodmFyIGk9MDsgaSA8IGltZ19saXN0Lmxlbmd0aDsgaSsrH KSB7DQogICAgZG9jdW1lbnQucHJlbG9hZGxpc3RbdG9wK2ldICAgICA9IG5ldyBJbWFnZTsNH CiAgICBkb2N1bWVudC5wcmVsb2FkbGlzdFt0b3AraV0uc3JjID0gaW1nX2xpc3RbaSsxXTsNH CiAgfSANCn0NCg0KZnVuY3Rpb24gbmFfY2hhbmdlX2ltZ19zcmMobmFtZSwgbnNkb2MsIHJwH YXRoLCBwcmVsb2FkKQ0KeyANCiAgdmFyIGltZyA9IGV2YWwoKG5hdmlnYXRvci5hcHBOYW1lH ID09ICdOZXRzY2FwZScpID8gbnNkb2MrJy4nK25hbWUgOiAnZG9jdW1lbnQuYWxsLicrbmFtH ZSk7DQogIGlmIChuYW1lID09ICcnKQ0KICAgIHJldHVybjsNCiAgaWYgKGltZykgew0KICAgH IGltZy5hbHRzcmMgPSBpbWcuc3JjOw0KICAgIGltZy5zcmMgICAgPSBycGF0aDsNCiAgfSANH Cn0NCg0KZnVuY3Rpb24gbmFfb3Blbl93aW5kb3cobmFtZSwgdXJsLCBsZWZ0LCB0b3AsIHdpH ZHRoLCBoZWlnaHQsIHRvb2xiYXIsIG1lbnViYXIsIHN0YXR1c2Jhciwgc2Nyb2xsYmFyLCByH ZXNpemFibGUpDQp7DQogIHRvb2xiYXJfc3RyID0gdG9vbGJhciA/ICd5ZXMnIDogJ25vJzsNH CiAgbWVudWJhcl9zdHIgPSBtZW51YmFyID8gJ3llcycgOiAnbm8nOw0KICBzdGF0dXNiYXJfH c3RyID0gc3RhdHVzYmFyID8gJ3llcycgOiAnbm8nOw0KICBzY3JvbGxiYXJfc3RyID0gc2NyH b2xsYmFyID8gJ3llcycgOiAnbm8nOw0KICByZXNpemFibGVfc3RyID0gcmVzaXphYmxlID8gH J3llcycgOiAnbm8nOw0KICB3aW5kb3cub3Blbih1cmwsIG5hbWUsICdsZWZ0PScrbGVmdCsnH LHRvcD0nK3RvcCsnLHdpZHRoPScrd2lkdGgrJyxoZWlnaHQ9JytoZWlnaHQrJyx0b29sYmFyH PScrdG9vbGJhcl9zdHIrJyxtZW51YmFyPScrbWVudWJhcl9zdHIrJyxzdGF0dXM9JytzdGF0H dXNiYXJfc3RyKycsc2Nyb2xsYmFycz0nK3Njcm9sbGJhcl9zdHIrJyxyZXNpemFibGU9JytyH ZXNpemFibGVfc3RyKTsNCn0NCg0KLy8tLT4NCjwvc2NyaXB0Pg0KDQo8YmFzZSBocmVmPSJoH dHRwOi8vd3d3LmVmcmVlY2FsbC5jby5rci9pbWcvIj4NCjxib2R5IE9uTG9hZD0ibmFfcHJlH bG9hZF9pbWcoZmFsc2UsICdzaG9wcGluZy5qcGcnLCAnbWFpbmltZy5qcGcnKTsiPg0KPHAgH YWxpZ249ImxlZnQiIHN0eWxlPSJsaW5lLWhlaWdodDoxMDAlOyBtYXJnaW4tdG9wOjA7IG1hH cmdpbi1ib3R0b206MDsiPjxmb250IGNvbG9yPSJibGFjayI+PHNwYW4gc3R5bGU9ImZvbnQtH c2l6ZToxMHB0OyI+vsiz58fPvLy/5CANCrDHsK29xMewIMD8ua4gvO7Hzrj0PC9mb250PjxmH b250IGNvbG9yPSJibHVlIj4gPGEgaHJlZj0iamF2YXNjcmlwdDpuYV9vcGVuX3dpbmRvdygnH d2luJywgJ2h0dHA6Ly93d3cuZWZyZWVjYWxsLmNvLmtyJywgMCwgMCwgODAwLCA2MDAsIDEsH IDEsIDEsIDEsIDEpOyI+PHU+d3d3LmVmcmVlY2FsbC5jby5rcjwvdT48L2E+IA0KPC9mb250H Pjxmb250IGNvbG9yPSJibGFjayI+wNS0zzwvc3Bhbj602S48L2ZvbnQ+PC9wPg0KPGhyIGFsH aWduPSJsZWZ0IiB3aWR0aD0iNjAwIiBjb2xvcj0ibGltZSIgc3R5bGU9ImxpbmUtaGVpZ2h0H OjEwMCU7IG1hcmdpbi10b3A6MDsgbWFyZ2luLWJvdHRvbTowOyI+DQo8cCBhbGlnbj0ibGVmH dCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEwMCU7IG1hcmdpbi10b3A6MDsgbWFyZ2luLWJvdHRvH bTowOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+PGZvbnQgY29sb3I9ImJsYWNrH Ij48aW1nIHNyYz0ibG9nby5naWYiIHdpZHRoPSIyMDAiIGhlaWdodD0iNjAiIGJvcmRlcj0iH MCI+PC9zcGFuPjwvZm9udD48L3A+DQo8aHIgY29sb3I9ImxpbWUiIGFsaWduPSJsZWZ0IiB3H aWR0aD0iNjAwIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTAwJTsgbWFyZ2luLXRvcDowOyBtYXJnH aW4tYm90dG9tOjA7Ij4NCjxwIGFsaWduPSJsZWZ0IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTAwH JTsgbWFyZ2luLXRvcDowOyBtYXJnaW4tYm90dG9tOjA7Ij48c3BhbiBzdHlsZT0iZm9udC1zH aXplOjlwdDsiPsfjtvS++MDMILjewM/AuyC6uLO7sNS1x77uIMHLvNvH1bTPtNkuILHNx8/AH xyDAzLjewM/B1rzStMIgwM7FzbPdu+fAzMauILnXILDUvcPGx8C7xevH2CDIrrq4x8+/tL3AH tM+02S4gPGJyPiDA+sjxIA0KvO7Hzrj0sPogwPq3xcfRILChsN3AxyDBwcC6ILvzx7DAuyCxH zcfPsrIgvNKws8fPsO3A2iC43sDPwLsgurizwLTPtNkuPGJyPrz2vcWwxbrOuKYgDQq/+MfPH vcO0wiC60MC6IDxhIGhyZWY9Im1haWx0bzpyZWZ1c2UwNjE1QGhvdG1haWwuY29tIj6/qbHiH PC9hPrimILStt6/B1r3KvcO/wDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmH bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmH bmJzcDs8dT48Zm9udCBjb2xvcj0iIzkxQURGQyI+wMzHwbiuxN0gDQq758DMxq4oaHR0cDovH L3d3dy5lZnJlZWNhbGwuY28ua3Ipt84gudm3zrChvcO3wbjpIL7Gt6EgwMy5zMH2uKYgxay4H r8fPvLy/5C48L2ZvbnQ+PC91Pjxicj48L3NwYW4+PGEgaHJlZj0iamF2YXNjcmlwdDpuYV9vH cGVuX3dpbmRvdygnd2luJywgJ2h0dHA6Ly93d3cuZWZyZWVjYWxsLmNvLmtyJywgMCwgMCwgH ODAwLCA2MDAsIDEsIDEsIDEsIDEsIDEpOyIgT25Nb3VzZU91dD0ibmFfcmVzdG9yZV9pbWdfH c3JjKCd0b3BpbWFnJywgJ2RvY3VtZW50JykiIE9uTW91c2VPdmVyPSJuYV9jaGFuZ2VfaW1nH X3NyYygndG9waW1hZycsICdkb2N1bWVudCcsICdzaG9wcGluZy5qcGcnLCB0cnVlKTsiPjxpH bWcgc3JjPSJtYWluaW1nLmpwZyIgd2lkdGg9IjYwMCIgaGVpZ2h0PSIxNjAiIGJvcmRlcj0iH MCIgbmFtZT0idG9waW1hZyI+PC9hPiZuYnNwOzxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzH cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzH cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzH cDsmbmJzcDs8Zm9udCBjb2xvcj0iIzkxQURGQyI+PHU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6H ZTo5cHQ7Ij7BpsewwMy5zMH2uKYgDQrFrLivIMfPvcO46SC87sfOuPTAxyDH2LTnIMTas8q3H ziC52bfOIL+ssOG1y7TPtNk8L3U+PC9mb250Pjwvc3Bhbj48dGFibGUgYm9yZGVyPSIwIiB3H aWR0aD0iNjAwIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTAwJTsgbWFyZ2luLXRvcDowOyBtYXJnH aW4tYm90dG9tOjA7Ij4NCiAgICA8dHI+DQogICAgICAgIDx0ZCB3aWR0aD0iNTk0IiBoZWlnH aHQ9IjE1IiBjb2xzcGFuPSIyIj4NCiAgICAgICAgICAgIDxwIHN0eWxlPSJsaW5lLWhlaWdoH dDoxMDAlOyBtYXJnaW4tdG9wOjA7IG1hcmdpbi1ib3R0b206MDsiPiZuYnNwOzwvcD4NCjwvH dGQ+DQogICAgPC90cj4NCiAgICA8dHI+DQogICAgICAgIDx0ZCB3aWR0aD0iMTcxIiBoZWlnH aHQ9IjE1Ij4NCiAgICAgICAgICAgIDxwPjxhIGhyZWY9ImphdmFzY3JpcHQ6bmFfb3Blbl93H aW5kb3coJ3dpbicsICdodHRwOi8vd3d3LmVmcmVlY2FsbC5jby5rci9oZWFsdGgxLmh0bScsH IDAsIDAsIDgwMCwgNjAwLCAxLCAxLCAxLCAxLCAxKTsiPjxpbWcgc3JjPSJiYW5uZXIxLmdpH ZiIgd2lkdGg9IjE3MCIgaGVpZ2h0PSI0MCIgYm9yZGVyPSIwIj48L2E+PC9wPg0KICAgICAgH ICA8L3RkPg0KICAgICAgICA8dGQgd2lkdGg9IjQxNSIgaGVpZ2h0PSIxNSI+DQogICAgICAgH ICAgICA8cD48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzAyRDVCRiI+x/e057D8uK6/oSC1+7bzH IMWrurTAzLXJILz2tbUgwNvAurq0wMwgDQogICAgICAgICAgICC1ySC89rW1IMDWtMIgtOe0H ojxicj7AzMfBuK7E3cDMIMfUsrIgx9W0z7TZPC9mb250PjwvcD4NCiAgICAgICAgPC90ZD4NH CiAgICA8L3RyPg0KPC90YWJsZT4NCjx0YWJsZSBib3JkZXI9IjEiIGNlbGxzcGFjaW5nPSIwH IiB3aWR0aD0iNTk2IiBib3JkZXJjb2xvcj0iIzA5RUVENyIgYm9yZGVyY29sb3JkYXJrPSJ3H aGl0ZSIgYm9yZGVyY29sb3JsaWdodD0iIzA5RUVENyI+DQogICAgPHRyPg0KICAgICAgICA8H dGQgd2lkdGg9IjExMSIgaGVpZ2h0PSI5MiIgcm93c3Bhbj0iMiI+DQogICAgICAgICAgICA8H cD48YSBocmVmPSJqYXZhc2NyaXB0Om5hX29wZW5fd2luZG93KCd3aW4nLCAnaHR0cDovL3d3H dy5lZnJlZWNhbGwuY28ua3IvaGVhbHRoMS04Lmh0bScsIDAsIDAsIDgwMCwgNjAwLCAxLCAxH LCAxLCAxLCAxKTsiPjxpbWcgc3JjPSJhLXMxLTMuanBnIiB3aWR0aD0iMTEwIiBoZWlnaHQ9H IjExMCIgYm9yZGVyPSIwIj48L2E+PC9wPg0KICAgICAgICA8L3RkPg0KICAgICAgICA8dGQgH d2lkdGg9IjE3OCIgaGVpZ2h0PSI0Ij4NCiAgICAgICAgICAgIDxwPjxhIGhyZWY9ImphdmFzH Y3JpcHQ6bmFfb3Blbl93aW5kb3coJ3dpbicsICdodHRwOi8vd3d3LmVmcmVlY2FsbC5jby5rH ci9oZWFsdGgxLTguaHRtJywgMCwgMCwgODAwLCA2MDAsIDEsIDEsIDEsIDEsIDEpOyI+PGI+H PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyI+PGZvbnQgY29sb3I9ImJsdWUiPrjtwvc8H L2ZvbnQ+PC9zcGFuPjwvYT48Zm9udCBzaXplPSIyIj4mbmJzcDs8L2I+PC9mb250PjxzcGFuH IHN0eWxlPSJmb250LXNpemU6OXB0OyI+wM618L/AtenAxyC68b7gPC9zcGFuPjwvcD4NCiAgH ICAgICAgPC90ZD4NCiAgICAgICAgPHRkIHdpZHRoPSIxMTEiIGhlaWdodD0iOTIiIHJvd3NwH YW49IjIiPg0KICAgICAgICAgICAgPHA+PGEgaHJlZj0iamF2YXNjcmlwdDpuYV9vcGVuX3dpH bmRvdygnd2luJywgJ2h0dHA6Ly93d3cuZWZyZWVjYWxsLmNvLmtyL2hlYWx0aDEtOS5odG0nH LCAwLCAwLCA4MDAsIDYwMCwgMSwgMSwgMSwgMSwgMSk7Ij48aW1nIHNyYz0iYS1zMS00LmpwH ZyIgd2lkdGg9IjExMCIgaGVpZ2h0PSIxMTAiIGJvcmRlcj0iMCI+PC9hPjwvcD4NCiAgICAgH ICAgPC90ZD4NCiAgICAgICAgPHRkIHdpZHRoPSIxNzkiIGhlaWdodD0iNCI+DQogICAgICAgH ICAgICA8cD48YSBocmVmPSJqYXZhc2NyaXB0Om5hX29wZW5fd2luZG93KCd3aW4nLCAnaHR0H cDovL3d3dy5lZnJlZWNhbGwuY28ua3IvaGVhbHRoMS05Lmh0bScsIDAsIDAsIDgwMCwgNjAwH LCAxLCAxLCAxLCAxLCAxKTsiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdDsiPjxGH T05UIGNvbG9yPSJibHVlIj7A/MXrt8k8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpH emU6MTBwdDsiPiANCiAgICAgICAgICAgIDwvc3Bhbj48L2I+PC9GT05UPjxzcGFuIHN0eWxlH PSJmb250LXNpemU6OXB0OyI+sdm6u8D7wM4gx/e058G2wP08L3NwYW4+PC9wPg0KICAgICAgH ICA8L3RkPg0KICAgIDwvdHI+DQogICAgPHRyPg0KICAgICAgICA8dGQgd2lkdGg9IjE3OCI+H DQogICAgICAgICAgICA8cD48Rk9OVCBjb2xvcj0iYmx1ZSI+PHNwYW4gc3R5bGU9ImZvbnQtH c2l6ZTo5cHQ7Ij6057SiurQgudcgsO3H977QIA0KICAgICAgICAgICAgwfW78zwvRk9OVD7AH uyC/z8itIMfPtMK9xMewwMy45yAgtOe0osDHIMfVurTB9cC4t84guLnAzCC7/bHitMIguemzH u8Dlte4gvsi6tCANCiAgICAgICAgICAgIL/PyK2/obW1IA0KICAgICAgICAgICAgttm+7rOtH IL3Ex7DA1LTPtNkgPGJyPjxicj4mbmJzcDs8L3NwYW4+PC9wPg0KICAgICAgICA8L3RkPg0KH ICAgICAgICA8dGQgd2lkdGg9IjE3OSI+DQogICAgICAgICAgICA8cD48c3BhbiBzdHlsZT0iH Zm9udC1zaXplOjlwdDsiPrnMPEZPTlQgY29sb3I9IzAwMDAwMD63rr/4vNLAxyDAr73HwLsgH uLe+xiC02bPisKMguLfH+7T4IDwvRk9OVD48Rk9OVCBjb2xvcj0iYmx1ZSI+w+nA5TwvRk9OH VD48Rk9OVCBjb2xvcj0jMDAwMDAwPsC7IDwvRk9OVD48Rk9OVCBjb2xvcj0iYmx1ZSI+yLC8H usitPC9GT05UPjxGT05UIGNvbG9yPSMwMDAwMDA+IL3DxbCw7SDAzr22uLAgx9W8ur+hIA0KH x8q/5MfRILHiw8q5sMH6wLsgwaaw+DwvRk9OVD7Hz7+pIDxmb250IGNvbG9yPSJibHVlIj7HH 97TnPC9mb250PsC7IDxmb250IGNvbG9yPSJibHVlIj6+yMGkwPs8L2ZvbnQ+wLi3ziA8Zm9uH dCBjb2xvcj0iYmx1ZSI+wPrHzzwvZm9udD69w8WwtMIgDQogICAgICAgICAgICC9xMewwNS0H z7TZPC9zcGFuPjwvcD4NCiAgICAgICAgPC90ZD4NCiAgICA8L3RyPg0KPC90YWJsZT4NCjx0H YWJsZSBib3JkZXI9IjAiIHdpZHRoPSI2MDAiPg0KICAgIDx0cj4NCiAgICAgICAgPHRkIHdpH ZHRoPSI1OTQiIGhlaWdodD0iMTUiIGNvbHNwYW49IjIiPg0KICAgICAgICAgICAgPHA+Jm5iH c3A7PC9wPg0KPC90ZD4NCiAgICA8L3RyPg0KICAgIDx0cj4NCiAgICAgICAgPHRkIHdpZHRoH PSIxNzEiIGhlaWdodD0iMTUiPg0KICAgICAgICAgICAgPHA+PGEgaHJlZj0iamF2YXNjcmlwH dDpuYV9vcGVuX3dpbmRvdygnd2luJywgJ2h0dHA6Ly93d3cuZWZyZWVjYWxsLmNvLmtyL2hlH YWx0aDUuaHRtJywgMCwgMCwgODAwLCA2MDAsIDEsIDEsIDEsIDEsIDEpOyI+PGltZyBzcmM9H ImJhbm5lcjUuZ2lmIiB3aWR0aD0iMTcwIiBoZWlnaHQ9IjQwIiBib3JkZXI9IjAiPjwvYT48H L3A+DQogICAgICAgIDwvdGQ+DQogICAgICAgIDx0ZCB3aWR0aD0iNDE1IiBoZWlnaHQ9IjE1H Ij4NCiAgICAgICAgICAgIDxwPjxmb250IHNpemU9IjIiIGNvbG9yPSIjRUVBOTA4Ij7EobfhH seKwoyCx5rDtILTZvcMgwOe538fPseK1tSANCiAgICAgICAgICAgIL2sv+4guavBuzxicj7AH z8HWwM+4uCDF9cDax8+8vL/kITwvZm9udD48L3A+DQogICAgICAgIDwvdGQ+DQogICAgPC90H cj4NCjwvdGFibGU+DQo8dGFibGUgYm9yZGVyPSIxIiBjZWxsc3BhY2luZz0iMCIgd2lkdGg9H IjU5NiIgYm9yZGVyY29sb3I9IiNFRUE5MDgiIGJvcmRlcmNvbG9yZGFyaz0id2hpdGUiIGJvH cmRlcmNvbG9ybGlnaHQ9IiNFRUE5MDgiPg0KICAgIDx0cj4NCiAgICAgICAgPHRkIHdpZHRoH PSIxMTEiIHJvd3NwYW49IjIiPg0KICAgICAgICAgICAgPHA+PGEgaHJlZj0iamF2YXNjcmlwH dDpuYV9vcGVuX3dpbmRvdygnd2luJywgJ2h0dHA6Ly93d3cuZWZyZWVjYWxsLmNvLmtyL2hlH YWx0aDUtOC5odG0nLCAwLCAwLCA4MDAsIDYwMCwgMSwgMSwgMSwgMSwgMSk7Ij48aW1nIHNyH Yz0ici1zMS0xLmpwZyIgd2lkdGg9IjExMCIgaGVpZ2h0PSIxMTAiIGJvcmRlcj0iMCI+PC9hH PjwvcD4NCiAgICAgICAgPC90ZD4NCiAgICAgICAgPHRkIHdpZHRoPSI0NzUiPg0KICAgICAgH ICAgICAgPHA+PEZPTlQgY29sb3I9I2NjMzMwMD48Qj4gPC9GT05UPjxhIGhyZWY9ImphdmFzH Y3JpcHQ6bmFfb3Blbl93aW5kb3coJ3dpbicsICdodHRwOi8vd3d3LmVmcmVlY2FsbC5jby5rH ci9oZWFsdGg1LTguaHRtJywgMCwgMCwgODAwLCA2MDAsIDEsIDEsIDEsIDEsIDEpOyI+PHNwH YW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyI+PEZPTlQgY29sb3I9IiNFRUE5MDgiPrnZt7m5H zLzSPC9GT05UPjwvYT48Rk9OVCBjb2xvcj0iYmx1ZSI+IA0KICAgICAgICAgICAgPC9zcGFuH PiZuYnNwOzwvQj48L0ZPTlQ+PEZPTlQgY29sb3I9IiNDQzMzMDAiPjxzcGFuIHN0eWxlPSJmH b250LXNpemU6OXB0OyI+N8DPwMcgDQogICAgICAgICAgICDA57nfvvi0wiDEobfhIL7gvNM8H L0ZPTlQ+PEZPTlQgY29sb3I9I2NjMzMwMD48Qj48YnI+PC9zcGFuPjwvQj48L0ZPTlQ+PC9wH Pg0KICAgICAgICA8L3RkPg0KICAgIDwvdHI+DQogICAgPHRyPg0KICAgICAgICA8dGQgd2lkH dGg9IjQ3NSI+DQogICAgICAgICAgICA8cCBhbGlnbj0ibGVmdCIgc3R5bGU9ImxpbmUtaGVpH Z2h0OjEwMCU7IG1hcmdpbi10b3A6MDsgbWFyZ2luLWJvdHRvbTowOyI+PHNwYW4gc3R5bGU9H ImZvbnQtc2l6ZTo5cHQ7Ij42fjfAzyDB9rzTwPvAziDEp8D8v+S5/cC4t84gx+LIxCDA57nfH tckgsKG0yby6wMwguMW/7CDI8bnax8+45ywgDQogICAgICAgICAgICC9ycfRILCht8G/8sH1H sPogud+zv7v1sKEgw7m757/ryMQgsdcgtNnAvbOvt84gx9i80iC1y7TPtNk8YnI+PEZPTlQgH Y29sb3I9ImJsdWUiPrnZt7m5zLzSPC9GT05UPrTCPEI+IA0KICAgICAgICAgICAgPC9CPjxmH b250IGNvbG9yPSJibHVlIj6xubChsPjAzr3Dx+ggsMu757HisPwgS0FUUkk8L2ZvbnQ+v6G8H rSC5q8G7IMivsOa/oSC068fRIA0KICAgICAgICAgICAguavBu7HVv6EgtOvH0SA8Rk9OVCANH CmNvbG9yPSJibHVlIj7A+sfXvLrAuzwvRk9OVD4gvcPH6MfRILDhsPogPEZPTlQgY29sb3I9H ImJsdWUiPjEwMCUgsdW758DHILnfwLDAzCDAzsH2tcfB9iANCr7KtMK02TwvRk9OVD60wiC9H w8fosOGw+rimIL7yvvq9wLTPtNkuPGJyPiZuYnNwOzwvc3Bhbj4gICAgICAgIDwvdGQ+DQogH ICAgPC90cj4NCjwvdGFibGU+DQo8dGFibGUgYm9yZGVyPSIwIiB3aWR0aD0iNjAwIj4NCiAgH ICA8dHI+DQogICAgICAgIDx0ZCB3aWR0aD0iNTk0IiBoZWlnaHQ9IjE1IiBjb2xzcGFuPSIyH Ij4NCiAgICAgICAgICAgIDxwPiZuYnNwOzwvcD4NCjwvdGQ+DQogICAgPC90cj4NCiAgICA8H dHI+DQogICAgICAgIDx0ZCB3aWR0aD0iMTcxIiBoZWlnaHQ9IjE1Ij4NCiAgICAgICAgICAgH IDxwPjxhIGhyZWY9ImphdmFzY3JpcHQ6bmFfb3Blbl93aW5kb3coJ3dpbicsICdodHRwOi8vH d3d3LmVmcmVlY2FsbC5jby5rci9oZWFsdGg3Lmh0bScsIDAsIDAsIDgwMCwgNjAwLCAxLCAxH LCAxLCAxLCAxKTsiPjxpbWcgc3JjPSJiYW5uZXI3LmdpZiIgd2lkdGg9IjE3MCIgaGVpZ2h0H PSI0MCIgYm9yZGVyPSIwIj48L2E+PC9wPg0KICAgICAgICA8L3RkPg0KICAgICAgICA8dGQgH d2lkdGg9IjQxNSIgaGVpZ2h0PSIxNSI+DQogICAgICAgICAgICA8cD48Zm9udCBzaXplPSIyH IiBjb2xvcj0iI0FBMDBGRiI+vcnH0SCw5r/sILjxvPux7sH2IL7RvsawpSC89iDA1rTCIA0KH ICAgICAgICAgICAgw7W9xDxicj7AzMfBuK7E3cDMILi7ufq1tsC7IMDMv+vH0SDIubHiwPvAH ziDBpsewwLsgvNKwsyDH1bTPtNk8L2ZvbnQ+PC9wPg0KICAgICAgICA8L3RkPg0KICAgIDwvH dHI+DQo8L3RhYmxlPg0KPHRhYmxlIGJvcmRlcj0iMSIgY2VsbHNwYWNpbmc9IjAiIHdpZHRoH PSI1OTYiIGJvcmRlcmNvbG9yPSIjQUEwMEZGIiBib3JkZXJjb2xvcmRhcms9IndoaXRlIiBiH b3JkZXJjb2xvcmxpZ2h0PSIjQUEwMEZGIj4NCiAgICA8dHI+DQogICAgICAgIDx0ZCB3aWR0H aD0iMTA4IiByb3dzcGFuPSIyIj4NCiAgICAgICAgICAgIDxwPjxhIGhyZWY9ImphdmFzY3JpH cHQ6bmFfb3Blbl93aW5kb3coJ3dpbicsICdodHRwOi8vd3d3LmVmcmVlY2FsbC5jby5rci9oH ZWFsdGg3LTYuaHRtJywgMCwgMCwgODAwLCA2MDAsIDEsIDEsIDEsIDEsIDEpOyI+PGltZyBzH cmM9ImctczEuanBnIiB3aWR0aD0iMTEwIiBoZWlnaHQ9IjExMCIgYm9yZGVyPSIwIj48L2E+H PC9wPg0KICAgICAgICA8L3RkPg0KICAgICAgICA8dGQgd2lkdGg9IjQ3OCI+DQogICAgICAgH ICAgICA8cD4mbmJzcDs8YSBocmVmPSJqYXZhc2NyaXB0Om5hX29wZW5fd2luZG93KCd3aW4nH LCAnaHR0cDovL3d3dy5lZnJlZWNhbGwuY28ua3IvaGVhbHRoNy02Lmh0bScsIDAsIDAsIDgwH MCwgNjAwLCAxLCAxLCAxLCAxLCAxKTsiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwH dDsiPjxmb250IGNvbG9yPSIjQUEwMEZGIj7B9rrAPC9mb250Pjwvc3Bhbj48L2E+IA0KICAgH ICAgICAgICAgJm5ic3A7PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OXB0OyI+tb/Ax7q4H sKjAxyCz67rAueYouLu5+sH9KcC7IA0KICAgICAgICAgICAgwMy/68fRIMO1vcQgx9i80jwvH c3Bhbj48L3A+DQogICAgICAgIDwvdGQ+DQogICAgPC90cj4NCiAgICA8dHI+DQogICAgICAgH IDx0ZCB3aWR0aD0iNDc4Ij4NCiAgICAgICAgICAgIDxwIGFsaWduPSJsZWZ0IiBzdHlsZT0iH bGluZS1oZWlnaHQ6MTAwJTsgbWFyZ2luLXRvcDowOyBtYXJnaW4tYm90dG9tOjA7Ij48c3BhH biBzdHlsZT0iZm9udC1zaXplOjlwdDsiPjxmb250IGNvbG9yPSJibHVlIj61v8DHuriwqDwvH Zm9udD7AzCANCiAgICAgICAgICAgIMD8x8+0wiCz67rAueYouLu5+sH9KcDHIMi/tMkhISE8H YnI+wfa6wMC6ILChwLu/obytILDcv++758DMv6Egwfa4rrvqv6G8rSDDvMPrx9EgDQogICAgH ICAgICAgICA8Zm9udCBjb2xvcj0iYmx1ZSI+vcW8scfRIMO1v6y/+LfhPC9mb250Pri4wLsgH u+e/68fPv6kgDQogICAgICAgICAgICCwx7CtwfXB+CzDvMH6sLO8sS4gv7W+57q4sd7AzCC1H x7TCIL3Ex7DA1LTPtNkuPGJyPjxicj4mbmJzcDs8L3NwYW4+ICAgICAgICA8L3RkPg0KICAgH IDwvdHI+DQo8L3RhYmxlPg0KPHRhYmxlIGJvcmRlcj0iMCIgd2lkdGg9IjYwMiI+DQogICAgH PHRyPg0KICAgICAgICA8dGQgd2lkdGg9IjU5NiIgaGVpZ2h0PSIxNSIgY29sc3Bhbj0iMiI+H DQogICAgICAgICAgICA8cD4mbmJzcDs8L3A+DQo8L3RkPg0KICAgIDwvdHI+DQogICAgPHRyH Pg0KICAgICAgICA8dGQgd2lkdGg9IjE3MSIgaGVpZ2h0PSIxNSI+DQogICAgICAgICAgICA8H cD48YSBocmVmPSJqYXZhc2NyaXB0Om5hX29wZW5fd2luZG93KCd3aW4nLCAnaHR0cDovL3d3H dy5lZnJlZWNhbGwuY28ua3IvaGVhbHRoOS5odG0nLCAwLCAwLCA4MDAsIDYwMCwgMSwgMSwgH MSwgMSwgMSk7Ij48aW1nIHNyYz0iYmFubmVyOS5naWYiIHdpZHRoPSIxNzAiIGhlaWdodD0iH NDAiIGJvcmRlcj0iMCI+PC9hPjwvcD4NCiAgICAgICAgPC90ZD4NCiAgICAgICAgPHRkIHdpH ZHRoPSI0MTUiIGhlaWdodD0iMTUiPg0KICAgICAgICAgICAgPGZvbnQgY29sb3I9InJlZCIgH c2l6ZT0iMiI+uLa+4Lq4tNkgsvex4iDI+7XptNm0wiC047noLi4uPGJyPrTjuei/zcDHIMD8H wO/AuyC8scb3x8+/qSDA2r3FsPogDQogICAgICAgICAgICCwocG3wMcgsMewrcC7IMH2xbC9H yr3Dv8AuPC9mb250PiAgICAgICAgPC90ZD4NCiAgICA8L3RyPg0KPC90YWJsZT4NCjx0YWJsH ZSBib3JkZXI9IjEiIGNlbGxzcGFjaW5nPSIwIiB3aWR0aD0iNTk2IiBib3JkZXJjb2xvcj0iH cmVkIiBib3JkZXJjb2xvcmRhcms9IndoaXRlIiBib3JkZXJjb2xvcmxpZ2h0PSJyZWQiPg0KH ICAgIDx0cj4NCiAgICAgICAgPHRkIHdpZHRoPSIxMTIiIGhlaWdodD0iOTIiIHJvd3NwYW49H IjIiPg0KICAgICAgICAgICAgPHA+PGEgaHJlZj0iamF2YXNjcmlwdDpuYV9vcGVuX3dpbmRvH dygnd2luJywgJ2h0dHA6Ly93d3cuZWZyZWVjYWxsLmNvLmtyL2hlYWx0aDktMy5odG0nLCAwH LCAwLCA4MDAsIDYwMCwgMSwgMSwgMSwgMSwgMSk7Ij48aW1nIHNyYz0iaS1zMS5qcGciIHdpH ZHRoPSIxMTAiIGhlaWdodD0iMTEwIiBib3JkZXI9IjAiPjwvYT48L3A+DQogICAgICAgIDwvH dGQ+DQogICAgICAgIDx0ZCB3aWR0aD0iNDcyIiBoZWlnaHQ9IjYiPg0KICAgICAgICAgICAgH PHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyI+PGI+PGEgaHJlZj0iamF2YXNjcmlwH dDpuYV9vcGVuX3dpbmRvdygnd2luJywgJ2h0dHA6Ly93d3cuZWZyZWVjYWxsLmNvLmtyL2hlH YWx0aDktMy5odG0nLCAwLCAwLCA4MDAsIDYwMCwgMSwgMSwgMSwgMSwgMSk7Ij48Zm9udCBjH b2xvcj0icmVkIj6047noIA0KICAgICAgICAgICAgtbYgu+ezybLbPC9hPiAmbmJzcDs8L2ZvH bnQ+PC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjlwdDsiPsO8s7vAxyANCiAgH ICAgICAgICAgILTjuei1tsC7ILj2udvAuLfOIL/PwPwguejD4iEhISA8L3NwYW4+PC9wPg0KH ICAgICAgICA8L3RkPg0KICAgIDwvdHI+DQogICAgPHRyPg0KICAgICAgICA8dGQgd2lkdGg9H IjQ3MiI+DQogDQogICAgICAgICAgICA8cCBzdHlsZT0ibGluZS1oZWlnaHQ6MTAwJTsgbWFyH Z2luLXRvcDowOyBtYXJnaW4tYm90dG9tOjA7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjlwH dDsiPjxmb250IGNvbG9yPSJibHVlIj6047notba757PJsts8L2ZvbnQ+wLogyO2/rMC4t84gH wM7H0SC49rzTwMcgPGZvbnQgY29sb3I9ImJsdWUiPrTjuei1tjwvZm9udD7AuyC067zSuq/AH uLfOIA0KICAgICAgICAgICAgPGZvbnQgY29sb3I9ImJsdWUiPr/PwPwguejD4jwvZm9udD4gH vcPFsLnHt8694SCx3bTcIMf2u/PAuyC++L7WsO0gtOO56LimIMOzwL0gx8e/7LTCILvntvfDH s7ezIA0KtOO56LjAwLsgu/O9x73DxNEgtOO56LimILL3sNTHz7TCIDxmb250IGNvbG9yPSJiH bHVlIj6x2b/4waawxb/4uK48L2ZvbnQ+t84gv6yxuCwgwabBtrXIIMGmx7DAzMDUtM+02TwvH c3Bhbj4uPGJyPjxicj4mbmJzcDsgICAgICAgIDwvdGQ+DQogICAgPC90cj4NCjwvdGFibGU+H DQo8dGFibGUgYm9yZGVyPSIwIiB3aWR0aD0iNjAyIj4NCiAgICA8dHI+DQogICAgICAgIDx0H ZCB3aWR0aD0iNTkyIiBoZWlnaHQ9IjE1IiBjb2xzcGFuPSIyIj4NCiAgICAgICAgICAgIDxwH PiZuYnNwOzwvcD4NCjwvdGQ+DQogICAgPC90cj4NCiAgICA8dHI+DQogICAgICAgIDx0ZCB3H aWR0aD0iMTcxIiBoZWlnaHQ9IjE1Ij4NCiAgICAgICAgICAgIDxwPjxhIGhyZWY9ImphdmFzH Y3JpcHQ6bmFfb3Blbl93aW5kb3coJ3dpbicsICdodHRwOi8vd3d3LmVmcmVlY2FsbC5jby5rH ci9tYWxsL3Nob3BwaW5nL3Nob3BwaW5nLWluZGV4LnBocD9jPTEzJywgMCwgMCwgODAwLCA2H MDAsIDEsIDEsIDEsIDEsIDEpOyI+PGltZyBzcmM9ImJhbm5lcjExLmdpZiIgd2lkdGg9IjE3H MCIgaGVpZ2h0PSI0MCIgYm9yZGVyPSIwIj48L2E+PC9wPg0KICAgICAgICA8L3RkPg0KICAgH ICAgICA8dGQgd2lkdGg9IjQxNSIgaGVpZ2h0PSIxNSI+DQogICAgICAgICAgICA8cD48Zm9uH dCBzaXplPSIyIiBjb2xvcj0iZnVjaHNpYSI+v6m8urrQtenAxyCw7bnOLi48YnI+wMzHwbiuH xN3AzCDH1LKyIA0KICAgICAgICAgICAgx9W0z7TZLjwvZm9udD48L3A+DQogICAgICAgIDwvH dGQ+DQogICAgPC90cj4NCjwvdGFibGU+DQo8dGFibGUgYm9yZGVyPSIxIiBjZWxsc3BhY2luH Zz0iMCIgd2lkdGg9IjU5NiIgYm9yZGVyY29sb3I9ImZ1Y2hzaWEiIGJvcmRlcmNvbG9yZGFyH az0id2hpdGUiIGJvcmRlcmNvbG9ybGlnaHQ9ImZ1Y2hzaWEiPg0KICAgIDx0cj4NCiAgICAgH ICAgPHRkIHdpZHRoPSIxMDMiIGhlaWdodD0iMTA4IiByb3dzcGFuPSIyIj4NCiAgICAgICAgH ICAgIDxwPjxhIGhyZWY9ImphdmFzY3JpcHQ6bmFfb3Blbl93aW5kb3coJ3dpbicsICdodHRwH Oi8vd3d3LmVmcmVlY2FsbC5jby5rci9tYWxsL3Nob3BwaW5nL3Nob3BwaW5nLWRldGFpbC5wH aHA/cGk9MzcnLCAwLCAwLCA4MDAsIDYwMCwgMSwgMSwgMSwgMSwgMSk7Ij48aW1nIHNyYz0iH Yi1zMS0xLmpwZyIgd2lkdGg9IjExMCIgaGVpZ2h0PSIxMTAiIGJvcmRlcj0iMCI+PC9hPjwvH cD4NCiAgICAgICAgPC90ZD4NCiAgICAgICAgPHRkIHdpZHRoPSIxODYiIGhlaWdodD0iMjEiH Pg0KICAgICAgICAgICAgPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+PGEgaHJlH Zj0iamF2YXNjcmlwdDpuYV9vcGVuX3dpbmRvdygnd2luJywgJ2h0dHA6Ly93d3cuZWZyZWVjH YWxsLmNvLmtyL21hbGwvc2hvcHBpbmcvc2hvcHBpbmctZGV0YWlsLnBocD9waT0zNycsIDAsH IDAsIDgwMCwgNjAwLCAxLCAxLCAxLCAxLCAxKTsiPjxiPjxmb250IGNvbG9yPSJmdWNoc2lhH Ij7E3bbzsNU8L2E+PC9zcGFuPiANCiAgICAgICAgICAgICZuYnNwOzwvYj48L2ZvbnQ+PHNwH YW4gc3R5bGU9ImZvbnQtc2l6ZTo5cHQ7Ij7Hx7rOs+vIrSC42MPntvMhITwvc3Bhbj48L3A+H DQogICAgICAgIDwvdGQ+DQogICAgICAgIDx0ZCB3aWR0aD0iMTExIiBoZWlnaHQ9IjEwOCIgH cm93c3Bhbj0iMiI+DQogICAgICAgICAgICA8cD48YSBocmVmPSJqYXZhc2NyaXB0Om5hX29wH ZW5fd2luZG93KCd3aW4nLCAnaHR0cDovL3d3dy5lZnJlZWNhbGwuY28ua3IvbWFsbC9zaG9wH cGluZy9zaG9wcGluZy1kZXRhaWwucGhwP3BpPTM2JywgMCwgMCwgODAwLCA2MDAsIDEsIDEsH IDEsIDEsIDEpOyI+PGltZyBzcmM9IngtczEtMS5qcGciIHdpZHRoPSIxMTAiIGhlaWdodD0iH MTEwIiBib3JkZXI9IjAiPjwvYT48L3A+DQogICAgICAgIDwvdGQ+DQogICAgICAgIDx0ZCB3H aWR0aD0iMTc4IiBoZWlnaHQ9IjIxIj4NCiAgICAgICAgICAgIDxwIGFsaWduPSJsZWZ0IiBzH dHlsZT0ibGluZS1oZWlnaHQ6MTAwJTsgbWFyZ2luLXRvcDowOyBtYXJnaW4tYm90dG9tOjA7H Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwcHQ7Ij48Yj48YSBocmVmPSJqYXZhc2NyaXB0H Om5hX29wZW5fd2luZG93KCd3aW4nLCAnaHR0cDovL3d3dy5lZnJlZWNhbGwuY28ua3IvbWFsH bC9zaG9wcGluZy9zaG9wcGluZy1kZXRhaWwucGhwP3BpPTM2JywgMCwgMCwgODAwLCA2MDAsH IDEsIDEsIDEsIDEsIDEpOyI+PGZvbnQgY29sb3I9ImZ1Y2hzaWEiPsW+vtjIrcDMxq48L2E+H IA0KICAgICAgICAgICAgPC9mb250PjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6H ZTo5cHQ7Ij6x4rnMLMDixrwswdax2bH6PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuH YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuH YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO7Dtuc4gDQogICAgICAgICAgICCzH oTwvc3Bhbj48L3A+DQogICAgICAgIDwvdGQ+DQogICAgPC90cj4NCiAgICA8dHI+DQogICAgH ICAgIDx0ZCB3aWR0aD0iMTg2Ij4NCiAgICAgICAgICAgIDxwIHN0eWxlPSJsaW5lLWhlaWdoH dDoxMDAlOyBtYXJnaW4tdG9wOjA7IG1hcmdpbi1ib3R0b206MDsiPjxzcGFuIHN0eWxlPSJmH b250LXNpemU6OXB0OyI+PGZvbnQgY29sb3I9ImJsdWUiPsfHus6z68itwMcgDQogICAgICAgH ICAgICC/+MDOPC9mb250PsC6IDxicj7Hx7rOs7sgPGZvbnQgY29sb3I9ImJsdWUiPsTdtvOwH 1cDHsKi80iE8L2ZvbnQ+PGJyPiA8Zm9udCBjb2xvcj0iYmx1ZSI+xN2287DVPC9mb250PsDMH IA0KICAgICAgICAgICAgtOe9xcDHIMD+wL3AuyDB9sTRteW4s7TPtNkuPC9zcGFuPiAgICAgH ICAgPC90ZD4NCiAgICAgICAgPHRkIHdpZHRoPSIxNzgiPg0KICAgICAgICAgICAgPHNwYW4gH c3R5bGU9ImZvbnQtc2l6ZTo5cHQ7Ij6x4rnMLLDLufa8uCzB1rHZsfoswOLGvC4uLi48YnI+H wMzBpiANCiAgICAgICAgICAgILCow9/B9iC4u7DtIDxicj48Zm9udCBjb2xvcj0iYmx1ZSI+H ucy56TwvZm9udD4gPGZvbnQgY29sb3I9ImJsdWUiPsD8ua68uiDFqbiyPC9mb250Pjxicj48H Zm9udCBjb2xvcj0iYmx1ZSI+xb6+2MitwMzGrjwvZm9udD63ziCyyyDA4sC4vLy/5CEhPGJyH Pjxicj4mbmJzcDsNCiAgICAgICAgICAgIDwvc3Bhbj4gICAgICAgIDwvdGQ+DQogICAgPC90H cj4NCjwvdGFibGU+DQo8aHIgd2lkdGg9IjYwMCIgYWxpZ249ImxlZnQiIG5vc2hhZGUgY29sH b3I9ImxpbWUiIHN0eWxlPSJsaW5lLWhlaWdodDoxMDAlOyBtYXJnaW4tdG9wOjA7IG1hcmdpH bi1ib3R0b206MDsiPg0KPHAgc3R5bGU9ImxpbmUtaGVpZ2h0OjEwMCU7IG1hcmdpbi10b3A6H MDsgbWFyZ2luLWJvdHRvbTowOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5cHQ7Ij48YSBoH cmVmPSJqYXZhc2NyaXB0Om5hX29wZW5fd2luZG93KCd3aW4nLCAnaHR0cDovL2VmcmVlY2FsH bC5jby5rcicsIDAsIDAsIDgwMCwgNjAwLCAxLCAxLCAxLCAxLCAxKTsiIE9uTW91c2VPdXQ9H Im5hX3Jlc3RvcmVfaW1nX3NyYygnYm90dG9iJywgJ2RvY3VtZW50JykiIE9uTW91c2VPdmVyH PSJuYV9jaGFuZ2VfaW1nX3NyYygnYm90dG9iJywgJ2RvY3VtZW50JywgJ21haW5pbWcuanBnH JywgdHJ1ZSk7Ij48aW1nIHNyYz0ic2hvcHBpbmcuanBnIiB3aWR0aD0iNjAwIiBoZWlnaHQ9H IjE2MCIgYm9yZGVyPSIwIiBuYW1lPSJib3R0b2IiPjwvYT48L3NwYW4+PC9wPg0KPGhyIHdpH ZHRoPSI2MDAiIGFsaWduPSJsZWZ0IiBub3NoYWRlIGNvbG9yPSJsaW1lIiBzdHlsZT0ibGluH ZS1oZWlnaHQ6MTAwJTsgbWFyZ2luLXRvcDowOyBtYXJnaW4tYm90dG9tOjA7Ij4NCjxwIGFsH aWduPSJsZWZ0IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTAwJTsgbWFyZ2luLXRvcDowOyBtYXJnH aW4tYm90dG9tOjA7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjlwdDsiPiZuYnNwOzxpbWcgH c3JjPSJjb3B5cmlnaHQuZ2lmIiB3aWR0aD0iMzk1IiBoZWlnaHQ9IjQ0IiBib3JkZXI9IjAiH IHZzcGFjZT0iMCIgaHNwYWNlPSIxMTAiIHVzZW1hcD0iI0ltYWdlTWFwMSI+PC9zcGFuPjwvH cD4NCjxtYXAgbmFtZT0iSW1hZ2VNYXAxIj4NCjxhcmVhIHNoYXBlPSJyZWN0IiBjb29yZHM9H IjM3MiwgMjcsIDM5NCwgNDMiIGhyZWY9Im1haWx0bzp3ZWJtYXN0ZXJAZWZyZWVjYWxsLmNv LmtyIj4NCjwvbWFwPg==  - ------=_NextPart_000_0117_01C0F10A.93A14C00--3   ------------------------------  $ Date: Wed, 9 Jan 2002 14:40:37 -05002 From: "Sue Skonetski" <susan.skonetski@compaq.com># Subject: Alpha Itanium Advertismentw2 Message-ID: <v%0%7.463$5Y4.13819@news.cpqcorp.net>  : You may have seen this, but just in case here is the text.  I This was in print and also distributed at Oracle openworld and will be inSL the following.  Please note that I typed this in which is why the trademarks are not included  
 warm regards,C Suer   _____s Publication name Insertion dateD   Sybase magazine Jan 24, 2002   Oracle magazine March/Aprilx   SAS Magazine March/April  1 EMEA Inform Magazine current issue (see web site)y@ http://emea-files.eur.compaq.com/ebg/Hps/10710-INFORM_Compaq.pdf  ? _______________________________________________________________CJ Compaq Customers Depend on AlphaServer Systems to run their most demanding business critical applications.V  6 Compaq and its partners will make sure that continues.  L We know why our customer have invested-and continue to invest-in AlphaServerC systems: simply put, they want the most effective system to run theiE applications they need, now and in the future.  And we are taking theG8 following steps to ensure the future of your investment.  G By teaming with Intel to transition to the Itanium architecture, we arevL giving customer long-term, secure processor development road map.  And sinceJ it is expected to be the most widely used 64-bit technology, our customers6 will benefit from a greater range of software options.K Our applications partners are teaming with us to support you the transition+
 including:  B ORACLE SAP, SAS,PEOPLESOFT, IONA, BEA, IDX, BMC SOFTWARE, COMPUTERJ ASSOCIATES, SYBASE, SANCHEZ, GIFTS, REAL SOLUTIONS, ENTRUST, REALNETWORKS, ROLF & NOLAN, INFORMIX  I We are porting OpenVMS to the Itanium architecture and for our Tru64 UNIXzH customers, we will be offering an enterprise UNIX to deliver outstanding) capabilities on the Itanium architecture.g  L We intend to continue to develop new AlphaServer systems on the current roadH map through 2004, and will continue to support AlphaServer systems for a multi-year period.  K For those in the process of acquiring or adding to the AlphaServer systems,AF Compaq is providing investment protection options that include special6 financing, deferred-payment leasing programs and more.  9 To find out all the ways we're ensuring that you have thewJ highest-performance enterprise computing for your business-critical needs,G please register on the Web for a Compaq IT Forum or talk to your CompaqS representative   go to compaq.com/ipf-enterprisei   ------------------------------  % Date: Wed, 09 Jan 2002 17:49:04 -0500j- From: JF Mezei <jfmezei.spamnot@videotron.ca>W' Subject: Re: Alpha Itanium AdvertismentS+ Message-ID: <3C3CC8DB.131FEBE@videotron.ca>H   Sue Skonetski wrote:3 > EMEA Inform Magazine current issue (see web site)CB > http://emea-files.eur.compaq.com/ebg/Hps/10710-INFORM_Compaq.pdf  N Is that the issue that has the word "Commitment"  near "Compaq" on the cover ? I giggled when I saw that.  I > By teaming with Intel to transition to the Itanium architecture, we aresN > giving customer long-term, secure processor development road map.  And sinceL > it is expected to be the most widely used 64-bit technology, our customers8 > will benefit from a greater range of software options.  I Interesting. Now Compaq restricts the IA64 to the most widely used 64-bitiN technology. And having killed Alpha, it still "hopes" that Intel will have theH most widely used one. That measn that Power and Sparc have a bloody goodL chance at winning. And this means that Compaq erred when it put all its eggs into the Intel basket.    N Sorry Compaq, no matter how you spin it, the Alphacide makes you look bad. YouN are better off just mentioning that the projects to port  VMS and NSK  to IA64G are still funded and will inform customers when that IA64 thing becomesGH reality, until then they can rest assured that Alpha will continue.  And Compaq should keep it at that.  J Using the word "commitment" on the front page reminds everyone that CompaqK broke its commitment with Alpha. That is a word Compaq needs to avoid for ajI few years. If/when IA64 does surpass Alpha and customers really do prefermM IA64, then you can start to brag about Itanium/IA64/whatever its name will beD
 that week.  H Until then, Compaq should remain low key on that issue because it simply= reminds customers of the huge blunder Compaq made on June 25.C  M > Our applications partners are teaming with us to support you the transition  > including: > D > ORACLE SAP, SAS,PEOPLESOFT, IONA, BEA, IDX, BMC SOFTWARE, COMPUTERL > ASSOCIATES, SYBASE, SANCHEZ, GIFTS, REAL SOLUTIONS, ENTRUST, REALNETWORKS, > ROLF & NOLAN, INFORMIX  L Humm, does Real Networks offer any VMS based software ? Since Tru64 is dead,H why would Real Network port its server software to HPUX when it probably, already has its softwrae running on HP UX ?.  M Same goes for SAP. Why would SAP be involved with Compaq to port something to8N IA64 ? It already is involved with HP, so it has no point in poorting anythingL from Compaq's products to IA64. (Unless Compaq has struct a secret agreement to port SAP to VMS).    K > We are porting OpenVMS to the Itanium architecture and for our Tru64 UNIX6J > customers, we will be offering an enterprise UNIX to deliver outstanding+ > capabilities on the Itanium architecture.H  M Again, don't rub it in. If someone chose the less popular Tru64 over HPUX, itKM is because they really needed the superior technology of Tru64 at the expenseCK of having a less popular UNIX with fewer applications.  If, on a technologyjN basis, HP UX is inferior to Solaris and/or IBM's AIX, then those customers whoL chose Tru64 for its superior technology will move to the second best (either? IBM or SUN), not the one with the technologically weakest Unix.g    L It was a huge blunder for Compaq to burn its bridges before the wedding with Compaq was consumed.  M > For those in the process of acquiring or adding to the AlphaServer systems,jH > Compaq is providing investment protection options that include special8 > financing, deferred-payment leasing programs and more.  M Read: we realised that for the next year nobody wants to by any alphas unlessG= they really have to , so we have to provide major incentives.C  L I wonder if Compaq would be willing to protect an Alpha investment by payingI for the port to Sun Solaris once Compaq pulls the plug on Alpha ? (eg: ifgJ customer does not want to go IA64 , but wants to go Alpha for the next fewL years, would the incentives allow for the customer to buy Alpha now and thenJ get a break to move to Sun later when the plug is pulled from Alpha's life
 support ?)   ------------------------------  $ Date: Wed, 9 Jan 2002 18:03:29 -05002 From: "Sue Skonetski" <susan.skonetski@compaq.com>' Subject: Re: Alpha Itanium AdvertismentD2 Message-ID: <HZ3%7.485$5Y4.14408@news.cpqcorp.net>  K This is an advertisement, one of the things the newsgroup keeps saying thatG VMS is not mentioned in.   We are mentioned in this one.m   sueh    : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message% news:3C3CC8DB.131FEBE@videotron.ca...D > Sue Skonetski wrote:5 > > EMEA Inform Magazine current issue (see web site)wD > > http://emea-files.eur.compaq.com/ebg/Hps/10710-INFORM_Compaq.pdf >gH > Is that the issue that has the word "Commitment"  near "Compaq" on the cover ?z > I giggled when I saw that. >CK > > By teaming with Intel to transition to the Itanium architecture, we arejJ > > giving customer long-term, secure processor development road map.  And sincesD > > it is expected to be the most widely used 64-bit technology, our	 customers7: > > will benefit from a greater range of software options. >HK > Interesting. Now Compaq restricts the IA64 to the most widely used 64-bitcL > technology. And having killed Alpha, it still "hopes" that Intel will have thegJ > most widely used one. That measn that Power and Sparc have a bloody goodI > chance at winning. And this means that Compaq erred when it put all its1 eggs > into the Intel basket. >m >DL > Sorry Compaq, no matter how you spin it, the Alphacide makes you look bad. YougK > are better off just mentioning that the projects to port  VMS and NSK  tox IA64I > are still funded and will inform customers when that IA64 thing becomes+J > reality, until then they can rest assured that Alpha will continue.  And  > Compaq should keep it at that. >XL > Using the word "commitment" on the front page reminds everyone that CompaqK > broke its commitment with Alpha. That is a word Compaq needs to avoid form aSK > few years. If/when IA64 does surpass Alpha and customers really do preferCL > IA64, then you can start to brag about Itanium/IA64/whatever its name will be > that week. >lJ > Until then, Compaq should remain low key on that issue because it simply? > reminds customers of the huge blunder Compaq made on June 25.c >MD > > Our applications partners are teaming with us to support you the
 transition > > including: > >GF > > ORACLE SAP, SAS,PEOPLESOFT, IONA, BEA, IDX, BMC SOFTWARE, COMPUTER@ > > ASSOCIATES, SYBASE, SANCHEZ, GIFTS, REAL SOLUTIONS, ENTRUST,
 REALNETWORKS,k > > ROLF & NOLAN, INFORMIX >iH > Humm, does Real Networks offer any VMS based software ? Since Tru64 is dead,pJ > why would Real Network port its server software to HPUX when it probably. > already has its softwrae running on HP UX ?. >nL > Same goes for SAP. Why would SAP be involved with Compaq to port something toG > IA64 ? It already is involved with HP, so it has no point in poortingK anythingD > from Compaq's products to IA64. (Unless Compaq has struct a secret	 agreement  > to port SAP to VMS). >u >gH > > We are porting OpenVMS to the Itanium architecture and for our Tru64 UNIXL > > customers, we will be offering an enterprise UNIX to deliver outstanding- > > capabilities on the Itanium architecture.h >8L > Again, don't rub it in. If someone chose the less popular Tru64 over HPUX, itG > is because they really needed the superior technology of Tru64 at thev expenseCB > of having a less popular UNIX with fewer applications.  If, on a
 technologyL > basis, HP UX is inferior to Solaris and/or IBM's AIX, then those customers whoTF > chose Tru64 for its superior technology will move to the second best (eitherOA > IBM or SUN), not the one with the technologically weakest Unix.u >A >0I > It was a huge blunder for Compaq to burn its bridges before the weddingm with > Compaq was consumed. >/F > > For those in the process of acquiring or adding to the AlphaServer systems,J > > Compaq is providing investment protection options that include special: > > financing, deferred-payment leasing programs and more. >DH > Read: we realised that for the next year nobody wants to by any alphas unless? > they really have to , so we have to provide major incentives.H >jG > I wonder if Compaq would be willing to protect an Alpha investment byC payingK > for the port to Sun Solaris once Compaq pulls the plug on Alpha ? (eg: ifCL > customer does not want to go IA64 , but wants to go Alpha for the next fewI > years, would the incentives allow for the customer to buy Alpha now andj thenL > get a break to move to Sun later when the plug is pulled from Alpha's life > support ?)   ------------------------------  $ Date: Wed, 9 Jan 2002 18:57:34 -0500+ From: "Main, Kerry" <Kerry.Main@compaq.com>+' Subject: RE: Alpha Itanium AdvertismentyT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF401AB1B65@kaoexc01.americas.cpqcorp.net>   JF,g  H What are your thoughts on Sun suddenly dropping one of its platforms for Solaris?  4  http://www.nwfusion.com/news/2002/0108sunintel.html3    Sun to drop Intel support in Solaris 9, 01/08/022  B "This tradition, however, will come to a close with the release ofB Solaris 9 in the first half of this year. Sun decided the costs ofA support, such as bug tracking and software patches, for Solaris 9s8 running on Intel was not worth the cost to the company."  G "We are focusing more on our bottom line," said Graham Lovell, directorSG of product marketing for Solaris at Sun. "We need to focus on immediateG revenue where possible."  E What are your thoughts on Sun dropping support for this platform withg less than 6 months notice?=203  6 What do you think these Customers next step should be?   Regards,  
 Kerry Main Senior Consultantu Compaq Canada Corp.y Professional Servicesv Voice: 613-592-4660D Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----4 From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca] Sent: January 9, 2002 5:49 PM3 To: Info-VAX@Mvb.Saic.Comj' Subject: Re: Alpha Itanium AdvertismentQ     Sue Skonetski wrote:3 > EMEA Inform Magazine current issue (see web site)hB > http://emea-files.eur.compaq.com/ebg/Hps/10710-INFORM_Compaq.pdf  F Is that the issue that has the word "Commitment"  near "Compaq" on the cover ?w I giggled when I saw that.  E > By teaming with Intel to transition to the Itanium architecture, weq areHH > giving customer long-term, secure processor development road map.  And sinceQB > it is expected to be the most widely used 64-bit technology, our	 customersu8 > will benefit from a greater range of software options.  B Interesting. Now Compaq restricts the IA64 to the most widely used 64-bitE technology. And having killed Alpha, it still "hopes" that Intel willy have theH most widely used one. That measn that Power and Sparc have a bloody goodG chance at winning. And this means that Compaq erred when it put all its+ eggs into the Intel basket.    E Sorry Compaq, no matter how you spin it, the Alphacide makes you lookr bad. YouE are better off just mentioning that the projects to port  VMS and NSKy to IA64uG are still funded and will inform customers when that IA64 thing becomesuH reality, until then they can rest assured that Alpha will continue.  And Compaq should keep it at that.  C Using the word "commitment" on the front page reminds everyone thatW CompaqE broke its commitment with Alpha. That is a word Compaq needs to avoidl for a2B few years. If/when IA64 does surpass Alpha and customers really do preferE IA64, then you can start to brag about Itanium/IA64/whatever its namec will be8
 that week.  H Until then, Compaq should remain low key on that issue because it simply= reminds customers of the huge blunder Compaq made on June 25.g  B > Our applications partners are teaming with us to support you the
 transition > including: >=20D > ORACLE SAP, SAS,PEOPLESOFT, IONA, BEA, IDX, BMC SOFTWARE, COMPUTER> > ASSOCIATES, SYBASE, SANCHEZ, GIFTS, REAL SOLUTIONS, ENTRUST,
 REALNETWORKS,a > ROLF & NOLAN, INFORMIX  F Humm, does Real Networks offer any VMS based software ? Since Tru64 is dead,jH why would Real Network port its server software to HPUX when it probably, already has its softwrae running on HP UX ?.  @ Same goes for SAP. Why would SAP be involved with Compaq to port something toE IA64 ? It already is involved with HP, so it has no point in poortingG anythingB from Compaq's products to IA64. (Unless Compaq has struct a secret	 agreement  to port SAP to VMS).    F > We are porting OpenVMS to the Itanium architecture and for our Tru64 UNIX> > customers, we will be offering an enterprise UNIX to deliver outstandingG+ > capabilities on the Itanium architecture.V  D Again, don't rub it in. If someone chose the less popular Tru64 over HPUX, itE is because they really needed the superior technology of Tru64 at they expensei@ of having a less popular UNIX with fewer applications.  If, on a
 technology@ basis, HP UX is inferior to Solaris and/or IBM's AIX, then those
 customers whoDD chose Tru64 for its superior technology will move to the second best (either6? IBM or SUN), not the one with the technologically weakest Unix.s    G It was a huge blunder for Compaq to burn its bridges before the weddingi with Compaq was consumed.  D > For those in the process of acquiring or adding to the AlphaServer systems,H > Compaq is providing investment protection options that include special8 > financing, deferred-payment leasing programs and more.  F Read: we realised that for the next year nobody wants to by any alphas unless= they really have to , so we have to provide major incentives.0  E I wonder if Compaq would be willing to protect an Alpha investment byj payingF for the port to Sun Solaris once Compaq pulls the plug on Alpha ? (eg: ifF customer does not want to go IA64 , but wants to go Alpha for the next few G years, would the incentives allow for the customer to buy Alpha now andw thenE get a break to move to Sun later when the plug is pulled from Alpha'sn life
 support ?)   ------------------------------  % Date: Wed, 09 Jan 2002 19:38:33 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca> ' Subject: Re: Alpha Itanium Advertismenta, Message-ID: <3C3CE27D.64E17A97@videotron.ca>   "Main, Kerry" wrote:  D > "This tradition, however, will come to a close with the release ofD > Solaris 9 in the first half of this year. Sun decided the costs ofC > support, such as bug tracking and software patches, for Solaris 9 : > running on Intel was not worth the cost to the company."  G > What are your thoughts on Sun dropping support for this platform withr > less than 6 months notice?    M 1- has sun indicated that it will stop supporting existing version of Solarist
 on Intel ?M The announcement means that no new versions will be relased on Intel, but theyB article does allude to 7 years of support for Solaris 8 on intel.     F Note that such an announcement was once made for 68000 based Macintosh/ computers (new version would be PowerPC only). 4   The key statement is:o ##L Most people using Solaris on Intel-based servers are in universities and notI large companies, Haff said. Sun had looked to keep Solaris popular in theCL university community as a way to familiarize students with  Unix. The risingJ popularity of Linux in these communities is now doing this job for Sun and( reduced the burden of promoting Solaris. ##    K In other words: those running Solaris  on Intel weren't generating profits,pI and they have the option of moving to Sparc to keep Solaris or use Linux,gI especially if they are poor and can't affor to pay for support/enterprise  level services.   L This is quite different from HP killing MPE with no new versions at all, andS Compaq killing Tru64 along with Alpha. Solaris continues to live with new versions.p    K I think that the decision makes sense, especially if supporting 32 bit 8086fJ with all its architectural quirck caused more headaches than the generatedJ revenus. The fact that enterprises chose to build solaris on a proprietaryJ SPARC chip and that SUN rules the unix world is a strong message to CompaqM that Compaq could have succeeded with Alpha just as Sun succeeded with Sparc.   M My initial impression was "Sun wants to stop supporting Intel's profits". AndFL the timing corresponds roughly with Intel trying to shove IA64 down people's4 throats. With only HP and Compaq blindly following).  K Considering that Sun does have low cost desktops that run Solaris on Sparc,pI the loss of Intel 8086 support doesn't change much on the grand scheme of 4 Solaris things (there is an equivalent replacement).   ------------------------------  % Date: Wed, 09 Jan 2002 23:18:59 -0500s1 From: Michael Austin <maustin@firstdbasource.com>g( Subject: Apache CSWS POST not working...2 Message-ID: <3C3D1633.524F40B2@firstdbasource.com>   GET and PUT work, but not POST.l  4 I never see a query_string when using the following: Apache 1.1-1  E $APACHE$DCL_ENV :== "$apache$common:[000000]APACHE$DCL_ENV.EXE_ALPHA"s $!@ $ write sys$output f$fao("!AS!/!/", "Content-type: text/plain") ( $write sys$output f$fao("!AS!/","<pre>") $set verifyt $define APACHE$CGI_MODE "0"o  $define APACHE$DEBUG_DCL_CGI "T"# $define APACHE$SHOW_CGI_SYMBOLS "T"u, $!Define APACHE$PREFIX_DCL_CGI_SYMBOLS_WWW   $apache$dcl_env -d  $APACHE$DCL_ENV -e tmpvar.lis -c $apache$dcl_env -l  3 I also never see tmpvar.lis... does it get deleted?  symbol REQUEST_METHOD = POST symbol WWW_REQUEST_METHOD =  logical    REQUEST_METHOD =    symbol QUERY_STRING =  symbol WWW_QUERY_STRING =  logical    QUERY_STRING =    This from a TCPTRACE   E..-..@...~..... .......P...e.(.. P....*..Content- type: applicatio n/x-www-form-url encoded..Content -length: 189.... KEY1=1L1&KEY2=2E P&KEY3=4CR&KEY4= 5RTO&KEY5=6MISC& KEY6=12L1&KEY7=1 3EP&KEY8=15CR&KE Y9=16RTO&KEY10=1 7MISC&C11=ON&KEY 11=1PIPE&C12=ON& KEY12=3PIPE&C13= ON&KEY13=11PIPE& C14=ON&KEY14=14P IPE&B1=Submit   !   ---more where that came from...o -- t   Regards,   Michael Austin7 First DBA Source, Inc. -- http://www.firstdbasource.comC President/Sr. DBA Consultant 704-947-1089 (Office)o 704-236-4377 (Mobile)t   ------------------------------  # Date: Wed, 09 Jan 2002 23:38:31 GMT ' From: "David G. Conroy" <dgc@spies.com> Y Subject: Re: BLISS pros and cons, was: Re: historical evidence of what went	 wrong  at DEoC Message-ID: <Xv4%7.27030$2L2.2325302487@newssvr21.news.prodigy.com>   K  > There is no such thing as a "byte" in C.  The word isn't even indexed indL > K&R, and K&R explicitly caution against making assumptions about how chars > relate to ints or pointers.m  7 The C language works fine on non-byte-oriented machinessG and machines with "unusual" word sizes. The PDP-10 is one fine example.o; Another fine example is the TITAN, a word-addressed machine @ built at DEC's Western Research Laboratory, upon which lots of CG code (including UNIX itself) ran just fine. On this machine pointers tor; characters looked different from pointers to anything else. E When an imported program failed to work on this machine it was alwaysU= the case that the program assumed something that the languagef did not guarantee.  @ The original standard runtime does, however, make the assumptionH that all objects can be evenly divided into chars; this assumption shows> up in routines like "fread", which use "char *" and the returnG value of "sizeof" as a universal address and length. Even then, nothingo@ demanded byte addressing or 8-bit bytes; 9 bit chars on a 32 bit: machine and/or 12 bit chars on a 24 bit machine work fine.   dgc    ------------------------------  # Date: Wed, 09 Jan 2002 23:53:23 GMTs' From: "David G. Conroy" <dgc@spies.com>eY Subject: Re: BLISS pros and cons, was: Re: historical evidence of what went	 wrong  at DE.C Message-ID: <TJ4%7.29044$6l2.3032869925@newssvr14.news.prodigy.com>l  B > demanded byte addressing or 8-bit bytes; 9 bit chars on a 36 bit>                                                             ^^   ------------------------------    Date: 10 Jan 2002 03:14:48 +0800, From: Paul Repacholi <prep@prep.synonet.com>Y Subject: Re: BLISS pros and cons, was: Re: historical evidence of what went  wrong   at Do- Message-ID: <87sn9f1glz.fsf@prep.synonet.com>e  ) John Sauter <J_Sauter@Empire.Net> writes:i   > Alan Greig wrote (in part):r  ? > Then it does appear absolutely astonishing you wouldn't know!0   > John Sauter responded:  E > And I remain astonished that I didn't find out until 16 years laternF > that EDT had been ported to TOPS-20 in 1985, even though I worked onF > TOPS-20 software from 1975 to 1978, and on EDT from 1981 to 1983.  IE > think if we had all stayed in the Mill I would have found out aboute > the port sooner.  F I think that was EDT v2, aka ED2. At one decus, the implementer gave aF talk on it, and one of *his* conditions for agreeing to do it was thatD *everyone* got it, under mainatainance or not! DEC had to do specialF ED2 only distro kits. I seem to remember from reading the source, that@ it supported RT, RSX, RSTS, 10s, 20s, and vaxen, with bugger allC conditional coding. (but totaly different included system files) In C fact I think there was small address and large address variants forA 10/20s.s  F Complex BLISS macros will destroy your brain. I showed some BLISS codeC to a unix head years ago, and he thought it was fake and I was just  winding him up..  % "%UNQOTE! Nothing would use that!" ;)t     -- s< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Wed, 09 Jan 2002 15:48:43 -0500t* From: John Reagan <john.reagan@compaq.com>Y Subject: Re: BLISS pros and cons, was: Re: historical evidence of what went  wrong   at Dh) Message-ID: <3C3CACAB.6070407@compaq.com>n   Paul Repacholi wrote:w  H > Complex BLISS macros will destroy your brain. I showed some BLISS codeE > to a unix head years ago, and he thought it was fake and I was just  > winding him up.h > ' > "%UNQOTE! Nothing would use that!" ;)     F Well, to be honest, in close to 19 years, I've never seen anybody use 	 %UNQUOTE.4    _ Here's PART one of the macros from the Pascal compiler that uses the most %QUOTEs in a row (5).      KEYWORDMACROF      ACT_( nam, gbl=0, tar=None, labels=, flags=0, base_conditional=,  index_conditional= ) =            %IF NOT %NULL(labels)          %THENI                  %ASSIGN(PAT_Label_Generator_, PAT_1st_Free_Label_Index_)G/                  Init_Labels_(%REMOVE(labels));                   MACRO2                      PAT_Act_Names_to_UNDECLARE_ =7                          %QUOTE %EXPAND %REMOVE(labels) ?                          $COMMA(%QUOTE %EXPAND %REMOVE(labels))c<                          %QUOTE %QUOTE %QUOTE %QUOTE %QUOTE  PAT_Act_Names_to_UNDECLARE_b"                          %QUOTE %;          %FI         -- g John ReaganW' Compaq Pascal/{A|I}MACRO Project Leadero   ------------------------------   Date: 9 Jan 2002 15:42:47 -0600n- From: Kilgallen@SpamCop.net (Larry Kilgallen) Y Subject: Re: BLISS pros and cons, was: Re: historical evidence of what went  wrong   at Du3 Message-ID: <EO0yyb3pj3v$@eisner.encompasserve.org>t  V In article <3C3CACAB.6070407@compaq.com>, John Reagan <john.reagan@compaq.com> writes:  H > Well, to be honest, in close to 19 years, I've never seen anybody use  > %UNQUOTE.b  H I have found several occasions to use %UNQUOTE (also in about 19 years).   ------------------------------  % Date: Wed, 09 Jan 2002 22:42:55 +0000f% From: "a.carlini" <arcarlini@iee.org>aY Subject: Re: BLISS pros and cons, was: Re: historical evidence of what went wrong   at DE & Message-ID: <3C3CC76F.1E45A84@iee.org>   Paul Repacholi wrote:l0 > Complex BLISS macros will destroy your brain.   ! The thing I miss most about BLISSo is its macro capability.  ' > "%UNQOTE! Nothing would use that!" ;)   $ Only once did I descend sufficiently% deeply into those depths ... but then  I did it with gusto and needed   about half a dozen in a row!   Happy memories :-)   Antonio    -- e   ---------------n- Antonio Carlini             arcarlini@iee.org-   ------------------------------  % Date: Wed, 09 Jan 2002 21:54:36 -0500x' From: John Sauter <J_Sauter@Empire.Net>eY Subject: Re: BLISS pros and cons, was: Re: historical evidence of what went wrong   at DEp* Message-ID: <3C3D026C.4EDCEEFD@Empire.Net>   Paul Repacholi wrote:   4 I think that was EDT v2, aka ED2. At one decus, the 0 implementer gave a talk on it, and one of *his* 5 conditions for agreeing to do it was that *everyone* u2 got it, under mainatainance or not! DEC had to do 1 special ED2 only distro kits. I seem to remember r4 from reading the source, that it supported RT, RSX, 7 RSTS, 10s, 20s, and vaxen, with bugger all conditional 25 coding. (but totaly different included system files) p2 In fact I think there was small address and large  address variants for 10/20s.   John Sauter responded:  5 I don't remember ever saying that at DECUS, so it mayu5 have been Bob Kushlis, or my successor, or I may have 8 forgotten what I said.  I think EDT was up to version 3 6 before it supported TOPS-20, though version 2 did run 2 on the VAX and various PDP-11 operating systems.  2 Since it ran on PDP-11s with small address spaces 4 compared to the PDP-10, I don't see why it would be 7 necessary to have small and large address variants for n the PDP-10.w  4 We did have large and small versions for the PDP-11.3 The source code was the same, the difference was inc2 the degree of overlaying.  I wrote a program which0 tried very hard to construct an optimal overlay 1 description for the RSX-11M TKB.  As I recall, wet4 tuned the journal file flushing parameters by having0 several people run EDT simultaneously on a small1 PDP-11/23 system.  EDT was considered adequate ift# it could keep up with their typing.n%     John Sauter (J_Sauter@Empire.Net)    ------------------------------    Date: 09 Jan 2002 20:27:56 +0100+ From: Johnny Eriksson <bygg@stacken.kth.se>nY Subject: Re: BLISS pros and cons, was: Re: historical evidence of what went wrong  at DECA: Message-ID: <m3yadvn9ver.fsf@hector-lector.stacken.kth.se>  - Mark Crispin <MRC@CAC.Washington.EDU> writes:   # > On 8 Jan 2002, Bob Koehler wrote:s7 > > >>The C compilers for the PDP-10 were all freeware.eH > >    The only one I saw was a commercial product.  I don't doubt there# > >    were many freeware versions.a > ; > There was never any commercial C compiler for the PDP-10.    Counter-example: Sargasso C.   --Johnny   ------------------------------  % Date: Wed, 09 Jan 2002 15:41:29 -0700n+ From: Ben Franchuk <bfranchuk@jetnet.ab.ca> Y Subject: Re: BLISS pros and cons, was: Re: historical evidence of what wentwrong at DEC at, Message-ID: <3C3CC719.5CB46A49@jetnet.ab.ca>   "David G. Conroy" wrote:  B > The original standard runtime does, however, make the assumptionJ > that all objects can be evenly divided into chars; this assumption shows@ > up in routines like "fread", which use "char *" and the returnI > value of "sizeof" as a universal address and length. Even then, nothing.B > demanded byte addressing or 8-bit bytes; 9 bit chars on a 32 bit< > machine and/or 12 bit chars on a 24 bit machine work fine.  6 Umm how do you fit 9 bit chars on a 32 bit machine. :)8 Are there any web sites on 24 bit machines that are byteA oriented other than my own. From what little I have read from theg punched B card era of 24 bit machines is that they had no byte instructions.  F Byte instructions so seem to come and go in instruction set evolution.   -- d% Ben Franchuk - Dawn * 12/24 bit cpu *n+ www.jetnet.ab.ca/users/bfranchuk/index.htmlt   ------------------------------   Date: 9 Jan 2002 15:30:58 CDTe= From: wayne@tachysoft.xxx.514360.killspam.00c9 (Wayne Sewell) G Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for ther. Message-ID: <svO5cnuturXi@tachxxsoftxxconsult>  c In article <mUon32KfHB1J@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:I^ > In article <a1gd48$1al$1@citadel.in.taronga.com>, peter@taronga.com (Peter da Silva) writes:6 >> In article <yUabDk1pELgR@eisner.encompasserve.org>,1 >> Bob Koehler <koehler@encompasserve.org> wrote:pK >>>   Uncle.  OK, I short changed that one a bit.  I know MOVCx, POLYx, andnI >>>   others on VAX are interruptable, but we were really talking about aqI >>>   simple ADD.  Do you know of any processor that has an interruptable  >>>   integer ADD? >> i >> How about >> r >> 	ADDL2	(R1)+,(R2)+  >> q> >> where R1 and R2 both point to different non-resident pages? > = > I believe ADDL2 is a non-interruptable instructions on VAX, 9 > so after the fault was handled the instruction would beo > restarted from scratch.a >   N One of the strangest crashes I ever analyzed was back in the early days of theM vax, somewhere around 1981.  There was a bug in the microcode that caused therL progam counter to not be backed up to the beginning of the instruction afterM the fault.   The byte count was off and the program counter wound up pointing/H somewhere in the middle of the instuction upon restart.   This caused anO "opcode reserved to digital" fault when the processor misinterpreted one of the  operands as the opcode.  :-)  J I don't remember which instuction it was or what circumstances caused this condition to occur.  u     [stuff deleted]n   -- oO ===============================================================================nM 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  :-) O ===============================================================================eN Sparky (from Bring It On): "In cheerleading, we throw people in the air.  Fat  	people don't go as high."   ------------------------------  % Date: Wed, 09 Jan 2002 20:16:40 +0100 , From: Didier Morandi <Didier.Morandi@gmx.ch>8 Subject: BUG: duplicated msg when booting 7.3 first time& Message-ID: <3C3C9717.C28521C4@gmx.ch>  M When booting a 7.3 system disk after its installation from the CD, VMS states H twice that it is extending the PAGEFILE.SYS file. Once before the actualN extension, then comes the "please wait it will take 200 seconds" message, then) again the extending PAGEFILE.SYS message.r  8 FCI (For Compaq Information, no access to SPR from home)   D.   ------------------------------  % Date: Wed, 09 Jan 2002 23:04:00 +0100s, From: Didier Morandi <Didier.Morandi@gmx.ch>* Subject: Clustering two PWS600 via a BA356& Message-ID: <3C3CBE50.97E50A48@gmx.ch>  N I have at home two PWS600 running 7.3 (for the moment. Then when everything isI ok, I'll install the Hobbyist CD as soon as I find an SCSI CD-ROM drive).v    The systems are DTL01 and DTL02.  ? I have plugged a BA356 with two SCSI cables, one to each Alpha.u  O When one cable only is plugged, I can see my disks, with the DTL01$DKA100 nameseK and so on. When I plug both ends, any system won't boot and I get a message $ "waiting for PKA0something to poll".  M Is it an ALLOCLASS problem? Or I just cannot do what I want with this BA box?a7 (none of the systems are defined as cluster nodes yet).u     Thanks,t   D.   ------------------------------  $ Date: Wed, 9 Jan 2002 17:30:14 -0500* From: WILLIAM WEBB <WWEBB1@email.usps.gov>. Subject: RE: Clustering two PWS600 via a BA356- Message-ID: <0033000047322160000002L002*@MHS>o  7 =0AIf you're using the 16-bit I/O module and connectingn/ both PWSs to it, Google-search for my post fromh0 yesterday where I discussed this at some length.  ( "personality module" should bring it up.   There *are* gotchas with it.  / Other thoughts are that you might have too manyn0 (or not enough) terminators in the chain, or the1 bus may be too long with both machines hooked up.s  2 It is a truism that neither "S" in SCSI represents the word "standard"-  0 (or "strange", for that matter, and, believe me,0 there are times when that *should* be the case.)   WWWebb   -----Original Message-----/ From: Info-VAX-Request@Mvb.Saic.Com at INTERNETe) Sent: Wednesday, January 09, 2002 5:04 PMxB To: Webb, William W Raleigh, NC; Info-VAX@Mvb.Saic.Com at INTERNET* Subject: Clustering two PWS600 via a BA356    H I have at home two PWS600 running 7.3 (for the moment. Then when everyt= hing is H ok, I'll install the Hobbyist CD as soon as I find an SCSI CD-ROM drive= ).    The systems are DTL01 and DTL02.  ? I have plugged a BA356 with two SCSI cables, one to each Alpha.s  H When one cable only is plugged, I can see my disks, with the DTL01$DKA1= 00 namesH and so on. When I plug both ends, any system won't boot and I get a mes= sage$ "waiting for PKA0something to poll".  H Is it an ALLOCLASS problem? Or I just cannot do what I want with this B= A box?7 (none of the systems are defined as cluster nodes yet).3     Thanks,2   D.=b   ------------------------------   Date: 9 Jan 2002 15:00:05 -0700r1 From: nothome@spammers.are.scum (Malcolm Dunnett) . Subject: Re: Clustering two PWS600 via a BA356, Message-ID: <svhObCJvJT0p@malvm6.mala.bc.ca>  ' In article <3C3CBE50.97E50A48@gmx.ch>, "1    Didier Morandi <Didier.Morandi@gmx.ch> writes:v  P > I have at home two PWS600 running 7.3 (for the moment. Then when everything isK > ok, I'll install the Hobbyist CD as soon as I find an SCSI CD-ROM drive).h > " > The systems are DTL01 and DTL02. > A > I have plugged a BA356 with two SCSI cables, one to each Alpha.t > R    Have you installed differential SCSI controllers in each Alpha and differentialK SCSI disks in the box? AFAIK this setup is only supported with differential  SCSI.S  M    Having said that, it's conceivable it might work with single-ended SCSI ifo2 the bus length is OK, grounds are compatible, etc.  I    Host SCSI adapters are usually set to SCSI ID 7 by default. Having twoSO host adapters on the bus that both have an ID of 7 won't work. Have you changedIN the ID on one of the host adapters? You can usually do this from the console -K do a "SHOW PK*" and look for a variable called "pka0_host_id". If the valueiI is the same ( eg 7 ) on each system change it to something else on one ofoA the systems ( not the same ID as any of your SCSI disks though ).-  Q > When one cable only is plugged, I can see my disks, with the DTL01$DKA100 namesyM > and so on. When I plug both ends, any system won't boot and I get a messagen& > "waiting for PKA0something to poll". > O > Is it an ALLOCLASS problem? Or I just cannot do what I want with this BA box?h9 > (none of the systems are defined as cluster nodes yet).& > M    If the hardware works you'll need to make sure the allocation class is thetL same on each system ( or at least the port allocation class for the SCSI bus on each system )   ------------------------------  # Date: Wed, 09 Jan 2002 23:26:34 GMTe2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman). Subject: Re: Clustering two PWS600 via a BA3562 Message-ID: <Kk4%7.486$5Y4.14293@news.cpqcorp.net>  U In article <3C3CBE50.97E50A48@gmx.ch>, Didier Morandi <Didier.Morandi@gmx.ch> writes: 7 :I have at home two PWS600 running 7.3 (for the moment.a  @ :I have plugged a BA356 with two SCSI cables, one to each Alpha.  D   You will also need to configure each node as a cluster member, andD   you must provide a cluster communications interconnect -- EthernetA   is the most common choice -- in addition to the cluster storagew   connection provided by SCSI.  K :When one cable only is plugged, I can see my disks, with the DTL01$DKA100 a
 :names...   A   You will want to configure allocation classes.  Please see the iA   FAQ and please see the cluster manual for assistance in setting-B   up a multi-host SCSI configuration.  The OpenVMS cluster manual ?   in particular provides details on setting up multi-host SCSI.:=   (Yes, I know, "Reading the manual is admitting defeat." :-)D  A :When I plug both ends, any system won't boot and I get a messaged% :"waiting for PKA0something to poll".t  C   You will want to ensure that the host SCSI controllers and all of +   the SCSI devices are at unique addresses.   B   You will also want to ensure that whichever SCSI controllers areD   in use here are supported for multi-host SCSI.  The list is eitherF   in the manuals, in the SPD, or at the cluster portion of the OpenVMS5   website.  (Without details, I can't check for you.)    :Is it an ALLOCLASS problem?  ?   Please see the OpenVMS FAQ for details on allocation classes.0  2 :Or I just cannot do what I want with this BA box?  @   How is the BA356 configured?  (There are various configurationA   options and various personality modules available with various t@   BA3xx series StorageWorks enclosures that can become variously    involved in various problems.)  8 :(none of the systems are defined as cluster nodes yet).     They need to be, of course.d    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Wed, 09 Jan 2002 23:27:49 -0500e( From: David Froble <davef@tsoft-inc.com>. Subject: Re: Clustering two PWS600 via a BA356* Message-ID: <3C3D1845.30805@tsoft-inc.com>  C  > I have at home two PWS600 running 7.3 (for the moment. Then when F  > everything is ok, I'll install the Hobbyist CD as soon as I find an  >  SCSI CD-ROM drive).   >#  > The systems are DTL01 and DTL02.)  >B  > I have plugged a BA356 with two SCSI cables, one to each Alpha.  >?  > When one cable only is plugged, I can see my disks, with the B  > DTL01$DKA100 names and so on. When I plug both ends, any systemF  > won't boot and I get a message "waiting for PKA0something to poll".  >C  > Is it an ALLOCLASS problem? Or I just cannot do what I want with G  > this BA box? (none of the systems are defined as cluster nodes yet).n  G Not a cluster expert, but from the above I infer that you're attaching oI one BA356 and two Alphas on one SCSI bus.  Each Alpha and each disk will  1 have to have a unique SCSI ID.  Got that covered?g   Dave   -- a4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  % Date: Wed, 09 Jan 2002 23:31:17 -0500m( From: David Froble <davef@tsoft-inc.com>. Subject: Re: Clustering two PWS600 via a BA356, Message-ID: <3C3D1915.4020902@tsoft-inc.com>   Hoff Hoffman wrote:T    D >   You will also want to ensure that whichever SCSI controllers areF >   in use here are supported for multi-host SCSI.  The list is eitherH >   in the manuals, in the SPD, or at the cluster portion of the OpenVMS7 >   website.  (Without details, I can't check for you.)D  ? Without the manual I'm guessing that this required Low Voltage QG Differential (LVD) SCSI?  Yeah, if I could find a manual, I could read T% it, but where's the fun in that?  :-)R   Dave   -- P4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------   Date: 9 Jan 2002 19:14:53 GMTt& From: peter@abbnm.com (Peter da Silva); Subject: Re: Compaq still tries to spin Alphacide both ways $ Message-ID: <a1i4rd$qv@web.nmti.com>  E In article <Mf7_7.9209$Vz3.1079597@newsread2.prod.itd.earthlink.net>,s% Felger Carbon <fmrfne@jps.net> wrote:sJ > Well, it's been a while since the RISC-CISC wars were fought in this NG.G > What I'm asking is, "Has there _ever_ been a true CISC x86 processor?o  H They all are. CISC doesn't describe the implementation, it describes the instruction set.  J A RISC instruction set is very close to what used to be known as "verticalL microcode", where each micro-op performed one simple operation very quickly.  I The alternative was "horizontal microcode", where each microcode word hadeE many fields to operate on every part of the processor simultaneously.   K For small processors, and they were all small in the '80s by our standards,-G horizontal microcode was a significant win, since each microinstruction-H took about the same amount of time whether it was a vertical micro-op orC a horizontal one. Once pipelining was developed, and even more withRI superscalar designs, horizontal microcode became the thing to do, becauseEH the fewer side effects a micro-op had the more easily it could be run in parallel with other micro-ops.  F Part of the background for RISC was the reaslization that a horizontalI microcode micro-op wasn't that far removed from the individual operationsdE of simpler microprocessors... and people didn't have a lot of troubleeF writing code for them, so why not just use them directly. So you had aK lot of fiddling with the design, with different kinds of RISC designs beingpB floated from the extremely raw MIPS designs (they didn't even haveF hardcoded interlocks on the pipeline so you had to put delays in afterI branches to let the pipeline refill: the branch didn't actually occur foryH a couple of instructions after the branch opcode) to the complexities of
 the Sparc.  K Things have tended towards the MIPS end of the spectrum, but they've had totG add interlocks... what happens when the pipeline's longer in the secondh generation?o  K Meanwhile, some people decided to try and see if horizontal microcode couldrJ also be used directly. This is where VLIW and EPIC and the IA64 come from.  I The problem is, writing horizontal microcode is tough. And it still makes L superscalar implementations hard: Intel has switched to a vertical microcodeM (what they call their RISC core) in the x86 to get performance up. So why didnL they think they could win with an explicit horizontal design? Well, the ideaJ was that you could get the compiler to handle all the scheduling decisionsJ and dump a stream of pre-decoded vertical micro-ops that could just be fedI into the CPU. You wouldn't need a superscalar design, you'd just make thecG instruction word wide enough that all the potential parallelization wasnD already handled. Sort of like feeding an athlete on pure predigested5 proteins and energy drinks instead of beef and beans.n  " There's two main issues with this:  " 	1. You need a heck of a compiler.  @ 	2. What happens when the second generation unit comes out? With? 	   vertical microcode, there's no reason two versions of a CPUwB 	   have to have the same fundamental units, and if you change theA 	   implementation you change the rules on what operations happen-? 	   when, how long they take, even how many subunits there are, B 	   well, only the microcode programmers see it. You can't DO thatA 	   with an instruction set: It's like the MIPS situation, exceptt? 	   now you have to add interlocks all over the place, run codey? 	   in an emulator, or have a hardware mode that does some kindhB 	   of interpretation on the old instructions so they can feed the 	   new hardware.s  G So what do you do? You compromise. You abstract the underlying hardware H somewhat and put a little bit of interpretation in. There's still timingL issues, so old code may run slower than a dog with no legs, but at least theL instruction set doesn't change every time you tweak the design. You probablyH want to recompile everything for every new CPU, but you don't *have* to.  M That makes upgrading to a new machine possible without crosscompiling. Alwaysc good.a  I But you still need a hell of a compiler, and you've also thrown away mostrJ of the potential advantages of the VLIW model since you still have to haveH an instruction processor. And looking at the IA64 they've compromised anK awful lot: the EPIC instruction now looks like a bunch of RISC instructionsm* crammed asymmetrically into a single word.  K They think they can get enough of a win from compiler technology that it'll H end up much faster than a traditional RISC design. But it's telling thatF people are seriously talking about the EV8 team putting an Alpha styleH RISC/Horizontal Microcode engine under the hood of the great grandson of Itanium.  C > If so, why are current x86 processors not considered to be CISCs,s  I Current x86 processors *are* CISCs. They use a microcode that's closer to H the kinds of microcodes RISC instruction sets were derived from now, butK that's an implementation detail. What goes on under the instruction set haseG only been part of the way you classify the instruction set in marketinge literature.i   > aside fromJ > the fact that there are a lot of former Taliban - excuse me, former RISCJ > supporters - out there who don't like the fact that they wound up on theC > wrong side, as their worthless stock options conclusively prove?"d  & How do you figure it's the wrong side?  B > This is comp.arch.  Isn't it true that a micro's instruction set> > architecture, and not its implementation, defines the micro?  G Absolutely. The x86 is a CISC, and its performance is due to some truly J brilliant implementations and amazing heroics, and the fact that Intel hasJ been able to throw orders of magnitude more engineering into making it run% fast than everyone else put together.e  L It's telling that Digital/Compaq, using a fraction of Intel's resources, hasE been able to stay ahead of them... usually significantly so... in CPUcI perfomance for almost all the last decade. I would love to see what Intel-G could do with a good design in their pocket. If Intel had, say, adopted=M something like the Alpha in 1995 instead of striking out on their traditionalhK path of trying to build a complex design that'll knock everyone's socks offeM (iApx432), at least when the compiler technology comes together (i860, IA64),=@ we'd already be using them for all our high-performance systems.   --  +  `-_-'   In hoc signo hack, Peter da Silva.wE   'U`    "A well-rounded geek should be able to geek about anything."-L                                                        -- nicolai@esperi.org          Disclaimer: WWFD?   ------------------------------  % Date: Thu, 10 Jan 2002 14:48:02 +1100 $ From: "Jon Hart" <jon@daemon.com.au>; Subject: Re: Compaq still tries to spin Alphacide both waysS8 Message-ID: <8b8%7.1970$ko4.209104@nasal.pacific.net.au>  J > Things have tended towards the MIPS end of the spectrum, but they've had toI > add interlocks... what happens when the pipeline's longer in the secondF
 > generation?m  L Is there an issue with distributing applications in pCode and then compiling theeI pCode to native code on installation? The code will need to be recompiled> when the cpu is upgraded.W  F In the days of DOS asking this of the OS may have been too much, but IG think that with modern OS'es it is reasonable to ask them to be able tol manageK all of that, and cope with a full reinstall without destroying your system.    --   Jon Hart   ------------------------------   Date: 10 Jan 2002 05:22:54 GMT& From: peter@abbnm.com (Peter da Silva); Subject: Re: Compaq still tries to spin Alphacide both ways % Message-ID: <a1j8fe$eno@web.nmti.com>n  K Let's try this again. I had an attack of the stupids in the last version ofpN this article, and mixed up horizontal and vertical microcode in several placesJ in it. Pardon for the confusion (and if I still have them wrong, feel free to send me nasty email).  < I also took the opportunity to expand a little near the end.  E In article <Mf7_7.9209$Vz3.1079597@newsread2.prod.itd.earthlink.net>,3% Felger Carbon <fmrfne@jps.net> wrote: J > Well, it's been a while since the RISC-CISC wars were fought in this NG.G > What I'm asking is, "Has there _ever_ been a true CISC x86 processor?.  H They all are. CISC doesn't describe the implementation, it describes the instruction set.  J A RISC instruction set is very close to what used to be known as "verticalL microcode", where each micro-op performed one simple operation very quickly.  I The alternative was "horizontal microcode", where each microcode word hadrE many fields to operate on every part of the processor simultaneously.h  K For small processors, and they were all small in the '80s by our standards,iG horizontal microcode was a significant win, since each microinstruction H took about the same amount of time whether it was a vertical micro-op orC a horizontal one. Once pipelining was developed, and even more with G superscalar designs, vertical microcode became the thing to do, becausesH the fewer side effects a micro-op had the more easily it could be run in parallel with other micro-ops.  C Part of the background for RISC was the realization that a verticalsI microcode micro-op wasn't that far removed from the individual operationseE of simpler microprocessors... and people didn't have a lot of troubleiF writing code for them, so why not just use them directly. So you had aK lot of fiddling with the design, with different kinds of RISC designs beingaB floated from the extremely raw MIPS designs (they didn't even haveF hardcoded interlocks on the pipeline so you had to put delays in afterI branches to let the pipeline refill: the branch didn't actually occur for H a couple of instructions after the branch opcode) to the complexities of
 the Sparc.  K Things have tended towards the MIPS end of the spectrum, but they've had toPG add interlocks... what happens when the pipeline's longer in the seconds generation?y  K Meanwhile, some people decided to try and see if horizontal microcode couldnJ also be used directly. This is where VLIW and EPIC and the IA64 come from.  I The problem is, writing horizontal microcode is tough. And it still makesnL superscalar implementations hard: Intel has switched to a vertical microcodeM (what they call their RISC core) in the x86 to get performance up. So why didiL they think they could win with an explicit horizontal design? Well, the ideaJ was that you could get the compiler to handle all the scheduling decisionsL and dump a stream of pre-decoded horizontal micro-ops that could just be fedI into the CPU. You wouldn't need a superscalar design, you'd just make thecG instruction word wide enough that all the potential parallelization wasID already handled. Sort of like feeding an athlete on pure predigested5 proteins and energy drinks instead of beef and beans.y  " There's two main issues with this:  " 	1. You need a heck of a compiler.  @ 	2. What happens when the second generation unit comes out? WithA 	   horizontal microcode, there's no reason two versions of a CPUrB 	   have to have the same fundamental units, and if you change theA 	   implementation you change the rules on what operations happena? 	   when, how long they take, even how many subunits there are,yB 	   well, only the microcode programmers see it. You can't DO thatA 	   with an instruction set: It's like the MIPS situation, excepte? 	   now you have to add interlocks all over the place, run codea? 	   in an emulator, or have a hardware mode that does some kindoB 	   of interpretation on the old instructions so they can feed the 	   new hardware.3  G So what do you do? You compromise. You abstract the underlying hardware H somewhat and put a little bit of interpretation in. There's still timingL issues, so old code may run slower than a dog with no legs, but at least theL instruction set doesn't change every time you tweak the design. You probablyH want to recompile everything for every new CPU, but you don't *have* to.  M That makes upgrading to a new machine possible without crosscompiling. Alwayso good.y  I But you still need a hell of a compiler, and you've also thrown away most$J of the potential advantages of the VLIW model since you still have to haveH an instruction processor. And looking at the IA64 they've compromised anK awful lot: the EPIC instruction now looks like a bunch of RISC instructions * crammed asymmetrically into a single word.  K They think they can get enough of a win from compiler technology that it'll H end up much faster than a traditional RISC design. But it's telling thatF people are seriously talking about the EV8 team putting an Alpha styleF RISC/Vertical Microcode engine under the hood of the great grandson of Itanium.  C > If so, why are current x86 processors not considered to be CISCs,a  I Current x86 processors *are* CISCs. They use a microcode that's closer tonH the kinds of microcodes RISC instruction sets were derived from now, butK that's an implementation detail. What goes on under the instruction set haseG only been part of the way you classify the instruction set in marketing  literature.n  E However, it still means that RISC design (that is, something like theTH internal microcode your Pentium IV's 'RISC CORE' runs) has proven itselfG the best design to build a high performance CPU. Everything between the : Pentium IV's 'RISC CORE' and the compiler has two effects:  @ 	1. It adds hardware that has to be designed, taped out, tested,= 	   verified, and so on. It adds hardware that reduces yeild,t@ 	   increases costs, and takes resources away from hardware thatB 	   actually makes the secret high performance instruction set run	 	   fast.-  A 	2. It makes it harder for the compiler to schedule instructions, B 	   because the code it generates doesn't actually get executed by@ 	   the processor. About all it can do is pick instructions that> 	   run fast, and let the dynamic instruction scheduler do the	 	   work.6   In addition:  A 	3. The 'RISC CORE' has to be better at scheduling micro-ops thanWA 	   regular RISC processors, which means that it's got to be moreI< 	   complex, and thus slower than one that can use a simpler 	   scheduler.  K So to get equivalent performance you have to spend more resources on designS and fabrication.   > aside fromJ > the fact that there are a lot of former Taliban - excuse me, former RISCJ > supporters - out there who don't like the fact that they wound up on theC > wrong side, as their worthless stock options conclusively prove?"a  & How do you figure it's the wrong side?  B > This is comp.arch.  Isn't it true that a micro's instruction set> > architecture, and not its implementation, defines the micro?  G Absolutely. The x86 is a CISC, and its performance is due to some truly J brilliant implementations and amazing heroics, and the fact that Intel hasJ been able to throw orders of magnitude more engineering into making it run% fast than everyone else put together.F  L It's telling that Digital/Compaq, using a fraction of Intel's resources, hasE been able to stay ahead of them... usually significantly so... in CPU-I perfomance for almost all the last decade. I would love to see what IntelrG could do with a good design in their pocket. If Intel had, say, adopted6M something like the Alpha in 1995 instead of striking out on their traditional K path of trying to build a complex design that'll knock everyone's socks offhM (iApx432), at least when the compiler technology comes together (i860, IA64), @ we'd already be using them for all our high-performance systems.   -- o+  `-_-'   In hoc signo hack, Peter da Silva.uE   'U`    "A well-rounded geek should be able to geek about anything."lL                                                        -- nicolai@esperi.org          Disclaimer: WWFD?   ------------------------------  # Date: Thu, 10 Jan 2002 01:40:18 GMTo* From: "Bill Todd" <billtodd@metrocast.net>F Subject: Re: Compaq's Board of Directors & their value to shareholders@ Message-ID: <6i6%7.97003$Yf.6362460@bin3.nnrp.aus1.giganews.com>  9 "Duane Sand" <Duane.Sand@mindspring.com> wrote in messagee& news:u5F_7.6783$762.68314@rwcrnsc54...   ...a  ? > The actions of W. Hewlett may be morally justifiable from thewD > point of view of an HP stockholder, but they really suck, from theE > point of view of fair dealings with the company they were proposingb > to become a partner with.S   ...w  < > This active public opposition by a director may be legally: > complying with the merger contract but it sure isn't the9 > package that Compaq thought they & HP were agreeing to.o  J Dear me:  that sounds an awful lot like how Alpha customers felt when theyK found out that Alpha's future wasn't quite what Compaq had promised them itu	 would be.h    Serves Compaq bloody right, IMO.   - bill   ------------------------------  $ Date: Wed, 9 Jan 2002 16:13:24 -0500+ From: "Rick Barry" <barry@star.zko.dec.com>o# Subject: Re: csws_php and Multinet?02 Message-ID: <Yn2%7.474$5Y4.14305@news.cpqcorp.net>  H ""Alan Winston - SSRL Admin Cmptg Mgr"" <winston@SSRL.SLAC.STANFORD.EDU>C wrote in message news:00A07C0E.A17D43C7@SSRL04.SLAC.STANFORD.EDU...l > comp.os.vmsers:, >d. > AlphaServer 800, VMS 7.2-2, Multinet 4.3-AX. >iJ > I just upgraded my Apache/CSWS/perl/mod_perl/mod_php versions current onI > the Compaq website.  Trying to load mod_php, Apache crashes; the servera log A > has an error from the image activator that it couldn't load ther php4_module. >sK > (This confused me because I didn't have any trouble doing this on my homeo > machine.)p >dK > When I tried running php_setup.com and then executing PHP by hand, I got:  >e > $ phpy7 > %DCL-W-ACTIMAGE, error activating image TCPIP$IPC_SHR ' > -CLI-E-IMAGEFNF, image file not foundm5 > $9$DKA0:[SYS1.SYSCOMMON.][SYSLIB]TCPIP$IPC_SHR.EXE;  > $o > L > Apparently  php is linked against a specific TCPIP Services image.  (I hadL > it on my home machine because I'm running TCPIP Services there.)  Is thereJ > any easy workaround for using php with Multinet?  (I presume I could get the E > source and figure out where it's calling TCPIP$IPC_SHR routines andn replace.H > those with equivalent Multinet calls and relink and hope I could still buildl+ > mod_php, but I've got other stuff to do.)z >a	 > Thanks,  >l	 > -- Alan   J The CSWS_PHP T1.0 kit was linked against TCPIP$IPC_SHR to resolve some DNSK APIs that are exported by the C run-time library. Unfortunately, these APIsaK are not guaranteed to be supported by other TCP/IP stacks. We've decided toyI use a different strategy for the production kit by dynamically activatingtI TCPIP$IPC_SHR rather than statically linking against it. For those stacks J that don't support the necessary DNS APIs, the PHP functions that use themJ (such as the SMTP extension) will not be available, but  PHP will load and# function correctly aside from that.a  
 Rick Barry) Compaq Secure Web Server Development Teamn OpenVMS Systems Software Group Compaq Computer Corporationd
 Nashua, NH   ------------------------------   Date: 10 Jan 2002 00:12:07 GMT- From: ukgaragescene@aol.com (UK Garage Scene)  Subject: DCL (F$GETQUI) Problem 9 Message-ID: <20020109191207.28750.00003654@mb-fe.aol.com>o  O I'm trying to create a dcl .com to extract all entrys created in one queue by aeO single user (USERX for example), then $SET ENT/HOLD  for the rest of the entrystL leaving USERX released for completion, then releasing the rest of the entrysE once the USERX entrys have all been completed.  Had a look in the DCLnN dictionary at the F$GETQUI lexical but it went straight over my head, too many" commands.  Can anybody help me?      ------------------------------  # Date: Thu, 10 Jan 2002 03:22:08 GMT 4 From: Tim Llewellyn <tim.llewellyn@blueyonder.co.uk># Subject: Re: DCL (F$GETQUI) Problemt0 Message-ID: <3C3D075A.77EBB1E4@blueyonder.co.uk>   UK Garage Scene wrote: > Q > I'm trying to create a dcl .com to extract all entrys created in one queue by a Q > single user (USERX for example), then $SET ENT/HOLD  for the rest of the entrystN > leaving USERX released for completion, then releasing the rest of the entrysG > once the USERX entrys have all been completed.  Had a look in the DCLeP > dictionary at the F$GETQUI lexical but it went straight over my head, too many! > commands.  Can anybody help me?y  ! yes, I am currently available :-)l  P alternatively, read the manual some more or look for postings here demonstratingM how to use F$GETQUI (I may well have posted one or more in the past, I'm surenP I saw something recently also). The examples in the manual are a decent starting point. h   regardss   -- n Tim.Llewellyn@cableinet.co.uk     C Standard disclaimer applies. My views in no way represent those of e! my employers or service provider.a   ------------------------------  # Date: Thu, 10 Jan 2002 04:21:28 GMTr1 From: "David J. Dachtera" <djesys.nospam@fsi.net>s Subject: Re: DCL whish listd' Message-ID: <3C3D1789.8F46B4DD@fsi.net>d   Tim Llewellyn wrote: >  > Fabio Cardoso wrote: > >r > > I just want this > >s$ > > $ DELETE/ENTRY=ALL/QUE=SYS$PRINT > >h > > Why not ???e > >'6 > because anyone worth their salt with DCL can write a > loop over F$GETQUI to do it?  H Yeah, F$GETQUI() *IS* the bane of the DCL coder's existence, but it doesH make certain convenience functions possible, within a few limits. I haveG one proc. that can reSUBMIT using the data from an existing (pending or D holding) entry, such as when changes are needed to a recurring batchF job, and you don't want the old code to run more time just to reSUBMITB itself and grab the new code. I have another to clear out retainedA entries (left over from a massive testing effort some years ago).s  C > Mind you, I can't see adding /entry=all would break any exisitingi- > functionality, so it would be nice I guess.p  H Agreed. I've been bitten by that one, also, but I usually find it easierH to simply SHOW QUEUE/FULL, DELETE/QUEUE and INIT/QUE to re-create it. Of# course, that's not always possible.a   --   David J. Dachterao dba DJE Systemst http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/e   ------------------------------  % Date: Thu, 10 Jan 2002 10:56:52 +0400t4 From: Valentin Likoum <valentin.likoum@ncc.volga.ru> Subject: Re: DCL whish liste4 Message-ID: <1829801283.20020110105652@ncc.volga.ru>  = On 09.01.2002 Fabio Cardoso <fabiopenvms@yahoo.com.br> wrote:    > I just want this" > $ DELETE/ENTRY=ALL/QUE=SYS$PRINT
 > Why not ???p  B   While we are on the topic, why not to show PID of the process in= SHOW QUEUE and SHOW ENTRY if job is executing. Something likey  4   Entry  Jobname         Username             Status4   -----  -------         --------             ------F     812  BCK             B_USER               Executing (PID:000046D1)F                                                         ^^^^^^^^^^^^^^A   I'm a bit lazy to search through SHOW SYSTEM output to find out F in which process certain entry is executing every time I need to check how this entry is doing.   Thank you.    -- .   Valentin Likoumc   valentin.likoum@ncc.volga.ru   ------------------------------  # Date: Thu, 10 Jan 2002 04:10:58 GMTc1 From: "David J. Dachtera" <djesys.nospam@fsi.net>e& Subject: Re: DCL wish list (of 1 item)' Message-ID: <3C3D1522.859FD972@fsi.net>C   Jan-Erik Sderholm wrote:  >  > $ dir somefile.tmp# > %DIRECT-W-NOFILES, no files foundr: > $ pipe dir/col=1 | search sys$input IP6/out=somefile.tmp > $ dir somefile.tmp >   > Directory SYS$SYSROOT:[SYSMGR] >  > SOMEFILE.TMP;1 >  > Total of 1 file. > $ typ somefile.tmp > TCPIP$IP6_SETUP.COM;1c > $i > - > Exacly *what* was you unable to duplicate ?    Jan-Erik Sderholm wrote:- >  > Or : > 7 > $ PIPE DIR | SEARCH SYS$INPUT SOMETHING /OUTPUT=F.LISn > B > That will realy create only create *one* F.LIS, not two version.   Does this answer your question?n   -- m David J. Dachterar dba DJE Systemsa http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/l   ------------------------------  # Date: Wed, 09 Jan 2002 19:47:37 GMTt2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)# Subject: Re: DECpc AXP 150 and VMS.o2 Message-ID: <t71%7.465$5Y4.14021@news.cpqcorp.net>  c In article <3C3C126F.B90D7A51@aaa.com>, Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com> writes:t  . :I have a "DECpc AXP 150" (type no : PB22H-CX,5 :Series no : BA55-A9) which has *always* been running 
 :OpenVMS.      So?p  F :It was actualy delivered from Digital as an OpenVMS server and fully  :supported as such.   G   That should officially be the DEC 2000 series, not the DECpc AXP 150.sG   The DECps AXP 150 series was sold for use (only) with Windows NT, andnJ   was regularly sold with I/O options that were incompatible with OpenVMS.  : :I can't remember having to do anything special with it to4 :run VMS. And most of it's "life" it was not running2 :as a hobbyist system. And it's a white (or *was*  :white when new) box.w  I   Um, so?  A whitebox is not officially SUPPORTED by OpenVMS Engineering t   for use with OpenVMS.   L   OpenVMS has certainly been successfully bootstrapped on certain platforms I   lacking official operating system support (eg: the Multia).  If OpenVMS I   should crater on an unsupported platform, we may or may not remedy the  $   particular problem(s) encountered.  K   For the list of platforms supported for use with OpenVMS, please see the c-   OpenVMS Software Product Description (SPD).n    2 :Might it be that there is some difference between, :"DECpc AXP 150" and "DEC 2000 Model 300" ??     Yes, there can be.      J   English can be a subtle language, and the phrasing that I have used (in L   the text that you have cited below) is quite careful and quite deliberate.   :Hoff Hoffman wrote: :>L :>   Hobbyists might or might not be able to get certain members and certainL :>   configurations of the DIGITAL Personal Workstation -a series, the DECpcL :>   150 AXP series, and various other "Whitebox" Alpha systems -- these areL :>   the Windows NT (only) Alpha systems -- to load SRM and to boot OpenVMS.    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Wed, 09 Jan 2002 19:53:49 GMTo2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)# Subject: Re: DECpc AXP 150 and VMS.t2 Message-ID: <hd1%7.467$5Y4.13926@news.cpqcorp.net>  T In article <3C3C2AF5.B68C24C0@127.0.0.1>, Nic Clews <sendspamhere@127.0.0.1> writes:  5 :Different name on the interchangeable plastic bezel.-# :Different part number (of course).C  @   Different testing.  Different support.  Different licensing.  <   Different default hardware packages.  Different ancillary =   kits (eg: ECU floppy).  And yes, a different badge.  (None u9   of which particularly means much to a hobbyist user, ofa
   course.)  2   The DEC 2000 series was the "universal" variant.  @   As I have likely stated elsewhere, I too was pleased when the C   "Whitebox" distinction and the slight-variant hardware offerings  B   were dropped -- it simplifies things for customers and even for C   operating system support.  But it does not alter the list of the p3   systems that are officially supported by OpenVMS.h  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Wed, 09 Jan 2002 21:59:43 GMTa* From: "Andy Stoffel" <acs@fcgnetworks.net># Subject: Re: DECpc AXP 150 and VMS.p@ Message-ID: <j33%7.62734$wa.4637542@bin6.nnrp.aus1.giganews.com>  ? "Hoff Hoffman" <hoffman@xdelta.zko.dec.nospam> wrote in messaget, news:t71%7.465$5Y4.14021@news.cpqcorp.net...O > In article <3C3C126F.B90D7A51@aaa.com>, Jan-Erik =?iso-8859-1?Q?S=F6derholm?=U <aaa@aaa.com> writes:t > 0 > :I have a "DECpc AXP 150" (type no : PB22H-CX,7 > :Series no : BA55-A9) which has *always* been runninge > :OpenVMS.a    G > :It was actualy delivered from Digital as an OpenVMS server and fullyt > :supported as such.   I >   That should officially be the DEC 2000 series, not the DECpc AXP 150. I >   The DECps AXP 150 series was sold for use (only) with Windows NT, andIL >   was regularly sold with I/O options that were incompatible with OpenVMS.  ? Hmmm.... I've been running a DECpc AXP 150 with VMS for 3 years = now. Not a bad little box once I replaced the NT-only devices < with VMS compatible ones. Faster WOULD be nice but for a oneC person stand-alone machine it does fine (usually...). Someday it'llg7 grow up and become a 2 CPU DS20E or "Itanium" based VMS6 system.r  < > :I can't remember having to do anything special with it to6 > :run VMS. And most of it's "life" it was not running3 > :as a hobbyist system. And it's a white (or *was*  > :white when new) box.m  6 >   Um, so?  A whitebox is not officially SUPPORTED by. >   OpenVMS Engineering  for use with OpenVMS.  7 Didn't that machine pre-date the "white box" machines ?t; Mine is standard-issue "light grey", unlike the white TLZ09e: I have attached to it (So I do know the color difference -9 white is like the foot of snow outside right now and greyEB is the color of the "road grime" on my car this time of year....).   -Andy- --   ------------------------------  * Date: Wed, 9 Jan 2002 23:17:46 +0000 (UTC) From: david20@alpha2.mdx.ac.uk# Subject: Re: DECpc AXP 150 and VMS.o+ Message-ID: <a1ij2q$kii$1@aquila.mdx.ac.uk>h  m In article <j33%7.62734$wa.4637542@bin6.nnrp.aus1.giganews.com>, "Andy Stoffel" <acs@fcgnetworks.net> writes:t >c@ >"Hoff Hoffman" <hoffman@xdelta.zko.dec.nospam> wrote in message- >news:t71%7.465$5Y4.14021@news.cpqcorp.net...rP >> In article <3C3C126F.B90D7A51@aaa.com>, Jan-Erik =?iso-8859-1?Q?S=F6derholm?= ><aaa@aaa.com> writes: >>J >>   That should officially be the DEC 2000 series, not the DECpc AXP 150.J >>   The DECps AXP 150 series was sold for use (only) with Windows NT, andM >>   was regularly sold with I/O options that were incompatible with OpenVMS.m >r@ >Hmmm.... I've been running a DECpc AXP 150 with VMS for 3 years> >now. Not a bad little box once I replaced the NT-only devices= >with VMS compatible ones. Faster WOULD be nice but for a one,D >person stand-alone machine it does fine (usually...). Someday it'll8 >grow up and become a 2 CPU DS20E or "Itanium" based VMS >system. >l= >> :I can't remember having to do anything special with it to 7 >> :run VMS. And most of it's "life" it was not runningi4 >> :as a hobbyist system. And it's a white (or *was* >> :white when new) box. >y7 >>   Um, so?  A whitebox is not officially SUPPORTED byr/ >>   OpenVMS Engineering  for use with OpenVMS.c >a8 >Didn't that machine pre-date the "white box" machines ?< >Mine is standard-issue "light grey", unlike the white TLZ09; >I have attached to it (So I do know the color difference -s: >white is like the foot of snow outside right now and greyC >is the color of the "road grime" on my car this time of year....).a >s >-Andy-  >--d    5 A colleague of mine has one which has always run VMS.dJ It predated the whitebox only for NT period. It was sold as a system which could run NT, OSF-1 or VMS.g  
 David Webb VMS and Unix team leader CCSS Middlesex University     ------------------------------  $ Date: Wed, 9 Jan 2002 22:59:51 -0600, From: "Rich Jordan" <rjordan@mindspring.com># Subject: Re: DECpc AXP 150 and VMS.g3 Message-ID: <a1j73l$qgn$1@nntp9.atl.mindspring.net>   E We have a PC AXP150 that was purchased new with Win-NT, along with aneG OpenVMS Base license, ADL user licenses, VAXcluster license, and DECnet J Endnode, along with the required VMS V6.1FT4 media kit (reportedly V1.5xxxI was not compatible with this box), all on the same PO and direct from DECtC (that was before they tiered us because we were small system folk).vK Supported or not (and we were told at the time it was, and in fact we stillnJ have software support for VMS on this system!) it has run quite well sinceH 1994 through numerous upgrades and hardware additions (note that all theJ original hardware: NIC, SCSI, video, etc are still in use with VMS V7.2-1,$ and I expect no problems with V7.3).  J Hoff, not arguing your statement, but DEC did tell us this was a supported config way back when.w   Rich Jordanv    ! Hoff Hoffman wrote in message ...e1 >In article <3C3C126F.B90D7A51@aaa.com>, Jan-Eriki2 =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com> writes: >H/ >:I have a "DECpc AXP 150" (type no : PB22H-CX,a6 >:Series no : BA55-A9) which has *always* been running
 >:OpenVMS. >s >  So? >nF >:It was actualy delivered from Digital as an OpenVMS server and fully >:supported as such. >iH >  That should officially be the DEC 2000 series, not the DECpc AXP 150.H >  The DECps AXP 150 series was sold for use (only) with Windows NT, andK >  was regularly sold with I/O options that were incompatible with OpenVMS.n >n; >:I can't remember having to do anything special with it tor5 >:run VMS. And most of it's "life" it was not runningO2 >:as a hobbyist system. And it's a white (or *was* >:white when new) box. >AI >  Um, so?  A whitebox is not officially SUPPORTED by OpenVMS Engineeringr >  for use with OpenVMS. > L >  OpenVMS has certainly been successfully bootstrapped on certain platformsJ >  lacking official operating system support (eg: the Multia).  If OpenVMSI >  should crater on an unsupported platform, we may or may not remedy theh% >  particular problem(s) encountered.s >pK >  For the list of platforms supported for use with OpenVMS, please see the,. >  OpenVMS Software Product Description (SPD). >A >N3 >:Might it be that there is some difference between[- >:"DECpc AXP 150" and "DEC 2000 Model 300" ??t >  >  Yes, there can be.  >c >cJ >  English can be a subtle language, and the phrasing that I have used (inA >  the text that you have cited below) is quite careful and quiteh deliberate.e >  >:Hoff Hoffman wrote:  >:> E >:>   Hobbyists might or might not be able to get certain members and  certain G >:>   configurations of the DIGITAL Personal Workstation -a series, the  DECpc I >:>   150 AXP series, and various other "Whitebox" Alpha systems -- these  arehD >:>   the Windows NT (only) Alpha systems -- to load SRM and to boot OpenVMS. >  > ' > ---------------------------- #includet' <rtfaq.h> -----------------------------tK >      For additional, please see the OpenVMS FAQ -- www.openvms.compaq.coma+ > --------------------------- pure personalt# opinion ---------------------------t0 >   Hoff (Stephen) Hoffman   OpenVMS Engineering hoffman#xdelta.zko.dec.com >D   ------------------------------  $ Date: Wed, 9 Jan 2002 04:22:36 -05005 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>r Subject: Re: DECWindows problemB2 Message-ID: <uu2%7.476$5Y4.14294@news.cpqcorp.net>  . Did you install the Motif layered product kit?    4 "Flash" <balzanotogliquesto@iol.it> wrote in message! news:a1hg1v$ia7$1@half.spin.it...m	 > Hi all,c >@F > I have installed an OpenVMS hobbyist kit on a VAXStation 4000/60 and9 > registered the license for it and the layered products.iG > I've tried to find some help on the Montagar site to start up the CDE  loginu > manager but at this site:  >TE > http://www.openvms.compaq.com:8000/73final/sysadmin/sysadmin_1.HTMLl >o' > the help is about Unix and not VMS!!!  >eD > Anybody can help me to find some documentation to set up the Login manager? >h > TNXQ > Luca >b >i   ------------------------------  # Date: Wed, 09 Jan 2002 22:14:07 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: Re: DECWindows problem 2 Message-ID: <Pg3%7.484$5Y4.14304@news.cpqcorp.net>  S In article <a1hg1v$ia7$1@half.spin.it>, "Flash" <balzanotogliquesto@iol.it> writes:r  E :I have installed an OpenVMS hobbyist kit on a VAXStation 4000/60 andt8 :registered the license for it and the layered products.L :I've tried to find some help on the Montagar site to start up the CDE login :manager but at this site:  )   Install the DECwindows kit for OpenVMS?E  B   There are two parts to DECwindows, the system-dependent portion A   that ships with and installs when you install OpenVMS, and the a=   seperately-installed and system-independent DECwindows kit.v  A   If/when the DECwindows kit is installed -- and if the problems pG   persist -- then please follow the DECwindows startup troubleshooting n%   sequence listed in the OpenVMS FAQ.   L :Anybody can help me to find some documentation to set up the Login manager?  +   http://www.openvms.compaq.com/doc/#decwine  J   As for setting up the Login Manager, You need actually do little beyond H   install the OpenVMS and DECwindows kits -- assuming supported hardware%   and software versions, of course...r  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Wed, 09 Jan 2002 19:39:08 GMTh2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)Y Subject: Re: Does anyone know a way of getting version 7.2  to support the Oxygen vx1 grar2 Message-ID: <w%0%7.464$5Y4.13882@news.cpqcorp.net>  T In article <3C3BDA8B.9000106@uakron.edu>, Francisco Moore <moore@uakron.edu> writes:  I :I just picked up a ds20 and have installed version 7.2 off the hobbyist eF :cd. My Oxygen Vx1 graphics card is not supported. I can find the Vx1 I :patches for just about every release except 7.2. Has anyone solved this / :problem before?  J   IIRC, the OpenVMS device drivers for the Oxygen VX1 assume an EV6 21264 K   Alpha microprocessor and associated operating system version, or a later H"   generation Alpha microprocessor.  E   AFAIK, the 3DLabs Oxygen VX1 drivers are available for the OpenVMS aE   releases with available and current support.  You might be able to lE   unpack the Oxygen VX1 driver kit for V7.2-* and get the drivers to -G   install and work on V7.2, but it would be equally reasonable to move mJ   to a later release (eg: V7.2-2), and (depending on the OpenVMS version) I   use the driver provided within OpenVMS and/or use the available driver a!   kit for the particular release.b  I   If you have to ask the question (and no offense is intended here), you oG   will probably want to move to V7.2-2 or V7.3 or (as available) later. G   (I expect the only reason you are asking this is because you have thenF   widget and you have V7.2, and you don't have a V7.2-2 or a V7.3 kit.F   I'd work on getting a more current OpenVMS kit first, before I tried   back-porting a driver kit.)   N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  $ Date: Wed, 9 Jan 2002 04:18:11 -05005 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>RY Subject: Re: Does anyone know a way of getting version 7.2  to support the Oxygen vx1 gram2 Message-ID: <lq2%7.475$5Y4.14067@news.cpqcorp.net>  5 "Francisco Moore" <moore@uakron.edu> wrote in messageu# news:3C3BDA8B.9000106@uakron.edu...i	 > Hi all, I > I just picked up a ds20 and have installed version 7.2 off the hobbyistlF > cd. My Oxygen Vx1 graphics card is not supported. I can find the Vx1I > patches for just about every release except 7.2. Has anyone solved thisr > problem before?R   Hoff gave a good explanation.T  E In short, when we have new hardware we tend to check it into the next I release, and where possible we generate patch kits for previous releases.bH Even though the bits may be exactly the same for each release we do thisJ for, it means that we have to build a release-specific kit so that all theJ tracking tools work, and so that we can reconstruct the exact bits that weH shipped for any given release - note that each release may use different compilers, etc.w  I To keep that managable, we only go back so far.  We try to make sure that-L the most widely used versions get a patch.  For V7.2x, which is the previousL minor version from the current one, we created a consolidated release calledD V7.2-2 where we will do most if not all future maintenance for V7.2x
 customers.  F Now, in this particular case, the graphics bits will work in any V7.2xH release.  So, go to the patch site and find a V7.2x version of an updateI kit, and you can extract the graphics components by hand, and put them inrG the right place.  But better still, would be to upgrade to V7.2-2 or topL V7.3 - I recommend V7.3 - which will get you the bits without doing anything special.   ------------------------------  # Date: Thu, 10 Jan 2002 01:12:51 GMTA2 From: "Zane H. Healy" <healyzh@shell1.aracnet.com>% Subject: Getting DEC ADA 3.5A to work C Message-ID: <nU5%7.153874$lV4.26317841@e420r-atl1.usenetserver.com>t  L OK, I'm about to go crazy here.  For some odd reason I've decided to installC DEC Ada 3.5A and try and learn something about ADA.  I followed theeH installation document, and ADA passes IVP.  However, I can't seem to get5 anything to compile and run.  I've got a really basic  'hello, world' program:D   $ type hello.ada with Text_IO; use Text_IO;   procedure Hello is begin"$   TEXT_IO.PUT_LINE ("Hello world!");   Text_IO.New_Line; 
 end Hello; $   I I pulled it out of a couple documents on ADA that I found on the web.  IthL will compile without any errors, it's when I try and link it that I run into	 problems.   L According to the manual one of the following should work to build HELLO.ADA.   $ ada helloc $ acs link helloE %ACS-I-CL_LINKING, Invoking the OpenVMS Linker for OPENVMS_AXP targete1 %LINK-W-MULTFR, multiply defined transfer addresse%         in module ADA$ELAB_HELLO filea* MONK$DKB500:[HEALYZH.WORK.ADALIB]HELLO.OBJ ;4% %LINK-W-NUDFSYMS, 1 undefined symbol:e$ %LINK-I-UDFSYM,         ADA$HELLO$M 9 %LINK-W-USEUNDEF, undefined symbol ADA$HELLO$M referenced.)         in psect $LINK$ offset %X00000020-%         in module ADA$ELAB_HELLO file-* MONK$DKB500:[HEALYZH.WORK.ADALIB]HELLO.OBJ ;49 %LINK-W-USEUNDEF, undefined symbol ADA$HELLO$M referenced-)         in psect $LINK$ offset %X00000020 %         in module ADA$ELAB_HELLO filea* MONK$DKB500:[HEALYZH.WORK.ADALIB]HELLO.OBJ ;4) %ACS-W-CL_WARDURLIN, Warnings during link7	 $ r hellon; %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual  address=000000000000& 0000, PC=0000000000000000, PS=0000001B/ %TRACE-E-TRACEBACK, symbolic stack dump followstP   image    module    routine             line      rel PC           abs PC      >  ADARTL                                     0 000000000004355C 000000007C04555C>                                             0 FFFFFFFF804C796C FFFFFFFF804C796C= ----- above condition handler called with exception 0000000C:0; %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtuala address=000000000000& 0000, PC=0000000000000000, PS=0000001B ----- end of exception message>                                             0 FFFFFFFF8009271C FFFFFFFF8009271C>                                             0 0000000000000000 0000000000000000>  HELLO  ADA$ELAB_HELLO                      0 0000000000020128 0000000000030128>  HELLO                                      0 0000000000020CE0 0000000000030CE0>                                             0 FFFFFFFF8045EEA4 FFFFFFFF8045EEA4>  HELLO  ADA$ELAB_HELLO                      0 0000000000020BE0 0000000000030BE0>  ADARTL                                     0 00000000000436E0 000000007C0456E0>  ADARTL                                     0 0000000000042E54 000000007C044E54>  ADARTL                                     0 000000000002DCF0 000000007C02FCF0>  HELLO  ADA$ELAB_HELLO                      0 0000000000020B5C 0000000000030B5C>  HELLO                                      0 0000000000020CE0 0000000000030CE0>                                             0 FFFFFFFF8045EEA4 FFFFFFFF8045EEA4>  HELLO  ADA$ELAB_HELLO                      0 00000000000200E0 00000000000300E0>  ADARTL                                     0 00000000000436E0 000000007C0456E0>  ADARTL                                     0 0000000000042E54 000000007C044E54>  ADARTL                                     0 000000000002DCF0 000000007C02FCF0>  HELLO  ADA$ELAB_HELLO                      0 000000000002005C 000000000003005C>  HELLO                                      0 0000000000020CE0 0000000000030CE0>  PTHREAD$RTL                                0 00000000000312FC 000000007BC072FC>  PTHREAD$RTL                                0 0000000000012B48 000000007BBE8B48>                                             0 FFFFFFFF8583B474 FFFFFFFF8583B474 $        $ acs load hello5 %ACS-I-CL_COMPILING, Invoking the Compaq Ada compilerh $ acs compile hellooJ %ACS-I-CL_COMPILEOK, All units and files current; no compilations required $ acs link helloE %ACS-I-CL_LINKING, Invoking the OpenVMS Linker for OPENVMS_AXP targets1 %LINK-W-MULTFR, multiply defined transfer addressn%         in module ADA$ELAB_HELLO file * MONK$DKB500:[HEALYZH.WORK.ADALIB]HELLO.OBJ ;4% %LINK-W-NUDFSYMS, 1 undefined symbol:k$ %LINK-I-UDFSYM,         ADA$HELLO$M 9 %LINK-W-USEUNDEF, undefined symbol ADA$HELLO$M referenced )         in psect $LINK$ offset %X00000020s%         in module ADA$ELAB_HELLO filer* MONK$DKB500:[HEALYZH.WORK.ADALIB]HELLO.OBJ ;49 %LINK-W-USEUNDEF, undefined symbol ADA$HELLO$M referenced+)         in psect $LINK$ offset %X00000020 %         in module ADA$ELAB_HELLO filee* MONK$DKB500:[HEALYZH.WORK.ADALIB]HELLO.OBJ ;4) %ACS-W-CL_WARDURLIN, Warnings during linka $       7 The most successful link I've managed is the following:c% $ link hello, ADA$PREDEFINED:text_io_eJ %LINK-W-USRTFR, image MONK$DKB500:[HEALYZH.WORK.ADALIB]HELLO.EXE;15 has no user r transfer address $   9 However, since it has no transfer address I can't run it..   $ run hello>! %DCL-E-NOTFR, no transfer addresse $     J So, does anyone have any idea what is wrong here?  Have I missed something obvious?   			Zaneo   ------------------------------   Date: 9 Jan 2002 21:23:00 -0600a- From: Kilgallen@SpamCop.net (Larry Kilgallen)u) Subject: Re: Getting DEC ADA 3.5A to work 3 Message-ID: <qFVYgQMswTiJ@eisner.encompasserve.org>y  x In article <nU5%7.153874$lV4.26317841@e420r-atl1.usenetserver.com>, "Zane H. Healy" <healyzh@shell1.aracnet.com> writes:N > OK, I'm about to go crazy here.  For some odd reason I've decided to installE > DEC Ada 3.5A and try and learn something about ADA.  I followed thetJ > installation document, and ADA passes IVP.  However, I can't seem to get7 > anything to compile and run.  I've got a really basicw > 'hello, world' program:   ? The commands you gave and the program you show worked for me on @ V3.5 variants on both VAX and Alpha without problem.  (Not 3.5A,5 but that should not matter with this simple program.)"  A Are you sure your ACS CREATE LIBRARY and ACS SET LIBRARY commandsl had no problem ?   ------------------------------  # Date: Thu, 10 Jan 2002 04:29:30 GMT 2 From: "Zane H. Healy" <healyzh@shell1.aracnet.com>) Subject: Re: Getting DEC ADA 3.5A to workmC Message-ID: <KM8%7.154187$lV4.26392526@e420r-atl1.usenetserver.com>   . Larry Kilgallen <Kilgallen@spamcop.net> wrote:A > The commands you gave and the program you show worked for me onCB > V3.5 variants on both VAX and Alpha without problem.  (Not 3.5A,7 > but that should not matter with this simple program.)o  C > Are you sure your ACS CREATE LIBRARY and ACS SET LIBRARY commands  > had no problem ?  I I get no errors from either command, in fact I just created new librariesTL under both my normal user account and as SYSTEM.  Both times it fails on the link.C  G What I can't figure out is how on earth SYS$TEST:ADA$IVP.COM manages to. work.a   			Zanet   ------------------------------  # Date: Thu, 10 Jan 2002 04:37:31 GMTe2 From: "Zane H. Healy" <healyzh@shell1.aracnet.com>) Subject: Re: Getting DEC ADA 3.5A to work C Message-ID: <fU8%7.154228$lV4.26394606@e420r-atl1.usenetserver.com>   1 Zane H. Healy <healyzh@shell1.aracnet.com> wrote:rI > What I can't figure out is how on earth SYS$TEST:ADA$IVP.COM manages toh > work.N  H Mystery solved.  It just goes to show how dangerous someone that doesn'tB know what they're doing can be.  I had HELLO.ADA in my Ada LibraryK directory.  Once I moved it, and myself out of thier it compiled and linkedH
 just fine!  H Finally!  I've been fighting this for way longer than I care to confess!   		Zane   ------------------------------  # Date: Thu, 10 Jan 2002 06:45:47 GMTn* From: "Bill Todd" <billtodd@metrocast.net>7 Subject: Re: Hey Intel, VMS is your ticket to high end!:C Message-ID: <vMa%7.211544$m05.18340379@bin5.nnrp.aus1.giganews.com>   : "Michael A. Foley" <mikiefoley@yahoo.com> wrote in message) news:u3p4522p89pc22@corp.supernews.com...e   ...A  L >     Let us all remember that a cheap PC in 1990 dollars was $4k, not $799.  I That recollection does not jibe well with the Leading Edge XT I bought inbH 1987 for $1900.  Granted, it only sported a 10 MB drive, but you did say 'cheap'.   - bill   ------------------------------    Date: 10 Jan 2002 01:29:41 +0800, From: Paul Repacholi <prep@prep.synonet.com>: Subject: Re: historical evidence of what went wrong at DEC- Message-ID: <87wuyr1lh6.fsf@prep.synonet.com>    robert@bonomi.invalid writes:a  ) > In article <3C3B5DBD.217B4B65@aaa.com>,y* > Jan-Erik Sderholm  <aaa@aaa.com> wrote:  & > [[.. snip a bunch of good stuff ..]]  B > >And if foo is some program you have written, you'll get exactlyB > >"*.c *.x", and it's up to foo to do whatever it want with it...  C > Which confirms that the VMS/DCL interpretation of wildcards is asN@ > inconsistant as the programmer(s) care to make it.  "directory< > entries", "related names", or "something (anything) else".  D > And, that there is *NO*WAY* -- from inspection of the command-line= > only -- to determine which interpretation applies, to which F > instance.  Specific knowledge of the particular context is required.  ? > The semantics of the wildcard construct depend utterly on the " > context in which it is employed.  D Not so, as the 'wild card' is never expanded in VMS! (We will ignoreB unix apps that have been poorly ported) Both file *specifications*E are used as templates for selecting file names. The first is comparednG with the name returned by the file system, the second takes the 'input'- name and transforms it.   E Yes, the programmer CAN make the whole thing a mess. DD has to be thea clasic case of that!   -- -< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.a@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  $ Date: Wed, 9 Jan 2002 11:54:09 -0800+ From: Mark Crispin <mrc@CAC.Washington.EDU>o: Subject: Re: historical evidence of what went wrong at DECT Message-ID: <Pine.NXT.4.50.0201091139450.562-100000@Tomobiki-Cho.CAC.Washington.EDU>  $ On 9 Jan 2002, Peter da Silva wrote:L > Christ, Mark, that's like saying that the fact that UNIX can't make a file9 > called "23/07/1960" means that it's a piece of garbage.   1 But UNIX *can* create a file called "23/07/1960"!n  A Don't be confused by the fact that "23" is a directory, "07" is aSI directory under "23", and "1960" is a file under "07".  From the point ofgI view of the application, it created a file called "23/07/1960" and it can  open a file by that name.:  . You have to try harder to whack UNIX, such as:3  . be able to create a file "23" and a file "23/07"g!  . be able to create a file "23/"c  I In the case of VMS, however, we're talking about an arbitrary prohibitiontE of a character in a filename for reasons unrelated to the filesystem.X  H The fallacy in prohibiting the use of a character in a filesystem due toG the dictates of a user interface is that it presumes that all access toEF the filesystem is through that user interface.  That necessarily makesI that filesystem less capable, and in client/server applications that lacko of capability is deadly.  C The UNIX filesystem is deficient enough with its theft of "/" for adI directory delimiter and NUL-termination.  But at least those deficienciestI have a legitimate filesystem-based reason, and aren't due to the whims ofo a command decoder.  
 -- Mark --   http://staff.washington.edu/mrc F Science does not emerge from voting, party politics, or public debate.   ------------------------------    Date: 09 Jan 2002 12:36:44 -08003 From: Eric Smith <eric-no-spam-for-me@brouhaha.com>e: Subject: Re: historical evidence of what went wrong at DEC0 Message-ID: <qhk7urgt2b.fsf@ruckus.brouhaha.com>  * "John S. Dyson" <dyson@iquest.net> writes: > Even TOPS10 allowed '*'.  I Yes, well, TOPS-10 allowed any 36-bit word to be used as a base filename,.@ and any 18-bit halfword *except* "SFD" (encoded in sixbit) as an
 extension.   ------------------------------  % Date: Wed, 09 Jan 2002 13:21:51 -0700 + From: Ben Franchuk <bfranchuk@jetnet.ab.ca>-: Subject: Re: historical evidence of what went wrong at DEC, Message-ID: <3C3CA65F.D21C1947@jetnet.ab.ca>   Peter da Silva wrote:e > . > In article <3C3B6BCD.3B96AD13@jetnet.ab.ca>,/ > Ben Franchuk  <bfranchuk@jetnet.ab.ca> wrote:nF > >I think file names should be a..zA..Z0..9_  Why else would you need > >more? > C > Well, my surname name is "da Silva". Not "daSilva" or "da-Silva".s > ( > What about someone like "Ren Gring"? > L > I wish Bell labs had been able to productise Plan 9. You could have a fileJ > name that contained latin, cyrillic, kana, and aramaic components if you	 > wanted.   5 Good point but is that not a flaw with OS but rather  $ the lack of a real standard for textF characters in the 1960's and 1970's of different languages. Now is the 'char'D data size of 8 bits outdated since you have many different langages?   -- s% Ben Franchuk - Dawn * 12/24 bit cpu *o+ www.jetnet.ab.ca/users/bfranchuk/index.html    ------------------------------  % Date: Wed, 09 Jan 2002 13:58:47 -0700 + From: Ben Franchuk <bfranchuk@jetnet.ab.ca> : Subject: Re: historical evidence of what went wrong at DEC, Message-ID: <3C3CAF07.E426A871@jetnet.ab.ca>   Eric Smith wrote:  > / > Ben Franchuk <bfranchuk@jetnet.ab.ca> writes:aG > > I think file names should be a..zA..Z0..9_  Why else would you neede	 > > more?  > & > What, you're not going to allow "."?  5 Ok I forgot about "." . But now that I think about iso, "." part of the file name or part of a path? -- t% Ben Franchuk - Dawn * 12/24 bit cpu *a+ www.jetnet.ab.ca/users/bfranchuk/index.html    ------------------------------    Date: 09 Jan 2002 22:20:23 +0100- From: rydis (Martin Rydstr|m) @CD.Chalmers.SEc: Subject: Re: historical evidence of what went wrong at DEC4 Message-ID: <xf18zb7mdbc.fsf@licia.dtek.chalmers.se>  9 >>>>> "PdS" == Peter da Silva <peter@taronga.com> writes:n  N PdS> In article <xGQ_7.346350$W8.12957707@bgtnsc04-news.ops.worldnet.att.net>,= PdS> David Thompson <david.thompson1@worldnet.att.net> wrote:a- >> Peter da Silva <peter@taronga.com> wrote : ? >>> You might as well complain that Lisp doesn't have a "goto".o  ) >> Um, Common LISP _does_ have goto.  <G>o  7 PdS> I don't *do* "Common Lisp", like I don't *do* C++.w  A GO has been in Lisp since 1958, at least according to the text atgB <URL:http://www8.informatik.uni-erlangen.de/html/lisp/mcc91.html>.   TTFN,2   'mra   -- aO rydis (Martin Rydstr|m) @CD.Chalmers.SE ; With a spirit soaring ten miles high,oO <URL:http://www.cd.chalmers.se/~rydis/> ; I sing loud words that make me cry...aG [Emacs] is written in Lisp, which is the only computer language that is G beautiful.  -- Neal Stephenson, _In the Beginning was the Command Line_    ------------------------------  # Date: Wed, 09 Jan 2002 21:30:33 GMTb* From: "Bill Todd" <billtodd@metrocast.net>: Subject: Re: historical evidence of what went wrong at DECB Message-ID: <ZD2%7.412617$C8.29957200@bin4.nnrp.aus1.giganews.com>  ( <robert@bonomi.invalid> wrote in message2 news:Bnx_7.784$Kf.14367@ord-read.news.verio.net...B > In article <Stu_7.19967$Oc.1701234@bin1.nnrp.aus1.giganews.com>,+ > Bill Todd <billtodd@metrocast.net> wrote:m   ...e  L > >On the subject of file deletion, I've often thought that deferred garbageF > >collection offered a kinder alternative that avoided such issues asI > >automatically saying 'I mean it' and then suffering later regrets.  ItV woulduJ > >allow deleted files to be recovered for (nearly) as long as their space wasxJ > >not needed elsewhere by the system (even across user logout, unlike the TOPSD > >example), which would give a user at least a reasonable chance of
 recoveringJ > >from a mistake without cluttering up the interface (i.e., delete reallyI > >means delete, but you *usually* have the opportunity to reconsider for  some > >period afterwards). > >aJ > >But it's intrinsically not predictable (e.g., a system with very little freeH > >storage space and high activity levels would be far less likely to be ableL > >to recover a deleted file than others).  Is that really a problem in this > >case? >IL > Short answer:   yes.  *IF* the users come to rely on the 'normal' behaviorK > of a system with lots of free-space, and low activity levels, they _will_s5 > have some *very*rude* surprises when they move to aa high-activity/low-free-'I > space system.  Reduction-to-absurdity example.  they want to see what'slH > in the directory *other* than a specific type of file.  so they deleteE > all of that type, do a listing, and 'undelete'.  *EXPECTING* to geto
 everythingL > back.  Guess what happens on a resource-starved system?   And, believe me,) > users *do* do this kind of 'silliness'.n  ; Well, I did ask for opinions, but you haven't convinced me.d  G Lacking major implementation impediments to the behavior I described, IfK think I'll do it:  I'd far rather give users with half a brain the (likely) K ability to recover from a rare mistake than go to extremes to protect thoseOF with no brain at all.  But perhaps an option could be provided to makeL recovery of a deleted file a privileged operation, so sysadmins who feel the8 way you do could prevent users from doing it themselves.   - bill   ------------------------------  # Date: Wed, 09 Jan 2002 22:10:37 GMTD* From: "Bill Todd" <billtodd@metrocast.net>: Subject: Re: historical evidence of what went wrong at DEC@ Message-ID: <xd3%7.62827$wa.4646680@bin6.nnrp.aus1.giganews.com>  ( "JD" <dyson@jdyson.com> wrote in message+ news:is__7.56$vb1.10800@news1.iquest.net...v >a@ > "David Jones" <JONESD@er6.eng.ohio-state.edu> wrote in message6 > news:a1ho3q$7du$1@charm.magnus.acs.ohio-state.edu...: > > In message <pPY_7.47$vb1.10190@news1.iquest.net>, "JD" <dyson@jdyson.com> writes:F > > >DCL BY DEFAULT has inconsistant parsing of wildcards in differing contexts > >0 ^^^^^^^^^^^^^^^^^^ > > >as NORMAL behavior. > > I > > There's nothing wrong with parsing wildcards differently in differentd	 contexts,tH > > it's only a problem if you parse them different in the same context. > >dF > That is a matter of YOUR definition (and probably those who like the inconsistantI > parsing of wildcards depending on context.)   If you want to use a wildF card asCL > a 'list of files' or 'expression specifying a target name transformation',	 then thatO; > defacto demonstrates that the semantics are inconsistant.0 >0L > Frankly, I used to like the DCL scheme also, and wrote a DCL before RSX11M had0J > one normally available (from scratch, as a CLI.)   After that, I learned	 the shell4L > approach, and was still biased towards the 'DCL' approach.   Even with theI > skeptcism and preference for the 'DCL' inconsistancy, I found the shell0 approachF > to be 'cleaner'.   Eventually, as I learned (at a technology, not an engineering level)- > the relative advantages, the shell won out.0 >CH > It has been many years since that happened, and the full context of my thinkingI > back in the early '80's is hard to re-construct, but the shell approach0
 has prettyL > much taken over, and is VERY consistant.   There are indeed abnormal casesJ > where both schemes can be tripped up, but IMO, consistant semantics win. >0I > If DCL 'rename' was well designed and consistant, it would be something0 likeH > this:   rename /newext:x *.c.   Perhaps the transformation wouldn't be	 specified0F > in the same way as a filespec.   There is a BIG difference between a transformation > and 'names'.  L This discussion seems much akin to debating how many angels can dance on the1 head of a pin, but perhaps I'm missing something.0  L Alternatively, perhaps the problem is that the same syntax is being used forK different purposes without adequate explanation - i.e., that in the command0L rename *.c *.x the second argument LOOKS like a 'wildcard specification' butJ in fact is not one (any more than '-' in a Unix command always announces a switch).  I If one adopts this attitude, there's no inconsistency in DCL's treatment,A: just a possibly-confusing use of identical constructs withL positionally-dependent meaning (but *any* operation which accepts, say, bothL an input spec and an output spec often uses the same constructs for both butG with different meanings).  But since those who actually use this syntax-G don't seem to be confused by it, if there's no issue of semantic purityL( involved then is there any real problem?   - bill   ------------------------------  $ Date: Wed, 9 Jan 2002 17:20:50 -0500 From: "JD" <dyson@jdyson.com>A: Subject: Re: historical evidence of what went wrong at DEC1 Message-ID: <mg3%7.98$vb1.13121@news1.iquest.net>I  5 "Bill Todd" <billtodd@metrocast.net> wrote in messagef: news:xd3%7.62827$wa.4646680@bin6.nnrp.aus1.giganews.com... >_* > "JD" <dyson@jdyson.com> wrote in message- > news:is__7.56$vb1.10800@news1.iquest.net...l > >gB > > "David Jones" <JONESD@er6.eng.ohio-state.edu> wrote in message8 > > news:a1ho3q$7du$1@charm.magnus.acs.ohio-state.edu...< > > > In message <pPY_7.47$vb1.10190@news1.iquest.net>, "JD" > <dyson@jdyson.com> writes:H > > > >DCL BY DEFAULT has inconsistant parsing of wildcards in differing
 > contexts > > >r > ^^^^^^^^^^^^^^^^^^ > > > >as NORMAL behavior. > > > K > > > There's nothing wrong with parsing wildcards differently in differenti > contexts,oJ > > > it's only a problem if you parse them different in the same context. > > >qH > > That is a matter of YOUR definition (and probably those who like the > inconsistantK > > parsing of wildcards depending on context.)   If you want to use a wildK	 > card as N > > a 'list of files' or 'expression specifying a target name transformation', > then thata= > > defacto demonstrates that the semantics are inconsistant.n > >dN > > Frankly, I used to like the DCL scheme also, and wrote a DCL before RSX11M > hadtL > > one normally available (from scratch, as a CLI.)   After that, I learned > the shellhN > > approach, and was still biased towards the 'DCL' approach.   Even with theK > > skeptcism and preference for the 'DCL' inconsistancy, I found the shelle
 > approachH > > to be 'cleaner'.   Eventually, as I learned (at a technology, not an > engineering level)/ > > the relative advantages, the shell won out.n > >HJ > > It has been many years since that happened, and the full context of my
 > thinkingK > > back in the early '80's is hard to re-construct, but the shell approache > has prettyN > > much taken over, and is VERY consistant.   There are indeed abnormal casesL > > where both schemes can be tripped up, but IMO, consistant semantics win. > >hK > > If DCL 'rename' was well designed and consistant, it would be somethingR > likeJ > > this:   rename /newext:x *.c.   Perhaps the transformation wouldn't be > specifiedmH > > in the same way as a filespec.   There is a BIG difference between a > transformation > > and 'names'. > N > This discussion seems much akin to debating how many angels can dance on the3 > head of a pin, but perhaps I'm missing something.- >-F It got blown out of proportion due to the statement that the semantics1 are different between differing positions on DCL.C   >3N > Alternatively, perhaps the problem is that the same syntax is being used forM > different purposes without adequate explanation - i.e., that in the command N > rename *.c *.x the second argument LOOKS like a 'wildcard specification' butL > in fact is not one (any more than '-' in a Unix command always announces a
 > switch). >I\ Well, the first one IS a wildcard specification.   The second one is a transformation.  :-).  - It is probably best to agree to disagree :-).e   John   ------------------------------  # Date: Wed, 09 Jan 2002 22:19:11 GMT-* From: "Bill Todd" <billtodd@metrocast.net>: Subject: Re: historical evidence of what went wrong at DECB Message-ID: <zl3%7.412650$C8.29990374@bin4.nnrp.aus1.giganews.com>  ( "JD" <dyson@jdyson.com> wrote in message+ news:xKY_7.46$vb1.10144@news1.iquest.net...y   ...c  1 > Broken OSes cannot handle upper and lower case.e  H Arguably correct - and VMS has fixed this with ODS-5 (I suspect it couldL have fixed it in ODS-2 from the beginning, had it chosen to preserve case inK the names it stored, and for all I know it may have done so somewhere alongv the way before ODS-5).  L However, a file system is *truly* broken if it *distinguishes* between upperK and lower case in file names (rather than just preserving the case the namevJ was created with and performing case-insensitive look-ups).  Unix has been# broken in this fashion since Day 1.a   - bill   ------------------------------  $ Date: Wed, 9 Jan 2002 17:35:39 -0500 From: "JD" <dyson@jdyson.com>f: Subject: Re: historical evidence of what went wrong at DEC1 Message-ID: <fu3%7.99$vb1.13438@news1.iquest.net>u  5 "Bill Todd" <billtodd@metrocast.net> wrote in messagef< news:zl3%7.412650$C8.29990374@bin4.nnrp.aus1.giganews.com... >s* > "JD" <dyson@jdyson.com> wrote in message- > news:xKY_7.46$vb1.10144@news1.iquest.net...s >t > ...n >i3 > > Broken OSes cannot handle upper and lower case.n >cJ > Arguably correct - and VMS has fixed this with ODS-5 (I suspect it couldN > have fixed it in ODS-2 from the beginning, had it chosen to preserve case inM > the names it stored, and for all I know it may have done so somewhere alongt > the way before ODS-5). > N > However, a file system is *truly* broken if it *distinguishes* between upperM > and lower case in file names (rather than just preserving the case the nameeL > was created with and performing case-insensitive look-ups).  Unix has been% > broken in this fashion since Day 1.i >tI Distingushing upper/lower case is GOOD.   Many computer languages do, andgR it is a superset to be able to distingush.   If any given userland program doesn'tJ want to distingush, then there are ways to do that on good OSes (including at the command level.)  W If an OS (or filesystem) is restricted to UPPER CASE only, then silly escape mechanismsaQ are needed to support the superset.   This unnecessarily lengthens filenames whenbY full upper/lower case is desirable.   Not only that, a fully escaped filename will likelyi have more length limitations!!!u  R There is NO REASON to fix that limitation deep in the OS/Filesystem code, when the/ limitation can be programmed at the user level.o   John   ------------------------------  # Date: Thu, 10 Jan 2002 00:15:36 GMTg From: robert@bonomi.invalidt: Subject: Re: historical evidence of what went wrong at DEC8 Message-ID: <I25%7.856$Kf.15687@ord-read.news.verio.net>  B In article <ZD2%7.412617$C8.29957200@bin4.nnrp.aus1.giganews.com>,) Bill Todd <billtodd@metrocast.net> wrote:i > ) ><robert@bonomi.invalid> wrote in messageo3 >news:Bnx_7.784$Kf.14367@ord-read.news.verio.net...6C >> In article <Stu_7.19967$Oc.1701234@bin1.nnrp.aus1.giganews.com>,t, >> Bill Todd <billtodd@metrocast.net> wrote: >l >... >dM >> >On the subject of file deletion, I've often thought that deferred garbageeG >> >collection offered a kinder alternative that avoided such issues asiJ >> >automatically saying 'I mean it' and then suffering later regrets.  It >wouldK >> >allow deleted files to be recovered for (nearly) as long as their space  >wasK >> >not needed elsewhere by the system (even across user logout, unlike the. >TOPSnE >> >example), which would give a user at least a reasonable chance ofp >recoveringtK >> >from a mistake without cluttering up the interface (i.e., delete reallyiJ >> >means delete, but you *usually* have the opportunity to reconsider for >somet >> >period afterwards).a >> >K >> >But it's intrinsically not predictable (e.g., a system with very littleo >free I >> >storage space and high activity levels would be far less likely to bem >able,M >> >to recover a deleted file than others).  Is that really a problem in this9	 >> >case?2 >>M >> Short answer:   yes.  *IF* the users come to rely on the 'normal' behaviorsL >> of a system with lots of free-space, and low activity levels, they _will_6 >> have some *very*rude* surprises when they move to a >high-activity/low-free-J >> space system.  Reduction-to-absurdity example.  they want to see what'sI >> in the directory *other* than a specific type of file.  so they delete F >> all of that type, do a listing, and 'undelete'.  *EXPECTING* to get >everything M >> back.  Guess what happens on a resource-starved system?   And, believe me,e* >> users *do* do this kind of 'silliness'. >5< >Well, I did ask for opinions, but you haven't convinced me. >cH >Lacking major implementation impediments to the behavior I described, IL >think I'll do it:  I'd far rather give users with half a brain the (likely)L >ability to recover from a rare mistake than go to extremes to protect thoseG >with no brain at all.  But perhaps an option could be provided to makeBM >recovery of a deleted file a privileged operation, so sysadmins who feel the 9 >way you do could prevent users from doing it themselves.y  E "for every fool-proof system, there exists a sufficiently determined    fool capable of breaking it."  E Users of systems with 'safety nets', come to rely on the safety nets.tH And blame the _system_ when the existant safety nets do *not* save them I from their own 'excessively creative' mistake.  It is especially traumticeG when they move to a _differently_configured_ system of the same 'type',0N that does -not- have the safety nets that they have come to know and *expect*.N (I, personally, have seen considerable of this last kind of havoc, with peopleP transitioning from a University system to a commercial time-sharing environment;K one with the same h/w, and same O/S, just radically different 'policies'. )yJ This class of users comes running to the admins, *regularly*, blaming the 2 system for failing to have 'adequate' safety nets.  H Users of systems *without* nets learn to rely on themselves.  They buildO their -own- "safety nets" -- to the degree *they* feel necessrary for whatever -L they are working on at the time.  And move those nets _with_ them, when theyG change environments.  This class of user will, on occasion, come to theC& admins, seeking _help_, *not* blaming.   ------------------------------   Date: 10 Jan 2002 00:04:26 GMT( From: peter@taronga.com (Peter da Silva): Subject: Re: historical evidence of what went wrong at DEC2 Message-ID: <a1ilqa$16ka$1@citadel.in.taronga.com>  , In article <3C3CA65F.D21C1947@jetnet.ab.ca>,- Ben Franchuk  <bfranchuk@jetnet.ab.ca> wrote:n6 >Good point but is that not a flaw with OS but rather % >the lack of a real standard for textiG >characters in the 1960's and 1970's of different languages. Now is thea >'char'tE >data size of 8 bits outdated since you have many different langages?c  H Well, yes, but the first example I gave doesn't require characters wider than 8 bits.   -- r@ Rev. Peter da Silva, ULC.	                                 WWFD?  F "Be conservative in what you generate, and liberal in what you accept" 	-- Matthew 10:16 (l.trans)h   ------------------------------   Date: 10 Jan 2002 00:07:21 GMT( From: peter@taronga.com (Peter da Silva): Subject: Re: historical evidence of what went wrong at DEC2 Message-ID: <a1ilvp$16tf$1@citadel.in.taronga.com>  0 In article <qhk7urgt2b.fsf@ruckus.brouhaha.com>,5 Eric Smith  <eric-no-spam-for-me@brouhaha.com> wrote: + >"John S. Dyson" <dyson@iquest.net> writes:s >> Even TOPS10 allowed '*'.n  J >Yes, well, TOPS-10 allowed any 36-bit word to be used as a base filename,A >and any 18-bit halfword *except* "SFD" (encoded in sixbit) as anO >extension.    What were the other 18 bits?   -- a@ Rev. Peter da Silva, ULC.	                                 WWFD?  F "Be conservative in what you generate, and liberal in what you accept" 	-- Matthew 10:16 (l.trans)o   ------------------------------   Date: 10 Jan 2002 00:03:12 GMT( From: peter@taronga.com (Peter da Silva): Subject: Re: historical evidence of what went wrong at DEC2 Message-ID: <a1ilo0$16iu$1@citadel.in.taronga.com>  0 In article <qhd70jgz4x.fsf@ruckus.brouhaha.com>,5 Eric Smith  <eric-no-spam-for-me@brouhaha.com> wrote: + >peter@taronga.com (Peter da Silva) writes:oM >> I wish Bell labs had been able to productise Plan 9. You could have a filerK >> name that contained latin, cyrillic, kana, and aramaic components if yous
 >> wanted.  B >I think you can do that using NTFS.  They use Unicode file names.  H Of course under NT it's quite difficult to even enter the full ISO8859.1G character set at a keyboard, so how you would enter such a file name isa3 an interesting question. In Plan 9 it was possible.a  F >I don't know any reason why you can't do it on Unix, for that matter.  E If you don't mind not being able to enter characters that contain thed5 ASCII value of "/" in one of their octets, you could.o  @ >You can use Unicode with UTF8 encoding.  Isn't that actually in >common use?  I You'd think it would be. But, no. There isn't a heck of a lot of softwarea% out there that can deal with wchar_t.   E I mean, even in NT the biggest use of Unicode seems to be in Internet  Information Server exploits.   --  @ Rev. Peter da Silva, ULC.	                                 WWFD?  F "Be conservative in what you generate, and liberal in what you accept" 	-- Matthew 10:16 (l.trans)    ------------------------------   Date: 10 Jan 2002 00:33:36 GMT( From: peter@taronga.com (Peter da Silva): Subject: Re: historical evidence of what went wrong at DEC2 Message-ID: <a1inh0$17m1$1@citadel.in.taronga.com>  B In article <zl3%7.412650$C8.29990374@bin4.nnrp.aus1.giganews.com>,) Bill Todd <billtodd@metrocast.net> wrote:eM >However, a file system is *truly* broken if it *distinguishes* between upperuL >and lower case in file names (rather than just preserving the case the name< >was created with and performing case-insensitive look-ups).  G How do you in general determine what the uppercase form of an arbitraryaD character is? What is the uppercase form of "/home/rne"? What about/ about ""? Should that match a file named "SS"?.   --  @ Rev. Peter da Silva, ULC.	                                 WWFD?  F "Be conservative in what you generate, and liberal in what you accept" 	-- Matthew 10:16 (l.trans)0   ------------------------------    Date: 09 Jan 2002 17:28:11 -08003 From: Eric Smith <eric-no-spam-for-me@brouhaha.com>r: Subject: Re: historical evidence of what went wrong at DEC0 Message-ID: <qhitabf104.fsf@ruckus.brouhaha.com>   I wrote:K > Yes, well, TOPS-10 allowed any 36-bit word to be used as a base filename,lB > and any 18-bit halfword *except* "SFD" (encoded in sixbit) as an > extension.  * peter@taronga.com (Peter da Silva) writes: > What were the other 18 bits?  D The other 18 bits in the directory entry were the pointer to the RIBD (Retrieval Information Block).  The RIB is like a Unix inode, exceptF that they can be in any cluster (or was it supercluster?) on the disk.B This sets an absolute upper bound of 2**18 (256K) files on a disk.  B A multi-disk structure can have more files since each disk has the, directory entries for the file on that disk.  D The MFD (Master File Directory, equivalent to a Unix root directory)@ contains one directory entry for each UFD (User File Directory),< including one for the MFD itself.  A UFD "filename" is a PPNB (Project/Programmer Number) in octal.  It is presented to the userA as the octal PPN, rather than as the sixbit characters in which ae' filename is normally displayed/entered.d  B I seem to recall that PIP (Peripheral Interchange Program) allowedD some means for the entry of filenames and extensions in octal, whichB was useful if you accidentally created a file with an unusual nameE and needed to rename or delete it.  The typical example is a filenamem, beginning with one or more space characters.  C [This is from memory of using the stuff 21 years ago, so I may wellu have the details wrong.]   ------------------------------  # Date: Thu, 10 Jan 2002 02:43:44 GMTi" From: bonomi@c-ns. (Robert Bonomi): Subject: Re: historical evidence of what went wrong at DEC8 Message-ID: <Ad7%7.859$Kf.15815@ord-read.news.verio.net>  . In article <uzo3niukt.fsf@spacy.Boston.MA.US>,5 Christopher Stacy  <cstacy@spacy.Boston.MA.US> wrote:eB >Some people seemed to be theorizing at length about how operatingA >systems that had a certain feature could not work right.  I saideF >that those were ignorant comments, based on my personal of experience@ >(spanning 21 years) with such operating systems (including ones$ >that they probably never heard of.) >cA >You decided that this was specifically about you, and wrote backg? >that I was ignorant and had a "lack of breadth of experience".   C You misquote.  I said you were DEMONSTRATING those characteristics.e There _is_ a difference.   > = >Whether or not you are ignorant about the technical matters 0< >originally being discussed, it's no matter of opinion about@ >whether you're ignorant about my personal history, yet you feel> >compelled to make authoritative derogatory comments about it.  I True.  and I did not comment on your history.  Only those characteristicsw! you were currently demonstrating.c  G Claiming things are 'imaginary' on the (apparent) basis that -you- have L not experienced them, does bespeak a degree of arrogance. as does dismissing: other people's _first_hand_ experience as "ignorant talk".  N If other people have experience of certian things happening, that you do not, M it would seem to indicate that their experience does have a broader base thanx yours.    A >I dunno, I started programming in 1973, and since then have donerC >lots of operating system design and development, and lots of other I >system, network, application, and research programming; also done systemmL >management for a number of different kinds (educational/research, military,G >commercial, industrial) of large and smaller sites; programmed in manytH >different languages, and probably used (at least a little) almost everyI >operating system worth mentioning in the last 29 years... I sure as hellaE >don't know nearly everything, but I think I can fairly be consideredlD >to have been around the block and have both some depth and breadth. >aD >I suppose I must lack experience relative to you: please elaborate.  N Not that it really matters, but you are correct. For starters, substitute 1966N in the above para, and 35 years -- the rest pretty much applies as is;  I alsoM have far more than my fair share of experience with 'wierd things' happening.eN In 68/69 I inadvertently triggered an IBM mainframe  hardware design oversightJ (it couldnt even really be called a 'bug'), that resulted in the affected L installation being down "hard", for nearly a week.  Every similiar installedM system _world-wide_ got an emergency ECO at IBMs expense as a result of that  5 incident, to insure it didn't happen to anybody else.   H I've seen *recurring* mainframe crashes due to the position of the Moon.L Well, actually it was the 'tide' that was the proximate cause, but that _is_K driven by the Moon's position. <grin>  It took the engineers _weeks_ to runu that one down,  L I've seen non-working electronic equipment that would magically 'fix' itselfJ when the repairman stepped into the same room.  He could stand outside theL door, and see for himself that it was not working -- step across the thresh-K old, and *bing* it started working.  Take one step back, and it'd go on the M fritz again.  "Someone else" could walk right up to the machine, and it would G stay broken.  It sounds crazy, I know.  I witnessed it.  As did others.fL The gear got fixed by the service tech have another person actually _do_ theL work, while he directed from outside the door-way.   No rational explanation" was _ever_ developed for that one.  L I found a mainframe O/S bug, where the vendor replied "yes, that's a genuineN bug.  However, since you're the only person in 15 years to have *ever* trippedI it, we're not going to do anything about it. DON'T DO IT AGAIN!" That bug-J merely infinite-looped the *entire* time-sharing subsystem.  There was no A simple/easy fix -- it was a "business" decision not to repair it.n  I I've programmed on IBM mainframes, all of the "BUNCH", Zerox Sigma 7, IBM.F sys/3, system 34/36/38, AS/400, early Crays, DEC pdp-8, -10, -11, -20,O Tandem, Stratus, Nixdorf, DG minis, IBM series/1 (ugh!), Convex, assorted work-eJ station class machines (sun, apollo, hp, DG aviion, to name  few), variousK micros under CP/M, CPM/68, MP/M, Apple (][, III, and Mac, missed the Lisa), J assorted embedded systems (e.g. 8048 based), SKY array processors, CharlesI River Data Systems, ModComp,  and a bunch more whos names I've forgotten.   I Anything from conventional business apps, to systems programming, device-uJ drivers, real-time process-control, and various 'exotic' stuff.  Wanna try, coding data-compression code in CICS COBOL ?  M I've done sys admin, tech support, and help-desk -- in university, time-share,/ service-bureau, and in-house business settings.s  N I _do_ have limited exposure to VMS, and havn't done telephone-switch innards E at all.  I've also never used "All-IN-1" on VAXen (or anything else).s  = >  robert> Limiting EXPUNGE (or equivalent) to user-initiated.C >  robert> *only*, is a 'luxury'.  It requires additional resources B >  robert> to support. In systems of the '70s, and early '80s, theC >  robert> incremental cost _was_ "non-trivial".  A user transitingeA >  robert> from a system with the luxuries to one without them --f@ >  robert> even if the hardware and O/S was the same, was in for  >  robert> some "rude suprises". >aC >If you think I was referring specifically to you as being ignorant5C >about how such systems work and how users behave on such operatinge
 >systems,   N Specifically, and to wit: DEC-2060 users coming from a university environment O to a commercial time-share service. Same CPU, same O/S (modulo a few minor rev. O levels).  Where I was the one fielding their irate phone calls, when the systemDN 'lost' things for them.  Specific names aren't relevant, as the University is O now using different gear (no surprise), and the time-share service is no longer M in that business.   The 'learning curve' tended to be around 4-6 months, withsJ 10-15 panic-calls/complaints per customer.  Admittedly, the last 1/3 or soK of them were along the lines of "did I just scr*w myself again?" as opposedb> to the "your system ate my data -- get it back!" type demands.    M I don't claim that *everybody* had these kinds of problems -- the majority ofN users did *not*. t        D >That would tend to counter my original posting, where I merely said@ >that those features worked out very well, and that people were : >ignorant if they imagined that it could not have been so.  5 That may be what you meant.  it is not what you said.t  H You dismissed the _entire_  discussion as "ignorant talk about imagined G problems" -- when, in fact, significant parts were factual reportage oft actual historical occurances.   < Things _can_ work "very well", and still have failure modes.  B The discussion started around 'failure modes' of a user interface,C from a human-factors viewpoint.   The particular failure mode beingtE diccussed can, does, and -has- happened.  Yes, the particular failure F mode used for the example is relatively infreuent,  one would even sayH 'rare'.  In fact, almost *all* the individual failures of the type underG dicussion *are* rare. *Cumulatively*, they contribute to the perception H of inconsistency of the user-interface.  Eliminating as many as possibleF of those 'rara avis' _does_ improve the perception of consistancy, and" 'ease of use' of the interface.        >r@ >In particular, since you've decided that I was referring to the@ >paragraph cited above, please describe your specific experienceA >with a base of users transitioning from an operating system that>@ >supported file-delete-but-only-ever-expunge-on-user-command and> >had lots of disk space to go with it, to one that was exactly? >the same except with less luxurious disk space.  What systems l? >are you thinking of, and what "rude surprises" would they get?   E See above.   specifically files in 'DELETEd, but not EXPUNGEd' status D for _days_ (University, ran EXPUNGE once over the weekend), vs 'goneD almost immediately' (service-bureau -- system-wide EXPUNGE ran everyG 5-10 minutes, regular schedule, *no* warning).  In addition for serviceeM bureau, EXPUNGE (per user) ran on session logout.  Customer has two sessions rK logged-in, and (accidentally) deletes file in one session,  Employee using ,K other session -ust-happens- to log out before the guy in the first session uK can finish typing in the UNDELETE.   guess what??   wanna take bets on who * they blame?i  ? >My experience was that they'd just be out of disk space a lot,n? >which was never a surprise on any computer back in those days,o  L In a service bureau environment, that was simply not an "acceptable answer".M On the other hand, having 'more than was needed' was an un-necessary expense.eK and, as you should be aware, disk was *not* inexpensive.  This led to 'very I agressive' space reclamation policies.  as well as 'small time increment'o storage billing.  G >If your contention is merely that users who come from better operatingeH >systems onto worse operating systems may become confused and frustratedG >because they're predisposed to expecting things to work well, then I'dlF >have to agree 100%. (They even do that when the operating systems areI >approximately "as good" or as crappy as each other, but just different.)t >    ------------------------------   Date: 9 Jan 2002 20:52 CST' From: carl@gerg.tamu.edu (Carl Perkins) : Subject: Re: historical evidence of what went wrong at DEC, Message-ID: <9JAN200220522593@gerg.tamu.edu>  S In article <PSY_7.48$vb1.10237@news1.iquest.net>, "JD" <dyson@jdyson.com> writes...  } i }"Bob Koehler" <koehler@encompasserve.org> wrote in message news:sEXGJbLGZSav@eisner.encompasserve.org... Z }> In article <vNI_7.809$Kf.14422@ord-read.news.verio.net>, reobert@bonomi.invalid writes: }> > tP }> > How can it be "consistent", when it's valid in some instances, and 'illegal }> > syntax' in others?  }>  @ }>    The documented consistent behaviour is different for inputI }>    and output files.  One could take the point of view that wildcards ,K }>    always mean "look for existing files for input", and "make new file" tK }>    for  output, whether the output file already has an existing version -
 }>    or not.J }> 0K }>    But the distinction is not DCL's, it's yours.  To DCL both are simplyi }>    lists of file names. n }>J }Nope, the second list of filenames in 'rename' isn't a LIST OF FILENAMES,J }but is a prototype of a specification of a new set of names.   This isn't! }the same as a list of filenames.w }  }Johnt  J The first one isn't a list of filenames either. It is a prototype that theG program uses to find which files are to be renamed. DCL does not expandiK wildcards to lists of filenames in any circumstance. The wildcard is passedr to the program.    --- Carl   ------------------------------  $ Date: Wed, 9 Jan 2002 22:14:05 -0500 From: "JD" <dyson@jdyson.com>F: Subject: Re: historical evidence of what went wrong at DEC2 Message-ID: <iz7%7.124$vb1.16724@news1.iquest.net>  [ "Carl Perkins" <carl@gerg.tamu.edu> wrote in message news:9JAN200220522593@gerg.tamu.edu...dU > In article <PSY_7.48$vb1.10237@news1.iquest.net>, "JD" <dyson@jdyson.com> writes...v > }f= > }"Bob Koehler" <koehler@encompasserve.org> wrote in message.- news:sEXGJbLGZSav@eisner.encompasserve.org...e\ > }> In article <vNI_7.809$Kf.14422@ord-read.news.verio.net>, reobert@bonomi.invalid writes: > }> >R > }> > How can it be "consistent", when it's valid in some instances, and 'illegal > }> > syntax' in others?S > }>B > }>    The documented consistent behaviour is different for inputJ > }>    and output files.  One could take the point of view that wildcardsL > }>    always mean "look for existing files for input", and "make new file"L > }>    for  output, whether the output file already has an existing version > }>    or not.  > }>M > }>    But the distinction is not DCL's, it's yours.  To DCL both are simplyn > }>    lists of file names. > }>L > }Nope, the second list of filenames in 'rename' isn't a LIST OF FILENAMES,L > }but is a prototype of a specification of a new set of names.   This isn't# > }the same as a list of filenames.s > }l > }John  >nL > The first one isn't a list of filenames either. It is a prototype that the5 > program uses to find which files are to be renamed.w >eO That is the same as a list of filenames.   Refer to almost every doco regardingu wildcard expansion.t  L It isn't consistant to use the same kind of spec for a 'list of names' being: virtual or literal and also as the transformation grammar.   John   ------------------------------   Date: 9 Jan 2002 21:08 CST' From: carl@gerg.tamu.edu (Carl Perkins)y: Subject: Re: historical evidence of what went wrong at DEC, Message-ID: <9JAN200221084771@gerg.tamu.edu>  ! "JD" <dyson@jdyson.com> writes...o\ }"Carl Perkins" <carl@gerg.tamu.edu> wrote in message news:9JAN200200163940@gerg.tamu.edu...2 }> Mark Crispin <mrc@CAC.Washington.EDU> writes.... }> }On Tue, 8 Jan 2002, Bill Gunshannon wrote:' }> }> On 8 Jan 2002, Bob Koehler wrote:oG }> }> >    VMS never let us do silly things like make a *.C, even ODS-5vF }> }> >    won't.  I'm still hoping COE won't, but I recall POSIX did.G }> }> I would guess, based on what I know of COE at this point, that ita- }> }> will require it to be a valid filename.  }> } 2G }> }VMS won't let you make a file called "*.C" under any circumstances?h }> } a2 }> }Proof positive that VMS is a piece of garbage. }> } 7 }> }-- Mark -- }> g: }> Your favorite OS will let you make a file called "*.C"? }>; }They were discussing the inability of some broken OSes notw: }supporting full upper/lower case.   Even TOPS10 supported  : No, they were not. It was the "*" not the case of the "C".  ? }the creation of the filename "*.C" literally if you ignore thesC }upper/lower case issue.   "*" could easily be put into a filename.u  C On VMS it can't. It isn't *impossible*, it is just impossible usingmB the normal interfaces. If you want, you could write a program that? bypasses all of the ususal methods supplied with the OS to deal @ with files and directly grab a file header and fill it with thatE junk, and then directly manipulate a directory file to insert the bad-F filename into it. I expect that you would then have a rather hard timeC dealing with the file since none of the standard tools is likely toeA handle it "correctly" (what exactly the term "correctly" means inhH reference to handling something which is itself incorrect is not clear -< at any rate, it won't do what *you* probably want it to do).  0 }> Proof positive that it is a piece of garbage. }> o6 }No.   Broken OSes cannot handle upper and lower case. }  }John   F VMS can handle mixed case filenames these days. It is case preserving,H but not case sensitive - it has never been case sensitive, unless it wasH before V3.7 or so when I first used VMS, but it has only recently (aboutE a year or so ago) gained a filesystem that preserves the case insteadkC of converting all filenames to uppercase. Not all sites use the newr" filesystem (I don't, for example).  E BTW, use of cases in filenames has nothing to so with the OS as such.iC It is a property of the filesystem. Saying what you just said makes C exactly as much sense as saying "the OS doesn't run on systems thate/ come in boxes that are green, so it is broken."    --- Carl   ------------------------------  $ Date: Wed, 9 Jan 2002 22:49:14 -0500 From: "JD" <dyson@jdyson.com>m: Subject: Re: historical evidence of what went wrong at DEC2 Message-ID: <f48%7.128$vb1.17427@news1.iquest.net>  [ "Carl Perkins" <carl@gerg.tamu.edu> wrote in message news:9JAN200221084771@gerg.tamu.edu...d# > "JD" <dyson@jdyson.com> writes...a^ > }"Carl Perkins" <carl@gerg.tamu.edu> wrote in message news:9JAN200200163940@gerg.tamu.edu...4 > }> Mark Crispin <mrc@CAC.Washington.EDU> writes...0 > }> }On Tue, 8 Jan 2002, Bill Gunshannon wrote:) > }> }> On 8 Jan 2002, Bob Koehler wrote: I > }> }> >    VMS never let us do silly things like make a *.C, even ODS-5tH > }> }> >    won't.  I'm still hoping COE won't, but I recall POSIX did.I > }> }> I would guess, based on what I know of COE at this point, that its/ > }> }> will require it to be a valid filename.e > }> }  I > }> }VMS won't let you make a file called "*.C" under any circumstances?r > }> } o4 > }> }Proof positive that VMS is a piece of garbage. > }> } e > }> }-- Mark -- > }> i< > }> Your favorite OS will let you make a file called "*.C"? > }>= > }They were discussing the inability of some broken OSes not < > }supporting full upper/lower case.   Even TOPS10 supported > < > No, they were not. It was the "*" not the case of the "C". > A > }the creation of the filename "*.C" literally if you ignore theaE > }upper/lower case issue.   "*" could easily be put into a filename.l > E > On VMS it can't. It isn't *impossible*, it is just impossible usingwD > the normal interfaces. If you want, you could write a program thatA > bypasses all of the ususal methods supplied with the OS to dealaB > with files and directly grab a file header and fill it with thatG > junk, and then directly manipulate a directory file to insert the badt > filename into it.h >-H It is best to be able to handle non-text filenames, because one person's! text is another persons non-text.s  B Regarding broken OSes, that was other people making the claim thatB I answered.   I tended to mention broken OS/filesystems that don'tC properly handle case sensitivty and try to fold upper case to lower.@ case (vice versa) during matching operations.   Filenames should= essentially be reasonable forms of text data.   Maybe a counto? field for a filename would be better than null termination, andm things like that.e  @ If you have case sensitivity at the OS/filesystem level, you canB implement case insensitivity easily (if you wish.)  I suggest that? it isn't worthwhile, because many current programming languagese tend to train case sensitivity.a  @ When I was an ignorant, first-time C user, I was bit by the caseC sensitivity, but I was using backwards OSes before then that didn'te& distinguish in most normal situations.  ? Again:  One person's binary data is another persons non-Englishe alphabet character.p   John   ------------------------------  % Date: Wed, 09 Jan 2002 14:20:16 -0800s0 From: Mark Berryman <Mark.Berryman@Mvb.Saic.Com>> Subject: Re: How to create the Flight object in DECnet Phase V, Message-ID: <3C3C51A0.5D6DA76E@Mvb.Saic.Com>   JF Mezei wrote:6 >  > Mark Berryman wrote:E > > The following NCL commands will create the flight object for you:  > >l8 > > CREATE NODE 0 SESSION CONTROL APPLICATION FLT$SERVER > >g? > > SET NODE 0 SESSION CONTROL APPLICATION FLT$SERVER ADDRESSESm > G > Does the NCP "emulator" in the decnet-5 allow one to create objects ?i   It does.  
 Mark Berrymanp   ------------------------------  % Date: Wed, 09 Jan 2002 17:24:59 -0500p- From: JF Mezei <jfmezei.spamnot@videotron.ca> > Subject: Re: How to create the Flight object in DECnet Phase V, Message-ID: <3C3CC339.585D0D6A@videotron.ca>  8 "Patrick MOREAU, CENA Athis, Tel: 01.69.57.64.40" wrote:N > And don't forget to download add-on Worlds and Hangars available on the DECW$ > archive (http://decwarch.free.fr).  J Where does one get the Flight developper's kit to develop a world ? I know, that the hangar compiler comes with flight ?  N  ( I was able to soup up Concorde to achieve escape velocity and travel to the moon at up to mach 80 :-),  H However, I do not know where to start if I want to build my own airport.J Another problem is that getting the various frequencies for the beacons isa next to impossible since world listings don't include those, only the physical buildings/runways.e  L And while I am at it, with the standard Concorde, how come I am unable to goN much beyond mach 1 ? The plane is supposed to reach Mach 2.5 and I can achieve9 1.5 while descending rathere steeply. What is the trick ?t   ------------------------------  % Date: Wed, 09 Jan 2002 14:31:48 -0800n0 From: Mark Berryman <Mark.Berryman@Mvb.Saic.Com>> Subject: Re: How to create the Flight object in DECnet Phase V, Message-ID: <3C3C5454.1DC7FE0F@Mvb.Saic.Com>   Bob Koehler wrote: > ^ > In article <3C3BAB2F.56BB97A9@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > > Mark Berryman wrote:F > >> The following NCL commands will create the flight object for you: > >>9 > >> CREATE NODE 0 SESSION CONTROL APPLICATION FLT$SERVER6 > >>@ > >> SET NODE 0 SESSION CONTROL APPLICATION FLT$SERVER ADDRESSES > >mI > > Does the NCP "emulator" in the decnet-5 allow one to create objects ?C > I >    Not in my experience.  The NCP translator will get you commands thatlB >    come pretty close, but I got closer studying the existing NCL" >    commands that create objects.  G SYS$UPDATE:DECNET_MIGRATE.EXE is a utility for translating NCP commandsd; to NCL commands - frequently very useful but sometimes not.t  E SYS$SYSTEM:NCP.EXE, as shipped with phase V, is a functioning utilityvG that allows one to actually use (as opposed to translate) a limited setaB of NCP commands in a phase V environment.  Had you entered the NCPB commands used by the flight install procedure to create the flightF object into this utility, the object would have been created.  But you@ still would have needed to know the NCL syntax to enter into theE NET$APPLICATION_STARTUP.NCL file in order for the object to survive ar reboot.o  G I assusmed JF's question referred to the latter program when I answerede1 that the emulator would, in fact, create objects.r  
 Mark Berrymanr   ------------------------------  % Date: Wed, 09 Jan 2002 19:36:29 +0000r< From: Andrew Swallow <andrew.swallow@eatspam.baesystems.com>9 Subject: Re: HP admits it will kill VMS if merger suceeds06 Message-ID: <3C3C9BBD.B3BD39AE@eatspam.baesystems.com>  
 cjt wrote: >  > Andrew Swallow wrote:O [snip]  >7 > > Is there a market for servers without keyboards andt > > screens? > I > I hope that's a rhetorical question.  Of course there is such a market.vM > Sun sells tons of such machines, and I would have thought Compaq does, too.e >   5 It was a rhetorical question.  Keyboard less machinesn0 are often forgotten, particularly when designing/ machines.  For instance to recover from a powerd failure just type BOOT.f --  7 _______________________________________________________a+ Andrew Swallow (7605) 2225   Cowes site, UK- andrew.swallow@baesystems.com    ------------------------------  # Date: Wed, 09 Jan 2002 20:59:28 GMTi# From: "John Smith" <a@nonymous.com>T9 Subject: Re: HP admits it will kill VMS if merger suceedsl> Message-ID: <Qa2%7.160032$pa1.47616738@news3.rdc1.on.home.com>  J Best thing Compaq could do right now is get the OpenVMS port done asap andJ then get Dell to offer it as the standard o/s on their Intel servers, withJ Windoze are the 2nd or 3rd choice o/s on the drop-down configuration list. Compaq would make millions.u      ? "Terry C. Shannon" <terryshannon@mediaone.net> wrote in messagev( news:3d4_7.16680$Sf2.153373@rwcrnsc52... >h@ > "John McLean" <mcleanj@swissonline.delete.ch> wrote in message1 > news:3C389F6B.1524EEAA@swissonline.delete.ch...i > > Hi John, > >i' > > Yes, it would be a very smart move.e > >e& > > - financial analysts would love it) > > - industry commentators would love it > > > - existing high-end customers would stop feeling neglected > > andyG > > - it will rid Compaq of the perception that it is ONLY a PC companyr > >o > > All very positive. > >sL > > Let Compaq concentrate on business PC's and sell them by the hundreds orB > > thousands rather than individually ... and pick up support and > > maintenance contracts too. > >cD > > I wish I had seen the report.  I went searching today in Yahoo'sB > > financial news and the message board but I found no reference. > >nJ > > As I see things, diluting the PC side of the business might dilute theG > > control that Houston has.  This is both at a board/management levelhJ > > (cries of "Compaq is leaving Houston") kind of thing and the influenceG > > of the loss-making PC faction - being local to the headquarters and 7 > > having good close contact with the decision makers.N > >sI > > I believe that this is the glaringly obvious thing that Compaq shoulde@ > > do.  To lose about $700 million on PCs this year is no joke. > > 8 > > The big question is - Will Compaq bite the bullet ?? > >  >vI > Sigh. Either they bite the bullet, or they shoot themselves in the foote with9 > the bullet. Actually in both feet with the same bullet.o > J > Amazingly, CPQ is still running Presario ads on teevee for the Christmas > holidays. Doh. >a >i   ------------------------------  # Date: Thu, 10 Jan 2002 03:13:04 GMTh4 From: Tim Llewellyn <tim.llewellyn@blueyonder.co.uk>9 Subject: Re: HP admits it will kill VMS if merger suceedsy0 Message-ID: <3C3D05F8.D432C56C@blueyonder.co.uk>   Andrew Swallow wrote:  >  > cjt wrote: > >l > > Andrew Swallow wrote:n > [snip] >  >9 > > > Is there a market for servers without keyboards and  > > > screens? > > K > > I hope that's a rhetorical question.  Of course there is such a market.cO > > Sun sells tons of such machines, and I would have thought Compaq does, too.  > >r > 7 > It was a rhetorical question.  Keyboard less machines 2 > are often forgotten, particularly when designing1 > machines.  For instance to recover from a powerh > failure just type BOOT.l  2 whats wrong with enabling autoboot in the console? -- g Tim.Llewellyn@cableinet.co.uk  g  C Standard disclaimer applies. My views in no way represent those of -! my employers or service provider.    ------------------------------  # Date: Thu, 10 Jan 2002 03:59:17 GMTs1 From: "David J. Dachtera" <djesys.nospam@fsi.net>-9 Subject: Re: HP admits it will kill VMS if merger suceeds8' Message-ID: <3C3D1265.2C6EB5AE@fsi.net>@   John Smith wrote:  > L > Best thing Compaq could do right now is get the OpenVMS port done asap andL > then get Dell to offer it as the standard o/s on their Intel servers, withL > Windoze are the 2nd or 3rd choice o/s on the drop-down configuration list. > Compaq would make millions.e  E ...which is exactly why they would never do it. Can't make a buck, ore produce a profit, y'know... ;-)e   -- r David J. Dachterau dba DJE Systemsc http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/a   ------------------------------  % Date: Wed, 09 Jan 2002 22:05:05 +0100s1 From: John McLean <mcleanj@swissonline.delete.ch>  Subject: HP, imaging and VMS5 Message-ID: <3C3CB080.F290D77F@swissonline.delete.ch>f  H In yesterday's CNet's report of Fiorina's keynote speech at the Consumer% Electronics Show in Las Vegas (at URL C http://news.cnet.com/news/0-1006-200-8412036.html) it states at onea	 point ...l  H "Her explanation was a rather oblique assurance that Compaq will help HP make better G cameras and other digital-imaging products and services, partly throught Compaq's leadershipo@ in 'fault-tolerant computing,' an area typically associated with million-dollar Unix servers."   9 I bet Tandem folk are as happy as VMS people to hear that:3 "fault-tolerant" is TYPICALLY associated with Unix.:  D Also on the subject of imaging, Fiorina as been known to talk of theF average consumer transferring the image from the camera to a Compaq PCG for processing and then printing it on a HP printer.  She seems to have8H forgotten that there is an increasing number of cameras that permit someA degree of editing and many permit direct connection to a printer.s  D We'll probably also see digital cameras doing the same thing as PCs,E becoming such a commodity that the profit margins are extremely thin.   F It seems that Fiorina and Compaq have a natural affinity in the targetG markets they prefer, the small-margin markets of home use.  Sounds liket/ Walter H has some good reasons to be concerned.      John McLeane   ------------------------------  $ Date: Wed, 9 Jan 2002 04:39:53 -05005 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>   Subject: Re: HP, imaging and VMS2 Message-ID: <JK2%7.479$5Y4.14280@news.cpqcorp.net>  > "John McLean" <mcleanj@swissonline.delete.ch> wrote in message/ news:3C3CB080.F290D77F@swissonline.delete.ch...e >    snip  F > Also on the subject of imaging, Fiorina as been known to talk of theH > average consumer transferring the image from the camera to a Compaq PCI > for processing and then printing it on a HP printer.  She seems to have J > forgotten that there is an increasing number of cameras that permit someC > degree of editing and many permit direct connection to a printer.  >iF > We'll probably also see digital cameras doing the same thing as PCs,G > becoming such a commodity that the profit margins are extremely thin.  >e  J While there are some limited things you might build into a digital camera,F and while there are any number of special-purpose attachments to allowG things like simple printing of the picture - downloading digital cameratC images to a PC will probably remain the most common way of storing,J6 manipulating, publishing, and printing digital images.   ------------------------------  % Date: Wed, 09 Jan 2002 18:13:51 -0500M- From: JF Mezei <jfmezei.spamnot@videotron.ca>   Subject: Re: HP, imaging and VMS, Message-ID: <3C3CCEA9.E7A5B74D@videotron.ca>   John McLean wrote:F > We'll probably also see digital cameras doing the same thing as PCs,G > becoming such a commodity that the profit margins are extremely thin.l > H > It seems that Fiorina and Compaq have a natural affinity in the targetI > markets they prefer, the small-margin markets of home use.  Sounds likea1 > Walter H has some good reasons to be concerned.r  M Agreed. The companies that will be succesful in the cameras are the ones thatuN are already succesful in cameras (eg: Japanese). There is one good reason. YouN might replace the backplate with a CCD plate, but you still need the lens. AndN the lens is the critical part of a camera. Does HP have lens making facilitiesH ? If it must purchase its lenses from Nikon or some other outfit, can it4 really compete against those same japanese outfits ?  L Unless, of course, you aim is to capture the "cheap family pictures" market,L in which point you are talking about low quality cameras best made overseas.  ! I just feel bad for Kodak though.    ------------------------------   Date: 9 Jan 2002 16:18:01 -0600f+ From: kuhrt@encompasserve.org (Marty Kuhrt)i+ Subject: Re: OpenVMS 7.2 - Slow Queman ????i3 Message-ID: <1LYLaVqQ37uZ@eisner.encompasserve.org>a  9 I've been noticing this problem recently, too.  VMS V7.3.a  ? When I get to a critical mass of jobs in the queue (and I don'tm@ know what the exact number "critical mass" is) all queue related8 commands will stall for long periods of time.  I finallyA correlated it to when the journal file was being "refilled".  Thea@ system would decide that it needed to create a new journal file,> rename the old one to _old, create a new one, and populate it.> While that happened all queue related activity would come to a? halt.  Depending on the size of the original file it might take  30 to 45 minutes to complete.a  @ I moved the queue related files to their own disk with about 20G? free, so freespace is no longer an issue.  This "disk" is a sixa> disk array used only for queue activity, so performance should8 not be a problem.  I did increase the performance of the? "refills" by setting the disk where the journal file resided toa= nohighwater, but never found the root cause.  I now make sure ? that no more than 5000 jobs are in the queue at one time, which @ has cut down on the size of the rebuild, but not the frequency. @ I just checked the three systems this happens on and the journal? file is less than five minutes old on all three, so it is stillg@ going on.  Previous uses of the MC JBC$COMMAND DIAG attempt at a fix didn't make a difference.a  @ I've been buzy putting out other (unrelated) fires, so I haven't logged a call yet.  S In article <3C3ABFAD.5E96DF5C@compaq.com>, Guy Peleg <guy.peleg@compaq.com> writes:.1 > Have you checked the size of the journal file ?.K > Large journal files might cause this behavior. Please try the following :B >  > $MC JBC$COMMAND> > JBC$COMMAND> DIAG 7u > JBC$COMMAND> EXITe >  > Guy, >  > Joel Loveless wrote: > D >> Do you have some sort of disk defrag utility running. We had thisH >> problem when the DEC defrager was working on the queue manager master >> file. >>9 >> On Mon, 7 Jan 2002 07:52:18 -0800 (PST), Fabio Cardosoa$ >> <fabiopenvms@yahoo.com.br> wrote: >>3 >> >I noticed a strange problem with my queues lastp- >> >friday. It happened a few weeks ago, too.  >> > >> >When I tried to displayt >> > >> >$ SHOW QUE any-queue >> >4 >> >The command didnt show anything.  It freezed.=206 >> >I tried a lot of queues but I had allways the same >> >problem. >> >7 >> >After a period (about 5-10 minutes since I noticed)C >> >, the displays returned ok.l >> > >> >I triedl >> > >> >$ SHOW ENTRY >> >! >> >and had the same symptoms.=20l >> > >> >Do you know anything ? >> > >> > >> >Regards  >> > >> >=3D=3D=3D=3D=3DpP >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >> >=3Da >> >F=E1bio dos Santos Cardoso >> >OpenVMS System Manager >> >Rio de Janeiro - Brazilr >> >fabiopenvms@yahoo.com.brP >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >> >=3Da >> >6 >> >__________________________________________________ >> >Do You Yahoo!?* >> >Send FREE video emails in Yahoo! Mail!% >> >http://promo.yahoo.com/videomail/e >    ------------------------------   Date: 9 Jan 2002 16:36:22 -0600O+ From: kuhrt@encompasserve.org (Marty Kuhrt)e= Subject: Re: OpenVMS on PWS-a (was: Re: Alpha 21164 and 7.3?)r3 Message-ID: <8XwFMuRR$blF@eisner.encompasserve.org>s  T In article <3C3A0FEF.615C9A8@gmx.ch>, Didier Morandi <Didier.Morandi@gmx.ch> writes: > Hoff Hoffman wrote:r > @ >>   re: OpenVMS on DIGITAL Personal Workstation (PWS) -a series >> SL >>   As I might have commented once or twice before, OpenVMS is not reliableJ >>   on and is not supported on the DIGITAL Personal Workstation -a seriesN >>   boxes.  Please use these for Microsoft Windows NT (as they were intended)& >>   or maybe for Linux.  Not OpenVMS. > K > Are you saying that I can install an INTEL WNT OS on an Alpha system??? IoP > thought there was a 64bits WNt version (that was cancelled as we all know) for > the Alpha. >  > D. > G > PS: someone around here has a (unsupported) 64bits WNT distrib??? :-)   > Oodly, enough, the PWS 500 I bought on Ebay a while back had aB Windows 2000 Professional for Alpha (Microsoft Internal Use Only) ? CD in the CD drive when it arrived.  I didn't try to install itB@ because I could give a rodents buttocks about any Billware, but * it does indicate that it is still around.    ------------------------------   Date: 9 Jan 2002 14:14:40 -0600N+ From: young_r@encompasserve.org (Rob Young) > Subject: Re: OT: Sun To Drop/Delay Intel Support For Solaris 93 Message-ID: <oJujCuFS8Jw$@eisner.encompasserve.org>-   In article <kT%_7.10410$cD4.21471@www.newsranger.com>, Simon Clubley <simon_clubley@remove_me.altavista.co.uk-Earth.UFP> writes:M > On Wed, 09 Jan 2002 14:36:57 GMT, in article <dAY_7.5537$Oh1.46691@insync>,o > Jerry Leslie wrote:R >>8 >>   http://www.nwfusion.com/news/2002/0108sunintel.html5 >>   Sun to drop Intel support in Solaris 9, 01/08/02h >>6 >>   http://news.cnet.com/news/0-1003-200-8409777.htmlB >>   Sun delays Solaris 9 for Intel chips -  Tech News -  CNET.com > G > Yes, all the Linux fans probably love Sun right now for eliminating a K > competitor to Linux. (The Intel x86 version of Solaris was also availableoH > for free download and that download has been pulled off Sun's website;I > only the Sparc download remains. You can still buy the packaged versione( > of Solaris 8; the US price is 45 USD). > M > It's interesting that some of the comments in comp.unix.solaris and relatedhG > newsgroups are along of the lines of: that potential users of SolarisTJ > will shortly have no way of very cheaply evaluating Solaris and that youM > will have to buy proprietary Sparc hardware to run Solaris. They also pointa= > out that such hardware is a lot cheaper than it used to be.. >  > Sound familiar ? :-) >   @ 	Very! And predictable!  Sun never jumped on the IA64 bandwagon,D 	hence focus on UltraSparc hardware.  There are higher margins thereE 	and short term this is wise.  Long term, they have an infrastructuren; 	that gets costly to support.  It may be a simple thing butLI 	selling the Alpha IP to Intel in the long term may not be bad.  Idea is SH 	when server margins decline to where Dell wants them to be, Sun is hurt> 	the most as the CPU infrastructure costs are there for Sun toD 	maintain.   Meanwhile, HP and Compaq add value by designing server G 	guts and popping in Intel parts.  When switches come to IA64 CPUs the mB 	server guts get less complicated and so hopefully they move some E 	Server gut designers to Storage gut designers or somewhere... maybe y 	out the door.  D 	Now before everyone gets jumpy... my hope had been that Alpha staysC 	above the fray (and they are in the near-term).  But long term, it G 	may prove that a 32 processor IA64 server 4 years from now would carryiA 	the processing needs of 98% of companies... so that extra 40-50%dB 	Alpha performance differential wouldn't be spinning enough heads.  E 	There are some very complicating factors here.  Compaq in purchasingB? 	Tandem, then Digital certainly knew that PCs and Intel serversnH 	certainly wouldn't be a very good near term (5-7 years) business model E 	hence the desire to get into services and true Enterprise computing.a9 	Where they are going from here is evolving in real-time.e   				Rob    ------------------------------  % Date: Wed, 09 Jan 2002 16:55:35 -05002( From: David Froble <davef@tsoft-inc.com>> Subject: Re: OT: Sun To Drop/Delay Intel Support For Solaris 9* Message-ID: <3C3CBC57.10006@tsoft-inc.com>   Rob Young wrote:    G  > 	Now before everyone gets jumpy... my hope had been that Alpha stays F  > 	above the fray (and they are in the near-term).  But long term, itD  > 	may prove that a 32 processor IA64 server 4 years from now wouldC  > carry 	the processing needs of 98% of companies... so that extrauE  > 40-50% 	Alpha performance differential wouldn't be spinning enoughe	  > heads.n  I Sorry Rob, but such arguments are a bit too much like the arguments from oG the windoz advocates about 'when' windoz gets 'good enough'.  I didn't _G buy those arguments as a reason to move from VMS to windoz, and I have s+ the same problems with the Ia-64 arguments.   I The 4 years you're talking about brings us to 2006, and frankly, the big  I thing is giving up 4 years of progress, in the unlikely event that IA-64 mH will match in 2006 what Alpha can do today.  If it doesn't get that far ( in 4 years, then the loss is even worse.  H Regardless of Intel's money, anybody that thinks IA-64 will not already H have lost the contest to Power4 and possibly others is just being blind I to reality.  IA-32, from Intel or AMD, or possibly others, will continue  D to be the volumn chip.  There's nothing imaginable that will change G this.  If Intel tries to force the issue, I for one will be buying AMD iD stock.  There is no way that MS will try to limit their market.  No  percentage there for them.  H There's a real good chance that all the hype from Intel, HP, and Compaq 0 will come to nought, and that IA-64 will crater.   Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------   Date: 9 Jan 2002 19:11:39 -0600u+ From: young_r@encompasserve.org (Rob Young)a> Subject: Re: OT: Sun To Drop/Delay Intel Support For Solaris 93 Message-ID: <T1Us6qg2VlpU@eisner.encompasserve.org>d  U In article <3C3CBC57.10006@tsoft-inc.com>, David Froble <davef@tsoft-inc.com> writes:s > Rob Young wrote: >  > I >  > 	Now before everyone gets jumpy... my hope had been that Alpha stays H >  > 	above the fray (and they are in the near-term).  But long term, itF >  > 	may prove that a 32 processor IA64 server 4 years from now wouldE >  > carry 	the processing needs of 98% of companies... so that extra G >  > 40-50% 	Alpha performance differential wouldn't be spinning enougho >  > heads.  > K > Sorry Rob, but such arguments are a bit too much like the arguments from iI > the windoz advocates about 'when' windoz gets 'good enough'.  I didn't tI > buy those arguments as a reason to move from VMS to windoz, and I have l- > the same problems with the Ia-64 arguments.m >   C 	But it isn't without precendence, nor without supporting examples.oA 	Today, UltraSparc servers are selling well and Slowaris is still,F 	the number #1 Unixcks.  UltraSparc as a CPU is no better than 4th in G 	most/all benchmarks.  My point there is that much cheaper and adequates@ 	performance will win the day.  VAX became expensive and slow in* 	comparison to most boxes circa 1986-1989. 	w 				Rob    ------------------------------  # Date: Thu, 10 Jan 2002 04:28:00 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>c> Subject: Re: OT: Sun To Drop/Delay Intel Support For Solaris 9' Message-ID: <3C3D1920.EDA1CB0B@fsi.net>h   Jerry Leslie wrote:  > 8 >    http://www.nwfusion.com/news/2002/0108sunintel.html5 >    Sun to drop Intel support in Solaris 9, 01/08/02i > 6 >    http://news.cnet.com/news/0-1003-200-8409777.htmlB >    Sun delays Solaris 9 for Intel chips -  Tech News -  CNET.com  B BLAST! ...and I wanted to offer Solaris/Intel along with Linux andD FreeBSD on custom-built servers and desktops. The idea is to be 100%E Micro$lop free (unfortunately, people tend to read that as "Micro$lop 1 100% free" - so, I gotta work on that some more).y  A Then again, I wonder what it would take to port Koffice to VMS...    -- 8 David J. Dachtera1
 dba TUXputersi (no website yet)   dba DJE Systemse http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  $ Date: Wed, 9 Jan 2002 19:10:28 -0500! From: "me" <wicklinedd@erols.com>n' Subject: Reel to Reel recorder questionl+ Message-ID: <a1in3t$fq6$1@bob.news.rcn.net>n  H I got a VS400-90 but together to decode a DDS Vax tape.  Now another guyK need to try to read some old Reel-to-Reel tapes from a Vax.  How would I goAJ about this I don't know anything about the format for 1/2 Tape.  One quickF search of COMPAQ shows a TSZ07 SCSI which should work but for very oldF tapes, (They list as coming from a MVII, VMS5.3, nothing else else theJ actual save set file name and backup contents).  I do have access to a DOSI Proprietary interface.  What If somehow DOS TAR'd the tape to a file theni# FTP'd the TAR to VAX for restoring?t   Dave   VMS newbie and atwork advocate   ------------------------------  # Date: Wed, 09 Jan 2002 20:42:28 GMT # From: "John Smith" <a@nonymous.com> C Subject: Re: Samsung ordered to pay $73.5 million for mismanagemento> Message-ID: <UW1%7.159923$pa1.47603469@news3.rdc1.on.home.com>  K Both Palmer and Capellas should be forced to give back the money they spentlK on slick suits, and Palmer should be forced to pay back all the money spendo< on his big hair...Capellas get a 'bye' on this count though.  K I wonder if Officers & Directors liability insurance can be made to pay forcK stupid executive tricks? Maybe we can all profit from it though...if we sueh0 for breach of contract based on broken promises.  7 "Arne Vajhj" <arne.vajhoej@gtech.com> wrote in message # news:3C3C69C5.140C05AF@gtech.com...a > Larry Kilgallen wrote:J > > http://www.azcentral.com/business/articles/breaking/1228samsung28.html > >tG > > SEOUL, South Korea - In a landmark ruling, a South Korean court hasnK > > ordered 10 executives from Samsung Electronics Co. to pay $73.5 millionl4 > > back to the company for mismanaging its affairs. > >mF > > The decision handed down Thursday marked the first time that South@ > > Korean business executives were held legally responsible forL > > mismanagement, which has caused serious financial losses to South Korean > > companies and shareholders.n >.A > Anyone care to estimate what Palmer & Capella should pay back ?  >m > :-)  >s > Arne   ------------------------------  % Date: Wed, 09 Jan 2002 17:54:31 -0500f- From: JF Mezei <jfmezei.spamnot@videotron.ca> C Subject: Re: Samsung ordered to pay $73.5 million for mismanagement , Message-ID: <3C3CCA23.2FB47333@videotron.ca>   John Smith wrote:m > M > Both Palmer and Capellas should be forced to give back the money they spentoM > on slick suits, and Palmer should be forced to pay back all the money spend > > on his big hair...Capellas get a 'bye' on this count though.  L If Palmer merely executed a plan set forth by his bosses, then should Palmer be held responsible ?oH Similarly, if Capellas is merely executing orders from Ben Rosen, should Capellas be held responsible ?  L I say YES. They accepted the job, the title and the responsability.  If theyK tolerate being controlled by others because that is the only way they couldsN have gotten that plush job, then they are still responsible for accepting thatQ job and should be held responsible for the poor decisions they were told to make.e  N Furthermore, in the case of Capellas, he has surrounded himself with the typesI of people he wanted. So the fact that Winkler and friends are so high andiF respocted while folks like Marcello are ignored reflects on Capellas's2 mentality. He is therefore to be held responsible.  N If Capellas really thought that the Digital poroducts were the key to Compaq'sN success, he would have brought marcello with him to investor presentations andL have Marcello talk about the great advantages Compaq's products have againstN competitors, instead of bringing Winkler who talks about how Windows will rule
 the world.  L Where there is a will, there is a way. And Capellas clearly like the idea ofJ windows ruling the world, otherwise he would not have tolerated Winkler in that position for very long.   ------------------------------  $ Date: Wed, 9 Jan 2002 03:59:03 -05005 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> D Subject: Re: Steve Jobs not affraid to sell his "different" products2 Message-ID: <o82%7.472$5Y4.14248@news.cpqcorp.net>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3C3B7F73.5661D051@videotron.ca... > Fred Kleinsorge wrote: > >0L > > Yeah, lets join forces with the O/S platform that has ~3% of the desktop) > > market and none of the server market.q >uJ > Funny, APPLE has 5% of SALES market share, but it also has a much larger > installed base.h >I  L There sales and installed base are some small single digit percentage of theJ desktop market.  Apple claims something larger than most analysts use.  InJ any case it is tiny.  Characterized in many ways like the VMS user - not a> lot of them, but most of them don't want to use anything else.  K Don't get me wrong.  From a user perspective, the Mac has always had a nicee
 interface.  K > VMS has 0% of those sales, so Apple is infinitely better than VMS, so whoh aree > you to talk ?f >   J We have 0% of MacOS sales?  I don't really get your point.  The Mac has 0% of servers.  So what?i  J > Once you admit that microsoft is the enemy, you then side with the enemy of8 > your enemy and together toy better the evil Microsoft. >   K I'd prefer not to see everyone as enemies.  I also think that your point istG even stronger if you make the enemy of your enemy UNIX vs Windows.  VMStD *can* put itself in a position of being source compatable with UNIX.  L > VMS has not gained anything by being so cosy to Windows. Windows custoemrs > couldn't care less about VMS.e >r  E Reality is that the vast majority of users have a PC on most of theirsI desktops.  It makes perfect sense to be able to play in that environment.C  G > But if VMS were to cosy up to Apple and offer itself as the server ofp choiceK > for Apple, it would then gain a very easy access to 5% of market, and youCL > should know that Apple customers are also very loyal customers. And do notJ > forget that by having a MAC-VMS combination, the sum would then start toI > attract many new customers and both apple and VMS would grow to attractB new markets/customers. >O  I I don't see it, and I don't get it.  The Mac is a nice standalone desktop G for some users.  But its programming interface is very foreign, and not L something I could see VMS programmers embracing as the new paradigm.  So youK make it the desktop front end for VMS.  What does that offer that is betterr/ than having a PC as the desktop or a Linux box?   I > VMS has a chance to open a new niche that nobody has botherered to dealI withG > before, and to VMS, that 5% market share is HUGE compared to it being  limitedh' > to a few dozen health care companies.f  G I think you have a perception problem if you think that all VMS does is(F service a few dozen health care companies.  I don't see many companiesI outside of very, very selected niches that use MacOS instead of Windows -tJ mostly from what I can see publishing.  So who are the non-home-user MacOSB base that will beat a path to our door if somehow we become "MacOS compliaint" or friendly?   ------------------------------   Date: 9 Jan 2002 15:46:51 -0600m- From: Kilgallen@SpamCop.net (Larry Kilgallen)iD Subject: Re: Steve Jobs not affraid to sell his "different" products3 Message-ID: <0iRJPYAG7tO7@eisner.encompasserve.org>>  j In article <o82%7.472$5Y4.14248@news.cpqcorp.net>, "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes: > < > "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message( > news:3C3B7F73.5661D051@videotron.ca... >> Fred Kleinsorge wrote:o >> >M >> > Yeah, lets join forces with the O/S platform that has ~3% of the desktop * >> > market and none of the server market. >>K >> Funny, APPLE has 5% of SALES market share, but it also has a much largerM >> installed base. >> > N > There sales and installed base are some small single digit percentage of theL > desktop market.  Apple claims something larger than most analysts use.  InL > any case it is tiny.  Characterized in many ways like the VMS user - not a@ > lot of them, but most of them don't want to use anything else.  @ My gut feel is that PCs turn over faster than Macintoshes.  I am@ still making occasional use of a Machintosh I bought in 1987.  A? MicroVax II I bought in 1986 is running a mission-critical (buts; not performance-sensitive) application for me.  Yes, I have  newer models in both lines :-)   ------------------------------  % Date: Wed, 09 Jan 2002 18:05:05 -0500h- From: JF Mezei <jfmezei.spamnot@videotron.ca>eD Subject: Re: Steve Jobs not affraid to sell his "different" products, Message-ID: <3C3CCC9C.866FD6A2@videotron.ca>   Fred Kleinsorge wrote:I > I think you have a perception problem if you think that all VMS does isrH > service a few dozen health care companies.  I don't see many companiesK > outside of very, very selected niches that use MacOS instead of Windows -pL > mostly from what I can see publishing.  So who are the non-home-user MacOSD > base that will beat a path to our door if somehow we become "MacOS > compliaint" or friendly?   Two points:i  K 1- It is exactly because Apple has a weakness in the server market that VMSAN could easily jump in there and give Apple a boost while easily acquiring a newM market for VMS. To Microsoft and others, the MAC marketplace is small. But to,< VMS, that marketplace is HUGE compared to what VMS has left.  L 2-MAC has a big place in schools. Just the right place where you can put VMSF servers and get them to be aware of VMS while they are young. You'd beL surprised how much influence the young kid has on parents when he tells themN what he can do on the school's computers and how backwards their widnows PC at0 home is. (my nephew is at that stage right now).  K And in the publishing industry, you'd be surprised how many do use servers.tK And you'd be surprised how many need heavy duty alpha-power computing needsrL for rendering and for rasterizing postscript. And those people would LOVE toK have a server that needs little maintenance and has online help a human cano= actually read because they are not geeks like unix folks are.a  L Furthermore, an alliance between VMS and APPLE would allow Apple to sell VMSN on your behalf, something Compaq isn't doing. And Apple would have a vested inI terest in selling/marketing VMS as its server OS because that would allow ? Apple to enter some enterprise markets with a strong server OS.t  N If VMS were spun off and sold as a separate entity, its natural alliance wouldJ be with Apple where VMS would be "king" and the MACs would be the desktopsI around the kind. If VMS is purchased by IBM, VMS would just be a sidelineeH product. (yeah, I know, IBM has much more of an enterprise mentality and  infrastructure than Apple does).   ------------------------------  % Date: Wed, 09 Jan 2002 19:16:33 -0500s. From: Chuck McCrobie <mccrobie@cablespeed.com>D Subject: Re: Steve Jobs not affraid to sell his "different" products. Message-ID: <3C3CDD61.8550CD2D@cablespeed.com>   Fred Kleinsorge wrote: >  > M > I'd prefer not to see everyone as enemies.  I also think that your point iseI > even stronger if you make the enemy of your enemy UNIX vs Windows.  VMSsF > *can* put itself in a position of being source compatable with UNIX. >   E HA HA HA HA HA HA HA - will someone please step up to do "autoconf"? gG That'll be the day!  "Source compatible" - maybe, but just try to buildr< most Unix software and one runs into "autoconf".  Good luck!  F Whose going to make VMS source compatible with UNIX?  Not Compaq - VMSC engineering is already busy porting to the WIZ-BANGEST CPU du jour.i  D Can I compile POSTGRESQL - a free database package for Unix - on VMSG without hacking together a boat-load of include files?  Don't think so!2  B Will VMS ever be source compatible with Unix device drivers?  File= systems?  I'll take you statement seriously when I can take aDH Linux/Solaris file system and compile it with minimal change and it runs on OpenVMS.j  E Ya, I know that file systems on Solaris are not the same as FreeBSD /aH Linux / HP-UX, etc., but its a da*n slight easier to get it working than> trying to take such a file system and make it work on OpenVMS.  F Although, it looks like PCI hardware driver interface (at least to the- PCI and DMA widgets) aren't that different...a   ------------------------------  % Date: Thu, 10 Jan 2002 10:53:35 +1300 # From: Bruce Hoult <bruce@hoult.org>hY Subject: Re: Sv: Sv: Sv: Younger recruits versus experienced veterans ( was Re:     The dS> Message-ID: <bruce-86F3B4.10533510012002@news.paradise.net.nz>  9 In article <gm0o3ugvto1g5v2si33cshrpg7u427g4sd@4ax.com>,  & Brian.Inglis@SystematicSw.ab.ca wrote:  3 > On Tue, 08 Jan 2002 01:18:01 +0000, Christian Bau4- > <christian.bau@cbau.freeserve.co.uk> wrote:  > [snip]K > >There is one situation where "contextual menu by waiting" is beneficial: H > >Use a web browser. Click on a link. Realise just before releasing theI > >mouse button that you want to open that link in a new window. Wait for-J > >contextual menu to pop up, select "open in new window". This allows youE > >to change how the mouse click is interpreted while the mouse clickr> > >happens, something that is impossible using a PC mouse with6 > >right/wrong^H^H^H^H^H^H^H^H^H^H^Hleft/right button. > = > Not if you always right click on links and pick open in new B > window normally or just open if you want to replace the window.    But that's *so* clunky.a  D All the Mac browsers I've used do "open in new window" if you click @ while holding the "command" key.  Much faster than using a menu.  H Also, the current version of IE lets you do command-shift-click to open G in a new window behind the current one.  So you can quickly click on a  G bunch of links and have a new window for each one waiting for you when c you close the front window.I   -- Bruce   ------------------------------  # Date: Wed, 09 Jan 2002 22:21:05 GMTn, From: liam@nessie.xinqu.net (Liam Greenwood)Y Subject: Re: Sv: Sv: Sv: Younger recruits versus experienced veterans ( was Re:     The dn2 Message-ID: <slrna3pg91.lta.liam@nessie.xinqu.net>  H On Thu, 10 Jan 2002 10:53:35 +1300, Bruce Hoult <bruce@hoult.org> wrote:: >In article <gm0o3ugvto1g5v2si33cshrpg7u427g4sd@4ax.com>, ' >Brian.Inglis@SystematicSw.ab.ca wrote:s >> 8> >> Not if you always right click on links and pick open in newC >> window normally or just open if you want to replace the window.   >, >But that's *so* clunky. > E >All the Mac browsers I've used do "open in new window" if you click  A >while holding the "command" key.  Much faster than using a menu.r   But that's *so* clunky.i  < In X I merely click on the link with the middle mouse button# to "open in a new window".  *grins*n   Cheers, Liam   ------------------------------  % Date: Thu, 10 Jan 2002 18:39:08 +1300l# From: Bruce Hoult <bruce@hoult.org>cY Subject: Re: Sv: Sv: Sv: Younger recruits versus experienced veterans ( was Re:     The ds> Message-ID: <bruce-E3B94F.18390810012002@news.paradise.net.nz>  B In article <slrna3pg91.lta.liam@nessie.xinqu.net>, liam@xinqu.net  wrote:  J > On Thu, 10 Jan 2002 10:53:35 +1300, Bruce Hoult <bruce@hoult.org> wrote:< > >In article <gm0o3ugvto1g5v2si33cshrpg7u427g4sd@4ax.com>, ) > >Brian.Inglis@SystematicSw.ab.ca wrote:S > >> F@ > >> Not if you always right click on links and pick open in newE > >> window normally or just open if you want to replace the window. t > >  > >But that's *so* clunky. > >oG > >All the Mac browsers I've used do "open in new window" if you click .C > >while holding the "command" key.  Much faster than using a menu.c >  > But that's *so* clunky.  > > > In X I merely click on the link with the middle mouse button% > to "open in a new window".  *grins*0  B You ignored the part about opening in another window *behind* the  current one.  F Go on, admit it ... you're in denial and secretly lusting after a new  iMac.  I know.   -- Bruce   ------------------------------  $ Date: Wed, 9 Jan 2002 20:36:29 +0100, From: Steve O'Hara-Smith <steveo@eircom.net>Y Subject: Re: Sv: Sv: Sv: Younger recruits versus experienced veterans ( was Re: The demis-7 Message-ID: <20020109203629.2fbd1df8.steveo@eircom.net>     On Wed, 09 Jan 2002 17:30:00 GMT3 "Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote:    SF> = SF> "Steve O'Hara-Smith" <steveo@eircom.net> wrote in messagec4 SF> > a mouse does is easier for a three year old :) SF>  SF> To quote Tom Lehrer  SF> K SF>     "It's so simple, so very simple, that only a child can do it"   :-)   D 	<grin> and to make it even more fun, just as I read this the randomI number generator provided me with him playing "The Folk Song Army" :) I'miG becoming more and more convinced that /dev/random knows things, perhapsa% those Taiosts were right after all :)c   -- tH C:>WIN                                          |     Directable MirrorsN The computer obeys and wins.                    |A Better Way To Focus The SunL You lose and Bill collects.                     |  licenses available - see:J                                                 |   http://www.sohara.org/   ------------------------------  % Date: Wed, 09 Jan 2002 22:14:58 +0100l, From: Didier Morandi <Didier.Morandi@gmx.ch>8 Subject: TCP/IP 5.1 and DHCP and Internet/Cable provider& Message-ID: <3C3CB2D1.8AEA41E2@gmx.ch>  P When I enable DHCP (TCP/IP V5-1 OpenVMS 7.3) it times out after 30 sec. The sameG RJ45 cable plugged to my PC or my iBook gives me my DHCP configuration.u  2 Why? circuit is WE0 (ESA0), system is ... PWS600au  > If I tell the conf proc to choose WE0 or NONE, same behaviour.   D.   ------------------------------  % Date: Wed, 09 Jan 2002 18:17:27 -0500e- From: JF Mezei <jfmezei.spamnot@videotron.ca>/< Subject: Re: TCP/IP 5.1 and DHCP and Internet/Cable provider, Message-ID: <3C3CCF80.AA71BDDD@videotron.ca>   Didier Morandi wrote:  > R > When I enable DHCP (TCP/IP V5-1 OpenVMS 7.3) it times out after 30 sec. The sameI > RJ45 cable plugged to my PC or my iBook gives me my DHCP configuration.i > 4 > Why? circuit is WE0 (ESA0), system is ... PWS600au  K Be careful. Youd cable modem may be the culprit. If you are provisioned formJ only 1 IP address, the cable modem will respond to DHCP requests that comeI only from the first ethernet address they see on your lan and will ignoreh9 others (so your ISP's DHCP server doesn't even see them).-  N Of course, this may be different depending on the type of cable modem you have4 and the software revision loaded in them by the ISP.  N Trick is to disconnect your PC from the lan, power off and power on the modem,- and then get your vax to do the dhcp request.   I I just got a router, and it is so much nicer, my lan all has local staticsM adresses, and the router does the dhcp negotiation with the ISP so none of myi$ machines need be bothered with DHCP.   ------------------------------  % Date: Wed, 09 Jan 2002 19:08:01 -0500s- From: JF Mezei <jfmezei.spamnot@videotron.ca>,, Subject: TCPIP programming: $QIO vs C socket, Message-ID: <3C3CDB57.21F3030F@videotron.ca>  M We are often reminded that TCPIP services is a port of the Tru64 TCPIP stack.y  5 I am curious though at what level was the port made ?   L Looking at the programming interface for $QIO, it seems most "interesting".   N Looking just at the function to establish a connection with a remote host, one4 needs do to a $QIO with the IO$ACCESS function code.   So far so good.r  N However, instead of using the 6 potential parameters to separately specify theK protocol type, internet IP address (integer), and port number, they have uslL pass a pointer to a descriptor which contains a pointer to a structure whichL contains that information ( and the address portion is actually a union that has multiple definitions).  J (The doc doesn't contain a description of that structure, one must rummage< through the various includes (thank you SEARCH) to find it.)   This has gotten me to wonder:t  K Did they build the core as VMS native and only add ported utilities such as M NSLOOKUP TCPIP etc, or is the core also from Unix with a $QIO kludge added tos it ?  N Is there some sort of background that explains the nature of the design of the@ TCPIP $QIO interface compared say to DECNET or mailbox drivers ?   ------------------------------  # Date: Wed, 09 Jan 2002 19:26:56 GMTo2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)Q Subject: Re: UWSSs and NOSHRIMG Calling out to other shareables (Not in cookbook).2 Message-ID: <4Q0%7.462$5Y4.13891@news.cpqcorp.net>  c In article <a1g2rm$smm$1@helle.btinternet.com>, "Richard Maher" <maher_rj@notsohotmail.com> writes:   F :"Never make subroutine calls to other shareable images from kernel or :executive mode"  M :There doesn't appear to be a lot of grey area or room to manoeuvre with thataL :statement and there's only so much ambiguity that can be read into the wordL :*NEVER*. Or so I thought. . .and then I realized that every other bloke and9 :his dog was just dropping the /PROTECT and running amoc.n  G   This mechanism is a blade guard, and one that should be removed only '   with great care.  G :I note that the Alpha C example implies that calling other "protected"aK :shareable images is ok but the attached message text for NOSHRIMG does not K :say "drop the /PROTECT" it says "rewrite your UWSS". I know how to protectnB :individual program sections on a needs basis with PROTECT=YES and :COLLECT=safe,psect1.   .   Exactly why are you digging into this stuff?B   What problem -- other than the section PROTECT stuff -- are you    seeking to resolve?   D :Is it safe to call other shareables from inner mode whether they be> :protected or not? (as long as they're installed (protected?))     No.n  K :What about the loose talk regarding the EXEC mode deployment of LIB$GET_VMyC :and LIB$FREE_VM? I for one am sick of $expreg when a lovely little  :lib$get_vm would do!   K   You can't call most RTL services from anything other than user-mode code.e  M   You will generally need to use the kernel C RTL or a kernel-mode accessablep   system service entry point.v  L :You're in an EXEC mode AST and you want to call a user routine at AST levelH :so you have to drop down to user mode. So what you'd like to do is callB :lib$get_vm to store the user AST parameters and then do a $dclast :psl$c_user.  K   You can't call most RTL services from anything other than user-mode code.tI   If you try this, then page ownerships will tend to cause perturbations T   within the application.   A :   The memory could be freed by a shell routine or the user codeiJ :itself. So what if user code buggers up the memory or the user mode stackH :for that matter, as long as the integrity of the protected subsystem is :maintained then who cares?n  K   The RTL memory pool is shared, but is not re-entrant across access modes.e  M :I thought the other security hack could be to spoof LIBRTL.EXE but with onlysB :trusted logical names (SYS/EXEC) being utilized then how could an :unprivileged user do this?   H   I prefer to avoid using this forum to provide a tutorial for cracking ,   into poorly-written privileged subsystems.  / :Why is there secureshr.exe and secureshrP.exe.e  H   That is the partitioning of the privileged-mode code and the user-mode1   code involved in the various security services.i  + :Is it safe to call $getuai from EXEC mode?      AFAIK, no.  I   Most system services can usually be called from an inner-mode, but some5J   (eg: RMS) have restrictions on how privileged you can be.  Services thatB   are in privileged shareable images are generally not accessable.  K :Why does $persona_create live in secureshr.exe and *insist* on probing theqL :output persona_id with a hard-coded user_mode probe and not #0 or PREV_MODE :or ifnowrt? :p :Thanks for any assistance.m :a :Regards Richard Maher :1J :PS. I finally found the Guide to upgrading privileged code. (OK six yearsL :late - but I'm used to working on VMS 6.2) why was this manual (Which couldF :just as easily be titled VMS V7.0 Release Notes) hidden away with theJ :Correct posture Guide? Now I know why I have to put up with that bollocksG :Epid. Why wasn't it called a Tpid for threads and leave the rest of us  :alone?A :eK :BTW. Thanks very much for the EXEC rundown handler and the ability to call D :RMS at rundown! I'm sure you have people doing UWSSs just for this.  >   RMS is (in V7.3-1) now performing its run-down on a $delprc.  B : NOSHRIMG,  privileged shareable image cannot have outbound calls ..    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Thu, 10 Jan 2002 03:07:05 GMTs4 From: Tim Llewellyn <tim.llewellyn@blueyonder.co.uk>K Subject: Re: VAX 4000/100 with Correctable Memory Errors resulting in crash 0 Message-ID: <3C3D0491.9994B6FE@blueyonder.co.uk>   "Barry Treahy, Jr." wrote: > G > I have an older VAX 4000/100 with the 16MB simms loaded out to 128MB. J >  The system has not been under HW maintenance for some time but has beenH > very stable until recently.  As of late, we have logged at least threeB > times correctable memory errors that were flagged as "Memory SBEB > reduction subpacket" resulting in a system shutdown/crash due toJ > "RESEXH, Resources exhausted, system shutting down."  The general status' > is "scrubbed" and that is about it..., > G > What is of concern is that it is not a single simm location, but eachdD > time it is a different simm producing the same error with the same > results... >  > Any thoughts or suggestions? >   L Reseat the simms? Aircon failure recently? PSU or flaky mains power problem?1 Neighbours installed a particle accelerator :-) ?h   regardso   --   Tim.Llewellyn@cableinet.co.uk  r  C Standard disclaimer applies. My views in no way represent those of .! my employers or service provider.    ------------------------------   Date: 10 Jan 2002 00:37:32 GMT- From: Joe Heimann <heimann@nog.ecs.umass.edu>  Subject: Re: VAX in a VT-103?a, Message-ID: <a1inoc$sua$1@odo.ecs.umass.edu>  3 Stuart S. Johnson <stuartsjohnson@yahoo.com> wrote: J > I had a VT103 w/dual TU58's, 11/03 CPU, DLV-11J serial, MSV11-DD memory,M > dual 8" DSDD Shugart floppies (w/patched floppy driver for DSDD operation),AK > and 3rd party 8" floppy disk controller back in 1981. As I recall, it waslN > loaded both slot and power-wise in this configuration. I seriously wonder ifN > any of the uVax processors would have worked with the small power supply andI > limited ventilation. Moving the thing would also be a nice way to get ae > hernia :)t  E > Oh, yeah - ever boot a system from a TU-58? There is an exercise inu > patience!I  G Every time the HSC50's reboot here.  5-10 minutes for the boot to go to H completion.  That is if the tape does not have to be popped out and backH in because the drive wheel has developed a "flat" spot and will not spin on the first try.r    Joe Heimann   heimann@ecs.umass.eduo   (rest snipped)   ------------------------------   Date: 9 Jan 2002 15:09:42 CDT = From: wayne@tachysoft.xxx.514360.killspam.00c9 (Wayne Sewell) 1 Subject: Re: VMS Marketing For the General Public . Message-ID: <aKAzd3Cc5xt3@tachxxsoftxxconsult>  [ In article <3C3BB3CA.ABD4BCB1@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:o > K > ....and William (Webb): May I assume no objections to using your materiall! > as the basis of an ad campaign?h >     I Certainly the vms_not_toy ad at my site is available.  It's creator, Philo> Jamieson of Software Partners, said to spread it far and wide.  H Ya wanna hear something funny?  The girl in the picture appears to be atL the end of her rope after fighting billy systems all day long.  Phil said he. got the picture from some Microshit archive.     --  O =============================================================================== M Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxxt: http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-)wO ===============================================================================,N Sparky (from Bring It On): "In cheerleading, we throw people in the air.  Fat  	people don't go as high."   ------------------------------  # Date: Thu, 10 Jan 2002 04:02:33 GMTs1 From: "David J. Dachtera" <djesys.nospam@fsi.net>t1 Subject: Re: VMS Marketing For the General Public,' Message-ID: <3C3D1329.FEB2356F@fsi.net>    Wayne Sewell wrote:h > ] > In article <3C3BB3CA.ABD4BCB1@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:g > > M > > ....and William (Webb): May I assume no objections to using your materialv# > > as the basis of an ad campaign?a > >l > K > Certainly the vms_not_toy ad at my site is available.  It's creator, Phila@ > Jamieson of Software Partners, said to spread it far and wide.   So be it, Jedi...   J > Ya wanna hear something funny?  The girl in the picture appears to be atN > the end of her rope after fighting billy systems all day long.  Phil said he. > got the picture from some Microshit archive.  
 Figgers...   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/h   ------------------------------  # Date: Thu, 10 Jan 2002 04:07:38 GMTH1 From: "David J. Dachtera" <djesys.nospam@fsi.net> 1 Subject: Re: VMS Marketing For the General Publicw' Message-ID: <3C3D145A.EE0A745E@fsi.net>l   "Terry C. Shannon" wrote:s > [snip]I > To fix the ad so it passes the OS Political Correctness Committee, just : > change "closing the windows" to "closing the loopholes."  
 How 'bout:  + 		Security weaknesses in some other systems-, 		open windows of opportunity that can lead  		to downtime and missing data.l  + 		If you're tired of frequent downtime and i. 		missing data, then it's time to think about  		closing those windows!  H This provides a suitable context so the statement (with minor edits) can4 stand as is and simply constitute a double-entendre.   Yes? No?   -- : David J. Dachterat dba DJE Systemsc http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/n   ------------------------------  % Date: Wed, 09 Jan 2002 17:14:52 -05000- From: JF Mezei <jfmezei.spamnot@videotron.ca>i@ Subject: Re: Want to follow IBM model Capellas?  IBM quits pc's!, Message-ID: <3C3CC0DA.925DF7CD@videotron.ca>   Bob Ceculski wrote:oD > IBM said yesterday it was to sell its PC manufacturing business inD > Europe and US to Sanmina although it will still make StinkPads and- > still design and sell the desktop machines.   M You'll note that IBM long ago sold its PC manufacturing business in Canada totL a bunch of execs who ran it. The company went public and is seen as a "good"M .COM in canada. It is called "Celestica" and it now manufactures PCs for more0 than just IBM.  M Offloading manufacturing to 3rd party does not mean exiting the PC business. e  E I think that IBM's PC advertising on TV right now is a prettty strong8/ indication that IBM is continueing to sell PCs.n   ------------------------------  # Date: Thu, 10 Jan 2002 01:19:05 GMT0* From: "Bill Todd" <billtodd@metrocast.net>, Subject: Re: what is future of VMS and alphaB Message-ID: <c_5%7.412864$C8.30149715@bin4.nnrp.aus1.giganews.com>  > "Keith Parris" <keithparris_NOSPAM@yahoo.com> wrote in message7 news:cf15391e.0201082242.120748a6@posting.google.com...y7 > "Bill Todd" <billtodd@metrocast.net> wrote in message*> news:<XAw_7.391783$C8.28561848@bin4.nnrp.aus1.giganews.com>...H > > The MS answer to host-based volume shadowing is host-mirrored drives thatK > > are taken over by (failed over to - a matter of seconds if a journalingt fileL > > system like NTFS is used) a second host if the first fails.  If you wantI > > disaster tolerance, you can have it (at least up to 10 km or whatever. normalB > > FC allows these days) by separating the disks from each other. > {...}kG > > The up-side of this approach is that you can have either host *and*0 either: > > disk fail and still operate, unlike the case with VMS. >:G > Seems to me a VMS cluster has exactly this same capability, given thehH > same FC storage configuration (with an inter-site FC link), unless I'mH > missing something.  With an inter-site FC link, VMS MSCP-serving isn'tG > needed for access to the remote disks, so that removes the dependencye# > on a VMS node at the remote site.f  B I may well not understand all the options of VMS host-based volumeL shadowing, then - I thought the individual volumes were private to each hostJ and not accessible if that host failed (which would mean you're describingL truly-shared devices, such as cooperating HSxs, above rather than host-basedK volume shadowing, which was the specific area in question).  But if there'seI a way for one host of a host-based volume-shadowing pair to take over the B volume that had been being managed by another (failed) host (or ifF host-based volume-shadowing allows both hosts to cooperate constantly,K sharing access to both volumes in the shared pair), then I stand corrected.    - bill   ------------------------------  # Date: Thu, 10 Jan 2002 01:28:07 GMTe* From: "Bill Todd" <billtodd@metrocast.net>, Subject: Re: what is future of VMS and alphaB Message-ID: <H66%7.593111$8q.48054207@bin2.nnrp.aus1.giganews.com>  : "Warren Spencer" <wspencer@ap.nospam.org> wrote in message1 news:91909227Bwarrenspencer1977@209.249.90.100...b- > billtodd@metrocast.net (Bill Todd) wrote inP9 > <XAw_7.391783$C8.28561848@bin4.nnrp.aus1.giganews.com>:. >WJ > >But the question then becomes whether the fact that MS achieves similar2 > >function by a different mechanism is important. >a	 > Agreed.7 > G > >The MS answer to host-based volume shadowing is host-mirrored drivesID > >that are taken over by (failed over to - a matter of seconds if aG > >journaling file system like NTFS is used) a second host if the firstCJ > >fails.  If you want disaster tolerance, you can have it (at least up toI > >10 km or whatever normal FC allows these days) by separating the disksu > >from each other.t >iH > Clearly I need sum edukation here.  Are you saying a given MS host can haveB > disk drives located 10 km apart?  Any idea what sort of hardware- > configuration would be required to do this?e  K Normal FC adapters and disks, plus (single-mode?) optical fibre, support atsJ least 10 km link lengths, so technically a single host could have disks 20C km apart (10 km in each direction).  I believe FC distance-extenderdL mechanisms (i.e., FC-over-something-else) are also available, but don't know any details.   >o: > > And there's no reason you can't run productive work onF > >both servers (e.g., a symmetrical configuration where each normallyF > >manages one set of disks and serves as back-up server for another). > >iF > >The up-side of this approach is that you can have either host *and*@ > >either disk fail and still operate, unlike the case with VMS. >pK > This part I don't quite get - is the assumption here a 2-node VMS clusterDH > that will hang when one node departs?  The last fully redundant 2-nodeG > cluster I saw could lose one node (assuming it's not the one with the I > quorum disk), any disk controller, and any shadow-set member, and still, > keep on pumpin'.  L As I replied to Keith, I assumed the disks were MSCP-exported (i.e., privateK to each host).  If host-based volume-shadowing (as distinguished from othersL approaches such as truly-shared HSx pairs) can be set up to allow both hostsK direct access to both disks in the shadow-set pair (I know, Rob - there cantF be triples and even more as well), then indeed any single host and anyL single disk could fail in the VMS case as well without harming availability.   >  > > ThehF > >down-side is that all access to the disk pair is funneled through aK > >single host (which isn't so bad if they're really just disks but becomes 9 > >a problem if they're in fact high-performance arrays).i >hH > Again, if you would, education:  How does a high-performance arry make this > more problematic?   H High-performance arrays can easily generate more bandwidth than a singleJ host (especially a single IA32 platform host) can serve to the rest of theL world.  But if multiple hosts can share *direct* access to the array, as VMS' can do, then that needn't be a problem.    - bill   ------------------------------  % Date: Thu, 10 Jan 2002 05:18:14 +0100R2 From: martin@radiogaga.harz.de (Martin Vorlaender), Subject: Re: what is future of VMS and alpha; Message-ID: <3c3d1606.524144494f47414741@radiogaga.harz.de>R  . JF Mezei (jfmezei.spamnot@videotron.ca) wrote:J > In all fairness to the troll, (he was featured in the Harry Potter movie > BTW),e  H Quest For The Ring also has one - as ugly as I always thought he'd be...   cu,t   Martin -- tG So long, and thanks        | Martin Vorlaender  |  VMS & WNT programmerE4 for all the books...       | work: mv@pdv-systeme.deG In Memoriam Douglas Adams  |   http://www.pdv-systeme.de/users/martinv/c;             1952-2001      | home: martin@radiogaga.harz.deb   ------------------------------  $ Date: Wed, 9 Jan 2002 15:14:16 -05002 From: "Sue Skonetski" <susan.skonetski@compaq.com>+ Subject: Re: who else got the VMS brochure? 2 Message-ID: <1v1%7.470$5Y4.14095@news.cpqcorp.net>  L The brochure is the latest VMS brochure, it is designed for the sales folks,1 partner and Compaq to distribute to any audience.c  B You received a copy because you are in the VMS customer data base.  L The photographs come from the corporate graphics library.  I do not know anyK of the people in the pictures, but I usually don't in any brochure from anyt company.  
 Warm Regards,'   suea          : "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message- news:T7dmdrYr6JRw@eisner.encompasserve.org...BL > In article <01KCVIDRMZ6Q8ZEGIP@sysdev.deutsche-boerse.com>, Phillip Helbig, <HELBPHI@sysdev.deutsche-boerse.com> writes:F > > Due to a delay because it was sent to an old address, I just got aI > > brochure entitled OPENING GREATER OPPORTUNITIES.  It seems to be REALpF > > VMS marketing, like we've all been asking for.  Not JUST buzzwordsL > > (though they are there) but relevant information, quotes from real heads > > of real companies etc. > >t > > Who else got this? >tF > Listing people in this newsgroup who got it is not very interesting.F > The important thing is how many still have it.  The answer should be > None.i >tJ > > It seems to me that this type of information should be target not just> > > at existing customers but also at potential new customers. >tG > Exactly.  So if you got one by mistake, or because yours was the namet? > that Compaq had, please give it away to someone who needs it.t   ------------------------------  # Date: Wed, 09 Jan 2002 20:37:27 GMTe From: 1076366@charter.nete+ Subject: Re: who else got the VMS brochure?b/ Message-ID: <3c3ca90b.9655914@news.charter.net>g  % Thank you, Sue, for clearing that up.   $ What I would really like to know is:  1 Can we have access to the VMS customer data base?   4 (you can email me directly at schiffkey@charter.net)   Why, you may ask.y   Well,   I am looking for work right now.; And sadly, the only work I am finding is NON vax/vms based.d   I have 18 years of vax/vms (20 in Cobol, 9 in Ingres)  : and I would sincerely hate to have to work in IBM (as/400) or any other environment!!!!  A But, if you could give me a lead on customers still using vax/vmsSF especially in my home state of Florida, I would be extremely greatful.  E You would not want to lose any truly loyal DEC programmers would you? 	 Hope not!e  9 So, write, call, email, whatever, as quickly as possible.u  " Jerrold at   schiffkey@charter.net   and Thank you!( ----------------------------------------  2 On Wed, 9 Jan 2002 15:14:16 -0500, "Sue Skonetski"# <susan.skonetski@compaq.com> wrote:r  M >The brochure is the latest VMS brochure, it is designed for the sales folks, 2 >partner and Compaq to distribute to any audience. >tC >You received a copy because you are in the VMS customer data base.i > M >The photographs come from the corporate graphics library.  I do not know any L >of the people in the pictures, but I usually don't in any brochure from any	 >company.e >E >Warm Regards, >n >sue >l >  >c >  >R; >"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in messaget. >news:T7dmdrYr6JRw@eisner.encompasserve.org...M >> In article <01KCVIDRMZ6Q8ZEGIP@sysdev.deutsche-boerse.com>, Phillip Helbigu- ><HELBPHI@sysdev.deutsche-boerse.com> writes:-G >> > Due to a delay because it was sent to an old address, I just got alJ >> > brochure entitled OPENING GREATER OPPORTUNITIES.  It seems to be REALG >> > VMS marketing, like we've all been asking for.  Not JUST buzzwordsSM >> > (though they are there) but relevant information, quotes from real heads- >> > of real companies etc.  >> > >> > Who else got this?  >>G >> Listing people in this newsgroup who got it is not very interesting.0G >> The important thing is how many still have it.  The answer should be9 >> None. >>K >> > It seems to me that this type of information should be target not just1? >> > at existing customers but also at potential new customers.o >>H >> Exactly.  So if you got one by mistake, or because yours was the name@ >> that Compaq had, please give it away to someone who needs it. >l >e   ------------------------------  # Date: Wed, 09 Jan 2002 21:47:50 GMTl= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)h+ Subject: Re: who else got the VMS brochure?t0 Message-ID: <00A07CB5.D651E1AC@SendSpamHere.ORG>  g In article <1v1%7.470$5Y4.14095@news.cpqcorp.net>, "Sue Skonetski" <susan.skonetski@compaq.com> writes:rM >The brochure is the latest VMS brochure, it is designed for the sales folks,s2 >partner and Compaq to distribute to any audience. >?C >You received a copy because you are in the VMS customer data base.c >eM >The photographs come from the corporate graphics library.  I do not know anydL >of the people in the pictures, but I usually don't in any brochure from any	 >company.d >  >Warm Regards, >- >sue    K "When was this brochure mailed?", bellowed the fellow that hasn't seen one.a   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM             oJ   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbesw   ------------------------------   Date: 9 Jan 2002 21:21 CST' From: carl@gerg.tamu.edu (Carl Perkins)I+ Subject: Re: who else got the VMS brochure?r, Message-ID: <9JAN200221213128@gerg.tamu.edu>  = Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> writes...lD }Due to a delay because it was sent to an old address, I just got a G }brochure entitled OPENING GREATER OPPORTUNITIES.  It seems to be REAL  D }VMS marketing, like we've all been asking for.  Not JUST buzzwords J }(though they are there) but relevant information, quotes from real heads  }of real companies etc.  }  }Who else got this?  } H }It seems to me that this type of information should be target not just ; }at existing customers but also at potential new customers.o   We did.n  G Unfortunately, the very first thing that came to mind when I saw it was G something along the lines of, "How do you open greater opportunities byR0 restricting it to a small set of niche markets?"  D Clearly the left hand has no concept of what the right hand is doing
 at Compaq.   But it is a nice brochure.  B I'm guessing that this is part 2 of the campaign, where part 1 was9 the Mark Twain book of quotations thing not too long ago.a   --- Carl   ------------------------------  % Date: Thu, 10 Jan 2002 07:06:37 +0100P1 From: John McLean <mcleanj@swissonline.delete.ch> + Subject: Re: who else got the VMS brochure?u5 Message-ID: <3C3D2F6D.3C05AE45@swissonline.delete.ch>    Carl Perkins wrote:i >  ....	 > We did.d > I > Unfortunately, the very first thing that came to mind when I saw it was I > something along the lines of, "How do you open greater opportunities by=2 > restricting it to a small set of niche markets?" > F > Clearly the left hand has no concept of what the right hand is doing > at Compaq. >  > But it is a nice brochure. > D > I'm guessing that this is part 2 of the campaign, where part 1 was; > the Mark Twain book of quotations thing not too long ago.y    F I received the brochure last Saturday and by Sunday evening I had sent& an email with some feedback to Mark G.  B If you do this kind of thing Compaq will soon learn that people doD notice and appreciate these things.  A bit of constructive criticismG might be useful to them and it wll make it clear that we are all trying D to achieve the best we can for VMS (even if our methods sometimes do vary).     John McLeanm   ------------------------------  % Date: Wed, 09 Jan 2002 20:13:51 +0100t, From: Didier Morandi <Didier.Morandi@gmx.ch>D Subject: Re: [tired] PWS600au does not e7 e6 e5... anymore and hangs& Message-ID: <3C3C966F.96D0DCC8@gmx.ch>   Didier Morandi wrote:r >  > Pffffff.... what a pain! > K > I restarted my PWS600au this evening and surprize, no more hardware tests O > sequence. Then I got my SRM prompt, I could see my BA356, I booted DKA100, itdO > started booting until the "jumping to bootstrap code", then it just sit here.. >  > Any idea?  > I broke my motherboard?m >  > D.  8 Fixed. Console was graphics and SRM variable was serial.   D.   ------------------------------   End of INFO-VAX 2002.017 ************************4:07:38 GMTH1 From: "David J. Dachtera" <djesys.nospam@fsi.net> 1 Subject: Re: VMS Marketing For the General Publicw' Message-ID: <3C3D145A.EE0A745E@fsi.net>l   "Terry C. Shannon" wrote:s > [snip]I > To fix the ad so it passes the OS PolitiB@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@    B@     C@    C@    C@    C@    C@    C@    C@    C@    C@    	C@    
C@    C@    C@    
C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@     C@    !C@    "C@    #C@    $C@    %C@    &C@    'C@    (C@    )C@    *C@    +C@    ,C@    -C@    .C@    /C@    0C@    1C@    2C@    3C@    4C@    5C@    6C@    7C@    8C@    9C@    :C@    ;C@    <C@    =C@    >C@    ?C@    @C@    AC@    BC@    CC@    DC@    EC@    FC@    GC@    HC@    IC@    JC@    KC@    LC@    MC@    NC@    OC@    PC@    QC@    RC@    SC@    TC@    UC@    VC@    WC@    XC@    YC@    ZC@    [C@    \C@    ]C@    ^C@    _C@    `C@    aC@    bC@    cC@    dC@    eC@    fC@    gC@    hC@    iC@    jC@    kC@    lC@    mC@    nC@    oC@    pC@    qC@    rC@    sC@    tC@    uC@    vC@    wC@    xC@    yC@    zC@    {C@    |C@    }C@    ~C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    C@    