This is G o o g l e's cache of http://www.lp.se/ftp/mailinglists/VMS-MOSAIC.TXT.
G o o g l e's cache is the snapshot that we took of the page as we crawled the web.
The page may have changed since that time. Click here for the current page without highlighting.
Google is not affiliated with the authors of this page nor responsible for its content. |
| These search terms have been highlighted: | ftp |
|
|
Return-path: <jonathan@tvax2.cdrh.fda.gov>
Date: Tue, 07 Jan 1997 13:58:56 -0500
From: jonathan@tvax2.cdrh.fda.gov (Jonathan S. Boswell, Ph.D.)
Subject: Mosaic V2.7b6?
To: vms-mosaic@hhs.dk
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Here are two questions.
1) Is this list moribund, or what?
2) What happened to the Mosaic V2.7b6 distribution that people
were talking about last November? I can't seem to locate it
anywhere at NCSA, as of yesterday.
Thanks in advance.
Jonathan Boswell
FDA/CDRH
Return-path: <JLAURET@sbchm3.chem.sunysb.edu>
Date: Tue, 07 Jan 1997 14:11:25 -0500 (EST)
From: Jerome LAURET <JLAURET@nucax1.chem.sunysb.edu>
Subject: Re : Mosaic V2.7b6?
To: vms-mosaic@hhs.dk
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
> From: SMTP%"jonathan@tvax2.cdrh.fda.gov"
> To: JLAURET
> CC:
> Subj: Mosaic V2.7b6?
>
>
> Here are two questions.
>
> 1) Is this list moribund, or what?
>
> 2) What happened to the Mosaic V2.7b6 distribution that people
> were talking about last November? I can't seem to locate it
> anywhere at NCSA, as of yesterday.
>
> Thanks in advance.
>
> Jonathan Boswell
> FDA/CDRH
If you have any aswer about the 2.7b6, let me know because I was
looking for it a week ago and could not locate it anywhere ...
Jerome LAURET S.U.N.Y. @ Stony Brook
,,,,, Dept. of Chemistry
( o o ) Stony Brook NY 11794-3400
---m---U---m---------------------------------------------
E-mail: jlauret@sbchem.chem.sunysb.edu
URL : http://nucwww.chem.sunysb.edu/people/jlauret.html
Return-path: <zinser@eur.sas.com>
Date: Wed, 08 Jan 1997 09:01:04 +0000 (MET-1MET)
From: "Martin P.J. Zinser, SAS Europe" <zinser@eur.sas.com>
Subject: Future of Mosaic/VMS browser?
To: vms-mosaic@hhs.dk
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Hello!
I fished the following out of comp.infosystems.www.browser.x
Paul Bleisch (pbleisch@uiuc.edu) wrote:
:
: I also think it would be great if the 'net community developed a free browser.
: Not sure about basing it on Mosaic either. Mail Scott and ask him about
: using the alpha code. But if I were you, I would start fresh and use C++.
:
: And just think, you could have quality control in the hands of root@tailor.org
: (or whatever his address is now).
:
I would be happy to lead (at least in the begining) an effort to develop a net
community browser. It would definitely be new code and in C++.
I am sure there would be no problem with providing mail list support and space
for distribution at NCSA. If there is sufficient interest (so far no one has
contacted me) in doing this, I will start putting out feelers here.
Scott
--
Scott W. Powers | '*Nothing* the government does surprises
NCSA-SDD Vis Group Lead | me.' "That's a very Russian attitude. I
http://shire.ncsa.uiuc.edu/ | commend you." -- Ivanova and Garibaldi
Looks like Mosaic will no longer supported by NCSA at all. We
should discuss how to proceede from here.
Greetings, Martin
* Martin P.J. Zinser Email: eurmpz@eur.sas.com
* SAS Institute Europe
* Tech Support If you are interested in VMS try
* Postfach 105340 http://axp616.gsi.de:8080/www/vms/sw.html
* D-69043 Heidelberg or (if you are confined in the SAS internal net)
* Phone: 49 +6221 416222 http://gringo.eur.sas.com:8080/www/vms/sw.html
Return-path: <vance@toyvax.Tucson.AZ.US>
Date: Wed, 08 Jan 1997 15:52:50 -0700 (MST)
From: How do you turn this thing off?! <vance@toyvax.Tucson.AZ.US>
Subject: RE: Future of Mosaic/VMS browser?
To: vms-mosaic@hhs.dk
Cc: vance@toyvax.Tucson.AZ.US
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Martin P.J. Zinser wrote:
>Looks like Mosaic will no longer supported by NCSA at all. We
>should discuss how to proceede from here.
Unfortunately, that looks to be true. However, what what I've
read, it looks like 2.7b6 and then 2.7 final will be released soon.
In fact 2.7b6 should be out any day now. But that looks to be it
as far as NCSA is concerned.
See: http://shire.ncsa.uiuc.edu/release/time.html
--
Vance Haemmerle Internet vance%toyvax@Arizona.EDU
Tucson, AZ vance@toyvax.Tucson.AZ.US
http://condor.lpl.arizona.edu/~vance/ NSI-SPAN/HEPNET 47540::TOYVAX::VANCE
Return-path: <JLAURET@sbchm3.chem.sunysb.edu>
Date: Wed, 08 Jan 1997 18:09:39 -0500 (EST)
From: Jerome LAURET <JLAURET@nucax1.chem.sunysb.edu>
Subject: Reporting bugs in 2.7b5
To: vms-mosaic@hhs.dk
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Well, before it's too late and he 2.7b6 gets released, may this bug can
be fixed :
I]
The bottom of this Email is a crash a user did produced (I could
reproduced) doing the following :
1) Open the Hotlist
2) Create a new list/path to store adresses in (ex: Test)
2) Do a copy on an old existing list (ex: Old)
3) Click on Insert inside the new one
4) Double click on -> Test
Double click on -> Old
and BANG ! (see below)
II]
Second problem : I open the 2.7-5on an Xterminal. The font
-adobe-times-bold-r-normal-*-24-*-*-*-*-*-iso8859-1 is not available on the
Xserver running on the NCD Xterminal. So I use in MOSAIC.DAT
Mosaic*Header1Font: -adobe-times-bold-r-normal-*-25-*-*-*-*-*-iso8859-1
But when I open mosaic, I get the message :
Load Font Error
Could not open font '-adobe-times-bold-r-normal-*-24-*-*-*-*-*-*-*'.
Using fixed instead.
and the Header1 are not displayed as it should (using the fixed font)
regardless of what I have in the resource file.
BTW: I am using DEC C V5.3-006 on OpenVMS Alpha V6.1 .
----------------------------------------------------------------------------
[...]
CC:
Subj: mosaic
assert error: expression = set_state == XmxSet || set_state == XmxUnset, in file STELL_USER1:[JLA
URET.APPS_DEV.MOSAIC.LIBXMX]XMX.C;1 at line 453
Improperly handled condition, image exit forced.
Signal arguments: Number = 00000003
Name = 00000434
80594C4C
0000001B
Register dump:
R0 = 0000000000000001 R1 = 0000000000000001 R2 = 000000007FE6CBF8
R3 = FFFFFFFFFFFFFFFE R4 = 0000000000000434 R5 = 0000000000000000
R6 = 0000000000000000 R7 = 0000000000B065F8 R8 = 000000000000001A
R9 = 0000000000000000 R10 = 0000000000000001 R11 = 0000000000000002
R12 = 000000000000001E R13 = 000000000000000B R14 = 0000000000000000
R15 = 0000000000AA8B48 R16 = 0000000000000434 R17 = 0000000000000000
R18 = 0000000000000000 R19 = FFFFFFFFFFFFFFFF R20 = 0000000000000000
R21 = 0000000000000000 R22 = 0000000000000000 R23 = FFFFFFFFFFFFFF79
R24 = 0000000000000040 R25 = 0000000000000001 R26 = FFFFFFFF80594C4C
R27 = 000000007FB623B0 R28 = 300000000000001B R29 = 000000007F949070
SP = 000000007F949070 PC = FFFFFFFF80594C4C PS = 300000000000001B
Jerome LAURET S.U.N.Y. @ Stony Brook
,,,,, Dept. of Chemistry
( o o ) Stony Brook NY 11794-3400
---m---U---m---------------------------------------------
E-mail: jlauret@sbchem.chem.sunysb.edu
URL : http://nucwww.chem.sunysb.edu/people/jlauret.html
Return-path: <COOK@wvnvaxa.wvnet.edu>
Date: Wed, 08 Jan 1997 03:45:37 -0500 (EST)
From: George Cook <COOK@wvnvaxa.wvnet.edu>
Subject: Re: Future of Mosaic/VMS browser?
To: "Martin P.J. Zinser, SAS Europe" <zinser@eur.sas.com>
Cc: vms-mosaic@hhs.dk, COOK@wvnvaxa.wvnet.edu
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
> Looks like Mosaic will no longer supported by NCSA at all. We
> should discuss how to proceede from here.
Although NCSA still plans to release 2.7b6 any day now (and probably a
final 2.7 at a later point), from what I have been able to make out
from reading comp.infosystems.www.browsers.x, it appears that NCSA is
dropping all active support for X Mosaic.
Several options how to proceed:
1. This group can try to continue to support the final release of X
Mosaic on VMS. It will need minor work to keep it running on new
releases of Motif, VMS, etc. It might also be possible to hack in
the table support, etc. from mMosaic.
2. Look at adding VMS support to mMosaic. Could be a lot of work
since few of the VMS patches made it into 2.7b4 on which mMosaic
is based, plus the mMosaic developer would have to be interested
in supporting VMS unless we want to return to keeping the VMS
modifications separate.
3. Look at porting some other browser like Chimera to VMS.
4. Become active in some yet to be formed "net community" effort to
create a "net community" browser. This could possibly be based
on the latest Mosaic 2.8 Alpha code if NCSA decides to release
the code from copyright (or whatever is legally required).
Most of these options would require significant volunteer programming
effort by one or more members of the VMS community.
To those who ask why not just use Netscape: well, that would leave
the VMS community trapped with a browser having only the functionality
that Netscape/Digital manage to port to VMS. Given Digital's erratic/
irrational behavior in the last few years, I try not to depend too much
on what they say they intend to do. There is also a significant need
for a browser which comes with source code; Netscape definitely does
not meet that need.
George
Return-path: <zinser@eur.sas.com>
Date: Thu, 09 Jan 1997 08:50:13 +0000 (MET-1MET)
From: "Martin P.J. Zinser, SAS Europe" <zinser@eur.sas.com>
Subject: Re: Future of Mosaic/VMS browser?
To: COOK@wvnvaxa.wvnet.edu
Cc: vms-mosaic@hhs.dk
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Hello!
George Cook <COOK@wvnvaxa.wvnet.edu> writes:
>Several options how to proceed:
>
>1. This group can try to continue to support the final release of X
>Mosaic on VMS. It will need minor work to keep it running on new
>releases of Motif, VMS, etc. It might also be possible to hack in
>the table support, etc. from mMosaic.
>
I think it is obvious that we should do this at least for
a start. As I pointed out already before I definitly want
to have my users something halfways stable and functional
(besides of tables ;-( before embarking to completely new
project.
>2. Look at adding VMS support to mMosaic. Could be a lot of work
>since few of the VMS patches made it into 2.7b4 on which mMosaic
>is based, plus the mMosaic developer would have to be interested
>in supporting VMS unless we want to return to keeping the VMS
>modifications separate.
I'd only recommend that in case mMosaic becomes something
like a 'net community' effort.
>
>3. Look at porting some other browser like Chimera to VMS.
Where to get this (for Unix I guess)?
>
>4. Become active in some yet to be formed "net community" effort to
>create a "net community" browser. This could possibly be based
>on the latest Mosaic 2.8 Alpha code if NCSA decides to release
>the code from copyright (or whatever is legally required).
>
>Most of these options would require significant volunteer programming
>effort by one or more members of the VMS community.
>
As I pointed out to George already in personal mail I would
volunteer to do at least some of the work, but due to other
restrictions (job and family) I defintily can't do it alone.
>To those who ask why not just use Netscape: well, that would leave
>the VMS community trapped with a browser having only the functionality
>that Netscape/Digital manage to port to VMS. Given Digital's erratic/
>irrational behavior in the last few years, I try not to depend too much
>on what they say they intend to do. There is also a significant need
>for a browser which comes with source code; Netscape definitely does
>not meet that need.
>
>
This is perfectly phrased! I use Netscape if I have to (dreaded
frames), but I would be very reluctant to rely on it completely.
Greetings, Martin
* Martin P.J. Zinser Email: eurmpz@eur.sas.com
* SAS Institute Europe
* Tech Support If you are interested in VMS try
* Postfach 105340 http://axp616.gsi.de:8080/www/vms/sw.html
* D-69043 Heidelberg or (if you are confined in the SAS internal net)
* Phone: 49 +6221 416222 http://gringo.eur.sas.com:8080/www/vms/sw.html
Return-path: <COOK@wvnvaxa.wvnet.edu>
Date: Thu, 09 Jan 1997 04:10:34 -0500 (EST)
From: George Cook <COOK@wvnvaxa.wvnet.edu>
Subject: Re: Future of Mosaic/VMS browser?
To: "Martin P.J. Zinser, SAS Europe" <zinser@eur.sas.com>
Cc: COOK@wvnvaxa.wvnet.edu, vms-mosaic@hhs.dk
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
>>3. Look at porting some other browser like Chimera to VMS.
> Where to get this (for Unix I guess)?
Yes, only for Unix currently. The Chimera home page is
http://www.unlv.edu/chimera/
It uses the Athena widget set instead of Motif and uses Perl scripts for
stuff like MAILTO: and NEWS:
The comments I've heard about it seem positive, but I have never seen
it run since I don't have access to a Unix platform. The need for Perl
is negative in that Perl for VMS (besides being a large package) is not
easy to install particularly when socket support is required.
George
Return-path: <niepraschk@ChbRB.Berlin.PTB.De>
Date: Thu, 09 Jan 1997 11:13:17 -0500 (EST)
From: Rolf Niepraschk <niepraschk@ChbRB.Berlin.PTB.De>
Subject: Re: Future of Mosaic/VMS browser?
To: COOK@wvnvaxa.wvnet.edu
Cc: vms-mosaic@hhs.dk, zinser@eur.sas.com
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
> >>3. Look at porting some other browser like Chimera to VMS.
>
> > Where to get this (for Unix I guess)?
>
> Yes, only for Unix currently. The Chimera home page is
> http://www.unlv.edu/chimera/
>
> It uses the Athena widget set instead of Motif and uses Perl scripts for
> stuff like MAILTO: and NEWS:
>
> The comments I've heard about it seem positive, but I have never seen
> it run since I don't have access to a Unix platform. The need for Perl
> is negative in that Perl for VMS (besides being a large package) is not
> easy to install particularly when socket support is required.
What's about the amaya browser? At the moment exists binaries for
linux and sun but in the future the source code will be available, I think.
Look at
http://www.w3.org/pub/WWW/Amaya/
...Rolf
.----------------------------------------------------.
| Rolf Niepraschk |
| Physikalisch-Technische Bundesanstalt |
| Abbestr. 2-12 |
| D-10587 Berlin, Germany |
| Tel.: ++49-30-3481-316, Fax.: ++49-30-3481-490 |
| Bitnet: NIEPRASCHK@PTBIB |
| Internet: NIEPRASCHK@PTB.DE |
`----------------------------------------------------'
Return-path: <jhjennis2@mmm.com>
Date: Thu, 09 Jan 1997 08:31:02 -0500 (EST)
From: jhjennis2@mmm.com
Subject: Re: Future of Mosaic/VMS browser?
To: vms-mosaic@hhs.dk
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
I agree with George 110%!!!! I vote for trying to keep X-Mosaic going on OVMS.
There is no substitute for a browser (like mosaic) which has the source code
included. Despite Mosaic's limitations, I cannot get what I need from Netscape
or "Bill's Company". VMS is a fine operating system (and so is unix) but if the
World User/Net community at large does not take some initiative, we will all
have to be running One of Bill's products on one of Intel's machines. Where will
the creativity be then?
I am hoping that the many talented VMS'ers out here can band together with the
Unix/Linux people and form a group that will get 2.8 Operational. Lack of real
table/frame support is getting to be a little troublesome now even though these
(to my knowledge) are still not "standard html". (My one concern with a 2.8 port
is the suggested move by NCSA to C++) Although it is quite powerful and will be
the "language of the future" when standards are more defined, but as of now, I
think moving to C++ would limit the participation in any porting/development
efforts.
I have been involved with VMS/Mosaic since I worked with Bjorn Nilsson on
testing the original 2.4 port, although I am no "real programmer" I would be
happy to help in any way that I can.
Thanks and best regards to all in the group,
Jim Jennis, Sr. Manufacturing Specialist
Imation Corp.
Printing & Publishing Systems Div.
Manufacturing Systems/Networking/Internet Services
Middleway Plant
Middleway, WV. USA.
Internet: jhjennis2@mmm.com
> Looks like Mosaic will no longer supported by NCSA at all. We
> should discuss how to proceede from here.
Although NCSA still plans to release 2.7b6 any day now (and probably a
final 2.7 at a later point), from what I have been able to make out
from reading comp.infosystems.www.browsers.x, it appears that NCSA is
dropping all active support for X Mosaic.
Several options how to proceed:
1. This group can try to continue to support the final release of X
Mosaic on VMS. It will need minor work to keep it running on new
releases of Motif, VMS, etc. It might also be possible to hack in
the table support, etc. from mMosaic.
2. Look at adding VMS support to mMosaic. Could be a lot of work
since few of the VMS patches made it into 2.7b4 on which mMosaic
is based, plus the mMosaic developer would have to be interested
in supporting VMS unless we want to return to keeping the VMS
modifications separate.
3. Look at porting some other browser like Chimera to VMS.
4. Become active in some yet to be formed "net community" effort to
create a "net community" browser. This could possibly be based
on the latest Mosaic 2.8 Alpha code if NCSA decides to release
the code from copyright (or whatever is legally required).
Most of these options would require significant volunteer programming
effort by one or more members of the VMS community.
To those who ask why not just use Netscape: well, that would leave
the VMS community trapped with a browser having only the functionality
that Netscape/Digital manage to port to VMS. Given Digital's erratic/
irrational behavior in the last few years, I try not to depend too much
on what they say they intend to do. There is also a significant need
for a browser which comes with source code; Netscape definitely does
not meet that need.
George
Return-path: <del@intranet.com>
Date: Thu, 09 Jan 1997 10:11:06 -0500 (EST)
From: "G. Del Merritt" <del@intranet.com>
Subject: Re: Future of Mosaic/VMS browser?
To: vms-mosaic@hhs.dk
Cc: bailey@HMIVAX.HUMGEN.UPENN.EDU
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
In-reply-to: "COOK@wvnvaxa.wvnet.edu"'s message of 9-JAN-1997 04:19:11.78
>>>3. Look at porting some other browser like Chimera to VMS.
> :
>It uses the Athena widget set instead of Motif and uses Perl scripts for
>stuff like MAILTO: and NEWS:
>
>The comments I've heard about it seem positive, but I have never seen
>it run since I don't have access to a Unix platform. The need for Perl
>is negative in that Perl for VMS (besides being a large package) is not
>easy to install particularly when socket support is required.
Yes, Perl is a large package. No, it's not particularly difficult to install
because of its socket support, if you read the documentation. The fact that
it uses socketshr makes it _easier_, since you can have a TCPwise heterogenous
cluster and use one copy of the application using socketshr. (Of course, if
you have a mixed hardware cluster of AXPen and VAXen, you still need two
images.)
I've CC'd the caretaker of Perl-for-VMS (and current, or at least recent, Perl
pumpkin holder) Charles Bailey. I would suggest that anyone who chooses to
pursue this Chimera should consider joining/auditing the Perl for VMS list
(vmsperl@genetics.upenn.edu; subscribe by sending a note to Charles Bailey)
and/or peruse the archives noted below. As most of you are probably aware,
Perl is available on the OpenVMS Freeware CDROM; DEC is evidently about to
release a new version of that CDROM, and it will possibly include Perl 5.0004,
which would be the latest version (Charles is helping keep Perl viable and
current for the VMS community). If you have that CD or its predecessor, check
out the various readme's therein for the list of VMS Perl web pages. A couple
of possible pages include:
http://w4.lns.cornell.edu/~pvhp/perl/VMS.html
http://duphy4.physics.drexel.edu/duphy4/
The mailing list archives are at:
http://www.rosat.mpe-garching.mpg.de/mailing-lists/VMSperl/
--
Del Merritt del@IntraNet.com
IntraNet, Inc., One Gateway Center #700, Newton, MA 02158
Voice: 617-527-7020; FAX: 617-527-1761 Just say no to Clipper.
You may not add me to a commercial mailing list or send me commercial
advertising without my consent.
NERD PRIDE is a registered trademark of the MIT
Return-path: <COOK@wvnvaxa.wvnet.edu>
Date: Thu, 09 Jan 1997 10:30:53 -0500 (EST)
From: George Cook <COOK@wvnvaxa.wvnet.edu>
Subject: Re: Future of Mosaic/VMS browser?
To: "G. Del Merritt" <del@intranet.com>
Cc: vms-mosaic@hhs.dk, bailey@HMIVAX.HUMGEN.UPENN.EDU, COOK@wvnvaxa.wvnet.edu
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
>>The comments I've heard about it seem positive, but I have never seen
>>it run since I don't have access to a Unix platform. The need for Perl
>>is negative in that Perl for VMS (besides being a large package) is not
>>easy to install particularly when socket support is required.
>Yes, Perl is a large package. No, it's not particularly difficult to install
>because of its socket support, if you read the documentation. The fact that
>it uses socketshr makes it _easier_, since you can have a TCPwise heterogenous
>cluster and use one copy of the application using socketshr. (Of course, if
>you have a mixed hardware cluster of AXPen and VAXen, you still need two
>images.)
My perspective is from that of a user who just recently installed a recent
release of Perl. I'd agree that building it with socket support using
socketshr would probably not make it any more difficult to install if
socketshr was a viable package. Unfortunately socketshr was (in early
1995) and still is Very Badly Broken, not only in it's lack of support for
DEC C on VAX, but also in it's functioning. It was an extreme hassle to
make socketshr work (work being a relative term in that it never actually
did work 100%) with Mosaic; an experience I would not repeat unless there
was no alternative.
There have been repeated rumors of new socketshr releases and/or bug
fixes, however the release available from the socketshr home location
was still the 1995 release when I checked a month or so back.
As far as making Perl's socket support easy to install in all cases
(assuming a recent release of MultiNet, TCPware, CMU/LIBCMUII, UCX or
Pathway is installed on the system), the way to go is to have a single
UCX compatibility build without any direct support (i.e., no use of the
package's own socket library or include files) for the underlaying
TCP/IP package. Once all the issues were worked thru (it took quite
a lot of discussion due to mass confusion on the topic), the actual
implementation of this with Mosaic turned out to be amazingly simple.
When I recently added support for TCPware to Mosaic, it took only a
few minutes and required simple mods to just four files.
George
Return-path: <zinser@eur.sas.com>
Date: Thu, 09 Jan 1997 17:19:16 +0000 (MET-1MET)
From: "Martin P.J. Zinser, SAS Europe" <zinser@eur.sas.com>
Subject: Re: Future of Mosaic/VMS browser?
To: COOK@wvnvaxa.wvnet.edu
Cc: vms-mosaic@hhs.dk
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
George Cook <COOK@wvnvaxa.wvnet.edu> writes:
>
>There have been repeated rumors of new socketshr releases and/or bug
>fixes, however the release available from the socketshr home location
>was still the 1995 release when I checked a month or so back.
>
>As far as making Perl's socket support easy to install in all cases
>(assuming a recent release of MultiNet, TCPware, CMU/LIBCMUII, UCX or
>Pathway is installed on the system), the way to go is to have a single
>UCX compatibility build without any direct support (i.e., no use of the
>package's own socket library or include files) for the underlaying
>TCP/IP package. Once all the issues were worked thru (it took quite
>a lot of discussion due to mass confusion on the topic), the actual
>implementation of this with Mosaic turned out to be amazingly simple.
>When I recently added support for TCPware to Mosaic, it took only a
>few minutes and required simple mods to just four files.
>
>
I do have to admit that I tend to avoid socketshr too.
But making perl work with the native UCX socket includes/libs
was not really difficult. All the changes that were necessary
can be found via
http://axp616.gsi.de:8080/www/vms/sw/perl.htmlx
Greetings, Martin
P.S. On a related note: XPMlib 3.4j was released recently and contains
now build-scripts and support for OpenVMS from the start.
* Martin P.J. Zinser Email: eurmpz@eur.sas.com
* SAS Institute Europe
* Tech Support If you are interested in VMS try
* Postfach 105340 http://axp616.gsi.de:8080/www/vms/sw.html
* D-69043 Heidelberg or (if you are confined in the SAS internal net)
* Phone: 49 +6221 416222 http://gringo.eur.sas.com:8080/www/vms/sw.html
Return-path: <ARNE@ko.hhs.dk>
Date: Fri, 10 Jan 1997 09:15:22 +0100 (MET)
From: Arne Vajhoej <ARNE@ko.hhs.dk>
Subject: Re: Future of Mosaic/VMS browser?
To: COOK@wvnvaxa.wvnet.edu
Cc: vms-mosaic@hhs.dk
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
> 1. This group can try to continue to support the final release of X
> Mosaic on VMS. It will need minor work to keep it running on new
> releases of Motif, VMS, etc. It might also be possible to hack in
> the table support, etc. from mMosaic.
I think this option should be choosed anyway, because it does not
exclude the other options. And it is nice to have something working
while new things are being developed.
Arne
(still hanging around)
Arne Vajhĝj local DECNET: KAL13::ARNE
Computer Department PSI: PSI%23831001354030::ARNE
Southern Denmark Business School Internet: ARNE@KO.HHS.DK
WWW URL: http://www.hhs.dk/~arne/arne.html
Return-path: <ARNE@ko.hhs.dk>
Date: Fri, 10 Jan 1997 09:19:09 +0100 (MET)
From: Arne Vajhoej <ARNE@ko.hhs.dk>
Subject: Re: Future of Mosaic/VMS browser?
To: zinser@eur.sas.com
Cc: vms-mosaic@hhs.dk
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
> >To those who ask why not just use Netscape: well, that would leave
> >the VMS community trapped with a browser having only the functionality
> >that Netscape/Digital manage to port to VMS. Given Digital's erratic/
> >irrational behavior in the last few years, I try not to depend too much
> >on what they say they intend to do. There is also a significant need
> >for a browser which comes with source code; Netscape definitely does
> >not meet that need.
> >
> >
> This is perfectly phrased! I use Netscape if I have to (dreaded
> frames), but I would be very reluctant to rely on it completely.
It is always good to have more than one. Monopoly is not good for
either development or price (seen from the customers point of view).
And the source code aspect is not unimportant.
Arne
Arne Vajhĝj local DECNET: KAL13::ARNE
Computer Department PSI: PSI%23831001354030::ARNE
Southern Denmark Business School Internet: ARNE@KO.HHS.DK
WWW URL: http://www.hhs.dk/~arne/arne.html
Return-path: <ARNE@ko.hhs.dk>
Date: Fri, 10 Jan 1997 09:24:02 +0100 (MET)
From: Arne Vajhoej <ARNE@ko.hhs.dk>
Subject: Re: Future of Mosaic/VMS browser?
To: del@intranet.com
Cc: vms-mosaic@hhs.dk
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
> (vmsperl@genetics.upenn.edu; subscribe by sending a note to Charles Bailey)
It was announced that it was possible to subscribe by sending to:
VMSPERL-REQUEST@GENETICS.UPENN.EDU
Arne
Arne Vajhĝj local DECNET: KAL13::ARNE
Computer Department PSI: PSI%23831001354030::ARNE
Southern Denmark Business School Internet: ARNE@KO.HHS.DK
WWW URL: http://www.hhs.dk/~arne/arne.html
Return-path: <bailey@genetics.upenn.edu>
Date: Fri, 10 Jan 1997 14:32:14 -0500 (EST)
From: Charles Bailey <bailey@genetics.upenn.edu>
Subject: Re: Future of Mosaic/VMS browser?
To: George Cook <COOK@wvnvaxa.wvnet.edu>
Cc: "G. Del Merritt" <del@intranet.com>, vms-mosaic@hhs.dk
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Content-transfer-encoding: 7BIT
George Cook <COOK@wvnvaxa.wvnet.edu> wrote:
|
| >>The comments I've heard about it seem positive, but I have never seen
| >>it run since I don't have access to a Unix platform. The need for Perl
| >>is negative in that Perl for VMS (besides being a large package) is not
| >>easy to install particularly when socket support is required.
|
| >Yes, Perl is a large package. No, it's not particularly difficult to install
| >because of its socket support, if you read the documentation. The fact that
| >it uses socketshr makes it _easier_, since you can have a TCPwise heterogenous
| >cluster and use one copy of the application using socketshr. (Of course, if
| >you have a mixed hardware cluster of AXPen and VAXen, you still need two
| >images.)
|
| My perspective is from that of a user who just recently installed a recent
We're always trying to clean up installation problems that show up at
different sites, so we'd be happy to hear about any problems you had.
| release of Perl. I'd agree that building it with socket support using
| socketshr would probably not make it any more difficult to install if
| socketshr was a viable package. Unfortunately socketshr was (in early
| 1995) and still is Very Badly Broken, not only in it's lack of support for
Agreed (wrt DECC compatibility at least; I've only run into a few instances
of design/function errors). I'm not forever wedded to SocketShr for Perl;
it provides two advantages, which I'd be just as happy to take from another
source if it could provide them:
1. Relative vendor independence. NETLIB is out in this respect, since
its API isn't very BSD-like, but perhaps a UXC-compatibility build
would work, since I gather that most TCP/IP stacks for VMS now
include UCX emulation. (Would you like some bread with your
alphabet soup? :-))
2. Shims for stdio routines. Perl allows sockets to be used as
normal I/O channels as well as arguments to socket-specific
I/O functions. Thus it's possible to say something like
socket(SOCK,PF_INET,SOCK_STREAM,$my_proto);
. . .
print SOCK $my_msg;
in which case the I/O will eventually be done by C fwrite() or
printf(). SocketShr will intercept these calls and redirect
them to the proper socket functions; is this true of the
equivalent routines in any version of the CRTL?
| There have been repeated rumors of new socketshr releases and/or bug
| fixes, however the release available from the socketshr home location
| was still the 1995 release when I checked a month or so back.
Given this apparent lack of development (alas), I've been thinking
of putting DECC-compiled object code up for aftp here, so that people
who wish to build Perl using DECC on a VAX (a desirable thing) can
just grab the object files and not have to wrestle with the SOCKETSHR
source code.
| TCP/IP package. Once all the issues were worked thru (it took quite
| a lot of discussion due to mass confusion on the topic), the actual
| implementation of this with Mosaic turned out to be amazingly simple.
Does Mosaic do any of the socket-is-normal-FILE* stuff I mentioned
above? If it looks like I'm starting at shadows, I'll be happy to
try folding a UCX-emulation option into Perl.
Regards,
Charles Bailey bailey@genetics.upenn.edu
Return-path: <reed@cbict3.cb.lucent.com>
Date: Fri, 10 Jan 1997 16:40:16 -0500 (EST)
From: Brian Reed <reed@cbict3.cb.lucent.com>
Subject: Re: Future of Mosaic/VMS browser?
To: vms-mosaic@hhs.dk
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
>1. This group can try to continue to support the final release of X
> Mosaic on VMS. It will need minor work to keep it running on new
> releases of Motif, VMS, etc. It might also be possible to hack in
> the table support, etc. from mMosaic.
For me, the current Mosaic does quite well, except for tables.
If the table support from mMosaic can be used, that would be
great. Does anyone have an idea on how much work that would be?
Since it was based on 2.7.4?? I was just wondering if it would
be "simple" to copy over.
I also have a couple of suggestions, that I think should be
rather easy to implement.
1) Adding a "Goto URL" button on the toolbar. Does the same thing
as the popup menu, to go to the URL that is highlighted. I find
myself using this quite a bit now.
2) Adding the count of number of bytes downloaded to the "save"
screen (similar/same as what appears during download). I've
had some cases where a download timed out, but I didn't
realize it till after trying to use the file.
Brian D. Reed
Lucent Technologies
Columbus Works
bdreed1@lucent.com
614-860-6218
Return-path: <srwmcln@baby.bedroom.gen.nz>
Date: Sat, 11 Jan 1997 14:30:58 +1300
From: Clive Nicolson <srwmcln@baby.bedroom.gen.nz>
Subject: Re: Future of Mosaic/VMS browser?
To: vms-mosaic@hhs.dk
Cc: srwmcln@baby.bedroom.gen.nz
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Charles Bailey <bailey@genetics.upenn.edu> wrote
...deleted material
>Agreed (wrt DECC compatibility at least; I've only run into a few instances
>of design/function errors). I'm not forever wedded to SocketShr for Perl;
>it provides two advantages, which I'd be just as happy to take from another
>source if it could provide them:
>
> 1. Relative vendor independence. NETLIB is out in this respect, since
> its API isn't very BSD-like, but perhaps a UXC-compatibility build
> would work, since I gather that most TCP/IP stacks for VMS now
> include UCX emulation. (Would you like some bread with your
> alphabet soup? :-))
>
> 2. Shims for stdio routines. Perl allows sockets to be used as
> normal I/O channels as well as arguments to socket-specific
> I/O functions. Thus it's possible to say something like
>
> socket(SOCK,PF_INET,SOCK_STREAM,$my_proto);
> . . .
> print SOCK $my_msg;
>
> in which case the I/O will eventually be done by C fwrite() or
> printf(). SocketShr will intercept these calls and redirect
> them to the proper socket functions; is this true of the
> equivalent routines in any version of the CRTL?
>
The VAXC RTL implementation of sockets does not permit them to be treated
as a stream file, this is however provided by the DECC RTL (>6.0?) most
VMS IP packages should support the updated UCX socket emulation for this.
I have a shareable library (derived from socketshr) which provides the
sims for most VAXC stream io routines, but it uses the socket routines
in the VAXC RTL, ie this sort of adds the newer functionality of the
DECC RTL which is missing from the VAXC RTL.
....deleted material....
>Does Mosaic do any of the socket-is-normal-FILE* stuff I mentioned
>above? If it looks like I'm starting at shadows, I'll be happy to
>try folding a UCX-emulation option into Perl.
Mosaic does not treat sockets as stream files. This makes sockets via
the VAXC RTL doable for Mosaic.
Clive.
Return-path: <COOK@wvnvaxa.wvnet.edu>
Date: Sun, 12 Jan 1997 23:44:52 -0500 (EST)
From: George Cook <COOK@wvnvaxa.wvnet.edu>
Subject: Re: Future of Mosaic/VMS browser?
To: Charles Bailey <bailey@genetics.upenn.edu>
Cc: George Cook <COOK@wvnvaxa.wvnet.edu>, "G. Del Merritt" <del@intranet.com>,
vms-mosaic@hhs.dk, COOK@wvnvaxa.wvnet.edu
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
>We're always trying to clean up installation problems that show up at
>different sites, so we'd be happy to hear about any problems you had.
The build of 5.003_13_961221 failed with a DCL error at one point during
the build. Unfortunately, I cleaned the directories when I was done, so
I couldn't find the bad code later. The problem was a DCL WRITE command
which tries to write out three DCL commands into a file which is then
executed, however the WRITE puts all three commands on a single line
which when executed fails with a syntax error.
The only way I'd find this again would be to do a complete rebuild.
>| release of Perl. I'd agree that building it with socket support using
>| socketshr would probably not make it any more difficult to install if
>| socketshr was a viable package. Unfortunately socketshr was (in early
>| 1995) and still is Very Badly Broken, not only in it's lack of support for
>Agreed (wrt DECC compatibility at least; I've only run into a few instances
>of design/function errors). I'm not forever wedded to SocketShr for Perl;
>it provides two advantages, which I'd be just as happy to take from another
>source if it could provide them:
> 1. Relative vendor independence. NETLIB is out in this respect, since
> its API isn't very BSD-like, but perhaps a UXC-compatibility build
> would work, since I gather that most TCP/IP stacks for VMS now
> include UCX emulation. (Would you like some bread with your
> alphabet soup? :-))
> 2. Shims for stdio routines. Perl allows sockets to be used as
> normal I/O channels as well as arguments to socket-specific
> I/O functions. Thus it's possible to say something like
> socket(SOCK,PF_INET,SOCK_STREAM,$my_proto);
> . . .
> print SOCK $my_msg;
> in which case the I/O will eventually be done by C fwrite() or
> printf(). SocketShr will intercept these calls and redirect
> them to the proper socket functions; is this true of the
> equivalent routines in any version of the CRTL?
Given that DEC C does number 2 above, then a DEC C UCX compatibility
build provides both of the above advantages. A UCX compatibility
build, which will execute successfully on any system having the standard
DEC C files regardless of which if any TCP/IP is installed, requires
doing the following:
1. Use only the IP/socket related header files included with DEC C.
The one IP header file (UCX$INETDEF.H) provided with UCX cannot
be used. In case any of the definitions which exist only in
UCX$INETDEF.H are needed, those definitions must be hard coded.
In general, the only time the extra definitions in UCX$INETDEF.H
are needed is when using the ioctl routine.
2. Do not include the UCX$IPC_SHR.EXE shareable image (or any other
TCP/IP's shareable image) in the link for the executable(s).
The resulting executable(s) will run on any system of the same
architecture having a compatible DEC C RTL and a TCP/IP package
which provides UCX compatibility. All of the third party TCP/IP
packages have provided UCX compatibilty for several years now
including CMU when it's combined with LIBCMUII. Although some
of the early third party releases having UCX compatibility don't
work properly (e.g. MultiNet releases prior to V3.4 are badly
broken at least in the case of Mosaic), all of the more recent
releases seem to function properly.
The objects resulting from the build can be linked on any system
of the same architecture which has the DEC C RTL installed (it
can be installed on 5.5 or later of VMS according to the CRT060
release notes).
Note that the above discussion ignores any version issues due to
other shareable images such as Motif's in the case of Mosaic.
George
Return-path: <bailey@genetics.upenn.edu>
Date: Mon, 13 Jan 1997 17:41:13 -0500 (EST)
From: Charles Bailey <bailey@genetics.upenn.edu>
Subject: Re: Future of Mosaic/VMS browser?
To: George Cook <COOK@wvnvaxa.wvnet.edu>
Cc: "G. Del Merritt" <del@intranet.com>, vms-mosaic@hhs.dk
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Content-transfer-encoding: 7BIT
George Cook <COOK@wvnvaxa.wvnet.edu> wrote:
|
| >We're always trying to clean up installation problems that show up at
| >different sites, so we'd be happy to hear about any problems you had.
|
| The build of 5.003_13_961221 failed with a DCL error at one point during
| the build. Unfortunately, I cleaned the directories when I was done, so
| I couldn't find the bad code later. The problem was a DCL WRITE command
| which tries to write out three DCL commands into a file which is then
| executed, however the WRITE puts all three commands on a single line
| which when executed fails with a syntax error.
Hmm. Can you remember whether this occurred while building the basic
Perl images or the standard extensions? That'd help identify the
offending code. Also, what C compiler were you using?
| >Agreed (wrt DECC compatibility at least; I've only run into a few instances
| >of design/function errors). I'm not forever wedded to SocketShr for Perl;
| >it provides two advantages, which I'd be just as happy to take from another
| >source if it could provide them:
|
| > 1. Relative vendor independence. NETLIB is out in this respect, since
| > its API isn't very BSD-like, but perhaps a UXC-compatibility build
| > would work, since I gather that most TCP/IP stacks for VMS now
| > include UCX emulation. (Would you like some bread with your
| > alphabet soup? :-))
|
| > 2. Shims for stdio routines. Perl allows sockets to be used as
| > normal I/O channels as well as arguments to socket-specific
| > I/O functions. Thus it's possible to say something like
|
| > socket(SOCK,PF_INET,SOCK_STREAM,$my_proto);
| > . . .
| > print SOCK $my_msg;
|
| > in which case the I/O will eventually be done by C fwrite() or
| > printf(). SocketShr will intercept these calls and redirect
| > them to the proper socket functions; is this true of the
| > equivalent routines in any version of the CRTL?
|
| Given that DEC C does number 2 above, then a DEC C UCX compatibility
Great! I hadn't known this. Does it vet calls to all I/O routines
(stdio, "Unix I/O", and decc$*), or just stdio?
If DECC does indeed handl the I/O redirection adequately, I'll be happy
to set up Perl so that it defaults to a UCXish build with DECC and a
SOCKETSHRish build with VAXC.
Thanks for the information.
Regards,
Charles Bailey bailey@genetics.upenn.edu
Return-path: <jhjennis2@mmm.com>
Date: Mon, 20 Jan 1997 16:08:45 -0500 (EST)
From: jhjennis2@mmm.com
Subject: Setting Mail Aliases
To: vms-mosaic@hhs.dk
Cc: JENNIS@mdw.mmm.com
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
How can I set mosaic to put a mail alias in the "From" section of mail and news
posts. Our fire wall will reject the "real" smtp address because it is not in the
registry database....eg. I would like mosaic to make the following substitution.
Real address Alias
jennis@myhost.mmm.com jhjennis2@mmm.com
I am running Mosaic 2.7b5 using the multinet smtp interface to vms mail. Ii have
set the aliases in my smtp_aliases file in my login directory, but mosaic does not
seem to read this.
Thanks and best regards,
Jim Jennis, Sr. Manufacturing Specialist
Imation Corp.
Printing & Publishing Systems Div.
Manufacturing Systems/Networking/Internet Services
Middleway Plant
Middleway, WV. USA.
Internet: jhjennis2@mmm.com
Return-path: <COOK@wvnvaxa.wvnet.edu>
Date: Wed, 22 Jan 1997 03:42:18 -0500 (EST)
From: George Cook <COOK@wvnvaxa.wvnet.edu>
Subject: Re: Setting Mail Aliases
To: jhjennis2@mmm.com
Cc: vms-mosaic@hhs.dk, JENNIS@mdw.mmm.com, COOK@wvnvaxa.wvnet.edu
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
>How can I set mosaic to put a mail alias in the "From" section of mail and news
>posts. Our fire wall will reject the "real" smtp address because it is not in the
>registry database....eg. I would like mosaic to make the following substitution.
>I am running Mosaic 2.7b5 using the multinet smtp interface to vms mail. Ii have
>set the aliases in my smtp_aliases file in my login directory, but mosaic does not
>seem to read this.
As far as mailto: messages, Mosaic does not in any way set the message
"From" address. It simply hands the message body over to the VMS mail
utility along with a "To" address and a Subject. VMS Mail and/or whatever
mailer you use (i.e. MX, PMDF, MultiNet's SMTP) adds the "From" and
other header information. The Mailer used is controlled with Mosaic's
Mail Prefix setting.
In the case of news postings, the "From" address can be changed using
the DefaultAuthorEmail resource.
George
Return-path: <system@niuhep.physics.niu.edu>
Date: Fri, 24 Jan 1997 12:41:32 +0000
From: system@niuhep.physics.niu.edu
Subject: mail-to attachments
To: vms-mosaic@hhs.dk
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Hi,
the documentation suggests that we should be able to attach/include
files when using the mail-to: on a webpage. But there
doesn't seem to be a way to do this. We are using 2.6-2.
Thanks for any help you can give.
Robert
Return-path: <COOK@wvnvaxa.wvnet.edu>
Date: Sun, 26 Jan 1997 03:24:52 -0500 (EST)
From: George Cook <COOK@wvnvaxa.wvnet.edu>
Subject: Re: mail-to attachments
To: system@niuhep.physics.niu.edu
Cc: vms-mosaic@hhs.dk, COOK@wvnvaxa.wvnet.edu
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
>the documentation suggests that we should be able to attach/include
>files when using the mail-to: on a webpage. But there
>doesn't seem to be a way to do this. We are using 2.6-2.
I don't remember if 2.6-2 had the ability to do it, however the latest
releases of Mosaic do. With 2.7-5, there is an insert file button
on the mailto: window. Try upgrading to 2.7-5; it is much improved
over 2.6-2.
George
Return-path: <music@triumf.ca>
Date: Wed, 29 Jan 1997 18:37:17 -0800 (PST)
From: "Fred W. Bach, TRIUMF Operations" <music@triumf.ca>
Subject: Strange annoying MAIL bug in MOSAIC for VMS.
To: vms-mosaic@hhs.dk
Cc: music@triumf.ca
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Dear Mosaic List,
Hear is an interesting MOSAIC BUG report. Mailing DCL code via
MOSAIC's pulldown File menu **executes** the code. But you may
need a row of dashes before the code to demonstrate it.
*************
My setup:
VXT2000 with 18 megs of memory and FPU running Decwindows Motif
version 1.2-3 . Terminal Manager says VXT 2.1E .
AlphaServer 2000 5/250
Multiprocessing is DISABLED. Uniprocessing synchronization image loaded.
Minimum multiprocessing revision levels: CPU = 1
System Memory Resources on 29-JAN-1997 17:23:50.52
Physical Memory Usage (pages): Total Free In Use Modified
Main Memory (256.00Mb) 32768 5021 22210 5537
Virtual I/O Cache (Kbytes): Total Free In Use
Cache Memory 3200 0 3200
OpenVMS V6.2 on node 29-JAN-1997 17:21:19.51 Uptime 8 00:15:25
MOSAIC 2.61b
TCP/IP is MULTINET (in case this matters:)
VERSION V3.5
REVISION B-X
DATE 01-NOV-1995
PRODUCER TGV
PHASEIP_VERSION V1.3
SECUREIP_VERSION V2.0
INSTALLED_IPAPPS YES
INSTALLED_NFSCLIENT YES
INSTALLED_NFSSERVER YES
INSTALLED_NETWARESERVER YES
INSTALLED_PHASEIP YES
INSTALLED_SECUREIP_CLIENT YES
INSTALLED_SECUREIP_SERVER YES
INSTALLED_DOCUMENTATION YES
INSTALLED_LIBRARIES YES
XREPLACED UCXDRIVER.VUI ECO-UCXDRIVER035 22-OCT-1996
**************
Perhaps you have seen this MOSAIC fault before. It's new to me today.
I always wondered why if one didn't run the MOSAIC image with
SPAWN/NOWAIT/INPUT=NL:/OUTPUT=NL:
(notably the /output=NL)
that, after mailing something via MOSAIC, you would have to go back
to the calling DCL window and hit RETURN to get the mail to go and
to get MOSAIC to un-hang.
Little did I suspect what it was REALLY up to.
Well today I was reading news:comp.os.vms on MOSAIC and I found a
post from Wolfgang J. Moeller (below). His comments are separated
from a neat little DCL script with a row of minus signs.
I mailed the article to my sys manager. (My VMS Mail has CC set
so I get a copy of this.)
Very shortly after I mailed the article from MOSIAC, the dreaded
"d i g i t a l" logo box appeared on my screen along with a session
login box (the kind WITHOUT a cancel button). Nothing I initially
tried would get rid of that box, including making a legitamate
logon and then signing off the session manager, giving 3 false
username/password pairs. The logo and sessionlogin boxes just kept
coming back.
What MOSAIC had done was separate the mail at the row of minus
signs, (my VMS Mail CC: copy tells me that - it goes as far as the
line of minus signs) mail that row and what was above it, and then
MOSIAC fed the DCL script to I suspect the mother process (I may be
wrong) but anyway it executed the DCL Script!!
I mean, WHAT IN BLAZES allowed this MOTHER BUG to slip in? I know
that some mailers or remailers (such as anonymous remailers)
deliberately strip off code after a line which starts with 2 minus
signs. But MOSAIC ???
I eventually figured out that I had to get rid of all orphan
windows of the same username (including detached ones) on my
workstation and THEN give three false username/password pairs in
order for the logo and sessionlogin boxes to disappear for good.
This included detached process windows (as long as they were the
same username as the one from which I was running Mosaic). I had
some plots going under another username and I really did NOT want
to reboot the Xterm.
I would appreciate it if someone else found and fixed this bug.
I don't see it under the bugs for the later versions under MOSAIC
help. Thanks in advance.
HERE IS Wolfgang'S post:
Path: unixg.ubc.ca!info.ucla.edu!csulb.edu!hammer.uoregon.edu!news.mathworks.com!mvb.saic.com!info-vax
From: "GWDVMS::MOELLER" <moeller@gwdvms.dnet.gwdg.de>
Newsgroups: comp.os.vms
Subject: RE: Autologin after boot with a VAX 4090
Message-ID: <58314601@MVB.SAIC.COM>
Date: Wed, 29 Jan 1997 20:37:46 +0100
Organization: Info-Vax<==>Comp.Os.Vms Gateway
X-Gateway-Source-Info: Mailing List
Lines: 127
Xref: unixg.ubc.ca comp.os.vms:134564
Guag <guag@PCUCP4.CRA.ENEL.IT> writes:
> I have a system ( VAX station 4090 VMS 6.1 ) that must restart
> automatically the appilcation that is running also after a black out.
> Infact, in case of a black -out the system, after automatic the boot,
> should to login in to a username automatically.
> Someone knows how to configure DECW$STARTUP to perform this autologin?
I have a command file (below) that automatically logs in SYSTEM
(note that it has "$ submit ... /user=SYSTEM" at one place).
I think (not going to test it myself) that it could "log in"
other users, if you give it another value for /user, and not
require them to have unusual privileges (except for being able
to execute a _batch_ job within the queue mentioned.
The command file (called SYS-SESSION.COM here) is "declared"
to the DECW-Startup by having (at least) the following line
in SYS$MANAGER:DECW$PRIVATE_APPS_SETUP.COM :
$ DECW$MAINAPP == "@SYS$MANAGER:SYS-SESSION.COM"
Normally, DECW$MAINAPP is the "login-box", so if things go wrong,
you're left without one ("goto default" tries to catch some error
situations foreseen by me). Be careful, and make sure you have
an alternate way (network or terminal) to get into the system.
Wolfgang J. Moeller, Tel. +49 551 2011516 or -510, moeller@gwdvms.dnet.gwdg.de
GWDG, D-37077 Goettingen, F.R.Germany | Disclaimer: No claim intended!
<moeller@decus.decus.de> ----- <moeller@gwdg.de> ----- <w.moeller@ieee.org>
----- SYS-SESSION.COM ----------------------------------------------------------
$! replacement for DECW$MAINAPP ... (DECW/Motif 1.2)
$! - to be invoked from within DECW*STARTAPP*.COM
$! - go batch in oder to force user=SYSTEM
$! (requires a certain batch queue - below - and suitable queue state)
$! - when running in batch, go detached and finally
$! run DECW$SESSION - w/o executing DECW$*LOGIN.COM
$!
$! Requires all sorts of suitable privileges!
$!
$! w.j.m. jul 1994, somewhat after (DECW/Motif 1.2) DECW$STARTSM.COM
$!==============================================================================
$!
$ on warning then goto default
$!
$ if f$environ("depth").eq.0 then goto 'f$mode()' ! initially depth > 0
$!
$!
$!***** 1st step: invoked from e.g. DECW*STARTAPP, DECW$DISPLAY=>display
$!
$ queue = "GWD$SYS_JOBS" ! <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
$!
$ if f$getqui("display_queue","queue_batch",queue) then goto tq1
$ goto default
$tq1:
$ if f$getqui("display_queue","queue_idle",queue) .or.-
(f$getqui("display_queue","queue_available",queue) .and.-
.not.f$getqui("display_queue","queue_stop_pending",queue)) then goto tq2
$ goto default
$tq2:
$ display = f$getdvi("DECW$DISPLAY","fulldevnam")
$ if display.nes.""
$ then
$ submit/queue='queue'/user=SYSTEM/nolog -
'f$environ("procedure")' -
/parameter=('display')
$ exit
$ endif
$!
$default:
$ set noon
$ run SYS$SYSTEM:DECW$STARTLOGIN
$ exit
$!
$!
$!***** 2nd step (normally BATCH), P1=display
$!
$NETWORK:
$INTERACTIVE:
$BATCH:
$ on warning then exit $status
$!
$ display = f$getdvi(p1,"fulldevnam")
$ if f$extract(0,4,display).nes."_WSA" then exit 2
$!
$ myself = f$environ("procedure")
$ myname = f$parse(myself,,,"name")
$ run/detached SYS$SYSTEM:LOGINOUT -
/authorize - ! required for getting SYS$LOGIN etc.
/process_name='myname' -
/input='myself' -
/output='display' - ! pass WSA as SYS$OUTPUT
/error='myname'.LOG
$ exit
$!
$!
$!***** 3rd step (detached), SYS$OUTPUT=>display
$!
$OTHER:
$ set noon
$ display = f$getdvi("SYS$OUTPUT","fulldevnam")
$ if f$extract(0,4,display).nes."_WSA" then exit 2
$ define/job DECW$DISPLAY 'display'
$!
$! ... leave SYS$OUTPUT pointing to _WSA ...
$!
$ define/nolog decw$doing_session SESSIONINIT
$ sessioninit = F$TRNLNM("DECW$SESSIONINIT")
$ if sessioninit .EQS. "" then goto do_sessionmain
$ 'sessioninit
$do_sessionmain:
$ define/nolog decw$doing_session SESSIONMAIN
$ sessionmain = F$TRNLNM("DECW$SESSIONMAIN")
$ if sessionmain .EQS. "" then goto do_sessionend
$ 'sessionmain
$do_sessionend:
$ define/nolog decw$doing_session SESSIONEND
$ sessionend = F$TRNLNM("DECW$SESSIONEND")
$ if sessionend .EQS. "" then goto do_exit
$ 'sessionend
$do_exit:
$ logout
$ stop/id=0
----- SYS-SESSION.COM ----------------------------------------------------------
Wolfgang J. Moeller, Tel. +49 551 2011516 or -510, moeller@gwdvms.dnet.gwdg.de
GWDG, D-37077 Goettingen, F.R.Germany | Disclaimer: No claim intended!
<moeller@decus.decus.de> ----- <moeller@gwdg.de> ----- <w.moeller@ieee.org>
**********************
Fred W. Bach , Operations Group | Internet: music@triumf.ca
TRIUMF (TRI-University Meson Facility) | Voice: 604-222-1047 loc 6327/7333
4004 WESBROOK MALL, UBC CAMPUS | FAX: 604-222-1074
University of British Columbia, Vancouver, B.C., CANADA V6T 2A3
"Accuracy is important. Details can mean the difference between life & death."
These are my opinions, which should ONLY make you read, think, and question.
They do NOT necessarily reflect the views of my employer or fellow workers.
Return-path: <COOK@wvnvaxa.wvnet.edu>
Date: Sun, 02 Feb 1997 04:25:31 -0500 (EST)
From: George Cook <COOK@wvnvaxa.wvnet.edu>
Subject: Re: Strange annoying MAIL bug in MOSAIC for VMS.
To: "Fred W. Bach, TRIUMF Operations" <music@triumf.ca>
Cc: vms-mosaic@hhs.dk, COOK@wvnvaxa.wvnet.edu
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
> MOSAIC 2.61b
This problem was fixed in one of the 2.7b releases. The original code
did not properly protect the mail command's sys$input. Adding the DCL
command DECK/DOLLAR to the sys$input stream fixed the problem.
> What MOSAIC had done was separate the mail at the row of minus
> signs, (my VMS Mail CC: copy tells me that - it goes as far as the
> line of minus signs) mail that row and what was above it, and then
> MOSIAC fed the DCL script to I suspect the mother process (I may be
> wrong) but anyway it executed the DCL Script!!
Return-path: <jhjennis2@mmm.com>
Date: Tue, 04 Feb 1997 10:20:32 -0500 (EST)
From: jhjennis2@mmm.com
Subject: Fixing table Support in 2.7-x
To: vms-mosaic@hhs.dk
Cc: JENNIS@mdw.mmm.com
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Hi VMS-Mosaic Group!
There are more and more sites (my own included) will HAVE to
use html table constructs. Users are starting (for example) to
use MicroSoft Office '97 to export Excel spreadsheets as html
tables. Mosaic (IMHO) is the premier browser for X clients. I
very very much want to keep using Mosaic as my default
production browser on X windows clients because to the
flexibility and security it provides over Netscape.
I am wondering if there is any appetite (since 2.8 Mosaic
seems to be dormant now) to hack some table fixes into 2.7-x
At this point I would be happy if the tables just displayed
correctly (even if imbedded hypertext links don't work)!
I am NOT a Motif programmer, but would be happy to volunteer
as an alpha/beta tester or in any other way.
Thanks and best regards,
Jim Jennis, Sr. Manufacturing Specialist
Imation Corp.
Printing & Publishing Systems Div.
Manufacturing Systems/Networking/Internet Services
Middleway Plant
Middleway, WV. USA.
Internet: jhjennis2@mmm.com
Return-path: <adye@v2.rl.ac.uk>
Date: Thu, 20 Feb 1997 01:23:30 +0000 (GMT)
From: adye@v2.rl.ac.uk (Tim Adye: RAL x6632, Oxford x73396, CERN x2103)
Subject: Mosaic remote control crash
To: vms-mosaic@hhs.dk
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Hi,
I think I have found a problem with the remote control facility of
VMS Mosaic 2.7-5 (it may also be there in the Unix version), which can
cause Mosaic to crash.
I think what happens is that if a remote control command appears on the
mailbox too soon after it is created, then Mosaic may not yet have
opened any windows, so a command to operate on a window causes the
crash. I guess that this could also happen with the Unix version.
The CCI initialisation seems to be done later, though still before the
initial window is opened, so there may be the potental for trouble there
too if the mechanism is similar (I haven't tried this).
I found this because my remote controller sits waiting for the mailbox
to be created immediately after starting Mosaic. As soon as the mailbox
is detected, it sends the first command. Of course I can get round
this by putting in a delay, but this is not an ideal solution.
Without the delay, I was able to get Mosaic working by moving the
mailbox initialisation from mo_do_gui to the end of fire_er_up, when I
believe everything should have been started properly. Is this the
correct solution? I'll append the differences in my modified gui.c in
case this is of interest (it also includes very minor fixes which I
noticed in passing: they prevent an invalid "move" or "resize" command
causing a crash).
Regards,
Tim.
============================== cut here ==============================
************
File DATA_DISK7:[ADYE.UTIL.SOURCE.MOSAIC2_7-5.SRC]GUI.C;5
659 static char mbx_name[64];
660 static int use_mbx = 0;
661 static int grp_mbx = 0;
******
File DATA_DISK7:[ADYE.UTIL.SOURCE.MOSAIC2_7-5.SRC]GUI.C;1
************
************
File DATA_DISK7:[ADYE.UTIL.SOURCE.MOSAIC2_7-5.SRC]GUI.C;5
4135 /*
4136 * Setup remote control. Since a remote control command can come in
4137 * any time afterwards, we must have everything else ready. Is it now?
4138 */
4139 #ifndef VMS
4140 signal (SIGUSR1, (void *)ProcessExternalDirective);
4141 #else /* BSN */
4142 if (use_mbx) {
4143 int i;
4144 /*
4145 * Reserve event flag and initalize mailbox on VMS for remote control.
4146 */
4147 i = lib$free_ef(&mbx_event_flag);
4148 i = lib$reserve_ef(&mbx_event_flag);
4149 if (i & 1) {
4150 XtInputId mo_InputId;
4151 mo_InputId = XtAppAddInput(app_context, mbx_event_flag, mbx_iosb,
4152 ProcessExternalDirective, NULL);
4153 InitExternalDirective(grp_mbx, mbx_name);
4154 }
4155 }
4156 #endif
4157
******
File DATA_DISK7:[ADYE.UTIL.SOURCE.MOSAIC2_7-5.SRC]GUI.C;1
************
************
File DATA_DISK7:[ADYE.UTIL.SOURCE.MOSAIC2_7-5.SRC]GUI.C;5
******
File DATA_DISK7:[ADYE.UTIL.SOURCE.MOSAIC2_7-5.SRC]GUI.C;1
4336 char mbx_name[64];
4337 XtInputId mo_InputId;
4338 int use_mbx = 0;
4339 int grp_mbx = 0;
************
************
File DATA_DISK7:[ADYE.UTIL.SOURCE.MOSAIC2_7-5.SRC]GUI.C;5
******
File DATA_DISK7:[ADYE.UTIL.SOURCE.MOSAIC2_7-5.SRC]GUI.C;1
5181 #ifndef VMS
5182 signal (SIGUSR1, (void *)ProcessExternalDirective);
5183 #else /* BSN */
5184 if (use_mbx) {
5185 /*
5186 * Reserve event flag and initalize mailbox on VMS for remote control.
5187 */
5188 i = lib$free_ef(&mbx_event_flag);
5189 i = lib$reserve_ef(&mbx_event_flag);
5190 if (i & 1) {
5191 mo_InputId = XtAppAddInput(app_context, mbx_event_flag, mbx_iosb,
5192 ProcessExternalDirective, NULL);
5193 InitExternalDirective(grp_mbx, mbx_name);
5194 }
5195 }
5196 #endif
5197
************
************
File DATA_DISK7:[ADYE.UTIL.SOURCE.MOSAIC2_7-5.SRC]GUI.C;5
5411 } else status = url;
******
File DATA_DISK7:[ADYE.UTIL.SOURCE.MOSAIC2_7-5.SRC]GUI.C;1
5406 }
************
************
File DATA_DISK7:[ADYE.UTIL.SOURCE.MOSAIC2_7-5.SRC]GUI.C;5
5421 } else status = url;
******
File DATA_DISK7:[ADYE.UTIL.SOURCE.MOSAIC2_7-5.SRC]GUI.C;1
5416 }
************
Number of difference sections found: 6
Number of difference records found: 49
DIFFERENCES /IGNORE=()/MATCH=2/MERGED=0
============================== cut here ==============================
Tim Adye, DELPHI/BaBar Groups, Particle Physics Dept., _ /|
Rutherford Appleton Laboratory, UK. \'o.O' Oop!
e-mail: T.J.Adye@rl.ac.uk or VXCERN::ADYE (HEPNET/SPAN) =(___)= Ack!
WWW: http://hepwww.rl.ac.uk/Delphi/Adye/homepage.html U Thphft!
Return-path: <COOK@wvnvaxa.wvnet.edu>
Date: Mon, 24 Feb 1997 01:39:55 -0500 (EST)
From: George Cook <COOK@wvnvaxa.wvnet.edu>
Subject: Re: Mosaic remote control crash
To: adye@v2.rl.ac.uk
Cc: vms-mosaic@hhs.dk, COOK@wvnvaxa.wvnet.edu
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
>I think I have found a problem with the remote control facility of
>VMS Mosaic 2.7-5 (it may also be there in the Unix version), which can
>cause Mosaic to crash.
>Without the delay, I was able to get Mosaic working by moving the
>mailbox initialisation from mo_do_gui to the end of fire_er_up, when I
>believe everything should have been started properly. Is this the
>correct solution? I'll append the differences in my modified gui.c in
>case this is of interest (it also includes very minor fixes which I
>noticed in passing: they prevent an invalid "move" or "resize" command
>causing a crash).
I put an updated GUI.C with the fixes in the mosaic anonymous ftp area
on wvnvms.wvnet.edu.
George
Return-path: <SCHUMAN@bnlstb.bio.bnl.gov>
Date: Mon, 24 Feb 1997 13:26:29 -0500 (EST)
From: SCHUMAN@bnlstb.bio.bnl.gov
Subject: Vers. 2.7-4 crashing like mad!
To: vms-mosaic@hhs.dk
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Hi Web and Mosaic friends,
I have been running Mosaic verson 2.7-4 for some
time with virtually no problems...today I have
consistently been crashing...new net bug? I don't think
so! I seem to get garbled URLs (looks like junk strings
in a C program that read something it shouldn't
have...the voice of experience), listed in the top URL
window. Of course if I tryt o go back using the arrow,
I crash with the message congratulating me on finding a
bug in my copy of Mosaic. The exact message appears
after this note. I did try to clear the URL window and
enter a clean address, but the program just appends the
garbage onto my new URL and crashes. I will admit I was
looking at some non-mosaic compliant stuff (tables!)
when this occurs and the tables were turned off. It
appears to be the page that leads me into the table
page, which has an imagemap on it...I will continue to
dig into the problem, but was wondering if anyone had
seen this behavior before and might offer some clues.
Thanks very much...
Gail I. Schuman
Brookhaven National Lab
Biology Dept
schuman1@bnl.gov
Error message and System Info:
--------------------------------------------------------
Congratulations, you may have found a bug in (your copy
of)NCSA Mosaic 2.7-4 on
OpenVMS VAX.
Remaining page file quota 89088, maximum virtual size
98304
If you did not read the README.VMS-2_x file carefully
before installing, it
might be a good time to do it now. If there were any
compilation or linking
errors, you should try to find the reason for them and
correct them.
If this does not help, please take note of what
happened in as much detail
as possible and send mail to cook@wvnvms.wvnet.edu.
Your system version appears to be V5.5-2 running on
VAXstation 4000-90 hardware.
The TCP/IP software is MultiNet.
Your Mosaic executable was generated using Motif 1.1
The logical SYS$LOGIN points to DISK$3:[SCHUMAN]
The logical SYS$SCRATCH points to DISK$3:[SCHUMAN]
...exiting NCSA Mosaic now.
%SYSTEM-F-ABORT, abort
Return-path: <SCHUMAN@bnlstb.bio.bnl.gov>
Date: Tue, 25 Feb 1997 14:06:14 -0500 (EST)
From: SCHUMAN@bnlstb.bio.bnl.gov
Subject: RE: Vers. 2.7-4 crashing like mad!
To: vms-mosaic@hhs.dk
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Hi All,
Just a little update on the problem of the
garbled URL in Mosaic 2.7-4. I also tried using
netscape to view and move around these pages and had no
problem. If anyone would like to check this out also,
please look at:
http://www.bnl.gov
Select the link for User Facilities
From there Select the High Flux Beam reactor
As soon as I load that page, the URL appears garbled in
the viewing window at the top of the Mosaic screen. I
can move forward from links on that page, but not
backwards. if I exit while on that page, Mosaic also
crashes. Happy Hunting! Thanks.
Gail (Schuman)
Brookhaven National Lab
Biology Dept
schuman1@bnl.gov
PS...Several mails were returned from this list as not
valid...is anyone maintaining list? I will send the bum
addresses if interested.
Return-path: <SEB@LNS62.LNS.CORNELL.EDU>
Date: Tue, 25 Feb 1997 14:21:17 -0500 (EST)
From: Selden E Ball Jr <SEB@LNS62.LNS.CORNELL.EDU>
Subject: RE: Vers. 2.7-4 crashing like mad!
To: SCHUMAN@bnlstb.bio.bnl.gov
Cc: vms-mosaic@hhs.dk, SEB@LNS62.LNS.CORNELL.EDU
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Content-transfer-encoding: 7BIT
Gail,
You wrote
>please look at:
>http://www.bnl.gov
>Select the link for User Facilities
>From there Select the High Flux Beam reactor
>As soon as I load that page, the URL appears garbled in
>the viewing window at the top of the Mosaic screen.
Your instructions lead to the page http://neutron.chm.bnl.gov/HFBR/
I used Lynx to look at it.
The problem seems to be in the <base> reference in its <head>.
It contains (illegal) binary codes. See below.
Evidently the page generator has a bug or two.
I hope this helps.
Selden
==========================
<HTML>
<HEAD>
<TITLE>The High Flux Beam Reactor homepage</TITLE>
<BASE HREF="àùûżdjU1·÷żdjU_">
<META NAME="GENERATOR" CONTENT="Internet Assistant for Word 2.0z Beta">
</HEAD>
Return-path: <fk64@bfkvax.fm.bs.dlr.de>
Date: Wed, 26 Feb 1997 08:48:07 +0100
From: fk64@bfkvax.fm.bs.dlr.de
Subject: Re: Vers. 2.7-4 crashing like mad!
To: vms-mosaic@hhs.dk
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
> Just a little update on the problem of the
> garbled URL in Mosaic 2.7-4. I also tried using
> netscape to view and move around these pages and had no
> problem. If anyone would like to check this out also,
> please look at:
>
> http://www.bnl.gov
>
> Select the link for User Facilities
>
> From there Select the High Flux Beam reactor
>
> As soon as I load that page, the URL appears garbled in
> the viewing window at the top of the Mosaic screen. I
> can move forward from links on that page, but not
> backwards. if I exit while on that page, Mosaic also
> crashes. Happy Hunting! Thanks.
The URL http://neutron.chm.bnl.gov/HFBR/ contains bad html code:
<HTML>
<HEAD>
<TITLE>The High Flux Beam Reactor homepage</TITLE>
<BASE HREF="àùûżdjU1·÷żdjU_">
<META NAME="GENERATOR" CONTENT="Internet Assistant for Word 2.0z Beta">
</HEAD>
...
I think the BASE HREF is not really what it should be.
---------------------------------------------------------------------------
Michael Zoellner
German Aerospace Research Establishment (DLR)
Institute of Flight Mechanics Tel. (+49) 531 / 295-2686
Postoffice Box 3267 Fax (+49) 531 / 295-2647
D-38022 Braunschweig eMail Michael.Zoellner@dlr.de
Germany
Return-path: <jhjennis2@mmm.com>
Date: Wed, 26 Feb 1997 07:50:41 -0500 (EST)
From: jhjennis2@mmm.com
Subject: Configuring Mosaic 2.7-5 for proxy server
To: vms-mosaic@hhs.dk
Cc: JENNIS@mdw.mmm.com
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Hi VMS-Mosaic Group!
A proxy server is being installed to screen outbound internet connections in our
organization. This is the first time we have used a proxy server, and so I am
unfamiliar with the configuration changes needed for Mosaic to use it. What are the
procedures involved in configuring Mosaic to use this proxy server? Thanks in advance
for any help/advice!
Thanks and best regards,
Jim Jennis, Sr. Manufacturing Specialist
Imation Corp.
Printing & Publishing Systems Div.
Manufacturing Systems/Networking/Internet Services
Middleway Plant
Middleway, WV. USA.
Internet: jhjennis2@mmm.com
Return-path: <eplan@kapsch.co.at>
Date: Wed, 26 Feb 1997 14:03:44 +0100
From: Peter LANGSTOEGER <eplan@kapsch.co.at>
Subject: RE: Configuring Mosaic 2.7-5 for proxy server
To: jhjennis2@mmm.com
Cc: vms-mosaic@hhs.dk, eplan@kapsch.co.at
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
>A proxy server is being installed to screen outbound internet connections in our
>organization. This is the first time we have used a proxy server, and so I am
>unfamiliar with the configuration changes needed for Mosaic to use it. What are the
>procedures involved in configuring Mosaic to use this proxy server? Thanks in advance
>for any help/advice!
Create with an editor a file MOSAIC_DIR:PROXY. which contains the line
http <your-proxy.internet.address> 8080 http
where 8080 is the port of your proxy server and (if required) another file
MOSAIC_DIR:NO_PROXY. with lines like
<your.local.domain.name> 80
<your.local.domain.name> 8000
to prevent using the proxy server for accessing your own webservers
(messages sent twice over your network instead of once and unneccessarily
occupying cache disk space on your caching proxy server).
Of course the same result can be achieved by using the pulldown menus of
mosaic (File - Proxy List... and File - No Proxy List...).
just my 0.02
Return-path: <jhjennis2@mmm.com>
Date: Mon, 03 Mar 1997 09:01:41 -0500 (EST)
From: jhjennis2@mmm.com
Subject: Some General Questions on Mosaic...
To: vms-mosaic@hhs.dk
Cc: JENNIS@mdw.mmm.com
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Greetings VMS-Mosaic Users!
Just a couple of general questions...It has been a long time
since we heard anything on the status of 2.8 Mosaic. Is NCSA
still actively working on this or is 2.8 dead?
I would very much like to stay with VMS-Mosaic, but the need
for table support (as well as other features like alignment)
is getting to be crucial. I'm hoping that Mosaic will be
adding these features and that 2.8 will be out soon.
In another vein...is there any documentation on interpretting
the output of the mosaic.x-history file (eg...what do the
appended numbers mean------------------------|
|
V
http://cigno.mmm.com/images/3mlogo.gif 857378062
http://cigno.mmm.com/images/newyel.gif 857302121
http://cigno.mmm.com/images/caribou2.gif 857123132
http://cigno.mmm.com/demo/nagel23a.html 857211882
http://cigno.mmm.com/demo/nagel23a.gif 855668154
Can a date/time of the url access be extracted from this?
Thanks and best regards,
Jim Jennis, Sr. Manufacturing Specialist
Imation Corp.
Printing & Publishing Systems Div.
Manufacturing Systems/Networking/Internet Services
Middleway Plant
Middleway, WV. USA.
Internet: jhjennis2@mmm.com
Return-path: <u.desilva@mdx.ac.uk>
Date: Mon, 03 Mar 1997 18:38:08 +0000 (GMT)
From: "Uditha DeSilva, VMS Team" <u.desilva@mdx.ac.uk>
Subject: Re: Some General Questions on Mosaic...
To: jhjennis2@mmm.com
Cc: u.desilva@mdx.ac.uk, vms-mosaic@hhs.dk, JENNIS@mdw.mmm.com,
VMS-MOSAIC-EXPAND@ko.hhs.dk
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
On Mon, 3 Mar 1997 jhjennis2@mmm.com wrote:
> In another vein...is there any documentation on interpretting
> the output of the mosaic.x-history file (eg...what do the
> appended numbers mean------------------------|
> |
> V
> http://cigno.mmm.com/images/3mlogo.gif 857378062
> http://cigno.mmm.com/images/newyel.gif 857302121
> http://cigno.mmm.com/images/caribou2.gif 857123132
> http://cigno.mmm.com/demo/nagel23a.html 857211882
> http://cigno.mmm.com/demo/nagel23a.gif 855668154
>
> Can a date/time of the url access be extracted from this?
>
> Thanks and best regards,
>
> Jim Jennis, Sr. Manufacturing Specialist
It looks like a 'unix' time stamp to me. eg
perl -le "print scalar localtime(857378062)"
gives me
Mon Mar 3 08:34:22 1997
-- ie time of last access?
Uditha De Silva - VMS & Unix systems team
Computing Services, Middlesex University, London, England
u.desilva@mdx.ac.uk http://www.mdx.ac.uk/~uditha1 +44 181 362 5760
Return-path: <adye@v2.rl.ac.uk>
Date: Tue, 04 Mar 1997 00:27:08 +0000 (GMT)
From: adye@v2.rl.ac.uk (Tim Adye: RAL x6632, Oxford x73396, CERN x2103)
Subject: Upgraded hotlist crash
To: vms-mosaic@hhs.dk
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Hi,
Thanks to George for providing such a rapid fix to my remote control
bug. I'm afraid I've found another small bug in VMS Mosaic 2.7-5.
This one wasn't present in 2.7-4.
It manifests itself when one upgrades straight from a very old version
(2.4 or before) and Mosaic kindly converts one's hotlist from
ncsa-xmosaic-hotlist-format-1 to 3. Although the newly created file is
in ncsa-xmosaic-hotlist-format-3 (as it should be), it is saved in a
file named MOSAIC-HOTLIST-DEFAULT.HTML (where one would expect a
format-2 hotlist). The hotlist is displayed OK in Mosaic, but if one
selects the first entry, then it crashes with:-
assert error: expression = set_state == XmxSet || set_state == XmxUnset,
in file MOSAIC_ROOT:[MOSAIC2_7-5.LIBXMX]XMX.C;1 at line 453
%SYSTEM-F-OPCCUS, opcode reserved to customer fault at PC=8099457C, PS=0000001B
followed by a register dump.
If instead of trying to use this fatal hotlink, Mosaic is exited and
then restarted, then MOSAIC-HOT.HTML is finally created. The only
unexpected feature that remains (apart from the spurious
MOSAIC-HOTLIST-DEFAULT.HTML file) is that that first hotlink is already
added to the RMB menu.
Any ideas?
Thanks,
Tim.
PS. In case you no longer have any very old versions of Mosaic or their
hotlists, here is an example format-1 hotlist that can be used to
provoke the error. It should go into MOSAIC.HOTLIST-DEFAULT. Remember to
move MOSAIC-HOT.HTML and MOSAIC-HOTLIST-DEFAULT.HTML out of the way,
otherwise Mosaic 2.7-5 will see them first.
============================== cut here ==============================
ncsa-xmosaic-hotlist-format-1
Default
http://hepwww.rl.ac.uk/ Mon Mar 3 23:34:26 1997
Particle Physics Department at RAL
http://hepwww.rl.ac.uk/ukhep.html Mon Mar 3 23:34:42 1997
Particle Physics within the United Kingdom
http://www1.cern.ch/NormalWelcome.html Mon Mar 3 23:34:59 1997
CERN Welcome
============================== cut here ==============================
Tim Adye, DELPHI/BaBar Groups, Particle Physics Dept., _ /|
Rutherford Appleton Laboratory, UK. \'o.O' Oop!
e-mail: T.J.Adye@rl.ac.uk or VXCERN::ADYE (HEPNET/SPAN) =(___)= Ack!
WWW: http://hepwww.rl.ac.uk/Delphi/Adye/homepage.html U Thphft!
Return-path: <spowers@shire.ncsa.uiuc.edu>
Date: Tue, 04 Mar 1997 01:49:52 -0600 (CST)
From: Scott Powers <spowers@shire.ncsa.uiuc.edu>
Subject: Re: Reporting bugs in 2.7b5
To: JLAURET@nucax1.chem.sunysb.edu (Jerome LAURET)
Cc: vms-mosaic@hhs.dk
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7bit
In 2.7b6 (see my latest post on 2.7b6) the hotlist crashing stuff has been
nixed (as far as I can tell). The bug below was definitely fixed.
Scott
Jerome LAURET randomly punched a keyboard and produced:
>
>
>
> Well, before it's too late and he 2.7b6 gets released, may this bug can
> be fixed :
>
>
> I]
>
> The bottom of this Email is a crash a user did produced (I could
> reproduced) doing the following :
> 1) Open the Hotlist
> 2) Create a new list/path to store adresses in (ex: Test)
> 2) Do a copy on an old existing list (ex: Old)
> 3) Click on Insert inside the new one
> 4) Double click on -> Test
> Double click on -> Old
>
> and BANG ! (see below)
>
>
> II]
>
> Second problem : I open the 2.7-5on an Xterminal. The font
> -adobe-times-bold-r-normal-*-24-*-*-*-*-*-iso8859-1 is not available on the
> Xserver running on the NCD Xterminal. So I use in MOSAIC.DAT
> Mosaic*Header1Font: -adobe-times-bold-r-normal-*-25-*-*-*-*-*-iso8859-1
>
> But when I open mosaic, I get the message :
> Load Font Error
> Could not open font '-adobe-times-bold-r-normal-*-24-*-*-*-*-*-*-*'.
> Using fixed instead.
>
> and the Header1 are not displayed as it should (using the fixed font)
> regardless of what I have in the resource file.
>
>
> BTW: I am using DEC C V5.3-006 on OpenVMS Alpha V6.1 .
>
>
>
>
> ----------------------------------------------------------------------------
> [...]
> CC:
> Subj: mosaic
>
> assert error: expression = set_state == XmxSet || set_state == XmxUnset, in file STELL_USER1:[JLA
> URET.APPS_DEV.MOSAIC.LIBXMX]XMX.C;1 at line 453
>
> Improperly handled condition, image exit forced.
> Signal arguments: Number = 00000003
> Name = 00000434
> 80594C4C
> 0000001B
>
> Register dump:
> R0 = 0000000000000001 R1 = 0000000000000001 R2 = 000000007FE6CBF8
> R3 = FFFFFFFFFFFFFFFE R4 = 0000000000000434 R5 = 0000000000000000
> R6 = 0000000000000000 R7 = 0000000000B065F8 R8 = 000000000000001A
> R9 = 0000000000000000 R10 = 0000000000000001 R11 = 0000000000000002
> R12 = 000000000000001E R13 = 000000000000000B R14 = 0000000000000000
> R15 = 0000000000AA8B48 R16 = 0000000000000434 R17 = 0000000000000000
> R18 = 0000000000000000 R19 = FFFFFFFFFFFFFFFF R20 = 0000000000000000
> R21 = 0000000000000000 R22 = 0000000000000000 R23 = FFFFFFFFFFFFFF79
> R24 = 0000000000000040 R25 = 0000000000000001 R26 = FFFFFFFF80594C4C
> R27 = 000000007FB623B0 R28 = 300000000000001B R29 = 000000007F949070
> SP = 000000007F949070 PC = FFFFFFFF80594C4C PS = 300000000000001B
>
>
>
>
> Jerome LAURET S.U.N.Y. @ Stony Brook
> ,,,,, Dept. of Chemistry
> ( o o ) Stony Brook NY 11794-3400
> ---m---U---m---------------------------------------------
> E-mail: jlauret@sbchem.chem.sunysb.edu
> URL : http://nucwww.chem.sunysb.edu/people/jlauret.html
>
--
O- Scott W. Powers <*>| "You've been talking to Garibaldi again,
NCSA-SDD Vis Group Lead | haven't you?"
http://shire.ncsa.uiuc.edu/ | -- Delenn and Sinclair, "The Gathering"
Return-path: <spowers@shire.ncsa.uiuc.edu>
Date: Tue, 04 Mar 1997 01:53:14 -0600 (CST)
From: Scott Powers <spowers@shire.ncsa.uiuc.edu>
Subject: Re: Future of Mosaic/VMS browser?
To: COOK@wvnvaxa.wvnet.edu (George Cook)
Cc: zinser@eur.sas.com, COOK@wvnvaxa.wvnet.edu, vms-mosaic@hhs.dk
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7bit
George Cook randomly punched a keyboard and produced:
>
> >>3. Look at porting some other browser like Chimera to VMS.
>
> > Where to get this (for Unix I guess)?
>
> Yes, only for Unix currently. The Chimera home page is
> http://www.unlv.edu/chimera/
>
> It uses the Athena widget set instead of Motif and uses Perl scripts for
> stuff like MAILTO: and NEWS:
>
> The comments I've heard about it seem positive, but I have never seen
> it run since I don't have access to a Unix platform. The need for Perl
> is negative in that Perl for VMS (besides being a large package) is not
> easy to install particularly when socket support is required.
>
Also, the latest version has a completely new HTML widget (it was originally
based on the X/Mosaic HTML widget). It has a ways to go before becoming a
solid usable browser (as far as functionality goes), but the formatting is
fairly good and HTML 3.2 support is there for the most part.
Scott
--
O- Scott W. Powers <*>| "This is Lieutenant Commander Laurel
NCSA-SDD Vis Group Lead | Takeshima. ... Babylon 5 is open for
http://shire.ncsa.uiuc.edu/ | business." -- Laurel Takeshima, "tG"
Return-path: <spowers@shire.ncsa.uiuc.edu>
Date: Tue, 04 Mar 1997 02:26:01 -0600 (CST)
From: Scott Powers <spowers@shire.ncsa.uiuc.edu>
Subject: 2.7b6 and assorted info
To: vms-mosaic@hhs.dk (VMS Mailing List)
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7bit
2.7b6 will make it out soon...the definition of when "soon" is, however, is
still very much up in the air. The "xmosaic group" has essentially been
dissolved and I am the only one still working on the 2.7 source base. This is
done completely on my own time as I now lead the Visualization group. Under
this group the xmosaic developers also moved. The current project of the
ex-xmosaic group is "Hyperion" which is a cross-platform C++ framework
(coming along very nicely). There is the possibility that a couple of us might
put out a completely new browser under the Hyperion framework this summer.
Unforunately, unless the availability of C++ becomes much, much greater it
does not look good for a VMS port of Hyperion. I have a few contacts of people
at DEC and hope to convince them of the incredible benefits of providing this
framework for VMS (any app written under Hyperion simply needs to be compiled
under VMS...no porting)...but I'm not holding my breath.
...just to be clear, I'm working on getting 2.7b6 out, but it depends
completely on there being free time for me to do this...which as of late has
been less and less due to a couple of Vis deadlines.
I have looked into merging mMosaic into the current source base and I can tell
you flat out it would be near impossible. There were many, many changes
between 2.7b4 and the current code base, not to mention that whenever the
mMosaic developers came across something they thought frivolous, they simply
deleted it. No kiosk mode, no VMS patches, and a lot of other stuff that has
been changed which was required to make other parts of the code work. They
pretty much rewrote the parser/formatter to be multi-pass and from what I saw
I have my doubts as to whether it will ever be stable. It would have been
better to simply start over...too many hacks (what would be the name analagous
with "too many secrets"?). Note this is not a slam on the mMosaic developers,
there were some things they didn't fully understand as far as src tree
dependencies as well as the removal of entire functionalities of Mosaic (which
is unacceptable according to the people above me).
The 2.8alpha code is also officially "dropped". That source code still belongs
to the U of I and is under copyright stuff, but so is Mosaic 2.7...same
copyright stuff. I would, however, discourage anyone from basing new work on
the 2.8alpha tree...we were about to scratch the majority and start over
because there were some fundamental flaws in the network/gui/message model.
I know none of this is news you want to hear and I'm sorry I have to be the
bearer of said news. I will, of course, pop over and read this list from time
to time and would be more than willing to lend a hand in any development you
all decide to do.
George has essentially told me that GNU C++ is not going to move forward
anytime in the next decade, so it would appear the only hope for a Hyperion
port lies in DECs hands...unless there can be a fire lit somewhere at GNU.
Scott
--
O- Scott W. Powers <*>| "Commander, there's a problem."
NCSA-SDD Vis Group Lead | -- Ivanova, "Midnight on the Firing
http://shire.ncsa.uiuc.edu/ | Line"
Return-path: <SCHUMAN@bnlstb.bio.bnl.gov>
Date: Tue, 11 Mar 1997 11:26:33 -0500 (EST)
From: SCHUMAN@bnlstb.bio.bnl.gov
Subject: URL interpretation question
To: vms-mosaic@hhs.dk
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Hi Mosaic users,
I used my VMS mailer to include an html file and
sent it to a different server manager for inclusion at
that site. The mailer added returns to the wrapped
lines. When I view the file using netscape, all works
fine, but when using the VMS mosaic, the lines with
split URLs do not work (they are shortened to where
the
cr is placed and do not read the next line to include
the full URL, or to the ending > of the request). The
question is...Is there some way to readily prevent
this
behavior with options or somewhere else. I have tried
modifying the mosaic.dat files in my root and in the
system area and do not see that the program responds
to
the mods in any way even though the logicals point to
the right places.
Thanks for any insight...
Gail I. Schuman
Brookhaven National Laboratory
Biology Dept
schuman1@bnl.gov
System Info:
VAXstation 4000/90 VMS 5.5-2 Mosaic 2.7-4 OSU 1.9a
Return-path: <jhjennis2@mmm.com>
Date: Thu, 13 Mar 1997 06:40:25 -0500 (EST)
From: jhjennis2@mmm.com
Subject: Allocation of Colormap entries in Mosaic
To: vms-mosaic@hhs.dk
Cc: JENNIS@mdw.mmm.com
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Greetings Mosaic Users!
Perhaps this question relates more to X-Windows itself than
Mosaic, but since the problem manifests itself with Mosaic,
and there are many Xperts (please excuse the pun) on this
list, I will ask it here.
I am running VMS Mosaic on our production floor on NCD X-terms
that also run a custom application (written in XVT) on a unix
box. I am using the NCD's local window manager and not
starting up an full blown XDM session with either my Alpha or
the Unix box. Both Mosaic and the Unix app are initiated by a
normal telnet session to either machine.
If I start up Mosaic before starting up the XVT application
all is well. However, if I start the XVT unix app first and
then log into my Alpha and start Mosaic, I get a series of
errors about colors/colormap entries that cannot be allocated.
Mosaic then starts up, but will not display some of the
colored text in html files. This is unfortunate since one of
the colors it chooses not to display is the dark blue default
color for followed links.
Has anyone else experienced this problem? If so, is there a
fix (other than always starting Mosaic as the first
application)?
Thanks and best regards,
Jim Jennis, Sr. Manufacturing Specialist
Imation Corp.
Printing & Publishing Systems Div.
Manufacturing Systems/Networking/Internet Services
Middleway Plant
Middleway, WV. USA.
Internet: jhjennis2@mmm.com
Return-path: <COOK@wvnvaxa.wvnet.edu>
Date: Mon, 17 Mar 1997 02:05:48 -0500 (EST)
From: George Cook <COOK@wvnvaxa.wvnet.edu>
Subject: Re: Allocation of Colormap entries in Mosaic
To: jhjennis2@mmm.com
Cc: vms-mosaic@hhs.dk, COOK@wvnvaxa.wvnet.edu
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
>Perhaps this question relates more to X-Windows itself than
>Mosaic, but since the problem manifests itself with Mosaic,
>and there are many Xperts (please excuse the pun) on this
>list, I will ask it here.
>I am running VMS Mosaic on our production floor on NCD X-terms
>that also run a custom application (written in XVT) on a unix
>box. I am using the NCD's local window manager and not
>starting up an full blown XDM session with either my Alpha or
>the Unix box. Both Mosaic and the Unix app are initiated by a
>normal telnet session to either machine.
>If I start up Mosaic before starting up the XVT application
>all is well. However, if I start the XVT unix app first and
>then log into my Alpha and start Mosaic, I get a series of
>errors about colors/colormap entries that cannot be allocated.
>Mosaic then starts up, but will not display some of the
>colored text in html files. This is unfortunate since one of
>the colors it chooses not to display is the dark blue default
>color for followed links.
You can try starting Mosaic with the -install (/install) option
which will give it its own color map, however the other application
will likely be unviewable whenever Mosaic has focus.
George
Return-path: <COOK@wvnvaxa.wvnet.edu>
Date: Mon, 17 Mar 1997 02:12:51 -0500 (EST)
From: George Cook <COOK@wvnvaxa.wvnet.edu>
Subject: Re: URL interpretation question
To: SCHUMAN@bnlstb.bio.bnl.gov
Cc: vms-mosaic@hhs.dk, COOK@wvnvaxa.wvnet.edu
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Is the problem related to the incorrect wrapping in your message to the
list (i.e., why did your mailer wrap the three lines which are incorrectly
wrapped below?)?
> I used my VMS mailer to include an html file and
> sent it to a different server manager for inclusion at
> that site. The mailer added returns to the wrapped
> lines. When I view the file using netscape, all works
> fine, but when using the VMS mosaic, the lines with
> split URLs do not work (they are shortened to where
>the
> cr is placed and do not read the next line to include
> the full URL, or to the ending > of the request). The
> question is...Is there some way to readily prevent
>this
> behavior with options or somewhere else. I have tried
> modifying the mosaic.dat files in my root and in the
> system area and do not see that the program responds
>to
> the mods in any way even though the logicals point to
> the right places.
What mods were you trying to make to mosaic.dat?
> System Info:
> VAXstation 4000/90 VMS 5.5-2 Mosaic 2.7-4 OSU 1.9a
My first suggestion would be to upgrade to 2.7-5.
George
Return-path: <spowers@shire.ncsa.uiuc.edu>
Date: Fri, 21 Mar 1997 17:32:16 -0700
From: d_zabarah@urquel.cxo.dec.com (DudeTTe)
Subject: Mosaic AccVio
Sender: spowers@shire.ncsa.uiuc.edu
To: mosaic-x@ncsa.uiuc.edu
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
After upgrading my vax4000-VLC from V7.0 of OpenVMS to V7.1, attempts
to bring up MOSAIC report:
Congratulations, you have found a bug in
NCSA Mosaic 2.7b3A on OpenVMS.
Please, try to take note of *exactly* what happened in full detail and
the details of the Access Violation or other information
and mail the results, and a description of what you were doing at the time,
to mosaic-x@ncsa.uiuc.edu. We thank you for your support.
Remaining page file quota 193191, maximum virtual size 200000
Caught signal 11
...exiting NCSA Mosaic now.
%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=FF20DB3C, PC
=000DBF8A, PSL=03C00008
%TRACE-F-TRACEBACK, symbolic stack dump follows
module name routine name line rel PC abs PC
PIXMAPS FindIconColor 36057 0000013A 000DBF8A
PIXMAPS PixmapFromData 36192 00000166 000DC1BA
PIXMAPS LoadSplashXPM 36443 000000C9 000DC9A9
GUI mo_do_gui 36780 00000489 000B883D
MAIN main 25251 00000084 000B2424
What to do???
-Dinah Zabarah
DIGITAL CSC
Return-path: <jhjennis2@mmm.com>
Date: Mon, 24 Mar 1997 08:54:29 -0500 (EST)
From: jhjennis2@mmm.com
Subject: Future of Mosaic
To: vms-mosaic@hhs.dk
Cc: JENNIS@mdw.mmm.com
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Hi VMS-Mosaic Users!
I have just heard (maybe I am "behind the times) that NCSA has officially
dropped plans for further Mosaic Development on all platforms.
If this is true, then I am wondering about the future of web browsers in
general and those for OpenVMS in particular.
I have been using VMS-Mosaic since version 2.0 and have always found it to
be a significant advantage to be able to have a browser with the source
code available. Mosaic is and has been a program with many features that
give it significant advantages over Notscape or "Bill's Browser".
If Mosaic development is terminated by NCSA...and the development of other
WEB browsers for OpenVMS takes the typical course, IMHO it is just another
"nail in the coffin" for OpenVMS as a viable and flourishing platform for
WWW and X-Windows. This would be a real tragedy. Despite all the claims,
hype, etc for Unix and NT, in more than 20 yrs
developing/deploying/managing/running 7X24X365 manufacturing information
systems, I have never found an OS which can provide the same combination of
performance, reliability, ease of maintenance/use/support as OpenVMS (just
for the record...I have 3 flavors of unix and NT here also, so I am
speaking from experience --- not just some prejudice or sentimental
preference for OpenVMS!)
I am curious as to what other OpenVMS people think/feel we should do about
this situation? Surely we cannot sit back and just let it die??? (or should
I start porting to unix/NT immediately?)
Regards,
Jim Jennis, Sr. Manufacturing Specialist
Imation Corp.
Printing & Publishing Systems
Manufacturing Systems/Networking/Internet Services
Middleway Plant
Middleway, WV. USA.
Internet: jhjennis2@mmm.com
Return-path: <COOK@wvnvaxa.wvnet.edu>
Date: Tue, 25 Mar 1997 05:13:59 -0500 (EST)
From: George Cook <COOK@wvnvaxa.wvnet.edu>
Subject: Re: Future of Mosaic
To: jhjennis2@mmm.com
Cc: vms-mosaic@hhs.dk, COOK@wvnvaxa.wvnet.edu
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
>I have just heard (maybe I am "behind the times) that NCSA has officially
>dropped plans for further Mosaic Development on all platforms.
NCSA Mosaic development is basically dead. I plan to get the final
releases (2.7b6 and 2.7) ported when/if they are ever released, but
they will have very little in the way of new functionality.
>If this is true, then I am wondering about the future of web browsers in
>general and those for OpenVMS in particular.
The future looks fairly poor for having a graphical browser with full
sources available on OpenVMS. It does look like Digital plans to keep
new releases of Netscape on OpenVMS, but Netscape comes without sources.
The main problem with porting some other browser to VMS is deciding which
one to port. Pick the wrong one and it becomes, in a year or two, just
another deadend (with a lot of wasted effort) like NCSA Mosaic. Most
of the other browsers available with source are primarily supported by
just one or two people; if they move on, then the browser dies. At this
point, Chimera looks like the best bet for porting, but I have never
seen it in action (I have no way of running UNIX browsers).
Unfortunately, the one source code browser, Lynx, which does have full
VMS support and a good support team is non-graphical (in fact Lynx is
the browser I use at least 95% of the time).
George
Return-path: <zinser@eur.sas.com>
Date: Tue, 25 Mar 1997 14:54:09 +0000 (MET-1MET)
From: "Martin P.J. Zinser, SAS Europe" <zinser@eur.sas.com>
Subject: Re: Future of Mosaic
To: vms-mosaic@hhs.dk
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Hello!
George has an excellent point here. If there would be a strong
sucessor to Mosaic everything would be (more or less) fine.
The problem I see currently is that the X/Motif community
does not yet have made up their minds on where to concentrate
on (besides of Explorer bashing, which is a good thing, but
unfortunatly not very productive ;-).
My best bet would be arena at the moment, because it is
GPL'd and under active development by an organized group.
Greetings, Martin
Return-path: <u.desilva@mdx.ac.uk>
Date: Tue, 25 Mar 1997 14:19:58 +0000 (GMT)
From: "Uditha DeSilva, VMS Team" <u.desilva@mdx.ac.uk>
Subject: Re: Future of Mosaic
To: "Martin P.J. Zinser, SAS Europe" <zinser@eur.sas.com>
Cc: vms-mosaic@hhs.dk
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
On Tue, 25 Mar 1997, Martin P.J. Zinser, SAS Europe wrote:
> My best bet would be arena at the moment, because it is
> GPL'd and under active development by an organized group.
>
> Greetings, Martin
Erm, isn't it Amaya that's now the W3C's chosen browser, with Arena being
dropped by them? or are you referring to Yggdrasil, who are now supposed
to be co-ordinating further work on Arena?
Uditha De Silva - VMS & Unix systems team
Computing Services, Middlesex University, London, England
u.desilva@mdx.ac.uk http://www.mdx.ac.uk/~uditha1 +44 181 362 5760
Return-path: <music@triumf.ca>
Date: Tue, 25 Mar 1997 08:06:06 -0800 (PST)
From: "Fred W. Bach, TRIUMF Operations" <music@triumf.ca>
Subject: Re: Future of Mosaic
To: COOK