INFO-VAX Wed, 21 Feb 2007 Volume 2007 : Issue 104 Contents: Re: Adding pre/post escape sequences to a "SAY" Canadian OpenVMS Seminar (07.02.20) EVE defined key problem. Re: EVE defined key problem. Re: FA: DEC Digital DLV11-J DLVJ1 M8043 & Cab Kit PDP-11 NOS NR Re: How to temporarily disable AUTO_DLIGHT_SAV? Re: Migrating C application from VMS to LINUX OpenVMS 6.2 debugger - show calls question Re: Purveyor CGI mailbox capacity [bit long winded] Re: Purveyor CGI mailbox capacity [bit long winded] Re: They are slowly coming home to the worlds ONLY virus free OS! Re: They are slowly coming home to the worlds ONLY virus free OS! Re: They are slowly coming home to the worlds ONLY virus free OS! Re: VT320 or 420 keypad codes ---------------------------------------------------------------------- Date: 21 Feb 2007 04:39:06 -0800 From: "n.rieck@sympatico.ca" Subject: Re: Adding pre/post escape sequences to a "SAY" Message-ID: <1172061546.302858.197850@v33g2000cwv.googlegroups.com> On Feb 20, 10:20 pm, David J Dachtera wrote: > JF Mezei wrote: > How about: $ bel[0,8] == 7 $ esc[0,8] == 27 $ say :== write sys$output $ say esc,"[2J",esc,"[1;1H","hello there" Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/ ------------------------------ Date: 21 Feb 2007 02:35:39 -0800 From: "n.rieck@sympatico.ca" Subject: Canadian OpenVMS Seminar (07.02.20) Message-ID: <1172054139.583563.188340@s48g2000cws.googlegroups.com> Canadian OpenVMS Seminar (07.02.20) I won't bore you with the whole thing but here are some key Itanium points. 1) there are now more Itanium CPUs installed in working system than Alphas. (this figure is industry-wide; not just HP) 2) 70 companies are involved in producing Itanium systems 3) Don't expect a quad-core Itanium2 until 2009. Reason? No chip sets are currently available which would be able to constantly feed data to all 4 cores 4) The Itanium chip can provide RAS (Reliability, Availability, Serviceability) while x86-64 systems currently do not. I heard one engineer say "Bill Gates isn't responsible for all instances of the blue-screen-of-death; the quirkiness of x86-64 and supporting chip- sets are partially to blame" Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/ ------------------------------ Date: 21 Feb 2007 06:15:27 -0800 From: "Fatz" Subject: EVE defined key problem. Message-ID: <1172067323.463933.71030@m58g2000cwm.googlegroups.com> Hello, All I want is for KP2 to split the TPU buffer but altho the key gets defined ok, the keystroke does not perform the required action. Here's what I'm seeing: $ editx/tpu [DO] Command: define key=kp2 split Key defined I press kp2 and the cursor moves one line down [DO] Command: show key kp2 KP2 is defined as 'split_window (eve$k_no_arg' in the USER keypad. This doesn't look like valid TPU to me so i just tried it with an empty arg list Command: tpu split_window Undefined procedure call SPLIT_WINDOW So I went back a step: $ editx/tpu Command: sho key kp2 KP2 is defined as 'typing' in the NUMERIC keypad So I press KP2 and the cursor moves down one line as tho it had been defined to MOVE_DOWN. Thanks for any help, Fatz. ------------------------------ Date: 21 Feb 2007 08:45:09 -0800 From: "Fatz" Subject: Re: EVE defined key problem. Message-ID: <1172076307.711196.282510@j27g2000cwj.googlegroups.com> Thanks for responding: Using "two" instead of "split" had no effect. > TPU MESSAGE(STR(READ_KEY)) DOWN I am indeed using an eXceed DECterm. Settings are VT300 mode, 7 bit. I've tried VT100, no change. Tried setting terminal lD to VT100 and VT320 both with no luck. SET TERM/DEV=VT100 also had no effect. What else should I be looking at? (Do I need to be creating new DECterms to see the changes or is Apply/OK in the properties box sufficient?) Thanks again, Fatz. ------------------------------ Date: Wed, 21 Feb 2007 18:16:08 GMT From: Rob Brown Subject: Re: FA: DEC Digital DLV11-J DLVJ1 M8043 & Cab Kit PDP-11 NOS NR Message-ID: On Tue, 20 Feb 2007, Jeff Shirley wrote: > In vmsnet.pdp-11 David J Dachtera wrote: > >> (Old joke from the movie, "Airplane".) > [snip] > > Classic Leslie Nielsen, indeed! > > "This woman has to be gotten to a hospital." > "A hospital? What is it? > "It's a big building with patients, but that's not important right now." I think Classic Leslie Nielsen would have to be: "Nice planet you have here. High oxygen content." "I seldom use it myself, sir. It promotes rust." - Forbidden Planet, 1956 -- Rob Brown b r o w n a t g m c l d o t c o m G. Michaels Consulting Ltd. (780)438-9343 (voice) Edmonton (780)437-3367 (FAX) http://gmcl.com/ ------------------------------ Date: 21 Feb 2007 07:21:14 -0800 From: "tadamsmar" Subject: Re: How to temporarily disable AUTO_DLIGHT_SAV? Message-ID: <1172071274.756399.251610@m58g2000cwm.googlegroups.com> On Feb 16, 4:53 pm, norm.raph...@metso.com wrote: > "tadamsmar" wrote on 02/16/2007 04:15:01 PM: > > > > > > > On Feb 16, 11:49 am, norm.raph...@metso.com wrote: > > > "tadamsmar" wrote on 02/16/2007 10:07:16 AM: > > > > > On Feb 13, 10:10 pm, Ken Fairfield > wrote: > > > > > tadamsmarwrote: > > > > > > I have the following notes on how to set AUTO_DLIGHT_SAV > > > > > > > SYSMAN > > > > > > PARA SET AUTO_DLIGHT_SAV 1 > > > > > > PARA WRITE ACTIVE > > > > > > PARA WRITE CURRENT > > > > > > reboot > > > > > > A late reply here, but I'd note that the above sequence > > > > > is dangerous! Don't do it... > > > > > > You're overwriting the CURRENT parameters (as created > > > > > by AUTOGEN and stored in ALPHAVMSSYS.PAR) with the > > > > > ACTIVE(in-memory) parameters; ALL of them. The > > > > > ACTIVE paramters do NOT all have the same values > > > > > as the CURRENT parameters. > > > > > > Instead, be sure to USE the parameter set you want prior > > > > > to changing a value: > > > > > > $ MCR SYSMAN > > > > > SYSMAN> use active > > > > > SYSMAN> set AUTO_DLIGHT_SAV 1 > > > > > SYSMAN> show . ! Verify setting > > > > > SYSMAN> write active > > > > > SYSMAN> use current > > > > > SYSMAN> set AUTO_DLIGHT_SAV 1 > > > > > SYSMAN> show . > > > > > SYSMAN> write current ! Only AUTO_DLIGHT_SAV changed > > > > > SYSMAN> exit > > > > > > Regards, Ken > > > > > -- > > > > > Ken & Ann Fairfield > > > > > What: Ken dot And dot Ann > > > > > Where: Gmail dot Com > > > > > Thanks. To be exact: > > > > > > $ MCR SYSMAN > > > > > SYSMAN> para use active > > > > > SYSMAN> para set AUTO_DLIGHT_SAV 1 > > > > > SYSMAN> para show auto ! Verify setting > > > > > SYSMAN> para write active > > > > > SYSMAN> para use current > > > > > SYSMAN> para set AUTO_DLIGHT_SAV 1 > > > > > SYSMAN> para show auto > > > > > SYSMAN> para write current ! Only AUTO_DLIGHT_SAV > > > changed > > > > > SYSMAN> exit > > > > ..but IIRC AUTO_DLIGHT_SAV is not dynamic, > > > so "WRITE ACTIVE" will not change anything; > > > a REBOOT will still be required. > > > > Did you try: > > > SYSMAN> para use active > > > SYSMAN> para show auto ! Really Verify setting > > > > after "SYSMAN> para write active" above?- Hide quoted text - > > > > - Show quoted text - > > > I did not. Actually I was setting AUTO_DAYLIGHT_SAV to 0 when I was > > trying the command sequence. > > I did not verify the setting. But I already knew that this machine > > had it enabled. > > > Why do the verification? > > ..because AUTO_DLIGHT_SAV is not dynamic, so you cannot change the > ACTIVE parameters and it does not warn you. A reboot is still required > > Here's my Alpha V7.3-1 > > SYSGEN> USE ACTIVE > SYSGEN> SHO AUTO > Parameter Name Current Default Min. Max. Unit > Dynamic > -------------- ------- ------- ------- ------- ---- > ------- > AUTO_DLIGHT_SAV 1 0 0 1 Boolean > SYSGEN> SET AUTO 0 > SYSGEN> WRITE ACTIVE > SYSGEN> USE ACTIVE > SYSGEN> SHO AUTO > Parameter Name Current Default Min. Max. Unit > Dynamic > -------------- ------- ------- ------- ------- ---- > ------- > AUTO_DLIGHT_SAV 1 0 0 1 Boolean > SYSGEN> > > Note that I set it and wrote it and it did not complain, but when I read it > again > and showed it, there was actually no change; the set/write silently did > nothing.- Hide quoted text - > > - Show quoted text - So, the proper procedure would be: $ MCR SYSMAN SYSMAN> param use current SYSMAN> param set AUTO_DLIGHT_SAV 1 SYSMAN> param show AUTO SYSMAN> param write current SYSMAN> exit The reboot and update MODPARAMS.DAT And same procedure to turn it off, except set it to 0. Correct? ------------------------------ Date: 20 Feb 2007 23:19:37 -0800 From: "klaus1" Subject: Re: Migrating C application from VMS to LINUX Message-ID: <1172042377.535263.233810@k78g2000cwa.googlegroups.com> On 19 Feb., 18:36, Paul Repacholi wrote: > "klaus1" writes: > > i mean how can I port RMS spezific things in VMS to Linux ? > > WHICH `RMS things'? Unless you want to write all of RMS for > Uoids, and add metadata to the file systems. > > Called a SMOP* by gung ho managers AIR. > > *Small Matter of Programming I do use an Oracle DBMS. only a few things are written with RMS. ------------------------------ Date: 21 Feb 2007 07:22:26 -0800 From: "Charlie" Subject: OpenVMS 6.2 debugger - show calls question Message-ID: <1172071346.051494.234390@s48g2000cws.googlegroups.com> Dusting off my vms debugger knowledge from a long ways back.... I'm getting an access violation when debugging some code, no real rocket science there :). So, the debugger breaks and I can do a show calls to display the trail of destruction. Something way back in my head seems to recall that I can go up the call stack to check variables, etc. Yes? Been through the doc and help, and I don't see it... but I could swear I used to do this..... ------------------------------ Date: Wed, 21 Feb 2007 20:28:59 +1030 From: Mark Daniel Subject: Re: Purveyor CGI mailbox capacity [bit long winded] Message-ID: <12to648mkgidad6@corp.supernews.com> bob@instantwhip.com wrote: > On Feb 20, 2:45 pm, Mark Daniel wrote: > >>Mark Daniel wrote: >> >>>Yes, I can't really believe I'm doing this, myself ;-} >> >>>Chasing some odd behaviours of soyMAIL under Purveyor for a NZ evaluator >>>(yup, I know I said it was not supported - it still - almost - isn't, >>>and I think lot this may be the final nail) I have ended up going back >>>to basics with the CGI stream. To make a long story a little >>>shorter I have probed the Purveyor CGI output interface using a slightly >>>tailored-for-Purveyor version of the WASD utility IPCTICKLER.C >> >>>From http://vms.process.com/~help/helpapicgi.html... >> >>>"Just as with POSTed data, an OpenVMS mailbox is used to deliver the CGI >>>program's output to the server (for sending to the browser). Because of >>>the way OpenVMS handles mailboxes (which are record, not carriage >>>control, oriented devices), some special considerations apply. In >>>particular, Purveyor appends a line terminator (CR/LF) to each record >>>written by the CGI program when the Content-type is text (such as >>>text/html or text/plain). For all other Content-types, Purveyor does not >>>append anything to each record written. For binary data, a content-type >>>other than text must be used (usually, binary output is >>>application/octet-stream or some other content type)." >> >>>This is not terribly startling because any such interface needs to do >>>much the same to provide for record-oriented output from DCL utilities >>>and the like. The critical ascpect is the fixed nature of the >>>carriage-control adjustment for *all* "text/.." content-types. >> >>>My probing indicates a maximum of 1024 characters in any one record >>>before potentially inappropriate carriage-control is introduced. This >>>may seem like a lot but when at least some of the content is out of the >>>application's control (e.g. message body, MIME part, HTML message >>>content) this may occasionally be exceeded making the application >>>(soyMAIL) unreliable. Also, soyMAIL is written in the belief that we >>>can leave the output buffering to the C-RTL, and so some of it's own >>>fprintf()s can generate a lot of output, potentially overflowing >>>internal RTL buffers and thence mailbox buffers. (And I certainly don't >>>feel any impulse to count all the fixed characters and all the formatted >>>strings, etc., of every fprintf() in all my code to ensure statements >>>stay within some arbitrary limit.) >> >>>I'm guessing there are no undocumented work-arounds for Purveyor and >>>this issue but thought I might poll the community before abandoning it >>>altogether. >> >>>(I should add that this not an issue for VMS Apache, OSU or WASD because >>>of available mechanisms allowing such carriage-control massaging >>>behaviours to be script-controlled.) >> >>It's been three weeks since the initial post and apart from the expected >>input from Bob Ceculski there has no comment either confirming or >>disputing the issue, or providing a programmatic work-around. This >>indicates any/all of; nobody in the Purveyor community reads c.o.v. >>(apart from BC), nobody from PSC is permitted to comment(/support) >>Purveyor (even informally), nobody is using Purveyor on VMS (apart from >>BC), no concern about data corruption in the Purveyor community (even >>BC), no interest at all (apart from BC). As this is a serious issue the >>next release of soyMAIL (Real Soon Now(tm)) will have Purveyor support >>written out and the application will advise it cannot be (safely) run >>under Purveyor.- Hide quoted text - >> >>- Show quoted text - [Normally I try to avoid this sort of rant but occasionally the level of frustration becomes great enough as to require catharsis.] > no problem Mark ... Process software will remedy the situation > hopefully ... "TCPware for PDP-11 and Purveyor for OpenVMS ------------------------------------------- TCPware for PDP-11 and Purveyor for OpenVMS products are sold 'as is' and there is no bug fixing service available. There will be no further enhancements to the TCPware for PDP-11 or Purveyor for OpenVMS products." http://www.process.com/techsupport/maintagreement.html > that is another reason why it pays to pay for software and support > instead > of freeware because when you have a problem, the author seems to > either > pull a Bill Clinton (I tried as hard as I could), or just vanish to > some beach > in the Bahamas ... Instantwhip certainly paid for Purveyor, Bob but if PSC have continued billing the company for maintenance (and it has been remitting same) then consult a lawyer - not even a good one, any graduate should be able to win the case - considering Purveyor support was discontinued in 1999. Now let's see. As an example; Purveyor and WASD are approximately the same vintage - originating circa mid-nineties. Instantwhip paid for Purveyor up-front, paid annual maintenance for what, five years(?), and then not only had further development terminated but any future support as well! WASD, while not perfect at any stage, has continued to evolve, receive maintenance and support well in excess of twice the life of Purveyor (so far). I fail to see how you can use Purveyor as substantiation for the advantages of 'why it pays to pay'! [Before anyone tries to explain the 'Bob-how' to me - this is a rhetorical usage. :-] Now *you* have a *problem*. It's not with soyMAIL. soyMAIL exposes the problem. The problem is a Purveyor data corruption. It's not freeware. You paid for it. Get satisfaction! And while the name of Bill Clinton is hanging in the air; my personal favourites are: "I have never had sexual relations with Monica Lewinsky." "I did not have sexual relations with that woman ..." "There is not a sexual relationship ... " "Indeed I did have a relationship with Miss Lewinsky ..." http://en.wikipedia.org/wiki/Clinton_administration [Though I can't imagine Bob being held even partly responsible for this by having voted Democrat.] > Now Mark said he would try for a fee, but the lesson is freeware never > ends up being free ... 1) I believe I am being misrepresented here Bob. If you are refering to my aside "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)." http://groups.google.com/group/comp.os.vms/msg/8710d62deffc9439 then that was obviously in the context of an Instantwhip/ISAPI-specific version of soyMAIL. Now, if you need a site-specific customisation of anything, open-source or vendor-proprietory, you either do it yourself (if possible) or pay someone (perhaps the vendor) to do it on your behalf. In fact in light of the "it pays to pay for software and support" above, I'm surprised you're bemoaning the suggestion that a special project should cost hard currency and instead be embracing the offer (not that it was anything other than rhetoric) as being completely in line with your business philosophy. If Instantwhip enjoys or requires the functionality of Web-based VMS email access (such as soyMAIL provides) then perhaps it should consider a purchase of and maintenance agreement for a product such as Quintara from Brilliant Systems http://www.brilliant.com/qsoft.html (Though I'd suggest that if Quintara would be CGI-based under Purveyor it would be just as affected by the data corruption unless it can guarantee that no record it sends to the script process SYS$OUTPUT exceeds 1024 characters. If it's ISAPI based then your problem's solved! If not, then perhaps they'd be interested in knocking-up an ISAPI release for the Purveyor community.) 2) Though the terms are often used interchangably (I do it myself) I believe you are confusing 'freeware' and 'free software'. http://en.wikipedia.org/wiki/Freeware http://en.wikipedia.org/wiki/Free_software 'Free software' continues the noble tradition established early by DECUS and similar user groups - sharing of knowlege, experience, effort and resources. Considering the (excellent) descriptions above, soyMAIL (and WASD) certainly fall into the latter rather than former category. You are correct, 'freeware' often does not end up free of cost (it can be a 'teaser' from a company hoping you'll buy the version containing the desirable capabilities - not always but common enough). Whereas 'free software' is always free of cost because the term implies the availability of the source code and associated resources. If it doesn't do exactly what you need *you* can modify it - or (for whatever reasons - time, skills or other constraints) you can employ someone to do that for you. (You *may* be obliged by the original license to make those changes generally available but that's a different issue.) What you can't expect is the 'free software' community to do *your* programming for you. ------------------------------ Date: 21 Feb 2007 06:07:54 -0800 From: bob@instantwhip.com Subject: Re: Purveyor CGI mailbox capacity [bit long winded] Message-ID: <1172066874.554177.187940@q2g2000cwa.googlegroups.com> On Feb 21, 4:58 am, Mark Daniel wrote: > b...@instantwhip.com wrote: > > On Feb 20, 2:45 pm, Mark Daniel wrote: > > >>Mark Daniel wrote: > > >>>Yes, I can't really believe I'm doing this, myself ;-} > > >>>Chasing some odd behaviours of soyMAIL under Purveyor for a NZ evaluator > >>>(yup, I know I said it was not supported - it still - almost - isn't, > >>>and I think lot this may be the final nail) I have ended up going back > >>>to basics with the CGI stream. To make a long story a little > >>>shorter I have probed the Purveyor CGI output interface using a slightly > >>>tailored-for-Purveyor version of the WASD utility IPCTICKLER.C > > >>>From http://vms.process.com/~help/helpapicgi.html... > > >>>"Just as with POSTed data, an OpenVMS mailbox is used to deliver the CGI > >>>program's output to the server (for sending to the browser). Because of > >>>the way OpenVMS handles mailboxes (which are record, not carriage > >>>control, oriented devices), some special considerations apply. In > >>>particular, Purveyor appends a line terminator (CR/LF) to each record > >>>written by the CGI program when the Content-type is text (such as > >>>text/html or text/plain). For all other Content-types, Purveyor does not > >>>append anything to each record written. For binary data, a content-type > >>>other than text must be used (usually, binary output is > >>>application/octet-stream or some other content type)." > > >>>This is not terribly startling because any such interface needs to do > >>>much the same to provide for record-oriented output from DCL utilities > >>>and the like. The critical ascpect is the fixed nature of the > >>>carriage-control adjustment for *all* "text/.." content-types. > > >>>My probing indicates a maximum of 1024 characters in any one record > >>>before potentially inappropriate carriage-control is introduced. This > >>>may seem like a lot but when at least some of the content is out of the > >>>application's control (e.g. message body, MIME part, HTML message > >>>content) this may occasionally be exceeded making the application > >>>(soyMAIL) unreliable. Also, soyMAIL is written in the belief that we > >>>can leave the output buffering to the C-RTL, and so some of it's own > >>>fprintf()s can generate a lot of output, potentially overflowing > >>>internal RTL buffers and thence mailbox buffers. (And I certainly don't > >>>feel any impulse to count all the fixed characters and all the formatted > >>>strings, etc., of every fprintf() in all my code to ensure statements > >>>stay within some arbitrary limit.) > > >>>I'm guessing there are no undocumented work-arounds for Purveyor and > >>>this issue but thought I might poll the community before abandoning it > >>>altogether. > > >>>(I should add that this not an issue for VMS Apache, OSU or WASD because > >>>of available mechanisms allowing such carriage-control massaging > >>>behaviours to be script-controlled.) > > >>It's been three weeks since the initial post and apart from the expected > >>input from Bob Ceculski there has no comment either confirming or > >>disputing the issue, or providing a programmatic work-around. This > >>indicates any/all of; nobody in the Purveyor community reads c.o.v. > >>(apart from BC), nobody from PSC is permitted to comment(/support) > >>Purveyor (even informally), nobody is using Purveyor on VMS (apart from > >>BC), no concern about data corruption in the Purveyor community (even > >>BC), no interest at all (apart from BC). As this is a serious issue the > >>next release of soyMAIL (Real Soon Now(tm)) will have Purveyor support > >>written out and the application will advise it cannot be (safely) run > >>under Purveyor.- Hide quoted text - > > >>- Show quoted text - > > [Normally I try to avoid this sort of rant but occasionally the level of > frustration becomes great enough as to require catharsis.] > > > no problem Mark ... Process software will remedy the situation > > hopefully ... > > "TCPware for PDP-11 and Purveyor for OpenVMS > ------------------------------------------- > TCPware for PDP-11 and Purveyor for OpenVMS products are sold 'as is' > and there is no bug fixing service available. There will be no > further enhancements to the TCPware for PDP-11 or Purveyor for > OpenVMS products." > > http://www.process.com/techsupport/maintagreement.html > > > that is another reason why it pays to pay for software and support > > instead > > of freeware because when you have a problem, the author seems to > > either > > pull a Bill Clinton (I tried as hard as I could), or just vanish to > > some beach > > in the Bahamas ... > > Instantwhip certainly paid for Purveyor, Bob but if PSC have continued > billing the company for maintenance (and it has been remitting same) > then consult a lawyer - not even a good one, any graduate should be able > to win the case - considering Purveyor support was discontinued in 1999. > > Now let's see. As an example; Purveyor and WASD are approximately the > same vintage - originating circa mid-nineties. Instantwhip paid for > Purveyor up-front, paid annual maintenance for what, five years(?), and > then not only had further development terminated but any future support > as well! WASD, while not perfect at any stage, has continued to evolve, > receive maintenance and support well in excess of twice the life of > Purveyor (so far). > > I fail to see how you can use Purveyor as substantiation for the > advantages of 'why it pays to pay'! [Before anyone tries to explain the > 'Bob-how' to me - this is a rhetorical usage. :-] > > Now *you* have a *problem*. It's not with soyMAIL. soyMAIL exposes the > problem. The problem is a Purveyor data corruption. It's not freeware. > You paid for it. Get satisfaction! > > And while the name of Bill Clinton is hanging in the air; my personal > favourites are: > > "I have never had sexual relations with Monica Lewinsky." > "I did not have sexual relations with that woman ..." > "There is not a sexual relationship ... " > "Indeed I did have a relationship with Miss Lewinsky ..." > > http://en.wikipedia.org/wiki/Clinton_administration > > [Though I can't imagine Bob being held even partly responsible for this > by having voted Democrat.] > > > Now Mark said he would try for a fee, but the lesson is freeware never > > ends up being free ... > > 1) I believe I am being misrepresented here Bob. > > If you are refering to my aside > > "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)." > > http://groups.google.com/group/comp.os.vms/msg/8710d62deffc9439 > > then that was obviously in the context of an Instantwhip/ISAPI-specific > version of soyMAIL. Now, if you need a site-specific customisation of > anything, open-source or vendor-proprietory, you either do it yourself > (if possible) or pay someone (perhaps the vendor) to do it on your > behalf. In fact in light of the "it pays to pay for software and > support" above, I'm surprised you're bemoaning the suggestion that a > special project should cost hard currency and instead be embracing the > offer (not that it was anything other than rhetoric) as being completely > in line with your business philosophy. > > If Instantwhip enjoys or requires the functionality of Web-based VMS > email access (such as soyMAIL provides) then perhaps it should consider > a purchase of and maintenance agreement for a product such as Quintara > from Brilliant Systems > > http://www.brilliant.com/qsoft.html > > (Though I'd suggest that if Quintara would be CGI-based under Purveyor > it would be just as affected by the data corruption unless it can > guarantee that no record it sends to the script process SYS$OUTPUT > exceeds 1024 characters. If it's ISAPI based then your problem's > solved! If not, then perhaps they'd be interested in knocking-up an > ISAPI release for the Purveyor community.) > > 2) Though the terms are often used interchangably (I do it myself) I > believe you are confusing 'freeware' and 'free software'. > > http://en.wikipedia.org/wiki/Freeware > http://en.wikipedia.org/wiki/Free_software > > 'Free software' continues the noble tradition established early by DECUS > and similar user groups - sharing of knowlege, experience, effort and > resources. > > Considering the (excellent) descriptions above, soyMAIL (and WASD) > certainly fall into the latter rather than former category. You are > correct, 'freeware' often does not end up free of cost (it can be a > 'teaser' from a company hoping you'll buy the version containing the > desirable capabilities - not always but common enough). Whereas 'free > software' is always free of cost because the term implies the > availability of the source code and associated resources. If it doesn't > do exactly what you need *you* can modify it - or (for whatever reasons > - time, skills or other constraints) you can employ someone to do that > for you. (You *may* be obliged by the original license to make those > changes generally available but that's a different issue.) What you > can't expect is the 'free software' community to do *your* programming > for you.- Hide quoted text - > > - Show quoted text - I don't expect it, but that what many others think will happen when it does not ... ------------------------------ Date: 21 Feb 2007 03:33:59 -0800 From: "n.rieck@sympatico.ca" Subject: Re: They are slowly coming home to the worlds ONLY virus free OS! Message-ID: <1172057639.663369.150360@h3g2000cwc.googlegroups.com> On Feb 21, 5:52 am, "n.ri...@sympatico.ca" wrote: > wrote in message > [...snip...] > > Most of the stuff on our Solaris-8 system is managed by an external > contractor. So yesterday, for the first time and at the request of my > boss, it was my pleasure to log ontowww.Sun.comand search for two > DST patches required for March-11. The Solaris process was totally > convoluted compared to my experiences downloading patches for OpenVMS. > > Now maybe I just haven't looked far enough, but I did not see anything > similar to the consolidated kits found at the OpenVMS patch site. UNIX > systems are not as easy to manage as OpenVMS. > Oops! Consolidated patch kits in the Solaris world are called "patch clusters". (is this what they mean when they say that Sun has clustering? :-) Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/ ------------------------------ Date: Wed, 21 Feb 2007 21:22:51 +0800 From: Paul Repacholi Subject: Re: They are slowly coming home to the worlds ONLY virus free OS! Message-ID: <87abz763x0.fsf@k9.prep.synonet.com> "Michael D. Ober" writes: > That's because you and most of this group, including myself anymore, > don't do real-time (RT), time critical computing. Although VMS can > get close, it is simply _NOT_ a real-time OS in the sense that when > an event occurs, the OS will guarantee it handles the event within a > specified time. OS9000 is a RT OS and does make these types of > guarantees. However, the tradeoff for these guarantees is that > OS9000 isn't very good for general purpose computing. Sorry, but Vax VMS at least CAN do this. It gets sort of ugly, and reaching for a sprinkle of ELN is a very tempting option, but, yes you CAN do hard RT with VaxVMS. Not triedor done that on an Alpha, so I'll pass. ------------------------------ Date: Wed, 21 Feb 2007 21:19:44 +0800 From: Paul Repacholi Subject: Re: They are slowly coming home to the worlds ONLY virus free OS! Message-ID: <87ejoj6427.fsf@k9.prep.synonet.com> bill@cs.uofs.edu (Bill Gunshannon) writes: > OpenVMS/VMS 7 Cert Vulnerabilities listed > OS9000 0 Cert Vulnerabilities listed > So, based on boob's favorite criteria, which OS should they have > chosen? Well, if you gave us the CERT count for VaxELN... ------------------------------ Date: 21 Feb 2007 00:34:54 -0800 From: "urbancamo" Subject: Re: VT320 or 420 keypad codes Message-ID: <1172046894.759243.38730@t69g2000cwt.googlegroups.com> I use minicom to connect to my Alpha serial port. It works very well. Mark. John Santos wrote: > Thomas Dickey wrote: > > Steve Bainbridge wrote: > > > > > >>Is it possible to use xterm to access the console port of a VMS system > >>i.e. via a PCs serial port ? > > > > > > There's a program called "seyon" which does modem connections as a shell > > around xterm. > > > > (I haven't used serial connections in quite a while -ymmv). > > iirc, Debian has a package for it. > > > > Another possibility is to run C-Kermit in an xterm window on the Linux > box, and connect to the VMS system's console using a null modem between > a serial port on the Linux box and the VMS serial console port. > > You could also use latd's llogin program (Unix LAT emulator) to a > DECServer terminal server with a null modem connected to the VMS serial > console (or a bunch of VMS serial consoles) running in an xterm window. > Telnet to an IP-capable terminal server would also work. (Some people > have said they've experienced serious problems with latd, but I've not > had any problems in light usage on a Mac OS X 10.4 Powerbook.) > > -- > John Santos > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 ------------------------------ End of INFO-VAX 2007.104 ************************