INFO-VAX Wed, 31 Jan 2007 Volume 2007 : Issue 61 Contents: Re: An opening for VMS: licence management Re: An opening for VMS: licence management Re: An opening for VMS: licence management Re: cannot log in at console Re: cannot log in at console Re: cannot log in at console Re: Disk space problem Re: Disk space problem Re: Disk space problem Re: Disk space problem Re: Fun with GNV - Watch out for MNT. Re: How long to really setup a VMS system ? Re: How long to really setup a VMS system ? Re: How long to really setup a VMS system ? Re: How long to really setup a VMS system ? Re: How long to really setup a VMS system ? Re: How long to really setup a VMS system ? Re: How long to really setup a VMS system ? Re: How long to really setup a VMS system ? HSZTerm for Integrity? Re: HSZTerm for Integrity? Re: Kermit Large File Support Re: Kermit Large File Support Looking for hobbyists in or around Oklahoma City Re: Monitor rms issue on Vax Mozilla: "edit" as helper application ? Re: PL/I for Itanium Re: PL/I for Itanium Re: PL/I for Itanium RE: PL/I for Itanium Re: PL/I for Itanium RE: PL/I for Itanium Re: PPPD, TCPIP Services and incomplete negotiations Re: PPPD, TCPIP Services and incomplete negotiations Re: PPPD, TCPIP Services and incomplete negotiations Re: Purveyor CGI mailbox capacity [bit long winded] Re: TCPIP Failsafe vs ARP Cluster alias Re: TCPIP Failsafe vs ARP Cluster alias ---------------------------------------------------------------------- Date: Tue, 30 Jan 2007 22:10:09 +0100 From: Paul Sture Subject: Re: An opening for VMS: licence management Message-ID: In article , helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) wrote: > In article <8c159$45bf2201$cef8887a$13298@TEKSAVVY.COM>, JF Mezei > writes: > > > Definitely. But the point is that Microsoft is now embarking on a witch > > hunt wantijng to audit business customer sites and threathen to charge for > > any illegal license. > > Whatever one thinks of Microsoft, one can't fault them for legally > attacking people who are stealing from them. But it appears it isn't as simple as that: http://www.networkworld.com/newsletters/sbt/2006/0612networker3.html?page =3 "Buy a laptop with installed software lately? Scott bought a Lenovo ThinkPad and the invoice didn't mention the software. Scott demanded a new invoice listing the software so he'd be clear in a BSA audit. Even though the laptop package from Lenovo mentioned the software, the laptop had the holographic Certificate of Authority, and the package included original CDs from Microsoft, the software was NOT legal according to BSA rulings from previous software audits Scott has defended." > IF YOU DON'T LIKE THEIR > SOFTWARE, DON'T USE IT. Despite RMS, there is nothing morally wrong > with charging money for software. (I read up on some of his statements > after he showed up again in another thread here recently. My > "favourite" quote was that it is a crime against humanity to charge > money for software. This guy has some SERIOUS problems with putting > things into perspective. Don't let your mutual hatred of Microsoft put > you in his camp.) > Agreed. -- Paul Sture ------------------------------ Date: 30 Jan 2007 15:56:11 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: An opening for VMS: licence management Message-ID: In article , helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: > In article <8c159$45bf2201$cef8887a$13298@TEKSAVVY.COM>, JF Mezei > writes: > >> Definitely. But the point is that Microsoft is now embarking on a witch >> hunt wantijng to audit business customer sites and threathen to charge for >> any illegal license. > > Whatever one thinks of Microsoft, one can't fault them for legally > attacking people who are stealing from them. No, but suing your customers isn't a great way to expand your markets. ------------------------------ Date: 30 Jan 2007 16:45:30 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: An opening for VMS: licence management Message-ID: In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > In article , helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: >> In article <8c159$45bf2201$cef8887a$13298@TEKSAVVY.COM>, JF Mezei >> writes: >> >>> Definitely. But the point is that Microsoft is now embarking on a witch >>> hunt wantijng to audit business customer sites and threathen to charge for >>> any illegal license. >> >> Whatever one thinks of Microsoft, one can't fault them for legally >> attacking people who are stealing from them. > > No, but suing your customers isn't a great way to expand your > markets. Not all of us are interested in having Microsoft expand their markets. ------------------------------ Date: 30 Jan 2007 12:56:26 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: cannot log in at console Message-ID: In article , Rob Brown writes: > On Tue, 30 Jan 2007, Hoary Hairy Hoax wrote: > >> We have a Digital Alpha running VMS 7.3-2. Its only >> user is SYSTEM. I can log in as SYSTEM from another >> host with ssh. I cannot log in at the console. The >> window interface accepts my user name and password, >> brings up a Motif hourglass, and reverts to the login >> screen. Any suggestions? > > I don't know about this can happen to user SYSTEM, but if a user's > login directory is not accessible, the login fails exactly as you > describe. Another possibility is that something in the LOGIN.COM for SYSTEM presumes an interactive terminal. With DECwindows, lots of logins of ancillary processes happen without an interactive terminal. ------------------------------ Date: Tue, 30 Jan 2007 18:10:03 -0500 From: JF Mezei Subject: Re: cannot log in at console Message-ID: <1179b$45bfd050$cef8887a$16632@TEKSAVVY.COM> When you get the HP login window, click on OPTIONS and you can choose between 3 sessions types. New Desktop, Failsafe and Old desktop. (not sure of the actual terminology). The "failsafe" gives you a single decterm window and no actual desktop. Not sure if this allows bypassing lack of Motif licence though. ------------------------------ Date: Tue, 30 Jan 2007 20:16:43 -0600 From: David J Dachtera Subject: Re: cannot log in at console Message-ID: <45BFFC0B.D216BA42@spam.comcast.net> Hoary Hairy Hoax wrote: > > We have a Digital Alpha running VMS 7.3-2. Its only > user is SYSTEM. I can log in as SYSTEM from another > host with ssh. I cannot log in at the console. The > window interface accepts my user name and password, > brings up a Motif hourglass, and reverts to the login > screen. Any suggestions? This and the other post, "cannot restore SYSUAF" were due to mistaking PRCLM for MAXJOBS. We corresponded off the list and he has resolved his issue. ...although the problem of COPY not working while booted from the CD is troubling. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: 30 Jan 2007 11:17:23 -0800 From: "tadamsmar" Subject: Re: Disk space problem Message-ID: <1170184643.777990.185170@m58g2000cwm.googlegroups.com> On Jan 30, 11:37 am, Paul Sture wrote: > In article , > Tad Winters wrote: > > > > > > > "tadamsmar" wrote in news:1170171652.426528.307070 > > @a75g2000cwd.googlegroups.com: > > > > I was updating my VMS 7.3.2 systems with the UPDATE 9 patch. > > > > But I pulled an old AXP 150 out of storage and found that it has too > > > little disk space for UPDATE 9. > > > > We tried to upgrade the disks (it has a shadowset) a while back, but > > > it seems to be finicky about the disks it will use. (We have put big > > > disks on all our other Alphas) > > > > PRODUCT INSTALL says I need an extra 216,901 blocks. My dump file is > > > has already been reduced to almost nothing. My page file is at > > > 270,000. swap file at 17,500. > > > > PRODUCT INSTALL says that UPDATE 9 takes about 480,000 blocks. > > > > I guess I could just install the TDF patch and it's dependencies and > > > give up on running the same patches on all my Alpha boxes. > > > > Any other ideas? > > > Things that occur to me: > > o Get rid of the dump file. (You can always map it to the page file.) > > o Reboot (in case there are any old versions of files open.) > > o With plenty of memory, you should be able to eliminate the swap file. > > o Disable accounting and then delete the ACCOUNTNG.DAT file. > > o Delete ERRLOG.SYS from SYS$ERRORLOG (and any ERRLOG.OLD) > > o Create a new audit file with SET AUDIT/SERVER=NEW > > o Purge the entire system disk. > > o If DFU is installed, DFU DIR/COMP/TRUN SYS$SYSDEVICE:[000000...]* > > o ANALYZE/DISK/REPAIR SYS$SYSDEVICE > > o Check various directories, like SYS$EXAMPLES, for unneeded files. > > o Check directories for *_OLD.* files. > > Also check for old OPERATOR.LOG files. > > > Some files may be able to be moved to another disk, during the upgrade or > > even permanently. > > -- > Paul Sture- Hide quoted text - > > - Show quoted text - I decided to to UPGRADE V9, since TDF V3 needs at least UPGRADE V5 I reduced my page file to 30,000 and my swap file to 10,000. I started the upgrade and it is estimating that I will have 130,000 block left after the upgrade completes. That means that this AXP 150 is getting pretty close to useless for running our appllication. It has been a backup replacement in setting in storage. It would be nice to upgrade the disks on this puppy, but we had trouble when we tried it and folks on this newsgroup said the AXP 150 is picky about the disks it will run. ------------------------------ Date: Tue, 30 Jan 2007 14:54:13 -0500 From: norm.raphael@metso.com Subject: Re: Disk space problem Message-ID: Tm90IHRvIHB1dCB0b28gZmluZSBhIHBvaW50IG9uIGl0LCBidXQgaXMgdGhlIEFYUDE1MCBldmVu IHN1cHBvcnRlZCBmb3INCk9wZW5WTVMgQWxwaGEgVjcuMy0yPw0KDQpEZXRhaWxzIGFyZSBhbHNv IGxpc3RlZCBpbiB0aGUgY3VycmVudCBWQVggVk1TIFNQRCBhdA0KaHR0cDovL2gxODAwMC53d3cx LmhwLmNvbS9pbmZvL1NQMjUwMS9TUDI1MDFQRi5QREYNCg0KU1lTVEVNUyBTVVBQT1JURUQNCkFs cGhhIFN5c3RlbXMgU3VwcG9ydGVkDQpUaGlzIHNlY3Rpb24gbGlzdHMgdGhlIEFscGhhIHN5c3Rl bXMgdGhhdCBhcmUgc3VwcG9ydGVkDQpieSBPcGVuVk1TIEFscGhhIFZlcnNpb24gNy4zLTIuIFJl ZmVyIHRvIHRoZSBhcHByb3ByaWF0ZQ0KcGFnZSBhdCB0aGUgZm9sbG93aW5nIHdlYnNpdGUgZm9y IGRldGFpbHMgY29uY2VybmluZw0KQWxwaGEgaGFyZHdhcmUgY29uZmlndXJhdGlvbnMgYW5kIG9w dGlvbnM6DQpodHRwOi8vaDE4MDAyLnd3dzEuaHAuY29tL2FscGhhc2VydmVyLw0KVFVSQk9jaGFu bmVsIEJ1cy1CYXNlZCBTeXN0ZW1zDQrigKIgREVDIDMwMDAgTW9kZWxzIDMwMC8zMDBMLzMwMExY LzMwMFgNCuKAoiBERUMgMzAwMCBNb2RlbHMgNDAwLzQwMFMNCuKAoiBERUMgMzAwMCBNb2RlbHMg NTAwLzUwMFMvNTAwWA0K4oCiIERFQyAzMDAwIE1vZGVscyA2MDAvNjAwUw0K4oCiIERFQyAzMDAw IE1vZGVscyA3MDAvNzAwTFgNCuKAoiBERUMgMzAwMCBNb2RlbHMgODAwLzgwMFMNCuKAoiBERUMg MzAwMCBNb2RlbHMgOTAwLzkwMExYDQpEU1NJIEJ1cy1CYXNlZCBTeXN0ZW1zDQrigKIgREVDIDQw MDAgTW9kZWwgNjAwDQrigKIgREVDIDQwMDAgTW9kZWwgNzAwDQpYTUkgQnVzLUJhc2VkIFN5c3Rl bXMNCuKAoiBBbHBoYVNlcnZlciA4NDAwIChBbGwgY2hpcCBzcGVlZHMpDQrigKIgREVDIDcwMDAg TW9kZWwgNjAwDQrigKIgREVDIDEwMDAwIE1vZGVsIDYwMA0KUENJIEJ1cy1CYXNlZCBTeXN0ZW1z DQrigKIgQWxwaGFTZXJ2ZXIgMzAwIChBbGwgY2hpcCBzcGVlZHMpDQrigKIgQWxwaGFTZXJ2ZXIg NDAwIChBbGwgY2hpcCBzcGVlZHMpDQrigKIgQWxwaGFTZXJ2ZXIgODAwIChBbGwgY2hpcCBzcGVl ZHMpDQrigKIgQWxwaGFTZXJ2ZXIgMTAwMCAoQWxsIGNoaXAgc3BlZWRzKQ0K4oCiIEFscGhhU2Vy dmVyIDEwMDBBIChBbGwgY2hpcCBzcGVlZHMpDQrigKIgQWxwaGFTZXJ2ZXIgMTIwMCAoQWxsIGNo aXAgc3BlZWRzKQ0K4oCiIEFscGhhU2VydmVyIDIwMDAgKEFsbCBjaGlwIHNwZWVkcywgZXhjZXB0 IDUvMzc1KQ0K4oCiIEFscGhhU2VydmVyIDIxMDAgKEFsbCBjaGlwIHNwZWVkcywgZXhjZXB0IDUv Mzc1KQ0K4oCiIEFscGhhU2VydmVyIDIxMDBBIChBbGwgY2hpcCBzcGVlZHMsIGV4Y2VwdCA1LzM3 NSkNCuKAoiBBbHBoYVNlcnZlciAyMTAwQSBMUCAoQWxsIGNoaXAgc3BlZWRzKQ0K4oCiIEFscGhh U2VydmVyIDQwMDAgKEFsbCBjaGlwIHNwZWVkcykNCuKAoiBBbHBoYVNlcnZlciA0MTAwIChBbGwg Y2hpcCBzcGVlZHMpDQrigKIgQWxwaGFTZXJ2ZXIgODIwMCAoQWxsIGNoaXAgc3BlZWRzKQ0K4oCi IEFscGhhU2VydmVyIDg0MDAgKEFsbCBjaGlwIHNwZWVkcykNCuKAoiBBbHBoYVNlcnZlciBEUzEw DQrigKIgQWxwaGFTZXJ2ZXIgRFMxMEwNCuKAoiBBbHBoYVNlcnZlciBEUzE1DQrigKIgQWxwaGFT ZXJ2ZXIgRFMyMA0K4oCiIEFscGhhU2VydmVyIERTMjBFDQrigKIgQWxwaGFTZXJ2ZXIgRFMyNQ0K 4oCiIEFscGhhU2VydmVyIEVTNDANCuKAoiBBbHBoYVNlcnZlciBFUzQ1DQrigKIgQWxwaGFTZXJ2 ZXIgRVM0NyBSYWNrICoNCuKAoiBBbHBoYVNlcnZlciBFUzgwDQrigKIgQWxwaGFTZXJ2ZXIgR1M2 MA0K4oCiIEFscGhhU2VydmVyIEdTNjBFDQrigKIgQWxwaGFTZXJ2ZXIgR1M4MA0K4oCiIEFscGhh U2VydmVyIEdTMTQwDQrigKIgQWxwaGFTZXJ2ZXIgR1MxNjANCuKAoiBBbHBoYVNlcnZlciBHUzMy MA0K4oCiIEFscGhhU2VydmVyIEdTMTI4MCAqDQrigKIgRElHSVRBTCAyMTAwIFNlcnZlciBNb2Rl bCBBNTAwTVAsIEE2MDBNUA0K4oCiIEFscGhhU3RhdGlvbiAyMDAgKEFsbCBjaGlwIHNwZWVkcykN CuKAoiBBbHBoYVN0YXRpb24gMjUwIChBbGwgY2hpcCBzcGVlZHMpDQrigKIgQWxwaGFTdGF0aW9u IDI1NS8yMzMsIDI1NS8zMDANCuKAoiBBbHBoYVN0YXRpb24gNDAwIChBbGwgY2hpcCBzcGVlZHMp DQrigKIgQWxwaGFTdGF0aW9uIDUwMC8yNjYsIDUwMC8zMzMsIDUwMC80MDAsIDUwMC81MDANCuKA oiBBbHBoYVN0YXRpb24gNjAwIChBbGwgY2hpcCBzcGVlZHMpDQrigKIgQWxwaGFTdGF0aW9uIDYw MEEgKEFsbCBjaGlwIHNwZWVkcykNCuKAoiBEaWdpdGFsIFBlcnNvbmFsIFdvcmtzdGF0aW9uIDQz M2F1LCA1MDBhdSwgNjAwYXUNCuKAoiBBbHBoYVN0YXRpb24gRFMxNQ0K4oCiIEFscGhhU3RhdGlv biBEUzIwZQ0K4oCiIEFscGhhU3RhdGlvbiBEUzI1DQrigKIgQWxwaGFTdGF0aW9uIEVTNDANCuKA oiBBbHBoYVN0YXRpb24gRVM0NyBUb3dlciAqDQrigKIgQWxwaGFTdGF0aW9uIFhQOTAwL0RTMTAN CuKAoiBBbHBoYVN0YXRpb24gWFAxMDAwDQpOb3RlOg0KKiBNaW5pbXVtIG9mIE9wZW5WTVMgVmVy c2lvbiA3LjPigJMxIHBsdXMgcGF0Y2gga2l0DQpyZXF1aXJlZC4gUGxlYXNlIHJlZmVyIHRvIHRo ZSBmb2xsb3dpbmcgd2ViIHNpdGUgdG8gZmluZA0KdGhlIGN1cnJlbnQgRVY3IFBhdGNoIGtpdDoN Cg0KInRhZGFtc21hciIgPHRhZGFtc21hckB5YWhvby5jb20+IHdyb3RlIG9uIDAxLzMwLzIwMDcg MDI6MTc6MjMgUE06DQoNCj4gT24gSmFuIDMwLCAxMTozNyBhbSwgUGF1bCBTdHVyZSA8cGF1bC5z dHVyZS5ub3MuLi5AaGlzcGVlZC5jaD4gd3JvdGU6DQo+ID4gSW4gYXJ0aWNsZSA8WG5zOThDODU0 M0FFMUE3QnN0YWZmb3Jkbm9zcGFtd2luLi4uQDEzMC44MS42NC4xOTY+LA0KPiA+ICBUYWQgV2lu dGVycyA8c3RhZmZvcmQubm8uc3BhbS53aW50ZS4uLkB2ZXJpem9uLm5ldD4gd3JvdGU6DQo+ID4N Cj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+ID4gInRhZGFtc21hciIgPHRhZGFtcy4uLkB5YWhvby5j b20+IHdyb3RlIGluDQpuZXdzOjExNzAxNzE2NTIuNDI2NTI4LjMwNzA3MA0KPiA+ID4gQGE3NWcy MDAwY3dkLmdvb2dsZWdyb3Vwcy5jb206DQo+ID4NCj4gPiA+ID4gSSB3YXMgdXBkYXRpbmcgbXkg Vk1TIDcuMy4yIHN5c3RlbXMgd2l0aCB0aGUgVVBEQVRFIDkgcGF0Y2guDQo+ID4NCj4gPiA+ID4g QnV0IEkgcHVsbGVkIGFuIG9sZCBBWFAgMTUwIG91dCBvZiBzdG9yYWdlIGFuZCBmb3VuZCB0aGF0 IGl0IGhhcw0KdG9vDQo+ID4gPiA+IGxpdHRsZSBkaXNrIHNwYWNlIGZvciBVUERBVEUgOS4NCj4g Pg0KPiA+ID4gPiBXZSB0cmllZCB0byB1cGdyYWRlIHRoZSBkaXNrcyAoaXQgaGFzIGEgc2hhZG93 c2V0KSBhIHdoaWxlIGJhY2ssDQpidXQNCj4gPiA+ID4gaXQgc2VlbXMgdG8gYmUgZmluaWNreSBh Ym91dCB0aGUgZGlza3MgaXQgd2lsbCB1c2UuICAoV2UgaGF2ZSBwdXQNCmJpZw0KPiA+ID4gPiBk aXNrcyBvbiBhbGwgb3VyIG90aGVyIEFscGhhcykNCj4gPg0KPiA+ID4gPiBQUk9EVUNUIElOU1RB TEwgc2F5cyBJIG5lZWQgYW4gZXh0cmEgMjE2LDkwMSBibG9ja3MuICAgTXkgZHVtcCBmaWxlDQpp cw0KPiA+ID4gPiBoYXMgYWxyZWFkeSBiZWVuIHJlZHVjZWQgdG8gYWxtb3N0IG5vdGhpbmcuICAg TXkgcGFnZSBmaWxlIGlzIGF0DQo+ID4gPiA+IDI3MCwwMDAuICBzd2FwIGZpbGUgYXQgMTcsNTAw Lg0KPiA+DQo+ID4gPiA+IFBST0RVQ1QgSU5TVEFMTCBzYXlzIHRoYXQgVVBEQVRFIDkgdGFrZXMg YWJvdXQgNDgwLDAwMCBibG9ja3MuDQo+ID4NCj4gPiA+ID4gSSBndWVzcyBJIGNvdWxkIGp1c3Qg aW5zdGFsbCB0aGUgVERGIHBhdGNoIGFuZCBpdCdzIGRlcGVuZGVuY2llcw0KYW5kDQo+ID4gPiA+ IGdpdmUgdXAgb24gcnVubmluZyB0aGUgc2FtZSBwYXRjaGVzIG9uIGFsbCBteSBBbHBoYSBib3hl cy4NCj4gPg0KPiA+ID4gPiBBbnkgb3RoZXIgaWRlYXM/DQo+ID4NCj4gPiA+IFRoaW5ncyB0aGF0 IG9jY3VyIHRvIG1lOg0KPiA+ID4gIG8gR2V0IHJpZCBvZiB0aGUgZHVtcCBmaWxlLiAgKFlvdSBj YW4gYWx3YXlzIG1hcCBpdCB0byB0aGUgcGFnZQ0KZmlsZS4pDQo+ID4gPiAgbyBSZWJvb3QgKGlu IGNhc2UgdGhlcmUgYXJlIGFueSBvbGQgdmVyc2lvbnMgb2YgZmlsZXMgb3Blbi4pDQo+ID4gPiAg byBXaXRoIHBsZW50eSBvZiBtZW1vcnksIHlvdSBzaG91bGQgYmUgYWJsZSB0byBlbGltaW5hdGUg dGhlIHN3YXANCmZpbGUuDQo+ID4gPiAgbyBEaXNhYmxlIGFjY291bnRpbmcgYW5kIHRoZW4gZGVs ZXRlIHRoZSBBQ0NPVU5UTkcuREFUIGZpbGUuDQo+ID4gPiAgbyBEZWxldGUgRVJSTE9HLlNZUyBm cm9tIFNZUyRFUlJPUkxPRyAoYW5kIGFueSBFUlJMT0cuT0xEKQ0KPiA+ID4gIG8gQ3JlYXRlIGEg bmV3IGF1ZGl0IGZpbGUgd2l0aCBTRVQgQVVESVQvU0VSVkVSPU5FVw0KPiA+ID4gIG8gUHVyZ2Ug dGhlIGVudGlyZSBzeXN0ZW0gZGlzay4NCj4gPiA+ICBvIElmIERGVSBpcyBpbnN0YWxsZWQsIERG VSBESVIvQ09NUC9UUlVOIFNZUyRTWVNERVZJQ0U6WzAwMDAwMC4uLl0qDQo+ID4gPiAgbyBBTkFM WVpFL0RJU0svUkVQQUlSIFNZUyRTWVNERVZJQ0UNCj4gPiA+ICBvIENoZWNrIHZhcmlvdXMgZGly ZWN0b3JpZXMsIGxpa2UgU1lTJEVYQU1QTEVTLCBmb3IgdW5uZWVkZWQgZmlsZXMuDQo+ID4gPiAg byBDaGVjayBkaXJlY3RvcmllcyBmb3IgKl9PTEQuKiBmaWxlcy4NCj4gPg0KPiA+IEFsc28gY2hl Y2sgZm9yIG9sZCBPUEVSQVRPUi5MT0cgZmlsZXMuDQo+ID4NCj4gPiA+IFNvbWUgZmlsZXMgbWF5 IGJlIGFibGUgdG8gYmUgbW92ZWQgdG8gYW5vdGhlciBkaXNrLCBkdXJpbmcgdGhlDQp1cGdyYWRl IG9yDQo+ID4gPiBldmVuIHBlcm1hbmVudGx5Lg0KPiA+DQo+ID4gLS0NCj4gPiBQYXVsIFN0dXJl LSBIaWRlIHF1b3RlZCB0ZXh0IC0NCj4gPg0KPiA+IC0gU2hvdyBxdW90ZWQgdGV4dCAtDQo+DQo+ IEkgZGVjaWRlZCB0byB0byBVUEdSQURFIFY5LCBzaW5jZSBUREYgVjMgbmVlZHMgYXQgbGVhc3Qg VVBHUkFERSBWNQ0KPg0KPiBJIHJlZHVjZWQgbXkgcGFnZSBmaWxlIHRvIDMwLDAwMCBhbmQgbXkg c3dhcCBmaWxlIHRvIDEwLDAwMC4NCj4NCj4gSSBzdGFydGVkIHRoZSB1cGdyYWRlIGFuZCBpdCBp cyBlc3RpbWF0aW5nIHRoYXQgSSB3aWxsIGhhdmUgMTMwLDAwMA0KPiBibG9jayBsZWZ0IGFmdGVy IHRoZSB1cGdyYWRlIGNvbXBsZXRlcy4NCj4NCj4gVGhhdCBtZWFucyB0aGF0IHRoaXMgQVhQIDE1 MCBpcyBnZXR0aW5nIHByZXR0eSBjbG9zZSB0byB1c2VsZXNzIGZvcg0KPiBydW5uaW5nIG91ciBh cHBsbGljYXRpb24uICBJdCBoYXMgYmVlbiBhIGJhY2t1cCByZXBsYWNlbWVudCBpbiBzZXR0aW5n DQo+IGluIHN0b3JhZ2UuDQo+DQo+IEl0IHdvdWxkIGJlIG5pY2UgdG8gdXBncmFkZSB0aGUgZGlz a3Mgb24gdGhpcyBwdXBweSwgYnV0IHdlIGhhZA0KPiB0cm91YmxlIHdoZW4gd2UgdHJpZWQgaXQg YW5kIGZvbGtzIG9uIHRoaXMgbmV3c2dyb3VwIHNhaWQgdGhlIEFYUCAxNTANCj4gaXMgcGlja3kg YWJvdXQgdGhlIGRpc2tzIGl0IHdpbGwgcnVuLg0KPg0KPg== ------------------------------ Date: Tue, 30 Jan 2007 20:08:08 -0000 From: "John Wallace" Subject: Re: Disk space problem Message-ID: <45bfa5ac$0$8739$ed2619ec@ptn-nntp-reader02.plus.net> "folks on this newsgroup said the AXP 150 is picky about the disks it will run." Well if we're being picky :) It's not so much a problem with the AXP150 itself as with whichever SCSI adapter card it's got, and with the finicky nature of SCSI cabling in general (and in particular, SCSI termination). The SCSI card is likely to be an Adaptec AHA1742A (an EISA card) but iirc in an Alpha these came with DEC-specific firmware. A wide variety of disks from the relevant era and a few years thereafter are likely to appear to work, which might be an option if you can lay your hands on a couple, but given that you are using shadowing, you might wish to stick to things which had DEC part numbers which had been qualified for VMS on the Jensen (aka DECpc AXP/150, aka DEC 2000 Model 300) rather than using widely available "generic" SCSI drives. Your choice. Hth John Wallace ------------------------------ Date: 30 Jan 2007 12:43:37 -0800 From: "tadamsmar" Subject: Re: Disk space problem Message-ID: <1170189817.264798.24910@v45g2000cwv.googlegroups.com> On Jan 30, 3:08 pm, "John Wallace" wrote: > "folks on this newsgroup said the AXP 150 is picky about the disks it will > run." > > Well if we're being picky :) It's not so much a problem with the AXP150 > itself as with whichever SCSI adapter card it's got, and with the finicky > nature of SCSI cabling in general (and in particular, SCSI termination). The > SCSI card is likely to be an Adaptec AHA1742A (an EISA card) but iirc in an > Alpha these came with DEC-specific firmware. A wide variety of disks from > the relevant era and a few years thereafter are likely to appear to work, > which might be an option if you can lay your hands on a couple, but given > that you are using shadowing, you might wish to stick to things which had > DEC part numbers which had been qualified for VMS on the Jensen (aka DECpc > AXP/150, aka DEC 2000 Model 300) rather than using widely available > "generic" SCSI drives. Your choice. > > Hth > John Wallace We tried the disk that came with one of our AlphStation 400s and never got it to work. How do I find a qualified, bigger disk drive? ------------------------------ Date: Tue, 30 Jan 2007 18:43:54 -0500 From: bradhamilton Subject: Re: Fun with GNV - Watch out for MNT. Message-ID: <45BFD83A.6000506@comcast.net> Peter Weaver wrote: [...] > Both you and Brad mentioned problems with shadowed drives but the > shadowed drives on my system were handled fine (if you can call what mnt > does fine). There may have been errors when I did the initial install, > but I rushed through the install rather quickly since I was only > installing GNV for the fun of it. > > Are both you and Brad running V8.3? I'm running V8.3 - the shadowed disks do get mounted, although I did notice the "error" messages mentioned previously. df under bash shows: $ bash bash$ df Filesystem 1k-blocks Used Available Use% Mounted on _DSA0: 8886762 2611706 6275056 29% _DSA0: _DSA1: 71687369 2650121 69037248 4% _DSA1: _DSA2: 71687369 2878793 68808576 4% _DSA2: _DSA3: 71687369 7824777 63862592 11% _DSA3: _$1$DKB0: 8886762 8886762 0 100% _$1$DKB0: _$1$DKB100: 71687369 71687369 0 100% _$1$DKB100: _$1$DKB200: 71687369 71687369 0 100% _$1$DKB200: _$1$DKB300: 71687369 71687369 0 100% _$1$DKB300: _$1$DKB400: 71687369 3623881 68063488 5% _$1$DKB400: _$1$DKB500: 71687369 1504521 70182848 2% _$1$DKB500: _$1$DKB600: 71687369 23099529 48587840 32% _$1$DKB600: _$1$DKA0: 8886762 8886762 0 100% _$1$DKA0: _$1$DKA100: 71687369 71687369 0 100% _$1$DKA100: _$1$DKA200: 71687369 71687369 0 100% _$1$DKA200: _$1$DKA300: 71687369 71687369 0 100% _$1$DKA300: bash$ As you can see, I have a mixture of shadowed and non-shadowed disks, which would make the task of mounting all of them "cleanly" that much more difficult. In any case, I think that GNV could do a better job of mounting the disks, or (better, I think) giving the administrator the choice of mounting only those disks that he/she wishes, either by "interactive" means, or by populating a *.DAT file containing the names of the disks to be mounted, which GNV would read upon startup. Why, for instance, would you want to mount the VMS system disk under GNV, where it could potentially become corrupted by an inferior "operating system". :-) ------------------------------ Date: Tue, 30 Jan 2007 19:51:51 -0500 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: How long to really setup a VMS system ? Message-ID: <45bfe821$0$49209$14726298@news.sunsite.dk> Dave Weatherall wrote: > If we believe 'OpenVMS - the secure, multi-site OS that just works.' > then we do so because the privelege system works. If it works, we > should be able to allow people to log on to 'production' systems > (scope there for interpretation), with _normal_ priveleges and use DCL > or other languages to write code such as mortgage repayment calcs or > models of avionic equipment. The security model of our trusted OS > prevents them causing damage. This is a much better way of showing > that VMS is 'open'. How will you guarantee that the apps running production will still meet performance requirements ? Arne ------------------------------ Date: Wed, 31 Jan 2007 03:29:09 +0100 From: Michael Kraemer Subject: Re: How long to really setup a VMS system ? Message-ID: Arne Vajhøj schrieb: > > Some people will consider FreeBSD a major Unix. what's the market share ? > The two most obvious missing is AIX and HP-UX. > > My guess is that IBM and HP does not see them as > desktop OS'es either. They don't have a high profile as desktop OS'es, sure. On HP's part that would need a lot of spin, given the fact that they killed Alpha, PA and Itanic as desktop CPUs. IBM OTOH still offers AIX desktop systems, either PPC or Power5 based. The PPC IntelliStation is sort of a Mac G5+, so an OpenOffice port would certainly be appropriate :-) ------------------------------ Date: Tue, 30 Jan 2007 22:05:56 -0500 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: How long to really setup a VMS system ? Message-ID: <45c0078f$0$49204$14726298@news.sunsite.dk> Michael Kraemer wrote: > Arne Vajhøj schrieb: >> Some people will consider FreeBSD a major Unix. > > what's the market share ? Revenue: 0% Boxes: a good chunk especially in the web hosting business (see http://news.netcraft.com/archives/2003/07/12/nearly_2_million_active_sites_running_freebsd.html) Arne ------------------------------ Date: 30 Jan 2007 20:42:44 -0800 From: davidc@montagar.com Subject: Re: How long to really setup a VMS system ? Message-ID: <1170218564.098984.233980@a75g2000cwd.googlegroups.com> On Jan 30, 9:31 pm, Arne Vajh=F8j wrote: > We were discussing your claim about OOo not being available > for major Unixes. >From www.infobsd.org: Howto Install OpenOffice 2 on OpenBSD - OpenOffice .org 2 has just been released. Although there is no native build for OpenBSD, OpenOffice runs perfectly on OpenBSD. Here's how. > > Arne ------------------------------ Date: 30 Jan 2007 21:01:37 -0800 From: davidc@montagar.com Subject: Re: How long to really setup a VMS system ? Message-ID: <1170219697.063546.212260@j27g2000cwj.googlegroups.com> On Jan 30, 9:31 pm, Arne Vajh=F8j wrote: > I don't know it is also irrelevant for the discussion. > > We were discussing your claim about OOo not being available > for major Unixes. it's not really relevent. However, this may be: >From http://porting.openoffice.org/freebsd/ 006/Dec/21: OOo 2.1 binaries for FreeBSD 6.2-RC1 (i386) are available at [Good-Day]. Also: Solaris (Intel or Sparc) is a major Unix, and it's available I would consider Linux a major Unix, and it's available Mac/OS as it is today could be considered a major Unix, and it's available. Microsoft Windows is not even a Unix, but a major O/S (of, for the purpose of this discussion), and it's available. I'd say the list of supported platforms above covers a very large percentage of total O/S market share. Plus http://porting.openoffice.org lists AIX, Tru64, and OpenVMS ports in progress. For OpenVMS, see http://www.oooovms.dyndns.org/ "OpenOffice On OpenVMS", they could use the help. ------------------------------ Date: Wed, 31 Jan 2007 00:13:12 -0500 From: JF Mezei Subject: Re: How long to really setup a VMS system ? Message-ID: <671fd$45c0256d$cef8887a$31958@TEKSAVVY.COM> Larry Kilgallen wrote: > If those logging on to production systems are the programmers who > wrote the production applications, how do you know they did not > introduce a trojan horse ? Programmer is given a normal username in a group which does not have access to production directories and files. When the time comes to put an updated piece of software, or fix a production problem ASAP, the developer is given password to a production account, and the password is then changed (or account /DISUSERed) once the fix/patch/new version is applied. The only time you really want programmers off a production node is when they deal with core that requires privileges that can either crash a node, or grant them access to production data/processes. ------------------------------ Date: 31 Jan 2007 05:55:33 GMT From: "Dave Weatherall" Subject: Re: How long to really setup a VMS system ? Message-ID: On Wed, 31 Jan 2007 04:57:12 UTC, Kilgallen@SpamCop.net (Larry Kilgallen) wrote: > In article <45bfe821$0$49209$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= writes: > > Dave Weatherall wrote: > >> If we believe 'OpenVMS - the secure, multi-site OS that just works.' > >> then we do so because the privelege system works. If it works, we > >> should be able to allow people to log on to 'production' systems > >> (scope there for interpretation), with _normal_ priveleges and use DCL > >> or other languages to write code such as mortgage repayment calcs or > >> models of avionic equipment. The security model of our trusted OS > >> prevents them causing damage. This is a much better way of showing > >> that VMS is 'open'. > > > > How will you guarantee that the apps running production > > will still meet performance requirements ? > > If those logging on to production systems are the programmers who > wrote the production applications, how do you know they did not > introduce a trojan horse ? I refer you to the answer I gave my honorable friend, the member for Denmark :-) * JF gives another perspective/option. Do we trust the VMS security system? I am not arguing there is _never_ a case for complete isolation. My argument is that there are cases where this 'closure' has been a misplaced policy that has worked to the detriment of VMS and what helped drive the need to rebrand it as Open. -- Cheers - Dave W. PS. I've gotten to the point that when I'm asked if VMS software will work on OpenVMS.... I just give in and say yes. If even one of our former system mangers never understood the name change and insisted OpenVMS was different... ------------------------------ Date: 31 Jan 2007 05:55:28 GMT From: "Dave Weatherall" Subject: Re: How long to really setup a VMS system ? Message-ID: On Wed, 31 Jan 2007 00:51:51 UTC, Arne Vajh›j wrote: > Dave Weatherall wrote: > > If we believe 'OpenVMS - the secure, multi-site OS that just works.' > > then we do so because the privelege system works. If it works, we > > should be able to allow people to log on to 'production' systems > > (scope there for interpretation), with _normal_ priveleges and use DCL > > or other languages to write code such as mortgage repayment calcs or > > models of avionic equipment. The security model of our trusted OS > > prevents them causing damage. This is a much better way of showing > > that VMS is 'open'. > > How will you guarantee that the apps running production > will still meet performance requirements ? > > Arne Valid point Arne and comes under the 'scope for interpretation' clause :-) -- Cheers - Dave W. ------------------------------ Date: Tue, 30 Jan 2007 17:42:07 -0800 From: "Malcolm Dunnett" Subject: HSZTerm for Integrity? Message-ID: <45bff3eb$1@flight> Stupid question I'm sure, but is there any way to get HSZTERM to work on an Integrity Server (binary translation of the EXE? source available anywhere? ). Anyone within HP know if it would be giving away any trade secrets to release the source code ( or is it built in some obscure language? ) If not is there anything that can talk to HSG80s through VMS 8.x on Integrity? ------------------------------ Date: Tue, 30 Jan 2007 20:27:32 -0600 From: David J Dachtera Subject: Re: HSZTerm for Integrity? Message-ID: <45BFFE94.17335307@spam.comcast.net> Malcolm Dunnett wrote: > > Stupid question I'm sure, but is there any way to get HSZTERM > to work on an Integrity Server (binary translation of the EXE? > source available anywhere? ). > > Anyone within HP know if it would be giving away any trade secrets > to release the source code ( or is it built in some obscure language? ) > > If not is there anything that can talk to HSG80s through VMS 8.x > on Integrity? Is this a hobbyist system? HSGs being as aged as they are it's hard for me to get my mind around the idea of using them in production, except as a transition to MSA, EVA or XP12K or - *GASP* - Symmetrix (Heresy! Sacrilege! Grab your torch and pitchfork!) -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Tue, 30 Jan 2007 14:44:50 -0600 (CST) From: sms@antinode.org (Steven M. Schweda) Subject: Re: Kermit Large File Support Message-ID: <07013014444996_20219436@antinode.org> From: John Santos > Exactly, and to get back to the implication of the original post, I must have missed the original post (Info-VAX or my e-mail problem?) > "why doesn't VMS Kermit support large files?", Frank asked for help > from the VMS C-Kermit community when he was doing the original Kermit > implementation, and no on stepped forward. [...] As I recall, this on did. I offered a semi-helpful suggestion somewhere around 27-AUG-2005 14:49:35.21 (Central time), which included: 1. Use off_t (or equivalent) for file offsets (and the like), not long (or long long). 2. Define the macro _LARGEFILE (to make off_t a 64-bit item instead of 32). 3. Submit a new complaint (wake me) when that fails. Having heard no more about it, I assumed that the problem was solved. I haven't really looked closely yet, but assuming that the code now uses "off_t" instead of "long" for file offsets and sizes, the only VMS-specific change should be defining the C macro _LARGEFILE somewhere (which will work only on non-VAX systems with sufficiently recent C run-time stuff). The biggest mystery (to me) is how the user should say that he wants large-file support. > (I don't know if C on VAX supports large files, so this might require > an Alpha or Itanium. It doesn't, so far as I know. > On the other hand, even if C doesn't support > large files or for older versions of C which don't, QIO does, so there > are workarounds. Sure, if you want to write a whole new C RTL I/O subsystem for the VAX and/or older Alpha systems. > I have no idea how much of the work Frank has already > done, or if someone else is already doing at least some of it in the > background, in which case we all owe them our thanks.) The latest kit I could find seemed to be missing something: alp $ mms /des = CKVKER.MMS %MMS-F-NOACCESS, Unable to access file "CCFLAGS.MMS". -RMS-E-FNF, file not found However, the non-MMS scheme seemed to offer some promise, with a suitable "P3": @ CKVKER.COM "" "" _LARGEFILE Although: Compiling SYS$SYSDEVICE:[UTILITY.SOURCE.KERMIT.V8R0_212_2007-01-29]CKUUS3.C int svcnum = gettcpport(); ........................^ %CC-I-IMPLICITFUNC, In the initializer for svcnum, the identifier "gettcpport" i s implicitly declared as a function. at line number 4990 in file SYS$SYSDEVICE:[UTILITY.SOURCE.KERMIT.V8R0_212_2007-0 1-29]CKUUS3.C;1 and some %CC-I-QUESTCOMPARE[1] complaints, none of which seems to be related to large files. So, perhaps it already has everything it needs, if you know how to ask. WERMIT.EXE didn't explode right out of the gate, and gettcpport() seems to be an "int", anyway, so what could go wrong? Wake me when it fails. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Tue, 30 Jan 2007 21:30:31 -0600 (CST) From: sms@antinode.org (Steven M. Schweda) Subject: Re: Kermit Large File Support Message-ID: <07013021303122_20219436@antinode.org> From: sms@antinode.org (Steven M. Schweda) > From: John Santos > > > Exactly, and to get back to the implication of the original post, > > I must have missed the original post (Info-VAX or my e-mail problem?) > > > "why doesn't VMS Kermit support large files?", Frank asked for help > > from the VMS C-Kermit community when he was doing the original Kermit > > implementation, and no on stepped forward. [...] > > As I recall, this on did. I offered a semi-helpful suggestion > somewhere around 27-AUG-2005 14:49:35.21 (Central time), which included: > [...] In fact, as I scan the archives here, I see a posting from around 25-FEB-2006 which mentioned: http://antinode.org/ftp/kermit/2006-02-25/ ftp://antinode.org/kermit/2006-02-25/ The CKVKER.COM procedure has two new "P2" options: F = large-file support, and I = internal FTP. (No complaint for "F" on VAX -- lazy.) > The latest kit I could find seemed to be missing something: > > alp $ mms /des = CKVKER.MMS > %MMS-F-NOACCESS, Unable to access file "CCFLAGS.MMS". > -RMS-E-FNF, file not found Because it wasn't intended to be used that way. Never mind. It appears, however, that I never updated CKVKER.MMS to deal with the internal FTP stuff, so specifying "M" in the P1 of "@ CKVKER.COM" is pretty much a requirement. > However, the non-MMS scheme seemed to offer some promise, with a > suitable "P3": > > @ CKVKER.COM "" "" _LARGEFILE Which method is obviated by my new P1 option (not P2, as I stated originally) "F", about which I had forgotten. > Compiling > SYS$SYSDEVICE:[UTILITY.SOURCE.KERMIT.V8R0_212_2007-01-29]CKUUS3.C > > int svcnum = gettcpport(); > ........................^ > %CC-I-IMPLICITFUNC, In the initializer for svcnum, the identifier "gettcpport" i > s implicitly declared as a function. > at line number 4990 in file SYS$SYSDEVICE:[UTILITY.SOURCE.KERMIT.V8R0_212_2007-0 > 1-29]CKUUS3.C;1 That one's curable, as are all but one of the %CC-I-QUESTCOMPARE[1] complaints. If I get bored, and/or if anyone expresses any interest, I can probably plop a more current set of changed files onto my server. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Tue, 30 Jan 2007 21:21:27 GMT From: Tad Winters Subject: Looking for hobbyists in or around Oklahoma City Message-ID: So since there don't appear to be any want-to-be hobbyists, are there any current hobbyists in the Oklahoma City area that might benefit from some newer hardware? Tad Tad Winters wrote in news:Xns98C785D84B8E0staffordnospamwinter@130.81.64.196: > Please email me if you live in the Oklahoma City area but are in need > of some hardware to get started as an OpenVMS hobbyist. Remove the > .no.spam in order to send to me and put "hobbyist" in the subject so > that I can pick it out of the folder if it gets put there as spam. > I'll contact you with details. > ------------------------------ Date: 30 Jan 2007 20:28:35 -0800 From: "Hein RMS van den Heuvel" Subject: Re: Monitor rms issue on Vax Message-ID: <1170217715.513761.167190@a34g2000cwb.googlegroups.com> On Jan 30, 10:21 am, magalet...@hotmail.com wrote: > Hi , > > I am not able to do the following on Vax 7.3 system... > > $ monitor rms/file=z.z > %MONITOR-E-COLLERR, error during data collection > -SYSTEM-F-ACCVIO, access violation, reason mask=D0, virtual > address=03C00000, PC > =00000000, PSL=200000A0 > All other monitor switches seem to run fine. > > The same test runs fine on any of my Alphas, anyone have any ideas ? It's a bug. No standard tool should fall over in a smoldering heap, no matter what you feed it. I doubt it is worth fixing, but if you feel it is important for your business, then submit as problem to HP. And that's all you have as argument? Often folks add /ITE /RECO / INT ... Does the file in question have statistics enabled? Indexed file (dir/ full)? Are you running low on gblpages or gblsections (need 2 pagelettes and 1 section) Is this just a curiosity question or are you trying to solve a read problem with MONI RMS? You may find my RMS_STATS tools are good (better!) alternative to MONI RMS. See: http://h71000.www7.hp.com/freeware/freeware60/rms_tools/ Regards, Hein van den Heuvel HvdH Performance Consulting ------------------------------ Date: Wed, 31 Jan 2007 01:30:07 -0500 From: JF Mezei Subject: Mozilla: "edit" as helper application ? Message-ID: <2588b$45c03775$cef8887a$29186@TEKSAVVY.COM> Ok, I have figured out that when a web site insists on sending an image as a useless application/octet-stream, I can force it to execute /appl/xv/xv.exe and it will open that file with XV. (appl is a logical name on my system) So, this points to an actual image which is then probably invoked as a foreign command. Is there a trick to tell Mozilla to accept "edit" as a command so it would use my default editor (TPU in decwindows mode) ? If I enter a DCL command, it complains because it cannot find that file. ------------------------------ Date: Tue, 30 Jan 2007 20:08:52 -0500 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: PL/I for Itanium Message-ID: <45bfec1e$0$49205$14726298@news.sunsite.dk> Bob Koehler wrote: > In article <45bc22fb$0$49198$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= writes: >> Michael Kraemer wrote: >> Java and C# have both passed C++/C for new development. > > Nobody is doing anything in C#, and very little in Java. You > must be living in a different country. Try go into a job advertising web site in the country where you live and look up number of jobs for various programming languages. You will see that both Java and C# skills are in demand. Feel free to postulate that it is just companies wanting to look hip and that they really tell the programmers they hire to code in C/C++ (or PL/I). The IT world continue to change. 15 years ago C/C++ were eating in on Fortran, Pascal etc.. Today Java and C# is eating in on C/C++. In 15 years X will be eating in on Java and C#. >> It is not obvious to me that it is technical reasons >> that makes PL/I a mainframe and VMS/VAX thing. > > Since IBM invented PL/I I hardly think its a VAX/VMS thing. > Of course, it could need a real file system. My mention of mainframe did not mean VAX 9000 ! :-) I do not think a byte stream based file system would prevent creating a PL/I compiler. See Tom L's long list of ports. Arne ------------------------------ Date: Wed, 31 Jan 2007 02:39:40 +0100 From: Michael Kraemer Subject: Re: PL/I for Itanium Message-ID: Arne Vajhøj schrieb: > > You will see that both Java and C# skills are in demand. > Did you actually *see* somebody creating anything useful in those languages ? If your assumptions were true, we should see much more Java/C# stuff in the public domain, given the fact that at least Java exists for about a decade now. But as far as I can see almost all open source stuff in high demand still is in C/C++, and that hasn't changed for about 15 years or so. ------------------------------ Date: Tue, 30 Jan 2007 17:33:32 -0800 From: "Tom Linden" Subject: Re: PL/I for Itanium Message-ID: On Tue, 30 Jan 2007 17:02:30 -0800, Arne Vajhøj wrote: > If enough people have wanted a PL/I compiler to make > it possible to make a profit making one, then it would have > been made. Actually we do make a profit on it, and have for almost 30 years. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ Date: Tue, 30 Jan 2007 20:11:55 -0600 From: "Forster, Michael" Subject: RE: PL/I for Itanium Message-ID: <024a01c744dd$390714cc$47146a8d@mcwcorp.net> Great news! There are others that rely on or use what may be mainstream passe = languages but are needed for business or other reasons - mine is MUMPS. = There is still money and code investment and recoding time invested in = the existing code so this is still visible like pl1 I imagine. We all need to coexist. -----Original Message----- From: "Tom Linden" To: "Info-VAX@Mvb.Saic.Com" Sent: 01/30/07 7:54 PM Subject: Re: PL/I for Itanium On Tue, 30 Jan 2007 17:02:30 -0800, Arne Vajh=C3=B8j = wrote: > If enough people have wanted a PL/I compiler to make > it possible to make a profit making one, then it would have > been made. Actually we do make a profit on it, and have for almost 30 years. --=20 Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ Date: Tue, 30 Jan 2007 20:32:17 -0600 From: David J Dachtera Subject: Re: PL/I for Itanium Message-ID: <45BFFFB1.FCB2676@spam.comcast.net> "Forster, Michael" wrote: > > Great news! > > There are others that rely on or use what may be mainstream passe languages but are needed for business or other reasons - mine is MUMPS. There is still money and code investment and recoding time invested in the existing code so this is still visible like pl1 > I imagine. > > We all need to coexist. The common incarnation of MUMPS these days is InterSystems's "Cache'" which is touted as a "post-relational" database (whatever the heck that might be!). Native Cache' code as shown in the documentation looks to me to be very BASIC-like rather than the cryptic "M" syntax. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Tue, 30 Jan 2007 20:45:05 -0600 From: "Forster, Michael" Subject: RE: PL/I for Itanium Message-ID: <026a01c744e1$d1b2dd19$46146a8d@mcwcorp.net> Cache supports the newer style plus the older. Perhaps we should chat = offline as I gather you deal pre and post cache same as I. -----Original Message----- From: "David J Dachtera" To: "Info-VAX@Mvb.Saic.Com" Sent: 01/30/07 8:39 PM Subject: Re: PL/I for Itanium "Forster, Michael" wrote: >=20 > Great news! >=20 > There are others that rely on or use what may be mainstream passe = languages but are needed for business or other reasons - mine is MUMPS. = There is still money and code investment and recoding time invested in = the existing code so this is still visible like pl1 > I imagine. >=20 > We all need to coexist. The common incarnation of MUMPS these days is InterSystems's "Cache'" = which is touted as a "post-relational" database (whatever the heck that might = be!). Native Cache' code as shown in the documentation looks to me to be very BASIC-like rather than the cryptic "M" syntax. --=20 David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Tue, 30 Jan 2007 18:00:00 -0500 From: JF Mezei Subject: Re: PPPD, TCPIP Services and incomplete negotiations Message-ID: Forrest Kenney wrote: > Well there is a PPPD command that is supposed to be used to > disconnect a terminal. It it is even named disconnect. "supposed" is the keyword here ! If I have a terminal that did a PPPD CONNECT but failed to negotiate PPP, the ASN device seems to be in a state of limbo between being totally free and between connected to the TCPIP system. And DISCONNECT TTA0: does nothing. ------------------------------ Date: Tue, 30 Jan 2007 18:07:50 -0500 From: JF Mezei Subject: Re: PPPD, TCPIP Services and incomplete negotiations Message-ID: <6ca57$45bfcfcb$cef8887a$16632@TEKSAVVY.COM> Forrest Kenney wrote: > > 1) Enable Virtual terminals on TTAO It is enabled. When I log in, I get a VTAxxx device as terminal. > a formal case will have to be submitted. Then you'll have to wait for a real customer who needs this to work to make the complaint. As a hobbyist, I am not allowed to make formal complaint. But I can thank you for the time you have taken already. I'll just have to give up on PPP working. I was really looking forwards to this when I got my first alpha. ------------------------------ Date: Tue, 30 Jan 2007 18:13:39 -0500 From: Forrest Kenney Subject: Re: PPPD, TCPIP Services and incomplete negotiations Message-ID: <45BFD123.27D959D1@hp.com> The PPPD code should never have allowed the connect to happen if that is the terminal you logged in on. That is an out and out bug which also explains why the line negotioatin does not take place. I have submitted a problem report for this. For lines you are logged in on you need to have Virtual terminals enabled. This allows the PPP code to sever the VT off of TTA0, and then start of with a clean quiet line to switch over. Forrest JF Mezei wrote: > > Forrest Kenney wrote: > > Well there is a PPPD command that is supposed to be used to > > disconnect a terminal. It it is even named disconnect. > > "supposed" is the keyword here ! > > If I have a terminal that did a PPPD CONNECT but failed to negotiate PPP, > the ASN device seems to be in a state of limbo between being totally free > and between connected to the TCPIP system. And DISCONNECT TTA0: does nothing. ------------------------------ Date: Wed, 31 Jan 2007 07:19:42 +1030 From: Mark Daniel Subject: Re: Purveyor CGI mailbox capacity [bit long winded] Message-ID: <12rvbvj4qgi3603@corp.supernews.com> bob@instantwhip.com wrote: > poll about what? Hmmm. Perhaps I didn't explain myself clearly enough. I had a C program (IPCTICKER.C) send records (chunks of ASCII characters) of increasing size until I observed a newline (ACTUALLY a ) that I didn't send appear in the output. I could not see this with a record size of 1024 characters (though I suspect it may have been masked). It became obvious at 1026 characters (though I suspect it kicked in just before that). At 1024 and 1026 characters the output looked like the following. Note that in both these examples the is a non-visible but never-the-less real newline character (0x0a) as the last in each record. ***** mailbox mrs: 0 record size: 1024 total chars: 2048 fopen(ctx=rec) fputs() *0123456789_abcdefghijklmnopqrstuvwx...ABCDEFGHIJKLMNOPQRSTUVWX *0123456789_abcdefghijklmnopqrstuvwx...ABCDEFGHIJKLMNOPQRSTUVWX OUTPUT: 2048 chars ***** mailbox mrs: 0 record size: 1026 total chars: 2048 fopen(ctx=rec) fputs() *0123456789_abcdefghijklmnopqrstuvwx...ABCDEFGHIJKLMNOPQRSTUVWXY Z *0123456789_abcdefghijklmnopqrstuvwx...ABCDEFGHIJKLMNOPQRSTUV OUTPUT: 2048 chars ***** Note the 'Z' on the start of a new line. That is, a carriage-control had been inserted by Purveyor after 1024 characters, then there is the 1025th character in the record (the 'Z') and then the 1026th character in the record (the 0x0a) as a new line after the 'Z'. This obviously makes Purveyor distort/damage/corrupt (whichever you feel is appropriate) "text/.." documents with records longer than 1024 characters and can obviously distort markup such as blah into blah (making it fail) if it happens to span the 1024 character boundary. Every document therefore becomes a source of potential problems beacuse you can't be sure when it's going to bite you. According to the referenced Purveyor documentation carriage-control massaging is not applied to non-"text/.." content-types. > We want to use it and obviously someone else wants too also As I understand it that site either has commenced or is about to evaluate WASD. I just wanted to get to the bottom of some soyMAIL behaviours I could not seem to reproduce on my WASD test-bench. >... are you saying that yahmail also truncated in Purveyor? Yes. Any CGI application producing a "text/.." content-type response with records (lines) in excess of 1024 characters. Won't happen often (perhaps) but it is still a genuine issue. > Just an idea ... it says you can avoid vms mailboxes and restrictions > by writing a .DLL in "c" to handle this ... what about writing one? "SAPI Extension DLLs must be written and debugged much more thoroughly than standard CGI programs because they run in the Worker's address space. If an ISAPI Extension DLL has a bug or memory leak, the Worker itself might be affected. CGI programs are run in a subprocess and therefore any errors they have affect only that request." http://vms.process.com/~help/helpapicgi.html soyMAIL is a large, complex application that just for starters does not do it's own memory management (it relies on image rundown). It is entirely unsuitable (by design) to be run in a persistent process. Of course any application can be built with sufficient rigor as to meet any requirement. If InstantWhip is prepared to pay a per-hour project cost I'd (perhaps) be prepared to rewrite it suitable for ISAPI (and having written an ISAPI interface for WASD I do understand what's involved). ------------------------------ Date: Tue, 30 Jan 2007 19:47:01 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: TCPIP Failsafe vs ARP Cluster alias Message-ID: In article <45bde9d4$0$7524$c3e8da3@news.astraweb.com>, JF Mezei writes: > Was the /CLUSTER qualifier for TCPIP> SET INTERFACE put back in 5.6 of > TCPIP services, or had I totally misread posts here that had complained > about it being removed after 5.3 ? I really hated that SHOW INTERFACE/CLUSTER worked in one version and stopped working in the next. Normally, it continues to work for a transitional time. ------------------------------ Date: Tue, 30 Jan 2007 19:47:55 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: TCPIP Failsafe vs ARP Cluster alias Message-ID: In article <45be80b3$0$10049$c3e8da3@news.astraweb.com>, JF Mezei writes: > Ian Miller wrote: > > it was not removed but is no longer recommended. > > Is it correct to state that in a mixed cluster environment (VAX and Alpha), > the SET INT/CLUSTER= mechanism is the only way to have the vax act as a > backup to the ALpha ? (since vax does not have the failsafe > service/mechanism) ? After moving to 5.4 on ALPHA, I didn't change anything and the cluster alias continues to work in a mixed cluster. One has to use IFCONFIG instead of SHOW CLUSTER on ALPHA, though. ------------------------------ End of INFO-VAX 2007.061 ************************