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 <stdout> mailbox capacity [bit long winded]
Re: Purveyor CGI <stdout> 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" <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 <djesys...@spam.comcast.net>
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" <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" <comedyox@yahoo.co.uk>
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" <comedyox@yahoo.co.uk>
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 <mylastname@gmcl.com>
Subject: Re: FA: DEC Digital DLV11-J DLVJ1 M8043 & Cab Kit PDP-11 NOS NR
Message-ID: <Pine.LNX.4.61.0702211110120.2670@localhost.localdomain>
On Tue, 20 Feb 2007, Jeff Shirley wrote:
> In vmsnet.pdp-11 David J Dachtera <djesys.no@spam.comcast.net> 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" <tadamsmar@yahoo.com>
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" <tadams...@yahoo.com> wrote on 02/16/2007 04:15:01 PM:
>
>
>
>
>
> > On Feb 16, 11:49 am, norm.raph...@metso.com wrote:
> > > "tadamsmar" <tadams...@yahoo.com> wrote on 02/16/2007 10:07:16 AM:
>
> > > > On Feb 13, 10:10 pm, Ken Fairfield <K...@Napili.Fairfield.Home>
> 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" <klaus.schu@gmail.com>
Subject: Re: Migrating C application from VMS to LINUX
Message-ID: <1172042377.535263.233810@k78g2000cwa.googlegroups.com>
On 19 Feb., 18:36, Paul Repacholi <p...@prep.synonet.com> wrote:
> "klaus1" <klaus.s...@gmail.com> 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" <cgilley@bravesw.com>
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 <mark.daniel@vsm.com.au>
Subject: Re: Purveyor CGI <stdout> mailbox capacity [bit long winded]
Message-ID: <12to648mkgidad6@corp.supernews.com>
bob@instantwhip.com wrote:
> On Feb 20, 2:45 pm, Mark Daniel <mark.dan...@vsm.com.au> 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 <stdout> 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 <stdout> mailbox capacity [bit long winded]
Message-ID: <1172066874.554177.187940@q2g2000cwa.googlegroups.com>
On Feb 21, 4:58 am, Mark Daniel <mark.dan...@vsm.com.au> wrote:
> b...@instantwhip.com wrote:
> > On Feb 20, 2:45 pm, Mark Daniel <mark.dan...@vsm.com.au> 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 <stdout> 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" <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" <n.ri...@sympatico.ca>
wrote:
> <b...@instantwhip.com> 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 <prep@prep.synonet.com>
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" <obermd.@.alum.mit.edu.nospam> 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 <prep@prep.synonet.com>
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" <mark@wickensonline.co.uk>
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 <stephen_bainbridge@yahoo.co.uk> 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
************************