INFO-VAX	Tue, 17 Apr 2007	Volume 2007 : Issue 212

   Contents:
64-bit: Intel Unveils New x86 Microarchitecture
Re: 64-bit: Intel Unveils New x86 Microarchitecture
Re: C++ Garbage Collector on VMS?
Re: C++ Garbage Collector on VMS?
Re: can you handle this?
Re: can you handle this?
Re: can you handle this?
Re: can you handle this?
Re: can you handle this?
Re: can you handle this?
Re: can you handle this?
Re: Error Checking in DCL using $severity
Re: Error Checking in DCL using $severity
Mozilla (CSWB) memory performance riddle.
Re: Now I've seen everything
Re: Now I've seen everything
Re: OT: 216 Billion Americans Squirrels Are Scientifically Illiterate (Part 36)
Re: OT: OpenVMS
Re: Problem with BACKUP/LIST/JOU/SINCE/SELECT
Re: Problem with BACKUP/LIST/JOU/SINCE/SELECT
Re: Problem with BACKUP/LIST/JOU/SINCE/SELECT
Re: Problem with BACKUP/LIST/JOU/SINCE/SELECT
Re: Problem with BACKUP/LIST/JOU/SINCE/SELECT
Re: Sun shows Rock first silicon
Re: Sun shows Rock first silicon
Re: Sun shows Rock first silicon
Re: Sun shows Rock first silicon
RE: Sun shows Rock first silicon
Re: Sun shows Rock first silicon
Re: TCPIP SMTP: suggestion
Re: VMS Alpha to Itanium port

----------------------------------------------------------------------

Date: Tue, 17 Apr 2007 06:39:36 -0400
From: "Neil Rieck" <n.rieck@sympatico.ca>
Subject: 64-bit: Intel Unveils New x86 Microarchitecture
Message-ID: <4624972a$0$16315$88260bb3@free.teranews.com>

64-bit: Intel Unveils New x86 Microarchitecture
http://www.ddj.com/dept/64bit/198701094?cid=RSSfeed_DDJ_All

Small Excerpt:

Intel on Wednesday introduced a new microarchitecture scheduled for 
production next year that stands to increase the performance gap Intel has 
with rival Advanced Micro Devices. Nehalem is the code name chosen for what 
Intel claims will be as big an architectural jump as the Pentium Pro when it 
was introduced in 1996, executives said at a San Francisco news conference. 
The new microarchitecture takes advantage of Intel's 45-nanometer production 
process, which enables the chipmaker to deliver two four-core processors in 
a single chipset. Currently, Intel offers a maximum of two dual-core 
processors in a single package.
    ###

Question: About 4 weeks ago I saw an article (which I can no longer find) 
claiming that Intel's Core design is more like a hyper-threaded Pentium-3 
since the P4 "net burst" stuff was removed.  Can anyone else comment on this 
statement one way or the other?

Neil Rieck
Kitchener/Waterloo/Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/links/cool_openvms.html
http://www3.sympatico.ca/n.rieck/links/openvms_demos.html






-- 
Posted via a free Usenet account from http://www.teranews.com

------------------------------

Date: Tue, 17 Apr 2007 07:31:57 -0400
From: Bill Todd <billtodd@metrocast.net>
Subject: Re: 64-bit: Intel Unveils New x86 Microarchitecture
Message-ID: <DrSdnVpW1umzLbnbnZ2dnUVZ_hmtnZ2d@metrocastcablevision.com>

Neil Rieck wrote:
> 64-bit: Intel Unveils New x86 Microarchitecture
> http://www.ddj.com/dept/64bit/198701094?cid=RSSfeed_DDJ_All
> 
> Small Excerpt:
> 
> Intel on Wednesday introduced a new microarchitecture scheduled for 
> production next year that stands to increase the performance gap Intel 
> has with rival Advanced Micro Devices. Nehalem is the code name chosen 
> for what Intel claims will be as big an architectural jump as the 
> Pentium Pro when it was introduced in 1996, executives said at a San 
> Francisco news conference. The new microarchitecture takes advantage of 
> Intel's 45-nanometer production process, which enables the chipmaker to 
> deliver two four-core processors in a single chipset. Currently, Intel 
> offers a maximum of two dual-core processors in a single package.
>    ###
> 
> Question: About 4 weeks ago I saw an article (which I can no longer 
> find) claiming that Intel's Core design is more like a hyper-threaded 
> Pentium-3 since the P4 "net burst" stuff was removed.  Can anyone else 
> comment on this statement one way or the other?

Yes:  both 'Core Duo' and 'Core 2 Duo' are outgrowths of Intel Haifa's 
Pentium M (mobile) architecture that appeared a few years ago (as 
Banias), which itself owed far more to Pentium III than to Pentium IV 
and its mutant Prescott 'Netburst' offspring (both of which increased 
pipeline lengths in pursuit of marketable MHz, the latter without 
question to the point of counter-productive returns).

AFAIK Nehalem (and Penryn before it) are both 45 nm. products in the 
same micro-architectural vein, the major difference between them being 
the advent of the HyperTransport-like 'common system interconnect' and 
on-chip memory controller and the return of hyperthreading, all of which 
are supposed to debut with Nehalem.  Intel's 45 nm. process also has 
some potentially important advances to boast about, but that has little 
to do with microarchitecture.

- bill

------------------------------

Date: Tue, 17 Apr 2007 09:55:03 +0000
From: Johann 'Myrkraverk' Oskarsson <myrkraverk@users.sourceforge.net>
Subject: Re: C++ Garbage Collector on VMS?
Message-ID: <m3fy6zba14.fsf@jin.myrkraverk.com>

David J. Dachtera <djesys...@spam.comcast.net> writes:

> I have to ask: Why does a programming language (other than an
> interpretive environment) need a "garbage collector"??!!

Maybe I'm implementing one in C++ and don't want to write my own
garbage collector?  Boehm GC, afaict, is very popular among such
projects.

I was sort of certain Boehm had already been ported to VMS, but as I
didn't find any mention of it in the sources, nor google, expept a
post here from 1995, I'm a bit lost as to how to proceed.

Johann

------------------------------

Date: 17 Apr 2007 07:48:55 -0500
From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)
Subject: Re: C++ Garbage Collector on VMS?
Message-ID: <2J5WjN5IRTbq@eisner.encompasserve.org>

In article <462434BB.B2A05EAD@spam.comcast.net>, David J Dachtera <djesys.no@spam.comcast.net> writes:
> 
> I have to ask: Why does a programming language (other than an interpretive
> environment) need a "garbage collector"??!!
> 

   As is painfully obvious to anyone who has used it, C++ generates
   a lot of garbage.

------------------------------

Date: 17 Apr 2007 07:00:54 -0500
From: clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley)
Subject: Re: can you handle this?
Message-ID: <MDPoAwtPiX16@eisner.encompasserve.org>

In article <6uqdnenvKtOay7nbnZ2dnUVZ_jydnZ2d@libcom.com>, Dave Froble <davef@tsoft-inc.com> writes:
> 
> Forget it Simon.  His mouth works, but his ears don't.
> 

Sadly, I've come to the same conclusion myself.

To answer Bill Todd's "why even try" question elsewhere, I've had some
quite interesting conversations with strongly religious people about their
viewpoints versus my own atheist and liberal viewpoints but unfortunately
Bob appears to be incapable (or simply afraid) to think about and explain
why he believes what he does.

Here ends my attempts at trying to communicate with him.

I think that any followups to this post should be in email as it's nothing
to do with COV - note that my email address in the From line has been
altered to protect against spambots.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world

------------------------------

Date: 17 Apr 2007 09:16:38 -0700
From: Andrew <andrew_harrison@symantec.com>
Subject: Re: can you handle this?
Message-ID: <1176826598.372799.131870@y5g2000hsa.googlegroups.com>

On 17 Apr, 13:00, clubley@remove_me.eisner.decus.org-Earth.UFP (Simon
Clubley) wrote:
> In article <6uqdnenvKtOay7nbnZ2dnUVZ_jydn...@libcom.com>, Dave Froble <d...@tsoft-inc.com> writes:
>
> > Forget it Simon.  His mouth works, but his ears don't.
>
> Sadly, I've come to the same conclusion myself.
>
> To answer Bill Todd's "why even try" question elsewhere, I've had some
> quite interesting conversations with strongly religious people about their
> viewpoints versus my own atheist and liberal viewpoints but unfortunately
> Bob appears to be incapable (or simply afraid) to think about and explain
> why he believes what he does.
>
> Here ends my attempts at trying to communicate with him.
>
> I think that any followups to this post should be in email as it's nothing
> to do with COV - note that my email address in the From line has been
> altered to protect against spambots.
>
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Microsoft: Bringing you 1980's technology to a 21st century world

Why not try phoning him. There is a number listed for a Robert
Cecluski outside Columbus Ohio where Instant Whip are based look it up
online.

Regards
Andrew

------------------------------

Date: 17 Apr 2007 11:37:07 -0500
From: clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley)
Subject: Re: can you handle this?
Message-ID: <GPxkzTE3wviT@eisner.encompasserve.org>

In article <1176826598.372799.131870@y5g2000hsa.googlegroups.com>, Andrew <andrew_harrison@symantec.com> writes:
> 
> Why not try phoning him. There is a number listed for a Robert
> Cecluski outside Columbus Ohio where Instant Whip are based look it up
> online.
> 

Because, like you, I am in the UK.

Besides, the idea of phoning someone up out of the blue to talk about this,
(especially if you are not sure that you have the right person), feels
weird. :-)

So, thanks for the suggestion, but no thanks - he's not worth the effort.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world

------------------------------

Date: 17 Apr 2007 10:06:36 -0700
From: genius@marblecliff.com
Subject: Re: can you handle this?
Message-ID: <1176829596.904408.263830@y5g2000hsa.googlegroups.com>

On Apr 17, 8:00 am, clubley@remove_me.eisner.decus.org-Earth.UFP
(Simon Clubley) wrote:
> In article <6uqdnenvKtOay7nbnZ2dnUVZ_jydn...@libcom.com>, Dave Froble <d...@tsoft-inc.com> writes:
>
> > Forget it Simon.  His mouth works, but his ears don't.
>
> Sadly, I've come to the same conclusion myself.
>
> To answer Bill Todd's "why even try" question elsewhere, I've had some
> quite interesting conversations with strongly religious people about their
> viewpoints versus my own atheist and liberal viewpoints but unfortunately
> Bob appears to be incapable (or simply afraid) to think about and explain
> why he believes what he does.
>
> Here ends my attempts at trying to communicate with him.
>
> I think that any followups to this post should be in email as it's nothing
> to do with COV - note that my email address in the From line has been
> altered to protect against spambots.
>
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Microsoft: Bringing you 1980's technology to a 21st century world

I am right here ... you do not need email ... why do you
insist on discussing things by email ... why not in the
open ... what are you hiding?

------------------------------

Date: 17 Apr 2007 10:07:38 -0700
From: genius@marblecliff.com
Subject: Re: can you handle this?
Message-ID: <1176829658.639833.220500@p77g2000hsh.googlegroups.com>

On Apr 17, 12:16 pm, Andrew <andrew_harri...@symantec.com> wrote:
> On 17 Apr, 13:00, clubley@remove_me.eisner.decus.org-Earth.UFP (Simon
>
>
>
>
>
> Clubley) wrote:
> > In article <6uqdnenvKtOay7nbnZ2dnUVZ_jydn...@libcom.com>, Dave Froble <d...@tsoft-inc.com> writes:
>
> > > Forget it Simon.  His mouth works, but his ears don't.
>
> > Sadly, I've come to the same conclusion myself.
>
> > To answer Bill Todd's "why even try" question elsewhere, I've had some
> > quite interesting conversations with strongly religious people about their
> > viewpoints versus my own atheist and liberal viewpoints but unfortunately
> > Bob appears to be incapable (or simply afraid) to think about and explain
> > why he believes what he does.
>
> > Here ends my attempts at trying to communicate with him.
>
> > I think that any followups to this post should be in email as it's nothing
> > to do with COV - note that my email address in the From line has been
> > altered to protect against spambots.
>
> > Simon.
>
> > --
> > Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> > Microsoft: Bringing you 1980's technology to a 21st century world
>
> Why not try phoning him. There is a number listed for a Robert
> Cecluski outside Columbus Ohio where Instant Whip are based look it up
> online.
>
> Regards
> Andrew- Hide quoted text -
>
> - Show quoted text -

sorry Andrew ... that is an old number ... new one is
unlisted ...

------------------------------

Date: 17 Apr 2007 10:09:09 -0700
From: genius@marblecliff.com
Subject: Re: can you handle this?
Message-ID: <1176829749.232618.16490@n59g2000hsh.googlegroups.com>

On Apr 17, 12:37 pm, clubley@remove_me.eisner.decus.org-Earth.UFP
(Simon Clubley) wrote:
> In article <1176826598.372799.131...@y5g2000hsa.googlegroups.com>, Andrew <andrew_harri...@symantec.com> writes:
>
>
>
> > Why not try phoning him. There is a number listed for a Robert
> > Cecluski outside Columbus Ohio where Instant Whip are based look it up
> > online.
>
> Because, like you, I am in the UK.
>
> Besides, the idea of phoning someone up out of the blue to talk about this,
> (especially if you are not sure that you have the right person), feels
> weird. :-)
>
> So, thanks for the suggestion, but no thanks - he's not worth the effort.
>
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Microsoft: Bringing you 1980's technology to a 21st century world

I am already saved ... I do not need no effort ... you are the one
who should be worried when you die and stand at your judgement
if you are an atheist ...

------------------------------

Date: 17 Apr 2007 12:16:04 -0500
From: clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley)
Subject: Re: can you handle this?
Message-ID: <svEfndHzHN3T@eisner.encompasserve.org>

In article <1176829596.904408.263830@y5g2000hsa.googlegroups.com>, genius@marblecliff.com writes:
> 
> I am right here ... you do not need email ... why do you
> insist on discussing things by email ... why not in the
> open ... what are you hiding?
> 

I am not hiding anything, and I do discuss these matters elsewhere.

However, what you obviously fail to grasp is that this is not the right
place for such a discussion because this newsgroup is about VMS.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world

------------------------------

Date: 17 Apr 2007 07:45:04 -0500
From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)
Subject: Re: Error Checking in DCL using $severity
Message-ID: <MVeCRlg4tOHC@eisner.encompasserve.org>

In article <1af7c$4623f160$cef8887a$556@TEKSAVVY.COM>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> Steven M. Schweda wrote:
>>    I'd bet that this stuff is also covered in the C RTL documentation. 
>> Where's the mystery?
> 
> Because it used to be possible to exit with a status of 0 (probably with 
> vaxC).

   It used to be so in DEC C, too.  And it is possible now, if you
   tell it not to mess with your exit status, such as by calling
   sys$exit(), or simply _exit(), instead of exit().

------------------------------

Date: 17 Apr 2007 09:59:32 -0500
From: wb8tyw@qsl.network (John E. Malmberg)
Subject: Re: Error Checking in DCL using $severity
Message-ID: <Fpi4WmylT9ws@eisner.encompasserve.org>

In article <58ifglF2hdnqjU2@mid.individual.net>, Ken Fairfield <Ken@Napili.Fairfield.Home> writes:
> Steven M. Schweda wrote:
>> From: JF Mezei <jfmezei.spamnot@vaxination.ca>
>>
>>> Because it used to be possible to exit with a status of 0 (probably with
>>> vaxC).
>>
>> alp $ type ets.c
>> #include <starlet.h>
>>
>> main()
>> {
>>     sys$exit( 0);
>
> Calling sys$exit with zero as its argument is far different
> then using "return 0;".  In the latter case, the CRTL can
> fix-up the return value to set $STATUS to 1.  In the former
> case, I'd be very surprised, indeed, unhappy if I told
> sys$exit a value that *didn't* get reflected in $STATUS...

I covered this at last years boot camp, and probably with some examples
posted here.

From C or C++, If you are passing a VMS status code, then you need to
take the default settings for the C or C++ compiler and /DEFINE options
for the exit command.

>> }
>>
>> alp $ cc ets
>> alp $ link ets
>> alp $ r ets
>> %NONAME-W-NOMSG, Message number 00000000
>>
>>
>>    It's not entirely obvious to me why any rational person would prefer
>> this behavior.
>>
>>> [...]  How much UNIX
>>> incompatibility would you like?
>>
>>    Still waiting ...

If you want to pass UNIX exit status codes of 0 to 255 and want them to be
understood properly by BASH, DCL, MMS, MMK, make, perl and just about every
other script or program that will call them, then you have to set some
non-default options.

If you have a 7.x compiler, then in addition to some other steps below, you can
use the /MAIN=POSIX_EXIT qualifier to make sure that exit code is properly
translated.

If you have an earlier compiler, then you must make sure that the main()
function explicitly calls exit(x) instead of return.

You also need to make sure that the header file containing the exit()
function prototype is included, and that /DEFINE=_POSIX_EXIT is set. (check
spelling on that because I did not :-).

This will cause the 0 to 255 UNIX status codes to be encoded into a range of
VMS exit codes that are reserved for that purpose.

0 becomes mapped to SS$_NORMAL.  1 Becomes mapped to a code that has an ERROR
severity that can be trapped by DCL (from memory).  2 through 255 are mapped to
codes that have success severity.

This means that VMS programs like DCL and MMS will work properly with UNIX
programs that return 0 for success and 1 for failure.

When a C program spawns a child process and gets an exit status from the child
that is one of the reserved range of status codes, it transparently decodes the
value back into the original code of 0 to 255.

The severity value is ignored, so if you can look up the range of the codes,
you can manually generated them with special severity statuses to make the
probram fully usuable from both DCL/MMS/MMK and bash/make.

Not translating the UNIX codes, (default behavior) will cause problems with
native VMS programs like DCL, MMK, and MMS.

-John
wb8tyw@qsl.network
Personal Opinion Only

------------------------------

Date: 17 Apr 2007 09:42:30 -0700
From: Rambo <m_roguski@yahoo.com>
Subject: Mozilla (CSWB) memory performance riddle.
Message-ID: <1176828150.635400.22690@b75g2000hsg.googlegroups.com>

I'm playing with CSWB on my DEC2000 and AS600.

DEC2000 has EV4/150 and 128 (max) MB memory, AS600 has EV5/333 and 256
MB
on DEC2000 GBLSECTIONS is 1200, on AS600 I set it to 3000.

The installed VMS systems are nearly identical, with only difference
that there's DECwindows starting on AS600 (graphic option- DEC TGA-
supported). Running browser under SYSTEM login.

On DEC2000 i can browse how long I want and whatever pages I want,
on AS600 it breaks with EXQUOTA or "physical memory exhausted" within
two browsed pages...

Any clue why is that? Somehow I'm not buying DECwindows X server
abusing memory so much...

Rambo

------------------------------

Date: Tue, 17 Apr 2007 09:40:46 +0200
From: Marc Van Dyck <marc.vandyck@brutele.be>
Subject: Re: Now I've seen everything
Message-ID: <mn.8a447d746b0db786.30579@brutele.be>

David J Dachtera formulated on mardi :
> Neil Rieck wrote:
>> 
>> Last night on TLC the boys from American Chopper received a phone call
>> from HP. It seems that the boys down in Houston want to have an HP-
>> Themed chopper built for some such reason. Was it a set-up when Paul
>> Sr. smashed a working PC then stepped on it and found that it still
>> worked? I don't know but I now can die in peace because I have seen
>> everything.
>
> Well, not quite everything. You haven't seen:
>
> o A full-page ad in the mainstream media for anything running on or related 
> to OpenVMS-I64
>
> o An I64 SuperDome that can outperform an Alpha EV7z GS1280

Sorry to rain on your parade, Dave, but I think a Superdome with
Montecito CPUs does that fingers in the nose.

I have both (but not with Montecito CPUs yet), unfortunately not
on OpenVMS (which still runs on GS160 boxes and will hopefully be
upgraded to Itanium next year), the GS1280 on Tru64 Unix and the
Superdome on HP-UX, and I can tell you the Superdome can withstand
as much, if not more, punishment as the GS1280 does. And if we'll
ever upgrade to montecito, this will be no matter for discussion at all
anymore. You'll have to admit it some time, however marvelous ;-) it
was, the Alpha CPU is now a thing of the past.

For the two other parts of your reply, there I'll admit that you have
a point.

>
> o A lucid, reasonable post from Boob.

-- 
Marc Van Dyck

------------------------------

Date: Tue, 17 Apr 2007 06:01:08 -0400
From: "Neil Rieck" <n.rieck@sympatico.ca>
Subject: Re: Now I've seen everything
Message-ID: <46248e26$0$16410$88260bb3@free.teranews.com>

"David J Dachtera" <djesys.no@spam.comcast.net> wrote in message 
news:46243595.73FFD375@spam.comcast.net...
[...snip...]
>
> Well, not quite everything. You haven't seen:
>
> o A full-page ad in the mainstream media for anything running on or 
> related to
> OpenVMS-I64
>
> o An I64 SuperDome that can outperform an Alpha EV7z GS1280
>
> o A lucid, reasonable post from Boob.
>

Touché   :-)

p.s. I just remember another ridiculous moment: The boys from American 
Chopper riding a "Segway PT" up and down the halls of HP's main campus in 
Houston. Hey I just had a thought: Am I encouraging some HP marketing dweeb 
by even posting this stuff?

Neil Rieck
Kitchener/Waterloo/Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/ 


-- 
Posted via a free Usenet account from http://www.teranews.com

------------------------------

Date: 17 Apr 2007 08:30:06 -0700
From: Andrew <andrew_harrison@symantec.com>
Subject: Re: OT: 216 Billion Americans Squirrels Are Scientifically Illiterate (Part 36)
Message-ID: <1176823806.451009.101300@b58g2000hsg.googlegroups.com>

On 17 Apr, 10:42, "Dr. Dweeb" <s...@dweeb.net> wrote:
> Andrew wrote:
> > On 13 Apr, 21:07, "Dr. Dweeb" <s...@dweeb.net> wrote:
> >> Andrew wrote:
> >>> On 12 Apr, 23:40, "Dr. Dweeb" <s...@dweeb.net> wrote:
> >>>> Richard B. gilbert wrote:
> >>>>> Bob Koehler wrote:
> >>>>>> In article <461c1f3a$0$7608$157c6...@dreader2.cybercity.dk>, "Dr.
> >>>>>> Dweeb" <s...@dweeb.net> writes:
> >>>>>>> C02 is not a pollutant, particulate mass is, and the stuff that
> >>>>>>> comes out of diesel engines is nasty stuff.
>
> >>>>>>    As the Supreme Court just informed the White House and the
> >>>>>>    rest of us have known all along, CO2 is a polutant.
>
> >>>>> When you equip yourself with a pollution control system to
> >>>>> depollute your own exhalations, we might take you seriously!
>
> >>>> Someone has calculated the volume of CO2 exhaled by biological
> >>>> organisms, but I cannot bebothered to find it just now. It is of
> >>>> course substantial.
>
> >>> Of course thats screamingly obvious its all part of the carbon cycle
> >>> and its why we exist at all.
>
> >>>> Obviously, the screaming alarmists that pervade this board do not
> >>>> rate highly with me.
>
> >>> Clearly, its just a shame that you have failed to produce any
> >>> credible evidence to counter the "screaming alarmists" and since
> >>> this is the case one has to conclude that the "screaming alarmists"
> >>> arn't alarmist at all.
>
> >>>> I think CO2, technically, is from an atmospheric perspective a
> >>>> trace gas.
>
> >>> I am not quite sure what you intended by this comment but yes you
> >>> are correct CO2 only accounts for a very small % of our atmosphere.
> >>> Just in case your comment was intended to imply that because CO2 is
> >>> a trace gas that its effects cannot be anything like as severe as
> >>> people suggest let me remind you that even the anti-humans
> >>> activities causing global warming camp have had to conclude that
> >>> increased levels of CO2 will cause warming.
>
> >>> just so you have some number to play with rather than a rather vague
> >>> "trace" pre large scale industrialization the concentrations of CO2
> >>> in the atmosphere were around 280 ppm, this has now risen to about
> >>> 380 ppm. The IPPC report concludes that CO2 is likely to hit the
> >>> 650 - 800 ppm levels by 2100. Causing a 2-5 degree rise in average
> >>> global temperatures.
>
> >> Sadly I will not be here to see this event.  It's getting awarmer -
> >> adapt. As has been pointed out - the predictive capability of the
> >> models to which you refer is approximately zero, so relying on this
> >> prediction for anything other than entertainment is rather pointless.
>
> > I guess you don't have any offspring to worry about or if you do lets
> > hope that you die rich so that they can afford to adapt.
>
> I do have offspring.
>
> > Because the reality of climate change is that the rich will be able to
> > adapt to moderate climate change (unless your assets are mainly in
> > coastal property). The poor however and that includes the poor in the
> > US will not. A great example of this is New Orleans. What was striking
> > was that the faces of the people stranded there were mainly black and
> > that they were mainly from poor neighborhoods. They all heard the
> > calls to leave the City but lacking access to transportation and
> > lacking a place to go outside the City they chose to stay put. The
> > middle class all had access to good transportation and had no concerns
> > about finding somewhere to stay when they left the city and so they
> > got out while the going was good.
>
> This was not a AGW related event.  But I see your point
>

Actually there are a large number of reputable scientists who would
dispute this assertion as well. There is a strong correlation between
ocean surface temperature and wind strength not surprising since that
is how Hurricanes get their energy. The water temperature in the Gulf
of Mexico in the year that Katrina occurred was on average 2 degrees
higher than normal. Now you can argue about the causes of this rise
but GW is a very strong candidate.

What is in very little doubt is that environmental damage contributed
to the disaster. The Mississippi Delta is losing 50 acres a day due to
a combination of subsidence, new water channels, urban development and
farming. The wetlands act as a very effective buffer for storm surges
and had there been as much wetland as there was a decade ago between
the city and the Ocean then there is a good chance that the disaster
would have been averted. As it is smaller and smaller hurricanes are
likely to cause similar levels of damage to the City.

Ironically the George Bush Senior administration placed strong
controls in place to protect these wetlands, these controls were
bolstered by the Clinton administration but were then swept aside when
George Junior came into office in favor of development.

So your assumption that GW had no impact on Katrina is flawed.

Regards
Andrew Harrison

------------------------------

Date: 17 Apr 2007 07:55:44 -0700
From: AEF <spamsink2001@yahoo.com>
Subject: Re: OT: OpenVMS
Message-ID: <1176821744.250764.73040@l77g2000hsb.googlegroups.com>

I'm not replying to anyone in particular, "just" to the entire thread.

I posted an ON-TOPIC question about BACKUP/LIST/JOURNAL/SINCE and have
gotten only 3 responses. Here's your chance for some ON TOPIC
discussion. Can anyone please help?

Thanks!

AEF

------------------------------

Date: 17 Apr 2007 01:44:40 -0700
From: Dave Gullen <dave.gullen@gap.co.uk>
Subject: Re: Problem with BACKUP/LIST/JOU/SINCE/SELECT
Message-ID: <1176799480.366160.318540@d57g2000hsg.googlegroups.com>

The Bitmap files have been modified since creation.

------------------------------

Date: 17 Apr 2007 05:09:54 -0700
From: AEF <spamsink2001@yahoo.com>
Subject: Re: Problem with BACKUP/LIST/JOU/SINCE/SELECT
Message-ID: <1176811794.879682.224370@n76g2000hsh.googlegroups.com>

On Apr 16, 10:52 pm, David J Dachtera <djesys...@spam.comcast.net>
wrote:
> AEF wrote:
>
> > $ BACK/LIS/JOU=STOR-2007/SINC=1-APR-2007/SELE=BITMAP
> > Listing of BACKUP journal
> > Journal file SYS$SYSDEVICE:[FELDMAN.BACKUP]STOR-2007.BJL;1 on 16-
> > APR-2007 21:29:13.63
>
> > Save set STOR-070131.IMG created on 31-JAN-2007 10:12:32.08
> > Volume number 1, volume label STOR50
> >     [000000]BITMAP.SYS;1 file header only
>
> > Save set STOR-070302.IMG created on  2-MAR-2007 20:37:59.84
> > Volume number 1, volume label STOR50
> >     [000000]BITMAP.SYS;1 file header only
> > .
> > .
> > .
>
> > VMS V6.2
>
> > OK, what am I doing wrong? It works fine for /BEFORE, but seems to
> > completely ignore /SINCE.
>
> First guess time: BACKUP knows that BITMAP.SYS is part of the file system and
> saving restoring it ... actually, I dunno why I would want to do that.
>
> A little more background may be useful...
>
> --
> David J Dachtera
> dba DJE Systemshttp://www.djesys.com/
>
> Unofficial OpenVMS Marketing Home Pagehttp://www.djesys.com/vms/market/
>
> Unofficial Affordable OpenVMS Home Page:http://www.djesys.com/vms/soho/
>
> Unofficial OpenVMS-IA32 Home Page:http://www.djesys.com/vms/ia32/
>
> Unofficial OpenVMS Hobbyist Support Page:http://www.djesys.com/vms/support/- Hide quoted text -
>
> - Show quoted text -

I have a BACKUP journal file that consists of several save set
"listings". I want to extract the listing of just the latest one.
According to the docs, I should be able to use /SINC to select save
sets after the /SINCE date, but it only works for /BEFORE, which
doesn't help me.

AEF

------------------------------

Date: 17 Apr 2007 05:11:18 -0700
From: AEF <spamsink2001@yahoo.com>
Subject: Re: Problem with BACKUP/LIST/JOU/SINCE/SELECT
Message-ID: <1176811878.838550.131830@d57g2000hsg.googlegroups.com>

On Apr 16, 11:09 pm, David B Sneddon <dbsned...@bigpond.com> wrote:
> On Apr 16, 8:31 pm, "AEF" <spamsink2...@yahoo.com> wrote:
>
> > $ BACK/LIS/JOU=STOR-2007/SINC=1-APR-2007/SELE=BITMAP
> > Listing of BACKUP journal
> > Journal file SYS$SYSDEVICE:[FELDMAN.BACKUP]STOR-2007.BJL;1 on 16-
> > APR-2007 21:29:13.63
>
> > Save set STOR-070131.IMG created on 31-JAN-2007 10:12:32.08
> > Volume number 1, volume label STOR50
> >     [000000]BITMAP.SYS;1 file header only
>
> > Save set STOR-070302.IMG created on  2-MAR-2007 20:37:59.84
> > Volume number 1, volume label STOR50
> >     [000000]BITMAP.SYS;1 file header only
> > .
> > .
> > .
>
> > VMS V6.2
>
> > OK, what am I doing wrong? It works fine for /BEFORE, but seems to
> > completely ignore /SINCE.
>
> > Thanks!
>
> > AEF
>
> You are using /SINCE.  Which date field is BACKUP using
> for the comparison? You have not specified one.
>
> Dave

It doesn't matter. I tried it without and with all four possibilities
and it just doesn't work. I always get save sets both before and after
the specified date. /BEFORE works fine, but that doesn't help me as I
want to extract the listings for the latest save set.

------------------------------

Date: 17 Apr 2007 05:13:58 -0700
From: AEF <spamsink2001@yahoo.com>
Subject: Re: Problem with BACKUP/LIST/JOU/SINCE/SELECT
Message-ID: <1176812038.374242.294160@l77g2000hsb.googlegroups.com>

On Apr 17, 4:44 am, Dave Gullen <dave.gul...@gap.co.uk> wrote:
> The Bitmap files have been modified since creation.

Nope. You mean on the disk? That doesn't make any sense.

The BITMAP.SYS listed is from a save set made BEFORE the /SINCE date,
so at the time the save set was made, it couldn't have been modified
since the later date I specified. Right?

Anyway, the doc says the /SINCE and /BEFORE works on the SAVE SET
DATES, not the dates of the files listed. I don't think any of the
file dates are in the journal file anyway, so it can't be that.

AEF

------------------------------

Date: Tue, 17 Apr 2007 17:15:43 GMT
From: Rob Brown <mylastname@gmcl.com>
Subject: Re: Problem with BACKUP/LIST/JOU/SINCE/SELECT
Message-ID: <Pine.LNX.4.61.0704171112430.30178@localhost.localdomain>

On Mon, 16 Apr 2007, AEF wrote:

> $ BACK/LIS/JOU=STOR-2007/SINC=1-APR-2007/SELE=BITMAP
> Listing of BACKUP journal
> Journal file SYS$SYSDEVICE:[FELDMAN.BACKUP]STOR-2007.BJL;1 on 16-
> APR-2007 21:29:13.63
>
> Save set STOR-070131.IMG created on 31-JAN-2007 10:12:32.08
> Volume number 1, volume label STOR50
>    [000000]BITMAP.SYS;1 file header only
>
> Save set STOR-070302.IMG created on  2-MAR-2007 20:37:59.84
> Volume number 1, volume label STOR50
>    [000000]BITMAP.SYS;1 file header only
> .
> .
> .
>
> VMS V6.2
>
> OK, what am I doing wrong? It works fine for /BEFORE, but seems to 
> completely ignore /SINCE.

Dunno.  I had never thought to try this.  I always did

   $ BACKUP/JOU=journal.bjl/list=journal.lis

and then examined the list file in an editor.  Of course we were 
probably using V6.2 at the time.


-- 

Rob Brown                        b r o w n a t g m c l d o t c o m
G. Michaels Consulting Ltd.      (780)438-9343 (voice)
Edmonton                         (780)437-3367 (FAX)
                                  http://gmcl.com/

------------------------------

Date: Tue, 17 Apr 2007 01:59:13 -0400
From: Dave Froble <davef@tsoft-inc.com>
Subject: Re: Sun shows Rock first silicon
Message-ID: <EaOdneT2Z7p5_LnbnZ2dnUVZ_vfinZ2d@libcom.com>

Andrew wrote:
> On 15 Apr, 13:05, "Neil Rieck" <n.ri...@sympatico.ca> wrote:
>> "Andrew" <andrew_harri...@symantec.com> wrote in message
>>
>> news:1176470355.483306.114870@d57g2000hsg.googlegroups.com...
>>
>>
>>
>>> After quietly announcing 1.95Ghz and 2.1Ghz Dual Core UltraSPARC IV+
>>> modules Sun have show pictures of the first Rock Silicon along with a
>>> claim that these are working chips.
>>> http://www.theregister.co.uk/2007/04/10/sun_rock_schwartz/
>>> These announcements come at a good time for Sun after recent reports
>>> of delays to the release of Power 6 from IBM though  an expected early
>>> or on time delivery of Rock may weaken sales of the servers Sun has
>>> developed with Fujitsu which are due for release next week.
>>> Regards
>>> Andrew Harrison
>> Yikes! This thing has 16 cores. Here is an excerpt from Jonathon's Blog
>> (which also appears in the article)...
>>
>>     ###
>> "Rock is 16 cores - we haven't said how many threads per core. Nor have we
>> said why this chip heralds the golden age of effortless parallel
>> programming, or how it brings fault tolerance to the masses. But stay tuned,
>> I think we're planning on talking up both in the next few weeks."
>>
>> In the past, we've disclosed that Rock will run two threads per core, giving
>> it 32 threads per chip. In addition, the 256TB of memory described by
>> Schwartz would come via a 8-socket box that holds 512 DIMMs, depicted here.
>> Our sources have indicated that Sun stopped work on systems any larger than
>> the Platinum box.
>>
> 
> Sun have been pretty closed mouthed about the actual number of threads
> in each Rock core. One thing we do know is that each Rock thread has
> at least one scout thread which runs ahead of the hardware thread in
> essence warming up the cache for the thread itself. Scout threads are
> an interesting way of solving the prediction problem but how many
> there are in each Rock core is open to conjecture at this point.
> 
> It will be interesting if they only do an 8 module system, the
> implication being that Sun expect that 8 rock modules will provide
> enough throughput to cover the entirety of the current Sun range with
> increases in throughput beyond what the 144 core F25K can support
> today.
> 
>>     ###
>>
>> Like it or not, this is another proof of why it was dumb to kill Alpha and
>> then defer that problem to Intel ("hey, we want to be more like Dell"). At
>> the Canadian seminar I attended in February-2007 the HP people said that
>> Itanium won't go quad-core until 2009 (citing the lack of proper chip sets).
>> So now our favourite OS is running on a chip that won't go quad core until
>> 2009 while the chip's vendor has plans to improve x86-64 which HP has
>> decided not to port OpenVMS to (catch-22).
> 
> I am not sure you can read this into Sun's Rock announcements. If Rock
> proves to be the way to go it will also prove to be a fundamental
> shift in the way people develop cores. This would have been just a big
> a shock to an Alpha platform based on what Compaq were proposing with
> EV8 as it may prove to be to vendors developing servers based on
> Itanium.

EV8 was to be one thing.  But there was already some preliminary 
thoughts on EV10, and, from the little I know about it, it might have 
been pretty similar to rock in some ways.

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486

------------------------------

Date: Tue, 17 Apr 2007 07:03:30 -0400
From: "Neil Rieck" <n.rieck@sympatico.ca>
Subject: Re: Sun shows Rock first silicon
Message-ID: <46249cdd$0$16263$88260bb3@free.teranews.com>

"Bob Koehler" <koehler@eisner.nospam.encompasserve.org> wrote in message 
news:yR+YST65b3Lp@eisner.encompasserve.org...
> In article <4622086e$0$16392$88260bb3@free.teranews.com>, "Neil Rieck" 
> <n.rieck@sympatico.ca> writes:
>
[...snip...]
>
>   But do they have a compiler than can provide "effortless parallel
>   programming"?
>
>   When I looked at generated code I was impressed what DEC's compilers
>   would do for parallel operations on 21064 (two threads).  But most
>   of the Sun users I've worked with just grab the gnu compilers.  I'm
>   not holding my breath waiting for gcc to keep 32 threads busy.  Can
>   I convince my Sun users to buy a professionally written compiler,
>   and if so, what assurances do I get that it will keep 32 threads busy,
>   or do I have to make sure I have 16 active processes to keep the 16
>   cores busy?
>
>   Anything less is just more marketing instructions per second.  I got
>   enough NOPs running on my Pentium M.
>

True but at least SUN "promotes" software development in order to leverage 
their hardware. The intro to this advert is good for a chuckle...

http://www.howmachineswork.com/Sun/TempleOfTheSun/?source=tile1

 ...but I'm not sure if it will translate into sales.  But at least it's 
something. DEC's got the best compilers but they've kept this fact an 
industry secret.

Neil Rieck
Kitchener/Waterloo/Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/


-- 
Posted via a free Usenet account from http://www.teranews.com

------------------------------

Date: 17 Apr 2007 07:47:33 -0500
From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)
Subject: Re: Sun shows Rock first silicon
Message-ID: <9qwxifbUxjFF@eisner.encompasserve.org>

In article <46249cdd$0$16263$88260bb3@free.teranews.com>, "Neil Rieck" <n.rieck@sympatico.ca> writes:
> 
>  ...but I'm not sure if it will translate into sales.  But at least it's 
> something. DEC's got the best compilers but they've kept this fact an 
> industry secret.

   DEC _had_ the best compilers.  DEC had some damn good software.  But
   now DEC doesn't have jack.

------------------------------

Date: 17 Apr 2007 09:12:48 -0700
From: Andrew <andrew_harrison@symantec.com>
Subject: Re: Sun shows Rock first silicon
Message-ID: <1176826368.940207.192580@e65g2000hsc.googlegroups.com>

On 16 Apr, 22:30, koeh...@eisner.nospam.encompasserve.org (Bob
Koehler) wrote:
> In article <4622086e$0$16392$88260...@free.teranews.com>, "Neil Rieck" <n.ri...@sympatico.ca> writes:
> >     ###
> > "Rock is 16 cores - we haven't said how many threads per core. Nor have we
> > said why this chip heralds the golden age of effortless parallel
> > programming, or how it brings fault tolerance to the masses. But stay tuned,
> > I think we're planning on talking up both in the next few weeks."
>
> > In the past, we've disclosed that Rock will run two threads per core, giving
> > it 32 threads per chip. In addition, the 256TB of memory described by
> > Schwartz would come via a 8-socket box that holds 512 DIMMs, depicted here.
> > Our sources have indicated that Sun stopped work on systems any larger than
> > the Platinum box.
>
> >     ###
>
>    But do they have a compiler than can provide "effortless parallel
>    programming"?
>

Thread level parallelism is relatively easy to exploit. Oracle, J2EE
environments do it without you having to write code yourself.

>    When I looked at generated code I was impressed what DEC's compilers
>    would do for parallel operations on 21064 (two threads).  But most
>    of the Sun users I've worked with just grab the gnu compilers.  I'm
>    not holding my breath waiting for gcc to keep 32 threads busy.  Can
>    I convince my Sun users to buy a professionally written compiler,
>    and if so, what assurances do I get that it will keep 32 threads busy,
>    or do I have to make sure I have 16 active processes to keep the 16
>    cores busy?
>

Actually many people now use the SunCompilers which are free with
Solaris rather than GCC and Sun's compilers do quite a good job of
parallelisation. Sun have even posted some multi-cpu SPEC results (not
SPECrate) using auto parallel options on the compilers.

As I said you don't need to convince your Sun users to buy anything,
the compilers are free.

Regards
Andrew

------------------------------

Date: Tue, 17 Apr 2007 13:26:16 -0400
From: "Main, Kerry" <Kerry.Main@hp.com>
Subject: RE: Sun shows Rock first silicon
Message-ID: <FA60F2C4B72A584DBFC6091F6A2B8684022B9505@tayexc19.americas.cpqcorp.net>

> -----Original Message-----
> From: Andrew [mailto:andrew_harrison@symantec.com]
> Sent: April 17, 2007 12:13 PM
> To: Info-VAX@Mvb.Saic.Com
> Subject: Re: Sun shows Rock first silicon
>=20

[snip ..]

>=20
> Actually many people now use the SunCompilers which are free with
> Solaris rather than GCC and Sun's compilers do quite a good job of
> parallelisation. Sun have even posted some multi-cpu SPEC results (not
> SPECrate) using auto parallel options on the compilers.
>=20
> As I said you don't need to convince your Sun users to buy anything,
> the compilers are free.
>=20
> Regards
> Andrew

Define free .. is it like "Linux is free as long as your time and labour
is worth nothing?"

Keep in mind that changing compilers is a big thing (not show stopper,
but big) as it means doing all sorts of additional testing,
certification, regression testing, load testing etc.

Also, threads have some benefits, but the down side is also additional
complexity in terms of troubleshooting i.e. one thread potentially
messing with other threads stuff etc. It gets even more interesting when
you start talking about clustering multi-threaded systems.

Again, these are issues that can be addressed with the right planning
and design efforts, but the effort required to use the "free" compilers
is certainly not "free".

Regards


Kerry Main
Senior Consultant
HP Services Canada
Voice: 613-592-4660
Fax: 613-591-4477
kerryDOTmainAThpDOTcom
(remove the DOT's and AT)=20

OpenVMS - the secure, multi-site OS that just works.

------------------------------

Date: 17 Apr 2007 10:47:56 -0700
From: Andrew <andrew_harrison@symantec.com>
Subject: Re: Sun shows Rock first silicon
Message-ID: <1176832076.787562.216050@y80g2000hsf.googlegroups.com>

On 17 Apr, 18:26, "Main, Kerry" <Kerry.M...@hp.com> wrote:
> > -----Original Message-----
> > From: Andrew [mailto:andrew_harri...@symantec.com]
> > Sent: April 17, 2007 12:13 PM
> > To: Info-...@Mvb.Saic.Com
> > Subject: Re: Sun shows Rock first silicon
>
> [snip ..]
>
>
>
> > Actually many people now use the SunCompilers which are free with
> > Solaris rather than GCC and Sun's compilers do quite a good job of
> > parallelisation. Sun have even posted some multi-cpu SPEC results (not
> > SPECrate) using auto parallel options on the compilers.
>
> > As I said you don't need to convince your Sun users to buy anything,
> > the compilers are free.
>
> > Regards
> > Andrew
>
> Define free .. is it like "Linux is free as long as your time and labour
> is worth nothing?"
>

Free as in there is no license cost for the compiler. Of course your
time and labour should be added into the equation but having said that
one of the apparent attractions of Solaris/OpenSolaris vs Linux is its
lower support costs.

> Keep in mind that changing compilers is a big thing (not show stopper,
> but big) as it means doing all sorts of additional testing,
> certification, regression testing, load testing etc.
>

Of course you need to test, but it isn't that big a deal. Sun in fact
have a number of references for SW development shops moving from GCC
to Sun Studio 11 which incidentally is also available on Linux.

> Also, threads have some benefits, but the down side is also additional
> complexity in terms of troubleshooting i.e. one thread potentially
> messing with other threads stuff etc. It gets even more interesting when
> you start talking about clustering multi-threaded systems.
>

This issues were all raised as apparent show stoppers when Sun
announced Niagara the reality is that apart from relatively slow
performance for each thread and poor FP these issues have generally
not been problems. Some of our SW without any changes has scaled
extremely well on T1's.

> Again, these are issues that can be addressed with the right planning
> and design efforts, but the effort required to use the "free" compilers
> is certainly not "free".
>

Of course.

Regards
Andrew Harrison
> Regards
>
> Kerry Main
> Senior Consultant
> HP Services Canada
> Voice: 613-592-4660
> Fax: 613-591-4477
> kerryDOTmainAThpDOTcom
> (remove the DOT's and AT)
>
> OpenVMS - the secure, multi-site OS that just works.

------------------------------

Date: Tue, 17 Apr 2007 05:51:12 +0000 (UTC)
From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)
Subject: Re: TCPIP SMTP: suggestion
Message-ID: <f01n8g$m7i$1@online.de>

In article <1f646$4623f415$cef8887a$1722@TEKSAVVY.COM>, JF Mezei
<jfmezei.spamnot@vaxination.ca> writes: 

> try zen and see how much your volume drops. And remember that since most 
> people block emails from dynamic IPs, if you use a dynamic IP, your own 
> messages will likely be blocked.

Right; that's why I stopped sending directly soon after I set up my 
cluster at home.

> No, it doesn't log which rbl matched. That is something which should not 
> only be logged, but also the message sent to the sender should also 
> include which rbl his IP is included in as a courtesy for legitimate 
> senders who may accidentally be on such a list.

Right.

------------------------------

Date: Tue, 17 Apr 2007 09:34:33 -0400
From: John Reagan <john.reagan@hp.com>
Subject: Re: VMS Alpha to Itanium port
Message-ID: <f02if8$oc9$1@usenet01.boi.hp.com>

Chris Townley wrote:
> 
> I wont even look at the macro - if it doesnt run out of the box, I
> rewrite as required, and there is nothing fancy in the C

As others have mentioned, moving Macro-32 is normally easy, but you 
might have to add a few new directives for some non-standard calling 
sequences.  The Macro compiler and linker can help you track them down. 
  If you need help, send me email.  The vast majority of OpenVMS' own 
Macro-32 code went from Alpha to I64 with no modifications required.

> 
> However the main area will be the basic. Has anyone any ideas what
> issues are likely?

In general, BASIC should recompile and go.  It is the same compiler as 
on Alpha.  However, there are some nagging performance issues with the 
BASIC RTL.  The RTL likes to walk up and down the stack looking for 
other BASIC routines to propagate things like scaling factor, etc. 
While that is quick enough on Alpha, the stack walk is much slower on 
I64.  That constant stack walking can slow down the BASIC application. 
We have fixed many of these issues for V8.3 but there are still others 
on our plate.  Again, if you need help, send me email.

> 
> TIA
> --
> Chris
> 

--
John Reagan
OpenVMS Pascal/Macro-32/COBOL Project Leader

------------------------------

End of INFO-VAX 2007.212
************************