INFO-VAX Mon, 05 Mar 2007 Volume 2007 : Issue 128
Contents:
Re: alpha sbc 5/480
Re: alpha sbc 5/480
Re: Can Samba be used to access Windows files on VMS
Re: DECforms
DNS- What I'm doing wrong?
Firmware-downgrade
Re: Firmware-downgrade
Re: Firmware-downgrade
Re: Firmware-downgrade
Re: Firmware-downgrade
Re: FYI We now have qty of DS15 systems
Re: FYI We now have qty of DS15 systems
Re: Going from Pathworks 7.3 to Samba
MediaWiki on OpenVMS?
Re: Oracle moves to per-chip licencing
Re: Purveyor CGI <stdout> mailbox capacity [bit long winded]
Re: Purveyor CGI <stdout> mailbox capacity [bit long winded]
Re: Purveyor CGI <stdout> mailbox capacity [bit long winded]
Re: SAMBA on OpenVMS with OS X client
Re: SWAT using Samba v3 on VMS8.2
Re: SYS$INPUT problem (I guess) running Java 1.42 servlet
VAX 7000-640
Re: VAX 7000-640
Re: VMS Client to Windows Storage Server x64 R2
Re: Wanted: MicroVAX I / VAXstation I owners
Re: Wanted: MicroVAX I / VAXstation I owners
Re: Wanted: MicroVAX I / VAXstation I owners
----------------------------------------------------------------------
Date: Mon, 5 Mar 2007 13:38:42 -0000
From: "chris" <christian.rothwell@baesystems>
Subject: Re: alpha sbc 5/480
Message-ID: <45ec1a25$1_1@glkas0286.greenlnk.net>
thanks i will post on there.
"Peter 'EPLAN' LANGSTOeGER" <peter@langstoeger.at> wrote in message
news:45ec25e7$1@news.langstoeger.at...
> In article <45ec0521$1_1@glkas0286.greenlnk.net>, "chris"
> <christian.rothwell@baesystems> writes:
>>I have an alpha SBC 5/480 in a vme rack taking up slots 4 and 5, i keep
>>getting random crashes on the sbc, an sbc in slots 1 and 2 is ok. The SBC
>>takes a few attempts to boot correctly, i have to keep flicking the reset
>>switch, sometime the LED display lights up all the segments, I have
>>changed
>>the SBC with a known working one and the fault still persists.
>>
>>When it does boot , it crashes intermittantly later on.
>>
>>ps ive had a vmetro in the subrack and there does not appear to be any
>>bus
>>errors
>>
>>Anyone help , before I go and change the whole vme subrack
>
> Try a better newsgroup (as VME bus <==> VMS opsys): comp.sys.dec
> and good luck
>
> --
> Peter "EPLAN" LANGSTOEGER
> Network and OpenVMS system specialist
> E-mail peter@langstoeger.at
> A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist
------------------------------
Date: Mon, 5 Mar 2007 15:51:27 -0000
From: "chris" <christian.rothwell@baesystems>
Subject: Re: alpha sbc 5/480
Message-ID: <45ec3942$1_1@glkas0286.greenlnk.net>
replaced VME rack and its sorted it!
"chris" <christian.rothwell@baesystems> wrote in message
news:45ec1a25$1_1@glkas0286.greenlnk.net...
> thanks i will post on there.
>
> "Peter 'EPLAN' LANGSTOeGER" <peter@langstoeger.at> wrote in message
> news:45ec25e7$1@news.langstoeger.at...
>> In article <45ec0521$1_1@glkas0286.greenlnk.net>, "chris"
>> <christian.rothwell@baesystems> writes:
>>>I have an alpha SBC 5/480 in a vme rack taking up slots 4 and 5, i keep
>>>getting random crashes on the sbc, an sbc in slots 1 and 2 is ok. The SBC
>>>takes a few attempts to boot correctly, i have to keep flicking the reset
>>>switch, sometime the LED display lights up all the segments, I have
>>>changed
>>>the SBC with a known working one and the fault still persists.
>>>
>>>When it does boot , it crashes intermittantly later on.
>>>
>>>ps ive had a vmetro in the subrack and there does not appear to be any
>>>bus
>>>errors
>>>
>>>Anyone help , before I go and change the whole vme subrack
>>
>> Try a better newsgroup (as VME bus <==> VMS opsys): comp.sys.dec
>> and good luck
>>
>> --
>> Peter "EPLAN" LANGSTOEGER
>> Network and OpenVMS system specialist
>> E-mail peter@langstoeger.at
>> A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist
>
>
------------------------------
Date: 5 Mar 2007 04:17:47 -0800
From: "dky" <dhruvakm@gmail.com>
Subject: Re: Can Samba be used to access Windows files on VMS
Message-ID: <1173097067.308647.107870@h3g2000cwc.googlegroups.com>
On Mar 1, 6:10 pm, sol gongola <s...@adldata.com> wrote:
> Gremlin wrote:
> > Hi All
>
> > So, probably a silly question, obviouslySambaon VMS makes the VMS files
> > available to Windows/*nix, but can it also be used to "interface" with
> > Windows files on a Windows server, so that they can be used within VMS?
>
> > Cheers
>
> You can't access files in a seamless fashion as you would going from
> windows to windows or windows to vms. There is an "smbclient"
> command that lets you connect to a windows box and lets you send
> and receive files using commands in an ftp like manner.
The SMBCLIENT tool on VMS is far from complete. Personally, I do not
suggest you use it for any serious work. On GNU/Linux, you have
"mount" that supports CIFS. That is the cleanest way of doing it. On
VMS, there is not equivalent of it and I do not see that happening in
the near future either.
-dky
------------------------------
Date: 5 Mar 2007 08:58:32 -0800
From: yyyc186@hughes.net
Subject: Re: DECforms
Message-ID: <1173113912.214602.121200@n33g2000cwc.googlegroups.com>
On Mar 1, 11:08 pm, Michael Kraemer <M.Krae...@gsi.de> wrote:
>
> > Warp 5 was awesome.
>
> I don't think such a beast ever existed.
> The last official IBM version was/is 4.5.
I ran Warp 5 for several years. It was available here in the USA at
least.
>
> It might be more stable than the M$ stuff,
> but can't compete with a Unix box.
> Every now and then I have to reboot due to TCP/IP and other troubles.
Warp 5 competed even with my SuSE Linux 10.2 box. In the two plus
years I ran it I only had to reboot when I installed a service pack or
had a power outage. It was the most stable PC based OS I had ever
had.
> A smallish company (Serenity System) still offers
> the eComStation desktop based on the
> dumped IBM product.
> (I'm currently writing these lines on a T30 running eCS)
Serenity wasn't exactly paid by MS. They thought they would make
money with support agreements, but they don't have any of the source
code, so the product will become increasingly unstable under them as
they try to hack new drivers into old object files.
>
> hmm, AFAIK Lattice was an independent compiler vendor,
> later bought by SAS Institute. They offered a (the best ?)
> C/C++ compiler for the Amiga until Commodore died (1994).
> They even delivered upgrades for the 68060 CPU long after that (1996).
Lattice was the original C compiler sold under private label by MS
with a non-compete agreement, but we see just how well MS honored that
non-compete agreement.
------------------------------
Date: 5 Mar 2007 09:46:16 -0800
From: "Rambo" <m_roguski@yahoo.com>
Subject: DNS- What I'm doing wrong?
Message-ID: <1173116774.930891.287190@c51g2000cwc.googlegroups.com>
So I'm playing with VMS now happily on AS600, yet I have a little
problem.
I successfully configured interface we0 for DHCP, I'm getting address,
my routing works, unfortunately I have problems with DNS:
TCPIP> show version
Compaq TCP/IP Services for OpenVMS Alpha Version V5.3
on a Digital AlphaStation 600 5/333 running OpenVMS V7.3-1
TCPIP> show name_service
BIND Resolver Parameters
Local domain: * Mismatch *
System
State: Started, Disabled
Transport: UDP
Domain:
Retry: 4
Timeout: 4
Servers: antyk.obta.uw.edu.pl
Path: 193.0.78.5, 212.87.0.37
Process
State: Disabled
Transport:
Domain:
Retry:
Timeout:
Servers:
Path:
When I'm configuringuring @sys$startup:tcpip$config
BIND RESOLVER Configuration
A BIND resolver has already been configured.
BIND Resolver Configuration
Transport: UDP
Domain: ID.UW.EDU.PL
Retry: 4
Timeout: 4
Servers: ns.icm.edu.pl, antyk.obta.uw.edu.pl
Path: No values defined
notice the differences?
Suffice to say: name resolution doesn't work.
What do I do wrong, and how to fix this?
Rambo
------------------------------
Date: 5 Mar 2007 09:02:43 -0800
From: dan.gillbjer@telia.com
Subject: Firmware-downgrade
Message-ID: <1173114163.467476.126420@t69g2000cwt.googlegroups.com>
Anyone out there who knows what firmware-level is needed to run
OpenVMS 6.2-1H3 instead of OpenVMS 7.2 on an AlphaStation 255 (and
where to find it) ?
// Dan
------------------------------
Date: 5 Mar 2007 11:18:47 -0600
From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)
Subject: Re: Firmware-downgrade
Message-ID: <atnDN8l39r9p@eisner.encompasserve.org>
In article <1173114163.467476.126420@t69g2000cwt.googlegroups.com>, dan.gillbjer@telia.com writes:
> Anyone out there who knows what firmware-level is needed to run
> OpenVMS 6.2-1H3 instead of OpenVMS 7.2 on an AlphaStation 255 (and
> where to find it) ?
> // Dan
There should be no need to downgrade the firmware.
------------------------------
Date: Mon, 5 Mar 2007 17:23:12 +0000 (UTC)
From: david20@alpha2.mdx.ac.uk
Subject: Re: Firmware-downgrade
Message-ID: <eshjm0$ral$1@south.jnrs.ja.net>
In article <1173114163.467476.126420@t69g2000cwt.googlegroups.com>, dan.gillbjer@telia.com writes:
>Anyone out there who knows what firmware-level is needed to run
>OpenVMS 6.2-1H3 instead of OpenVMS 7.2 on an AlphaStation 255 (and
>where to find it) ?
>// Dan
>
As far as I am aware it has always been safe to update the firmware to the
latest supported version whatever version of VMS you were running.
Hence if you are running VMS 7.2 then your current firmware version should also
support VMS 6.2-1H3.
Newer versions of the OS may require you to upgrade the firmware but older
versions don't as far as I am aware require you to downgrade the firmware.
David Webb
Security team leader
CCSS
Middlesex University
------------------------------
Date: 5 Mar 2007 18:32:55 +0100
From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOeGER)
Subject: Re: Firmware-downgrade
Message-ID: <45ec6257@news.langstoeger.at>
In article <1173114163.467476.126420@t69g2000cwt.googlegroups.com>, dan.gillbjer@telia.com writes:
>Anyone out there who knows what firmware-level is needed to run
>OpenVMS 6.2-1H3 instead of OpenVMS 7.2 on an AlphaStation 255 (and
>where to find it) ?
Does the latest (V7.0, many years old) really not work?
ftp://ftp.digital.com/pub/DEC/Alpha/firmware/archive/alpha200/
According to Table-5 in the firmware release notes it should...
ftp://ftp.digital.com/pub/DEC/Alpha/firmware/readmes/archive/doc/alpha200_v70_fw_relnote.pdf
Good luck
-EPLAN
--
Peter "EPLAN" LANGSTOEGER
Network and OpenVMS system specialist
E-mail peter@langstoeger.at
A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist
------------------------------
Date: 5 Mar 2007 09:50:05 -0800
From: dan.gillbjer@telia.com
Subject: Re: Firmware-downgrade
Message-ID: <1173117003.716141.318960@j27g2000cwj.googlegroups.com>
Yes, You are right, normally newer firmware can handle older OS'es.
During the late -99 I was travelling all over , upgrading Alpha's from
whatever OVMS-version to V7.2 (because of the Y2K-hype), and I
remember that this upgrade was a one-way road.
After firmware-upgrade it was no longer possible to reboot on the old
VMS-version (6.x).
In front of me (as I write ) I have an AS255 plus 3 disks.
One RZ26 loaded with 7.2
Two RZ28 with 6.2-1H3.
The AS255 happily boots on 7.2, but not fully on any 6.2-1H3 .
It comes to the point where it looks like the old non-graphic days on
a VT220-screen, where accounting info and other stuff where the last
output on the screen before it was possible to login.
But when I press return to login , nothing happends.
Ctrl/P sends me back to console-mode.
WINDOW_SYSTEM is set to 1 , and SYSTARTUP_P1 is blank.
(I have tried to min-boot the machine, without success).
>> show config
SRM Console : V7.0-9
PALcode : VMS PALcode V5.56-2
------------------------------
Date: Mon, 05 Mar 2007 02:20:06 -0500
From: Dave Froble <davef@tsoft-inc.com>
Subject: Re: FYI We now have qty of DS15 systems
Message-ID: <a56dnf3l7qEsWXbYnZ2dnUVZ_uHinZ2d@libcom.com>
David Turner, Island Computers US Corp wrote:
> For your info, we are now shipping brand new
> Alphaserver DS15 systems !
>
> Send us your required configuration !
>
> David
> Island Computers
> (dturner-at-islandco-dot-com)
>
>
>
You bought out HP's surpluss, huh?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
------------------------------
Date: Mon, 5 Mar 2007 07:10:50 -0500
From: "William Webb" <william.w.webb@gmail.com>
Subject: Re: FYI We now have qty of DS15 systems
Message-ID: <8660a3a10703050410s4e1c6830w7bd015350a7683c7@mail.gmail.com>
On 3/5/07, Dave Froble <davef@tsoft-inc.com> wrote:
> David Turner, Island Computers US Corp wrote:
> > For your info, we are now shipping brand new
> > Alphaserver DS15 systems !
> >
> > Send us your required configuration !
> >
> > David
> > Island Computers
> > (dturner-at-islandco-dot-com)
> >
> >
> >
>
> You bought out HP's surpluss, huh?
>
> --
> David Froble Tel: 724-529-0450
> Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
> DFE Ultralights, Inc.
> 170 Grimplin Road
> Vanderbilt, PA 15486
>
They aren't "surplus" yet.
Last order date for AlphaServer systems is 27-APR-2007.
WWWebb
------------------------------
Date: 5 Mar 2007 04:27:09 -0800
From: "dky" <dhruvakm@gmail.com>
Subject: Re: Going from Pathworks 7.3 to Samba
Message-ID: <1173097629.702841.158270@v33g2000cwv.googlegroups.com>
On Jan 24, 8:56 pm, "jbigboote" <jbigbo...@gmail.com> wrote:
> No backport to 7.3-2 I assume? And it doesn't appear 8.3 on Alpha is
> supported yet either? At the moment those are the only two VMS versions
> I am running. Guess I'll try it on 8.3 and see if it works.
Samba on VMS depends a lot on CRTL. Since some of the functionalities
added into CRTL for Samba cannot be back ported hence Samba itself
cannot be back ported. The main support is in the byte range locking
(cluster aware). If someone can implement a byte range locking code on
VMS with out using CRTL, technically it should be possible to back
port Samba.
-dky
~ My personal views only ~
------------------------------
Date: 5 Mar 2007 16:58:10 GMT
From: healyzh@aracnet.com
Subject: MediaWiki on OpenVMS?
Message-ID: <eshi72015rj@enews2.newsguy.com>
Has anyone here installed MediaWiki on OpenVMS? I'm trying to install it on
my system running WASD, and am running into problems with the installation
step where the database tables are created.
As I understand it, someone has done this, and I'm wondering how they made
it past this step. The error I'm getting is below.
Zane
Creating tables... using MySQL 4 table defs...Query "CREATE TABLE mage
( img_name varchar(255) binary NOT NULL default '', img_size int(8)
unsigned NOT NULL default '0', img_width int(5) NOT NULL default '0',
img_height int(5) NOT NULL default '0', img_metadata mediumblob NOT NULL,
img_bits int(3) NOT NULL default '0', img_media_type ENUM("UNKNOWN",
"BITMAP", "DRAWING", "AUDIO", "VIDEO", "MULTIMEDIA", "OFFICE", "TEXT",
"EXECUTABLE", "ARCHIVE") default NULL, img_major_mime ENUM("unknown",
"application", "audio", "image", "text", "video", "message", "model",
"multipart") NOT NULL default "unknown", img_minor_mime varchar(32) NOT NULL
default "unknown", img_description tinyblob NOT NULL default '', img_user
int(5) unsigned NOT NULL default '0', img_user_text varchar(255) binary NOT
NULL default '', img_timestamp char(14) binary NOT NULL default '', PRIMARY
KEY img_name (img_name), INDEX img_size (img_size), INDEX img_timestamp
(img_timestamp) ) TYPE=InnoDB " failed with error code "You have an error
in your SQL syntax; check the manual that corresponds to your MySQL server
version for the right syntax to use near 'UNKNOWN", "BITMAP", "DRAWING",
"AUDIO", "VIDEO", "MULTIMEDIA", " (localhost)".
------------------------------
Date: 5 Mar 2007 07:52:20 -0600
From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)
Subject: Re: Oracle moves to per-chip licencing
Message-ID: <It5j$ALqzpAm@eisner.encompasserve.org>
In article <45EB7F9A.2212DB79@spam.comcast.net>, David J Dachtera <djesys.no@spam.comcast.net> writes:
> Arne Vajhøj wrote:
>>
>> David J Dachtera wrote:
>> > Malcolm Dunnett wrote:
>> >> Standard Edition up to version 9.2 runs on VMS, but
>> >> Oracle is not going to release Standard Edition 10.x
>> >> on VMS. Apparently Oracle doesn't feel anyone wants
>> >> Standard Edition on VMS.
>> >
>> > I guess Oracle never heard of either Healthcare or high finance, both of which
>> > have been prime markets for Oracle.
>>
>> Would healthcare or financial sector use Standard Edition ? Or would
>> theu use Enterprise Edition ?
>
> Depends on the vendor, size of the installation, certification/requirements,
> etc.
If Oracle continues on its current path, they will be using
Enterprise Edition, or they'll move away from Oracle. More likely
the former.
------------------------------
Date: Mon, 05 Mar 2007 17:26:31 +1030
From: Mark Daniel <mark.daniel@vsm.com.au>
Subject: Re: Purveyor CGI <stdout> mailbox capacity [bit long winded]
Message-ID: <12unfug37qataca@corp.supernews.com>
Dave Froble wrote:
> bob@instantwhip.com wrote:
>
>> 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 ...
>>
>
> boob drives another person over the edge
I'd like to think I was well back from 'the edge' Dave :-)
I'd also like to think that was why the response was measured (IMO -
despite the occasional rhetorical flourish).
I just felt there were some things that needed stating out loud.
> Mark, don't waste your time getting excited. Just send him a quote. If
> he hires you, hey, take the cash. If he shuts up, no more problem.
>
> Surprising how problems are solved by sending a price quote. :-)
------------------------------
Date: 5 Mar 2007 06:29:26 -0800
From: bob@instantwhip.com
Subject: Re: Purveyor CGI <stdout> mailbox capacity [bit long winded]
Message-ID: <1173104966.749479.183890@64g2000cwx.googlegroups.com>
On Mar 5, 8:54 am, Mark Daniel <mark.dan...@vsm.com.au> wrote:
> b...@instantwhip.com wrote:
> > mark, here are quotes from the purveyor programmers manual ... seems
> > to
> > suggest using binary mode to avoid c problems.
> > Do you read anything here that is useful in solving the problem?
>
> Thankyou but I have consulted this documentation.
> It was part of the original 1.2 evaluation kit I use.
>
> The reference is to reading POSTed input via SYS$INPUT with the stream
> in binary mode. This disables the C-RTL record newline termination.
> What-you-read-is-what-you-get.
>
> The bit that breaks the whole shebang is on output:
>
> "... 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)."
>
> When the SYS$OUTPUT mailbox fills and is read as a record by Purveyor
> and subsequently sent on to the browser, extraneous carriage control
> is added to the stream as described above, and as described in my
> earlier posts. It doesn't do this to non-"text/.." responses. I
> cannot see, and nobody on c.o.v. has described, any way to disable
> this behaviour when required.
>
> This is not a C-language or C-RTL thing either. If you $QIO (using
> Dibol or any other environment) a single record of printable
> characters exceeding 1024 bytes in size in a "Content-type:
> text/plain" or "Content-type: text/html" response you find extraneous
> carriage-control.
>
>
>
> > Standard Input
>
> > When reading data, care must be taken to read it in binary mode. Data
> > is
> > delivered to the CGI program via an OpenVMS mailbox and the run-time
> > libraries for some languages, such as C, normally append a line
> > terminator
> > (LF in the case of C) after reading each record. To avoid this, open
> > the
> > input in binary mode. Purveyor delivers the data in 256-byte records
> > over
> > the mailbox (the last record may be less than 256 bytes). For an
> > example of
> > how to read data, see the MAILDEMO sample.
>
> > Be aware that SYS$INPUT and the QUERY_STRING environment variable
> > contain encoded characters (for example, an entered line feed is
> > represented
> > as %0A). You need to decode these characters before processing the
> > information.
>
> > Data Section
> > The data section contains the output (and HTML commands, if returning
> > an
> > HTML document) for the browser to display. The data section might
> > contain
> > readable diagnostic information for redirection and status responses.
>
> > 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).
>
> > Note that Purveyor always appends a line terminator (CR/LF) when
> > reading the
> > output header because the header is always text.
>
> > Because the OpenVMS mailbox is used to deliver the CGI program's
> > output, the
> > way output is written can significantly affect your application's
> > performance. It is best to write large amounts of data at once, rather
> > than
> > small amounts.
>
> > For example, the following program might be used to download a file
> > via a
> > CGI program:
>
> > Figure 2 Example Download CGI Program I
>
> > -----------------------------------------------------------------------=
----=AD-----
>
> > #include <stat.h>
> > #include <stdio.h>
> > void send_error(char *msg)
> > {
> > fprintf(stdout,"Content-type: text/html\n");
> > fprintf(stdout,"\n");
> > fprintf(stdout,"<HTML>\n");
> > fprintf(stdout,"<HEADER><TITLE>Download Error</TITLE></HEADER>\n");
> > fprintf(stdout,"<BODY>\n");
> > fprintf(stdout,"<H2>Your request could not be completed.</H2><P>
> > \n");
> > fprintf(stdout,"<H1>%s</H1>\n",msg);
> > fprintf(stdout,"</BODY>\n");
> > fprintf(stdout,"</HTML>\n");
> > }
> > void do_download(char *file)
> > {
> > stat_t statbuf;
> > int n_bytes;
> > int buf[1024];
> > FILE* df;
> > if (stat(file,&statbuf) <0) {
> > send_error("Unable to find download file!");
> > return;
> > }
> > if (!(df=3Dfopen(file, "rb","mbc=3D32","rop=3Drah"))) {
> > send_error("Unable to access download file!");
> > return;
> > }
> > fprintf(stdout,"Content-type: application/octet-stream\n");
> > fprint(stdout,"Content-disposition: filename=3D\"%s\"\n",file);
> > fprint(stdout,"Content-length: %d\n\n",statbuf.st_size);
> > freopen("WWW_OUT:","wb",stdout,"mbc=3D32");
> > while ((n_bytes=3Dfread(buf,1,sizeof(buf),df)) > 0)
> > if (fwrite(buf,1,n)bytes,stdout) !=3D n_bytes) break;
> > fclose(df);
> > }
> > main(int argc, char *argv[])
> > {
> > if (argc !=3D 2) send_error("Invalid request");
> > else do_download(argv[1]);
> > }
> > -----------------------------------------------------------------------=
----=AD-----
>
> > However, do not use the code in Example I; performance would be
> > extremely
> > poor because of the fwrite writing a single character at a time (since
> > mailbox devices are record oriented, C does a single QIO operation for
> > each
> > character). By making slight modifications to the C code, you can
> > improve
> > performance. A better do_download routine is in Figure 3 Example
> > Download
> > CGI Program II.
>
> > Figure 3 Example Download CGI Program II
>
> > -----------------------------------------------------------------------=
----=AD-----
>
> > void do_download(char *file)
> > {
> > stat_t statbuf;
> > char *download_file;
> > int n_bytes;
> > int buf[1024];
> > FILE* df;
> > if (stat(file,&statbuf) <0){
> > send_error("Unable to find download file!");
> > return;
> > }
> > if (!(df=3Dfopen(file, "rb","mbc=3D32","rop=3Drah"))) {
> > send_error("Unable to access download file!");
> > return;
> > }
> > fprintf(stdout,"Content-type: application/octet-stream\n");
> > fprintf(stdout,"Content-disposition: filename=3D\"%s\"\n",file);
> > fprintf(stdout,"Content-length: %d\n\n",statbuf.st_size);
> > freopen("WWW_OUT:","wb",stdout,"mbc=3D32");
> > while ((n_bytes=3Dfread(buf,1,sizeof(buf),df)) >0)
> > if (fwrite(buf,n_bytes,1,stdout) !=3D 1) break;
> > fclose(df);
> > }
> > -----------------------------------------------------------------------=
----=AD-----
>
> > The only change was the fwrite clause (shown in bold) By writing
> > n_bytes
> > (instead of 1) bytes at a time, performance improves dramatically.
> > With this
> > change, the time to download a 400-KB file changed from about 120
> > seconds to
> > 1 second when run on the same machine. Note also that stdout is opened
> > as a
> > binary file. This is very important to remember when sending binary
> > data.- Hide quoted text -
>
> - Show quoted text -
you reviewed the Purveyor code Mark several years ago ...
do you remeber seeing anything in there that could be tweaked
to solve the problem?
------------------------------
Date: Tue, 06 Mar 2007 00:57:35 +1030
From: Mark Daniel <mark.daniel@vsm.com.au>
Subject: Re: Purveyor CGI <stdout> mailbox capacity [bit long winded]
Message-ID: <12uoac91c2n5nd8@corp.supernews.com>
bob@instantwhip.com wrote:
> On Mar 5, 8:54 am, Mark Daniel <mark.dan...@vsm.com.au> wrote:
>
>>b...@instantwhip.com wrote:
>>
>>>mark, here are quotes from the purveyor programmers manual ... seems
>>>to
>>>suggest using binary mode to avoid c problems.
>>>Do you read anything here that is useful in solving the problem?
>>
>>Thankyou but I have consulted this documentation.
>>It was part of the original 1.2 evaluation kit I use.
>>
>>The reference is to reading POSTed input via SYS$INPUT with the stream
>>in binary mode. This disables the C-RTL record newline termination.
>>What-you-read-is-what-you-get.
>>
>>The bit that breaks the whole shebang is on output:
>>
>> "... 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)."
>>
>>When the SYS$OUTPUT mailbox fills and is read as a record by Purveyor
>>and subsequently sent on to the browser, extraneous carriage control
>>is added to the stream as described above, and as described in my
>>earlier posts. It doesn't do this to non-"text/.." responses. I
>>cannot see, and nobody on c.o.v. has described, any way to disable
>>this behaviour when required.
>>
>>This is not a C-language or C-RTL thing either. If you $QIO (using
>>Dibol or any other environment) a single record of printable
>>characters exceeding 1024 bytes in size in a "Content-type:
>>text/plain" or "Content-type: text/html" response you find extraneous
>>carriage-control.
>>
>>
>>
>>
>>>Standard Input
>>
>>>When reading data, care must be taken to read it in binary mode. Data
>>>is
>>>delivered to the CGI program via an OpenVMS mailbox and the run-time
>>>libraries for some languages, such as C, normally append a line
>>>terminator
>>>(LF in the case of C) after reading each record. To avoid this, open
>>>the
>>>input in binary mode. Purveyor delivers the data in 256-byte records
>>>over
>>>the mailbox (the last record may be less than 256 bytes). For an
>>>example of
>>>how to read data, see the MAILDEMO sample.
>>
>>> Be aware that SYS$INPUT and the QUERY_STRING environment variable
>>>contain encoded characters (for example, an entered line feed is
>>>represented
>>>as %0A). You need to decode these characters before processing the
>>>information.
>>
>>>Data Section
>>>The data section contains the output (and HTML commands, if returning
>>>an
>>>HTML document) for the browser to display. The data section might
>>>contain
>>>readable diagnostic information for redirection and status responses.
>>
>>>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).
>>
>>>Note that Purveyor always appends a line terminator (CR/LF) when
>>>reading the
>>>output header because the header is always text.
>>
>>>Because the OpenVMS mailbox is used to deliver the CGI program's
>>>output, the
>>>way output is written can significantly affect your application's
>>>performance. It is best to write large amounts of data at once, rather
>>>than
>>>small amounts.
>>
>>>For example, the following program might be used to download a file
>>>via a
>>>CGI program:
>>
>>>Figure 2 Example Download CGI Program I
>>
>>>--------------------------------------------------------------------------------
>>
>>>#include <stat.h>
>>>#include <stdio.h>
>>>void send_error(char *msg)
>>>{
>>> fprintf(stdout,"Content-type: text/html\n");
>>> fprintf(stdout,"\n");
>>> fprintf(stdout,"<HTML>\n");
>>> fprintf(stdout,"<HEADER><TITLE>Download Error</TITLE></HEADER>\n");
>>> fprintf(stdout,"<BODY>\n");
>>> fprintf(stdout,"<H2>Your request could not be completed.</H2><P>
>>>\n");
>>> fprintf(stdout,"<H1>%s</H1>\n",msg);
>>> fprintf(stdout,"</BODY>\n");
>>> fprintf(stdout,"</HTML>\n");
>>>}
>>>void do_download(char *file)
>>>{
>>> stat_t statbuf;
>>> int n_bytes;
>>> int buf[1024];
>>> FILE* df;
>>> if (stat(file,&statbuf) <0) {
>>> send_error("Unable to find download file!");
>>> return;
>>> }
>>> if (!(df=fopen(file, "rb","mbc=32","rop=rah"))) {
>>> send_error("Unable to access download file!");
>>> return;
>>> }
>>> fprintf(stdout,"Content-type: application/octet-stream\n");
>>> fprint(stdout,"Content-disposition: filename=\"%s\"\n",file);
>>> fprint(stdout,"Content-length: %d\n\n",statbuf.st_size);
>>> freopen("WWW_OUT:","wb",stdout,"mbc=32");
>>> while ((n_bytes=fread(buf,1,sizeof(buf),df)) > 0)
>>> if (fwrite(buf,1,n)bytes,stdout) != n_bytes) break;
>>> fclose(df);
>>>}
>>>main(int argc, char *argv[])
>>>{
>>> if (argc != 2) send_error("Invalid request");
>>> else do_download(argv[1]);
>>>}
>>>--------------------------------------------------------------------------------
>>
>>>However, do not use the code in Example I; performance would be
>>>extremely
>>>poor because of the fwrite writing a single character at a time (since
>>>mailbox devices are record oriented, C does a single QIO operation for
>>>each
>>>character). By making slight modifications to the C code, you can
>>>improve
>>>performance. A better do_download routine is in Figure 3 Example
>>>Download
>>>CGI Program II.
>>
>>>Figure 3 Example Download CGI Program II
>>
>>>--------------------------------------------------------------------------------
>>
>>>void do_download(char *file)
>>>{
>>> stat_t statbuf;
>>> char *download_file;
>>> int n_bytes;
>>> int buf[1024];
>>> FILE* df;
>>> if (stat(file,&statbuf) <0){
>>> send_error("Unable to find download file!");
>>> return;
>>> }
>>> if (!(df=fopen(file, "rb","mbc=32","rop=rah"))) {
>>> send_error("Unable to access download file!");
>>> return;
>>> }
>>> fprintf(stdout,"Content-type: application/octet-stream\n");
>>> fprintf(stdout,"Content-disposition: filename=\"%s\"\n",file);
>>> fprintf(stdout,"Content-length: %d\n\n",statbuf.st_size);
>>> freopen("WWW_OUT:","wb",stdout,"mbc=32");
>>> while ((n_bytes=fread(buf,1,sizeof(buf),df)) >0)
>>> if (fwrite(buf,n_bytes,1,stdout) != 1) break;
>>> fclose(df);
>>>}
>>>--------------------------------------------------------------------------------
>>
>>>The only change was the fwrite clause (shown in bold) By writing
>>>n_bytes
>>>(instead of 1) bytes at a time, performance improves dramatically.
>>>With this
>>>change, the time to download a 400-KB file changed from about 120
>>>seconds to
>>>1 second when run on the same machine. Note also that stdout is opened
>>>as a
>>>binary file. This is very important to remember when sending binary
>>>data.- Hide quoted text -
>>
>>- Show quoted text -
>
>
> so you are saying the developers from Process who wrote purveyor
> are idiots?
I don't remember casting any such aspersion.
It is difficult in the early stages of any development to anticipate
every possibe way in which a technology or aopplication might be used a
decade down the track. Purveyors continued development was arrested
very early (well over 8 years ago and just a handful of years after its
introduction). A lot has happened since then. And a lot of refinement
has occured in applications that have continued being supported during
that period.
You demonstrate to me this extraneous carriage-control is not added
under the circumstances described or tell me how to disable this
behaviour then.
And whether or not it can be argued that PSC *wrote* Purveyor or not is
another issue. I understand they licensed/purchased the codebase from a
third party then tailored and further developed that. IMO there are
more Windows(NT)-isms in Purveyor than VMS-isms. And remember, I've
seen the source code, Bob! Oh, and it's written using that 'C garbage' too.
------------------------------
Date: 5 Mar 2007 04:06:33 -0800
From: "dky" <dhruvakm@gmail.com>
Subject: Re: SAMBA on OpenVMS with OS X client
Message-ID: <1173096393.861320.78610@h3g2000cwc.googlegroups.com>
Hi,
Samba from HP in it's current released state does not support ODS-2
disks. This support is added in the yet/soon to be released based on
Samba 3.0.24.
IMHO, the error the OP is facing might be due to the temporary file
created by TextEdit (and MS WORD). The temporary files will have some
non-alphabetic chars which are not supported on ODS2 and needs extra
support from Samba to make that happen which is implemented and should
be part of upcoming release.
-dhruva
!My personal views only!
------------------------------
Date: 5 Mar 2007 04:13:55 -0800
From: "dky" <dhruvakm@gmail.com>
Subject: Re: SWAT using Samba v3 on VMS8.2
Message-ID: <1173096835.192402.101990@p10g2000cwp.googlegroups.com>
Hi,
From what I know (till I was last part of the team), SWAT was not
ported to VMS. I and the team tried and found some problems. Since
there were more important areas to focus (file format handling, byte
range locking, ACL support and a whole lot), we consciously lowered
the priority of SWAT porting.
The porting seems very straight forward: Redirect the stdin and
stdout to a socket and make it talk to the port on which the SWAT
listener was configured. We ended up in problems like getting back the
data we wrote to the socket when we did a subsequent read. It is a
small tweak or a fix somewhere that we could not find.
I am sure this can be fixed once there is enough bandwidth in the
team back in HP.
PS:
Can someone provide a shell account on an IA64 box running VMS 8.3, I
can continue working on Samba. I am no longer with HP and hence no
access to a VMS box.
with best regards,
dhruva
~ My personal views only ~
------------------------------
Date: 5 Mar 2007 07:57:22 -0600
From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)
Subject: Re: SYS$INPUT problem (I guess) running Java 1.42 servlet
Message-ID: <wvJ645AJ6cnv@eisner.encompasserve.org>
In article <pIidnZtg54FDsXTYnZ2dnUVZ_r-onZ2d@cavtel.net>, Stephen Eickhoff <operagost@og.com> writes:
> Warning: I'm not a Java programmer.
>
> I have Java 1.42 running a servlet that is designed with an interactive shell.
> It will run only in the following environments:
>
> 1. Interactively (java -classpath ScorchServer.jar:Scorch.jar
> ScorchServer.ScorchServer)
> 2. In a DCL command file with $ DEFINE/USER SYS$INPUT SYS$COMMAND
> before the above command.
>
> If I try to run it detached, spawned, or in a batch, the log will show that
> the servlet's prompt is scrolling endlessly (and consuming near 100% CPU) as
> if someone was holding down the ENTER key. I suppose it may be checking for
> user input, finding an EOF, and rewriting the prompt over and over. Is there
> a way I can keep it at bay without rewriting the code?
Just where do you expect the input device to map when you run the
process non-interactively?
You may have to create a DECterm with no process and then write a
.com file for the interactive process that maps the input (and
output) devices before starting the Java app.
Or you might fix the Java code to do something more reasonable when
faced with an empty input file. But then what usefull thing would
it do?
------------------------------
Date: 5 Mar 2007 15:22:38 GMT
From: bill@cs.uofs.edu (Bill Gunshannon)
Subject: VAX 7000-640
Message-ID: <552qtuF235ergU1@mid.individual.net>
The time has finally come. I have to start clearing space here at the
University. That manes stuff had got to go, one way or the other.
That being said, I have three VAX 7000-640's free to a good home (or
actually, any home!!) All you have to do is come and get them. Don't
have to take all three, I'll break up the set. :-) I would really
like to see them stay out of the landfill, but they do have to go.
Anybody interested? Any museum want to stage a rescue?
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
------------------------------
Date: 5 Mar 2007 07:39:34 -0800
From: "Tore Sinding Bekkedal" <toresbe@gmail.com>
Subject: Re: VAX 7000-640
Message-ID: <1173109174.803245.45030@v33g2000cwv.googlegroups.com>
On Mar 5, 4:22 pm, b...@cs.uofs.edu (Bill Gunshannon) wrote:
> The time has finally come. I have to start clearing space here at the
> University. That manes stuff had got to go, one way or the other.
>
> That being said, I have three VAX 7000-640's free to a good home (or
> actually, any home!!) All you have to do is come and get them. Don't
> have to take all three, I'll break up the set. :-) I would really
> like to see them stay out of the landfill, but they do have to go.
>
> Anybody interested? Any museum want to stage a rescue?
It's great to see that you're trying to keep it from dumpster death.
If nobody here replies, you might want to try Computer History Museum,
or failing that, the http://classiccmp.org mailing list. I'm in
Norway, otherwise I'd take it in a heartbeat. :)
-Tore :)
------------------------------
Date: 5 Mar 2007 04:21:16 -0800
From: "dky" <dhruvakm@gmail.com>
Subject: Re: VMS Client to Windows Storage Server x64 R2
Message-ID: <1173097276.054597.305960@q40g2000cwq.googlegroups.com>
On Mar 1, 7:49 pm, "Michael D. Ober" <obermd.@.alum.mit.edu.nospam>
wrote:
> I need the ability for our VMS server to mount drives from shares on a
> Windows Storage Server x64 R2. Basically, VMS will be a client to network
> shares.
>
> SYSTEM>tcpip show ver
>
> HP TCP/IP Services for OpenVMS Alpha Version V5.6
> on an AlphaServer 1200 5/533 4MB running OpenVMS V8.3
>
> Does anyone know if Pathworks Advanced Server, JYCSamba2.2.8, HPSamba
> 3.x, or native VMS NFS client can do this and if so, how?
If it is ALPHA, I would bet my production system on Advanced Server on
VMS (Pathworks). Samba is still an alpha not architecture) product and
needs time to mature.
If it an IA64 box, you will have to wait till a new release comes out
(many bugs fixed with lot of new features)
-dky
------------------------------
Date: 5 Mar 2007 13:02:27 GMT
From: bill@cs.uofs.edu (Bill Gunshannon)
Subject: Re: Wanted: MicroVAX I / VAXstation I owners
Message-ID: <552in3F21a4ciU2@mid.individual.net>
In article <1oumu2hdbd6kd8gkhrmebukemdtmplni6a@4ax.com>,
no.spam@no.uce.bellatlantic.net writes:
> On 4 Mar 2007 01:14:03 GMT, bill@cs.uofs.edu (Bill Gunshannon) wrote:
>
>>In article <1172942091.825878.220890@h3g2000cwc.googlegroups.com>,
>> sean@obanion.us writes:
>>> On Mar 2, 3:04 am, "vaxorcist" <vaxorc...@googlemail.com> wrote:
>>>> Who else has got (and eventually runs) the worlds slowest VAX ever ???
>>>>
>>>> I'm going to build one from parts and will probably need some help.
>>>> All OSes welcome!
>>>>
>>>> Regards
>>>>
>>>> Ulli
>>>
>>> Wan't the VAX-11/730 slower? I think it was about .3 VUP...
>>>
>>> When I installed bsd 4.1 (circa 1985, it was new!), the installation
>>> notes said the the 730 was not fast enough to be usefull.
>>
>>A MicroVAX II running NetBSD is not fast enough to be useful but that
>>doesn't seem to stop people from trying. :-)
>>
>>bill
>
>
> No idea why netbsd its so slow as I have a uVAX-II running Ultrix 4.2
> and it's pretty useable.
Because bloat crept in and their development doesn't take into account
the fact that some machines can not have their memory constantly (and
seemingly infinitely) increased. This was the reason I went to HP to
see about any chance of getting a hobbyist program for Ultrix. Their
answer was, "Run NetBSD!" Shows how little HP even understands the
value of the stuff they acquired from DEC via Compaq.
> Doesnt hurt to have as much ram as well fit
> and multiple RD54s or a SCSI disk.
The maximum memory for a MicroVAX-II is insufficient for doing anythng
serious using NetBSD. I have, for the most part, retired my MicroVAX.
Aboutt he smallest VAX I run now is the VS3100 and somethings are pain-
fully slow even on that.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
------------------------------
Date: 5 Mar 2007 07:34:33 -0600
From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)
Subject: Re: Wanted: MicroVAX I / VAXstation I owners
Message-ID: <abxoLS5RQE6M@eisner.encompasserve.org>
In article <escs3d$149$1@rumours.uwaterloo.ca>, dfevans@bcr10.uwaterloo.ca (David Evans) writes:
>
> I see your uV 2000s and raise you a Pro 350 running 2.9BSD. Now *that*
> was painful; you didn't make many mistakes, given how long it took to load
> vi.
>
Pro 350 running P/OS:
Load game, get cup of coffee.
Enter move, boot VMScluster.
Enter second move, reconfigure VMScluster.
Enter third move, read 4 usenet groups on VMScluster.
Enter forth move, read remaining groups.
Enter fifth move, get a beer.
...
Its not fast, but then it was meant for word processing, not gaming.
For word processing it has no problem keeping up with my keystrokes.
------------------------------
Date: Mon, 05 Mar 2007 16:36:37 GMT
From: no.spam@no.uce.bellatlantic.net
Subject: Re: Wanted: MicroVAX I / VAXstation I owners
Message-ID: <ijhou2lte6na7v7b0bino37afa04c9u4di@4ax.com>
On 5 Mar 2007 13:02:27 GMT, bill@cs.uofs.edu (Bill Gunshannon) wrote:
>In article <1oumu2hdbd6kd8gkhrmebukemdtmplni6a@4ax.com>,
> no.spam@no.uce.bellatlantic.net writes:
>> On 4 Mar 2007 01:14:03 GMT, bill@cs.uofs.edu (Bill Gunshannon) wrote:
>>
>>>In article <1172942091.825878.220890@h3g2000cwc.googlegroups.com>,
>>> sean@obanion.us writes:
>>>> On Mar 2, 3:04 am, "vaxorcist" <vaxorc...@googlemail.com> wrote:
>>>>> Who else has got (and eventually runs) the worlds slowest VAX ever ???
>>>>>
>>>>> I'm going to build one from parts and will probably need some help.
>>>>> All OSes welcome!
>>>>>
>>>>> Regards
>>>>>
>>>>> Ulli
>>>>
>>>> Wan't the VAX-11/730 slower? I think it was about .3 VUP...
>>>>
>>>> When I installed bsd 4.1 (circa 1985, it was new!), the installation
>>>> notes said the the 730 was not fast enough to be usefull.
>>>
>>>A MicroVAX II running NetBSD is not fast enough to be useful but that
>>>doesn't seem to stop people from trying. :-)
>>>
>>>bill
>>
>>
>> No idea why netbsd its so slow as I have a uVAX-II running Ultrix 4.2
>> and it's pretty useable.
>
>Because bloat crept in and their development doesn't take into account
>the fact that some machines can not have their memory constantly (and
>seemingly infinitely) increased. This was the reason I went to HP to
>see about any chance of getting a hobbyist program for Ultrix. Their
>answer was, "Run NetBSD!" Shows how little HP even understands the
>value of the stuff they acquired from DEC via Compaq.
>
>> Doesnt hurt to have as much ram as well fit
>> and multiple RD54s or a SCSI disk.
>
>The maximum memory for a MicroVAX-II is insufficient for doing anythng
>serious using NetBSD. I have, for the most part, retired my MicroVAX.
>Aboutt he smallest VAX I run now is the VS3100 and somethings are pain-
>fully slow even on that.
>
>bill
I run VMS on them for that reason, it's a better fit and far less pain
to install and use effectively. I have 12 vaxen that includes 2
uVAXIIs, 3 uVAX2000s and 5 uVAX3100 (m20s) and two 3100M76s
all loaded with ram and disks. Running older VMS such as 5.44 hand
tuned (not autogen) they are decent for their age.
Allison
------------------------------
End of INFO-VAX 2007.128
************************