f



Whither VMS?

Looks like another VMS casualty:

http://blogs.computerworld.com/14637/linux_powers_worlds_fastest_stock_exchange
0
curtis (20)
9/2/2009 3:42:32 AM
comp.os.vms 21904 articles. 1 followers. Post Follow

473 Replies
2624 Views

Similar Articles

[PageSpeed] 53

Curtis Rempel schrieb:
> Looks like another VMS casualty:
> 
> http://blogs.computerworld.com/14637/linux_powers_worlds_fastest_stock_exchange

wasn't Deutsche B�rse always bragging about being
a VMS stronghold?

0
M.Kraemer (2048)
9/2/2009 7:30:18 AM
Michael Kraemer wrote:

> wasn't Deutsche B�rse always bragging about being
> a VMS stronghold?

Yep. And also of interest in this article is the fact that many other
well known VMS exchanges (such as international securities exchange) are
linked to Deutsche B�rse.

Lets face it, HP's message about the future of VMS has been heard, and
each of the remaining niches has heeded the warnings and begun to invest
in other technologies.
0
9/2/2009 8:01:44 AM
Hi Curtis,

"Curtis Rempel" <curtis@no.spam.here.telus.net> wrote in message
news:IQlnm.42197$Db2.13820@edtnps83...
> Looks like another VMS casualty:
>
>
http://blogs.computerworld.com/14637/linux_powers_worlds_fastest_stock_exchange

So VMS license payers funding the port of RTR to Linux wasn't enough to
bring a tear to your eye at the last RoadMap?

Regards Richard Maher

PS. The good news is that all this MQSeries, BMQ, RTR store-and-forward crap
is yesterday's technology, a trading system with instantaneous matching,
clearing, and settlement can't be far away?


0
maher_rj (1626)
9/3/2009 12:41:18 PM
On Sep 3, 8:41=A0am, "Richard Maher" <maher...@hotspamnotmail.com>
wrote:
> Hi Curtis,
>
> "Curtis Rempel" <cur...@no.spam.here.telus.net> wrote in message
>
> news:IQlnm.42197$Db2.13820@edtnps83...> Looks like another VMS casualty:
>
> http://blogs.computerworld.com/14637/linux_powers_worlds_fastest_stoc...
>
> So VMS license payers funding the port of RTR to Linux wasn't enough to
> bring a tear to your eye at the last RoadMap?
>
> Regards Richard Maher
>
> PS. The good news is that all this MQSeries, BMQ, RTR store-and-forward c=
rap
> is yesterday's technology, a trading system with instantaneous matching,
> clearing, and settlement can't be far away?

You bring up an interesting point that has been in the back of my head
for months now. HP seems to push Windows, Linux and HPUX more than
anything else. Forgetting about Windows and Linux for a moment, what
does HP charge for OS and compiler licenses in the HPUX world?

If HPUX licenses are lower than OpenVMS then wouldn't this be a form
of unnatural selection against OpenVMS? (because bean counters will
always point you to the cheaper product; that's why our IS/IT people
keep leaning on us to switch to Windows Server 2003). The only way to
get OpenVMS licensing on a level playing field with HPUX (or anything
else) is to announce to the world that OpenVMS prices will drop a
certain percent every week for the next 60 months. The only down side
to this is guaranteeing that there will still be an OpenVMS market in
60 months.

And while on my soap box, I know that anyone can scrape together money
each year for a Connect membership then pay/apply for OpenVMS hobbyist
licenses which will expire after every year. (I'm not sure how you get
a hobbyist license for HPUX). Anyway, at the end of the day this is
still a bigger pain than just freely downloading Ubuntu, Linux,
Solaris or SUN Studio. Maybe HP should just go the extra mile and
allow people to freely download OpenVMS for non-commercial use. Why?
How will the newbies ever get involved with OpenVMS if they don't get
a free shot at trying it out? This is just food-for-thought.

Neil Rieck
Kitchener/Waterloo/Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
0
n.rieck (2007)
9/10/2009 1:36:46 AM
Neil Rieck schrieb:

> 
> You bring up an interesting point that has been in the back of my head
> for months now. HP seems to push Windows, Linux and HPUX more than
> anything else. 

No surprise here. Windoze and Linux are almost inevitable
for a vendor, and HP-UX is their genuine product, while VMS is n.i.h.

> Forgetting about Windows and Linux for a moment, what
> does HP charge for OS and compiler licenses in the HPUX world?
> 
> If HPUX licenses are lower than OpenVMS then wouldn't this be a form
> of unnatural selection against OpenVMS? 

Why? See above. And maybe it costs more to develop/maintain VMS.

> (because bean counters will
> always point you to the cheaper product; that's why our IS/IT people
> keep leaning on us to switch to Windows Server 2003).

 From what?

> The only way to
> get OpenVMS licensing on a level playing field with HPUX (or anything
> else) is to announce to the world that OpenVMS prices will drop a
> certain percent every week for the next 60 months. 

Assuming the world knows or even takes care about VMS.
And why not just lower the price at once?

> The only down side
> to this is guaranteeing that there will still be an OpenVMS market in
> 60 months.
> 
> And while on my soap box, I know that anyone can scrape together money
> each year for a Connect membership then pay/apply for OpenVMS hobbyist
> licenses which will expire after every year. (I'm not sure how you get
> a hobbyist license for HPUX). 

No need for that. If you grab an HP-UX capable workstation,
you have the license. If you manage to grab HP-UX media,
you can install at least the base OS, there are no PAKs.
Native compilers et al are a different story.

> Anyway, at the end of the day this is
> still a bigger pain than just freely downloading Ubuntu, Linux,
> Solaris or SUN Studio. 

Yep.

> Maybe HP should just go the extra mile and
> allow people to freely download OpenVMS for non-commercial use. Why?
> How will the newbies ever get involved with OpenVMS if they don't get
> a free shot at trying it out? This is just food-for-thought.

Put away those silly PAKs
(or at least offer a general, unlimited one, like that for Tru64),
and charge for the original OS media a processing fee, compatible
with the price of a hobbyist's hardware.

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

0
M.Kraemer (2048)
9/10/2009 7:52:46 AM
Michael Kraemer wrote:
> Neil Rieck schrieb:
> 
>> 
>> You bring up an interesting point that has been in the back of my head
>> for months now. HP seems to push Windows, Linux and HPUX more than
>> anything else. 
> 
> No surprise here. Windoze and Linux are almost inevitable
> for a vendor, and HP-UX is their genuine product, while VMS is n.i.h.


My impression (and it is just an impression) is that HP isn't pushing
HP-UX much more than VMS anymore and that the marketing is moving to
commodity OS (Linux and Windows).

The other day, I went to www.HP.com and tried to navigate to VMS. I
found neither VMS, nor NSK nor HP-UX.  If you don't know what to click,
you may not find it.

I know that there are /GO/something links (such as one posted recently)
which get you to the products, and some that bring you to a page that
shows all the enterprise platforms (including Alpha and Pa-Risc) as well
as all the OS (including VMS). But getting there from the HP home page
didn't seem obvious.

Perhaps HP is moving to a hardware and services company, de-emphasizing
its proprietary OS and going for commodity hardware and operating systems.

Not clear how the survival/demise of Solaris could change HP's plans.
Consider what HP did to Tru64 when it got Digital/Compaq. If HP gets
Sparc/Solaris, I suspect it would move to stop development and just
provide support. On the other hand, with Ia64 on its way out, perhaps HP
would (of all the ironies) adopt Sparc and put a spark back into that
architecture ?


0
9/10/2009 8:21:50 AM
JF Mezei schrieb:

> 
> My impression (and it is just an impression) is that HP isn't pushing
> HP-UX much more than VMS anymore and that the marketing is moving to
> commodity OS (Linux and Windows).

That maybe true, but in the commodity space "marketing",
in the sense of: "hey, listen, we have that too" is more
important. There's no second vendor for HP-UX or VMS.
OTOH, HP-UX is in the same IA64 pitfall as VMS,
but still it's their preferred platform.

> 
> The other day, I went to www.HP.com and tried to navigate to VMS. I
> found neither VMS, nor NSK nor HP-UX.  If you don't know what to click,
> you may not find it.
> 
> I know that there are /GO/something links (such as one posted recently)
> which get you to the products, and some that bring you to a page that
> shows all the enterprise platforms (including Alpha and Pa-Risc) as well
> as all the OS (including VMS). But getting there from the HP home page
> didn't seem obvious.

Corporate websites just suck, HP (and IBM as well) is no exception.
And of course they present the most wanted more visible
than exotic stuff such as HP-UX and VMS.

> Perhaps HP is moving to a hardware and services company, de-emphasizing
> its proprietary OS and going for commodity hardware and operating systems.

I think this is what Carly announced several years ago
(and Belluzzo long before).

> Not clear how the survival/demise of Solaris could change HP's plans.
> Consider what HP did to Tru64 when it got Digital/Compaq. If HP gets
> Sparc/Solaris, I suspect it would move to stop development and just
> provide support. On the other hand, with Ia64 on its way out, perhaps HP
> would (of all the ironies) adopt Sparc and put a spark back into that
> architecture ?

Unlikely, I'd say. They just got rid of their own CPU business
and one of their Unix platforms,
why would they reenter that business?
Even less likely now that Sun's death indicates, that Sparc & Solaris
weren't going that strong in the past few years.

0
M.Kraemer (2048)
9/10/2009 8:40:10 AM
Michael Kraemer wrote:

> Unlikely, I'd say. They just got rid of their own CPU business
> and one of their Unix platforms,
> why would they reenter that business?

Anti trust. Governments might not agree to Oracle giving Sun's leftovers
 for HP to just kill them. The industry would have gone from a wealth of
different architectures to only IBM Power and Intel/AMDs 8086. And since
Power is essentially proprietary in the enterprise server business, the
governments might rule that disapearance of Sparc would cause too much
concentration on the 8086.

Secondly, HP will have been burned by the failure of IA64 to take off,
while seeing IBM able maintain technological edge with its Power.

Perhaps HP might decide that it needs to get back into the chip business
to be able to control its own future and compete against IBM.

If it hadn't been for the Oracle takeover of Sun, I don't think that HP
would have even thought about restarting chip development. Their goal
would have been to move to 8086 once IA64 reaches its end. But with Sun
essentially going out of business (or so it appears), HP might need to
to reconsider many aspects of its long term plans.

HP neds to be careful. If it is drunken with the thought of growing
support revenues by buying Sun, it may not realise the impact of getting
Solaris and Sparc machines with it.

What bugs me in all that is why would Ellison buy Sun just to get Java
and mySQL and sell the rest ? Ellison seems like he is able to
strategise intelligently and be above hype.

And from HP's point of view, it would depend on how Hurd views Carly's
decision to buy Compaq and whether it was all worth it at the end,
considering that they didn't leverage much out of it (except DEC's disk
storage products). If Hurd doesn't think highly of the decision to buy
Compaq, he might not think highly of a plan to buy Sun.
0
9/10/2009 9:39:51 AM
In article <00249d7e$0$11333$c3e8da3@news.astraweb.com>, JF Mezei
<jfmezei.spamnot@vaxination.ca> writes:
> 
> Anti trust.

And why should HP care, they're not involved in antitrust issues.

> Governments might not agree to Oracle giving Sun's leftovers
>  for HP to just kill them. 

If Oracle don't want Sun's hardware business they could
just try to sell it off. If HP buys it, what could government say?

> The industry would have gone from a wealth of
> different architectures to only IBM Power and Intel/AMDs 8086. And since
> Power is essentially proprietary in the enterprise server business, the
> governments might rule that disapearance of Sparc would cause too much
> concentration on the 8086.

With the same logic they could have forbidden Apple
to switch to intel. Too much concentration on x86 on the desktop.

> 
> Secondly, HP will have been burned by the failure of IA64 to take off,

It is my understanding that HP feels being burned my making
non-standard chips altogether.

> while seeing IBM able maintain technological edge with its Power.

Only if one assumes that it is HP's goal to have technological edge
with home-made stuff at all. I think they (Carly) have made it clear
that this is not their goal. They relegated R&D to Intel and M$
and try to sell as many x86 commodity stuff as possible.
 
> Perhaps HP might decide that it needs to get back into the chip business
> to be able to control its own future and compete against IBM.

For them, controlling the future of  ink cartridges is enough.
As for computers, since they consume a significant 
amount of x86 CPUs they probably have some say at what goes on
at intel.
 
> If it hadn't been for the Oracle takeover of Sun, I don't think that HP
> would have even thought about restarting chip development. 

And I don't think they are considering it now.
Plus, AFAIK it's not Sun which develops and makes Sparc CPUs,
but a separate SPARC company (+Fujitsu).
I don't think these companies were for sale too.

> Their goal
> would have been to move to 8086 once IA64 reaches its end. 

And it still is. 
Drop VMS and offer an Linux/x86 "upgrade" path for HP-UX.

> But with Sun
> essentially going out of business (or so it appears),

unless Oracle reverts their decision, Sun is already history.

> HP might need to
> to reconsider many aspects of its long term plans.
> 
> HP neds to be careful. If it is drunken with the thought of growing
> support revenues by buying Sun, it may not realise the impact of getting
> Solaris and Sparc machines with it.

I don't think they need your advise.
Already the fate of DEC has shown, that even support revenues
appearing as cash cow do not necessarily translate into big profits when
the costs of making lots of own stuff are subtracted.
 
> What bugs me in all that is why would Ellison buy Sun just to get Java
> and mySQL and sell the rest ? Ellison seems like he is able to
> strategise intelligently and be above hype.

He hasn't "got" Java, and just for mySQL the price would be a bit steep.
He got means to complete Oracle's main business, i.e. now
they can offer complete solutions: hardware, OS, middleware, database. 

> And from HP's point of view, it would depend on how Hurd views Carly's
> decision to buy Compaq 

I don't believe he would waste a single thought on that. Done deal.

> and whether it was all worth it at the end,

Of course it was, unfortunately.
In revenue HP is about as big as IBM,
in profits not far behind. Of course most of 
it doesn't come from "real computers", but do shareholders care?

> considering that they didn't leverage much out of it (except DEC's disk
> storage products). If Hurd doesn't think highly of the decision to buy
> Compaq, he might not think highly of a plan to buy Sun.

Sun is not for sale. Oracle has it now.
0
M.Kraemer (2048)
9/10/2009 10:31:43 AM
On Sep 10, 6:31=A0am, m.krae...@gsi.de (Michael Kraemer) wrote:
> In article <00249d7e$0$11333$c3e8...@news.astraweb.com>, JF Mezei
>
> <jfmezei.spam...@vaxination.ca> writes:
>
> > Anti trust.
>
> And why should HP care, they're not involved in antitrust issues.
>
> > Governments might not agree to Oracle giving Sun's leftovers
> > =A0for HP to just kill them.
>
> If Oracle don't want Sun's hardware business they could
> just try to sell it off. If HP buys it, what could government say?
>
> > The industry would have gone from a wealth of
> > different architectures to only IBM Power and Intel/AMDs 8086. And sinc=
e
> > Power is essentially proprietary in the enterprise server business, the
> > governments might rule that disapearance of Sparc would cause too much
> > concentration on the 8086.
>
> With the same logic they could have forbidden Apple
> to switch to intel. Too much concentration on x86 on the desktop.
>
>
>
> > Secondly, HP will have been burned by the failure of IA64 to take off,
>
> It is my understanding that HP feels being burned my making
> non-standard chips altogether.
>
> > while seeing IBM able maintain technological edge with its Power.
>
> Only if one assumes that it is HP's goal to have technological edge
> with home-made stuff at all. I think they (Carly) have made it clear
> that this is not their goal. They relegated R&D to Intel and M$
> and try to sell as many x86 commodity stuff as possible.
>
> > Perhaps HP might decide that it needs to get back into the chip busines=
s
> > to be able to control its own future and compete against IBM.
>
> For them, controlling the future of =A0ink cartridges is enough.
> As for computers, since they consume a significant
> amount of x86 CPUs they probably have some say at what goes on
> at intel.
>
> > If it hadn't been for the Oracle takeover of Sun, I don't think that HP
> > would have even thought about restarting chip development.
>
> And I don't think they are considering it now.
> Plus, AFAIK it's not Sun which develops and makes Sparc CPUs,
> but a separate SPARC company (+Fujitsu).
> I don't think these companies were for sale too.
>
> > Their goal
> > would have been to move to 8086 once IA64 reaches its end.
>
> And it still is.
> Drop VMS and offer an Linux/x86 "upgrade" path for HP-UX.
>
> > But with Sun
> > essentially going out of business (or so it appears),
>
> unless Oracle reverts their decision, Sun is already history.
>
> > HP might need to
> > to reconsider many aspects of its long term plans.
>
> > HP neds to be careful. If it is drunken with the thought of growing
> > support revenues by buying Sun, it may not realise the impact of gettin=
g
> > Solaris and Sparc machines with it.
>
> I don't think they need your advise.
> Already the fate of DEC has shown, that even support revenues
> appearing as cash cow do not necessarily translate into big profits when
> the costs of making lots of own stuff are subtracted.
>
> > What bugs me in all that is why would Ellison buy Sun just to get Java
> > and mySQL and sell the rest ? Ellison seems like he is able to
> > strategise intelligently and be above hype.
>
> He hasn't "got" Java, and just for mySQL the price would be a bit steep.
> He got means to complete Oracle's main business, i.e. now
> they can offer complete solutions: hardware, OS, middleware, database.
>
> > And from HP's point of view, it would depend on how Hurd views Carly's
> > decision to buy Compaq
>
> I don't believe he would waste a single thought on that. Done deal.
>
> > and whether it was all worth it at the end,
>
> Of course it was, unfortunately.
> In revenue HP is about as big as IBM,
> in profits not far behind. Of course most of
> it doesn't come from "real computers", but do shareholders care?
>
> > considering that they didn't leverage much out of it (except DEC's disk
> > storage products). If Hurd doesn't think highly of the decision to buy
> > Compaq, he might not think highly of a plan to buy Sun.
>
> Sun is not for sale. Oracle has it now.

True (maybe he meant to say Solaris). For years now Oracle has been
positioning itself as the #1 software publisher in the Enterprise
market. Like Microsoft, they are not tied to any particular flavor of
hardware and since Solaris runs on many platforms, I can't see them
selling it, ever.

Neil Rieck
Kitchener/Waterloo/Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
0
n.rieck (2007)
9/10/2009 11:21:41 AM
On Sep 10, 10:21 am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
>
> The other day, I went towww.HP.comand tried to navigate to VMS. I
> found neither VMS, nor NSK nor HP-UX.  If you don't know what to click,
> you may not find it.
>

Huh?
1. Set mouse pointer on "Large Enterprise Business" in the left
frame.
2. Click on "Servers" in the pull-down menu.
3. You are done. It took just 1.5 mouse click.
HP-UX #1 in the list.
VMS is #4, NonStop Os is #5. Both listed below Windows and Linux but
above other popular 3rd party OS solutions (VMware, Netware, Solaris).
0
9/10/2009 9:14:55 PM
On Sep 10, 11:39 am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> And from HP's point of view, it would depend on how Hurd views Carly's
> decision to buy Compaq and whether it was all worth it at the end,
> considering that they didn't leverage much out of it (except DEC's disk
> storage products).

Huh?
80% of HP computer business today consists of Compaq (not DEC) legacy.
Proliant line in particular is a crown jewel.
Without the acquisition HP today wouldn't be IBM's equal but rather
Sun-with-the-Ink.
0
9/10/2009 9:23:42 PM
Michael S wrote:

> 1. Set mouse pointer on "Large Enterprise Business" in the left
> frame.
> 2. Click on "Servers" in the pull-down menu.
> 3. You are done. It took just 1.5 mouse click.
> HP-UX #1 in the list.
> VMS is #4, NonStop Os is #5. Both listed below Windows and Linux but
> above other popular 3rd party OS solutions (VMware, Netware, Solaris).


I swear, this page was changed since I last visited it. There was a
servers page with proliant, integrety HP9000 Alpha and the telco/carrier
garde stuff. But no operating systems mentioned. (not even HP-UX).

This page is much better. (and it has "As Sun sets customers seek new
light").
0
9/11/2009 1:30:48 AM
Michael S wrote:

> 80% of HP computer business today consists of Compaq (not DEC) legacy.
> Proliant line in particular is a crown jewel.

The only unique non-DEC technology HP got was the iPaq, which, at that
time still had an "exclusive" arrangement (Microsoft had given Compaq a
few years of exclusivity on that type of PDA/phone).

Excuse my ignorance, but what is so special about "Proliant" ? Aren't
they just commodity machines that HP could have built all by itself
without needing to buy Compaq ?



> Without the acquisition HP today wouldn't be IBM's equal but rather
> Sun-with-the-Ink.

That is debatable. Without acquisition, Carly would have been booted out
much earlier and Hurd would have come in earlier to fix the PC business
and would have acquired a large proportion of Compaq customers fleeing
the impending sinking of the Compaq ship. Remember that Compaq had been
without a captain since Pfeiffer was ousted.
0
9/11/2009 1:36:41 AM
On Sep 10, 3:52=A0am, Michael Kraemer <M.Krae...@gsi.de> wrote:
> Neil Rieck schrieb:
>
>
>
> > You bring up an interesting point that has been in the back of my head
> > for months now. HP seems to push Windows, Linux and HPUX more than
> > anything else.
>
> No surprise here. Windoze and Linux are almost inevitable
> for a vendor, and HP-UX is their genuine product, while VMS is n.i.h.
>
> > Forgetting about Windows and Linux for a moment, what
> > does HP charge for OS and compiler licenses in the HPUX world?
>
> > If HPUX licenses are lower than OpenVMS then wouldn't this be a form
> > of unnatural selection against OpenVMS?
>
> Why? See above. And maybe it costs more to develop/maintain VMS.
>
> > (because bean counters will
> > always point you to the cheaper product; that's why our IS/IT people
> > keep leaning on us to switch to Windows Server 2003).
>
> =A0From what?
>
> > The only way to
> > get OpenVMS licensing on a level playing field with HPUX (or anything
> > else) is to announce to the world that OpenVMS prices will drop a
> > certain percent every week for the next 60 months.
>
> Assuming the world knows or even takes care about VMS.
> And why not just lower the price at once?
>
> > The only down side
> > to this is guaranteeing that there will still be an OpenVMS market in
> > 60 months.
>
> > And while on my soap box, I know that anyone can scrape together money
> > each year for a Connect membership then pay/apply for OpenVMS hobbyist
> > licenses which will expire after every year. (I'm not sure how you get
> > a hobbyist license for HPUX).
>
> No need for that. If you grab an HP-UX capable workstation,
> you have the license. If you manage to grab HP-UX media,
> you can install at least the base OS, there are no PAKs.
> Native compilers et al are a different story.
>
> > Anyway, at the end of the day this is
> > still a bigger pain than just freely downloading Ubuntu, Linux,
> > Solaris or SUN Studio.
>
> Yep.
>
> > Maybe HP should just go the extra mile and
> > allow people to freely download OpenVMS for non-commercial use. Why?
> > How will the newbies ever get involved with OpenVMS if they don't get
> > a free shot at trying it out? This is just food-for-thought.
>
> Put away those silly PAKs
> (or at least offer a general, unlimited one, like that for Tru64),
> and charge for the original OS media a processing fee, compatible
> with the price of a hobbyist's hardware.
>
> > Neil Rieck
> > Kitchener/Waterloo/Cambridge,
> > Ontario, Canada.
> >http://www3.sympatico.ca/n.rieck/

I agree with all your points except the last one. While it is true
that most vendors (Redhat, Sun, etc.) will sell you optical media for
$10 or less, almost all of them allow for immediate free download. In
somes cases (Red Hat, Ubuntu, Linux) they have co-opted friends all
around the planet (mostly universities) to serve-up free binary
downloads from locations closer to the downloader. In the case of
others (Sun, Oracle, etc.) they allow free anytime downloads from
their corporate servers.

Let's all be realistic here, OpenVMS just isn't that popular in the
hacker/hobbyist community so HP could (if they wanted to) offer free
downloads of OpenVMS binaries NOW to anyone at anytime from their
corporate web site. There probably wouldn't be any noticeable increase
in their internet bandwidth usage.

I'm not sure who pays for the infrastructure costs at:
http://www.openvmshobbyist.org
but if it isn't HP then HP Marketing should pick up all the costs
because HP in in for some trouble when all us OpenVMS types retire.
Why? Because the younger generation coming up behind us has never
heard of OpenVMS which means that more of HP's market will wither on
the vine. (I am partially quoting the subject of this news thread :-)

Neil Rieck
Kitchener/Waterloo/Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
0
n.rieck (2007)
9/11/2009 9:30:45 AM
Neil Rieck wrote:

> I'm not sure who pays for the infrastructure costs at:
> http://www.openvmshobbyist.org


David Cathay from Montagar is the one that operates the hobbyist
programme and we should all be grateful for all that he has done.

I don't think he gets anything from HP. And with the change in staffing,
I am not even sure the folks in India know about it.

> because HP in in for some trouble when all us OpenVMS types retire.
> Why? Because the younger generation coming up behind us has never
> heard of OpenVMS which means that more of HP's market will wither on
> the vine. 

Why would that be a problem for HP ? In case you haven't yet accepted
it, HP has essentially already written off VMS. HP clearly doesn't see a
future for VMS and some VPs have already alluded to the fact that it is
an old operating system (now that it is more than 30 years old).

With Sun gone, HP has high hopes that it can retain a large percentage
of the remaining VMS customers when they realise there is no future for
VMS.  For most, the signs have been there and quire evident for some
time, but HP will need to ratchet up the font size to make the message
clearer for those few who still believe that HP has great plans for VMS.

0
9/11/2009 9:47:24 AM
In article <00632aa4$0$30091$c3e8da3@news.astraweb.com>,
 JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

> HP clearly doesn't see a future for VMS and some VPs have already 
> alluded to the fact that it is an old operating system (now that it 
> is more than 30 years old).

Unix is older than VMS but don't confuse me with the facts.  ;-)

Paul
0
9/11/2009 12:43:32 PM
JF Mezei wrote:

> 
> Excuse my ignorance, but what is so special about "Proliant" ? Aren't
> they just commodity machines that HP could have built all by itself
> without needing to buy Compaq ?
> 

The older Proliants were built like a tank and the documentation and 
software support is arguably the best in the business. All free to 
download from the compaq (oops, sorry), hp website, without registration
as well. The shear volume of stuff almost beggars belief. The ftp site 
even has softpaqs for the original Deskpro 386, should you really need it.

I have a couple of ML350,s in the rack here and they are the closest 
i've seen to the old style dec quality of construction...

Regards,

Chris



0
blackhole5 (113)
9/11/2009 1:04:35 PM
"Paul Anderson" <paulranderson@charter.net> wrote in message 
news:paulranderson-A9E29B.08433211092009@newsfarm.iad.highwinds-media.com...
> In article <00632aa4$0$30091$c3e8da3@news.astraweb.com>,
> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>
>> HP clearly doesn't see a future for VMS and some VPs have already
>> alluded to the fact that it is an old operating system (now that it
>> is more than 30 years old).
>
> Unix is older than VMS but don't confuse me with the facts.  ;-)
>
> Paul

Guardian is older than VMS as well.  That's what the voices in my head tell 
me (along with the facts).

John 


0
johnrreagan (372)
9/11/2009 1:25:25 PM
On Sep 11, 10:47=A0am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> Neil Rieck wrote:
> > I'm not sure who pays for the infrastructure costs at:
> >http://www.openvmshobbyist.org
>
> David Cathay from Montagar is the one that operates the hobbyist
> programme and we should all be grateful for all that he has done.
>
> I don't think he gets anything from HP. And with the change in staffing,
> I am not even sure the folks in India know about it.
>
> > because HP in in for some trouble when all us OpenVMS types retire.
> > Why? Because the younger generation coming up behind us has never
> > heard of OpenVMS which means that more of HP's market will wither on
> > the vine.
>
> Why would that be a problem for HP ? In case you haven't yet accepted
> it, HP has essentially already written off VMS. HP clearly doesn't see a
> future for VMS and some VPs have already alluded to the fact that it is
> an old operating system (now that it is more than 30 years old).
>
> With Sun gone, HP has high hopes that it can retain a large percentage
> of the remaining VMS customers when they realise there is no future for
> VMS. =A0For most, the signs have been there and quire evident for some
> time, but HP will need to ratchet up the font size to make the message
> clearer for those few who still believe that HP has great plans for VMS.


"HP has high hopes that it can retain a large percentage of the
remaining VMS customers"
"what is so special about "Proliant" ? "

There's a connection between those two.

Proliant is (or was, I've been away a while) to x86 servers what VAX
was to superminis - the "industry standard", with a model to suit
pretty much every requirement and every budget. Maybe a little bit
premium priced, often because of premium class design and engineering
and support, but if you do your research and pick the right model you
can be confident that what you're buying will work right out of the
box, and be properly supported through its (reasonably long in x86
terms) life cycle. At least it'll be OK until you put Windows on it,
then all bets are off, obviously. But lots of people do put Windows on
Proliant, and lots of people put Linux on them too, and lots of
enterprise applications on the Proliant/Windows or Proliant/Linux
combination are keeping businesses running around the world.

The current Proliant range starts at single socket and goes up to 8
socket, with (today, iirc) up to 512GB of memory. That covers most of
the server market.

There was an Itanium Proliant in the early IA64 days but the less said
about that the better. With "Common System Interconnect"/QuickPath one
might have hoped that an Itanium Proliant might rise again, perhaps
even to be qualified to run VMS; it would have seemed silly to have
Itanium-specific engineering at least at the low end of the IA64
range. Then again, now that the once-promised "common socket" between
x86-64 and IA64 no longer seems to be happening, who knows what will
happen.

It's highly likely that people abandoning VMS servers will end up on
Proliant just by default, unless the applications are already in the
tiny "Itanium-only" niche (eg they need more physical memory than
AMD64 can deliver in the foreseeable future, see related discussion
recently) or unless cHomPaq have already made enough enemies in the
organisation, such that the VMS systems are redesigned for a different
OS on Dell or IBM hardware (other options pale into insignificance).
0
9/11/2009 1:45:33 PM
In article <0062be6d$0$5080$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> 
> Excuse my ignorance, but what is so special about "Proliant" ? Aren't
> they just commodity machines that HP could have built all by itself
> without needing to buy Compaq ?

   Could have, but didn't.  Reminds me when Olivetti designed a new
   typewriter by designing the case first (my grey hair showing).

   And there are still Compaq systems on the shelf in addition to
   HP systems, so HP is still gettting the increased shelf space
   of selling under two names.

   Maybe they should bring back |d|i|g|t|a|l| and increase their shelf
   presence a little bit more.  I can remember the one time I went into
   a store and saw DEC PCs on a shelf, not longer after they had gone 
   through a short period when it seemed that all DEC PCs were rebranded
   Tandys (but I think at the time all the laptops were actaully
   rebranded Olivettis).
0
koehler2 (8314)
9/11/2009 2:00:53 PM
Paul Anderson schrieb:

> 
> Unix is older than VMS but don't confuse me with the facts.  ;-)

At worst the difference is a few years only
(and don't confuse Multics with Unix),
which is insignificant in hindsight of 30* years.

0
M.Kraemer (2048)
9/11/2009 3:46:35 PM
On Fri, 11 Sep 2009 17:46:35 +0200, Michael Kraemer wrote:

> Paul Anderson schrieb:
> 
> 
>> Unix is older than VMS but don't confuse me with the facts.  ;-)
> 
> At worst the difference is a few years only (and don't confuse Multics
> with Unix), which is insignificant in hindsight of 30* years.

Anyway, 32 bit UNIX didn't arrive until *after* VMS. One would have to 
compare early UNIX (even on the PDP-11) with 16 bit VMS (or RSX-11, as we 
know it)! :-)



-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
9/11/2009 6:28:33 PM
"Bob Eager" <rde42@spamcop.net> wrote in message 
news:7gvj6hF2ricj3U4@mid.individual.net...
> On Fri, 11 Sep 2009 17:46:35 +0200, Michael Kraemer wrote:
>
>> Paul Anderson schrieb:
>>
>>
>>> Unix is older than VMS but don't confuse me with the facts.  ;-)
>>
>> At worst the difference is a few years only (and don't confuse Multics
>> with Unix), which is insignificant in hindsight of 30* years.
>
> Anyway, 32 bit UNIX didn't arrive until *after* VMS. One would have to
> compare early UNIX (even on the PDP-11) with 16 bit VMS (or RSX-11, as we
> know it)! :-)

The Perkin-Elmer 8/32 (a 32-bit computer) ran a flavor of UNIX and was in 
the field before the first VAXen.  My former employer had one.  It was the 
first non-PDP-11 computer to run UNIX.

John 


0
johnrreagan (372)
9/11/2009 7:57:31 PM
On Fri, 11 Sep 2009 15:57:31 -0400, John Reagan wrote:

> "Bob Eager" <rde42@spamcop.net> wrote in message
> news:7gvj6hF2ricj3U4@mid.individual.net...
>> On Fri, 11 Sep 2009 17:46:35 +0200, Michael Kraemer wrote:
>>
>>> Paul Anderson schrieb:
>>>
>>>
>>>> Unix is older than VMS but don't confuse me with the facts.  ;-)
>>>
>>> At worst the difference is a few years only (and don't confuse Multics
>>> with Unix), which is insignificant in hindsight of 30* years.
>>
>> Anyway, 32 bit UNIX didn't arrive until *after* VMS. One would have to
>> compare early UNIX (even on the PDP-11) with 16 bit VMS (or RSX-11, as
>> we know it)! :-)
> 
> The Perkin-Elmer 8/32 (a 32-bit computer) ran a flavor of UNIX and was
> in the field before the first VAXen.  My former employer had one.  It
> was the first non-PDP-11 computer to run UNIX.

<pedant>
UNIX first appeared on the PDP-7, in around 1970. OK, it was written in 
assembler...!
</pedant>

Anyway...I'd be interested in dates. UNIX didn't go (semi-) public until 
about 1976 (I started using it in July 1976). Not sure about first VMS 
dates but I thought it was about then. Presumably the PE 8/32 (that was 
the Interdata later, wasn't it?) post-dates the PDP-11 version going 
public as v6?

Perhaps VMS was later than I thought, but 1976 sticks in my mind.




-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
9/11/2009 8:25:27 PM
Bob Eager wrote:

> Perhaps VMS was later than I thought, but 1976 sticks in my mind.

VMS was late 1978. That is why there was the 30th anniversary last year.

However, when HP mentions that one OS is old at 30, but pushes an even
older OS (Unix), it gives a hint on their intentions.
0
9/11/2009 8:28:31 PM
On Fri, 11 Sep 2009 16:28:31 -0400, JF Mezei wrote:

> Bob Eager wrote:
> 
>> Perhaps VMS was later than I thought, but 1976 sticks in my mind.
> 
> VMS was late 1978. That is why there was the 30th anniversary last year.
> 
> However, when HP mentions that one OS is old at 30, but pushes an even
> older OS (Unix), it gives a hint on their intentions.

They're about the same really. I doubt that 32 bit UNIX was much earlier 
than that.



-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
9/11/2009 8:56:27 PM
JF Mezei wrote:
> Neil Rieck wrote:
> 
>> I'm not sure who pays for the infrastructure costs at:
>> http://www.openvmshobbyist.org
> 
> 
> David Cathay from Montagar is the one that operates the hobbyist
> programme and we should all be grateful for all that he has done.
> 
> I don't think he gets anything from HP. And with the change in staffing,
> I am not even sure the folks in India know about it.
> 
>> because HP in in for some trouble when all us OpenVMS types retire.
>> Why? Because the younger generation coming up behind us has never
>> heard of OpenVMS which means that more of HP's market will wither on
>> the vine. 
> 
> Why would that be a problem for HP ? In case you haven't yet accepted
> it, HP has essentially already written off VMS. HP clearly doesn't see a
> future for VMS and some VPs have already alluded to the fact that it is
> an old operating system (now that it is more than 30 years old).
> 

Hmmm!!  How old is Unix???????  I think it's a few years older than VMS.

I can't see that the age of an O/S is, by itself, significant.  The 
significant points are:
a. What platform(s) does it run on?
b. What can it do?
c. What can it NOT do?
d. Will your applications build and run on it?
e. What is the cost of licenses, media, administration, and the hardware 
you want to run it on?
f. What level of support is available?
g. What is the cost of the support you need?
h. Is it, in some sense, "better" than the other choices?
0
rgilbert88 (4439)
9/11/2009 9:15:30 PM
Bob Eager <rde42@spamcop.net> wrote:
< On Fri, 11 Sep 2009 15:57:31 -0400, John Reagan wrote:
(snip)

<> The Perkin-Elmer 8/32 (a 32-bit computer) ran a flavor of UNIX and was
<> in the field before the first VAXen.  My former employer had one.  It
<> was the first non-PDP-11 computer to run UNIX.
(snip)
 
< Anyway...I'd be interested in dates. UNIX didn't go (semi-) public until 
< about 1976 (I started using it in July 1976). Not sure about first VMS 
< dates but I thought it was about then. Presumably the PE 8/32 (that was 
< the Interdata later, wasn't it?) post-dates the PDP-11 version going 
< public as v6?

< Perhaps VMS was later than I thought, but 1976 sticks in my mind.

A friend in math class was telling me about VAX in 1976, though
I am not sure it was ready yet.  VMS may have been running internally
in DEC, though.  I remember using VMS, I believe by 1978 or early 1979,
and it still had a lot of bugs.  Also, much of the system utilities
were still running in comparability (sic) mode.  

-- glen
0
gah (12851)
9/11/2009 9:16:06 PM
Bob Koehler wrote:
> In article <0062be6d$0$5080$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>> Excuse my ignorance, but what is so special about "Proliant" ? Aren't
>> they just commodity machines that HP could have built all by itself
>> without needing to buy Compaq ?
> 
>    Could have, but didn't.  Reminds me when Olivetti designed a new
>    typewriter by designing the case first (my grey hair showing).
> 

Many years ago somebody published a document about the "Product 
Development Cycle".

It read something like this:

1. Announce the product.
2. Design the package
3. Announce the product
4. Redesign the package
5. Announce the product
6. Redesign the package
7. Announce the product.
8. Design the prototype.
9. Announce the product.
10. Build the prototype.
11. Announce the product.
etc.
0
rgilbert88 (4439)
9/11/2009 9:24:30 PM
Bob Eager wrote:
> On Fri, 11 Sep 2009 15:57:31 -0400, John Reagan wrote:
> 
>> "Bob Eager" <rde42@spamcop.net> wrote in message
>> news:7gvj6hF2ricj3U4@mid.individual.net...
>>> On Fri, 11 Sep 2009 17:46:35 +0200, Michael Kraemer wrote:
>>>
>>>> Paul Anderson schrieb:
>>>>
>>>>
>>>>> Unix is older than VMS but don't confuse me with the facts.  ;-)
>>>> At worst the difference is a few years only (and don't confuse Multics
>>>> with Unix), which is insignificant in hindsight of 30* years.
>>> Anyway, 32 bit UNIX didn't arrive until *after* VMS. One would have to
>>> compare early UNIX (even on the PDP-11) with 16 bit VMS (or RSX-11, as
>>> we know it)! :-)
>> The Perkin-Elmer 8/32 (a 32-bit computer) ran a flavor of UNIX and was
>> in the field before the first VAXen.  My former employer had one.  It
>> was the first non-PDP-11 computer to run UNIX.
> 
> <pedant>
> UNIX first appeared on the PDP-7, in around 1970. OK, it was written in 
> assembler...!
> </pedant>
> 
> Anyway...I'd be interested in dates. UNIX didn't go (semi-) public until 
> about 1976 (I started using it in July 1976). Not sure about first VMS 
> dates but I thought it was about then. Presumably the PE 8/32 (that was 
> the Interdata later, wasn't it?) post-dates the PDP-11 version going 
> public as v6?
> 
> Perhaps VMS was later than I thought, but 1976 sticks in my mind.
> 
> 
> 
> 

Try 1978 for VMS and the VAX 11/780.  First customer shipment could have 
been WAY after that but I think 1978 is a good date for the hardware and 
software.
0
rgilbert88 (4439)
9/11/2009 9:32:30 PM
On Sep 11, 5:47=A0am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> Neil Rieck wrote:
> > I'm not sure who pays for the infrastructure costs at:
> >http://www.openvmshobbyist.org
>
> David Cathay from Montagar is the one that operates the hobbyist
> programme and we should all be grateful for all that he has done.
>
> I don't think he gets anything from HP. And with the change in staffing,
> I am not even sure the folks in India know about it.
>
> > because HP in in for some trouble when all us OpenVMS types retire.
> > Why? Because the younger generation coming up behind us has never
> > heard of OpenVMS which means that more of HP's market will wither on
> > the vine.
>
> Why would that be a problem for HP ? In case you haven't yet accepted
> it, HP has essentially already written off VMS. HP clearly doesn't see a
> future for VMS and some VPs have already alluded to the fact that it is
> an old operating system (now that it is more than 30 years old).
>
> With Sun gone, HP has high hopes that it can retain a large percentage
> of the remaining VMS customers when they realise there is no future for
> VMS. =A0For most, the signs have been there and quire evident for some
> time, but HP will need to ratchet up the font size to make the message
> clearer for those few who still believe that HP has great plans for VMS.

I get your point but don't fully agree with it. HP hasn't written off
OpenVMS, they just ignore it because they don't know what it is (sort
of like the young people at my employer's company; at one time or
another they all used Windows while a smaller number used UNIX/Linux.)
I'm sure HP execs are thankful for any OpenVMS-related income but they
know it happens with little effort on HP's part (aka customer
inertia). The problem with inertia related motion is that it always
runs down on the surface of the Earth.

NSR
0
n.rieck (2007)
9/11/2009 10:20:41 PM
On Sep 11, 9:25=A0am, "John Reagan" <johnrrea...@earthlink.net> wrote:
> "Paul Anderson" <paulrander...@charter.net> wrote in message
>
> news:paulranderson-A9E29B.08433211092009@newsfarm.iad.highwinds-media.com=
....
>
> > In article <00632aa4$0$30091$c3e8...@news.astraweb.com>,
> > JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
>
> >> HP clearly doesn't see a future for VMS and some VPs have already
> >> alluded to the fact that it is an old operating system (now that it
> >> is more than 30 years old).
>
> > Unix is older than VMS but don't confuse me with the facts. =A0;-)
>
> > Paul
>
> Guardian is older than VMS as well. =A0That's what the voices in my head =
tell
> me (along with the facts).
>
> John

By Guardian are you referring to "Colossus and Guardian"? (aka
"Colossus: The Forbin Project")

NSR
0
n.rieck (2007)
9/11/2009 10:26:16 PM
Neil Rieck wrote:
> HP hasn't written off
> OpenVMS, they just ignore it because they don't know what it is 

My opinion is that HP top execs have been told that VMS has no future
and that its only path is downwards. They are maintaining it and welcome
the support dollars as long as they come but have no intention of
spending any money to try to relauch a product with no future.

And the longer this happens, the costlier it would be to bring VMS back
to life and update more and more and more of the subsystems to get it
into a marketable state.

VMS is now like an unfinished renovation project of an office building.
It's got a solid structure and fondation, has running water to some
floors but just some ancient toilets and sinks (applications) in some
places and incompatible electric system (CPU).

There comes a time where it just isn't worth the effort to complete that
renovation when you have a perfectly good and "modern" building with
modern applications next door.
0
9/11/2009 10:34:03 PM
On Sep 11, 6:34=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> Neil Rieck wrote:
> > HP hasn't written off
> > OpenVMS, they just ignore it because they don't know what it is
>
> My opinion is that HP top execs have been told that VMS has no future
> and that its only path is downwards. They are maintaining it and welcome
> the support dollars as long as they come but have no intention of
> spending any money to try to relauch a product with no future.
>
> And the longer this happens, the costlier it would be to bring VMS back
> to life and update more and more and more of the subsystems to get it
> into a marketable state.
>
> VMS is now like an unfinished renovation project of an office building.
> It's got a solid structure and fondation, has running water to some
> floors but just some ancient toilets and sinks (applications) in some
> places and incompatible electric system (CPU).
>
> There comes a time where it just isn't worth the effort to complete that
> renovation when you have a perfectly good and "modern" building with
> modern applications next door.

These points are correct but you must agree that execs at most Western
companies are more interested in making money rather than producing a
technically superior product. For some companies like GM, this started
in 1970 when the financial people stopped the wrench-heads from
running the company every other year. For computer companies like DEC
and Apple, this started when they got rid of their technical founders
(remember when a Pepsi-guy was running things at Apple? Remember how
everyone thought getting rid of Ken Olsen would make DEC better?). Is
is just my imagination or had Microsoft stubbed its toe a few times
since Gates finally stepped down and stepped away? Apple and Oracle
are currently doing really well while their technically-oriented
founders are occupying the top job.

In the open-source world a considerable amount of software development
is being done by the community (IBM is the biggest contributor to
Linux which makes me wonder how they account for this activity;
Microsoft recently donated >20k lines to assist with future
virtualization issues). I don't need to tell anyone here that OpenVMS
is not open-source and won't be anytime soon, so how can HP keep
OpenVMS (barely) alive while still competing with open-source? ANSWER:
move OpenVMS code maintenance to India.

Now "IF" the Asian maintainers of OpenVMS are quietly tasked to do a
port to x86-64, then we will unanimously declare that HP exec were
business geniuses. On the flip side, if the move to India was nothing
more than putting OpenVMS on temporary life support, we will all think
HP execs were just money-motivated greedy bastards.

Time will tell which way the coin falls.

Neil Rieck
Kitchener/Waterloo/Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
0
n.rieck (2007)
9/12/2009 12:17:34 PM
In article <paulranderson-A9E29B.08433211092009@newsfarm.iad.highwinds-media.com>,
	Paul Anderson <paulranderson@charter.net> writes:
> In article <00632aa4$0$30091$c3e8da3@news.astraweb.com>,
>  JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> 
>> HP clearly doesn't see a future for VMS and some VPs have already 
>> alluded to the fact that it is an old operating system (now that it 
>> is more than 30 years old).
> 
> Unix is older than VMS but don't confuse me with the facts.  ;-)

But Linux isn't and people actually think that makes it better.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
9/12/2009 7:48:45 PM
In article <h8dras$p7b$02$1@news.t-online.com>,
	Michael Kraemer <M.Kraemer@gsi.de> writes:
> Paul Anderson schrieb:
> 
>> 
>> Unix is older than VMS but don't confuse me with the facts.  ;-)
> 
> At worst the difference is a few years only
> (and don't confuse Multics with Unix),
> which is insignificant in hindsight of 30* years.

Unix 1969
VMS 1975

That's 6 years.  A lifetime in this industry.

bill
 

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
9/12/2009 7:53:23 PM
In article <7gvq1nF2ricj3U7@mid.individual.net>,
	Bob Eager <rde42@spamcop.net> writes:
> On Fri, 11 Sep 2009 15:57:31 -0400, John Reagan wrote:
> 
>> "Bob Eager" <rde42@spamcop.net> wrote in message
>> news:7gvj6hF2ricj3U4@mid.individual.net...
>>> On Fri, 11 Sep 2009 17:46:35 +0200, Michael Kraemer wrote:
>>>
>>>> Paul Anderson schrieb:
>>>>
>>>>
>>>>> Unix is older than VMS but don't confuse me with the facts.  ;-)
>>>>
>>>> At worst the difference is a few years only (and don't confuse Multics
>>>> with Unix), which is insignificant in hindsight of 30* years.
>>>
>>> Anyway, 32 bit UNIX didn't arrive until *after* VMS. One would have to
>>> compare early UNIX (even on the PDP-11) with 16 bit VMS (or RSX-11, as
>>> we know it)! :-)
>> 
>> The Perkin-Elmer 8/32 (a 32-bit computer) ran a flavor of UNIX and was
>> in the field before the first VAXen.  My former employer had one.  It
>> was the first non-PDP-11 computer to run UNIX.
> 
> <pedant>
> UNIX first appeared on the PDP-7, in around 1970. OK, it was written in 
> assembler...!
> </pedant>

And what does the language it was written in have to do with anythng?

> 
> Anyway...I'd be interested in dates. UNIX didn't go (semi-) public until 
> about 1976 (I started using it in July 1976). 

And what does wether or not it was "public" (whatever that means) have to
do with anything?

>                                                Not sure about first VMS 
> dates but I thought it was about then. Presumably the PE 8/32 (that was 
> the Interdata later, wasn't it?) post-dates the PDP-11 version going 
> public as v6?
> 
> Perhaps VMS was later than I thought, but 1976 sticks in my mind.

Supposedly development started in 1975.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
9/12/2009 7:58:05 PM
John Reagan wrote:

> 
> "Bob Eager" <rde42@spamcop.net> wrote in message
> news:7gvj6hF2ricj3U4@mid.individual.net...
>> On Fri, 11 Sep 2009 17:46:35 +0200, Michael Kraemer wrote:
>>
>>> Paul Anderson schrieb:
>>>
>>>
>>>> Unix is older than VMS but don't confuse me with the facts.  ;-)
>>>
>>> At worst the difference is a few years only (and don't confuse Multics
>>> with Unix), which is insignificant in hindsight of 30* years.
>>
>> Anyway, 32 bit UNIX didn't arrive until *after* VMS. One would have to
>> compare early UNIX (even on the PDP-11) with 16 bit VMS (or RSX-11, as we
>> know it)! :-)
> 
> The Perkin-Elmer 8/32 (a 32-bit computer) ran a flavor of UNIX and was in
> the field before the first VAXen.  My former employer had one.  It was the
> first non-PDP-11 computer to run UNIX.
> 
> John

I remember OS/32 on a PE, didn't seem like UNIX though, maybe it ran both. 
Anyway, as a summer student, I can remember using something like "ME .OP
some text" to message the operator, equivalent to REQUEST in VMS.  One day,
we were getting the op particularly annoyed (there was a window between us
and the operator console) and in her flustered state, she forgot to prefix
her response with "ME" wanting to issue "ME SHUTUP" instead to us.  Unknown
to her, typing SHUTUP at the console invoked a symbol for the shutdown
procedure, an immediate one at that.  The sudden look of horror through the
glass was priceless!

Curtis
0
curtis (20)
9/12/2009 8:48:08 PM
On Sat, 12 Sep 2009 19:48:45 +0000, Bill Gunshannon wrote:

> In article
> <paulranderson-A9E29B.08433211092009@newsfarm.iad.highwinds-media.com>,
> 	Paul Anderson <paulranderson@charter.net> writes:
>> In article <00632aa4$0$30091$c3e8da3@news.astraweb.com>,
>>  JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>> 
>>> HP clearly doesn't see a future for VMS and some VPs have already
>>> alluded to the fact that it is an old operating system (now that it is
>>> more than 30 years old).
>> 
>> Unix is older than VMS but don't confuse me with the facts.  ;-)

Only if you compare 16 bit UNIX and 323 bit VMS. Compare 32 bit UNIX (a 
lot different) and they're much the same.

> But Linux isn't and people actually think that makes it better.

Linux isn't UNIX. It's a jumped up UNIX wannabe.


-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
9/12/2009 10:01:34 PM
Neil Rieck schrieb:

> 
> These points are correct but you must agree that execs at most Western
> companies are more interested in making money rather than producing a
> technically superior product. For some companies like GM, this started
> in 1970 when the financial people stopped the wrench-heads from
> running the company every other year. For computer companies like DEC
> and Apple, this started when they got rid of their technical founders
> (remember when a Pepsi-guy was running things at Apple? Remember how
> everyone thought getting rid of Ken Olsen would make DEC better?). Is
> is just my imagination or had Microsoft stubbed its toe a few times
> since Gates finally stepped down and stepped away? Apple and Oracle
> are currently doing really well while their technically-oriented
> founders are occupying the top job.

I think it's a popular myth that companies only prosper as long
as the techies are on top and go under as soon as the "bean counters"
take over. DEC being a good counterexample, IMHO.
The techie's (non)decisions under Olsen ruined the company
a decade later, not Palmer (anyway, IIRC he was a tech guy himself).
Had the bean counters entered
earlier, they made have brought more economic common sense
to DEC's megalomaniac projects of the late 1980s / early 1990s.
And OTOH it was a Nabisco-guy called Gerstner, a non-techie, who
helped saving IBM.
People say that under Gate's reign M$ nearly missed the Internet wave.
But, unlike DEC's techies, he corrected his mistake early enough.
I wouldn't even think of Gates as being a "techie", his and M$'s
strength is their absolute will to power.

> In the open-source world a considerable amount of software development
> is being done by the community (IBM is the biggest contributor to
> Linux which makes me wonder how they account for this activity;
> Microsoft recently donated >20k lines to assist with future
> virtualization issues). I don't need to tell anyone here that OpenVMS
> is not open-source and won't be anytime soon, so how can HP keep
> OpenVMS (barely) alive while still competing with open-source? ANSWER:
> move OpenVMS code maintenance to India.

Moving to India is a common cost-cutting measure these days.
HP-UX and AIX are already there, AFAIK.

> Now "IF" the Asian maintainers of OpenVMS are quietly tasked to do a
> port to x86-64, then we will unanimously declare that HP exec were
> business geniuses. On the flip side, if the move to India was nothing
> more than putting OpenVMS on temporary life support, we will all think
> HP execs were just money-motivated greedy bastards.

Well, that's what they call "capitalism".

0
M.Kraemer (2048)
9/12/2009 10:23:29 PM
Bill Gunshannon schrieb:
> In article <h8dras$p7b$02$1@news.t-online.com>,
> 	Michael Kraemer <M.Kraemer@gsi.de> writes:
> 
>>Paul Anderson schrieb:
>>
>>
>>>Unix is older than VMS but don't confuse me with the facts.  ;-)
>>
>>At worst the difference is a few years only
>>(and don't confuse Multics with Unix),
>>which is insignificant in hindsight of 30* years.
> 
> 
> Unix 1969

that's Multics, not Unix.

> VMS 1975
> 
> That's 6 years.  A lifetime in this industry.

But not in hindsight of 30+ years.
 From the point of view of a teeny called Windoze 3.x,
both are as old as the hills.

0
M.Kraemer (2048)
9/12/2009 10:26:25 PM
> Put away those silly PAKs
> (or at least offer a general, unlimited one

er, I thought we could do that already :) 


0
9/12/2009 11:18:38 PM
In article 
<paulranderson-A9E29B.08433211092009@newsfarm.iad.highwinds-media.com>,
 Paul Anderson <paulranderson@charter.net> wrote:

> In article <00632aa4$0$30091$c3e8da3@news.astraweb.com>,
>  JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> 
> > HP clearly doesn't see a future for VMS and some VPs have already 
> > alluded to the fact that it is an old operating system (now that it 
> > is more than 30 years old).
> 
> Unix is older than VMS but don't confuse me with the facts.  ;-)
> 

Unix hits 40 this year:

<http://www.serverwatch.com/trends/article.php/3825256/Unix-Hits-the-Big-
Four-Oh.htm>

-- 
Paul Sture
0
paul.nospam (2164)
9/12/2009 11:34:09 PM
Neil Rieck wrote:

> Now "IF" the Asian maintainers of OpenVMS are quietly tasked to do a
> port to x86-64, then we will unanimously declare that HP exec were
> business geniuses.

And I will have to eat many of my words :-( :-( :-(

Seriously though, if HP were contemplating a port of VMS to the 8086,
wouldn't they have kept the main engineering group intact since they
have had plenty of experience (many participated in VAX-alpha and many
more Alpha-IA64) ?

A new group with a much smaller core of experienced people (and one
doesn't know whether that expertise covers all areas of VMS, or just
specific ones) doesn't seem conducive to them starting a large porting
project.

Granted, a porting project does require a lot of grunt work to add
#ifdefs to all modules make a few changes and recompile, but it also
requires a lot of high level expertise to do the core kernel and develop
the boilerplates which the grunts can then apply to all of the simpler
modules.
0
9/13/2009 3:10:16 AM
Michael Kraemer wrote:

> And OTOH it was a Nabisco-guy called Gerstner, a non-techie, who
> helped saving IBM.


Gerstner was not a bean counter. He was a leader. And he was smart
enough to know he didn't know tech that much and knew to rely on
MULTIPLE people for guidance. (this way, he would see the many sides of
a coin).

Capellas was nothing but a bean counter. No leadership, no vision.

Turns out that Palmer was the same except he wasn't even a good bean
counter, he was only good at negotiating bargain basement prices for
DEC's limbs to be sold and cutting staff and terminating software products.
0
9/13/2009 3:27:29 AM
On Sep 12, 8:27=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> Michael Kraemer wrote:
> > And OTOH it was a Nabisco-guy called Gerstner, a non-techie, who
> > helped saving IBM.
>
> Gerstner was not a bean counter. He was a leader

If you are interested in how IBM turned themselves around and thrived,
I suggest:

Big Blues, the Unmaking of IBM.  Paul Carroll.

If I remember correctly it has some very interesting insights into the
whole MS/OS2 fiasco
0
jjgessling (81)
9/13/2009 3:56:48 AM
JF Mezei schrieb:

> Turns out that Palmer was the same except he wasn't even a good bean
> counter, 

IIRC he came from DECs microprocessor business,
and later joined AMD, another microprocessor business.
And AMD is still alive, as far as I can see.

> he was only good at negotiating bargain basement prices for
> DEC's limbs 

maybe they weren't worth more?

> to be sold and cutting staff and terminating software products.

maybe this was the only way to prevent DEC from going under
even earlier than 1998?

0
M.Kraemer (2048)
9/13/2009 8:30:34 AM
In article <h8h74h$ilo$03$2@news.t-online.com>,
	Michael Kraemer <M.Kraemer@gsi.de> writes:
> Bill Gunshannon schrieb:
>> In article <h8dras$p7b$02$1@news.t-online.com>,
>> 	Michael Kraemer <M.Kraemer@gsi.de> writes:
>> 
>>>Paul Anderson schrieb:
>>>
>>>
>>>>Unix is older than VMS but don't confuse me with the facts.  ;-)
>>>
>>>At worst the difference is a few years only
>>>(and don't confuse Multics with Unix),
>>>which is insignificant in hindsight of 30* years.
>> 
>> 
>> Unix 1969
> 
> that's Multics, not Unix.

Actually, it was listed as Unics and I assume this is the very first
attempt which is why I compared it to the 1975 date for VMS which
wasn't a release but the "start of development".  Now, if you want
to only compare finished products.....


> 
>> VMS 1975
>> 
>> That's 6 years.  A lifetime in this industry.
> 
> But not in hindsight of 30+ years.
>  From the point of view of a teeny called Windoze 3.x,
> both are as old as the hills.
 
Never said they weren't but Unix is definitely the older brother.
More importantly, one shold probably look at all the OSes that have
come and gone, some not even lasting that measly 6 years.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
9/13/2009 12:14:54 PM
In article <7h2k1uF2ricj3U12@mid.individual.net>,
	Bob Eager <rde42@spamcop.net> writes:
> On Sat, 12 Sep 2009 19:48:45 +0000, Bill Gunshannon wrote:
> 
>> In article
>> <paulranderson-A9E29B.08433211092009@newsfarm.iad.highwinds-media.com>,
>> 	Paul Anderson <paulranderson@charter.net> writes:
>>> In article <00632aa4$0$30091$c3e8da3@news.astraweb.com>,
>>>  JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>>> 
>>>> HP clearly doesn't see a future for VMS and some VPs have already
>>>> alluded to the fact that it is an old operating system (now that it is
>>>> more than 30 years old).
>>> 
>>> Unix is older than VMS but don't confuse me with the facts.  ;-)
> 
> Only if you compare 16 bit UNIX and 323 bit VMS. Compare 32 bit UNIX (a 
> lot different) and they're much the same.

What does the size of a word have to do with the whole discussion?
Or do you think that 32 bit Unix should have been created before
there was a machine to run it on?   I guess a good question would
be was VMS officially released before the first VAX implementation
of Unix was competed?

> 
>> But Linux isn't and people actually think that makes it better.
> 
> Linux isn't UNIX. It's a jumped up UNIX wannabe.
 
And where in the above statement did I say Linux is Unix?  If you
read here often you would know that I have always stated that Linux
is an inferior attempt to clone Unix.  I was merely point out that
the average person in this industry today places little value on
research and thinks younger is better. 

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
9/13/2009 12:20:23 PM
On Sun, 13 Sep 2009 12:14:54 +0000, Bill Gunshannon wrote:

>>> Unix 1969
>> 
>> that's Multics, not Unix.
> 
> Actually, it was listed as Unics and I assume this is the very first
> attempt which is why I compared it to the 1975 date for VMS which wasn't
> a release but the "start of development".  Now, if you want to only
> compare finished products.....

Surely the first attempt at VMS was a lot earlier....RSX?

RSX bears the same relation to VMS that Unics does to the 32 bit UNIX 
systems.



-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
9/13/2009 12:20:53 PM
In article <7h46d5F2s72n0U3@mid.individual.net>,
	Bob Eager <rde42@spamcop.net> writes:
> On Sun, 13 Sep 2009 12:14:54 +0000, Bill Gunshannon wrote:
> 
>>>> Unix 1969
>>> 
>>> that's Multics, not Unix.
>> 
>> Actually, it was listed as Unics and I assume this is the very first
>> attempt which is why I compared it to the 1975 date for VMS which wasn't
>> a release but the "start of development".  Now, if you want to only
>> compare finished products.....
> 
> Surely the first attempt at VMS was a lot earlier....RSX?

I hear this here quite a bit, but I see little in common betweem them.
(At the actual OS level.)

> 
> RSX bears the same relation to VMS that Unics does to the 32 bit UNIX 
> systems.
 
 woudl expect that there is much more in common between 16 bit and 32 bit
Unix than between RSX and VMS (do they actually share any code?)

bill 
 

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
9/13/2009 12:29:10 PM
On Sun, 13 Sep 2009 12:20:23 +0000, Bill Gunshannon wrote:

> What does the size of a word have to do with the whole discussion? Or do
> you think that 32 bit Unix should have been created before there was a
> machine to run it on?   I guess a good question would be was VMS
> officially released before the first VAX implementation of Unix was
> competed?

I think it was...so UNIX is newer!

>>> But Linux isn't and people actually think that makes it better.
>> 
>> Linux isn't UNIX. It's a jumped up UNIX wannabe.
>  
> And where in the above statement did I say Linux is Unix?

I was just agreeing with you.




-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
9/13/2009 1:11:24 PM
In article <h8dras$p7b$02$1@news.t-online.com>, Michael Kraemer <M.Kraemer@gsi.de> writes:
> 
> At worst the difference is a few years only

   It's a lot closer to a decade than any meaning of a "few years" that
   I would recognize.

0
koehler2 (8314)
9/14/2009 2:42:28 PM
In article <7gvj6hF2ricj3U4@mid.individual.net>, Bob Eager <rde42@spamcop.net> writes:
> 
> Anyway, 32 bit UNIX didn't arrive until *after* VMS. One would have to 
> compare early UNIX (even on the PDP-11) with 16 bit VMS (or RSX-11, as we 
> know it)! :-)

   Why?  The kernel design, file system design, and basic user interface
   design hasn't changed since 16 bit UNIX.

   Don't bother with X11 as a claim to a better user interface.  The
   fist thing UNIX users do with an X11 interface is bring up a shell
   window.

0
koehler2 (8314)
9/14/2009 2:44:22 PM
On Mon, 14 Sep 2009 09:44:22 -0500, Bob Koehler wrote:

> In article <7gvj6hF2ricj3U4@mid.individual.net>, Bob Eager
> <rde42@spamcop.net> writes:
>> 
>> Anyway, 32 bit UNIX didn't arrive until *after* VMS. One would have to
>> compare early UNIX (even on the PDP-11) with 16 bit VMS (or RSX-11, as
>> we know it)! :-)
> 
>    Why?  The kernel design, file system design, and basic user interface
>    design hasn't changed since 16 bit UNIX.
> 
>    Don't bother with X11 as a claim to a better user interface.  The
>    fist thing UNIX users do with an X11 interface is bring up a shell
>    window.

You fall into the trap of thinking that all 'UNIX' is UNIX. Which 
particular UNIX were you thinking of?

Lots has changed - more than VMS has. I would dispute the kernel and file 
system statements, for a start.



-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
9/14/2009 5:04:26 PM
In article <iIdNn9wAvFHE@eisner.encompasserve.org>,
koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <h8dras$p7b$02$1@news.t-online.com>, Michael Kraemer
> <M.Kraemer@gsi.de> writes:
> > 
> > At worst the difference is a few years only
> 
>    It's a lot closer to a decade than any meaning of a "few years" that
>    I would recognize.
> 

1975/76 vs 1978 (as we have learned here) certainly is more
a "few years" than a decade.

0
M.Kraemer (2048)
9/14/2009 5:47:32 PM
Bob Eager wrote:

> Lots has changed - more than VMS has. I would dispute the kernel and file 
> system statements, for a start.

It doesn't matter. Lots has changed with the Chevrolet Malibu, but the
brand has existed for decades.

Unix, as a brand, has existed for much longr than VMS. It has seen
makeovers of its looks, makeover of its engine and transmission, but it
remains Unix.

It retains the same basic set of commands liks "ls" and "cat" and in the
end, this is what defines unix.
0
9/14/2009 7:13:28 PM
On Mon, 14 Sep 2009 15:13:28 -0400, JF Mezei wrote:

> Bob Eager wrote:
> 
>> Lots has changed - more than VMS has. I would dispute the kernel and
>> file system statements, for a start.
> 
> It doesn't matter. Lots has changed with the Chevrolet Malibu, but the
> brand has existed for decades.
> 
> Unix, as a brand, has existed for much longr than VMS. It has seen
> makeovers of its looks, makeover of its engine and transmission, but it
> remains Unix.
> 
> It retains the same basic set of commands liks "ls" and "cat" and in the
> end, this is what defines unix.

I didn't disagree with that part, did I?

I was talking about kernel and file system, which are nothing like the 
originals.

Not to mention that probably a higher percentage of 'UNIX' users than VMS 
users use the command line very little, so the basic commands are far 
less relevant.

-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
9/14/2009 8:18:54 PM
Richard B. Gilbert wrote:

> 
> Many years ago somebody published a document about the "Product 
> Development Cycle".
> 
> It read something like this:
> 
> 1. Announce the product.
> 2. Design the package
> 3. Announce the product
> 4. Redesign the package
> 5. Announce the product
> 6. Redesign the package
> 7. Announce the product.
> 8. Design the prototype.
> 9. Announce the product.
> 10. Build the prototype.
> 11. Announce the product.
> etc.

Of course, engineers do it like this:

1) Understand and spec the requirements
2) Design and implement a solution
3) Prototype and test against 1)
4) Loop until correct
5) Build and ship the product
6) Customer happy, company rich

Dec css was like that and there were even more steps. Many companies 
still are, surprisingly :-)...

Regards,

Chris
0
blackhole5 (113)
9/14/2009 8:44:07 PM
In article <GZxA0FMEhsxA@eisner.encompasserve.org>,
	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <7gvj6hF2ricj3U4@mid.individual.net>, Bob Eager <rde42@spamcop.net> writes:
>> 
>> Anyway, 32 bit UNIX didn't arrive until *after* VMS. One would have to 
>> compare early UNIX (even on the PDP-11) with 16 bit VMS (or RSX-11, as we 
>> know it)! :-)
> 
>    Why?  The kernel design, file system design, and basic user interface
>    design hasn't changed since 16 bit UNIX.
> 
>    Don't bother with X11 as a claim to a better user interface.  The
>    fist thing UNIX users do with an X11 interface is bring up a shell
>    window.
 
Still passing out that FUD, I see.  I have been a Unix user since the late
70's and an X user since X10.  I bring up a shell window when the task that
needs to be done is a shell task and I use a GUI Window when that is the
appropriate inerface.  And, I expect the majority of real Unix users are
and alwyas have been the same.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
9/14/2009 8:46:35 PM
JF Mezei wrote:
> re Unix used as command line.
> 
> Note that Apple has sold about 50 million Iphone and IpodTouch. Both are
> based on Unix (freebsd), and neither offer a command line and are 100%
> GUI. Add to that the millions of OS-X machines Apple has sold which are,
> in the majority of cases, used exclusively as a GUI, and I would say
> that today, the majority of Unix users don't even know they are on Unix
> because they are sheltered from stuff like "ls" and "vi" because of a
> well developped GUI.
> 
> And think about all of the routers and industrial devices which are
> based on unix/linux and offer no "unix command line" access.
> 
> And for those who do use command line, while there may be significant
> kernel differences, various brands of Unix offer a pretty common command
> line shells. And in the end, that is what defines what Unix is, just
> like the $ prompt and the command syntax and argument parsing define how
> you interface with VMS.

You could argue that unix like os's are the most ubiquitous on the 
planet. All from the same root set of ideas, though widely variant in 
internals and user interfaces. Despite the differences, usefull code 
written to run on one, invariably gets ported to run on the rest, often 
with few changes.

Before X, unix was command line only and it's still the best way to get 
some work done. The gui is worth its weight in gold though. For example, 
I can have a box of 10 fc drives, and run 10 shells and instances of 
format to format and bad block all the drives at once. All this while 
editing source, reading mail, browsing the web, writing to newsgroups etc.

It's come a long way since Ultrix and 4.3 bsd...

Regards,

Chris


0
blackhole5 (113)
9/14/2009 9:16:20 PM
On Sep 14, 8:13=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> Bob Eager wrote:
> > Lots has changed - more than VMS has. I would dispute the kernel and fi=
le
> > system statements, for a start.
>
> It doesn't matter. Lots has changed with the Chevrolet Malibu, but the
> brand has existed for decades.
>
> Unix, as a brand, has existed for much longr than VMS. It has seen
> makeovers of its looks, makeover of its engine and transmission, but it
> remains Unix.
>
> It retains the same basic set of commands liks "ls" and "cat" and in the
> end, this is what defines unix.

If the industry at large had any sense, what defined Unix would be
conformance to a specification such asThe Open Group's Single Unix
Specification. The Open Group also own the UNIX trademark, which is
handy.

Strictly speaking, Linux is only a kernel. The OS as a whole should be
known as GNU/Linux.

GNU is of course an acronym: GNU's *NOT* UNIX.

Clearer now? Of course not, but does it matter, Windows 7 is on the
way, and Vista will soon be forgiven...
0
9/14/2009 9:21:02 PM
On Mon, 14 Sep 2009 20:46:35 +0000, Bill Gunshannon wrote:

> In article <GZxA0FMEhsxA@eisner.encompasserve.org>,
> 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>> In article <7gvj6hF2ricj3U4@mid.individual.net>, Bob Eager
>> <rde42@spamcop.net> writes:
>>> 
>>> Anyway, 32 bit UNIX didn't arrive until *after* VMS. One would have to
>>> compare early UNIX (even on the PDP-11) with 16 bit VMS (or RSX-11, as
>>> we know it)! :-)
>> 
>>    Why?  The kernel design, file system design, and basic user
>>    interface design hasn't changed since 16 bit UNIX.
>> 
>>    Don't bother with X11 as a claim to a better user interface.  The
>>    fist thing UNIX users do with an X11 interface is bring up a shell
>>    window.
>  
> Still passing out that FUD, I see.  I have been a Unix user since the
> late 70's and an X user since X10.  I bring up a shell window when the
> task that needs to be done is a shell task and I use a GUI Window when
> that is the appropriate inerface.  And, I expect the majority of real
> Unix users are and alwyas have been the same.

I agree. I currently have windows:

Newsreader (multiple)
Mail client (two)
Web browser (several)
System monitor
Console window (mainly for managing servers that don't have X)

Plus panels with icons, clock, etc.

I use the console window on this machine for programming, mainly.

And I've been using 'UNIX' since 1976. I only used UNIX (without the 
quotes) for about four years; then it was BSD, and still is.



-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
9/14/2009 9:21:09 PM
re Unix used as command line.

Note that Apple has sold about 50 million Iphone and IpodTouch. Both are
based on Unix (freebsd), and neither offer a command line and are 100%
GUI. Add to that the millions of OS-X machines Apple has sold which are,
in the majority of cases, used exclusively as a GUI, and I would say
that today, the majority of Unix users don't even know they are on Unix
because they are sheltered from stuff like "ls" and "vi" because of a
well developped GUI.

And think about all of the routers and industrial devices which are
based on unix/linux and offer no "unix command line" access.

And for those who do use command line, while there may be significant
kernel differences, various brands of Unix offer a pretty common command
line shells. And in the end, that is what defines what Unix is, just
like the $ prompt and the command syntax and argument parsing define how
you interface with VMS.

0
9/14/2009 9:48:08 PM
In article <7h7bcqF2s72n0U14@mid.individual.net>, Bob Eager <rde42@spamcop.net> writes:
> 
> You fall into the trap of thinking that all 'UNIX' is UNIX. Which 
> particular UNIX were you thinking of?

   "UNIX is the portable operating system that's different on
   every platform."  I'm sure someone will claim to know who said
   that first.

   However, 16 bit and 32 bit UNIX are two mode OS with the habit of
   forking all over the place.  These are just two examples of kernel
   design that haven't changed since the late 60s, when such were popular
   in timesharing OS design.

> Lots has changed - more than VMS has. I would dispute the kernel and file 
> system statements, for a start.

   UNIX file system internals have been re-implemented for a large number 
   of reasons that the end user can't see.  Externals remain the same, as
   does the on-size-fits-all file-as-a-stream-of-bytes.

   VMS, on the other hand, has changed file name sizes from 9.3 to just
   about any length, from uppercase storing case insensitive to case
   preserving with a choice between case sensitive and case insensitive,
   added ACLs to the protection implementation, and added stream (crlf),
   stream-lf, stream-cr file formats, added hard links, and added mount
   points.

   And that's a pretty short list of what's changed, and only reflects
   some of the file system changes visible to the user.

0
koehler2 (8314)
9/15/2009 1:38:11 PM
In article <h8lvjk$5db$1@lnx107.hrz.tu-darmstadt.de>, m.kraemer@gsi.de (Michael Kraemer) writes:
> 
> 1975/76 vs 1978 (as we have learned here) certainly is more
> a "few years" than a decade.
> 

   As we have learned, here and elsewhere, Ken Thompson of Bell Labs
   wrote UNIX in 1968, while the VMS Engineering team of DEC wrote
   VMS in the late 1970s, just about a decade later.

   When it shipped to the public by some measure does not reflect the
   OS design technology at the time it was written.  UNIX relfects
   designs popular in the late 60s, VMS reflects 10 more years of
   lessons learned.

0
koehler2 (8314)
9/15/2009 1:46:03 PM
In article <7h7odbF2sp05bU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:

>  I bring up a shell window when the task that
> needs to be done is a shell task and I use a GUI Window when that is the
> appropriate inerface.

   A GUI window that provides access only to an application and not the
   underlying reflects the application's user interface design more that 
   the OS's, and can be similar on just about any OS.

   Just compare Java Swing apps using the Java interface on Solaris,
   Windows, Mac OS, and VMS to see the truth of this.

0
koehler2 (8314)
9/15/2009 1:50:06 PM
In article <7h7qe4F2s72n0U22@mid.individual.net>, Bob Eager <rde42@spamcop.net> writes:
> 
> I agree. I currently have windows:
> 
> Newsreader (multiple)
> Mail client (two)
> Web browser (several)
> System monitor
> Console window (mainly for managing servers that don't have X)
> 
> Plus panels with icons, clock, etc.

   So you can't distinguish between your application's windows and the
   OS?

0
koehler2 (8314)
9/15/2009 1:51:08 PM
In article <0067c82e$0$30049$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> re Unix used as command line.
> 
> Note that Apple has sold about 50 million Iphone and IpodTouch. Both are
> based on Unix (freebsd), and neither offer a command line and are 100%
> GUI.

   Niether iPhone not iPod are UNIX.  Naturally Apple did a better job
   of designing the application interfaces than expecting its users to
   bring up UNIX shells.

0
koehler2 (8314)
9/15/2009 1:52:58 PM
In article <CzBBRcR308Gv@eisner.encompasserve.org>,
	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <7h7bcqF2s72n0U14@mid.individual.net>, Bob Eager <rde42@spamcop.net> writes:
>> 
>> You fall into the trap of thinking that all 'UNIX' is UNIX. Which 
>> particular UNIX were you thinking of?
> 
>    "UNIX is the portable operating system that's different on
>    every platform."  I'm sure someone will claim to know who said
>    that first.

I have always prefered:
  "Those who do not understand Unix are condemned to reinvent it, poorly"
                                                    Henry Spencer

As has been adequately demonstrated by Linux.

> 
>    However, 16 bit and 32 bit UNIX are two mode OS with the habit of
>    forking all over the place.  These are just two examples of kernel
>    design that haven't changed since the late 60s, when such were popular
>    in timesharing OS design.
> 
>> Lots has changed - more than VMS has. I would dispute the kernel and file 
>> system statements, for a start.
> 
>    UNIX file system internals have been re-implemented for a large number 
>    of reasons that the end user can't see.  Externals remain the same, as
>    does the on-size-fits-all file-as-a-stream-of-bytes.
> 
>    VMS, on the other hand, has changed file name sizes from 9.3 to just
>    about any length, from uppercase storing case insensitive to case
>    preserving with a choice between case sensitive and case insensitive,

Interesting how the first two improvements to VMS you chose to present 
have been standard on Unix all along.  :-)

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
9/15/2009 4:07:58 PM
On Tue, 15 Sep 2009 08:38:11 -0500, Bob Koehler wrote:

>    However, 16 bit and 32 bit UNIX are two mode OS with the habit of
>    forking all over the place.  These are just two examples of kernel
>    design that haven't changed since the late 60s, when such were
>    popular in timesharing OS design.

Actually, I believe UNIX was the one who started it.

>> Lots has changed - more than VMS has. I would dispute the kernel and
>> file system statements, for a start.
> 
>    UNIX file system internals have been re-implemented for a large
>    number of reasons that the end user can't see.  Externals remain the
>    same, as does the on-size-fits-all file-as-a-stream-of-bytes.
> 
>    VMS, on the other hand, has changed file name sizes from 9.3 to just
>    about any length, from uppercase storing case insensitive to case
>    preserving with a choice between case sensitive and case insensitive,

UNIX started with 14 character filenames.

>    added ACLs to the protection implementation

So has UNIX.

>    added hard links

UNIX had them already, and added soft links.

>    added mount points.

Which UNIX had already. Difficult to say that UNIX 'hasn't changed' in 
some areas when VMS is just playing catchup, though.

-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
9/15/2009 4:09:14 PM
In article <q6udTSzh5pjp@eisner.encompasserve.org>,
	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <h8lvjk$5db$1@lnx107.hrz.tu-darmstadt.de>, m.kraemer@gsi.de (Michael Kraemer) writes:
>> 
>> 1975/76 vs 1978 (as we have learned here) certainly is more
>> a "few years" than a decade.
>> 
> 
>    As we have learned, here and elsewhere, Ken Thompson of Bell Labs
>    wrote UNIX in 1968, while the VMS Engineering team of DEC wrote
>    VMS in the late 1970s, just about a decade later.
> 
>    When it shipped to the public by some measure does not reflect the
>    OS design technology at the time it was written.  UNIX relfects
>    designs popular in the late 60s, VMS reflects 10 more years of
>    lessons learned.

Tha is, if one believes that Unix remained static during its lifetime, which
we all know is hardly the case.  Things that needed changing have changed.
Things that did not have remained the same.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
9/15/2009 4:10:15 PM
On Tue, 15 Sep 2009 08:51:08 -0500, Bob Koehler wrote:

> In article <7h7qe4F2s72n0U22@mid.individual.net>, Bob Eager
> <rde42@spamcop.net> writes:
>> 
>> I agree. I currently have windows:
>> 
>> Newsreader (multiple)
>> Mail client (two)
>> Web browser (several)
>> System monitor
>> Console window (mainly for managing servers that don't have X)
>> 
>> Plus panels with icons, clock, etc.
> 
>    So you can't distinguish between your application's windows and the
>    OS?

I don't even understand the point you are trying to make. My point (and 
someoen else's too) is that these days, UNIX users are not wedded to the 
command prompt. I'm using 'UNIX' right now, but this is not a text-window 
newsreader.



-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
9/15/2009 4:10:55 PM
Bob Koehler wrote:

>    Niether iPhone not iPod are UNIX.  Naturally Apple did a better job
>    of designing the application interfaces than expecting its users to
>    bring up UNIX shells.
> 


iphone and ipodtouch run OS-X. OS-X is unix.
0
9/15/2009 7:05:11 PM
In article <4DldpVv7nDPQ@eisner.encompasserve.org>,
	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <0067c82e$0$30049$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>> re Unix used as command line.
>> 
>> Note that Apple has sold about 50 million Iphone and IpodTouch. Both are
>> based on Unix (freebsd), and neither offer a command line and are 100%
>> GUI.
> 
>    Niether iPhone not iPod are UNIX.  

Couldn't find anything about the OS in an iPod but the iPhone is OSX
which I think qualifies as Unix.

>                                       Naturally Apple did a better job
>    of designing the application interfaces than expecting its users to
>    bring up UNIX shells.

You just won't accept that there are other ways tio us Unix than a shell,
will you.  At least there has been since the TTY went away.  :-)
 
bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
9/16/2009 12:42:27 AM
On Wed, 02 Sep 2009 03:42:32 GMT, Curtis Rempel
<curtis@no.spam.here.telus.net> wrote:

>Looks like another VMS casualty:
>
>http://blogs.computerworld.com/14637/linux_powers_worlds_fastest_stock_exchange

One reason VMS was so secure was it was so useless when it came to the
Internet.   Apache with Mod Perl is a nightmare.  It has a CGI module,
that just does not work and does not support threads.  Most Ftp
clients don't recognize VMS.   Even DOS was more powerful when it came
to the internet applications than VMS, and was easier to use.  Batch
files in DOS and shell scripts in Unix are easier to read and write
than scripts in VMS. 

Given the way the company has been passed around over the years, I am
surprised that HP has not pulled the plug on VMS.  IBM pulled the plug
on OSII, and it was a lot more reliable than Windows. (When a former
Ford Auto board member becomes the CEO of IBM, then don't expect
anything visionary to come from IBM). 

Good bye VMS!   Good riddance COBOL.
0
nospam117 (1)
9/16/2009 4:15:35 AM
On Sep 16, 5:15=A0am, Judge Judy <nos...@shaw.com> wrote:
> On Wed, 02 Sep 2009 03:42:32 GMT, Curtis Rempel
>
> <cur...@no.spam.here.telus.net> wrote:
> >Looks like another VMS casualty:
>
> >http://blogs.computerworld.com/14637/linux_powers_worlds_fastest_stoc...
>
> One reason VMS was so secure was it was so useless when it came to the
> Internet. =A0 Apache with Mod Perl is a nightmare. =A0It has a CGI module=
,
> that just does not work and does not support threads. =A0Most Ftp
> clients don't recognize VMS. =A0 Even DOS was more powerful when it came
> to the internet applications than VMS, and was easier to use. =A0Batch
> files in DOS and shell scripts in Unix are easier to read and write
> than scripts in VMS.

Well I can't comment on the Web Server support, but come on, batch
scripts are easier to read and write in Unix and DOS! I really cannot
agree with that. Have you seen the average bash script that needs to
do something anything other than trivial? Maybe you're comparing the
noddy scripts you can write with the DOS batch language compared with
DCL? Please explain your comment about DOS and internet applications
because that simply doesn't compute. Have you ever tried to get DOS to
talk to a network, let alone the internet?

Listen, I sit firmly on the fence between Unix and VMS and love both
for different reasons, but DCL is much more readable that sh/bash/bat
any day of the week.
0
mark525 (244)
9/16/2009 9:39:05 AM
Bob Eager wrote:
> On Wed, 16 Sep 2009 02:39:05 -0700, urbancamo wrote:
> 
>> Listen, I sit firmly on the fence between Unix and VMS and love both for
>> different reasons, but DCL is much more readable that sh/bash/bat any
>> day of the week.
> 
> Same here. I use both.
> 
> I've been shell programming for 33 years, and I still don't like it (it's 
> just got more complicated). I write most of my 'UNIX' scripts in REXX!
> 
> 

I became reasonably competent in dcl in the days when I used vms, but 
the big problem was that it was not portable. Software development of 
any kind is labour intensive and expensive. One of the major advantages 
of the unix family is portability. I can take just about any app or 
shell script from one flavour to another and have a fair degree of 
confidence that it will compile and run with not much change. I suspect 
that this is also the reason why open source has become the driving 
force that it is now.

It's not all bad news though - I understand that vms has recently had a 
big win recently for the uk national health service. That could be a lot 
of business :-)...

Regards,

Chris
0
blackhole5 (113)
9/16/2009 9:46:56 AM
On Wed, 16 Sep 2009 02:39:05 -0700, urbancamo wrote:

> Listen, I sit firmly on the fence between Unix and VMS and love both for
> different reasons, but DCL is much more readable that sh/bash/bat any
> day of the week.

Same here. I use both.

I've been shell programming for 33 years, and I still don't like it (it's 
just got more complicated). I write most of my 'UNIX' scripts in REXX!


-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
9/16/2009 10:08:31 AM
R.A.Omond wrote:
> ChrisQ wrote:
>> [...snip...]
>> It's not all bad news though - I understand that vms has recently had 
>> a big win recently for the uk national health service. That could be a 
>> lot of business :-)...
> 
> Link ?
> 
> or are you referring to the National Blood Transfusion bank stuff
> that Colin Butcher (Xdelta) was involved in ?

It may have been. I forget where I saw the report, but noticed it 
specifically because it mentioned vms. It may have been one of the hp sites.

Vms should be ideal for this sort of work. Robust, very secure and with 
decades of rigorous development behind it. It's a shame its not more 
visible elsewhere...

Regards,

Chris
0
blackhole5 (113)
9/16/2009 10:09:01 AM
ChrisQ wrote:
> [...snip...]
> It's not all bad news though - I understand that vms has recently had a 
> big win recently for the uk national health service. That could be a lot 
> of business :-)...

Link ?

or are you referring to the National Blood Transfusion bank stuff
that Colin Butcher (Xdelta) was involved in ?
0
Roy.Omond (380)
9/16/2009 10:43:29 AM
In article <pdn0b5tbfum015s3pdbdpv99lb1e11aras@4ax.com>, Judge Judy <nospam@shaw.com> writes:
>On Wed, 02 Sep 2009 03:42:32 GMT, Curtis Rempel
><curtis@no.spam.here.telus.net> wrote:
>
>>Looks like another VMS casualty:
>>
>>http://blogs.computerworld.com/14637/linux_powers_worlds_fastest_stock_exchange
>
>One reason VMS was so secure was it was so useless when it came to the
>Internet.   Apache with Mod Perl is a nightmare.  It has a CGI module,
>that just does not work and does not support threads.  Most Ftp

Apache and Perl are applications; not the OS.


>clients don't recognize VMS.   Even DOS was more powerful when it came

I've never had any FTP issues.  This is, of course, not a VMS issue
either.  It's an issue with the stupid FTP clients that assume, and
wrongly, that all the world is *ix.  They should adhere to the RFCs
and stop the idiocy of parsing the listing format as if *ix are the
only FTP servers on the net.


>to the internet applications than VMS, and was easier to use.  Batch
>files in DOS and shell scripts in Unix are easier to read and write
>than scripts in VMS. 

You are biased because you know shell scripting.  DOS?  On the inter-
net?  I don't think so.  Go back to your Minesweeper.


>Given the way the company has been passed around over the years, I am
>surprised that HP has not pulled the plug on VMS.  IBM pulled the plug
>on OSII, and it was a lot more reliable than Windows. (When a former
>Ford Auto board member becomes the CEO of IBM, then don't expect
>anything visionary to come from IBM). 

Here's the "50 billion flies eating shit means it should be palatable
for all" argument again.


>Good bye VMS!   Good riddance COBOL.

Troll...  

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

  http://www.quirkfactory.com/popart/asskey/eqn2.png
  
  "Well my son, life is like a beanstalk, isn't it?"
0
VAXman
9/16/2009 11:01:14 AM
HI Brian,

<VAXman- @SendSpamHere.ORG> wrote in message
news:00A91A23.F17F6804@SendSpamHere.ORG...
> In article <pdn0b5tbfum015s3pdbdpv99lb1e11aras@4ax.com>, Judge Judy
<nospam@shaw.com> writes:
> >Good bye VMS!   Good riddance COBOL.
>
> Troll...
>
For the record, you are responding to someone who is happy to go my the
moniker Judge Judy. (Which I dare say is aspirational :-)
> -- 
Cheers Richard Maher


0
maher_rj (1626)
9/16/2009 11:56:38 AM
ChrisQ wrote:
> R.A.Omond wrote:
>> ChrisQ wrote:
>>> [...snip...]
>>> It's not all bad news though - I understand that vms has recently had 
>>> a big win recently for the uk national health service. That could be 
>>> a lot of business :-)...
>>
>> Link ?
>>
>> or are you referring to the National Blood Transfusion bank stuff
>> that Colin Butcher (Xdelta) was involved in ?
> 
> It may have been. I forget where I saw the report, but noticed it 
> specifically because it mentioned vms. It may have been one of the hp 
> sites.
> 
> Vms should be ideal for this sort of work. Robust, very secure and with 
> decades of rigorous development behind it. It's a shame its not more 
> visible elsewhere...

I expect it was Colin's stuff that you saw.

However, just a little comment:  there is still a lot of VMS
prevalent within the NHS (I deal with many such sites). Many
of them are quite elegantly setup e.g. in 3-site split clusters.
Even though I've heard the old, old story that they will be
replaced within the next 6 months, I've heard the exact same
story for the last 10 years ...
0
Roy.Omond (380)
9/16/2009 12:02:12 PM
In article <pdn0b5tbfum015s3pdbdpv99lb1e11aras@4ax.com>,
 Judge Judy <nospam@shaw.com> wrote:

> Batch files in DOS and shell scripts in Unix are easier to read and 
> write than scripts in VMS.

You must have no experience with DCL then.  Thanks for giving me my 
first laugh of the day!

Paul
0
9/16/2009 12:14:58 PM
In article <7h9shaF2svb63U1@mid.individual.net>, Bob Eager <rde42@spamcop.net> writes:
> On Tue, 15 Sep 2009 08:38:11 -0500, Bob Koehler wrote:
> 
>>    added ACLs to the protection implementation
> 
> So has UNIX.
>
   I've seen them on HP-UX, but not on all UNIX.  SO I'm under the
   impression "UNIX" has not.

>>    added hard links
> 
> UNIX had them already, and added soft links.
> 
>>    added mount points.
> 
> Which UNIX had already. Difficult to say that UNIX 'hasn't changed' in 
> some areas when VMS is just playing catchup, though.

   That which UNIX already has doesn't sound like proof that UNIX is
   changing.  That which VMS is adding certainly does sound like VMS
   is changing.  Who had it first doesn't matter.

0
koehler2 (8314)
9/16/2009 1:14:28 PM
In article <7h9skeF2svb63U2@mid.individual.net>, Bob Eager <rde42@spamcop.net> writes:
> 
> I don't even understand the point you are trying to make.

   Why am I not surprised?

0
koehler2 (8314)
9/16/2009 1:15:14 PM
In article <00287602$0$26780$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> Bob Koehler wrote:
> 
>>    Niether iPhone not iPod are UNIX.  Naturally Apple did a better job
>>    of designing the application interfaces than expecting its users to
>>    bring up UNIX shells.
>> 
> 
> 
> iphone and ipodtouch run OS-X. OS-X is unix.

     OS-X is UNIX plus a damn good GUI.  iPhone and iPod are not UNIX.

0
koehler2 (8314)
9/16/2009 1:15:55 PM
In article <7haqjjF2ssv04U1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
> 
> You just won't accept that there are other ways tio us Unix than a shell,
> will you.  At least there has been since the TTY went away.  :-)

   I have, and I do, but the application's interface is not the OS
   interface.

0
koehler2 (8314)
9/16/2009 1:16:50 PM
In article <pdn0b5tbfum015s3pdbdpv99lb1e11aras@4ax.com>, Judge Judy <nospam@shaw.com> writes:
> 
> Most Ftp
> clients don't recognize VMS.

   Shouldn't FTP clients be expected to recognise the FTP standard
   (formerly know as the RFC)?

0
koehler2 (8314)
9/16/2009 1:18:32 PM
Bob Koehler wrote:
> In article <pdn0b5tbfum015s3pdbdpv99lb1e11aras@4ax.com>, Judge Judy <nospam@shaw.com> writes:
>> Most Ftp
>> clients don't recognize VMS.
> 
>    Shouldn't FTP clients be expected to recognise the FTP standard
>    (formerly know as the RFC)?
> 

I don't use FTP very often these days.  I don't recall that it is 
necessary to "recognize" an O/S.  If the FTP implementation conforms, it 
should work with any other conforming FTP implementation.  VMS to Unix 
and Unix to VMS using FTP have always worked for me.  Binary files are 
transferred byte for byte.  Text files are sent as written and line 
termination is handled at the receiving end by translating to whatever 
the local custom is.
0
rgilbert88 (4439)
9/16/2009 2:06:13 PM
In article <acudnUi9eNBbbS3XnZ2dnUVZ_gGdnZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>Bob Koehler wrote:
>> In article <pdn0b5tbfum015s3pdbdpv99lb1e11aras@4ax.com>, Judge Judy <nospam@shaw.com> writes:
>>> Most Ftp
>>> clients don't recognize VMS.
>> 
>>    Shouldn't FTP clients be expected to recognise the FTP standard
>>    (formerly know as the RFC)?
>> 
>
>I don't use FTP very often these days.  I don't recall that it is 
>necessary to "recognize" an O/S.  If the FTP implementation conforms, it 
>should work with any other conforming FTP implementation.  VMS to Unix 
>and Unix to VMS using FTP have always worked for me.  Binary files are 
>transferred byte for byte.  Text files are sent as written and line 
>termination is handled at the receiving end by translating to whatever 
>the local custom is.

Right Richard but many of the attempts to make FTP GUI have taken to
parsing the FTP listing format as an *ix listing formats.  Those GUI
FTPs fall to pieces when the FTP server is VMS.  HG-FTP will provide
a *ix listing format for such GUI FTP clients but this shouldn't need
to be.

FWIW, it's sftp for me these days.  I don't even have to set the file
type (ASCII/BINARY) when using sftp which has rendered many FTP down-
loads unusable for me when I forgot to first set the file type.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

  http://www.quirkfactory.com/popart/asskey/eqn2.png
  
  "Well my son, life is like a beanstalk, isn't it?"
0
VAXman
9/16/2009 2:53:51 PM
VAXman- @SendSpamHere.ORG wrote:
> In article <acudnUi9eNBbbS3XnZ2dnUVZ_gGdnZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>> Bob Koehler wrote:
>>> In article <pdn0b5tbfum015s3pdbdpv99lb1e11aras@4ax.com>, Judge Judy <nospam@shaw.com> writes:
>>>> Most Ftp
>>>> clients don't recognize VMS.
>>>    Shouldn't FTP clients be expected to recognise the FTP standard
>>>    (formerly know as the RFC)?
>>>
>> I don't use FTP very often these days.  I don't recall that it is 
>> necessary to "recognize" an O/S.  If the FTP implementation conforms, it 
>> should work with any other conforming FTP implementation.  VMS to Unix 
>> and Unix to VMS using FTP have always worked for me.  Binary files are 
>> transferred byte for byte.  Text files are sent as written and line 
>> termination is handled at the receiving end by translating to whatever 
>> the local custom is.
> 
> Right Richard but many of the attempts to make FTP GUI have taken to
> parsing the FTP listing format as an *ix listing formats.  Those GUI
> FTPs fall to pieces when the FTP server is VMS.

I have no problem att all with the WRQ Reflection FTP client GUI.
It has no problem displaying file info incl version number, size,
dates and so on. Sub-dirs are clickable in the filellist and the
"up" icon in the tooolbar takes you up in the VMS dir structure.

0
9/16/2009 3:29:38 PM
On Wed, 16 Sep 2009 08:15:14 -0500, Bob Koehler wrote:

> In article <7h9skeF2svb63U2@mid.individual.net>, Bob Eager
> <rde42@spamcop.net> writes:
>> 
>> I don't even understand the point you are trying to make.
> 
>    Why am I not surprised?

Because you are incapable of accepting any view but your own.

-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
9/16/2009 4:11:17 PM
On Wed, 16 Sep 2009 08:16:50 -0500, Bob Koehler wrote:

> In article <7haqjjF2ssv04U1@mid.individual.net>, billg999@cs.uofs.edu
> (Bill Gunshannon) writes:
>> 
>> You just won't accept that there are other ways tio us Unix than a
>> shell, will you.  At least there has been since the TTY went away.  :-)
> 
>    I have, and I do, but the application's interface is not the OS
>    interface.

Neither is the command line.



-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
9/16/2009 4:11:33 PM
In article <qDWb2Cy5XQbv@eisner.encompasserve.org>,
	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <7h9shaF2svb63U1@mid.individual.net>, Bob Eager <rde42@spamcop.net> writes:
>> On Tue, 15 Sep 2009 08:38:11 -0500, Bob Koehler wrote:
>> 
>>>    added ACLs to the protection implementation
>> 
>> So has UNIX.
>>
>    I've seen them on HP-UX, but not on all UNIX.  SO I'm under the
>    impression "UNIX" has not.

"Unix" has over a dozen possible file system options so you can pick the
one that offers the features you need.

> 
>>>    added hard links
>> 
>> UNIX had them already, and added soft links.
>> 
>>>    added mount points.
>> 
>> Which UNIX had already. Difficult to say that UNIX 'hasn't changed' in 
>> some areas when VMS is just playing catchup, though.
> 
>    That which UNIX already has doesn't sound like proof that UNIX is
>    changing.  That which VMS is adding certainly does sound like VMS
>    is changing.  Who had it first doesn't matter.

Oh, I see.  Having the technological foresight to anticipate users
needs and desires is now seen as a shortcoming.  I understand.

bill
 

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
9/16/2009 4:13:17 PM
In article <b8rVzq6IfnV1@eisner.encompasserve.org>,
	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <7h9skeF2svb63U2@mid.individual.net>, Bob Eager <rde42@spamcop.net> writes:
>> 
>> I don't even understand the point you are trying to make.
> 
>    Why am I not surprised?
 
Sorry Bob, neither did I.  Did anybody?

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
9/16/2009 4:14:21 PM
In article <V49+bpWWDtyc@eisner.encompasserve.org>,
	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <7haqjjF2ssv04U1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>> 
>> You just won't accept that there are other ways tio us Unix than a shell,
>> will you.  At least there has been since the TTY went away.  :-)
> 
>    I have, and I do, but the application's interface is not the OS
>    interface.
 
So, now we are back to arguing what is OS and what is an application
on top of the OS.  Is BASH part of the OS?  Is DCL?  I really don't
think any "OS" has a "user" inteface.  They all have an API for which
various user interfaces get written.  Under Unix, a "shell" is just a
user level program.  One is not even necessary in order for the OS to
be functional for regular users.  Kind of like menu driven captive
accounts on VMS that offer no access to DCL for the user.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
9/16/2009 4:22:46 PM
In article <5Z0rcS2tvt1K@eisner.encompasserve.org>,
	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <00287602$0$26780$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>> Bob Koehler wrote:
>> 
>>>    Niether iPhone not iPod are UNIX.  Naturally Apple did a better job
>>>    of designing the application interfaces than expecting its users to
>>>    bring up UNIX shells.
>>> 
>> 
>> 
>> iphone and ipodtouch run OS-X. OS-X is unix.
> 
>      OS-X is UNIX plus a damn good GUI.  iPhone and iPod are not UNIX.
 
GUI is just a user application on top of the OS.  the OS is OS-X and it is
(has been certified) Unix.  Oh, and apparently the GUI on the iPhone is
Darwin, the same one that is on other systyems running OS-X.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
9/16/2009 4:24:23 PM
Bill Gunshannon wrote:
> In article <V49+bpWWDtyc@eisner.encompasserve.org>,
> 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>> In article <7haqjjF2ssv04U1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>>> You just won't accept that there are other ways tio us Unix than a shell,
>>> will you.  At least there has been since the TTY went away.  :-)
>>    I have, and I do, but the application's interface is not the OS
>>    interface.
>  
> So, now we are back to arguing what is OS and what is an application
> on top of the OS.  Is BASH part of the OS?  Is DCL?  I really don't
> think any "OS" has a "user" inteface.  They all have an API for which
> various user interfaces get written.  Under Unix, a "shell" is just a
> user level program.  One is not even necessary in order for the OS to
> be functional for regular users.  Kind of like menu driven captive
> accounts on VMS that offer no access to DCL for the user.
> 
> bill
> 

I think you could make a very reasonable case that DCL is part of the O/S.

1. DCL is part of system startup.
2. DCL is part of system shutdown.
3. DCL ships with the VMS binaries.

If you wanted to work at it, you could probably create a substitute or 
modify something to substitute.  Since DEC never documented the entry to 
supervisor mode or provided one (there is no CMSUPER()) you are pretty 
much on your own.

I think that TGV and a few others have managed to reverse engineer it 
but I don't think they have ever published the details of the interface.
0
rgilbert88 (4439)
9/16/2009 4:44:56 PM
Richard B. Gilbert vaguely mentioned on 16-9-2009 18:44:

[snip]
> 
> I think you could make a very reasonable case that DCL is part of the O/S.
> 
> 1. DCL is part of system startup.
> 2. DCL is part of system shutdown.
> 3. DCL ships with the VMS binaries.
> 
> If you wanted to work at it, you could probably create a substitute or 
> modify something to substitute.  Since DEC never documented the entry to 
> supervisor mode or provided one (there is no CMSUPER()) you are pretty 
> much on your own.
> 
> I think that TGV and a few others have managed to reverse engineer it 
> but I don't think they have ever published the details of the interface.

DCL is the ultimate VMS exit handler. It prevents process deletion after 
image rundown. In my book, that makes it an integral part of the OS.

/Wilm
0
w6.boerhout (112)
9/16/2009 6:00:35 PM
In article <7hchmmF2r574qU3@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>  
> So, now we are back to arguing what is OS and what is an application
> on top of the OS.  Is BASH part of the OS?  Is DCL?

   DCL is certainly part of VMS.  It is not a user mode program, it
   comes with the OS, and by default the OS is set up to grant it
   the environment it needs to run in supervisor mode.

0
koehler2 (8314)
9/16/2009 6:19:26 PM
In article <7hchpnF2r574qU4@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>  
> GUI is just a user application on top of the OS.  the OS is OS-X and it is
> (has been certified) Unix.  Oh, and apparently the GUI on the iPhone is
> Darwin, the same one that is on other systyems running OS-X.

   Which further supports my point, so thanks.

0
koehler2 (8314)
9/16/2009 6:20:14 PM
In article <qDWb2Cy5XQbv@eisner.encompasserve.org>,
koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <7h9shaF2svb63U1@mid.individual.net>, Bob Eager <rde42@spamcop.net>
> writes:
> > On Tue, 15 Sep 2009 08:38:11 -0500, Bob Koehler wrote:
> > 
> >>    added ACLs to the protection implementation
> > 
> > So has UNIX.
> >
>    I've seen them on HP-UX, but not on all UNIX.  SO I'm under the
>    impression "UNIX" has not.
> 

Just shows how little you know about the Unix family.
AIX had ACLs about the same time, if not earlier than HP-UX
(for JFS and not just for HFS). I'm pretty sure Tru64 and modern
versions of Solaris have them too. 
Unix filesystems went from simple UFS to modern JFS/LVM,
from 2GB max file/system sizes to 64bit entities
(not to be confused with 64bit CPU address space).
Quite a bit of changes, and all of them came in due time,
unlike VMS.
0
M.Kraemer (2048)
9/16/2009 7:39:32 PM
billg999@cs.uofs.edu (Bill Gunshannon) writes:

> So, now we are back to arguing what is OS and what is an application
> on top of the OS.  Is BASH part of the OS?  Is DCL?  I really don't
> think any "OS" has a "user" inteface.  They all have an API for which
> various user interfaces get written.

In the modern era, that's probably true, but it is not required that an OS
provide a separate shell/command processor.  The command processor in Tops-10
is an integral part of the monitor, running round-robin among the logged-in
jobs.

(No, Tops-10 does not have a fork/process model of computation.)

-- 
Rich Alderson                  "You get what anybody gets. You get a lifetime."
news@alderson.users.panix.com                           --Death, of the Endless
0
news83 (377)
9/16/2009 11:38:35 PM
In article <HcednTKQvIhBiCzXnZ2dnUVZ_rWdnZ2d@giganews.com>,
	"Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> Bill Gunshannon wrote:
>> In article <V49+bpWWDtyc@eisner.encompasserve.org>,
>> 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>>> In article <7haqjjF2ssv04U1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>>>> You just won't accept that there are other ways tio us Unix than a shell,
>>>> will you.  At least there has been since the TTY went away.  :-)
>>>    I have, and I do, but the application's interface is not the OS
>>>    interface.
>>  
>> So, now we are back to arguing what is OS and what is an application
>> on top of the OS.  Is BASH part of the OS?  Is DCL?  I really don't
>> think any "OS" has a "user" inteface.  They all have an API for which
>> various user interfaces get written.  Under Unix, a "shell" is just a
>> user level program.  One is not even necessary in order for the OS to
>> be functional for regular users.  Kind of like menu driven captive
>> accounts on VMS that offer no access to DCL for the user.
>> 
> 
> I think you could make a very reasonable case that DCL is part of the O/S.
> 
> 1. DCL is part of system startup.

So is the UNix Shell.

> 2. DCL is part of system shutdown.

So is the UNix Shell.

> 3. DCL ships with the VMS binaries.

So is the UNix Shell.


And yet, not part of the OS.  Simple question.  Forget about the
inability to configure anything, would the VMS kernel run if DCL.EXE
were not present on the system?  If the answer is yes, you make the
call.

Aren't there "embedded" VMS boxes?  Honest question, because I really
thought there were.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
9/17/2009 12:32:26 AM
In article <32gk6SH+kao5@eisner.encompasserve.org>,
	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <7hchmmF2r574qU3@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>>  
>> So, now we are back to arguing what is OS and what is an application
>> on top of the OS.  Is BASH part of the OS?  Is DCL?
> 
>    DCL is certainly part of VMS.  It is not a user mode program, it
>    comes with the OS, and by default the OS is set up to grant it
>    the environment it needs to run in supervisor mode.

You mean like the Unix Shell that does all the startup scripts and yet
isn't part  of the OS????
 
bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
9/17/2009 12:39:43 AM
In article <RVqsznRfWyau@eisner.encompasserve.org>,
	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <7hchpnF2r574qU4@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>>  
>> GUI is just a user application on top of the OS.  the OS is OS-X and it is
>> (has been certified) Unix.  Oh, and apparently the GUI on the iPhone is
>> Darwin, the same one that is on other systyems running OS-X.
> 
>    Which further supports my point, so thanks.

Bob you get more confusing every post.  What point?  I thought your point 
was that iPhones didn't run Unix and I just showed you that they do.

bill
 

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
9/17/2009 12:42:19 AM
Bill Gunshannon wrote:
> In article <HcednTKQvIhBiCzXnZ2dnUVZ_rWdnZ2d@giganews.com>,
> 	"Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>> Bill Gunshannon wrote:
>>> In article <V49+bpWWDtyc@eisner.encompasserve.org>,
>>> 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>>>> In article <7haqjjF2ssv04U1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>>>>> You just won't accept that there are other ways tio us Unix than a shell,
>>>>> will you.  At least there has been since the TTY went away.  :-)
>>>>    I have, and I do, but the application's interface is not the OS
>>>>    interface.
>>>  
>>> So, now we are back to arguing what is OS and what is an application
>>> on top of the OS.  Is BASH part of the OS?  Is DCL?  I really don't
>>> think any "OS" has a "user" inteface.  They all have an API for which
>>> various user interfaces get written.  Under Unix, a "shell" is just a
>>> user level program.  One is not even necessary in order for the OS to
>>> be functional for regular users.  Kind of like menu driven captive
>>> accounts on VMS that offer no access to DCL for the user.
>>>
>> I think you could make a very reasonable case that DCL is part of the O/S.
>>
>> 1. DCL is part of system startup.
> 
> So is the UNix Shell.

I know that there is some sort of a Unix-like shell on some recent 
releases but I think it was only in recent releases.  V3.7-V5.5-2 didn't 
have a Unix like shell.  I don't recall one in V6.x.  I'm not sure just 
when Posix came along.  I do know that the POSIX shell is a piss poor 
substitute for a genuine Unix shell.  The last time I tried (it was 
maybe four years ago) the VMS POSIX shell was not capable of running the
"configure" script for NTP.

> 
>> 2. DCL is part of system shutdown.
> 
> So is the UNix Shell.
> 
>> 3. DCL ships with the VMS binaries.
> 
> So is the UNix Shell.
> 
> 
> And yet, not part of the OS.  Simple question.  Forget about the
> inability to configure anything, would the VMS kernel run if DCL.EXE
> were not present on the system?  If the answer is yes, you make the
> call.

Probably, but THEN what would you do?  There is a hell of a lot more to 
VMS than "running the kernel".  There has to be SOME interface that lets 
you do some useful work with the system.  Without such, a computer is 
nothing more than a very expensive electric heater!
0
rgilbert88 (4439)
9/17/2009 2:25:01 AM
Richard B. Gilbert wrote:

> I know that there is some sort of a Unix-like shell on some recent
> releases but I think it was only in recent releases.  V3.7-V5.5-2 didn't
> have a Unix like shell.  I don't recall one in V6.x.  I'm not sure just
> when Posix came along.

   Apparently.

GIMP $ write sys$output f$getsyi( "version")
V5.5-2

GIMP $ posix
psx> uname -a
POSIX_for_OpenVMS_VAX GIMP V2.0(V2.0) V5.5-2 VAX_4000-200 VAX

What else don't you know?

>   I do know that the POSIX shell is a piss poor
> substitute for a genuine Unix shell.  The last time I tried (it was
> maybe four years ago) the VMS POSIX shell was not capable of running the
> "configure" script for NTP.

   Well, duh.  It takes more than a working shell to do any
useful work, and a typical "configure" script expects to use a
UNIX-like compiler.
0
sms.antinode (948)
9/17/2009 2:51:07 AM
On 2009-09-16, Bill Gunshannon <billg999@cs.uofs.edu> wrote:
> Oh, and apparently the GUI on the iPhone is
> Darwin, the same one that is on other systyems running OS-X.

Darwin is actually the *non-GUI* part of the OS. I forget what the GUI
part is called; Quartz or somesuch. Darwin is open-source, Quartz is
not.
-- 
roger ivie
rivie@ridgenet.net
0
rivie (670)
9/17/2009 2:51:41 AM
Steven Schweda wrote:
> Richard B. Gilbert wrote:
> 
>> I know that there is some sort of a Unix-like shell on some recent
>> releases but I think it was only in recent releases.  V3.7-V5.5-2 didn't
>> have a Unix like shell.  I don't recall one in V6.x.  I'm not sure just
>> when Posix came along.
> 
>    Apparently.
> 
> GIMP $ write sys$output f$getsyi( "version")
> V5.5-2
> 
> GIMP $ posix
> psx> uname -a
> POSIX_for_OpenVMS_VAX GIMP V2.0(V2.0) V5.5-2 VAX_4000-200 VAX
> 
> What else don't you know?
> 
>>   I do know that the POSIX shell is a piss poor
>> substitute for a genuine Unix shell.  The last time I tried (it was
>> maybe four years ago) the VMS POSIX shell was not capable of running the
>> "configure" script for NTP.

The POSIX subsystem would not run on recent VMS releases, I forget which 
one it stopped working on.

For at least the last 3 years, GNV has the capability of running many 
UNIX configure scripts.  The ftp://encompasserve.org/gnv directory is 
full of packages that most were built using GNV.

EAGLE> type gnv_ncurses_configure.sh
# DCL Fallback does not work so disable
export GNV_DISABLE_DCL_FALLBACK=1
#
# POSIX exit mode is needed for UNIX shells.
export GNV_CC_MAIN_POSIX_EXIT=1
#
# Where to look for the helper files.
export GNV_OPT_DIR=.
#
# Configure gets this run.
export cf_cv_xopen_source=no
#
# Set the directory to where the Configure script actually is.
cd ../..
../configure  --prefix=/usr --exec-prefix=/usr \
  --disable-dependency-tracking \
  --disable-libtool-lock --enable-reentrant \
  --with-pthread   --enable-widec \
  --enable-ext-colors
#

EAGLE> bash gnv_ncurses_configure.sh
checking for egrep... grep -E
Configuring NCURSES 5.7 ABI 5 (Wed Sep 16 23:40:14 CDT 2009)
checking build system type... alpha-dec-vms
checking host system type... alpha-dec-vms
checking target system type... alpha-dec-vms
Configuring for vms
checking for prefix... /usr
<skip output>
** Configuration summary for NCURSES 5.7 20081102:

      extended funcs: yes
      xterm terminfo: xterm-new

       bin directory: /usr/bin
       lib directory: /usr/lib
   include directory: /usr/include
       man directory: /usr/man
  terminfo directory: /usr/share/terminfo

EAGLE> show sys/noproc
OpenVMS V8.3  on node EAGLE  16-SEP-2009 23:49:28.88  Uptime  474 01:28:43

Regards,
-John
wb8tyw@qsl.network
Personal Opinion Only
0
wb8tyw (629)
9/17/2009 5:12:59 AM
In article <Td2dnSX7ar73ACzXnZ2dnUVZ_jydnZ2d@giganews.com>, "Richard B. Gilbert"
<rgilbert88@comcast.net> writes:
:

> 
> I do know that the POSIX shell is a piss poor 
> substitute for a genuine Unix shell.  The last time I tried (it was 
> maybe four years ago) the VMS POSIX shell was not capable of running the
> "configure" script for NTP.
> 

not necessarily VMS' fault. configure scripts tend to run on
Gnu/Linux only. An HP-UX system for example might have difficulties as well.


0
M.Kraemer (2048)
9/17/2009 5:16:48 AM
R.A.Omond wrote:

> I expect it was Colin's stuff that you saw.
> 
> However, just a little comment:  there is still a lot of VMS
> prevalent within the NHS (I deal with many such sites). Many
> of them are quite elegantly setup e.g. in 3-site split clusters.
> Even though I've heard the old, old story that they will be
> replaced within the next 6 months, I've heard the exact same
> story for the last 10 years ...

I wonder how much pdp activity there is now. I spent several years in 
the mid to late 80's/early 90's programming pdp. Embedded rt11 mainly, 
but some rsx as well. I suppose it's all dead now, but was a lot of fun 
at the time.

Are they still using dsm ?. No experience of it here, but understand 
that was quite common in the nhs and in other countrie's medical sector...

Regards,

Chris
0
blackhole5 (113)
9/17/2009 4:50:59 PM
Bob Eager wrote:

>> Oh, you mean *pdp-11*.  There are, after all, 3.5 other architectures
>> from DEC with "PDP" in their names: 12 bit (PDP-5/8), 18 bit (PDP-1,
>> PDP-4/7/9/15), and 36 bit (PDP-6/10).
> 
> What about the PDP-2? :-)
> 

The rt11 should have given it away :-). i still get nostalgic about 
those days, sign of advancing years perhaps. One comp[any that I worked 
for for over two years resulted in over 300 source library modules, all 
in macro 11. Menu systems, drivers for non standard hardware and loads 
of other stuff. Recovered some of it recently from an old vms system 
drive, but still have loads more on Rx02 floppies and rl02 packs. Have 
an rlv12 controller and a drive, but it hasn't run for years and would 
need carefull inspection before daring to put a pack in. Stuff to do on 
winters evenings perhaps...

Regards,

Chris
0
blackhole5 (113)
9/17/2009 6:33:32 PM
ChrisQ <blackhole@devnull.com> writes:

> I wonder how much pdp activity there is now. I spent several years in 
> the mid to late 80's/early 90's programming pdp. Embedded rt11 mainly, 
> but some rsx as well. I suppose it's all dead now, but was a lot of fun 
> at the time.

Oh, you mean *pdp-11*.  There are, after all, 3.5 other architectures from DEC
with "PDP" in their names: 12 bit (PDP-5/8), 18 bit (PDP-1, PDP-4/7/9/15), and
36 bit (PDP-6/10).

-- 
Rich Alderson                  "You get what anybody gets. You get a lifetime."
news@alderson.users.panix.com                           --Death, of the Endless
0
news83 (377)
9/17/2009 6:43:45 PM
On Thu, 17 Sep 2009 14:43:45 -0400, Rich Alderson wrote:

> ChrisQ <blackhole@devnull.com> writes:
> 
>> I wonder how much pdp activity there is now. I spent several years in
>> the mid to late 80's/early 90's programming pdp. Embedded rt11 mainly,
>> but some rsx as well. I suppose it's all dead now, but was a lot of fun
>> at the time.
> 
> Oh, you mean *pdp-11*.  There are, after all, 3.5 other architectures
> from DEC with "PDP" in their names: 12 bit (PDP-5/8), 18 bit (PDP-1,
> PDP-4/7/9/15), and 36 bit (PDP-6/10).

What about the PDP-2? :-)



-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
9/17/2009 7:08:10 PM
ChrisQ wrote:
> R.A.Omond wrote:
> 
>> I expect it was Colin's stuff that you saw.
>>
>> However, just a little comment:  there is still a lot of VMS
>> prevalent within the NHS (I deal with many such sites). Many
>> of them are quite elegantly setup e.g. in 3-site split clusters.
>> Even though I've heard the old, old story that they will be
>> replaced within the next 6 months, I've heard the exact same
>> story for the last 10 years ...
> 
> I wonder how much pdp activity there is now. I spent several years in 
> the mid to late 80's/early 90's programming pdp. Embedded rt11 mainly, 
> but some rsx as well. I suppose it's all dead now, but was a lot of fun 
> at the time.
> 
> Are they still using dsm ?. No experience of it here, but understand 
> that was quite common in the nhs and in other countrie's medical sector...
> 
> Regards,
> 
> Chris

If, by "dsm", you mean MUMPS, it's very much alive in the U.S. health 
care industry.  I'd say that at least 90% of the job postings for VMS 
System Administrators require MUMPS and CACHE experience.
0
rgilbert88 (4439)
9/17/2009 8:36:15 PM
On Thu, 17 Sep 2009 19:33:32 +0100, ChrisQ wrote:

> Bob Eager wrote:
> 
>>> Oh, you mean *pdp-11*.  There are, after all, 3.5 other architectures
>>> from DEC with "PDP" in their names: 12 bit (PDP-5/8), 18 bit (PDP-1,
>>> PDP-4/7/9/15), and 36 bit (PDP-6/10).
>> 
>> What about the PDP-2? :-)
>> 
>> 
> The rt11 should have given it away :-). i still get nostalgic about
> those days, sign of advancing years perhaps.

RT-11 was the *second* PDP-11 system I used. Much faster than DOS/BATCH, 
which was the first (but absolutely tiny, with over a hundred overlays).

-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
9/17/2009 8:52:55 PM
In article <Td2dnSX7ar73ACzXnZ2dnUVZ_jydnZ2d@giganews.com>,
	"Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> Bill Gunshannon wrote:
>> In article <HcednTKQvIhBiCzXnZ2dnUVZ_rWdnZ2d@giganews.com>,
>> 	"Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>>> Bill Gunshannon wrote:
>>>> In article <V49+bpWWDtyc@eisner.encompasserve.org>,
>>>> 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>>>>> In article <7haqjjF2ssv04U1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>>>>>> You just won't accept that there are other ways tio us Unix than a shell,
>>>>>> will you.  At least there has been since the TTY went away.  :-)
>>>>>    I have, and I do, but the application's interface is not the OS
>>>>>    interface.
>>>>  
>>>> So, now we are back to arguing what is OS and what is an application
>>>> on top of the OS.  Is BASH part of the OS?  Is DCL?  I really don't
>>>> think any "OS" has a "user" inteface.  They all have an API for which
>>>> various user interfaces get written.  Under Unix, a "shell" is just a
>>>> user level program.  One is not even necessary in order for the OS to
>>>> be functional for regular users.  Kind of like menu driven captive
>>>> accounts on VMS that offer no access to DCL for the user.
>>>>
>>> I think you could make a very reasonable case that DCL is part of the O/S.
>>>
>>> 1. DCL is part of system startup.
>> 
>> So is the UNix Shell.
> 
> I know that there is some sort of a Unix-like shell on some recent 
> releases but I think it was only in recent releases.  V3.7-V5.5-2 didn't 
> have a Unix like shell.  I don't recall one in V6.x.  I'm not sure just 
> when Posix came along.  I do know that the POSIX shell is a piss poor 
> substitute for a genuine Unix shell.  The last time I tried (it was 
> maybe four years ago) the VMS POSIX shell was not capable of running the
> "configure" script for NTP.

I am not talking about a "shell" on VMS.  We are talking about wether
or not DCL is a part of the OS as it has already been stated that
the Unix shell is not.  I was pointing out that the Unix shell has
the same functions that were listed as making DCL a part of the OS.
I claim it does not and that DCL is just an application that runs on
top of the VMS Kernel.

> 
>> 
>>> 2. DCL is part of system shutdown.
>> 
>> So is the UNix Shell.
>> 
>>> 3. DCL ships with the VMS binaries.
>> 
>> So is the UNix Shell.
>> 
>> 
>> And yet, not part of the OS.  Simple question.  Forget about the
>> inability to configure anything, would the VMS kernel run if DCL.EXE
>> were not present on the system?  If the answer is yes, you make the
>> call.
> 
> Probably, but THEN what would you do?  There is a hell of a lot more to 
> VMS than "running the kernel".  

Of course there is.  and the same is true of Unix.  But that doesn't
make DCL or the Unix shell a part of the OS.  It is still just an
application that runs on top of the OS.

>                                 There has to be SOME interface that lets 
> you do some useful work with the system.  Without such, a computer is 
> nothing more than a very expensive electric heater!

And that wasn't the question at hand.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
9/17/2009 9:55:41 PM
Bill Gunshannon wrote:
> In article <Td2dnSX7ar73ACzXnZ2dnUVZ_jydnZ2d@giganews.com>,
> 	"Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>> Bill Gunshannon wrote:
>>> In article <HcednTKQvIhBiCzXnZ2dnUVZ_rWdnZ2d@giganews.com>,
>>> 	"Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>>>> Bill Gunshannon wrote:
>>>>> In article <V49+bpWWDtyc@eisner.encompasserve.org>,
>>>>> 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>>>>>> In article <7haqjjF2ssv04U1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>>>>>>> You just won't accept that there are other ways tio us Unix than a shell,
>>>>>>> will you.  At least there has been since the TTY went away.  :-)
>>>>>>    I have, and I do, but the application's interface is not the OS
>>>>>>    interface.
>>>>>  
>>>>> So, now we are back to arguing what is OS and what is an application
>>>>> on top of the OS.  Is BASH part of the OS?  Is DCL?  I really don't
>>>>> think any "OS" has a "user" inteface.  They all have an API for which
>>>>> various user interfaces get written.  Under Unix, a "shell" is just a
>>>>> user level program.  One is not even necessary in order for the OS to
>>>>> be functional for regular users.  Kind of like menu driven captive
>>>>> accounts on VMS that offer no access to DCL for the user.
>>>>>
>>>> I think you could make a very reasonable case that DCL is part of the O/S.
>>>>
>>>> 1. DCL is part of system startup.
>>> So is the UNix Shell.
>> I know that there is some sort of a Unix-like shell on some recent 
>> releases but I think it was only in recent releases.  V3.7-V5.5-2 didn't 
>> have a Unix like shell.  I don't recall one in V6.x.  I'm not sure just 
>> when Posix came along.  I do know that the POSIX shell is a piss poor 
>> substitute for a genuine Unix shell.  The last time I tried (it was 
>> maybe four years ago) the VMS POSIX shell was not capable of running the
>> "configure" script for NTP.
> 
> I am not talking about a "shell" on VMS.  We are talking about wether
> or not DCL is a part of the OS as it has already been stated that
> the Unix shell is not.  I was pointing out that the Unix shell has
> the same functions that were listed as making DCL a part of the OS.
> I claim it does not and that DCL is just an application that runs on
> top of the VMS Kernel.
> 
>>>> 2. DCL is part of system shutdown.
>>> So is the UNix Shell.
>>>
>>>> 3. DCL ships with the VMS binaries.
>>> So is the UNix Shell.
>>>
>>>
>>> And yet, not part of the OS.  Simple question.  Forget about the
>>> inability to configure anything, would the VMS kernel run if DCL.EXE
>>> were not present on the system?  If the answer is yes, you make the
>>> call.
>> Probably, but THEN what would you do?  There is a hell of a lot more to 
>> VMS than "running the kernel".  
> 
> Of course there is.  and the same is true of Unix.  But that doesn't
> make DCL or the Unix shell a part of the OS.  It is still just an
> application that runs on top of the OS.
> 
>>                                 There has to be SOME interface that lets 
>> you do some useful work with the system.  Without such, a computer is 
>> nothing more than a very expensive electric heater!
> 
> And that wasn't the question at hand.
> 

If it ships with the O/S, is installed with the O/S, and is used during 
the installation, I think it might just be "part of the O/S"!

sh is part of Unix in the same sense that DCL is part of VMS.

Of course, if you define the O/S as the kernel you are right but I don't 
accept that definition so you are wrong!
;-)

Want to try an experiment?  Delete DCL.EXE and reboot.  Oh, and I'd 
recommend an image backup of your system disk first!  And have a copy of 
standalone backup that you can boot from.
0
rgilbert88 (4439)
9/17/2009 10:20:42 PM
ChrisQ wrote:
> R.A.Omond wrote:
> 
>> I expect it was Colin's stuff that you saw.
>>
>> However, just a little comment:  there is still a lot of VMS
>> prevalent within the NHS (I deal with many such sites). Many
>> of them are quite elegantly setup e.g. in 3-site split clusters.
>> Even though I've heard the old, old story that they will be
>> replaced within the next 6 months, I've heard the exact same
>> story for the last 10 years ...
> 
> Are they still using dsm ?. No experience of it here, but understand 
> that was quite common in the nhs and in other countries' medical sector...

Yes, DSM (or Caché as it is now).
0
Roy.Omond (380)
9/18/2009 9:56:31 AM
In article <mdd63biv4sj.fsf@panix5.panix.com>, Rich Alderson <news@alderson.users.panix.com> writes:
> 
> (No, Tops-10 does not have a fork/process model of computation.)

   Are you sure?  TOPS-20 certainly did.  I thought the TOPS-20
   internals were based on the TOPS-10 internals.
   
0
koehler2 (8314)
9/18/2009 1:40:44 PM
In article <7hdeqeF2qoc2jU2@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
> In article <32gk6SH+kao5@eisner.encompasserve.org>,
> 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>> In article <7hchmmF2r574qU3@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>>>  
>>> So, now we are back to arguing what is OS and what is an application
>>> on top of the OS.  Is BASH part of the OS?  Is DCL?
>> 
>>    DCL is certainly part of VMS.  It is not a user mode program, it
>>    comes with the OS, and by default the OS is set up to grant it
>>    the environment it needs to run in supervisor mode.
> 
> You mean like the Unix Shell that does all the startup scripts and yet
> isn't part  of the OS????

   I wouldn't want to, but I think I could write those steps in C
   programs instead of shell scripts.  Or I could change the boot
   processing to use to a different shell.

   But a UNIX shell is a user mode program that does not need a special
   environment.  Most UNIX today will prevent the unprivileged user from
   chsh to just any random program, but they can invoke there own
   program as a shell after they log in without losing any other
   feature.

   Try that on VMS and you'll find somethings that a CLI can do that
   your program can't.

0
koehler2 (8314)
9/18/2009 1:45:22 PM
In article <7hdecqF2qoc2jU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
> 
> Aren't there "embedded" VMS boxes?  Honest question, because I really
> thought there were.

   We've used VMS boxes in the same manner as embedded systems, but an
   embedded system doesn't even think it has an OPA0.

0
koehler2 (8314)
9/18/2009 1:46:36 PM
In article <7hdevbF2qoc2jU3@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
> 
> Bob you get more confusing every post.  What point?  I thought your point 
> was that iPhones didn't run Unix and I just showed you that they do.

   No, my point was that the applications on the iPhone are
   applications, not an OS.  Of course the iPhone has an OS, and I'm
   not the least bit surprised if its Darwin based.

0
koehler2 (8314)
9/18/2009 1:48:34 PM
In article <Td2dnSX7ar73ACzXnZ2dnUVZ_jydnZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> 
> I know that there is some sort of a Unix-like shell on some recent 
> releases but I think it was only in recent releases.

   I think you got the OP's reference to UNIX mixed up with VMS.

   However, back in the VMS 2 and 3 days Wollonging shipped Unice, a
   UNIX environment for VMS which included a csh.

   Later DEC shipped DECShell, an implementation of the Bourne shell.

   After that DEC shipped the POSIX kit, with the POSIX shell (a subset
   of ksh).

   And now you can get GNV, which includes a bash.

   So UNIX shells on VMS have a long history, with gaps.

0
koehler2 (8314)
9/18/2009 1:51:38 PM
In article <93bd7d6d-adb0-451d-b08d-f056bc0ca10d@33g2000vbe.googlegroups.com>, Steven Schweda <sms.antinode@gmail.com> writes:
> Richard B. Gilbert wrote:
> 
>> I know that there is some sort of a Unix-like shell on some recent
>> releases but I think it was only in recent releases.  V3.7-V5.5-2 didn't
>> have a Unix like shell.  I don't recall one in V6.x.  I'm not sure just
>> when Posix came along.
> 
>    Apparently.
> 
> GIMP $ write sys$output f$getsyi( "version")
> V5.5-2
> 
> GIMP $ posix
> psx> uname -a
> POSIX_for_OpenVMS_VAX GIMP V2.0(V2.0) V5.5-2 VAX_4000-200 VAX

   The POSIX kit (which first shipped about the time of VMS 6.0 for VAX) 
   supported VMS versions back to 5.5, and which were retroactively renamed 
   OpenVMS by DEC.

0
koehler2 (8314)
9/18/2009 1:56:52 PM
In article <Pj7h$NS4aLvz@eisner.encompasserve.org>,
	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <Td2dnSX7ar73ACzXnZ2dnUVZ_jydnZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>> 
>> I know that there is some sort of a Unix-like shell on some recent 
>> releases but I think it was only in recent releases.
> 
>    I think you got the OP's reference to UNIX mixed up with VMS.
> 
>    However, back in the VMS 2 and 3 days Wollonging shipped Unice, a
>    UNIX environment for VMS which included a csh.

Actually, it was Eunice.  I still have a ditro tape.  I just wish there
was some way to get a license to run it.

> 
>    Later DEC shipped DECShell, an implementation of the Bourne shell.
> 
>    After that DEC shipped the POSIX kit, with the POSIX shell (a subset
>    of ksh).
> 
>    And now you can get GNV, which includes a bash.
> 
>    So UNIX shells on VMS have a long history, with gaps.

Software Tools Virtual Operating System back in 1980.  It also had
a shell and ran quite well on VMS as well as dozens of other OSes.

bill
 

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
9/18/2009 4:23:40 PM
In article <jpDV126eGoXi@eisner.encompasserve.org>,
	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <7hdecqF2qoc2jU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>> 
>> Aren't there "embedded" VMS boxes?  Honest question, because I really
>> thought there were.
> 
>    We've used VMS boxes in the same manner as embedded systems, but an
>    embedded system doesn't even think it has an OPA0.

So then, you agree with me that DCL, per se, is not really a part of the
OS as it functions just fine without it.

Which brings us right back to the original topic.  The shell is not "the
standard Unix user interface" it is merely an application that runs on
top of the OS and offers features that some users find useful.

bill
 

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
9/18/2009 4:26:22 PM
On Fri, 18 Sep 2009, Bill Gunshannon wrote:

> Actually, it was Eunice.  I still have a ditro tape.  I just wish there
> was some way to get a license to run it.

I ran Eunice for some time. Believe me, if you can't get a license to run 
it, count yourself lucky.

Steve
0
smt (67)
9/18/2009 5:10:17 PM
In article <7hfpitF2qf9thU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
> 
> I am not talking about a "shell" on VMS.  We are talking about wether
> or not DCL is a part of the OS as it has already been stated that
> the Unix shell is not.  I was pointing out that the Unix shell has
> the same functions that were listed as making DCL a part of the OS.
> I claim it does not and that DCL is just an application that runs on
> top of the VMS Kernel.

   Not all the functions are the same.  And we've pointed out other
   considerations that make DCL more a part of VMS that a shell is
   of UNIX.

0
koehler2 (8314)
9/18/2009 5:40:27 PM
In article <7hhqleF2u15qvU2@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
> 
> So then, you agree with me that DCL, per se, is not really a part of the
> OS as it functions just fine without it.

   Nope.  I've never seen a VMS system running without DCL.  Even when
   we used VMS in a manner similar to an embedded system it did have
   an OPA0, and we used DCL heavily.

   "similar to" is not the same as "is".

0
koehler2 (8314)
9/18/2009 5:54:14 PM
On Sep 17, 4:55 pm, billg...@cs.uofs.edu (Bill Gunshannon) wrote:
> In article <Td2dnSX7ar73ACzXnZ2dnUVZ_jydn...@giganews.com>,
>         "Richard B. Gilbert" <rgilber...@comcast.net> writes:
>
>
>
> > Bill Gunshannon wrote:
> >> In article <HcednTKQvIhBiCzXnZ2dnUVZ_rWdn...@giganews.com>,
> >>        "Richard B. Gilbert" <rgilber...@comcast.net> writes:
> >>> Bill Gunshannon wrote:
> >>>> In article <V49+bpWWD...@eisner.encompasserve.org>,
> >>>>        koeh...@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> >>>>> In article <7haqjjF2ssv0...@mid.individual.net>, billg...@cs.uofs.edu (Bill Gunshannon) writes:
> >>>>>> You just won't accept that there are other ways tio us Unix than a shell,
> >>>>>> will you.  At least there has been since the TTY went away.  :-)
> >>>>>    I have, and I do, but the application's interface is not the OS
> >>>>>    interface.
>
> >>>> So, now we are back to arguing what is OS and what is an application
> >>>> on top of the OS.  Is BASH part of the OS?  Is DCL?  I really don't
> >>>> think any "OS" has a "user" inteface.  They all have an API for which
> >>>> various user interfaces get written.  Under Unix, a "shell" is just a
> >>>> user level program.  One is not even necessary in order for the OS to
> >>>> be functional for regular users.  Kind of like menu driven captive
> >>>> accounts on VMS that offer no access to DCL for the user.
>
> >>> I think you could make a very reasonable case that DCL is part of the O/S.
>
> >>> 1. DCL is part of system startup.
>
> >> So is the UNix Shell.
>
> > I know that there is some sort of a Unix-like shell on some recent
> > releases but I think it was only in recent releases.  V3.7-V5.5-2 didn't
> > have a Unix like shell.  I don't recall one in V6.x.  I'm not sure just
> > when Posix came along.  I do know that the POSIX shell is a piss poor
> > substitute for a genuine Unix shell.  The last time I tried (it was
> > maybe four years ago) the VMS POSIX shell was not capable of running the
> > "configure" script for NTP.
>
> I am not talking about a "shell" on VMS.  We are talking about wether
> or not DCL is a part of the OS as it has already been stated that
> the Unix shell is not.  I was pointing out that the Unix shell has
> the same functions that were listed as making DCL a part of the OS.
> I claim it does not and that DCL is just an application that runs on
> top of the VMS Kernel.
>
>
>
>
>
> >>> 2. DCL is part of system shutdown.
>
> >> So is the UNix Shell.
>
> >>> 3. DCL ships with the VMS binaries.
>
> >> So is the UNix Shell.
>
> >> And yet, not part of the OS.  Simple question.  Forget about the
> >> inability to configure anything, would the VMS kernel run if DCL.EXE
> >> were not present on the system?  If the answer is yes, you make the
> >> call.
>
> > Probably, but THEN what would you do?  There is a hell of a lot more to
> > VMS than "running the kernel".
>
> Of course there is.  and the same is true of Unix.  But that doesn't
> make DCL or the Unix shell a part of the OS.  It is still just an
> application that runs on top of the OS.
>
> >                                 There has to be SOME interface that lets
> > you do some useful work with the system.  Without such, a computer is
> > nothing more than a very expensive electric heater!
>
> And that wasn't the question at hand.
>


So, you missed or have forgotten the definition of operating system? I
believe you have a computer sciences department close by that could
help you with that.

How one specific operating system works and whatever various services
it does or doesn't include has absolutely no relevance to any other
operating system, anymore than one CPU's architecture has any
relevance to any other CPU.

DCL is part of OpenVMS. Read the SPD to see what other services and
utilities are considered part of the OpenVMS operating system.

-------------------
0
dphill46 (619)
9/18/2009 6:25:27 PM
On Fri, 18 Sep 2009 12:54:14 -0500, Bob Koehler wrote:

> In article <7hhqleF2u15qvU2@mid.individual.net>, billg999@cs.uofs.edu
> (Bill Gunshannon) writes:
>> 
>> So then, you agree with me that DCL, per se, is not really a part of
>> the OS as it functions just fine without it.
> 
>    Nope.  I've never seen a VMS system running without DCL.  Even when
>    we used VMS in a manner similar to an embedded system it did have an
>    OPA0, and we used DCL heavily.

I've seen a VMS system that didn't even have a console.

It was called an LPS-40.




-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
9/18/2009 6:56:06 PM
Bill Gunshannon wrote:

> Which brings us right back to the original topic.  The shell is not "the
> standard Unix user interface" it is merely an application that runs on
> top of the OS and offers features that some users find useful.


OS encompasses the kernel as well as the environment that is bundled
with the OS to allow the user to interact with the OS.

I think you are confusing kernel with operating system.  EV/TPU is not
part ofthe VMS core/kernel, but it is part of the operating system.

vi is not part of the unix kernel, but it is part of the unix operating
system.
0
9/18/2009 7:10:24 PM
Bob Eager wrote:
> On Fri, 18 Sep 2009 12:54:14 -0500, Bob Koehler wrote:
> 
>> In article <7hhqleF2u15qvU2@mid.individual.net>, billg999@cs.uofs.edu
>> (Bill Gunshannon) writes:
>>> So then, you agree with me that DCL, per se, is not really a part of
>>> the OS as it functions just fine without it.
>>    Nope.  I've never seen a VMS system running without DCL.  Even when
>>    we used VMS in a manner similar to an embedded system it did have an
>>    OPA0, and we used DCL heavily.
> 
> I've seen a VMS system that didn't even have a console.
> 
> It was called an LPS-40.

DCL is the default CLI, and plays a major role in the customary behavior 
of VMS that we all know, but VMS can be run with other CLIs with 
different behaviors.

It was pointed out before that DCL runs in its own private special mode 
(Supervisor) that allows it to play its unique and special role but 
other CLIs can get the job done too.  It is not very easy to discover 
HOW to write a CLI for VMS, but as was mentioned that is another 
story...  As such DCL is "more equal" than other CLIs, but the fact is 
VMS can run under other CLIs too.

   $HELP LOGIN /CLI:

   LOGIN

     /CLI

         /CLI=command-language-interpreter

      Specifies the name of an alternate command language interpreter
      (CLI) to override the default CLI listed in the UAF. The CLI
      you specify must be located in SYS$SYSTEM and have the file type
      .EXE.

      If you do not specify a command interpreter by using the /CLI
      qualifier and you do not have a default CLI listed in the UAF,
      the system supplies the qualifier /CLI=DCL by default.

BTW besides the alternate CLIs that have been mentioned, does anyone 
recall /CLI=MCR back in the early days of VMS?  In fact if you enter MCR 
as a bare command in DCL today it still knows that it should look for 
RSX.EXE.  I think the RSX MCR alternate CLI support (and the supporting 
RSX programs it used) were built into the base VMS distribution in the 
early days and then it was pushed out to a layered product later on 
(Around the time the "/11" stopped being on the end of CPU model numbers 
when they went from hardware support to software support for the PDP-11 
mode I thin)).  I don't know if the yayered product would still work on 
the current versions of VMS.  I do know I kept it on my systems for a 
long time so I could use certain features in the supporting RSX programs 
that did not have equivalents in VMS.

Bob Hassinger
0
xxx613 (1334)
9/18/2009 7:45:43 PM
R.A.Omond wrote:

> 
> Yes, DSM (or Caché as it is now).

So, is there any rt11 / rsx programming going on now, or any other 
activity, or is pdp11 finally dead ?. There was some company that took 
bought out the rights to cpu and os's, but I think they are out of 
business now...

Regards,

Chris
0
blackhole5 (113)
9/18/2009 7:52:25 PM
In article <HrRsm.2667$Jd7.2363@nwrddc02.gnilink.net>, xxx <xxx@yyy.zzz> writes:
>Bob Eager wrote:
>> On Fri, 18 Sep 2009 12:54:14 -0500, Bob Koehler wrote:
>> 
>>> In article <7hhqleF2u15qvU2@mid.individual.net>, billg999@cs.uofs.edu
>>> (Bill Gunshannon) writes:
>>>> So then, you agree with me that DCL, per se, is not really a part of
>>>> the OS as it functions just fine without it.
>>>    Nope.  I've never seen a VMS system running without DCL.  Even when
>>>    we used VMS in a manner similar to an embedded system it did have an
>>>    OPA0, and we used DCL heavily.
>> 
>> I've seen a VMS system that didn't even have a console.
>> 
>> It was called an LPS-40.
>
>DCL is the default CLI, and plays a major role in the customary behavior 
>of VMS that we all know, but VMS can be run with other CLIs with 
>different behaviors.
>
>It was pointed out before that DCL runs in its own private special mode 
>(Supervisor) that allows it to play its unique and special role but 
>other CLIs can get the job done too.  It is not very easy to discover 
>HOW to write a CLI for VMS, but as was mentioned that is another 
>story...  As such DCL is "more equal" than other CLIs, but the fact is 
>VMS can run under other CLIs too.
>
>   $HELP LOGIN /CLI:
>
>   LOGIN
>
>     /CLI
>
>         /CLI=command-language-interpreter
>
>      Specifies the name of an alternate command language interpreter
>      (CLI) to override the default CLI listed in the UAF. The CLI
>      you specify must be located in SYS$SYSTEM and have the file type
>      .EXE.
>
>      If you do not specify a command interpreter by using the /CLI
>      qualifier and you do not have a default CLI listed in the UAF,
>      the system supplies the qualifier /CLI=DCL by default.
>
>BTW besides the alternate CLIs that have been mentioned, does anyone 
>recall /CLI=MCR back in the early days of VMS?  In fact if you enter MCR 
>as a bare command in DCL today it still knows that it should look for 
>RSX.EXE.  I think the RSX MCR alternate CLI support (and the supporting 
>RSX programs it used) were built into the base VMS distribution in the 
>early days and then it was pushed out to a layered product later on 
>(Around the time the "/11" stopped being on the end of CPU model numbers 
>when they went from hardware support to software support for the PDP-11 
>mode I thin)).  I don't know if the yayered product would still work on 
>the current versions of VMS.  I do know I kept it on my systems for a 
>long time so I could use certain features in the supporting RSX programs 
>that did not have equivalents in VMS.

Yeap and I still use MCR as a shortcut to typing $ RUN SYS$SYSTEM:some.EXE

$ MCR SYSGEN
$ MCR SYSMAN
$ MCR AUTHORIZE

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

  http://www.quirkfactory.com/popart/asskey/eqn2.png
  
  "Well my son, life is like a beanstalk, isn't it?"
0
VAXman
9/18/2009 7:52:45 PM
Bob Eager wrote:

> 
> RT-11 was the *second* PDP-11 system I used. Much faster than DOS/BATCH, 
> which was the first (but absolutely tiny, with over a hundred overlays).
> 

Overlays - aargh. They were "fun". I remember using 2 or 3 overlays for 
a proprietary network diagnostic. A 16k or so data buffer, overlaid with 
code when the buffer was not in use.

Company was Crosfield, who used embedded pdp1, rt11 and rsx extensively 
in their scanner and page make up equipment. Sadly no longer with us...

Regards,

Chris
0
blackhole5 (113)
9/18/2009 7:58:50 PM
On Fri, 18 Sep 2009 20:58:50 +0100, ChrisQ wrote:

>> RT-11 was the *second* PDP-11 system I used. Much faster than
>> DOS/BATCH, which was the first (but absolutely tiny, with over a
>> hundred overlays).
>> 
> Overlays - aargh. They were "fun". I remember using 2 or 3 overlays for
> a proprietary network diagnostic. A 16k or so data buffer, overlaid with
> code when the buffer was not in use.

DOS/BATCH used two different overlay areas, as I recall. The command 
interpreter one was 128 words, I think. The RUN command used four 
overlays.

The whole system was only 2Kwords resident, thiugh.



-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
9/18/2009 9:36:00 PM
On 2009-09-18, ChrisQ <blackhole@devnull.com> wrote:
> So, is there any rt11 / rsx programming going on now, or any other 
> activity, or is pdp11 finally dead ?.

A better place to ask would be alt.sys.pdp11.

Yes, there is some PDP-11 activity. The current owners of the PDP-11
software, Mentec, seem to be unusually difficult to get in touch with,
but I don't think they're dead yet..
-- 
roger ivie
rivie@ridgenet.net
0
rivie (670)
9/18/2009 10:10:31 PM
Bob Eager wrote:
> On Fri, 18 Sep 2009 12:54:14 -0500, Bob Koehler wrote:
> 
>> In article <7hhqleF2u15qvU2@mid.individual.net>, billg999@cs.uofs.edu
>> (Bill Gunshannon) writes:
>>> So then, you agree with me that DCL, per se, is not really a part of
>>> the OS as it functions just fine without it.
>>    Nope.  I've never seen a VMS system running without DCL.  Even when
>>    we used VMS in a manner similar to an embedded system it did have an
>>    OPA0, and we used DCL heavily.
> 
> I've seen a VMS system that didn't even have a console.
> 
> It was called an LPS-40.

While the LPS-40 had a VAX processor in it, it certainly was not running 
VMS.  Paul Anderson can probably state more accurately, but IIRC, it was 
running VAX-ELN.

-John
wb8tyw@qsl.network
Personal Opinion Only
0
wb8tyw (629)
9/18/2009 10:48:48 PM
In article <k7Usm.49249$5n1.27017@attbi_s21>, "John E. Malmberg" <wb8tyw@qsl.network> writes:
>Bob Eager wrote:
>> On Fri, 18 Sep 2009 12:54:14 -0500, Bob Koehler wrote:
>> 
>>> In article <7hhqleF2u15qvU2@mid.individual.net>, billg999@cs.uofs.edu
>>> (Bill Gunshannon) writes:
>>>> So then, you agree with me that DCL, per se, is not really a part of
>>>> the OS as it functions just fine without it.
>>>    Nope.  I've never seen a VMS system running without DCL.  Even when
>>>    we used VMS in a manner similar to an embedded system it did have an
>>>    OPA0, and we used DCL heavily.
>> 
>> I've seen a VMS system that didn't even have a console.
>> 
>> It was called an LPS-40.
>
>While the LPS-40 had a VAX processor in it, it certainly was not running 
>VMS.  Paul Anderson can probably state more accurately, but IIRC, it was 
>running VAX-ELN.

Correct John.  Same with the PrintServer17.


-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

  http://www.quirkfactory.com/popart/asskey/eqn2.png
  
  "Well my son, life is like a beanstalk, isn't it?"
0
VAXman
9/18/2009 11:23:10 PM
In article <alpine.LRH.0.9999.0909181309300.9014@honker.vgersoft.com>,
	Steve Thompson <smt@vgersoft.com> writes:
> On Fri, 18 Sep 2009, Bill Gunshannon wrote:
> 
>> Actually, it was Eunice.  I still have a ditro tape.  I just wish there
>> was some way to get a license to run it.
> 
> I ran Eunice for some time. Believe me, if you can't get a license to run 
> it, count yourself lucky.

Oh, I ran it, too.  And compared to the hardware I ran it on originally
any of my current systems should be screamers by comparison.  :-)

Mostly, I would like to be able to run it for the same reason many of
us still run the VAX (or even PDP-11's!! :-)

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
9/19/2009 12:02:48 AM
John E. Malmberg wrote:

> While the LPS-40 had a VAX processor in it, it certainly was not running 
> VMS.  Paul Anderson can probably state more accurately, but IIRC, it was 
> running VAX-ELN.

Weren't Decserver 200s also based on VAX (I had heard all mighty
Microvax II chips) ????
0
9/19/2009 12:38:33 AM
In article <002ffaa8$0$32502$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>John E. Malmberg wrote:
>
>> While the LPS-40 had a VAX processor in it, it certainly was not running 
>> VMS.  Paul Anderson can probably state more accurately, but IIRC, it was 
>> running VAX-ELN.
>
>Weren't Decserver 200s also based on VAX (I had heard all mighty
>Microvax II chips) ????

Motorola 68000

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

  http://www.quirkfactory.com/popart/asskey/eqn2.png
  
  "Well my son, life is like a beanstalk, isn't it?"
0
VAXman
9/19/2009 12:41:49 AM
ChrisQ wrote:
> R.A.Omond wrote:
> 
>>
>> Yes, DSM (or Caché as it is now).
> 
> So, is there any rt11 / rsx programming going on now, or any other 
> activity, or is pdp11 finally dead ?. There was some company that took 
> bought out the rights to cpu and os's, but I think they are out of 
> business now...
> 
> Regards,
> 
> Chris

ISTR reading about PDP-11 systems being used in Air Traffic Control. . . 
..  I think that there are still quite a few PDP11s out there doing 
process control and other humble jobs that don't require 2GHz processors 
, 64 bit words and 32GB of RAM.
0
rgilbert88 (4439)
9/19/2009 12:51:17 AM
Richard B. Gilbert wrote:

> 
> ISTR reading about PDP-11 systems being used in Air Traffic Control. . . 

I think that was at West Drayton in the uk and they were dec system 
20's, from what i've been told. Dovebid ran an auction of their standby 
generator systems and infrastructure recently. Several 1 and 1/2 
megawatt diesel sets. Those old systems certainly drew the power :-).

pdp11/05's were used for plant control in some of the early uk nuclear 
power stations. Some years ago, I liberated an 11/05 from a scrap yard 
and the cpu bus was stuck. The local dec dealer told me that all the 
11/05 sets were earmarked for the industry and eventually had to debug 
the board with a scope. A single 8640 bus driver turned out to be the 
culprit...

Chris
0
blackhole5 (113)
9/19/2009 10:02:54 AM
Steve Thompson wrote:
> On Fri, 18 Sep 2009, Bill Gunshannon wrote:
>
> > Actually, it was Eunice.  I still have a ditro tape.  I just wish there
> > was some way to get a license to run it.
>
> I ran Eunice for some time. Believe me, if you can't get a license to run
> it, count yourself lucky.
>
> Steve

I'll second that aversion to Eunice.

Back in 1985, I was working on a project where there were multiple
development platforms and multiple target platforms. The targets were
VMS and an embedded OS, but the development boxes were a mix of low
end VAX, early 68000 boxes running UNIX (System V), IBM PC/XT (?)
running Venturcom Venix UNIX (UNIX V7?), and big(ger) Gould/SEL UNIX
boxes (which were in the US whereas I was in the UK) which ran UTX-32,
a System V/BSD hybrid. The VMS boxes had Eunice (a somewhat dated BSD
derivative) available, but due to its unbelievably appalling
performance it really didn't make sense to use it in that environment.

This was back in the days when the C routine for opening a file took
two parameters on System V and three on BSD. Or was it the other way
round. UNIX? Portable? Not then it wasn't.

In the UK end of this outfit, the most productive software development
platform was the VAX/VMS one (on a 725, for goodness sake), especially
after the screen oriented debugger in V4. And the most productive
documentation development platform was also VMS, even though *roff was
the project's documentation standard of choice (edit on VMS with a
decent editor, automagically translate the majority of the *roff to
RUNOFF and see how it looks, and when it's close to right, uucp the
source to the horribly restricted horribly unreliable SysV box to feed
it through the real *roff to produce a version for review).

But productivity is rarely quantifiable in a way that matters to
purchasing departments and PHBs,whereas performance and in particular
price/performance make good publicity and and attract interest.

The result is that every corporate desktop now has a "personal
productivity tool", many (most?) of which are entirely inappropriate
for the jobs they are doing.
0
9/19/2009 2:12:53 PM
In article <P95GyM6TVnvR@eisner.encompasserve.org>,
 koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote:

> In article <7hdevbF2qoc2jU3@mid.individual.net>, billg999@cs.uofs.edu (Bill 
> Gunshannon) writes:
> > 
> > Bob you get more confusing every post.  What point?  I thought your point 
> > was that iPhones didn't run Unix and I just showed you that they do.
> 
>    No, my point was that the applications on the iPhone are
>    applications, not an OS.  Of course the iPhone has an OS, and I'm
>    not the least bit surprised if its Darwin based.

But you _can_ run standard unix utilities (ls, tar...) on an iPhone 
(even if you have to "jail break" it and install those utilities to do 
so).

-- 
Paul Sture
0
paul.nospam (2164)
9/19/2009 4:19:39 PM
In article <h8qjjn$ke$1@news-01.bur.connect.com.au>,
 "Richard Maher" <maher_rj@hotspamnotmail.com> wrote:

> HI Brian,
> 
> <VAXman- @SendSpamHere.ORG> wrote in message
> news:00A91A23.F17F6804@SendSpamHere.ORG...
> > In article <pdn0b5tbfum015s3pdbdpv99lb1e11aras@4ax.com>, Judge Judy
> <nospam@shaw.com> writes:
> > >Good bye VMS!   Good riddance COBOL.
> >
> > Troll...
> >
> For the record, you are responding to someone who is happy to go my the
> moniker Judge Judy. (Which I dare say is aspirational :-)
> > -- 
> Cheers Richard Maher

There's an X-Authenticated-User: value in his headers :-)

-- 
Paul Sture
0
paul.nospam (2164)
9/19/2009 4:29:17 PM
In article <k7Usm.49249$5n1.27017@attbi_s21>,
 "John E. Malmberg" <wb8tyw@qsl.network> wrote:

> Bob Eager wrote:
> > On Fri, 18 Sep 2009 12:54:14 -0500, Bob Koehler wrote:
> > 
> >> In article <7hhqleF2u15qvU2@mid.individual.net>, billg999@cs.uofs.edu
> >> (Bill Gunshannon) writes:
> >>> So then, you agree with me that DCL, per se, is not really a part of
> >>> the OS as it functions just fine without it.
> >>    Nope.  I've never seen a VMS system running without DCL.  Even when
> >>    we used VMS in a manner similar to an embedded system it did have an
> >>    OPA0, and we used DCL heavily.
> > 
> > I've seen a VMS system that didn't even have a console.
> > 
> > It was called an LPS-40.
> 
> While the LPS-40 had a VAX processor in it, it certainly was not running 
> VMS.  Paul Anderson can probably state more accurately, but IIRC, it was 
> running VAX-ELN.
> 

I'm pretty sure it was VAX-ELN. They took ages to boot from cold.

-- 
Paul Sture
0
paul.nospam (2164)
9/19/2009 4:56:45 PM
In article <HrRsm.2667$Jd7.2363@nwrddc02.gnilink.net>,
 xxx <xxx@yyy.zzz> wrote:

> BTW besides the alternate CLIs that have been mentioned, does anyone 
> recall /CLI=MCR back in the early days of VMS?  In fact if you enter MCR 
> as a bare command in DCL today it still knows that it should look for 
> RSX.EXE.  I think the RSX MCR alternate CLI support (and the supporting 
> RSX programs it used) were built into the base VMS distribution in the 
> early days and then it was pushed out to a layered product later on 
> (Around the time the "/11" stopped being on the end of CPU model numbers 
> when they went from hardware support to software support for the PDP-11 
> mode I thin)).  I don't know if the yayered product would still work on 
> the current versions of VMS.  I do know I kept it on my systems for a 
> long time so I could use certain features in the supporting RSX programs 
> that did not have equivalents in VMS.

Yes I remember it well. We were surprised when the RSX environment 
became a layered product - at V4.0 IIRC. I believe it became a 
separately licensed product circa V5, by which time we'd had ample time 
to convert the last few compatibility mode programs to native mode.

(I think we'd already done that by V4.0, but not everyone had.)

-- 
Paul Sture
0
paul.nospam (2164)
9/19/2009 5:02:15 PM
In article <0067c82e$0$30049$c3e8da3@news.astraweb.com>,
 JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

> re Unix used as command line.
> 
> Note that Apple has sold about 50 million Iphone and IpodTouch. Both are
> based on Unix (freebsd), and neither offer a command line and are 100%
> GUI. Add to that the millions of OS-X machines Apple has sold which are,
> in the majority of cases, used exclusively as a GUI, and I would say
> that today, the majority of Unix users don't even know they are on Unix
> because they are sheltered from stuff like "ls" and "vi" because of a
> well developped GUI.

Google on "iphone command line terminal"

:-)

-- 
Paul Sture
0
paul.nospam (2164)
9/19/2009 5:14:51 PM
In article <GZxA0FMEhsxA@eisner.encompasserve.org>,
 koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote:

> In article <7gvj6hF2ricj3U4@mid.individual.net>, Bob Eager 
> <rde42@spamcop.net> writes:
> > 
> > Anyway, 32 bit UNIX didn't arrive until *after* VMS. One would have to 
> > compare early UNIX (even on the PDP-11) with 16 bit VMS (or RSX-11, as we 
> > know it)! :-)
> 
>    Why?  The kernel design, file system design, and basic user interface
>    design hasn't changed since 16 bit UNIX.
> 
>    Don't bother with X11 as a claim to a better user interface.  The
>    fist thing UNIX users do with an X11 interface is bring up a shell
>    window.

You can change that to VMS and DECWindows and I am Guilty as Charged :-)

-- 
Paul Sture
0
paul.nospam (2164)
9/19/2009 5:27:55 PM
In article <7hi3e5F2stnnjU15@mid.individual.net>, Bob Eager <rde42@spamcop.net> writes:
> 
> It was called an LPS-40.

   Are you sure it wasn't running VAXeln?  Our LPS-08 was running
   VAXeln.  I can't imagine someone moving from VAXeln to VMS for that
   application.

0
koehler2 (8314)
9/21/2009 12:43:35 PM
In article <paul.nospam-100F24.18193919092009@mac.sture.ch>, "P. Sture" <paul.nospam@sture.ch> writes:
> 
> But you _can_ run standard unix utilities (ls, tar...) on an iPhone 
> (even if you have to "jail break" it and install those utilities to do 
> so).

   So what?  I can run those on VMS.

0
koehler2 (8314)
9/21/2009 1:43:02 PM
Bob Koehler wrote:
> In article <paul.nospam-100F24.18193919092009@mac.sture.ch>, "P. Sture" <paul.nospam@sture.ch> writes:
>> But you _can_ run standard unix utilities (ls, tar...) on an iPhone 
>> (even if you have to "jail break" it and install those utilities to do 
>> so).
> 
>    So what?  I can run those on VMS.
> 

But can you put VMS in your pocket?  Use it while strolling through the 
park?
0
rgilbert88 (4439)
9/21/2009 1:51:28 PM
On Sep 21, 2:51=A0pm, "Richard B. Gilbert" <rgilber...@comcast.net>
wrote:
> Bob Koehler wrote:
> > In article <paul.nospam-100F24.18193919092...@mac.sture.ch>, "P. Sture"=
 <paul.nos...@sture.ch> writes:
> >> But you _can_ run standard unix utilities (ls, tar...) on an iPhone
> >> (even if you have to "jail break" it and install those utilities to do
> >> so).
>
> > =A0 =A0So what? =A0I can run those on VMS.
>
> But can you put VMS in your pocket? =A0Use it while strolling through the
> park?

Yes there have been reports of VMS running on emulated VAXes on hand
held hardware.
0
gxys (807)
9/21/2009 2:04:53 PM
In article <a-2dnVjI5urLGSrXnZ2dnUVZ_sSdnZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> 
> But can you put VMS in your pocket?  Use it while strolling through the 
> park?

   If you can load ls on it, what would stop me from loading SIMH
   on it?

0
koehler2 (8314)
9/21/2009 6:18:32 PM
 "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>Bob Eager wrote:
>> On Fri, 11 Sep 2009 15:57:31 -0400, John Reagan wrote:
>> 
>>> "Bob Eager" <rde42@spamcop.net> wrote...
>>>> On Fri, 11 Sep 2009 17:46:35 +0200, Michael Kraemer wrote:
>>>>
>>>>> Paul Anderson schrieb:
>>>>>
>>>>>> Unix is older than VMS but don't confuse me with the facts.  ;-)
>>>>> At worst the difference is a few years only (and don't confuse Multics
>>>>> with Unix), which is insignificant in hindsight of 30* years.
>>>> Anyway, 32 bit UNIX didn't arrive until *after* VMS. One would have to
>>>> compare early UNIX (even on the PDP-11) with 16 bit VMS (or RSX-11, as
>>>> we know it)! :-)
>>> The Perkin-Elmer 8/32 (a 32-bit computer) ran a flavor of UNIX and was
>>> in the field before the first VAXen.  My former employer had one.  It
>>> was the first non-PDP-11 computer to run UNIX.
>> 
>> <pedant>
>> UNIX first appeared on the PDP-7, in around 1970. OK, it was written in 
>> assembler...!
>> </pedant>
>> 
>> Anyway...I'd be interested in dates. UNIX didn't go (semi-) public until 
>> about 1976 (I started using it in July 1976). Not sure about first VMS 
>> dates but I thought it was about then. Presumably the PE 8/32 (that was 
>> the Interdata later, wasn't it?) post-dates the PDP-11 version going 
>> public as v6?
>> 
>> Perhaps VMS was later than I thought, but 1976 sticks in my mind.
>
>Try 1978 for VMS and the VAX 11/780.  First customer shipment could have 
>been WAY after that but I think 1978 is a good date for the hardware and 
>software.

warning: possibly unreliable memory here

we had a 780 (in cambridge, uk) in late 1979.  someone else suggested
vms was buggy at first ship: i didn't find that.  it wasn't perfect,
and it did indeed have a lot of very lightly-ported rsx-11m apps.

(i know buggy oses: in my research life, both before and after the vax
period, i've written one and been part of the team for two others.)

and the fortran compiler also ran in compatibility mode, though (iirc)
it produced 32-bit code.

i loved it: as a systems programming platform, it was as well-designed
as ever i've dealt with.  the sort of thing one might tinker with
after retiring...
-- 
Robin Fairbairns, Cambridge

0
rf10 (3613)
9/22/2009 9:11:24 PM
koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:

> In article <mdd63biv4sj.fsf@panix5.panix.com>, Rich Alderson
> <news@alderson.users.panix.com> writes:

>> (No, Tops-10 does not have a fork/process model of computation.)

>    Are you sure?  TOPS-20 certainly did.  I thought the TOPS-20
>    internals were based on the TOPS-10 internals.

I'm quite sure.  Tops-10 and TOPS-20 shared no code whatsoever.

I say this as someone who has used TOPS-20 since September 1977, and
Tops-10 since July 2003, and in the intervening time has made a living as
a TOPS-20 developer and adminstrator, and more recently the same for
Tops-10.

Tops-10 developed out of the standard DEC-style OS for the PDP-6 (April
1964), and feels very familiar to anyone who has ever used OS/8 or RT-11
(and even more so to anyone who used TSS/8, which was developed by some
36-bit engineers to give a Tops-10 feel to the PDP-8).

TOPS-20, on the other hand, is a descendant of the TENEX operating system
written at Bolt Beranek & Newman as an experiment in demand-paged virtual
memory operating systems c. 1970.  The original hardware for TENEX was a
PDP-10 (KA-10 CPU) with a BBN pager; it was ported to the KI-10 CPU (the
first machine labeled a DECsystem-10), and even ran in a master-slave
dual processor configuration.

TENEX became TOPS-20 when DEC bought the design for a PDP-10 clone from
the Stanford Artificial Intelligence Laboratory known as the SuperFoonly,
and turned it into the KL-10 processor of the DECSYSTEM-20.  The original
marketing plan was to replace all Tops-10 systems with TOPS-20 systems,
and we'd all march happily into the future.

Tops-10 customers had a great deal to say about that at DECUS--and the
Large Systems SIG was the most powerful at that time--so DEC retrofitted
Tops-10 to the new hardware.  When DEC introduced the DECSYSTEM-2020 (the
KS-10 CPU, a smaller departmental system), ADP did the Tops-10 retrofit
on contract to DEC.

-- 
Rich Alderson                  "You get what anybody gets. You get a lifetime."
news@alderson.users.panix.com                           --Death, of the Endless
0
news83 (377)
9/23/2009 12:10:37 AM
Roger Ivie <rivie@ridgenet.net> writes:

> On 2009-09-18, ChrisQ <blackhole@devnull.com> wrote:

>> So, is there any rt11 / rsx programming going on now, or any other 
>> activity, or is pdp11 finally dead ?.

> A better place to ask would be alt.sys.pdp11.

> Yes, there is some PDP-11 activity. The current owners of the PDP-11
> software, Mentec, seem to be unusually difficult to get in touch with,
> but I don't think they're dead yet..

Mentec USA is very very dead.  The parent company in Ireland has been acquired
by a company that has no notion whatsoever of PDP-11 software.

I have learned this first hand while trying to line up licenses for RSX-11M,
RT-11, and RSTS/E for some of the PDP-11 systems in our museum collection.

-- 
Rich Alderson                  "You get what anybody gets. You get a lifetime."
news@alderson.users.panix.com                           --Death, of the Endless
0
news83 (377)
9/23/2009 12:16:10 AM
Rich Alderson schrieb:

> 
> Mentec USA is very very dead.  The parent company in Ireland has been acquired
> by a company that has no notion whatsoever of PDP-11 software.

Then why did they buy?

0
M.Kraemer (2048)
9/23/2009 5:40:02 AM
In article <h9behs$2ko$2@gemini.csx.cam.ac.uk>, rf10@cl.cam.ac.uk (Robin
Fairbairns) writes: 

> warning: possibly unreliable memory here

Maybe you should try out some of that new parity memory.

> we had a 780 (in cambridge, uk) in late 1979.  someone else suggested
> vms was buggy at first ship: i didn't find that.  it wasn't perfect,
> and it did indeed have a lot of very lightly-ported rsx-11m apps.

0
helbig (5064)
9/23/2009 6:57:24 AM
Michael Kraemer <M.Kraemer@gsi.de> writes:

> Rich Alderson schrieb:

>> Mentec USA is very very dead.  The parent company in Ireland has been
>> acquired by a company that has no notion whatsoever of PDP-11 software.

> Then why did they buy?

You would have to ask them that.  Mentec apparently had wider interests than
just the PDP-11, in any case.

-- 
Rich Alderson                  "You get what anybody gets. You get a lifetime."
news@alderson.users.panix.com                           --Death, of the Endless
0
news83 (377)
9/23/2009 6:39:32 PM
On Sep 23, 6:40=A0am, Michael Kraemer <M.Krae...@gsi.de> wrote:
> Rich Alderson schrieb:
>
>
>
> > Mentec USA is very very dead. =A0The parent company in Ireland has been=
 acquired
> > by a company that has no notion whatsoever of PDP-11 software.
>
> Then why did they buy?

Mentec were one of several companies bought by an outfit called Calyx.
Read the press releases and related coverage, if you wish, but you'll
probably be not much better informed. I didn't see much of a fit
between Calyx and the pieces of Mentec we know round here, but I think
Mentec were at one time a bigger company than we saw round here.
0
9/23/2009 7:00:44 PM
In article <h9cc9f$cea$03$1@news.t-online.com>,
	Michael Kraemer <M.Kraemer@gsi.de> writes:
> Rich Alderson schrieb:
> 
>> 
>> Mentec USA is very very dead.  The parent company in Ireland has been acquired
>> by a company that has no notion whatsoever of PDP-11 software.
> 
> Then why did they buy?

Probably because the PDP-11 was not Mentec's only (or even their primary)
line of products.

bill
 

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
9/23/2009 11:12:27 PM
In article <h9behs$2ko$2@gemini.csx.cam.ac.uk>, rf10@cl.cam.ac.uk (Robin Fairbairns) writes:
> 
> and the fortran compiler also ran in compatibility mode, though (iirc)
> it produced 32-bit code.

   So did the SOS editor.  You should have seen the CPU load on my
   11/780 go down when I convinced people full screen EDT was easier
   to learn than SOS was to use.

0
koehler2 (8314)
9/24/2009 1:26:56 PM
Bob Koehler wrote:
> In article <h9behs$2ko$2@gemini.csx.cam.ac.uk>, rf10@cl.cam.ac.uk (Robin Fairbairns) writes:
>> and the fortran compiler also ran in compatibility mode, though (iirc)
>> it produced 32-bit code.
> 
>    So did the SOS editor.  You should have seen the CPU load on my
>    11/780 go down when I convinced people full screen EDT was easier
>    to learn than SOS was to use.
> 

I had to use SOS early in my VMS career!  EDT was available but it 
required a DEC terminal, VT-52, VT-100 or VT-200.  Nobody had realized 
before we ordered our VAX, that it required proprietary terminals.  SOS 
wasn't too bad as an editor but I replaced as soon as wee got some VT 
compatible third party terminals for which we payed about $600 instead 
of the ~$2,000 each VT-220s.
0
rgilbert88 (4439)
9/24/2009 1:55:44 PM
On Sep 24, 2:26=A0pm, koeh...@eisner.nospam.encompasserve.org (Bob
Koehler) wrote:
> In article <h9behs$2k...@gemini.csx.cam.ac.uk>, r...@cl.cam.ac.uk (Robin =
Fairbairns) writes:
>
> > and the fortran compiler also ran in compatibility mode, though (iirc)
> > it produced 32-bit code.
>
> =A0 =A0So did the SOS editor. =A0You should have seen the CPU load on my
> =A0 =A011/780 go down when I convinced people full screen EDT was easier
> =A0 =A0to learn than SOS was to use.


SOS, Son of Stopgap - I used that on TOPS10 before I discovered
teco :-)
0
gxys (807)
9/24/2009 4:58:49 PM
In article <mdd7hvqa5c2.fsf@panix5.panix.com>, Rich Alderson <news@alderson.users.panix.com> writes:
> 
> I'm quite sure.  Tops-10 and TOPS-20 shared no code whatsoever.

   That's interesting.  Having used TOPS-10 and TOPS-20 I knew the
   user interface and OS calls were both quite different, but I did
   not know TOPS-20 was based on TENEX.  The TOPS-10 command interpeter
   was certainly much less verbose than the TOPS-20 EXEC.

   I wonder how hard it was supporting all the TOPS-10 UUOs in TOPS-20
   without a common base.

   Are you saying TOPS-10 was not a demand paged system?

0
koehler2 (8314)
9/24/2009 5:15:53 PM
In article <SL-dnUDFmOL_5ybXnZ2dnUVZ_u2dnZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> 
> I had to use SOS early in my VMS career!  EDT was available but it 
> required a DEC terminal, VT-52, VT-100 or VT-200.  Nobody had realized 
> before we ordered our VAX, that it required proprietary terminals.  SOS 
> wasn't too bad as an editor but I replaced as soon as wee got some VT 
> compatible third party terminals for which we payed about $600 instead 
> of the ~$2,000 each VT-220s.

   SOS, which was basically the same as TOPS-20 EDIT, is an editor I've
   gladly left behind.  By comparison, TECO, which I learned on TOPS-10
   but found was not as productive as EDIT on TOPS-20, is one I keep
   finding uses for on VMS.  And I'd gladly keep using EDT if I didn't
   have such a heavily customized TPU section developed prior to the
   ship of the supported EDT emulation.

0
koehler2 (8314)
9/24/2009 5:19:05 PM
On Thu, 24 Sep 2009 12:15:53 -0500, Bob Koehler wrote:

>  Are you saying TOPS-10 was not a demand paged system?

It certainly wasn't on the KA-10.

-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
9/24/2009 6:10:44 PM
IanMiller <gxys@uk2.net> wrote:
(snip)
 
> SOS, Son of Stopgap - I used that on TOPS10 before I discovered
> teco :-)

I used SOS on TOPS10 even after I knew about TECO.

Previously I had used WYLBUR on IBM systems, and SOS was close
enough to be easy to learn and use.

I didn't use TECO until I started working with RT-11.

-- glen
0
gah (12851)
9/24/2009 6:10:58 PM
Bob Koehler wrote:
> In article <SL-dnUDFmOL_5ybXnZ2dnUVZ_u2dnZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>> I had to use SOS early in my VMS career!  EDT was available but it 
>> required a DEC terminal, VT-52, VT-100 or VT-200.  Nobody had realized 
>> before we ordered our VAX, that it required proprietary terminals.  SOS 
>> wasn't too bad as an editor but I replaced as soon as wee got some VT 
>> compatible third party terminals for which we payed about $600 instead 
>> of the ~$2,000 each VT-220s.
> 
>    SOS, which was basically the same as TOPS-20 EDIT, is an editor I've
>    gladly left behind.  By comparison, TECO, which I learned on TOPS-10
>    but found was not as productive as EDIT on TOPS-20, is one I keep
>    finding uses for on VMS.  And I'd gladly keep using EDT if I didn't
>    have such a heavily customized TPU section developed prior to the
>    ship of the supported EDT emulation.
> 

I've used TECO a couple of times with great care.  You never know when 
you're going to mistype something and cause TECO to delete all your 
files and reboot the system!  Alright, I exaggerate somewhat!

There are a few jobs that TECO can do with great ease and that other 
editors do with great difficulty or not at all.  I would not care to use 
it as my regular text editor but I'm glad it's there.

0
rgilbert88 (4439)
9/24/2009 6:53:32 PM
On 2009-09-24, Bob Koehler <koehler@eisner.nospam.encompasserve.org> wrote:
> In article <SL-dnUDFmOL_5ybXnZ2dnUVZ_u2dnZ2d@giganews.com>, 
> "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>> 
>> I had to use SOS early in my VMS career!
>
>    SOS, which was basically the same as TOPS-20 EDIT, is an editor I've
>    gladly left behind. 

I also used SOS early in my VMS career.

I took to it quite quickly, since the command set was basically the same
as the line-editing commands used by the various Microsoft BASICs I had
been using on microcomputers. Given that Bill Gates developed BASIC on a
PDP-10, I suspect that is not coincidence.

Unlike the earlier comment about easing CPU usage by going to EDT, we
were often tracked down and hollered at when we switched to EDT on H19s
at the university. Of course, this may also have been related to
increasing the baud rate to 9600 before firing up EDT...
-- 
roger ivie
rivie@ridgenet.net
0
rivie (670)
9/24/2009 7:32:20 PM
koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:

> In article <mdd7hvqa5c2.fsf@panix5.panix.com>, Rich Alderson
> <news@alderson.users.panix.com> writes:

>> I'm quite sure.  Tops-10 and TOPS-20 shared no code whatsoever.

>    That's interesting.  Having used TOPS-10 and TOPS-20 I knew the
>    user interface and OS calls were both quite different, but I did
>    not know TOPS-20 was based on TENEX.  The TOPS-10 command interpeter
>    was certainly much less verbose than the TOPS-20 EXEC.

The Tops-10 command interpreter was part of the monitor ("kernel" for those
from a later time).  The TOPS-20 command interpreter was a user-mode program
called EXEC.EXE, and actually *can* be replaced by another user-mode program.

(Login directories have a "Must-Run-Program" attribute, with associated name
of the program to be run.  We experimented with our port of bash on the XKL
Toad-1.  It pretty much worked.)

>    I wonder how hard it was supporting all the TOPS-10 UUOs in TOPS-20
>    without a common base.

Not all the Tops-10 UUOs were supported.  The TOPS-20 code for that was frozen
in the Tops-10 5.03/6.01 time frame.  6.01 introduced Tops-10 to the KL-10.

>    Are you saying TOPS-10 was not a demand paged system?

Only very very late in its history.  I think that 7.03 was the first such
release; 7.04 certainly uses the TOPS-20 memory model.  In fact, a KL-10
is loaded with the same microcode for TOPS-20 v7.0 or Tops-10 v7.04.  Those
were released in the spring of 1989.  (I chaired the DECUS announcement
sessions in Cincinnati.)

-- 
Rich Alderson                  "You get what anybody gets. You get a lifetime."
news@alderson.users.panix.com                           --Death, of the Endless
0
news83 (377)
9/24/2009 9:38:11 PM
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> IanMiller <gxys@uk2.net> wrote:
> (snip)

>> SOS, Son of Stopgap - I used that on TOPS10 before I discovered teco :-)

> I used SOS on TOPS10 even after I knew about TECO.

> Previously I had used WYLBUR on IBM systems, and SOS was close
> enough to be easy to learn and use.

> I didn't use TECO until I started working with RT-11.

I used Wylbur and EDIT.EXE (the TOPS-20 version of SOS) until I learned EMACS,
after which I edited my 370 assembler on TOPS-20 and submitted jobs via a HASP
RJE station which was an 11/34 (badged as a DN60).  I learned MIT TECO in order
to do extensions to EMACS; now I'm the official maintainer.

-- 
Rich Alderson                  "You get what anybody gets. You get a lifetime."
news@alderson.users.panix.com                           --Death, of the Endless
0
news83 (377)
9/24/2009 9:43:10 PM
In article <k7Usm.49249$5n1.27017@attbi_s21>, "John E. Malmberg" <wb8tyw@qsl.network> writes:
>Bob Eager wrote:
>> On Fri, 18 Sep 2009 12:54:14 -0500, Bob Koehler wrote:
>> 
>>> In article <7hhqleF2u15qvU2@mid.individual.net>, billg999@cs.uofs.edu
>>> (Bill Gunshannon) writes:
>>>> So then, you agree with me that DCL, per se, is not really a part of
>>>> the OS as it functions just fine without it.
>>>    Nope.  I've never seen a VMS system running without DCL.  Even when
>>>    we used VMS in a manner similar to an embedded system it did have an
>>>    OPA0, and we used DCL heavily.
>> 
>> I've seen a VMS system that didn't even have a console.
>> 
>> It was called an LPS-40.
>
>While the LPS-40 had a VAX processor in it, it certainly was not running 
>VMS.  Paul Anderson can probably state more accurately, but IIRC, it was 
>running VAX-ELN.

That was my memory as well.  (I think that was true for LPS-17 as well.)

-- Alan
0
winston (523)
9/24/2009 10:11:34 PM
 billg999@cs.uofs.edu (Bill Gunshannon) writes:
>	Michael Kraemer <M.Kraemer@gsi.de> writes:
>> Paul Anderson schrieb:
>>> Unix is older than VMS but don't confuse me with the facts.  ;-)
>> 
>> At worst the difference is a few years only
>> (and don't confuse Multics with Unix),

multics was another interesting system, hampered far more than vms by
being based on a special design of hardware.  (i don't actually know
of any port of multics to a different architecture; when i re-read
organick's book a little while back, i was amazed that they achieved
anything as a multi-user service on such limited hardware.)

>> which is insignificant in hindsight of 30* years.
>
>Unix 1969
>VMS 1975
>
>That's 6 years.  A lifetime in this industry.

so people programming vms today are great-great-great-great-
grandchildren of those of us who started on v1.6?
-- 
Robin Fairbairns, Cambridge
0
rf10 (3613)
9/25/2009 9:25:11 AM
 billg999@cs.uofs.edu (Bill Gunshannon) writes:
>Bob Eager <rde42@spamcop.net> writes:
>> Surely the first attempt at VMS was a lot earlier....RSX?
>
>I hear this here quite a bit, but I see little in common betweem them.
>(At the actual OS level.)

i never quite saw it, but a colleague who did systems programming for
my team on rsx 11-m said the internal structure of rsx "felt" very
similar to those modules of vms "signed" by dave cutler.

(wouldn't it be nice if commercial operating systems nowadays arrived
with source listings?  vms was the last such that i saw.)
-- 
Robin Fairbairns, Cambridge
0
rf10 (3613)
9/25/2009 9:29:47 AM
On Fri, 25 Sep 2009 09:25:11 +0000, Robin Fairbairns wrote:

> multics was another interesting system, hampered far more than vms by
> being based on a special design of hardware.  (i don't actually know of
> any port of multics to a different architecture; when i re-read
> organick's book a little while back, i was amazed that they achieved
> anything as a multi-user service on such limited hardware.)

*some* of the Multics features (e.g. the mapping of files into virtual 
memory as the only method of access, thus unifying paging and I/O) were 
incorporated into EMAS, developed at Edinburgh. That worked on anything 
with a decent page size; started off on ICL System 4 (?) and was ported 
to the ICL 2900. Also on the Amdahl mainframes, and the IBM XA 
architecture (I did work to port it to a 4381).

We put out a tender to get a 4381 running that, and got a VAXcluster 
instead!
0
rde42 (1163)
9/25/2009 12:24:47 PM
In article <h9i29n$rnr$2@gemini.csx.cam.ac.uk>,
	rf10@cl.cam.ac.uk (Robin Fairbairns) writes:
>  billg999@cs.uofs.edu (Bill Gunshannon) writes:
>>	Michael Kraemer <M.Kraemer@gsi.de> writes:
>>> Paul Anderson schrieb:
>>>> Unix is older than VMS but don't confuse me with the facts.  ;-)
>>> 
>>> At worst the difference is a few years only
>>> (and don't confuse Multics with Unix),
> 
> multics was another interesting system, hampered far more than vms by
> being based on a special design of hardware.  (i don't actually know
> of any port of multics to a different architecture; when i re-read
> organick's book a little while back, i was amazed that they achieved
> anything as a multi-user service on such limited hardware.)
> 
>>> which is insignificant in hindsight of 30* years.
>>
>>Unix 1969
>>VMS 1975
>>
>>That's 6 years.  A lifetime in this industry.
> 
> so people programming vms today are great-great-great-great-
> grandchildren of those of us who started on v1.6?

A little low on your estimation.  There is a reason why people in the
industry today (like the academics I work with in my civilian job) all
refer to me as a dinosaur.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
9/25/2009 12:49:01 PM
In article <7i3r4fF2v7ng5U3@mid.individual.net>,
 Bob Eager <rde42@spamcop.net> wrote:

> On Fri, 25 Sep 2009 09:25:11 +0000, Robin Fairbairns wrote:
> 
> > multics was another interesting system, hampered far more than vms by
> > being based on a special design of hardware.  (i don't actually know of
> > any port of multics to a different architecture; when i re-read
> > organick's book a little while back, i was amazed that they achieved
> > anything as a multi-user service on such limited hardware.)
> 
> *some* of the Multics features (e.g. the mapping of files into virtual 
> memory as the only method of access, thus unifying paging and I/O) were 
> incorporated into EMAS, developed at Edinburgh. That worked on anything 
> with a decent page size; started off on ICL System 4 (?) and was ported 
> to the ICL 2900. Also on the Amdahl mainframes, and the IBM XA 
> architecture (I did work to port it to a 4381).
> 
> We put out a tender to get a 4381 running that, and got a VAXcluster 
> instead!

Do you remember CAFS - Content Addressable File Store? One of our VAX 
customers used that on their ICL kit and reported that it was blazingly 
fast for the time (early 1980s).

<http://en.wikipedia.org/wiki/Content_Addressable_File_Store>

-- 
Paul Sture
0
paul.nospam (2164)
9/25/2009 6:21:56 PM
In article <nz4P8Fesn1fg@eisner.encompasserve.org>,
 koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote:

> In article <SL-dnUDFmOL_5ybXnZ2dnUVZ_u2dnZ2d@giganews.com>, "Richard B. 
> Gilbert" <rgilbert88@comcast.net> writes:
> > 
> > I had to use SOS early in my VMS career!  EDT was available but it 
> > required a DEC terminal, VT-52, VT-100 or VT-200.  Nobody had realized 
> > before we ordered our VAX, that it required proprietary terminals.  SOS 
> > wasn't too bad as an editor but I replaced as soon as wee got some VT 
> > compatible third party terminals for which we payed about $600 instead 
> > of the ~$2,000 each VT-220s.
> 
>    SOS, which was basically the same as TOPS-20 EDIT, is an editor I've
>    gladly left behind.  By comparison, TECO, which I learned on TOPS-10
>    but found was not as productive as EDIT on TOPS-20, is one I keep
>    finding uses for on VMS.  And I'd gladly keep using EDT if I didn't
>    have such a heavily customized TPU section developed prior to the
>    ship of the supported EDT emulation.

I vaguely remember hating SOS, but our documentation guy liked it. 
Before a decent EDT keypad emulation for TPU came along I was working at 
customers a lot and my first job on being granted an account was to 
define my own TPU section with an EDT keypad. I did have it on TK50, but 
obviously not many places would let me load from that.

-- 
Paul Sture
0
paul.nospam (2164)
9/25/2009 6:29:17 PM
In article <slrnhbni7j.e3c.rivie@stench.no.domain>,
 Roger Ivie <rivie@ridgenet.net> wrote:

> On 2009-09-24, Bob Koehler <koehler@eisner.nospam.encompasserve.org> wrote:
> > In article <SL-dnUDFmOL_5ybXnZ2dnUVZ_u2dnZ2d@giganews.com>, 
> > "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> >> 
> >> I had to use SOS early in my VMS career!
> >
> >    SOS, which was basically the same as TOPS-20 EDIT, is an editor I've
> >    gladly left behind. 
> 
> I also used SOS early in my VMS career.
> 
> I took to it quite quickly, since the command set was basically the same
> as the line-editing commands used by the various Microsoft BASICs I had
> been using on microcomputers. Given that Bill Gates developed BASIC on a
> PDP-10, I suspect that is not coincidence.
> 
> Unlike the earlier comment about easing CPU usage by going to EDT, we
> were often tracked down and hollered at when we switched to EDT on H19s
> at the university. Of course, this may also have been related to
> increasing the baud rate to 9600 before firing up EDT...

Wasn't SOS compatibility mode? Perhaps that's why I disliked it. I do 
remember rejoicing when VMS finally supported 19200 baud.

-- 
Paul Sture
0
paul.nospam (2164)
9/25/2009 6:34:05 PM
In article <TkicnCo4rK2s@eisner.encompasserve.org>,
 koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote:

> In article <h9behs$2ko$2@gemini.csx.cam.ac.uk>, rf10@cl.cam.ac.uk (Robin 
> Fairbairns) writes:
> > 
> > and the fortran compiler also ran in compatibility mode, though (iirc)
> > it produced 32-bit code.
> 
>    So did the SOS editor.  You should have seen the CPU load on my
>    11/780 go down when I convinced people full screen EDT was easier
>    to learn than SOS was to use.

Thanks for confirming that. I believe EDI was also compatibility mode 
and we had a lot of ex-RSX folks who swore by it in spite of the fact 
that to go to the top of file it wrote out the current contents first. 
ISTR that it didn't support file versions either.

I'm pretty sure that early VAX COBOL was also a compatibility mode 
compiler, producing native code. And for some inexplicable reason an in 
house compiler was compatibility mode too. With a team of a dozen or 
more developers on an 11/750 I forced compilations into batch, and when 
the external software house complained that it was slowing the project 
down the customer bought them another 11/750 which I used purely for 
compilations (via dual ported disks).

-- 
Paul Sture
0
paul.nospam (2164)
9/25/2009 6:46:23 PM
On Fri, 25 Sep 2009 20:21:56 +0200, P. Sture wrote:

> In article <7i3r4fF2v7ng5U3@mid.individual.net>,
>  Bob Eager <rde42@spamcop.net> wrote:
> 
>> On Fri, 25 Sep 2009 09:25:11 +0000, Robin Fairbairns wrote:
>> 
>> > multics was another interesting system, hampered far more than vms by
>> > being based on a special design of hardware.  (i don't actually know
>> > of any port of multics to a different architecture; when i re-read
>> > organick's book a little while back, i was amazed that they achieved
>> > anything as a multi-user service on such limited hardware.)
>> 
>> *some* of the Multics features (e.g. the mapping of files into virtual
>> memory as the only method of access, thus unifying paging and I/O) were
>> incorporated into EMAS, developed at Edinburgh. That worked on anything
>> with a decent page size; started off on ICL System 4 (?) and was ported
>> to the ICL 2900. Also on the Amdahl mainframes, and the IBM XA
>> architecture (I did work to port it to a 4381).
>> 
>> We put out a tender to get a 4381 running that, and got a VAXcluster
>> instead!
> 
> Do you remember CAFS - Content Addressable File Store? One of our VAX
> customers used that on their ICL kit and reported that it was blazingly
> fast for the time (early 1980s).
> 
> <http://en.wikipedia.org/wiki/Content_Addressable_File_Store>

I heard of it, but given that we were running a home grown operating 
system, it wasn't something we got involved with. EMAS did support the 
DAP (Distributed Array Processor) on the 2900 though.



-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
9/25/2009 7:22:02 PM
P. Sture wrote:
> In article <nz4P8Fesn1fg@eisner.encompasserve.org>,
>  koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote:
> 
>> In article <SL-dnUDFmOL_5ybXnZ2dnUVZ_u2dnZ2d@giganews.com>, "Richard B. 
>> Gilbert" <rgilbert88@comcast.net> writes:
>>> I had to use SOS early in my VMS career!  EDT was available but it 
>>> required a DEC terminal, VT-52, VT-100 or VT-200.  Nobody had realized 
>>> before we ordered our VAX, that it required proprietary terminals.  SOS 
>>> wasn't too bad as an editor but I replaced as soon as wee got some VT 
>>> compatible third party terminals for which we payed about $600 instead 
>>> of the ~$2,000 each VT-220s.
>>    SOS, which was basically the same as TOPS-20 EDIT, is an editor I've
>>    gladly left behind.  By comparison, TECO, which I learned on TOPS-10
>>    but found was not as productive as EDIT on TOPS-20, is one I keep
>>    finding uses for on VMS.  And I'd gladly keep using EDT if I didn't
>>    have such a heavily customized TPU section developed prior to the
>>    ship of the supported EDT emulation.
> 
> I vaguely remember hating SOS, but our documentation guy liked it. 
> Before a decent EDT keypad emulation for TPU came along I was working at 
> customers a lot and my first job on being granted an account was to 
> define my own TPU section with an EDT keypad. I did have it on TK50, but 
> obviously not many places would let me load from that.
> 

I found that a 3-1/2" floppy disk was very handy for loading a skeleton 
login.com, edtini.edt, and a couple of other handy tools.  Since I was 
the System Manager nobody dared to object!  At the price I charged, it 
would have cost them dearly to have me type it all in and debug it.
0
rgilbert88 (4439)
9/25/2009 7:54:58 PM
In article <h9gcni$qid$1@naig.caltech.edu>, glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> IanMiller <gxys@uk2.net> wrote:
> (snip)
>  
>> SOS, Son of Stopgap - I used that on TOPS10 before I discovered
>> teco :-)
> 
> I used SOS on TOPS10 even after I knew about TECO.

   TOPS-10 was the first system I ever knew.  We were taught how to
   logon, use TECO, execute programs from source, and print files.
   Then we were told to go find a FORTRAN book and write a simple 
   program.

   This was a two week assignment in sophmore physics lab, the high
   energy group owned the PDP-10.  We were told that you did high 
   energy physics by collecting data on a PDP-11 and analyzing it
   on a PDP-10.

   And I knew we were lucky not to have to use the campus mainframe
   in the basement of the math building.  I once tried to help a friend
   with a "FORTRAN problem", but it turned out she was having a JCL
   problem.  I didn't have to learn JCL until I got my first job.

   But the PDP-11 was just a data collection device that I didn't
   really have to learn until I'd had a VAX for two years.

0
koehler2 (8314)
9/26/2009 12:35:50 AM
In article <slrnhbni7j.e3c.rivie@stench.no.domain>, Roger Ivie <rivie@ridgenet.net> writes:
> 
> I took to it quite quickly, since the command set was basically the same
> as the line-editing commands used by the various Microsoft BASICs I had
> been using on microcomputers. Given that Bill Gates developed BASIC on a
> PDP-10, I suspect that is not coincidence.

   Microsoft?  I learned it before Billy boy became a dropout.

0
koehler2 (8314)
9/26/2009 12:37:08 AM
In article <h9i2ib$rnr$3@gemini.csx.cam.ac.uk>, rf10@cl.cam.ac.uk (Robin Fairbairns) writes:
> 
> i never quite saw it, but a colleague who did systems programming for
> my team on rsx 11-m said the internal structure of rsx "felt" very
> similar to those modules of vms "signed" by dave cutler.

   Dave Cutler's I/O subsystem design shows up in RSX, VMS, and Windows.
   Which is the only thing Windows has in common with a real OS.

> 
> (wouldn't it be nice if commercial operating systems nowadays arrived
> with source listings?  vms was the last such that i saw.)

   You can get the sources to Linux, and make your own listings. 
   Problem left to the student of arcane command syntax:  how to get
   gcc to produce listings.  Solaris is also supposed to open source,
   but I'm not about to get to know Sun's C compiler that well.
   
   The last time I checked, DEC's VMS source listing CD was selling at
   about the same price as HP's HP-UX source listings.  But for HP-UX
   you first had to show you owned a UNIX source licence, which was
   somewhat more expensive, and the system you read or stored the files
   on was not allowed to be connected to any network except electric
   power.

   With all the holes people find in Windows now, can you imagine what
   major increase in the insanity would take place if they had the
   source listings to help them?

0
koehler2 (8314)
9/26/2009 12:45:36 AM
In article <paul.nospam-5156FD.20340525092009@pbook.sture.ch>, "P. Sture" <paul.nospam@sture.ch> writes:
> 
> Wasn't SOS compatibility mode?

   Yes, and was released via DECUS when it was removed from VMS, but
   binaries only.

0
koehler2 (8314)
9/26/2009 12:46:58 AM
Bob Koehler wrote:
> In article <h9gcni$qid$1@naig.caltech.edu>, glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>> IanMiller <gxys@uk2.net> wrote:
>> (snip)
>>  
>>> SOS, Son of Stopgap - I used that on TOPS10 before I discovered
>>> teco :-)
>> I used SOS on TOPS10 even after I knew about TECO.
> 
>    TOPS-10 was the first system I ever knew.  We were taught how to
>    logon, use TECO, execute programs from source, and print files.
>    Then we were told to go find a FORTRAN book and write a simple 
>    program.
> 
>    This was a two week assignment in sophmore physics lab, the high
>    energy group owned the PDP-10.  We were told that you did high 
>    energy physics by collecting data on a PDP-11 and analyzing it
>    on a PDP-10.
> 
>    And I knew we were lucky not to have to use the campus mainframe
>    in the basement of the math building.  I once tried to help a friend
>    with a "FORTRAN problem", but it turned out she was having a JCL
>    problem.  I didn't have to learn JCL until I got my first job.
> 
>    But the PDP-11 was just a data collection device that I didn't
>    really have to learn until I'd had a VAX for two years.
> 

JCL wasn't too bad.  You used canned procedures for most things and 
mostly you wrote "DD" statements to tell the system where to get your 
inputs and where to put your outputs.  It has been at least fifteen 
years since I last wrote any JCL and twenty-five years since I used it 
regularly.


0
rgilbert88 (4439)
9/26/2009 12:50:01 AM
In article <paul.nospam-52C6B8.20462325092009@pbook.sture.ch>, "P. Sture" <paul.nospam@sture.ch> writes:
> 
> Thanks for confirming that. I believe EDI was also compatibility mode 
> and we had a lot of ex-RSX folks who swore by it in spite of the fact 
> that to go to the top of file it wrote out the current contents first. 
> ISTR that it didn't support file versions either.

   Tried EDI on RSX and didn't care for it.  Then I tried KED and was
   quite sure I could see the heritage that EDT grew from.
 
> I'm pretty sure that early VAX COBOL was also a compatibility mode 
> compiler, producing native code.

   At VMS 2.0, I think FORTRAN and Macro were the only two running
   in native mode.
   
0
koehler2 (8314)
9/26/2009 12:50:12 AM
rf10@cl.cam.ac.uk (Robin Fairbairns) writes:

>  billg999@cs.uofs.edu (Bill Gunshannon) writes:
>>	Michael Kraemer <M.Kraemer@gsi.de> writes:
>>> Paul Anderson schrieb:

>>>> Unix is older than VMS but don't confuse me with the facts.  ;-)

>>> At worst the difference is a few years only
>>> (and don't confuse Multics with Unix),

> multics was another interesting system, hampered far more than vms by
> being based on a special design of hardware.  (i don't actually know
> of any port of multics to a different architecture; when i re-read
> organick's book a little while back, i was amazed that they achieved
> anything as a multi-user service on such limited hardware.)

Although some features of Multics did inspire other operating systems, no
one ever ported the entirety of Multics to any hardware not descended from
the original GE645.  Honeywell dubbed the family "the 6000 series" when they
bought GE's computer business, and moved Multics to the 6180, followed by
the Level 66, Level 68, and DPS-8M.

The only remaining Multics-capable hardware is the Dockmaster system, now
at the Computer History Museum in Mountain View, California, but even this
system can no longer run because the HDAs were removed from the disk drives
when it was de-installed from its home at the NSA.

>>> which is insignificant in hindsight of 30* years.

>> Unix 1969
>> VMS 1975

Umm, 1975 seems about 4 years too early.  The 780 shipped with RSX-11M at
first ship, with VMS 1.0 coming along a bit later.  Call it ten years
between original Unix (on a PDP-7!) and VMS.

>> That's 6 years.  A lifetime in this industry.

> so people programming vms today are great-great-great-great-
> grandchildren of those of us who started on v1.6?

If you want to get TeXnical, I suppose so.

(I do remember you from c.t.t, don't I?)

-- 
Rich Alderson                  "You get what anybody gets. You get a lifetime."
news@alderson.users.panix.com                           --Death, of the Endless
0
news83 (377)
9/26/2009 12:50:13 AM
Bob Koehler wrote:
> In article <h9i2ib$rnr$3@gemini.csx.cam.ac.uk>, rf10@cl.cam.ac.uk (Robin Fairbairns) writes:
>> i never quite saw it, but a colleague who did systems programming for
>> my team on rsx 11-m said the internal structure of rsx "felt" very
>> similar to those modules of vms "signed" by dave cutler.
> 
>    Dave Cutler's I/O subsystem design shows up in RSX, VMS, and Windows.
>    Which is the only thing Windows has in common with a real OS.
> 
>> (wouldn't it be nice if commercial operating systems nowadays arrived
>> with source listings?  vms was the last such that i saw.)
> 
>    You can get the sources to Linux, and make your own listings. 
>    Problem left to the student of arcane command syntax:  how to get
>    gcc to produce listings.  Solaris is also supposed to open source,
>    but I'm not about to get to know Sun's C compiler that well.
>    
>    The last time I checked, DEC's VMS source listing CD was selling at
>    about the same price as HP's HP-UX source listings.  But for HP-UX
>    you first had to show you owned a UNIX source licence, which was
>    somewhat more expensive, and the system you read or stored the files
>    on was not allowed to be connected to any network except electric
>    power.
> 
>    With all the holes people find in Windows now, can you imagine what
>    major increase in the insanity would take place if they had the
>    source listings to help them?
> 

Keeping bad code a secret in order to prevent hacking is, to say the 
least, a poor way to do business.  Sun has made most of the Solaris 
source code available for comment, criticism, and improvement.  The 
stuff that's still not public belongs in whole or in part to third 
parties and is used by Sun under license.
0
rgilbert88 (4439)
9/26/2009 12:59:51 AM
Rich Alderson wrote:
> rf10@cl.cam.ac.uk (Robin Fairbairns) writes:
> 
>>  billg999@cs.uofs.edu (Bill Gunshannon) writes:
>>> 	Michael Kraemer <M.Kraemer@gsi.de> writes:
>>>> Paul Anderson schrieb:
> 
>>>>> Unix is older than VMS but don't confuse me with the facts.  ;-)
> 
>>>> At worst the difference is a few years only
>>>> (and don't confuse Multics with Unix),
> 
>> multics was another interesting system, hampered far more than vms by
>> being based on a special design of hardware.  (i don't actually know
>> of any port of multics to a different architecture; when i re-read
>> organick's book a little while back, i was amazed that they achieved
>> anything as a multi-user service on such limited hardware.)
> 
> Although some features of Multics did inspire other operating systems, no
> one ever ported the entirety of Multics to any hardware not descended from
> the original GE645.  Honeywell dubbed the family "the 6000 series" when they
> bought GE's computer business, and moved Multics to the 6180, followed by
> the Level 66, Level 68, and DPS-8M.
> 
> The only remaining Multics-capable hardware is the Dockmaster system, now
> at the Computer History Museum in Mountain View, California, but even this
> system can no longer run because the HDAs were removed from the disk drives
> when it was de-installed from its home at the NSA.

Those disks were probably chock full of "burn before reading" material. 
  No way to be certain that the data was erased beyond hope of recovery 
so  the HDAs went into the fire.

0
rgilbert88 (4439)
9/26/2009 1:12:12 AM
Bob Eager wrote:

> *some* of the Multics features (e.g. the mapping of files into virtual 
> memory as the only method of access, thus unifying paging and I/O) were 
> incorporated into EMAS, developed at Edinburgh. That worked on anything 
> with a decent page size; started off on ICL System 4 (?) and was ported 
> to the ICL 2900. Also on the Amdahl mainframes, and the IBM XA 
> architecture (I did work to port it to a 4381).

Yes, Bob, EMAS started off on the ICL System 4/75.  The Wikipedia entry
for EMAS at:

http://en.wikipedia.org/wiki/Edinburgh_Multiple_Access_System

is pretty accurate as far as my memory goes.  I did my B.Sc (Computer
Science) at Edinburgh in the mid-1970s and remember EMAS with great
fondness.  Quoting from the Wikipedia article:

"EMAS had several advanced (for the time) features, including dynamic 
linking, multi-level storage, an efficient scheduler, a separate 
user-space kernel ('director'), a user-level shell ('basic command 
interpreter'), and a memory-mapped file architecture. Such features lead 
EMAS supporters to claim that their system was superior to Unix for the 
first 20 years of the latter's existence."

Things have steadily got worse since those good old days ;-)

0
Roy.Omond (380)
9/26/2009 10:35:57 AM
On Sat, 26 Sep 2009 11:35:57 +0100, R.A.Omond wrote:

> Bob Eager wrote:
> 
>> *some* of the Multics features (e.g. the mapping of files into virtual
>> memory as the only method of access, thus unifying paging and I/O) were
>> incorporated into EMAS, developed at Edinburgh. That worked on anything
>> with a decent page size; started off on ICL System 4 (?) and was ported
>> to the ICL 2900. Also on the Amdahl mainframes, and the IBM XA
>> architecture (I did work to port it to a 4381).
> 
> Yes, Bob, EMAS started off on the ICL System 4/75.  The Wikipedia entry
> for EMAS at:
> 
> http://en.wikipedia.org/wiki/Edinburgh_Multiple_Access_System
> 
> is pretty accurate as far as my memory goes.  I did my B.Sc (Computer
> Science) at Edinburgh in the mid-1970s and remember EMAS with great
> fondness.

The 2900 version was a great improvement due to the greater amount of 
virtual memory available to map files. I have report CSR-18-77 right 
here: "An Experiment in Doing it Again, But Very Well This Time"...!

I had to port quite a few programs from EMAS to VMS, and wrote libraries 
to map files in the same way using the VMS systems services.

I still have the EMAS source code...!
-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
9/26/2009 10:41:06 AM
On Sat, 26 Sep 2009 10:41:06 +0000, Bob Eager wrote:

>> Yes, Bob, EMAS started off on the ICL System 4/75.  The Wikipedia entry
>> for EMAS at:
>> 
>> http://en.wikipedia.org/wiki/Edinburgh_Multiple_Access_System
>> 
>> is pretty accurate as far as my memory goes.  I did my B.Sc (Computer
>> Science) at Edinburgh in the mid-1970s and remember EMAS with great
>> fondness.
> 
> The 2900 version was a great improvement due to the greater amount of
> virtual memory available to map files. I have report CSR-18-77 right
> here: "An Experiment in Doing it Again, But Very Well This Time"...!
> 
> I had to port quite a few programs from EMAS to VMS, and wrote libraries
> to map files in the same way using the VMS systems services.

Just to be a bit more on-topic:

EMAS had dual CPU support from the early 1980s. We installed a dual CPU 
in 1983, and I had to write the model-specific code by reverse 
enginerring the microcode (I had a source listing).

The major guy who produced the SMP code was someone by the name of Bill 
Laing. He later went to Digital, and you can find his name in the SMP 
source code for VMS...!



-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
9/26/2009 11:02:17 AM
On Sep 11, 4:25=A0pm, Bob Eager <rd...@spamcop.net> wrote:
> On Fri, 11 Sep 2009 15:57:31 -0400, John Reagan wrote:
> > "Bob Eager" <rd...@spamcop.net> wrote in message
> >news:7gvj6hF2ricj3U4@mid.individual.net...
> >> On Fri, 11 Sep 2009 17:46:35 +0200, Michael Kraemer wrote:
>
> >>> Paul Anderson schrieb:
>
> >>>> Unix is older than VMS but don't confuse me with the facts. =A0;-)
>
> >>> At worst the difference is a few years only (and don't confuse Multic=
s
> >>> with Unix), which is insignificant in hindsight of 30* years.
>
> >> Anyway, 32 bit UNIX didn't arrive until *after* VMS. One would have to
> >> compare early UNIX (even on the PDP-11) with 16 bit VMS (or RSX-11, as
> >> we know it)! :-)
>
> > The Perkin-Elmer 8/32 (a 32-bit computer) ran a flavor of UNIX and was
> > in the field before the first VAXen. =A0My former employer had one. =A0=
It
> > was the first non-PDP-11 computer to run UNIX.
>
> <pedant>
> UNIX first appeared on the PDP-7, in around 1970. OK, it was written in
> assembler...!
> </pedant>
>
> Anyway...I'd be interested in dates. UNIX didn't go (semi-) public until
> about 1976 (I started using it in July 1976). Not sure about first VMS
> dates but I thought it was about then. Presumably the PE 8/32 (that was
> the Interdata later, wasn't it?) post-dates the PDP-11 version going
> public as v6?
>
> Perhaps VMS was later than I thought, but 1976 sticks in my mind.
>
> --
> Use the BIG mirror service in the UK:
> =A0http://www.mirrorservice.org

Actually, October 1977, San Diego DECUS convention was the official
public viewing of VAX-11/VMS.  First customer ship was in February
1978 (as I recall).

Bill.
0
pedersen (385)
9/27/2009 7:52:57 PM
 billg999@cs.uofs.edu (Bill Gunshannon) writes:
>	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>> Bob Eager <rde42@spamcop.net> writes:
>> 
>>> Anyway, 32 bit UNIX didn't arrive until *after* VMS. One would have to 
>>> compare early UNIX (even on the PDP-11) with 16 bit VMS (or RSX-11, as we 
>>> know it)! :-)
>> 
>>    Why?  The kernel design, file system design, and basic user interface
>>    design hasn't changed since 16 bit UNIX.
>> 
>>    Don't bother with X11 as a claim to a better user interface.  The
>>    fist thing UNIX users do with an X11 interface is bring up a shell
>>    window.
> 
>Still passing out that FUD, I see.  I have been a Unix user since the late
>70's and an X user since X10.  I bring up a shell window when the task that
>needs to be done is a shell task and I use a GUI Window when that is the
>appropriate inerface.  And, I expect the majority of real Unix users are
>and alwyas have been the same.

and it's irrelevant.  everyone _knows_ what un*x will and won't do for
you.  this thread started with a question about the future of vms, not
the past of unix; the past of unix is boring, except insofar as it
holds innovations that might be useful in the future of vms.  (having
been away from vms for so long, i couldn't possibly comment.)
-- 
Robin Fairbairns, Cambridge
0
rf10 (3613)
9/27/2009 8:55:04 PM
In article <Fc2dnfSHw9YW-iDXnZ2dnUVZ_gydnZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>
> Keeping bad code a secret in order to prevent hacking is, to say the 
> least, a poor way to do business.  Sun has made most of the Solaris 
> source code available for comment, criticism, and improvement.  The 
> stuff that's still not public belongs in whole or in part to third 
> parties and is used by Sun under license.

   Obviously Sun and Microsoft don't think the same!  Sun was one of the
   early proponents of "open sysytems".  Microsoft owns the most closed
   system in the business.  Nobody is allowed to see inside!

0
koehler2 (8314)
9/28/2009 1:15:59 PM
In article <+klqzn95w7HU@eisner.encompasserve.org>,
 koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote:

> In article <Fc2dnfSHw9YW-iDXnZ2dnUVZ_gydnZ2d@giganews.com>, "Richard B. 
> Gilbert" <rgilbert88@comcast.net> writes:
> >
> > Keeping bad code a secret in order to prevent hacking is, to say the 
> > least, a poor way to do business.  Sun has made most of the Solaris 
> > source code available for comment, criticism, and improvement.  The 
> > stuff that's still not public belongs in whole or in part to third 
> > parties and is used by Sun under license.
> 
>    Obviously Sun and Microsoft don't think the same!  Sun was one of the
>    early proponents of "open sysytems".  Microsoft owns the most closed
>    system in the business.  Nobody is allowed to see inside!

That was a source of frustration when I was seriously looking at NT.  
Various folks were coming out with stuff I couldn't find in any 
documentation and I was wondering where on earth they got it.

-- 
Paul Sture
0
paul.nospam (2164)
9/28/2009 2:19:08 PM
On Mon, 28 Sep 2009 08:15:59 -0500, Bob Koehler wrote:

> In article <Fc2dnfSHw9YW-iDXnZ2dnUVZ_gydnZ2d@giganews.com>, "Richard B.
> Gilbert" <rgilbert88@comcast.net> writes:
>>
>> Keeping bad code a secret in order to prevent hacking is, to say the
>> least, a poor way to do business.  Sun has made most of the Solaris
>> source code available for comment, criticism, and improvement.  The
>> stuff that's still not public belongs in whole or in part to third
>> parties and is used by Sun under license.
> 
>    Obviously Sun and Microsoft don't think the same!  Sun was one of the
>    early proponents of "open sysytems".  Microsoft owns the most closed
>    system in the business.  Nobody is allowed to see inside!

Not true. We had access to the NT source code, and I think it's still 
around somewhere.

Not that I thought much of the quality...



-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
9/28/2009 4:09:38 PM
Bob Eager wrote:

> 
> Not true. We had access to the NT source code, and I think it's still 
> around somewhere.
> 
> Not that I thought much of the quality...
> 
> 

Not a windows apologist, but by the time they got all the service packs 
sorted out and bug free drivers, NT 4 was quite robust and would run 
essentially for ever. I only moved from Nt 4 for one of my software dev 
boxes because some apps needed w2k minimum. Not for any reliability issues.

Would have liked to see the NT sources. It was the first windows os that 
could be considered for serious work, even if a little ragged to start 
with...

Regards,

Chris






0
ChrisQ
9/29/2009 1:59:33 PM
On Tue, 29 Sep 2009 14:59:33 +0100, ChrisQ wrote:

> Bob Eager wrote:
>> Not true. We had access to the NT source code, and I think it's still
>> around somewhere.
>> 
>> Not that I thought much of the quality...
>> 
> Not a windows apologist, but by the time they got all the service packs
> sorted out and bug free drivers, NT 4 was quite robust and would run
> essentially for ever. I only moved from Nt 4 for one of my software dev
> boxes because some apps needed w2k minimum. Not for any reliability
> issues.

By 'quality', I meant well written, i.e. properly laid out, commented, 
maintainable. It works OK!

-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
9/29/2009 7:48:50 PM
Bob Eager wrote:
> On Tue, 29 Sep 2009 14:59:33 +0100, ChrisQ wrote:
> 
>> Bob Eager wrote:
>>> Not true. We had access to the NT source code, and I think it's still
>>> around somewhere.
>>>
>>> Not that I thought much of the quality...
>>>
>> Not a windows apologist, but by the time they got all the service packs
>> sorted out and bug free drivers, NT 4 was quite robust and would run
>> essentially for ever. I only moved from Nt 4 for one of my software dev
>> boxes because some apps needed w2k minimum. Not for any reliability
>> issues.
> 
> By 'quality', I meant well written, i.e. properly laid out, commented, 
> maintainable. It works OK!
> 

Nice but don't hold your breath.  Spaghetti minds produce spaghetti 
code!  The people who write spaghetti code don't care about niceties 
such as structured code they just want results.  NOW!  That someone else 
might need to use, or even understand, the spaghetti code is not their 
problem!

The same program may be written by several dozen or even several hundred 
people before someone takes the trouble to "do it right"!
0
rgilbert88 (4439)
9/30/2009 12:49:32 AM
In article <7if6l2F30a3ujU2@mid.individual.net>,
 Bob Eager <rde42@spamcop.net> wrote:

> By 'quality', I meant well written, i.e. properly laid out, commented, 
> maintainable. It works OK!

The thing that raised warning signals with me once I saw the NT APIs was 
the dependence on null terminated strings.  I'd spent a lot of time in 
VMS applications eradicating those by adding a length parameter or using 
descriptors.

And when CPU was the limiting factor, I didn't see the point of scanning 
a string parameter to find the terminating null when the calling routine 
knew the length of the string in the first place.

-- 
Paul Sture
0
paul.nospam (2164)
9/30/2009 10:17:31 PM
On Thu, 01 Oct 2009 00:17:31 +0200, P. Sture wrote:

> In article <7if6l2F30a3ujU2@mid.individual.net>,
>  Bob Eager <rde42@spamcop.net> wrote:
> 
>> By 'quality', I meant well written, i.e. properly laid out, commented,
>> maintainable. It works OK!
> 
> The thing that raised warning signals with me once I saw the NT APIs was
> the dependence on null terminated strings.  I'd spent a lot of time in
> VMS applications eradicating those by adding a length parameter or using
> descriptors.
> 
> And when CPU was the limiting factor, I didn't see the point of scanning
> a string parameter to find the terminating null when the calling routine
> knew the length of the string in the first place.

I think that's inevitable when the major language in use is C. That's a 
design issue; I was thinking more of how well the code was (not) written.



-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
10/1/2009 6:35:58 AM
In article <7ij0ueF30a3ujU4@mid.individual.net>, Bob Eager <rde42@spamcop.net> writes:
> 
> I think that's inevitable when the major language in use is C. That's a 
> design issue; I was thinking more of how well the code was (not) written.

   Which makes you wonder why the inventors of C settled on such a design 
   in a day when CPUs were so much slower.  If I had a system slower
   than a PDP-11/70, I'd have wanted it to spend it's time doing better
   things.

0
koehler2 (8314)
10/1/2009 2:07:02 PM
In article <7ij0ueF30a3ujU4@mid.individual.net>,
 Bob Eager <rde42@spamcop.net> wrote:

> On Thu, 01 Oct 2009 00:17:31 +0200, P. Sture wrote:
> 
> > In article <7if6l2F30a3ujU2@mid.individual.net>,
> >  Bob Eager <rde42@spamcop.net> wrote:
> > 
> >> By 'quality', I meant well written, i.e. properly laid out, commented,
> >> maintainable. It works OK!
> > 
> > The thing that raised warning signals with me once I saw the NT APIs was
> > the dependence on null terminated strings.  I'd spent a lot of time in
> > VMS applications eradicating those by adding a length parameter or using
> > descriptors.
> > 
> > And when CPU was the limiting factor, I didn't see the point of scanning
> > a string parameter to find the terminating null when the calling routine
> > knew the length of the string in the first place.
> 
> I think that's inevitable when the major language in use is C. That's a 
> design issue; I was thinking more of how well the code was (not) written.

From time to time folks have written here about defensive programming in 
C to avoid that (I don't remember the details).

Some of the coding examples I found on the web in the early NT 4 era 
seemed alarmingly short on error return checking to my eyes, but I don't 
know how well those examples represented what the NT code itself was 
like.

-- 
Paul Sture
0
paul.nospam (2164)
10/1/2009 4:11:36 PM
On Thu, 01 Oct 2009 09:07:02 -0500, Bob Koehler wrote:

> In article <7ij0ueF30a3ujU4@mid.individual.net>, Bob Eager
> <rde42@spamcop.net> writes:
>> 
>> I think that's inevitable when the major language in use is C. That's a
>> design issue; I was thinking more of how well the code was (not)
>> written.
> 
>    Which makes you wonder why the inventors of C settled on such a
>    design in a day when CPUs were so much slower.  If I had a system
>    slower than a PDP-11/70, I'd have wanted it to spend it's time doing
>    better things.

I never saw that that, in particular, caused any kind of performance 
problem. The libraries that used it were few - it's not often that you 
need to know the length of a string; more often you need to know when 
you've reached the end, and that is equally well served by a count or a 
terminator.

However, they didn't want a real limit on the lengths of strings. If 
they'd used a length prefix (as the predecessor to C did) they'd have had 
to make it two bytes, minimum. That would have used an extra byte per 
string, a waste of an even more valuable resource.

CPU time is 'extensible'; you can wait a little longer. Memory is not; 
lack of it is a showstopper (overlays aside).



-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
10/1/2009 4:25:27 PM
Bob Eager <rde42@spamcop.net> wrote:
< On Thu, 01 Oct 2009 09:07:02 -0500, Bob Koehler wrote:
<> In article <7ij0ueF30a3ujU4@mid.individual.net>, Bob Eager
<> <rde42@spamcop.net> writes:
 
<>    Which makes you wonder why the inventors of C settled on such a
<>    design in a day when CPUs were so much slower.  If I had a system
<>    slower than a PDP-11/70, I'd have wanted it to spend it's time doing
<>    better things.
 
< I never saw that that, in particular, caused any kind of performance 
< problem. The libraries that used it were few - it's not often that you 
< need to know the length of a string; more often you need to know when 
< you've reached the end, and that is equally well served by a count or a 
< terminator.

I have.  I have seen strcat() called inside a loop for building
up a string while reading it in one line at a time.  The resulting
algorithm is O(n**2).  (O(pow(n,2)) for C programmers.)  It was
fast enough in testing, but in production the strings were millions
of characters long and most of the time was spent in that loop.
 
< However, they didn't want a real limit on the lengths of strings. If 
< they'd used a length prefix (as the predecessor to C did) they'd have had 
< to make it two bytes, minimum. That would have used an extra byte per 
< string, a waste of an even more valuable resource.

One result of null termination is the easy buffer overflow of
many programs today that don't properly check lengths.  Length
at the beginning doesn't work so well if you want pointers to
other than the beginning of a string.  The other way is with
a structure containing a length and pointer, pretty much what
Java does with String.
 
< CPU time is 'extensible'; you can wait a little longer. Memory is not; 
< lack of it is a showstopper (overlays aside).

Assuming that the program finishes before you need the result.

-- glen
0
gah (12851)
10/1/2009 5:14:37 PM
On Oct 1, 6:14=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Bob Eager <rd...@spamcop.net> wrote:
>
> < On Thu, 01 Oct 2009 09:07:02 -0500, Bob Koehler wrote:
> <> In article <7ij0ueF30a3u...@mid.individual.net>, Bob Eager
>
> <> <rd...@spamcop.net> writes:
>
> <> =A0 =A0Which makes you wonder why the inventors of C settled on such a
> <> =A0 =A0design in a day when CPUs were so much slower. =A0If I had a sy=
stem
> <> =A0 =A0slower than a PDP-11/70, I'd have wanted it to spend it's time =
doing
> <> =A0 =A0better things.
>
> < I never saw that that, in particular, caused any kind of performance
> < problem. The libraries that used it were few - it's not often that you
> < need to know the length of a string; more often you need to know when
> < you've reached the end, and that is equally well served by a count or a
> < terminator.
>
> I have. =A0I have seen strcat() called inside a loop for building
> up a string while reading it in one line at a time. =A0The resulting
> algorithm is O(n**2). =A0(O(pow(n,2)) for C programmers.) =A0It was
> fast enough in testing, but in production the strings were millions
> of characters long and most of the time was spent in that loop.
>
> < However, they didn't want a real limit on the lengths of strings. If
> < they'd used a length prefix (as the predecessor to C did) they'd have h=
ad
> < to make it two bytes, minimum. That would have used an extra byte per
> < string, a waste of an even more valuable resource.
>
> One result of null termination is the easy buffer overflow of
> many programs today that don't properly check lengths. =A0Length
> at the beginning doesn't work so well if you want pointers to
> other than the beginning of a string. =A0The other way is with
> a structure containing a length and pointer, pretty much what
> Java does with String.
>
> < CPU time is 'extensible'; you can wait a little longer. Memory is not;
> < lack of it is a showstopper (overlays aside).
>
> Assuming that the program finishes before you need the result.
>
> -- glen

In addition to the above (thank you for saving me pointing out that
the right answer late is sometimes unacceptable ie wrong), there seems
to be a class of security exploit which involves building a string
with an embedded null followed by data which isn't ignored because the
string length processing is different depending on who's doing it.
E.g. http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2009-2666

..ASCIZ was OK for MACRO11 and similar static strings, but for dynamic
stuff, descriptors and support routines are hard to beat.
0
10/1/2009 6:14:57 PM
John Wallace <johnwallace4@yahoo.co.uk> wrote:
(big snip)
 
> In addition to the above (thank you for saving me pointing out that
> the right answer late is sometimes unacceptable ie wrong), there seems
> to be a class of security exploit which involves building a string
> with an embedded null followed by data which isn't ignored because the
> string length processing is different depending on who's doing it.
> E.g. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2666
> 
> .ASCIZ was OK for MACRO11 and similar static strings, but for dynamic
> stuff, descriptors and support routines are hard to beat.

So was DEC the originator of null terminated strings?

-- glen
0
gah (12851)
10/1/2009 6:41:17 PM
On Thu, 01 Oct 2009 18:41:17 +0000, glen herrmannsfeldt wrote:

> John Wallace <johnwallace4@yahoo.co.uk> wrote: (big snip)
>  
>> In addition to the above (thank you for saving me pointing out that the
>> right answer late is sometimes unacceptable ie wrong), there seems to
>> be a class of security exploit which involves building a string with an
>> embedded null followed by data which isn't ignored because the string
>> length processing is different depending on who's doing it. E.g.
>> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2666
>> 
>> .ASCIZ was OK for MACRO11 and similar static strings, but for dynamic
>> stuff, descriptors and support routines are hard to beat.
> 
> So was DEC the originator of null terminated strings?

Well, OS/8 had them in the PAL assembler. That puts it before C and UNIX.

-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
10/1/2009 6:49:08 PM
On Thu, 1 Oct 2009 at 18:49 -0000, Bob Eager wrote:

> On Thu, 01 Oct 2009 18:41:17 +0000, glen herrmannsfeldt wrote:
>
>> So was DEC the originator of null terminated strings?
>
> Well, OS/8 had them in the PAL assembler. That puts it before C and 
> UNIX.

And also before the PDP-11, which was an architecture that nicely 
handled null-terminated strings.  It would appear that the 
functionality followed the usage rather than the other way around.

- Rob


-- 

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/

0
mylastname3 (505)
10/1/2009 8:01:39 PM
P. Sture wrote:
> In article <7if6l2F30a3ujU2@mid.individual.net>,
>  Bob Eager <rde42@spamcop.net> wrote:
> 
>> By 'quality', I meant well written, i.e. properly laid out, commented, 
>> maintainable. It works OK!
> 
> The thing that raised warning signals with me once I saw the NT APIs was 
> the dependence on null terminated strings.  I'd spent a lot of time in 
> VMS applications eradicating those by adding a length parameter or using 
> descriptors.
> 
> And when CPU was the limiting factor, I didn't see the point of scanning 
> a string parameter to find the terminating null when the calling routine 
> knew the length of the string in the first place.
> 

Well, you don't always know the length of the string and one way way is 
for the caller to know the buffer limits of the function that's being 
called and range check before calling. Either that (or preferably) the 
called function needs to range check any input during the copy to make 
sure it doesn't overflow it's own buffer. It has no real impact on 
performance. If you do any buffer copy without this, you deserve what 
you get.

But we are a bit out of date here - The later C lib functions like 
strncpy() did have a length parameter and stuff like this has been 
around in the C lib for 15+ years.

It's not the tools that are the problem, but those who use them :-)...

Regards,

Chris
0
ChrisQ
10/1/2009 8:39:15 PM
ChrisQ <meru@devnull.com> wrote:
(big snip)
 
< But we are a bit out of date here - The later C lib functions like 
< strncpy() did have a length parameter and stuff like this has been 
< around in the C lib for 15+ years.

Have you looked at strncpy()?

It pads the destianation with null characters out to the
specified length.  For large n that can be even slower than using
strcat() in a loop.

-- glen 
0
gah (12851)
10/1/2009 9:39:59 PM
glen herrmannsfeldt schrieb:

> 
> I have.  I have seen strcat() called inside a loop for building
> up a string while reading it in one line at a time.  The resulting
> algorithm is O(n**2).  (O(pow(n,2)) for C programmers.)  It was
> fast enough in testing, but in production the strings were millions
> of characters long and most of the time was spent in that loop.

The str*() functions exist for convenience.
If one has problems of that kind, I'd indeed store
data in a dedicated struct (ptr,len).

> 
> One result of null termination is the easy buffer overflow of
> many programs today 

Such as?

> that don't properly check lengths. 

this is not restricted to null-termination.

Anyway, I do not see why null termination would
naturally lead to buffer overflow.
I'm not aware of any libc function which
uses the null to mark the end of an area you
are allowed to *write* to.
With the exception of *printf() (and gets()) all writable
buffers have a specified maximum length.

0
M.Kraemer (2048)
10/2/2009 5:45:57 AM
 "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>Bob Koehler wrote:
>>  rf10@cl.cam.ac.uk (Robin Fairbairns) writes:
>>> and the fortran compiler also ran in compatibility mode, though (iirc)
>>> it produced 32-bit code.
>> 
>>    So did the SOS editor.  You should have seen the CPU load on my
>>    11/780 go down when I convinced people full screen EDT was easier
>>    to learn than SOS was to use.
>
>I had to use SOS early in my VMS career!

i had forgotten sos.  (selective memory...)

when we first got our vax, i started a porting exercise for a rather
more rational line-based editor by an old colleague at the university.

>EDT was available but it 
>required a DEC terminal, VT-52, VT-100 or VT-200.  Nobody had realized 
>before we ordered our VAX, that it required proprietary terminals.  SOS 
>wasn't too bad as an editor but I replaced as soon as wee got some VT 
>compatible third party terminals for which we payed about $600 instead 
>of the ~$2,000 each VT-220s.

we bought (rather grotty) compatibles, and worked with them for a long
time.  their arrival stopped my porting effort (it was going slowly
anyway, due to workload).

however, we were a dec oem, and eventually dec made us an offer we
couldn't refuse, for vt100s.  i never liked vt100s much but they were
an awful lot better than the previous compatibles.
-- 
Robin Fairbairns, Cambridge
0
rf10 (3613)
10/2/2009 10:08:16 AM
Robin Fairbairns wrote:

>  [...snip...]
> 
> when we first got our vax, i started a porting exercise for a rather
> more rational line-based editor by an old colleague at the university.

Robin, that wouldn't have been ZED by Phil Hazel by any chance ?  One of
my all-time favourite line-mode editors (I'm also an old Phoenix user
from the mid-1970s ;-)

> we bought (rather grotty) compatibles, and worked with them for a long
> time.  their arrival stopped my porting effort (it was going slowly
> anyway, due to workload).

Worth resurrecting the porting effort ?
0
Roy.Omond (380)
10/2/2009 10:57:44 AM
glen herrmannsfeldt wrote:
> ChrisQ <meru@devnull.com> wrote:
> (big snip)
>  
> < But we are a bit out of date here - The later C lib functions like 
> < strncpy() did have a length parameter and stuff like this has been 
> < around in the C lib for 15+ years.
> 
> Have you looked at strncpy()?
> 
> It pads the destianation with null characters out to the
> specified length.  For large n that can be even slower than using
> strcat() in a loop.
> 
> -- glen 

Gone are they days when you went to make some coffee, or took half the 
day off while task builder did it's thing. Modern machines are so fast 
that stuff like that is irrelevant for all intents and purposes. i/o 
bandwidth and latency are more likely to be the culprit.

The second thing is, what length string are you copying ?, If it's 
megabytes, then you could argue program design needs to be addressed...

Regards,

Chris
0
ChrisQ
10/2/2009 11:25:03 AM
On Fri, 02 Oct 2009 11:57:44 +0100, R.A.Omond wrote:

> Robin Fairbairns wrote:
> 
>>  [...snip...]
>> 
>> when we first got our vax, i started a porting exercise for a rather
>> more rational line-based editor by an old colleague at the university.
> 
> Robin, that wouldn't have been ZED by Phil Hazel by any chance ?  One of
> my all-time favourite line-mode editors (I'm also an old Phoenix user
> from the mid-1970s ;-)
> 
>> we bought (rather grotty) compatibles, and worked with them for a long
>> time.  their arrival stopped my porting effort (it was going slowly
>> anyway, due to workload).
> 
> Worth resurrecting the porting effort ?

Or was it ECCE? I have the VMS version here...





-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
10/2/2009 11:43:43 AM
Bob Eager wrote:
> On Fri, 02 Oct 2009 11:57:44 +0100, R.A.Omond wrote:
> 
>> Robin Fairbairns wrote:
>>
>>>  [...snip...]
>>>
>>> when we first got our vax, i started a porting exercise for a rather
>>> more rational line-based editor by an old colleague at the university.
>> Robin, that wouldn't have been ZED by Phil Hazel by any chance ?  One of
>> my all-time favourite line-mode editors (I'm also an old Phoenix user
>> from the mid-1970s ;-)
>>
>>> we bought (rather grotty) compatibles, and worked with them for a long
>>> time.  their arrival stopped my porting effort (it was going slowly
>>> anyway, due to workload).
>> Worth resurrecting the porting effort ?
> 
> Or was it ECCE? I have the VMS version here...

Bob, I somehow doubt it would have been ECCE - that was an Edinburgh
creation.  Robin's been at Cambridge for at least 100 years ;-)

Interesting nevertheless...
0
Roy.Omond (380)
10/2/2009 12:30:10 PM
En/na Michael Kraemer ha escrit:
> 
> The str*() functions exist for convenience.
> If one has problems of that kind, I'd indeed store
> data in a dedicated struct (ptr,len).
> 
>>
>> One result of null termination is the easy buffer overflow of
>> many programs today 
> 

Programmers are, some times, lazy. Specially when they work under 
unrealistic schedules and not enough resources. You can find a lot of 
things like this in production:

void someFunction(char *someString) {
	char aBuffer[1024];

	.
	.
	.
	strcpy(aBuffer, someString);
	doSomething(aBuffer);
	.
	.
	.
}

The problem is that in C you don't have tools (AFAIK) to catch time 
bombs like this one in compilation time nor, probably, in test time. In 
higher level languages (COBOL, PLI, even java) you can enable runtime 
range checking, and in some cases, even compiletime verification (which 
usually gives a WARNING). But not in C. You can have this code working 
quietly for years... until a programmer writes something which calls 
someFunction() with a 2048 bytes string. Or something who passes a 
pointer to something entered by a user. That's when things become 
interesting, since in architectures like x86 that can overwrite the 
stack frame, and with a well crafted overwrite you can make someFunction 
to return to your own bad code.

There are hundreds of examples. Take a look at the CVE reports.

Of course, that could'nt happen in a VAX. All you would get is a ACCVIO, 
since VAX has a exec bit for each page, and the stack should not be exec 
utable. But on the x86 they have that kind of protection only recently.

I don't know how does this apply to Alpha nor iA64. But on a purely 
stack-based, non-execution protected environment like whatever OS on 
x86, the NULL-terminated strings are an exploit waiting to happen.
0
send.me (12)
10/2/2009 1:18:30 PM
Jordi Guillaumes i Pons wrote:
> En/na Michael Kraemer ha escrit:
>>
>> The str*() functions exist for convenience.
>> If one has problems of that kind, I'd indeed store
>> data in a dedicated struct (ptr,len).
>>
>>>
>>> One result of null termination is the easy buffer overflow of
>>> many programs today 
>>
> 
> Programmers are, some times, lazy. Specially when they work under 
> unrealistic schedules and not enough resources. You can find a lot of 
> things like this in production:
> 
> void someFunction(char *someString) {
>     char aBuffer[1024];
> 
>     .
>     .
>     .
>     strcpy(aBuffer, someString);
>     doSomething(aBuffer);
>     .
>     .
>     .
> }
> 
> The problem is that in C you don't have tools (AFAIK) to catch time 
> bombs like this one in compilation time nor, probably, in test time. In 
> higher level languages (COBOL, PLI, even java) you can enable runtime 
> range checking, and in some cases, even compiletime verification (which 
> usually gives a WARNING). But not in C. You can have this code working 
> quietly for years... until a programmer writes something which calls 
> someFunction() with a 2048 bytes string. Or something who passes a 
> pointer to something entered by a user. That's when things become 
> interesting, since in architectures like x86 that can overwrite the 
> stack frame, and with a well crafted overwrite you can make someFunction 
> to return to your own bad code.
> 
> There are hundreds of examples. Take a look at the CVE reports.
> 

Poor design of the language and poor design of the program!  The authors 
of C wanted "creative freedom" and no backtalk from the compiler.

DEC C allows you to do a lot of checking or to shut up its complaining 
and compile what you wrote.  If you elect the latter option, you assume 
responsibility.  If you work at it you can do all sorts of damage.
0
rgilbert88 (4439)
10/2/2009 1:52:53 PM
In article <5ju4ah.m8l.ln@gw1>, Jordi Guillaumes i Pons <send.me@no.spam> writes:
>{...snip...}
>Of course, that could'nt happen in a VAX. All you would get is a ACCVIO, 
>since VAX has a exec bit for each page, and the stack should not be exec 
>utable. But on the x86 they have that kind of protection only recently.

Envision Rod Sterling walking out from the background darkness into the 
shadowy light, camera focused on him from his lapel and tie, and with a
cigarette lit and its smoke encircling his head...

    "Picture, if you will, a man who has just consumed too much wine 
     or too much LSD or who has simply fallen squarely upon his pate
     from an appreciable height, and is now totally delusional in the 
     usenet newsgroup of comp.Twilight.Zone..."

Where's this VAX exec bit?  

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

  http://www.quirkfactory.com/popart/asskey/eqn2.png
  
  "Well my son, life is like a beanstalk, isn't it?"
0
VAXman
10/2/2009 1:59:00 PM
On Fri, 02 Oct 2009 15:18:30 +0200, Jordi Guillaumes i Pons wrote:

> En/na Michael Kraemer ha escrit:
>> 
>> The str*() functions exist for convenience. If one has problems of that
>> kind, I'd indeed store data in a dedicated struct (ptr,len).
>>> One result of null termination is the easy buffer overflow of many
>>> programs today
>> 
> Programmers are, some times, lazy. Specially when they work under
> unrealistic schedules and not enough resources. You can find a lot of
> things like this in production:
> 
> void someFunction(char *someString) {
> 	char aBuffer[1024];
> 
> 	.
> 	.
> 	.
> 	strcpy(aBuffer, someString);
> 	doSomething(aBuffer);
> 	.
> 	.
> 	.
> }
> 
> The problem is that in C you don't have tools (AFAIK)

Google "Purify memory checker"

> interesting, since in architectures like x86 that can overwrite the
> stack frame

As you can in the VAX...

> Of course, that could'nt happen in a VAX. All you would get is a ACCVIO,
> since VAX has a exec bit for each page, and the stack should not be exec
> utable. But on the x86 they have that kind of protection only recently.

The exec bit won't save the stack frame. It'll stop part of the stack 
being executed as code, and it'll stop a corrupted return link diving 
into non-code, but it won't stop a corrupted return link diving into a 
different bit of code.
-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
10/2/2009 2:50:27 PM
On Fri, 02 Oct 2009 13:30:10 +0100, R.A.Omond wrote:

> Bob Eager wrote:
>> On Fri, 02 Oct 2009 11:57:44 +0100, R.A.Omond wrote:
>> 
>>> Robin Fairbairns wrote:
>>>
>>>>  [...snip...]
>>>>
>>>> when we first got our vax, i started a porting exercise for a rather
>>>> more rational line-based editor by an old colleague at the
>>>> university.
>>> Robin, that wouldn't have been ZED by Phil Hazel by any chance ?  One
>>> of my all-time favourite line-mode editors (I'm also an old Phoenix
>>> user from the mid-1970s ;-)
>>>
>>>> we bought (rather grotty) compatibles, and worked with them for a
>>>> long time.  their arrival stopped my porting effort (it was going
>>>> slowly anyway, due to workload).
>>> Worth resurrecting the porting effort ?
>> 
>> Or was it ECCE? I have the VMS version here...
> 
> Bob, I somehow doubt it would have been ECCE - that was an Edinburgh
> creation.  Robin's been at Cambridge for at least 100 years ;-)
> 
> Interesting nevertheless...

Oh, I know it was an Edinburgh creation. But it seems to turn up 
everywhere!

-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
10/2/2009 2:51:41 PM
 Rich Alderson <news@alderson.users.panix.com> writes:
>rf10@cl.cam.ac.uk (Robin Fairbairns) writes:
>>  billg999@cs.uofs.edu (Bill Gunshannon) writes:
>>> That's 6 years.  A lifetime in this industry.
>>
>> so people programming vms today are great-great-great-great-
>> grandchildren of those of us who started on v1.6?
>
>If you want to get TeXnical, I suppose so.
>
>(I do remember you from c.t.t, don't I?)

since you say so ;-) -- it's certainly possible.  i started using tex
on a vms machine, and had to haggle with the managing director of the
firm for a trivial amount of money to make the ln03 tex bitmap font
capable.  (pretty unusual -- they seldom accepted "we need it" as an
argument for equipment purchases.)
-- 
Robin Fairbairns, Cambridge
0
rf10 (3613)
10/2/2009 3:43:05 PM
En/na VAXman- @SendSpamHere.ORG ha escrit:
> 
> Envision Rod Sterling walking out from the background darkness into the 
> shadowy light, camera focused on him from his lapel and tie, and with a
> cigarette lit and its smoke encircling his head...
> 
>     "Picture, if you will, a man who has just consumed too much wine 
>      or too much LSD or who has simply fallen squarely upon his pate
>      from an appreciable height, and is now totally delusional in the 
>      usenet newsgroup of comp.Twilight.Zone..."
> 
> Where's this VAX exec bit?  

Perhaps in my imagination? I don't read about VAX arch and VMS internals 
sinde the early nineties, but I _think_ the entries in the page table 
have a protection mask allows marking a page as readable, but 
non-executable. I am wrong on that? Too many years, too much coffee and 
too many arch changes in my life... :(

0
send.me (12)
10/2/2009 4:12:30 PM
En/na Bob Eager ha escrit:
>>interesting, since in architectures like x86 that can overwrite the
>>stack frame
> 
> 
> As you can in the VAX...

Specially if you program in C and "think" in C. If you follow the rules 
(VAX Calling and Conditio Handling IIRC) you should use descriptors to 
pass strings. And your routine _should_ check if the lenght of the 
string passed as parameter fits in your buffer.

C is a good language for systems programming. I've always thought of it 
as an assembly language on steroids. For a systems programmer pointers 
are part of his daily life. But those things have no place in a payroll 
program. And, for the sake of the security, neither in a web server.


>>Of course, that could'nt happen in a VAX. All you would get is a ACCVIO,
>>since VAX has a exec bit for each page, and the stack should not be exec
>>utable. But on the x86 they have that kind of protection only recently.
> 
> 
> The exec bit won't save the stack frame. It'll stop part of the stack 
> being executed as code, and it'll stop a corrupted return link diving 
> into non-code, but it won't stop a corrupted return link diving into a 
> different bit of code.


Yep, but if the stack itself is not executable the bad guy will have 
more difficulties to do nasty things. First of all, he (or she) will not 
be able of putting a snippet of code in the stack. Yes, he could 
redirect the program to do nasty things... but not WHATEVER nasty thing.

Oh, by the way, I don't have if this has REALLY happened. Do you nou 
about any succesful attack against a VAX running VMS using a 
buffer/stack overflow?


0
send.me (12)
10/2/2009 4:20:22 PM
In article <cp85ah.k4n.ln@gw1>, Jordi Guillaumes i Pons <send.me@no.spam> writes:
>En/na VAXman- @SendSpamHere.ORG ha escrit:
>> 
>> Envision Rod Sterling walking out from the background darkness into the 
>> shadowy light, camera focused on him from his lapel and tie, and with a
>> cigarette lit and its smoke encircling his head...
>> 
>>     "Picture, if you will, a man who has just consumed too much wine 
>>      or too much LSD or who has simply fallen squarely upon his pate
>>      from an appreciable height, and is now totally delusional in the 
>>      usenet newsgroup of comp.Twilight.Zone..."
>> 
>> Where's this VAX exec bit?  
>
>Perhaps in my imagination? I don't read about VAX arch and VMS internals 
>sinde the early nineties, but I _think_ the entries in the page table 
>have a protection mask allows marking a page as readable, but 
>non-executable. I am wrong on that? Too many years, too much coffee and 
>too many arch changes in my life... :(

VAX PTE's maintain read and write access for the various modes only.  There
is no EXECUTE bit.  Not on the Alpha either.  Only on ia64 is there such a
concept.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

  http://www.quirkfactory.com/popart/asskey/eqn2.png
  
  "Well my son, life is like a beanstalk, isn't it?"
0
VAXman
10/2/2009 4:41:44 PM
In article <4895ah.i6n.ln@gw1>, Jordi Guillaumes i Pons <send.me@no.spam> writes:
>En/na Bob Eager ha escrit:
>>>interesting, since in architectures like x86 that can overwrite the
>>>stack frame
>> 
>> 
>> As you can in the VAX...
>
>Specially if you program in C and "think" in C. If you follow the rules 
>(VAX Calling and Conditio Handling IIRC) you should use descriptors to 
>pass strings. And your routine _should_ check if the lenght of the 
>string passed as parameter fits in your buffer.
>
>C is a good language for systems programming. I've always thought of it 
>as an assembly language on steroids. For a systems programmer pointers 
>are part of his daily life. But those things have no place in a payroll 
>program. And, for the sake of the security, neither in a web server.

Macro is an assembly language on steroids.  Bliss is an assembly language
on steroids.  C needs Altoids, not steroids, because it stinks.  It doesn't
even have a decent macro capability.


>>>Of course, that could'nt happen in a VAX. All you would get is a ACCVIO,
>>>since VAX has a exec bit for each page, and the stack should not be exec
>>>utable. But on the x86 they have that kind of protection only recently.
>> 
>> 
>> The exec bit won't save the stack frame. It'll stop part of the stack 
>> being executed as code, and it'll stop a corrupted return link diving 
>> into non-code, but it won't stop a corrupted return link diving into a 
>> different bit of code.
>
>
>Yep, but if the stack itself is not executable the bad guy will have 
>more difficulties to do nasty things. First of all, he (or she) will not 
>be able of putting a snippet of code in the stack. Yes, he could 
>redirect the program to do nasty things... but not WHATEVER nasty thing.
>
>Oh, by the way, I don't have if this has REALLY happened. Do you nou 
>about any succesful attack against a VAX running VMS using a 
>buffer/stack overflow?

Yes.  About a year ago there was much discussion here with respect to one 
of the RTL routines employed  in many of the system utilities for command
line input and recall.  I still have a simple 20 Alpha instruction "hack"
to demonstrate the exploit dated 17-Aug-2008.  I think if you go back and
google this news group for article around that time frame with DEFCON in
them, you should be able to find some info.  HP issued a patch for this
vulnerability.  Hopefully, sites installed it.


-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

  http://www.quirkfactory.com/popart/asskey/eqn2.png
  
  "Well my son, life is like a beanstalk, isn't it?"
0
VAXman
10/2/2009 4:53:44 PM
ChrisQ wrote:

> Gone are they days when you went to make some coffee, or took half the 
> day off while task builder did it's thing. Modern machines are so fast 
> that stuff like that is irrelevant for all intents and purposes. 

That is when you have a "standard" OS and you can build something with
built-in tools and not spend half a year to first port the various tools
needed for the build scripts (which themselves need tools you need to
port and so on and so on).
0
10/2/2009 6:39:40 PM
En/na VAXman- @SendSpamHere.ORG ha escrit:
> In article <cp85ah.k4n.ln@gw1>, Jordi Guillaumes i Pons <send.me@no.spam> writes:
> 
>>Perhaps in my imagination? I don't read about VAX arch and VMS internals 
>>sinde the early nineties, but I _think_ the entries in the page table 
>>have a protection mask allows marking a page as readable, but 
>>non-executable. I am wrong on that? Too many years, too much coffee and 
>>too many arch changes in my life... :(
> 
> 
> VAX PTE's maintain read and write access for the various modes only.  There
> is no EXECUTE bit.  Not on the Alpha either.  Only on ia64 is there such a
> concept.

OK I stand corrected...

0
send.me (12)
10/2/2009 7:26:56 PM
In article <ha442l$t2i$03$1@news.t-online.com>, Michael Kraemer <M.Kraemer@gsi.de> writes:
> 
> Anyway, I do not see why null termination would
> naturally lead to buffer overflow.
> I'm not aware of any libc function which
> uses the null to mark the end of an area you
> are allowed to *write* to.
> With the exception of *printf() (and gets()) all writable
> buffers have a specified maximum length.

   It's simply not true that all writebale buffers have a maximum
   specified length, from the point of view of a function.

   It's trivial to pass a pointer to a string to a function without the
   function knowing the size of the buffer, as in the size you're code
   declared it.

   A trivial example:

void a(char* b, char *c, char* d)
{
   for (; *d = *b; d++, b++);
   for (; *d = *c; d++, c++);
}

main ()
{
   char d[10];

   a("1234567890", "1234567890", d);
}

   In the above example, function a() will stuff 21 characters into 10 
   character buffer d, writing over who knows what in memory.  a() can
   see that string b is 11 characters, and string c is 11 characters,
   and will overwrite the null character it copied from b with the first 
   character of c, but it has no way of knowing that d is only 11
   characters.

   This is a common problem with C library routines such as strcat.

0
koehler2 (8314)
10/2/2009 9:16:05 PM
In article <5ju4ah.m8l.ln@gw1>, Jordi Guillaumes i Pons <send.me@no.spam> writes:
> 
> Of course, that could'nt happen in a VAX. All you would get is a ACCVIO, 
> since VAX has a exec bit for each page, and the stack should not be exec 
> utable. But on the x86 they have that kind of protection only recently.

   This is simply not true.  Once again:  the exec bit on VAX is only
   a hint to the linker, it is not enforced at runtime.
 
> I don't know how does this apply to Alpha nor iA64. But on a purely 
> stack-based, non-execution protected environment like whatever OS on 
> x86, the NULL-terminated strings are an exploit waiting to happen.

   On IA64, and I think some Alpha, the exec bit is enforced at run
   time.

0
koehler2 (8314)
10/2/2009 9:22:08 PM
In article <4895ah.i6n.ln@gw1>, Jordi Guillaumes i Pons <send.me@no.spam> writes:
> 
> Oh, by the way, I don't have if this has REALLY happened. Do you nou 
> about any succesful attack against a VAX running VMS using a 
> buffer/stack overflow?

   There have been at least dos attacks.

0
koehler2 (8314)
10/2/2009 9:23:30 PM
<VAXman- @SendSpamHere.ORG> wrote in message 
news:00A926E6.293C5FBD@SendSpamHere.ORG...

> VAX PTE's maintain read and write access for the various modes only. 
> There
> is no EXECUTE bit.  Not on the Alpha either.  Only on ia64 is there such a
> concept.
>

I don't remember the details but Tru64 Alpha has something to prevent you 
from executing on the stack.  I seem to remember having to call some 
mprotect() service in order to execute the Bound Procedure Values defined in 
the Tru64 Calling Standard.  I wonder how that is implemented?

John 


0
johnrreagan (372)
10/3/2009 12:48:26 AM
Jordi Guillaumes i Pons schrieb:

> 
> Programmers are, some times, lazy. Specially when they work under 
> unrealistic schedules and not enough resources. 

I don't buy that. Errors of the kind below are not
due to lack of resources.

> You can find a lot of 
> things like this in production:
> 
> void someFunction(char *someString) {
>     char aBuffer[1024];
>     strcpy(aBuffer, someString);
>     doSomething(aBuffer);
> }

That's not a problem of null termination,
it's a problem of writing to an area you do not own.
This may happen in any language, i.e.
Assuming a fixed size of your data objects
because it would never ever been exceeded
(Y2K comes to mind).
In C, one would have used sth like
aBuffer = calloc( strlen(someString)+1, sizeof(*aBuffer) )

> 
> The problem is that in C you don't have tools (AFAIK) to catch time 
> bombs like this one in compilation time nor, probably, in test time. In 
> higher level languages (COBOL, PLI, even java) you can enable runtime 
> range checking, 

and it would be switched off for production release,
where most of the buffer oflos would surface.

> and in some cases, even compiletime verification (which 
> usually gives a WARNING). But not in C. 

That would be a compiler issue, not a language issue.

> You can have this code working 
> quietly for years... until a programmer writes something which calls 
> someFunction() with a 2048 bytes string. Or something who passes a 
> pointer to something entered by a user. That's when things become 
> interesting, since in architectures like x86 that can overwrite the 
> stack frame, and with a well crafted overwrite you can make someFunction 
> to return to your own bad code.

That would be an architecture issue, not a language issue.

0
M.Kraemer (2048)
10/3/2009 5:45:56 AM
In article <ha6oek$gn9$02$1@news.t-online.com>, Michael Kraemer <M.Kraemer@gsi.de> writes:
>Jordi Guillaumes i Pons schrieb:
>
>> 
>> Programmers are, some times, lazy. Specially when they work under 
>> unrealistic schedules and not enough resources. 
>
>I don't buy that. Errors of the kind below are not
>due to lack of resources.
>
>> You can find a lot of 
>> things like this in production:
>> 
>> void someFunction(char *someString) {
>>     char aBuffer[1024];
>>     strcpy(aBuffer, someString);

strncpy!!

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

  http://www.quirkfactory.com/popart/asskey/eqn2.png
  
  "Well my son, life is like a beanstalk, isn't it?"
0
VAXman
10/3/2009 1:44:24 PM
VAXman- @SendSpamHere.ORG wrote:
> In article <ha6oek$gn9$02$1@news.t-online.com>, Michael Kraemer <M.Kraemer@gsi.de> writes:
>> Jordi Guillaumes i Pons schrieb:
>>
>>> Programmers are, some times, lazy. Specially when they work under 
>>> unrealistic schedules and not enough resources. 
>> I don't buy that. Errors of the kind below are not
>> due to lack of resources.
>>
>>> You can find a lot of 
>>> things like this in production:
>>>
>>> void someFunction(char *someString) {
>>>     char aBuffer[1024];
>>>     strcpy(aBuffer, someString);
> 
> strncpy!!

strncpy() may not overflow but then it does not terminate the copied 
chars when that happens either.  The whole null-termination approach is 
a crock (much as I use it).
0
10/3/2009 1:52:39 PM
In article <02d7462e$0$20630$c3e8da3@news.astraweb.com>, Mark Daniel <mark.daniel@wasd.vsm.com.au> writes:
>VAXman- @SendSpamHere.ORG wrote:
>> In article <ha6oek$gn9$02$1@news.t-online.com>, Michael Kraemer <M.Kraemer@gsi.de> writes:
>>> Jordi Guillaumes i Pons schrieb:
>>>
>>>> Programmers are, some times, lazy. Specially when they work under 
>>>> unrealistic schedules and not enough resources. 
>>> I don't buy that. Errors of the kind below are not
>>> due to lack of resources.
>>>
>>>> You can find a lot of 
>>>> things like this in production:
>>>>
>>>> void someFunction(char *someString) {
>>>>     char aBuffer[1024];
>>>>     strcpy(aBuffer, someString);
>> 
>> strncpy!!
>
>strncpy() may not overflow but then it does not terminate the copied 
>chars when that happens either.  The whole null-termination approach is 
>a crock (much as I use it).

Yup.  Stupid.  

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

  http://www.quirkfactory.com/popart/asskey/eqn2.png
  
  "Well my son, life is like a beanstalk, isn't it?"
0
VAXman
10/3/2009 3:27:38 PM
On 2009-10-03, Mark Daniel <mark.daniel@wasd.vsm.com.au> wrote:
>
> strncpy() may not overflow but then it does not terminate the copied 
> chars when that happens either.  The whole null-termination approach is 
> a crock (much as I use it).

I've made it a point to _always_ place a null in the past position of a
buffer after a call to strncpy() for exactly that reason.

IMHO, whoever specified the strncpy semantics deserves to be shamed.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world
0
clubley (1478)
10/3/2009 4:53:07 PM
On 2009-10-03, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2009-10-03, Mark Daniel <mark.daniel@wasd.vsm.com.au> wrote:
>>
>> strncpy() may not overflow but then it does not terminate the copied 
>> chars when that happens either.  The whole null-termination approach is 
>> a crock (much as I use it).
>
> I've made it a point to _always_ place a null in the past position of a

Typo: s/past/last/

Writing "past" a buffer I will leave to the virus writers... :-)

> buffer after a call to strncpy() for exactly that reason.
>
> IMHO, whoever specified the strncpy semantics deserves to be shamed.
>

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world
0
clubley (1478)
10/3/2009 5:03:47 PM
Simon Clubley wrote:
> On 2009-10-03, Mark Daniel <mark.daniel@wasd.vsm.com.au> wrote:
>> strncpy() may not overflow but then it does not terminate the copied 
>> chars when that happens either.  The whole null-termination approach is 
>> a crock (much as I use it).
> 
> I've made it a point to _always_ place a null in the past position of a
> buffer after a call to strncpy() for exactly that reason.
> 
> IMHO, whoever specified the strncpy semantics deserves to be shamed.
> 

Well, perhaps.  But who said you had to use strncpy?  Or C?  You can 
certainly write your own string copy routine and try to do it better.

It is a poor craftsman who blames his tools!
0
rgilbert88 (4439)
10/3/2009 8:28:04 PM
In article <aWlo0bAMpgI7@eisner.encompasserve.org>,
	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <7ij0ueF30a3ujU4@mid.individual.net>, Bob Eager <rde42@spamcop.net> writes:
>> 
>> I think that's inevitable when the major language in use is C. That's a 
>> design issue; I was thinking more of how well the code was (not) written.
> 
>    Which makes you wonder why the inventors of C settled on such a design 
>    in a day when CPUs were so much slower.  If I had a system slower
>    than a PDP-11/70, I'd have wanted it to spend it's time doing better
>    things.

And, it is once again necessary to point out that Unix didn't invent
the "null terminated string".  All the other PDP-11 OSes had them and
I would be willing to bet so did all the other DEC OSes that preceded
the PDP-11.

Can anyone here confirm the existence of the .ASCIZ directive in any
of the TOPS Assemblers?  (And, yes, the .PRINT programmed request
assumed a null terminated .ASCIZ string.)

bill
 

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
10/4/2009 11:03:25 AM
On Sun, 04 Oct 2009 11:03:25 +0000, Bill Gunshannon wrote:

> In article <aWlo0bAMpgI7@eisner.encompasserve.org>,
> 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>> In article <7ij0ueF30a3ujU4@mid.individual.net>, Bob Eager
>> <rde42@spamcop.net> writes:
>>> 
>>> I think that's inevitable when the major language in use is C. That's
>>> a design issue; I was thinking more of how well the code was (not)
>>> written.
>> 
>>    Which makes you wonder why the inventors of C settled on such a
>>    design in a day when CPUs were so much slower.  If I had a system
>>    slower than a PDP-11/70, I'd have wanted it to spend it's time doing
>>    better things.
> 
> And, it is once again necessary to point out that Unix didn't invent the
> "null terminated string".  All the other PDP-11 OSes had them and I
> would be willing to bet so did all the other DEC OSes that preceded the
> PDP-11.
> 
> Can anyone here confirm the existence of the .ASCIZ directive in any of
> the TOPS Assemblers?  (And, yes, the .PRINT programmed request assumed a
> null terminated .ASCIZ string.)

It's in the PAL assembler for the PDP-8 (it's not called ASCIZ; I think 
it's TEXT).

Just checked my DEcSystem-10 assembky language handbook, dated 1973, and 
it's in Macro-10 too.




-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
10/4/2009 11:07:14 AM
In article <ha2o1t$jr4$2@naig.caltech.edu>,
	glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Bob Eager <rde42@spamcop.net> wrote:
> < On Thu, 01 Oct 2009 09:07:02 -0500, Bob Koehler wrote:
> <> In article <7ij0ueF30a3ujU4@mid.individual.net>, Bob Eager
> <> <rde42@spamcop.net> writes:
>  
> <>    Which makes you wonder why the inventors of C settled on such a
> <>    design in a day when CPUs were so much slower.  If I had a system
> <>    slower than a PDP-11/70, I'd have wanted it to spend it's time doing
> <>    better things.
>  
> < I never saw that that, in particular, caused any kind of performance 
> < problem. The libraries that used it were few - it's not often that you 
> < need to know the length of a string; more often you need to know when 
> < you've reached the end, and that is equally well served by a count or a 
> < terminator.
> 
> I have.  I have seen strcat() called inside a loop for building
> up a string while reading it in one line at a time.  The resulting
> algorithm is O(n**2).  (O(pow(n,2)) for C programmers.)  It was
> fast enough in testing, but in production the strings were millions
> of characters long and most of the time was spent in that loop.
>  
> < However, they didn't want a real limit on the lengths of strings. If 
> < they'd used a length prefix (as the predecessor to C did) they'd have had 
> < to make it two bytes, minimum. That would have used an extra byte per 
> < string, a waste of an even more valuable resource.
> 
> One result of null termination is the easy buffer overflow of
> many programs today that don't properly check lengths.  

And once again we blame the language for the incompetence (or just plain
laziness) of the programmers.

>                                                        Length
> at the beginning doesn't work so well if you want pointers to
> other than the beginning of a string.  The other way is with
> a structure containing a length and pointer, pretty much what
> Java does with String.

And one of the first languages that I used that had this "length byte"
concept was UCSD-Pascal.  Which, from the very start, included a way
to violate those bounds.  Go figure....

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
10/4/2009 11:08:21 AM
In article <7imi9jF31nq9iU6@mid.individual.net>,
	Bob Eager <rde42@spamcop.net> writes:
> On Fri, 02 Oct 2009 15:18:30 +0200, Jordi Guillaumes i Pons wrote:
> 
>> En/na Michael Kraemer ha escrit:
>>> 
>>> The str*() functions exist for convenience. If one has problems of that
>>> kind, I'd indeed store data in a dedicated struct (ptr,len).
>>>> One result of null termination is the easy buffer overflow of many
>>>> programs today
>>> 
>> Programmers are, some times, lazy. Specially when they work under
>> unrealistic schedules and not enough resources. You can find a lot of
>> things like this in production:
>> 
>> void someFunction(char *someString) {
>> 	char aBuffer[1024];
>> 
>> 	.
>> 	.
>> 	.
>> 	strcpy(aBuffer, someString);
>> 	doSomething(aBuffer);
>> 	.
>> 	.
>> 	.
>> }
>> 
>> The problem is that in C you don't have tools (AFAIK)
> 
> Google "Purify memory checker"

Or you can go back to the PDP-11 in the early 70's (and other systems,
I seem to recall but the PDP was where my experience was) and a product
called Safe-C.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
10/4/2009 11:13:27 AM
In article <00A926E7.D6B1FDD9@sendspamhere.org>,
	VAXman-  @SendSpamHere.ORG writes:
> In article <4895ah.i6n.ln@gw1>, Jordi Guillaumes i Pons <send.me@no.spam> writes:
>>En/na Bob Eager ha escrit:
>>>>interesting, since in architectures like x86 that can overwrite the
>>>>stack frame
>>> 
>>> 
>>> As you can in the VAX...
>>
>>Specially if you program in C and "think" in C. If you follow the rules 
>>(VAX Calling and Conditio Handling IIRC) you should use descriptors to 
>>pass strings. And your routine _should_ check if the lenght of the 
>>string passed as parameter fits in your buffer.
>>
>>C is a good language for systems programming. I've always thought of it 
>>as an assembly language on steroids. For a systems programmer pointers 
>>are part of his daily life. But those things have no place in a payroll 
>>program. And, for the sake of the security, neither in a web server.
> 
> Macro is an assembly language on steroids.  Bliss is an assembly language
> on steroids.  C needs Altoids, not steroids, because it stinks.  It doesn't
> even have a decent macro capability.

Because C came from the Unix environment and putting the Macro
Pre-preocessor in the compiler would have violated the paradigm
Unix was based on.  Thus, "cpp" and, of course, M4 as separate
programs.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
10/4/2009 11:17:17 AM
On Sun, 04 Oct 2009 11:17:17 +0000, Bill Gunshannon wrote:

>> Macro is an assembly language on steroids.  Bliss is an assembly
>> language on steroids.  C needs Altoids, not steroids, because it
>> stinks.  It doesn't even have a decent macro capability.
> 
> Because C came from the Unix environment and putting the Macro
> Pre-preocessor in the compiler would have violated the paradigm Unix was
> based on.  Thus, "cpp" and, of course, M4 as separate programs.

It was also necessary for space reasons. The amount of address space 
available on a PDP-11 with non-separate I/D space was only 64K. Of that, 
8K (one page register) was set aside (AFAIR) for system communication, 
leaving 56K for programs.

c0 (the preprocessor) handled macros and includes. c1 was the compiler, 
which generated dreadful code as there was no space for the code 
generator to do optimisation. c2 was the optimiser, which did a lot of 
clever stuff. I think c1 was the limiting factor, needing pretty well all 
the available address space for program, and data structures.

Just took a look - c1 was 15K, c1 was 21K, and c2 was 8K (approx). That's 
just code and static data. c1 would need a lot of dynamically allocated 
storage for symbol tables, parse trees, etc.

-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
10/4/2009 12:24:08 PM
On Sun, 04 Oct 2009 12:24:08 +0000, Bob Eager wrote:

>> Because C came from the Unix environment and putting the Macro
>> Pre-preocessor in the compiler would have violated the paradigm Unix
>> was based on.  Thus, "cpp" and, of course, M4 as separate programs.

An unrelated comment: m4 must be the worst macro processor I have ever 
seen. I might be a bit biased; I've used the same one since 1971! It's 
been ported to everytung; I did the VMS version sometime in the 1980s.

  http://www.ml1.org.uk




-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
10/4/2009 12:28:24 PM
In article <ha4jeg$792$1@gemini.csx.cam.ac.uk>,
 rf10@cl.cam.ac.uk (Robin Fairbairns) wrote:

> we bought (rather grotty) compatibles, and worked with them for a long
> time.  their arrival stopped my porting effort (it was going slowly
> anyway, due to workload).
> 
> however, we were a dec oem, and eventually dec made us an offer we
> couldn't refuse, for vt100s.  i never liked vt100s much but they were
> an awful lot better than the previous compatibles.

When EDIT/TPU came out I couldn't use it because we were stuck with VT52 
compatibles! I really hated those things, and ended up buying a couple 
of VT220s myself.

-- 
Paul Sture
0
paul.nospam (2164)
10/4/2009 12:39:11 PM
In article <aWlo0bAMpgI7@eisner.encompasserve.org>,
 koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote:

> In article <7ij0ueF30a3ujU4@mid.individual.net>, Bob Eager 
> <rde42@spamcop.net> writes:
> > 
> > I think that's inevitable when the major language in use is C. That's a 
> > design issue; I was thinking more of how well the code was (not) written.
> 
>    Which makes you wonder why the inventors of C settled on such a design 
>    in a day when CPUs were so much slower.  If I had a system slower
>    than a PDP-11/70, I'd have wanted it to spend it's time doing better
>    things.

We came across that with PDP COBOL and early versions of VAX-COBOL, 
which didn't support global variables (it was an ANSII thing IIRC - 
lowest common denominator).  It wasn't too bad copying data areas to and 
from global sections on a VAX via MOVC3 (?) but it wasn't too clever on 
PDPs.  We heaved a sigh of relief when we managed to drop PDP support 
for those libraries.

-- 
Paul Sture
0
paul.nospam (2164)
10/4/2009 12:48:05 PM
Bob Eager <rde42@spamcop.net> wrote:
(snip)
 
<> Because C came from the Unix environment and putting the Macro
<> Pre-preocessor in the compiler would have violated the paradigm Unix was
<> based on.  Thus, "cpp" and, of course, M4 as separate programs.
 
< It was also necessary for space reasons. The amount of address space 
< available on a PDP-11 with non-separate I/D space was only 64K. Of that, 
< 8K (one page register) was set aside (AFAIR) for system communication, 
< leaving 56K for programs.

The OS/360 PL/I (F) compiler was also designed to run on a 64K system.
(20K for OS/360 PCP, 44K for the compiler.)  It also used a separate
pass for the preprocessor, it requested.
 
< c0 (the preprocessor) handled macros and includes. c1 was the compiler, 
< which generated dreadful code as there was no space for the code 
< generator to do optimisation. c2 was the optimiser, which did a lot of 
< clever stuff. I think c1 was the limiting factor, needing pretty well all 
< the available address space for program, and data structures.
 
< Just took a look - c1 was 15K, c1 was 21K, and c2 was 8K (approx). That's 
< just code and static data. c1 would need a lot of dynamically allocated 
< storage for symbol tables, parse trees, etc.

PL/I (F) will keep the symbol table on disk if necessary.  At the
end of each compilation it indicates the available memory requried
to keep the symbol table off disk.

-- glen
 
0
gah (12851)
10/4/2009 12:55:07 PM
Bill Gunshannon <billg999@cs.uofs.edu> wrote:
(snip, I wrote)
 
<> One result of null termination is the easy buffer overflow of
<> many programs today that don't properly check lengths.  
 
< And once again we blame the language for the incompetence (or just plain
< laziness) of the programmers.

Well, the C gets() function, I believe still part of the standard,
has no way to know the length of the buffer.  The only answer is
not to use it, but it does seem fair to blame the language in that
case.  Otherwise, yes, it is up to programmers to check at the
appropriate points.
 
<> Length
<> at the beginning doesn't work so well if you want pointers to
<> other than the beginning of a string.  The other way is with
<> a structure containing a length and pointer, pretty much what
<> Java does with String.
 
< And one of the first languages that I used that had this "length byte"
< concept was UCSD-Pascal.  Which, from the very start, included a way
< to violate those bounds.  Go figure....

PL/I also usually uses length at the beginning.  

-- glen
0
gah (12851)
10/4/2009 12:59:57 PM
Bill Gunshannon <billg999@cs.uofs.edu> wrote:
(snip)
 
> And, it is once again necessary to point out that Unix didn't invent
> the "null terminated string".  All the other PDP-11 OSes had them and
> I would be willing to bet so did all the other DEC OSes that preceded
> the PDP-11.
 
> Can anyone here confirm the existence of the .ASCIZ directive in any
> of the TOPS Assemblers?  (And, yes, the .PRINT programmed request
> assumed a null terminated .ASCIZ string.)

I remember it from MACRO-10.  (The PDP-10 was the first DEC system
I programmed on, after some years on IBM systems.)

-- glen
0
gah (12851)
10/4/2009 1:02:20 PM
In article <02d7462e$0$20630$c3e8da3@news.astraweb.com>,
 Mark Daniel <mark.daniel@wasd.vsm.com.au> wrote:

> The whole null-termination approach is  a crock (much as I use it).

It was what made me gag (as in involuntary screams of NO!) most when 
reading the K&R book.  I was having quite enough problems with nulls in 
places they weren't supposed to be in COBOL programs at the time (mainly 
down to records not being initialized properly).  The last thing I 
wanted was a compiler that actually inserted and depended on the things.

-- 
Paul Sture
0
paul.nospam (2164)
10/4/2009 1:08:24 PM
In article <7irif8F31nq9iU12@mid.individual.net>, Bob Eager <rde42@spamcop.net> writes:
>On Sun, 04 Oct 2009 11:17:17 +0000, Bill Gunshannon wrote:
>
>>> Macro is an assembly language on steroids.  Bliss is an assembly
>>> language on steroids.  C needs Altoids, not steroids, because it
>>> stinks.  It doesn't even have a decent macro capability.
>> 
>> Because C came from the Unix environment and putting the Macro
>> Pre-preocessor in the compiler would have violated the paradigm Unix was
>> based on.  Thus, "cpp" and, of course, M4 as separate programs.
>
>It was also necessary for space reasons. The amount of address space 
>available on a PDP-11 with non-separate I/D space was only 64K. Of that, 
>8K (one page register) was set aside (AFAIR) for system communication, 
>leaving 56K for programs.
>
>c0 (the preprocessor) handled macros and includes. c1 was the compiler, 
>which generated dreadful code as there was no space for the code 
>generator to do optimisation. c2 was the optimiser, which did a lot of 
>clever stuff. I think c1 was the limiting factor, needing pretty well all 
>the available address space for program, and data structures.
>
>Just took a look - c1 was 15K, c1 was 21K, and c2 was 8K (approx). That's 
>just code and static data. c1 would need a lot of dynamically allocated 
>storage for symbol tables, parse trees, etc.

If you haven't taken notice, C isn't being used these days for PDP-11
programming.


-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

  http://www.quirkfactory.com/popart/asskey/eqn2.png
  
  "Well my son, life is like a beanstalk, isn't it?"
0
VAXman
10/4/2009 1:36:36 PM
On Sun, 04 Oct 2009 12:55:07 +0000, glen herrmannsfeldt wrote:

> < c0 (the preprocessor) handled macros and includes. c1 was the
> compiler, < which generated dreadful code as there was no space for the
> code < generator to do optimisation. c2 was the optimiser, which did a
> lot of < clever stuff. I think c1 was the limiting factor, needing
> pretty well all < the available address space for program, and data
> structures.
>  
> < Just took a look - c1 was 15K, c1 was 21K, and c2 was 8K (approx).
> That's < just code and static data. c1 would need a lot of dynamically
> allocated < storage for symbol tables, parse trees, etc.
> 
> PL/I (F) will keep the symbol table on disk if necessary.  At the end of
> each compilation it indicates the available memory requried to keep the
> symbol table off disk.

I guess the lack of disk space would have been an issue. The version of 
UNIX I'm talking about ran off a 2.4MB RK05 disk (in practice, two of 
them). But there wasn't that much space left (a chunk was swap area, not 
to mention all the commands, etc.)



-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
10/4/2009 1:51:00 PM
On Sun, 04 Oct 2009 13:36:36 +0000, VAXman- wrote:

>>Just took a look - c1 was 15K, c1 was 21K, and c2 was 8K (approx).
>>That's just code and static data. c1 would need a lot of dynamically
>>allocated storage for symbol tables, parse trees, etc.
> 
> If you haven't taken notice, C isn't being used these days for PDP-11
> programming.

Never said it was! I was looking at the 1976 version of UNIX, which I 
have here. Just explaining the main reason the preprocessor was separate.



-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
10/4/2009 1:53:12 PM
On Sun, 04 Oct 2009 15:08:24 +0200, P. Sture wrote:

> In article <02d7462e$0$20630$c3e8da3@news.astraweb.com>,
>  Mark Daniel <mark.daniel@wasd.vsm.com.au> wrote:
> 
>> The whole null-termination approach is  a crock (much as I use it).
> 
> It was what made me gag (as in involuntary screams of NO!) most when
> reading the K&R book.  I was having quite enough problems with nulls in
> places they weren't supposed to be in COBOL programs at the time (mainly
> down to records not being initialized properly).  The last thing I
> wanted was a compiler that actually inserted and depended on the things.

I didn't like it much either. In those days I was doing a lot of BCPL 
programming; BCPL uses a length byte followed by the string. Occasionally 
it was a pain only having one byte to express a length.

The idea of null termination grew on me, but I'd rather use descriptors. 
My next machine was pretty well entirely descriptor based anyway!



-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
10/4/2009 1:55:18 PM
In article <00A9285E.A191C0B4@sendspamhere.org>,
	VAXman-  @SendSpamHere.ORG writes:
> In article <7irif8F31nq9iU12@mid.individual.net>, Bob Eager <rde42@spamcop.net> writes:
>>On Sun, 04 Oct 2009 11:17:17 +0000, Bill Gunshannon wrote:
>>
>>>> Macro is an assembly language on steroids.  Bliss is an assembly
>>>> language on steroids.  C needs Altoids, not steroids, because it
>>>> stinks.  It doesn't even have a decent macro capability.
>>> 
>>> Because C came from the Unix environment and putting the Macro
>>> Pre-preocessor in the compiler would have violated the paradigm Unix was
>>> based on.  Thus, "cpp" and, of course, M4 as separate programs.
>>
>>It was also necessary for space reasons. The amount of address space 
>>available on a PDP-11 with non-separate I/D space was only 64K. Of that, 
>>8K (one page register) was set aside (AFAIR) for system communication, 
>>leaving 56K for programs.
>>
>>c0 (the preprocessor) handled macros and includes. c1 was the compiler, 
>>which generated dreadful code as there was no space for the code 
>>generator to do optimisation. c2 was the optimiser, which did a lot of 
>>clever stuff. I think c1 was the limiting factor, needing pretty well all 
>>the available address space for program, and data structures.
>>
>>Just took a look - c1 was 15K, c1 was 21K, and c2 was 8K (approx). That's 
>>just code and static data. c1 would need a lot of dynamically allocated 
>>storage for symbol tables, parse trees, etc.
> 
> If you haven't taken notice, C isn't being used these days for PDP-11
> programming.
 
Which, of course, doesn't change the Unix paradigm.  Although GNU is
trying very hard to break even that.  Of course, when MS puts everything,
including the kitchen sink, in a single program it is called bloatware
and when GNU does it, it is called progress. 


bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
10/4/2009 2:49:56 PM
In article <7irnm8F31nq9iU15@mid.individual.net>, Bob Eager <rde42@spamcop.net> writes:
>On Sun, 04 Oct 2009 13:36:36 +0000, VAXman- wrote:
>
>>>Just took a look - c1 was 15K, c1 was 21K, and c2 was 8K (approx).
>>>That's just code and static data. c1 would need a lot of dynamically
>>>allocated storage for symbol tables, parse trees, etc.
>> 
>> If you haven't taken notice, C isn't being used these days for PDP-11
>> programming.
>
>Never said it was! I was looking at the 1976 version of UNIX, which I 
>have here. Just explaining the main reason the preprocessor was separate.

....but the preprocessor is still lame today in comparision to what I can
to with a macro in Macro-32 or Bliss.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

  http://www.quirkfactory.com/popart/asskey/eqn2.png
  
  "Well my son, life is like a beanstalk, isn't it?"
0
VAXman
10/4/2009 3:04:44 PM
On Sun, 04 Oct 2009 15:04:44 +0000, VAXman- wrote:

> In article <7irnm8F31nq9iU15@mid.individual.net>, Bob Eager
> <rde42@spamcop.net> writes:
>>On Sun, 04 Oct 2009 13:36:36 +0000, VAXman- wrote:
>>
>>>>Just took a look - c1 was 15K, c1 was 21K, and c2 was 8K (approx).
>>>>That's just code and static data. c1 would need a lot of dynamically
>>>>allocated storage for symbol tables, parse trees, etc.
>>> 
>>> If you haven't taken notice, C isn't being used these days for PDP-11
>>> programming.
>>
>>Never said it was! I was looking at the 1976 version of UNIX, which I
>>have here. Just explaining the main reason the preprocessor was
>>separate.
> 
> ...but the preprocessor is still lame today in comparision to what I can
> to with a macro in Macro-32 or Bliss.

Agreed. But what I've always done is use a separate macro processor (not 
m4, as noted!) which makes Macro-32 look lame!



-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
10/4/2009 3:20:17 PM
In article <7irr0kF332b3gU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>In article <00A9285E.A191C0B4@sendspamhere.org>,
>	VAXman-  @SendSpamHere.ORG writes:
>> In article <7irif8F31nq9iU12@mid.individual.net>, Bob Eager <rde42@spamcop.net> writes:
>>>On Sun, 04 Oct 2009 11:17:17 +0000, Bill Gunshannon wrote:
>>>
>>>>> Macro is an assembly language on steroids.  Bliss is an assembly
>>>>> language on steroids.  C needs Altoids, not steroids, because it
>>>>> stinks.  It doesn't even have a decent macro capability.
>>>> 
>>>> Because C came from the Unix environment and putting the Macro
>>>> Pre-preocessor in the compiler would have violated the paradigm Unix was
>>>> based on.  Thus, "cpp" and, of course, M4 as separate programs.
>>>
>>>It was also necessary for space reasons. The amount of address space 
>>>available on a PDP-11 with non-separate I/D space was only 64K. Of that, 
>>>8K (one page register) was set aside (AFAIR) for system communication, 
>>>leaving 56K for programs.
>>>
>>>c0 (the preprocessor) handled macros and includes. c1 was the compiler, 
>>>which generated dreadful code as there was no space for the code 
>>>generator to do optimisation. c2 was the optimiser, which did a lot of 
>>>clever stuff. I think c1 was the limiting factor, needing pretty well all 
>>>the available address space for program, and data structures.
>>>
>>>Just took a look - c1 was 15K, c1 was 21K, and c2 was 8K (approx). That's 
>>>just code and static data. c1 would need a lot of dynamically allocated 
>>>storage for symbol tables, parse trees, etc.
>> 
>> If you haven't taken notice, C isn't being used these days for PDP-11
>> programming.
> 
>Which, of course, doesn't change the Unix paradigm.  Although GNU is
>trying very hard to break even that.  Of course, when MS puts everything,
>including the kitchen sink, in a single program it is called bloatware
>and when GNU does it, it is called progress. 

Let's take a look at this...

Here, from my Alpha, is a listing of the size of the Macro32 compiler and
Macro64 assembler -- both which possess powerful macro capabilities.

ALPHA_MACRO.EXE;1       9088
MACRO64.EXE;1           5956

Here, from my Alpha, is a listing of the size of the Bliss32 compiler and
Bliss63 compiler -- both which possess powerful macro capabilities

BLISS32EN.EXE;1         9817
BLISS64EN.EXE;1         9807

Here, from my Alpha, is a listing of the size of the DECC compiler which
has pretty sucky macro capabilities.

DECC$COMPILER.EXE;1    11218

Why can Macro and Bliss have powerful macro processors in less space than
the glorified string substitution/replacement preprocessor of C???

I have, for example, a Macro32 macro I've created called: .SSINTERCEPT

        .MACRO  .SSINTERCEPT,func,srvc,type,mode,?lbl1,?lbl2
        ;++
        ; Parameters:
        ;       func: INSTALL intercept or RESTORE system service
        ;       srvc: system service to be intercepted SYS{$srvc}
        ;       type: CHM (CHange Mode) or MOC (Mode Of Caller)
        ;             SYMVEC (on IA64 ONLY)
        ;       mode: KERNEL or EXEC (required for type CHM)
        ;
        ; Implied Parameter:
        ;       name: root system service to be intercepted SYS${name}
        ; ...
        ;--

and it is invoked as:

        .SSINTERCEPT  INSTALL,$chm_mumble,CHM,KERNEL
        .SSINTERCEPT  INSTALL,$moc_mumble,MOC

Try to do something complex like the above in a C macro.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

  http://www.quirkfactory.com/popart/asskey/eqn2.png
  
  "Well my son, life is like a beanstalk, isn't it?"
0
VAXman
10/4/2009 3:23:10 PM
On 2009-10-03, Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>
> Well, perhaps.  But who said you had to use strncpy?  Or C?  You can 
> certainly write your own string copy routine and try to do it better.
>
> It is a poor craftsman who blames his tools!

However, it's a good craftsman who knows the limitations and dangers of
the tools he has to work with and who implements procedures to make sure
he's not caught out by them. :-)

BTW, sometimes C is the most appropriate tool for the job, even when you
might personally wish you could use another language.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world
0
clubley (1478)
10/4/2009 4:47:02 PM
On 2009-10-04, P. Sture <paul.nospam@sture.ch> wrote:
> When EDIT/TPU came out I couldn't use it because we were stuck with VT52 
> compatibles! I really hated those things, and ended up buying a couple 
> of VT220s myself.

The VT52 is my second favorite terminal, surpassed only by the 
Heathkit H19/Zenith Z19. Unfortunately, I don't have any left. 
*whistful sigh*
-- 
roger ivie
rivie@ridgenet.net
0
rivie (670)
10/4/2009 5:16:45 PM
Simon Clubley wrote:
> On 2009-10-03, Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>> Well, perhaps.  But who said you had to use strncpy?  Or C?  You can 
>> certainly write your own string copy routine and try to do it better.
>>
>> It is a poor craftsman who blames his tools!
> 
> However, it's a good craftsman who knows the limitations and dangers of
> the tools he has to work with and who implements procedures to make sure
> he's not caught out by them. :-)
> 
> BTW, sometimes C is the most appropriate tool for the job, even when you
> might personally wish you could use another language.
> 
> Simon.
> 

And given the cost of licenses, you sometimes must make do with the 
tools you have.
0
rgilbert88 (4439)
10/4/2009 5:35:24 PM
En/na glen herrmannsfeldt ha escrit:

>  
> < And one of the first languages that I used that had this "length byte"
> < concept was UCSD-Pascal.  Which, from the very start, included a way
> < to violate those bounds.  Go figure....
> 
> PL/I also usually uses length at the beginning.  
> 

Yup! Only for VARYING CHAR variables. On the other hand, it uses 
descriptors to pass string parameters so the called procedure knows the 
length of the incoming string, being it fixed-length or varying.

Of course, when you declare a VAR CHAR(1024) the compiler allocates 1026 
(or 1028 in the last versions) bytes, unless you declare a BASED or 
CONTROLLED variable. It's unvaluable processing varying length records:

DCL BUFFER_AREA		CHAR(1024) VARYING;
DCL 01 RECORD_TYPE_1	BASED(ADDR(BUFFER_AREA)),
        03 LENGTH        BINARY FIXED(15),
        03 DATA,
  	  05 RECORDTYPE CHAR(2),
           05...

DCL 01 RECORD_TYPE_2	BASED(ADDR(BUFFER_AREA)),
        03 LENGTH        BINARY FIXED(15),
        03 DATA,
  	  05 RECORDTYPE CHAR(2),
           05...

The more recent versions support C-isms like UNION, so the need to do 
such idioms (when you have to debug a program where one structure is 
based on the address of the last byte of another structure, which is 
based on a record, which is based on a POINTER, using a DUMP, you start 
to wonder what in #��$@ was thinking the programmer about... ;)).

Oh, by the way, I'm talking about zOS PLI compilers. I've not followed 
the current status of the Kednos version vs. the last IBM PLI extensions.

(After my golden VAX days, I spent nearly 12 years coding & designing 
applications for MVS-OS/390-z/OS, in PLI and against IMS/DB/DC...).

0
send.me (12)
10/4/2009 7:59:46 PM
glen herrmannsfeldt wrote:

> Well, the C gets() function, I believe still part of the standard,
> has no way to know the length of the buffer.  


Put yourself back into the 1960s context. It was pretty hard to provide
records longer than 80 bytes when imput methods were: PUNCHED CARDS and
80 character wide terminals.

Back then, having 81 byte buffers pretty much ensures you wouldn't have
buffer overflows.

And consider the VMS environment which, like MVS, likes structured
files. This is quite different from modern environments, especially
those handling web forms with variable length, multiline text entry
fields where you can enter 80k of text, not just 80 characters.
0
10/4/2009 8:51:08 PM
En/na Jordi Guillaumes i Pons ha escrit:
> En/na glen herrmannsfeldt ha escrit:
> 
>>  
>> < And one of the first languages that I used that had this "length byte"
>> < concept was UCSD-Pascal.  Which, from the very start, included a way
>> < to violate those bounds.  Go figure....
>>
aluable processing varying length records:
> 
> DCL BUFFER_AREA        CHAR(1024) VARYING;
> DCL 01 RECORD_TYPE_1    BASED(ADDR(BUFFER_AREA)),
>        03 LENGTH        BINARY FIXED(15),
>        03 DATA,
>        05 RECORDTYPE CHAR(2),
>           05...

Ehem... obviously wrong indentation. The '05's should be at the same 
column... ;)
0
send.me (12)
10/4/2009 8:59:22 PM
JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
< glen herrmannsfeldt wrote:
 
<> Well, the C gets() function, I believe still part of the standard,
<> has no way to know the length of the buffer.  
 
< Put yourself back into the 1960s context. It was pretty hard to provide
< records longer than 80 bytes when imput methods were: PUNCHED CARDS and
< 80 character wide terminals.

Cards yes, but on most terminals you can keep typing without a newline
while it wraps back to column 1 (or stays at 80).

And on disk you could have up to 7294 bytes per record.
 
< Back then, having 81 byte buffers pretty much ensures you 
< wouldn't have buffer overflows.
 
< And consider the VMS environment which, like MVS, likes structured
< files. This is quite different from modern environments, especially
< those handling web forms with variable length, multiline text entry
< fields where you can enter 80k of text, not just 80 characters.

-- glen
0
gah (12851)
10/4/2009 9:44:35 PM
 "R.A.Omond" <Roy.Omond@BlueBubble.UK.Com> writes:
>Robin Fairbairns wrote:
>
>>  [...snip...]
>> 
>> when we first got our vax, i started a porting exercise for a rather
>> more rational line-based editor by an old colleague at the university.
>
>Robin, that wouldn't have been ZED by Phil Hazel by any chance ?  One of
>my all-time favourite line-mode editors (I'm also an old Phoenix user
>from the mid-1970s ;-)

got it in one.  (though admittedly i used phoenix rather little, i
knew it was a good 'un, and i already had experience of phil's code
from titan days.)

>> we bought (rather grotty) compatibles, and worked with them for a long
>> time.  their arrival stopped my porting effort (it was going slowly
>> anyway, due to workload).
>
>Worth resurrecting the porting effort ?

i dunno.  i don't have the stuff phil sent me, any more, and i doubt
phil has either (he stopped working on ibm software way before the
last ibm machine disappeared, some time in the early 90s).

probably a lost cause.
-- 
Robin Fairbairns, Cambridge
0
rf10 (3613)
10/4/2009 10:34:59 PM
Jordi Guillaumes i Pons schrieb:

> Specially if you program in C and "think" in C. If you follow the rules 
> (VAX Calling and Conditio Handling IIRC) you should use descriptors to 
> pass strings. 

and what if I want to keep my programs portable ?

> And your routine _should_ check if the lenght of the 
> string passed as parameter fits in your buffer.

and what if it doesn't fit?
Abort the program?

> C is a good language for systems programming. I've always thought of it 
> as an assembly language on steroids. For a systems programmer pointers 
> are part of his daily life. But those things have no place in a payroll 
> program. And, for the sake of the security, neither in a web server.

Blech. You can use it for just everything, in particular
if you want portability.
If programmers can't cope with pointers, they probably
picked up the wrong career.
And, BTW, if you think C is an "unsecure" language,
why would it be a better choice for an OS than an app?
An OS has to be more secure than the apps running on top.

> 
> Oh, by the way, I don't have if this has REALLY happened. Do you nou 
> about any succesful attack against a VAX running VMS using a 
> buffer/stack overflow?

Do you know about a successful attack against a C64?

0
M.Kraemer (2048)
10/5/2009 1:12:06 AM
Bob Koehler schrieb:

> 
>    This is a common problem with C library routines such as strcat.
> 

No, it's a common problem of programming which predates C:
if you write to a buffer, make sure that:
a) you own it,
b) it's always large enough.

strcat() simply assumes that you have calloc'ed the target
buffer large enough before you use it.
Which is easy because one can query the string lengths before.
It's not so easy with fgets() because one can't guess
what's coming down the line.
Likewise with sprintf(), one doesn't know how much space
the formatted stuff would need.
snprintf() is sort of a security patch for that problem,
but not a real solution.
So these two functions are about the only "dangereous" ones
I can remember because you can't really use them safely in their
usual context.

0
M.Kraemer (2048)
10/5/2009 1:28:20 AM
glen herrmannsfeldt schrieb:
> 
> Well, the C gets() function, I believe still part of the standard,
> has no way to know the length of the buffer.  The only answer is
> not to use it, but it does seem fair to blame the language in that
> case. 

To be nitpicking: it's not part of the language,
neither are all other functions.
But I agree, at least the doc's should deprecate its use.

> Otherwise, yes, it is up to programmers to check at the
> appropriate points.
>  

0
M.Kraemer (2048)
10/5/2009 1:35:12 AM
Bill Gunshannon schrieb:

>  
> Which, of course, doesn't change the Unix paradigm.  Although GNU is
> trying very hard to break even that.  Of course, when MS puts everything,
> including the kitchen sink, in a single program it is called bloatware
> and when GNU does it, it is called progress. 

I have no problem calling Gnu "bloatware".

0
M.Kraemer (2048)
10/5/2009 1:38:23 AM
Michael Kraemer wrote:

> Do you know about a successful attack against a C64?

Yes.

You can jam the cassette recorder by pouring strawberry jam on it. This
is an effective denial of service attack since the onwer will no longer
be able to load programs from his casettes.

:-)
0
10/5/2009 1:39:12 AM
Jordi Guillaumes i Pons schrieb:
> En/na glen herrmannsfeldt ha escrit:
> 
>>  
>> < And one of the first languages that I used that had this "length byte"
>> < concept was UCSD-Pascal.  Which, from the very start, included a way
>> < to violate those bounds.  Go figure....
>>
>> PL/I also usually uses length at the beginning. 
> 
> 
> Yup! Only for VARYING CHAR variables. On the other hand, it uses 
> descriptors to pass string parameters so the called procedure knows the 
> length of the incoming string, being it fixed-length or varying.

So does C, thanks to null termination of read-only strings.
As for target strings, PL/I isn't any better, IMHO,
unless the standard has changed in the past 15 years.
They have a maximum length, if you exceed it on write, you'll
have a buffer overflow as well. Unless you have enabled
STRINGSIZE, of course, but this is rarely the case in
production code. And even if it is, what do you gain?
A production program which aborts due to STRINGSIZE raised.

A solution superior to C would be if PL/I allowed stuff like

DCL AA,BB,CC CHAR(*) VAR;
CC = AA || BB;

with automatic (re)allocation of CC with just the right length,
thanks to the descriptor concept.
Wasn't possible at the time I had to leave PL/I.

> 
> The more recent versions support C-isms like UNION, so the need to do 
> such idioms (when you have to debug a program where one structure is 
> based on the address of the last byte of another structure, which is 
> based on a record, which is based on a POINTER, using a DUMP, you start 
> to wonder what in #��$@ was thinking the programmer about... ;)).

You don't need unions to mess up your programs.
The PL/I concept of BASED variables does that as well.
You can trash just everything, including your oh-so-secure descriptors.
I remember using this "trick" deliberately to modify the dimension
layout of array.
Add to that that PL/I passes arguments by reference (not by
value, as does C), and you have another possibility of
trashing data.

0
M.Kraemer (2048)
10/5/2009 2:10:56 AM
Michael Kraemer <M.Kraemer@gsi.de> wrote:
< Bob Koehler schrieb:
 
<>    This is a common problem with C library routines such as strcat.
 
< No, it's a common problem of programming which predates C:
< if you write to a buffer, make sure that:
< a) you own it,
< b) it's always large enough.
 
< strcat() simply assumes that you have calloc'ed the target
< buffer large enough before you use it.

< Which is easy because one can query the string lengths before.

Much easier (and faster) to keep track of the string lengths
while they are being created.

< It's not so easy with fgets() because one can't guess
< what's coming down the line.

fgets() is the one with a length argument, its gets() that
doesn't have one.

< Likewise with sprintf(), one doesn't know how much space
< the formatted stuff would need.

I have wondered about using %f on machines with large exponents
like some Cray machines.  %f expands the field to the number of 
digits needed, which could be thousands on some machines.

< snprintf() is sort of a security patch for that problem,
< but not a real solution.
< So these two functions are about the only "dangereous" ones
< I can remember because you can't really use them safely in their
< usual context.

-- glen 
0
gah (12851)
10/5/2009 3:36:45 AM
Michael Kraemer <M.Kraemer@gsi.de> wrote:
< Jordi Guillaumes i Pons schrieb:
<> En/na glen herrmannsfeldt ha escrit:
  
<>> < And one of the first languages that I used that had this "length byte"
<>> < concept was UCSD-Pascal.  Which, from the very start, included a way
<>> < to violate those bounds.  Go figure....

<>> PL/I also usually uses length at the beginning. 
 
<> Yup! Only for VARYING CHAR variables. On the other hand, it uses 
<> descriptors to pass string parameters so the called procedure knows the 
<> length of the incoming string, being it fixed-length or varying.
 
< So does C, thanks to null termination of read-only strings.
< As for target strings, PL/I isn't any better, IMHO,
< unless the standard has changed in the past 15 years.
< They have a maximum length, if you exceed it on write, you'll
< have a buffer overflow as well. Unless you have enabled
< STRINGSIZE, of course, but this is rarely the case in
< production code. And even if it is, what do you gain?
< A production program which aborts due to STRINGSIZE raised.

I forget know whether STRINGSIZE defaults to enabled or not.
It is easy to enable if needed, either for the procedure or
by the statement.  It is much more difficult in C to add the
check to a program not designed for it.
 
< A solution superior to C would be if PL/I allowed stuff like
 
< DCL AA,BB,CC CHAR(*) VAR;
< CC = AA || BB;
 
< with automatic (re)allocation of CC with just the right length,
< thanks to the descriptor concept.
< Wasn't possible at the time I had to leave PL/I.

Not automatic, but still probably easier than doing the right
thing in C.  Deallocate if needed, allocate to length(aa)+length(bb),
assign.
 
<> The more recent versions support C-isms like UNION, so the need to do 
<> such idioms (when you have to debug a program where one structure is 
<> based on the address of the last byte of another structure, which is 
<> based on a record, which is based on a POINTER, using a DUMP, you start 
<> to wonder what in #??$@ was thinking the programmer about... ;)).
 
< You don't need unions to mess up your programs.
< The PL/I concept of BASED variables does that as well.
< You can trash just everything, including your oh-so-secure descriptors.
< I remember using this "trick" deliberately to modify the dimension
< layout of array.
< Add to that that PL/I passes arguments by reference (not by
< value, as does C), and you have another possibility of
< trashing data.

Well, arrays, strings, and structures are passed by descriptor.
It might be that VALUE has been added now for calls to C.

-- glen
 
0
gah (12851)
10/5/2009 3:43:48 AM
Michael Kraemer <M.Kraemer@gsi.de> wrote:
< glen herrmannsfeldt schrieb:
 
<> Well, the C gets() function, I believe still part of the standard,
<> has no way to know the length of the buffer.  The only answer is
<> not to use it, but it does seem fair to blame the language in that
<> case. 
 
< To be nitpicking: it's not part of the language,
< neither are all other functions.
< But I agree, at least the doc's should deprecate its use.

I have seen that discussed.  There are some questions in K&R as
to the library being part of the language.  Most agree that it is
for ANSI C.
 
<> Otherwise, yes, it is up to programmers to check at the
<> appropriate points.

And to always use fgets() instead of gets().

-- glen
0
gah (12851)
10/5/2009 3:45:59 AM
glen herrmannsfeldt schrieb:

> 
> Much easier (and faster) to keep track of the string lengths
> while they are being created.

I'm not advocating null termination to be the method
of choice for length measurement, just that
it is not the real culprit for buffer overflows.

> < It's not so easy with fgets() because one can't guess
> < what's coming down the line.
> 
> fgets() is the one with a length argument, its gets() that
> doesn't have one.

OK, it's getting late ...

> < Likewise with sprintf(), one doesn't know how much space
> < the formatted stuff would need.
> 
> I have wondered about using %f on machines with large exponents
> like some Cray machines.  %f expands the field to the number of 
> digits needed, which could be thousands on some machines.

For this (and similar) reasons sprintf()
is the real danger out there because it can't be easily
replaced (unlike gets() and strcat() and friends).
I'm contemplating a 2-pass workaround writing to /dev/null first,
thereby counting the number of bytes needed, then calloc'ing
the output buffer with the appropriate length, so sprintf()
would be safe. Works on Unix, but would require sort of a
null device support in the other OSs out there.


0
M.Kraemer (2048)
10/5/2009 6:37:14 AM
glen herrmannsfeldt schrieb:

> 
> I forget know whether STRINGSIZE defaults to enabled or not.

I remember "disabled" was the default.
And we all know what to think about security measures
which have to be enabled explicitly.

> It is easy to enable if needed, either for the procedure or
> by the statement.  It is much more difficult in C to add the
> check to a program not designed for it.
>  
> < A solution superior to C would be if PL/I allowed stuff like
>  
> < DCL AA,BB,CC CHAR(*) VAR;
> < CC = AA || BB;
>  
> < with automatic (re)allocation of CC with just the right length,
> < thanks to the descriptor concept.
> < Wasn't possible at the time I had to leave PL/I.
> 
> Not automatic, but still probably easier than doing the right
> thing in C.  Deallocate if needed, allocate to length(aa)+length(bb),
> assign.

As a draft (didn't check it really):

cc = calloc( strlen(aa)+strlen(bb)+1, sizeof(*cc) );
strcat(cc,aa); strcat(cc,bb);

vs

BEGIN;
DCL CC CHAR( LENGTH(aa)+LENGTH(bb) ) VAR;
CC = AA || BB;
END;

is not that much of a difference.
I doubt it would be much different with the CONTROLLED or BASED
storage classes.

> 
> Well, arrays, strings, and structures are passed by descriptor.

which means they can be trashed / modified anytime by the callee.

> It might be that VALUE has been added now for calls to C.

But it would not be the default, because that would break
compatibility with PL/I code of 40 years.

0
M.Kraemer (2048)
10/5/2009 7:02:51 AM
 Jordi Guillaumes i Pons <send.me@no.spam> writes:
>En/na VAXman- @SendSpamHere.ORG ha escrit:
>> 
>> Envision Rod Sterling walking out from the background darkness into the 
>> shadowy light, camera focused on him from his lapel and tie, and with a
>> cigarette lit and its smoke encircling his head...
>> 
>>     "Picture, if you will, a man who has just consumed too much wine 
>>      or too much LSD or who has simply fallen squarely upon his pate
>>      from an appreciable height, and is now totally delusional in the 
>>      usenet newsgroup of comp.Twilight.Zone..."
>> 
>> Where's this VAX exec bit?  
>
>Perhaps in my imagination? I don't read about VAX arch and VMS internals 
>sinde the early nineties, but I _think_ the entries in the page table 
>have a protection mask allows marking a page as readable, but 
>non-executable. I am wrong on that? Too many years, too much coffee and 
>too many arch changes in my life... :(

well, i have this "vax11 780 hardware handbook" on my shelf, so i
pulled it down and looked at it.  no mention of any execute-permission
bit in there.

remember, the later pdp 11 models had i-space and d-space, but i never
encountered anyone using them.  this was, of course, because the
pdp-ll architecture made it really rather difficult: this may have put
off the designers of the vax (for what i would consider irrational
reasons -- the vax architecture would have been far more amenable to
such a split).

of course, the design predated the morris worm, and back then there
was far less emphasis on this sort of code cleanliness.  the
industry's older and wiser now (even if some of its workers still rush
around like rabid rabbits).
-- 
Robin Fairbairns, Cambridge
0
rf10 (3613)
10/5/2009 12:06:21 PM
 Bob Eager <rde42@spamcop.net> writes:
>On Sun, 04 Oct 2009 12:24:08 +0000, Bob Eager wrote:
>
>>> Because C came from the Unix environment and putting the Macro
>>> Pre-preocessor in the compiler would have violated the paradigm Unix
>>> was based on.  Thus, "cpp" and, of course, M4 as separate programs.
>
>An unrelated comment: m4 must be the worst macro processor I have ever 
>seen. I might be a bit biased; I've used the same one since 1971! It's 
>been ported to everytung; I did the VMS version sometime in the 1980s.
>
>  http://www.ml1.org.uk

my first task in my first job for the university was to clean up and
debug the titan implementation of ml/1.  (i learned it on the pdp-7,
when i was still an undergraduate; i've only ever used it on pdp-7 and
titan.)

ml/1 is good and powerful, but it tends to descend into obscurity if
you try to be clever.  just like tex (the system for which i've
written more macros than any other, and indeed, pretty much any macro
generation scheme that allows you to be clever at all.

i'm amused that ml/1 is still available.  if i can ever get the other
side of my accumulated deadlines, i might try playing with it again.
-- 
Robin Fairbairns, Cambridge
0
rf10 (3613)
10/5/2009 12:16:14 PM
In article <habq5n$pi6$3@naig.caltech.edu>,
 glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> Michael Kraemer <M.Kraemer@gsi.de> wrote:
> < glen herrmannsfeldt schrieb:
>  
> <> Well, the C gets() function, I believe still part of the standard,
> <> has no way to know the length of the buffer.  The only answer is
> <> not to use it, but it does seem fair to blame the language in that
> <> case. 
>  
> < To be nitpicking: it's not part of the language,
> < neither are all other functions.
> < But I agree, at least the doc's should deprecate its use.
> 
> I have seen that discussed.  There are some questions in K&R as
> to the library being part of the language.  Most agree that it is
> for ANSI C.
>  
> <> Otherwise, yes, it is up to programmers to check at the
> <> appropriate points.
> 
> And to always use fgets() instead of gets().
> 

Is there a handy reference to this stuff? I mean a summary of what C 
calls to avoid and why (possibly detailing safe and unsafe 
circumstances).

-- 
Paul Sture
0
paul.nospam (2164)
10/5/2009 12:22:14 PM
In article <0041de51$0$26738$c3e8da3@news.astraweb.com>,
 JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

> Michael Kraemer wrote:
> 
> > Do you know about a successful attack against a C64?
> 
> Yes.
> 
> You can jam the cassette recorder by pouring strawberry jam on it. This
> is an effective denial of service attack since the onwer will no longer
> be able to load programs from his casettes.
> 
> :-)

The voice of experience?

:-)

-- 
Paul Sture
0
paul.nospam (2164)
10/5/2009 12:24:12 PM
 billg999@cs.uofs.edu (Bill Gunshannon) writes:
>	VAXman-  @SendSpamHere.ORG writes:
>> If you haven't taken notice, C isn't being used these days for PDP-11
>> programming.
> 
>Which, of course, doesn't change the Unix paradigm.  Although GNU is
>trying very hard to break even that.  Of course, when MS puts everything,
>including the kitchen sink, in a single program it is called bloatware
>and when GNU does it, it is called progress. 

perhaps by gnu; here it's called bloatware, just the same.
-- 
Robin Fairbairns, Cambridge
0
rf10 (3613)
10/5/2009 12:30:55 PM
In article <slrnhchm3t.dqo.rivie@stench.no.domain>,
 Roger Ivie <rivie@ridgenet.net> wrote:

> On 2009-10-04, P. Sture <paul.nospam@sture.ch> wrote:
> > When EDIT/TPU came out I couldn't use it because we were stuck with VT52 
> > compatibles! I really hated those things, and ended up buying a couple 
> > of VT220s myself.
> 
> The VT52 is my second favorite terminal, surpassed only by the 
> Heathkit H19/Zenith Z19. Unfortunately, I don't have any left. 
> *whistful sigh*

Yes, I quite liked the VT52 originals; the ones I hated were 3rd party 
compatibles which were being actively sold long after every one else was 
using VT100s and compatibles (Tandberg and C-ITOH were a couple of well 
done ones).

The only problem I recall with VT52s was something which failed on a 
regular basis (PSU ?).  The official time for that repair was over an 
hour, or so our terminal & printer engineer told us. Poor lad, he hated 
the job.  For us it represented real downtime.

-- 
Paul Sture
0
paul.nospam (2164)
10/5/2009 12:37:35 PM
P. Sture wrote:
> In article <habq5n$pi6$3@naig.caltech.edu>,
>  glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> 
>> Michael Kraemer <M.Kraemer@gsi.de> wrote:
>> < glen herrmannsfeldt schrieb:
>>  
>> <> Well, the C gets() function, I believe still part of the standard,
>> <> has no way to know the length of the buffer.  The only answer is
>> <> not to use it, but it does seem fair to blame the language in that
>> <> case. 
>>  
>> < To be nitpicking: it's not part of the language,
>> < neither are all other functions.
>> < But I agree, at least the doc's should deprecate its use.
>>
>> I have seen that discussed.  There are some questions in K&R as
>> to the library being part of the language.  Most agree that it is
>> for ANSI C.
>>  
>> <> Otherwise, yes, it is up to programmers to check at the
>> <> appropriate points.
>>
>> And to always use fgets() instead of gets().
>>
> 
> Is there a handy reference to this stuff? I mean a summary of what C 
> calls to avoid and why (possibly detailing safe and unsafe 
> circumstances).
> 

I've never seen or heard of one.  It's not necessary to "avoid" certain 
calls.  It IS necessary to understand exactly what you are doing.  C is 
really just a "portable" assembler.  You have to keep in mind that a 
slip on your part might crash your process or even your system.

C hands you both near total control AND near total responsibility!  Use 
it with care.  Consider whether or not C is the appropriate language for 
what you are trying to do.
0
rgilbert88 (4439)
10/5/2009 1:06:14 PM
glen herrmannsfeldt wrote:
> Bill Gunshannon <billg999@cs.uofs.edu> wrote:
> (snip, I wrote)
>  
> <> One result of null termination is the easy buffer overflow of
> <> many programs today that don't properly check lengths.  
>  
> < And once again we blame the language for the incompetence (or just plain
> < laziness) of the programmers.
> 
> Well, the C gets() function, I believe still part of the standard,
> has no way to know the length of the buffer.  The only answer is
> not to use it, but it does seem fair to blame the language in that
> case.  Otherwise, yes, it is up to programmers to check at the
> appropriate points.
>  

Sorry, but the C library is *not* part of C. It may included as a 
convenience, but there's no reason why you shouldn't write your own, as 
in fact many people do.

For embedded and systems programming work, there is no better language, 
imnsho. Portability, enough low level access for every nook and cranny 
of the machine, while at the same time enough high level facility to 
enable serious systems development.

Could could any such language be anything other than a compromise with 
all that that implies ?...

Chris
0
ChrisQ
10/5/2009 2:19:53 PM
In article <tK6dnR3F2e9Xc1TXnZ2dnUVZ_vKdnZ2d@giganews.com>, "Richard B. Gilbert"
<rgilbert88@comcast.net> writes:
> 
> I've never seen or heard of one.  It's not necessary to "avoid" certain 
> calls.  It IS necessary to understand exactly what you are doing. 

It's always good to think before coding.

> C is 
> really just a "portable" assembler.  You have to keep in mind that a 
> slip on your part might crash your process 

That's not restricted to C.

> or even your system.

How can a simple user app crash the system?
And why would that be a particular feature of C?
 
> C hands you both near total control AND near total responsibility! 

A user app written in C has not more control than if it were written
in PL/I.

> Use 
> it with care.  Consider whether or not C is the appropriate language for 
> what you are trying to do.

If portability is the prime directive, there's not much choice left
other than C/C++. Supports Roadrunner as well as PDP-11 (I guess).
Same goes for early support of new stuff (GPUs and Cell Engines come to mind).

0
M.Kraemer (2048)
10/5/2009 2:24:02 PM
In article <ha6oek$gn9$02$1@news.t-online.com>, Michael Kraemer <M.Kraemer@gsi.de> writes:
> 
> That's not a problem of null termination,
> it's a problem of writing to an area you do not own.

   It's a problem of the called routine having no way of preventing you
   from writing to an area you do not own.  Other languages do actually
   prevent it.

> This may happen in any language, i.e.
> Assuming a fixed size of your data objects
> because it would never ever been exceeded
> (Y2K comes to mind).
> In C, one would have used sth like
> aBuffer = calloc( strlen(someString)+1, sizeof(*aBuffer) )

   In Fortran, one would pass a string (CHARACTER), and the language 
   definition requires that the called function has access to the
   allocated length of the buffer, although this is implemented
   different ways by different compilers, and the function can prevent 
   the buffer from being overwritten.

> 
> and it would be switched off for production release,
> where most of the buffer oflos would surface.

   But functions in other languages can, and routinely do, block that
   from happening using features that are not compile time selectable,
   but instead are guarranteed by the language standard.
 
> That would be a compiler issue, not a language issue.

   The C compiler is not required to pass the length by any part of the
   C language standard, and I've never seen one that does, with the
   possible exception of one that didn't sell.

> 
> That would be an architecture issue, not a language issue.

   It is a language issue.  The C language standard could require the
   allocated length to be passed, but it doesn't.
 
0
koehler2 (8314)
10/5/2009 2:25:25 PM
P. Sture wrote:

> 
> Is there a handy reference to this stuff? I mean a summary of what C 
> calls to avoid and why (possibly detailing safe and unsafe 
> circumstances).
> 

I don't know about that point, but arguably the best book on the 
intricacies of C and it's standard library must be:

C, A Reference Manual by Harbison & Steele.

isbn: 0-13-326224-3 (paperback)

I have a very well thumbed 4th edition (1995) on my desk and my younger 
son has a castoff earlier version.

Every C programmer needs a copy of this book, if no other...

Chris
0
ChrisQ
10/5/2009 2:30:50 PM
In article <7irdntF32vm9nU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
> 
> And, it is once again necessary to point out that Unix didn't invent
> the "null terminated string".

   I didn't see anyone claim it did.  I also didn't see anyone claim C
   did.  I just don't see the logic in choosing it when a simple data
   structure seems to work better.  Even PASCAL seemed to choose a
   less intensive approach.

0
koehler2 (8314)
10/5/2009 2:33:10 PM
In article <7ire14F32vm9nU2@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
> 
> And once again we blame the language for the incompetence (or just plain
> laziness) of the programmers.

   That's like blaiming the carpenter who loses his hand to a circular
   saw without a blade guard.  The saw should have had the blade guard.

0
koehler2 (8314)
10/5/2009 2:34:35 PM
In article <7ireamF32vm9nU3@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
> 
> Or you can go back to the PDP-11 in the early 70's (and other systems,
> I seem to recall but the PDP was where my experience was) and a product
> called Safe-C.

   I think we've discussed Safe-C before.  IIRC it was available for
   a lot opf platforms, including VAXen running VMS.

   And it's lack of sales tells us a lot.

0
koehler2 (8314)
10/5/2009 2:35:56 PM
In article <habh56$s08$01$1@news.t-online.com>, Michael Kraemer <M.Kraemer@gsi.de> writes:
> 
> and what if it doesn't fit?
> Abort the program?
> 

   Well, that would be better than allowing a security hole.  But most
   programmers have better ideas about ahndling input errors.

0
koehler2 (8314)
10/5/2009 2:41:11 PM
In article <habigh$dpm$00$1@news.t-online.com>, Michael Kraemer <M.Kraemer@gsi.de> writes:
> 
> To be nitpicking: it's not part of the language,
> neither are all other functions.

   According to the ANSI C language standard, the ANSI C functions are
   part of the language.

0
koehler2 (8314)
10/5/2009 2:42:19 PM
In article <paul.nospam-BC3F65.14221405102009@pbook.sture.ch>, "P. Sture" <paul.nospam@sture.ch> writes:
> 
> Is there a handy reference to this stuff? I mean a summary of what C 
> calls to avoid and why (possibly detailing safe and unsafe 
> circumstances).

   It's simple.  Avoid any call that passes an output parameter by
   pointer but doesn't pass in input parameter provinding the allocated
   length.

0
koehler2 (8314)
10/5/2009 2:44:43 PM
On Oct 5, 9:25=A0am, koeh...@eisner.nospam.encompasserve.org (Bob
Koehler) wrote:
> =A0 =A0It's a problem of the called routine having no way of preventing y=
ou
> =A0 =A0from writing to an area you do not own. =A0Other languages do actu=
ally
> =A0 =A0prevent it.

property =3D theft
0
MetaEd
10/5/2009 3:04:55 PM
Richard Maher wrote:
>  Jordi Guillaumes i Pons <send.me@no.spam> writes:
>> En/na VAXman- @SendSpamHere.ORG ha escrit:
>>> Envision Rod Sterling walking out from the background darkness into the 
>>> shadowy light, camera focused on him from his lapel and tie, and with a
>>> cigarette lit and its smoke encircling his head...
>>>
>>>     "Picture, if you will, a man who has just consumed too much wine 
>>>      or too much LSD or who has simply fallen squarely upon his pate
>>>      from an appreciable height, and is now totally delusional in the 
>>>      usenet newsgroup of comp.Twilight.Zone..."
>>>
>>> Where's this VAX exec bit?  
>> Perhaps in my imagination? I don't read about VAX arch and VMS internals 
>> sinde the early nineties, but I _think_ the entries in the page table 
>> have a protection mask allows marking a page as readable, but 
>> non-executable. I am wrong on that? Too many years, too much coffee and 
>> too many arch changes in my life... :(
> 
> well, i have this "vax11 780 hardware handbook" on my shelf, so i
> pulled it down and looked at it.  no mention of any execute-permission
> bit in there.
> 
> remember, the later pdp 11 models had i-space and d-space, but i never
> encountered anyone using them.  this was, of course, because the
> pdp-ll architecture made it really rather difficult: this may have put
> off the designers of the vax (for what i would consider irrational
> reasons -- the vax architecture would have been far more amenable to
> such a split).
> 
> of course, the design predated the morris worm, and back then there
> was far less emphasis on this sort of code cleanliness.  the
> industry's older and wiser now (even if some of its workers still rush
> around like rabid rabbits).

In later versions of RSTS programs could be linked with separate I & D space.
IIRC this doubled the address space available, and decreased the need for stuff 
like co-trees

-- 
Mike R.
Home: http://alpha.mike-r.com/
QOTD: http://alpha.mike-r.com/php/qotd.php
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#before
--
0
Mike
10/5/2009 3:16:25 PM
In article <IsDt2fn6JJs9@eisner.encompasserve.org>,
	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <7ireamF32vm9nU3@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>> 
>> Or you can go back to the PDP-11 in the early 70's (and other systems,
>> I seem to recall but the PDP was where my experience was) and a product
>> called Safe-C.
> 
>    I think we've discussed Safe-C before.  IIRC it was available for
>    a lot opf platforms, including VAXen running VMS.
> 
>    And it's lack of sales tells us a lot.

Oh my god.  That's twice in one year we have agreed on something..... 
What is the world coming to?

bill
 

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
10/5/2009 3:43:15 PM
Bob Koehler wrote:

> 
>    According to the ANSI C language standard, the ANSI C functions are
>    part of the language.
>

Not to nitpick further, but while the standard library may be defined 
within the standard, but it's not part pf the syntax. Thus, the standard 
defines 2 parts, the language and it's standard library...

Chris


0
ChrisQ
10/5/2009 3:52:46 PM
Bob Koehler wrote:
> In article <7ire14F32vm9nU2@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>> And once again we blame the language for the incompetence (or just plain
>> laziness) of the programmers.
> 
>    That's like blaiming the carpenter who loses his hand to a circular
>    saw without a blade guard.  The saw should have had the blade guard.
> 

Perhaps it should, but the craftsman learns early on that blades are 
dangerous and to keep fingers etc well clear. Especially if he's lost a 
finger tip or two within that experience.

A similar comparison could be made between the all encompassing welfare 
or police states and democracy. In one case, you become completely 
subservient or institutionalised. In the other you have freedom of 
choice within commonly agreed limits :-)...

Regards,

Chris
0
ChrisQ
10/5/2009 3:59:56 PM
On Mon, 05 Oct 2009 08:37:14 +0200, Michael Kraemer wrote:

> glen herrmannsfeldt schrieb:
> 
> 
>> Much easier (and faster) to keep track of the string lengths while they
>> are being created.
> 
> I'm not advocating null termination to be the method of choice for
> length measurement, just that it is not the real culprit for buffer
> overflows.
> 
>> < It's not so easy with fgets() because one can't guess < what's coming
>> down the line.
>> 
>> fgets() is the one with a length argument, its gets() that doesn't have
>> one.
> 
> OK, it's getting late ...
> 
>> < Likewise with sprintf(), one doesn't know how much space < the
>> formatted stuff would need.
>> 
>> I have wondered about using %f on machines with large exponents like
>> some Cray machines.  %f expands the field to the number of digits
>> needed, which could be thousands on some machines.
> 
> For this (and similar) reasons sprintf() is the real danger out there
> because it can't be easily replaced (unlike gets() and strcat() and
> friends). I'm contemplating a 2-pass workaround writing to /dev/null
> first, thereby counting the number of bytes needed, then calloc'ing the
> output buffer with the appropriate length, so sprintf() would be safe.
> Works on Unix, but would require sort of a null device support in the
> other OSs out there.

But easy on VMS, of course! Sounds a good idea...



-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
10/5/2009 4:17:06 PM
On Mon, 05 Oct 2009 12:06:21 +0000, Robin Fairbairns wrote:

> remember, the later pdp 11 models had i-space and d-space, but i never
> encountered anyone using them.

Later versions of UNIX did. Version 7, anyway.

-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
10/5/2009 4:17:49 PM
On Mon, 05 Oct 2009 12:16:14 +0000, Robin Fairbairns wrote:

> Bob Eager <rde42@spamcop.net> writes:
>>On Sun, 04 Oct 2009 12:24:08 +0000, Bob Eager wrote:
>>
>>>> Because C came from the Unix environment and putting the Macro
>>>> Pre-preocessor in the compiler would have violated the paradigm Unix
>>>> was based on.  Thus, "cpp" and, of course, M4 as separate programs.
>>
>>An unrelated comment: m4 must be the worst macro processor I have ever
>>seen. I might be a bit biased; I've used the same one since 1971! It's
>>been ported to everytung; I did the VMS version sometime in the 1980s.
>>
>>  http://www.ml1.org.uk
> 
> my first task in my first job for the university was to clean up and
> debug the titan implementation of ml/1.  (i learned it on the pdp-7,
> when i was still an undergraduate; i've only ever used it on pdp-7 and
> titan.)

Good God! Probably the earliest ML/I user around; pre-dates me (1971). 
Now that Peter Brown has gone.

> ml/1 is good and powerful, but it tends to descend into obscurity if you
> try to be clever.  just like tex (the system for which i've written more
> macros than any other, and indeed, pretty much any macro generation
> scheme that allows you to be clever at all.

It was greatly improved when the closing delimiter for operation macros 
was changed from semicolon to newline. And it has simple string variables 
now.

> i'm amused that ml/1 is still available.  if i can ever get the other
> side of my accumulated deadlines, i might try playing with it again.

Yes, it must be one of the oldest programs still in use...!

-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
10/5/2009 4:20:49 PM
On Mon, 05 Oct 2009 14:24:02 +0000, Michael Kraemer wrote:

>> or even your system.
> 
> How can a simple user app crash the system? And why would that be a
> particular feature of C?

Indeed! Although we did have a design fault on an ICL mainframe which was 
triggered nearly every time by FORTRAN programs. Halted the microprogram.




-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
10/5/2009 4:23:27 PM
Bob Koehler wrote:

> 
>    It's simple.  Avoid any call that passes an output parameter by
>    pointer but doesn't pass in input parameter provinding the allocated
>    length.
> 

You can get the equivalent of call by descriptor by declaring a structure:

typedef struct {
    U8 u8Length;		/* Could be U16 or U32 */
    U8 *pu8String;
    } STRING;

Then:

U8 u8String [] = {"Some string"};

STRING sString;

sString.u8Length = strlen (&u8String [0]);
sString.pu8String = &u8String [0];

Pass into function:

vSomeFunction (&sString);

This looks a lot more wordy than it would actually do in practice. For 
the sort of work done here, the above type of construct is used a lot, 
though usually with more structure elements.

In the end, it comes down to a systems engineering and design issue, If 
you have a pair of functions that you can be sure will never exceed 
buffer limits or if the range checking has already been done elsewhere, 
then it's safe to pass the pointer alone. For some types of work, the 
overhead involved in having to range check every last argument becomes 
self defeating and points more to a bad system design in the first place...

Regards,

Chris






0
ChrisQ
10/5/2009 5:01:48 PM
On Mon, 5 Oct 2009 at 12:06 -0000, Robin Fairbairns wrote:

> remember, the later pdp 11 models had i-space and d-space, but i 
> never encountered anyone using them.  this was, of course, because 
> the pdp-ll architecture made it really rather difficult:

RSX-11M-Plus made it easy to use separate I/D space.  It was just a 
switch on your compile command line and a switch in the task builder. 
(If you were programming in Macro-11, you used separate I- and D-space 
PSECTs instead of a switch on the MAC command line.)

Now if you were programming without the benefit of an operating 
system, you would find that using separate I/D spaces was no more 
difficult than using the rest of the memory management hardware.


-- 

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/

0
mylastname3 (505)
10/5/2009 5:15:46 PM
ChrisQ <meru@devnull.com> wrote:
(snip)  

< Sorry, but the C library is *not* part of C. It may included as a 
< convenience, but there's no reason why you shouldn't write your own, as 
< in fact many people do.

You can write your own, but many names are reserved.  As I understand
it, all names starting with str are reserved.  Note that even if
you write your own library the compiler might inline strcpy(),
and not call an actual library routine.  That is the significance
of it being part of the language.
 
< For embedded and systems programming work, there is no better language, 
< imnsho. Portability, enough low level access for every nook and cranny 
< of the machine, while at the same time enough high level facility to 
< enable serious systems development.

Be careful with your names, and it should work just fine.

-- glen
0
gah (12851)
10/5/2009 6:32:03 PM
Michael Kraemer wrote:
> In article <tK6dnR3F2e9Xc1TXnZ2dnUVZ_vKdnZ2d@giganews.com>, "Richard B. Gilbert"
> <rgilbert88@comcast.net> writes:
>> I've never seen or heard of one.  It's not necessary to "avoid" certain 
>> calls.  It IS necessary to understand exactly what you are doing. 
> 
> It's always good to think before coding.
> 
>> C is 
>> really just a "portable" assembler.  You have to keep in mind that a 
>> slip on your part might crash your process 
> 
> That's not restricted to C.
> 
>> or even your system.
> 
> How can a simple user app crash the system?
> And why would that be a particular feature of C?

It depends on what system you are using.  Look at Windows, especially 
the older versions, for examples galore.  Some O/Ss are more difficult 
than others.
0
rgilbert88 (4439)
10/5/2009 6:32:24 PM
In article <jDoym.16$Rk1.6@newsfe07.ams2>, ChrisQ <meru@devnull.com> writes:
> Bob Koehler wrote:
> 
>> 
>>    According to the ANSI C language standard, the ANSI C functions are
>>    part of the language.
>>
> 
> Not to nitpick further, but while the standard library may be defined 
> within the standard, but it's not part pf the syntax. Thus, the standard 
> defines 2 parts, the language and it's standard library...

   That makes sense to me, and it makes sense to you, but it is not
   the ANSI definition.

0
koehler2 (8314)
10/5/2009 6:45:38 PM
In article <0Epym.2136$SO7.1146@newsfe15.ams2>, ChrisQ <meru@devnull.com> writes:
> Bob Koehler wrote:
> 
>> 
>>    It's simple.  Avoid any call that passes an output parameter by
>>    pointer but doesn't pass in input parameter provinding the allocated
>>    length.
>> 
> 
> You can get the equivalent of call by descriptor by declaring a structure:
> 

   Of course you can.  You can also update the C language standard.

0
koehler2 (8314)
10/5/2009 6:47:06 PM
Bob Koehler wrote:
> In article <7ire14F32vm9nU2@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>> And once again we blame the language for the incompetence (or just plain
>> laziness) of the programmers.
> 
>    That's like blaiming the carpenter who loses his hand to a circular
>    saw without a blade guard.  The saw should have had the blade guard.
> 

Yes but the carpenter should not have used a power saw without a blade 
guard.  You may remove or disable blade guards for your convenience but 
if you do you deserve whatever happens to you.

If a power saw without a blade guard is in use OSHA may have a few words 
to say on the subject here in the U.S. and may levy a substantial fine 
if this occurs in the workplace.

If you use a power saw at home and remove or defeat the blade guard the 
only penalty is the injury that will happen sooner or later.

"Experience keeps a dear school but a fool will learn in no other!"

0
rgilbert88 (4439)
10/5/2009 6:48:02 PM
Bob Koehler wrote:
> In article <7ire14F32vm9nU2@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>> And once again we blame the language for the incompetence (or just plain
>> laziness) of the programmers.
> 
>    That's like blaiming the carpenter who loses his hand to a circular
>    saw without a blade guard.  The saw should have had the blade guard.
> 

Yes but the carpenter should not have used a power saw without a blade 
guard.  You may remove or disable blade guards for your convenience but 
if you do you deserve whatever happens to you.

If a power saw without a blade guard is in use OSHA may have a few words 
to say on the subject here in the U.S. and may levy a substantial fine 
if this occurs in the workplace.

If you use a power saw at home and remove or defeat the blade guard the 
only penalty is the injury that will happen sooner or later.

"Experience keeps a dear school but a fool will learn in no other!"

0
rgilbert88 (4439)
10/5/2009 6:48:58 PM
Bob Eager wrote:
> On Mon, 05 Oct 2009 12:06:21 +0000, Robin Fairbairns wrote:
> 
>> remember, the later pdp 11 models had i-space and d-space, but i never
>> encountered anyone using them.
> 
> Later versions of UNIX did. Version 7, anyway.
> 

ISTR that RSX11M+ used I & D space.  This was back in the late 1980s or 
early 1990s.
0
rgilbert88 (4439)
10/5/2009 6:57:55 PM
Bob Eager wrote:
> On Mon, 05 Oct 2009 14:24:02 +0000, Michael Kraemer wrote:
> 
>>> or even your system.
>> How can a simple user app crash the system? And why would that be a
>> particular feature of C?
> 
> Indeed! Although we did have a design fault on an ICL mainframe which was 
> triggered nearly every time by FORTRAN programs. Halted the microprogram.
> 

It's not SUPPOSED to happen but Murphy says if it can it will!
0
rgilbert88 (4439)
10/5/2009 7:00:20 PM
On Mon, 05 Oct 2009 15:00:20 -0400, Richard B. Gilbert wrote:

> Bob Eager wrote:
>> On Mon, 05 Oct 2009 14:24:02 +0000, Michael Kraemer wrote:
>> 
>>>> or even your system.
>>> How can a simple user app crash the system? And why would that be a
>>> particular feature of C?
>> 
>> Indeed! Although we did have a design fault on an ICL mainframe which
>> was triggered nearly every time by FORTRAN programs. Halted the
>> microprogram.
>> 
>> 
> It's not SUPPOSED to happen but Murphy says if it can it will!

Yes...in that case, the manufacturer insisted there was no fault. So I 
wrote a microprogram patch....!



-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
10/5/2009 8:02:03 PM
Bob Eager <rde42@spamcop.net> wrote:
< On Mon, 05 Oct 2009 15:00:20 -0400, Richard B. Gilbert wrote:
 
<> It's not SUPPOSED to happen but Murphy says if it can it will!

A good rule for computing hardware in general.
 
< Yes...in that case, the manufacturer insisted there was no fault. 
< So I wrote a microprogram patch....!

Reminds me of the story of one IBM computer sometime before S/360.

For S/360, the EX (execute) instruction is not allowed to execute
another EX.  An earlier machine allowed it with a loop so tight
that power cycling the machine wouldn't get out of it.  
(Core memory including the address of the next instruction.)
The only way out involved magnets and opening the memory box.

I know the PDP-10 has XCT, and I thought VAX would have one,
but I don't see it in the book.

-- glen

0
gah (12851)
10/5/2009 8:15:13 PM
On Mon, 05 Oct 2009 20:15:13 +0000, glen herrmannsfeldt wrote:

> Bob Eager <rde42@spamcop.net> wrote:
> < On Mon, 05 Oct 2009 15:00:20 -0400, Richard B. Gilbert wrote:
>  
> <> It's not SUPPOSED to happen but Murphy says if it can it will!
> 
> A good rule for computing hardware in general.
>  
> < Yes...in that case, the manufacturer insisted there was no fault. < So
> I wrote a microprogram patch....!
> 
> Reminds me of the story of one IBM computer sometime before S/360.
> 
> For S/360, the EX (execute) instruction is not allowed to execute
> another EX.  An earlier machine allowed it with a loop so tight that
> power cycling the machine wouldn't get out of it. (Core memory including
> the address of the next instruction.) The only way out involved magnets
> and opening the memory box.

I heard that on the Honeywell 516, a very tight loop (single instruction) 
would burn out core. Never tried it though!
> 
> I know the PDP-10 has XCT, and I thought VAX would have one, but I don't
> see it in the book.

No, I don't see it, and I think I would have remembered it since I pretty 
well immersed myself in the VAX instruction set when writing a compiler...




-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
10/5/2009 8:28:52 PM
Bob Eager wrote:

> I heard that on the Honeywell 516, a very tight loop (single instruction) 
> would burn out core. Never tried it though!

James T Kirk tried it succesfully on a number of occasions, and this was
documented in a 1960s documentary called "Star Trek".

:-)
0
10/5/2009 8:30:49 PM
In article <nNudnZemEZqColfXnZ2dnUVZ_oKdnZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> 
> Yes but the carpenter should not have used a power saw without a blade 
> guard.

   Yep, and the programmer shouldn't have used C.

0
koehler2 (8314)
10/5/2009 9:01:20 PM
In article <hadk4h$k3m$1@naig.caltech.edu>, glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> 
> I know the PDP-10 has XCT, and I thought VAX would have one,
> but I don't see it in the book.

   No, VAX, PDP-11, Alpha, and don't.  The only good use for it that I
   ever saw on a PDP-10 was to accomplish the same result as a VAX
   CASE instruction.

0
koehler2 (8314)
10/5/2009 9:03:06 PM
In article <0042e784$0$26769$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>Bob Eager wrote:
>
>> I heard that on the Honeywell 516, a very tight loop (single instruction) 
>> would burn out core. Never tried it though!
>
>James T Kirk tried it succesfully on a number of occasions, and this was
>documented in a 1960s documentary called "Star Trek".

Landru is certain to get you for that!  If not Landru, perhaps Nomad or M5.
-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

  http://www.quirkfactory.com/popart/asskey/eqn2.png
  
  "Well my son, life is like a beanstalk, isn't it?"
0
VAXman
10/5/2009 9:08:59 PM
Bob Eager <rde42@spamcop.net> wrote:
< On Mon, 05 Oct 2009 20:15:13 +0000, glen herrmannsfeldt wrote:
(snip)
 
<> Reminds me of the story of one IBM computer sometime before S/360.
(snip of execute instruction executing itself)
 
< I heard that on the Honeywell 516, a very tight loop (single instruction) 
< would burn out core. Never tried it though!

Maybe that is why IBM used to imerse the whole core memory
in oil.  I am not so sure about burn out, but core memory is 
temperature sensitive.   The magnetic properties change, probably
enough to stop it from working if it gets too warm.
 
<> I know the PDP-10 has XCT, and I thought VAX would have one, but I don't
<> see it in the book.
 
< No, I don't see it, and I think I would have remembered it since I pretty 
< well immersed myself in the VAX instruction set when writing a compiler...

It might not be so commonly used by compilers, even if it did have one.

-- glen
0
gah (12851)
10/5/2009 9:28:33 PM
Bob Koehler <koehler@eisner.nospam.encompasserve.org> wrote:
(I wrote)
 
<> I know the PDP-10 has XCT, and I thought VAX would have one,
<> but I don't see it in the book.
 
<   No, VAX, PDP-11, Alpha, and don't.  The only good use for it that I
<   ever saw on a PDP-10 was to accomplish the same result as a VAX
<   CASE instruction.

For S/360, some instructions have a length field in the second byte.
EX allows for variable lengths by modifying (a copy of) the instruction
before executing it.  

At least some features of the PDP-10 are similar to features on the
IBM 36 bit predecessors to S/360, so XCT doesn't seem so surprising.
I did do some Macro-10 programming, but I don't remember using it.

-- glen
 
0
gah (12851)
10/5/2009 9:34:59 PM
In article <gKBLIl0YcnM+@eisner.encompasserve.org>,
	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <7ire14F32vm9nU2@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>> 
>> And once again we blame the language for the incompetence (or just plain
>> laziness) of the programmers.
> 
>    That's like blaiming the carpenter who loses his hand to a circular
>    saw without a blade guard.  The saw should have had the blade guard.

The saw wasn't made without a blade guard (at least none I ever used was).
It is still the fault of the operator for using it improperly.

When C is used properly it works just fine and doesn't have any more
security problems than any other language. I have never written a
program that was exploited thru a buffer overflow.

bill
 

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
10/5/2009 10:45:16 PM
Bob Koehler wrote:
> In article <nNudnZemEZqColfXnZ2dnUVZ_oKdnZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>> Yes but the carpenter should not have used a power saw without a blade 
>> guard.
> 
>    Yep, and the programmer shouldn't have used C.
> 

Well, the cases are not quite parallel.  I use C occasionally but I'm 
damned careful with it.  The old K&R C is really bad.  Newer ANSI 
standard C is a little better.  Neither will do much to protect your 
from your own stupidity.
0
rgilbert88 (4439)
10/5/2009 10:46:54 PM
In article <c+EmAKuu74DO@eisner.encompasserve.org>,
	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <7irdntF32vm9nU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>> 
>> And, it is once again necessary to point out that Unix didn't invent
>> the "null terminated string".
> 
>    I didn't see anyone claim it did.  I also didn't see anyone claim C
>    did.  I just don't see the logic in choosing it when a simple data
>    structure seems to work better.  Even PASCAL seemed to choose a
>    less intensive approach.
 
And as has been pointed out the method normally used by Pascal has
serious shortcomings and just bout all of the Pascal compilers I
have ever used included a way to turn of range and bounds checking
allowing for the exact same dangers as C'c null terminated strings.
Seems a lot of people saw that as a necessary evil.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
10/5/2009 10:48:20 PM
Bill Gunshannon wrote:
> In article <gKBLIl0YcnM+@eisner.encompasserve.org>,
> 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>> In article <7ire14F32vm9nU2@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>>> And once again we blame the language for the incompetence (or just plain
>>> laziness) of the programmers.
>>    That's like blaiming the carpenter who loses his hand to a circular
>>    saw without a blade guard.  The saw should have had the blade guard.
> 
> The saw wasn't made without a blade guard (at least none I ever used was).
> It is still the fault of the operator for using it improperly.
> 
> When C is used properly it works just fine and doesn't have any more
> security problems than any other language. I have never written a
> program that was exploited thru a buffer overflow.
> 

You are not part of the problem!  Nor am I.  I have coded programs in C
and dekludged a fair amount of other peoples C.  My C might look a 
little like Fortran but the programs work!

If C were a power saw, we would see a lot more three fingered carpenters!
0
rgilbert88 (4439)
10/5/2009 10:56:13 PM
Re: C and buffer overflows.

Is there a language which keeps 2 values for each string: amount
allocated and amount currently in use ?

Without such 2 values, you can't have totally save "read" and "write"
into that variable. When you write, you need to know how many bytes you
can write, and when you read, you need to know how many bytes were
written to it.

Cobol had solved the problem by having fixed lenghth strings and when
you moved a shorter value to them, they would be padded to the fixed
length. (and you couldn't move longer values from within Cobol).

HOWEVER, when you called an externally compiled routine, that routine
would have no knowledge of the alloocated size of the variable you are
passing as argument so it could write beyond the buffer and cause problems.
0
10/6/2009 3:46:52 AM
JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
< Re: C and buffer overflows.
 
< Is there a language which keeps 2 values for each string: amount
< allocated and amount currently in use ?
 
< Without such 2 values, you can't have totally save "read" and "write"
< into that variable. When you write, you need to know how many bytes you
< can write, and when you read, you need to know how many bytes were
< written to it.

I believe that PL/I does it.  In the implementations that I know of,
as well as I remember, the allocated length is known in the procedure
and passed in a descriptor (dope vector) on calls.  The current
length is at the beginning of the string.  Note, for example, that
for an array (in most languages) all elements have the same 
allocated length but possibly different current length.   

-- glen
0
gah (12851)
10/6/2009 3:57:53 AM
Not really Paul, most of it is just "the voice of experience" kind of  
stuff.
C is a really simple language, and though people may argue about it,
it is really very much like PDP-11 Macro assembler. You can get yourself
into trouble by not understanding what you are doing, but to compensate
for that, you can pretty much do *anything* you want to do.

Buffer over-runs can be a concern, and where they *are* a concern,
then use a different technique. :)

-Paul


On Oct 5, 2009, at 7:22 AM, P. Sture wrote:

> In article <habq5n$pi6$3@naig.caltech.edu>,
> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>
>> Michael Kraemer <M.Kraemer@gsi.de> wrote:
>> < glen herrmannsfeldt schrieb:
>>
>> <> Well, the C gets() function, I believe still part of the standard,
>> <> has no way to know the length of the buffer.  The only answer is
>> <> not to use it, but it does seem fair to blame the language in that
>> <> case.
>>
>> < To be nitpicking: it's not part of the language,
>> < neither are all other functions.
>> < But I agree, at least the doc's should deprecate its use.
>>
>> I have seen that discussed.  There are some questions in K&R as
>> to the library being part of the language.  Most agree that it is
>> for ANSI C.
>>
>> <> Otherwise, yes, it is up to programmers to check at the
>> <> appropriate points.
>>
>> And to always use fgets() instead of gets().
>>
>
> Is there a handy reference to this stuff? I mean a summary of what C
> calls to avoid and why (possibly detailing safe and unsafe
> circumstances).
>
> -- 
> Paul Sture
> _______________________________________________
> Info-vax mailing list
> Info-vax@rbnsn.com
> http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com
>


0
paul298 (265)
10/6/2009 4:34:35 AM
glen herrmannsfeldt wrote:
> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> < Re: C and buffer overflows.
>  
> < Is there a language which keeps 2 values for each string: amount
> < allocated and amount currently in use ?

As Glen points out PL/I does support this as part of the language.
VMS also has the descriptor type of DSC$K_DTYPE_VT.  This is a
descriptor that keeps the maximum length in DSC$W_LENGTH while
maintaining the actual length as the first word of the buffer
pointed at by DSC$A_POINTER.

>  
> < Without such 2 values, you can't have totally save "read" and "write"
> < into that variable. When you write, you need to know how many bytes you
> < can write, and when you read, you need to know how many bytes were
> < written to it.
> 
> I believe that PL/I does it.  In the implementations that I know of,
> as well as I remember, the allocated length is known in the procedure
> and passed in a descriptor (dope vector) on calls.  The current
> length is at the beginning of the string.  Note, for example, that
> for an array (in most languages) all elements have the same 
> allocated length but possibly different current length.   

Correct.  For OpenVMS the format of a varying string matches
that used by other languages, like Pascal.  The layout is
detailed here:

     http://www.kednos.com/pli/docs/REFERENCE_MANUAL/6291pro_009.html#vary_data

The built-in function LENGTH(string) provides the current length
of string.  Whereas MAXLENGTH(string) returns the maximum.  To
get this functionality the string needs to be declared with
the VARYING attribute.

Tim.
0
10/6/2009 4:34:50 AM
On 2009-10-05, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> Re: C and buffer overflows.
>
> Is there a language which keeps 2 values for each string: amount
> allocated and amount currently in use ?
>

Yes, Ada.

You have a range of string data types, so you can choose which one
best matches your requirements. One of the string data types Ada provides
is called Bounded String:

http://www.adaic.org/standards/95lrm/html/RM-A-4-4.html

If you can put to one side the US military origins of Ada, it's actually
a nice language to work with.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world
0
clubley (1478)
10/6/2009 11:13:47 AM
In article <paul.nospam-A4EA28.16190828092009@pbook.sture.ch>,
 "P. Sture" <paul.nospam@sture.ch> writes:
>In article <+klqzn95w7HU@eisner.encompasserve.org>,
> koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote:
>
>> In article <Fc2dnfSHw9YW-iDXnZ2dnUVZ_gydnZ2d@giganews.com>, "Richard B. 
>> Gilbert" <rgilbert88@comcast.net> writes:
>> >
>> > Keeping bad code a secret in order to prevent hacking is, to say the 
>> > least, a poor way to do business.  Sun has made most of the Solaris 
>> > source code available for comment, criticism, and improvement.  The 
>> > stuff that's still not public belongs in whole or in part to third 
>> > parties and is used by Sun under license.
>> 
>>    Obviously Sun and Microsoft don't think the same!  Sun was one of the
>>    early proponents of "open sysytems".  Microsoft owns the most closed
>>    system in the business.  Nobody is allowed to see inside!
>
>That was a source of frustration when I was seriously looking at NT.  
>Various folks were coming out with stuff I couldn't find in any 
>documentation and I was wondering where on earth they got it.

"windows internals" (published by m$ press) is a good source.  one of
the authors is now on the inside, but when i bought my copy (3rd
edition, iirc) both russinovich and solomon were independent
consultants.  they gave fantastic talks at m$ "teched" conferences
(which i attended a few times, mostly pretty tedious otherwise, the
highlight being the lotteries for free things for people who had
filled in lecture assessments).
-- 
Robin Fairbairns, Cambridge
0
rf10 (3613)
10/6/2009 11:44:31 AM
JF Mezei wrote:
> Re: C and buffer overflows.
> 
> Is there a language which keeps 2 values for each string: amount
> allocated and amount currently in use ?
> 
> Without such 2 values, you can't have totally save "read" and "write"
> into that variable. When you write, you need to know how many bytes you
> can write, and when you read, you need to know how many bytes were
> written to it.
> 
> Cobol had solved the problem by having fixed lenghth strings and when
> you moved a shorter value to them, they would be padded to the fixed
> length. (and you couldn't move longer values from within Cobol).
> 
> HOWEVER, when you called an externally compiled routine, that routine
> would have no knowledge of the alloocated size of the variable you are
> passing as argument so it could write beyond the buffer and cause problems.

I don't know of such a language.  I think you will have to "roll your 
own" string descriptors!  You could write your own library of string 
functions using your own descriptors.  Or you could just borrow the 
facility that's already there in DEC C.
0
rgilbert88 (4439)
10/6/2009 12:41:13 PM
In article <7iv384F31nq9iU23@mid.individual.net>,
	Bob Eager <rde42@spamcop.net> writes:
> On Mon, 05 Oct 2009 20:15:13 +0000, glen herrmannsfeldt wrote:
> 
>> Bob Eager <rde42@spamcop.net> wrote:
>> < On Mon, 05 Oct 2009 15:00:20 -0400, Richard B. Gilbert wrote:
>>  
>> <> It's not SUPPOSED to happen but Murphy says if it can it will!
>> 
>> A good rule for computing hardware in general.
>>  
>> < Yes...in that case, the manufacturer insisted there was no fault. < So
>> I wrote a microprogram patch....!
>> 
>> Reminds me of the story of one IBM computer sometime before S/360.
>> 
>> For S/360, the EX (execute) instruction is not allowed to execute
>> another EX.  An earlier machine allowed it with a loop so tight that
>> power cycling the machine wouldn't get out of it. (Core memory including
>> the address of the next instruction.) The only way out involved magnets
>> and opening the memory box.
> 
> I heard that on the Honeywell 516, a very tight loop (single instruction) 
> would burn out core. Never tried it though!
>> 
>> I know the PDP-10 has XCT, and I thought VAX would have one, but I don't
>> see it in the book.
> 
> No, I don't see it, and I think I would have remembered it since I pretty 
> well immersed myself in the VAX instruction set when writing a compiler...
 
Sounds like the HCF instruction reported to exist in some (in particular
Motorolla) microprocessors in the dim dark past.

bill 
 
 

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
10/6/2009 5:08:49 PM
"JF Mezei" <jfmezei.spamnot@vaxination.ca> wrote in message 
news:0083cc77$0$30078$c3e8da3@news.astraweb.com...
> Re: C and buffer overflows.
>
> Is there a language which keeps 2 values for each string: amount
> allocated and amount currently in use ?

Pascal (well, Extended Pascal, but OpenVMS Pascal has that from the EP 
standard).

The predeclared STRING type will take a run-time expression for the maximum 
capacity.  You can get the current length with LENGTH() and you can get the 
max capacity with the ".CAPACITY" descriminant.

Underneath, we use a leading length word on the string so you are limited to 
64K characters.  For ease of implementation, we use a longword at run-time 
to keep the CAPACITY, but check that it doesn't exceed 64K.

Note this is more flexible than the VARYING OF CHAR in OpenVMS Pascal 
(stolen from PL/I) which only allows compile-time expressions as the maximum 
length.

John 


0
johnrreagan (372)
10/6/2009 5:40:15 PM
Bill Gunshannon wrote:
> In article <7iv384F31nq9iU23@mid.individual.net>,
> 	Bob Eager <rde42@spamcop.net> writes:
>> On Mon, 05 Oct 2009 20:15:13 +0000, glen herrmannsfeldt wrote:
>>
>>> Bob Eager <rde42@spamcop.net> wrote:
>>> < On Mon, 05 Oct 2009 15:00:20 -0400, Richard B. Gilbert wrote:
>>>  
>>> <> It's not SUPPOSED to happen but Murphy says if it can it will!
>>>
>>> A good rule for computing hardware in general.
>>>  
>>> < Yes...in that case, the manufacturer insisted there was no fault. < So
>>> I wrote a microprogram patch....!
>>>
>>> Reminds me of the story of one IBM computer sometime before S/360.
>>>
>>> For S/360, the EX (execute) instruction is not allowed to execute
>>> another EX.  An earlier machine allowed it with a loop so tight that
>>> power cycling the machine wouldn't get out of it. (Core memory including
>>> the address of the next instruction.) The only way out involved magnets
>>> and opening the memory box.
>> I heard that on the Honeywell 516, a very tight loop (single instruction) 
>> would burn out core. Never tried it though!
>>> I know the PDP-10 has XCT, and I thought VAX would have one, but I don't
>>> see it in the book.
>> No, I don't see it, and I think I would have remembered it since I pretty 
>> well immersed myself in the VAX instruction set when writing a compiler...
>  
> Sounds like the HCF instruction reported to exist in some (in particular
> Motorolla) microprocessors in the dim dark past.
> 
> bill 
>  
>  
> 

I think HCF (Halt and Catch Fire) was invented by a humorist writing in 
"Datamation".  It might even have made into the book "Faith, Hope and 
Parity", a collection of humorous stories and cartoons culled from 
"Datamation".  I think that this was many years before Motorola got 
involved in the computer business!
0
rgilbert88 (4439)
10/6/2009 7:55:05 PM
glen herrmannsfeldt wrote:
> ChrisQ <meru@devnull.com> wrote:
> (snip)  
> 
> < Sorry, but the C library is *not* part of C. It may included as a 
> < convenience, but there's no reason why you shouldn't write your own, as 
> < in fact many people do.
> 
> You can write your own, but many names are reserved.  As I understand
> it, all names starting with str are reserved.  Note that even if
> you write your own library the compiler might inline strcpy(),
> and not call an actual library routine.  That is the significance
> of it being part of the language.
>  
> < For embedded and systems programming work, there is no better language, 
> < imnsho. Portability, enough low level access for every nook and cranny 
> < of the machine, while at the same time enough high level facility to 
> < enable serious systems development.
> 
> Be careful with your names, and it should work just fine.
> 
> -- glen

I must be out of date. Have been programming C since about 1983 and have 
never heard of C *library* function calls being reserved words within 
the the C *compiler*.

Perhaps someone could provide examples ?. Sounds like a lot of flannel 
to me ;-)...

Regards,

Chris

(flannel: A Yorkshire expression suggesting that an assertion of fact is 
in fact not so. Usually expressed with a little more emotion)
0
ChrisQ
10/6/2009 8:29:47 PM
On Oct 6, 3:29=A0pm, ChrisQ <m...@devnull.com> wrote:
> I must be out of date. Have been programming C since about 1983 and have
> never heard of C *library* function calls being reserved words within
> the the C *compiler*.
>
> Perhaps someone could provide examples ?. Sounds like a lot of flannel
> to me ;-)...

Here, let me Google that for you. ;-)

http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1336.pdf

See section 7.1.3. As I read it, a C library function identifier is a
reserved word IFF the associated header file is included. No idea if
this is enforced by any compilers. So, for example, you may define
your own malloc() but you shall not also include <stdlib.h>. Also, as
I read it, certain identifiers are reserved at all times, such as
those beginning with double underscore.

Please note the cited document is a draft revision of the C99 standard.
0
MetaEd
10/6/2009 9:06:59 PM
On Tue, 06 Oct 2009 14:06:59 -0700, MetaEd wrote:

> On Oct 6, 3:29 pm, ChrisQ <m...@devnull.com> wrote:
>> I must be out of date. Have been programming C since about 1983 and
>> have never heard of C *library* function calls being reserved words
>> within the the C *compiler*.
>>
>> Perhaps someone could provide examples ?. Sounds like a lot of flannel
>> to me ;-)...
> 
> Here, let me Google that for you. ;-)
> 
> http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1336.pdf
> 
> See section 7.1.3. As I read it, a C library function identifier is a
> reserved word IFF the associated header file is included. No idea if
> this is enforced by any compilers. So, for example, you may define your
> own malloc() but you shall not also include <stdlib.h>. Also, as I read
> it, certain identifiers are reserved at all times, such as those
> beginning with double underscore.
> 
> Please note the cited document is a draft revision of the C99 standard.

But section 7 is in the *library* section, not the *language* section. As 
such, it's not a compiler restriction, but an entirely reasonable library 
one.

Clearly it's intended to indicate that 'mix and match' stuff is not a 
good idea. More to the point, it provides for the case where a 'user' 
malloc takes differing arguments, or behaves differently, and would thus 
interfere with the workings of the library.

None of this invalidates using your own strcpy, etc. if you want to.




-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
10/6/2009 9:54:56 PM
MetaEd wrote:

> 
> Here, let me Google that for you. ;-)
> 
> http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1336.pdf
> 
> See section 7.1.3. As I read it, a C library function identifier is a
> reserved word IFF the associated header file is included. No idea if
> this is enforced by any compilers. So, for example, you may define
> your own malloc() but you shall not also include <stdlib.h>. Also, as
> I read it, certain identifiers are reserved at all times, such as
> those beginning with double underscore.
> 
> Please note the cited document is a draft revision of the C99 standard.

Obviously, if you include a header with a function prototype, you would 
expect to be in trouble if you then try to redefine the function within 
the module. Any function becomes "reserved" if you have already declared 
a prototype in an included include file.

What this draft revision seems to be saying is that the function 
prototype is only recognised by the compiler as a *library* function if 
the associated header file is included. What this means is that the 
compiler development must closely track the standard lib development and 
changes, which makes no sense. That is, the compiler must be aware of 
all the standard lib functions and their formal parameters.

Tripe, if you ask me. (Tripe: popular at one time together with raw 
onions and malt vinegar. Very nutritious, so i'm told)

Regards,

Chris
0
ChrisQ
10/6/2009 10:11:39 PM
ChrisQ wrote:

> I must be out of date. Have been programming C since about 1983 and have 
> never heard of C *library* function calls being reserved words within 
> the the C *compiler*.

From what I have been told, some of the C library functions have been
implemented as macros now so that the code is embedded in the mainline
and allowing compiler optimisations.

For instance, character conversions functions such as toupper, tolower,
isalpha, isnum etc are now implemented as macros, not functions.


I had heard at one point, but not sure, that some C compilers would
process "printf" internally instead of calling an external routine. But
am not sure of that. (remember that in some environments, the compiler
and linker are the same thing).

0
10/6/2009 10:39:42 PM
In article <mailman.29.1254803697.18305.info-vax_rbnsn.com@rbnsn.com>,
 Paul Raulerson <paul@raulersons.com> wrote:

> Not really Paul, most of it is just "the voice of experience" kind of  
> stuff.
> C is a really simple language, and though people may argue about it,
> it is really very much like PDP-11 Macro assembler. You can get yourself
> into trouble by not understanding what you are doing, but to compensate
> for that, you can pretty much do *anything* you want to do.
> 
> Buffer over-runs can be a concern, and where they *are* a concern,
> then use a different technique. :)

That's a shame, because I come from a generation where C was not taught 
at school or college (at least where I attended), and I keep coming 
across comments like "any idiot knows not to use xyz", but unfortunately 
nobody taught me why.

It does reinforce my opinion, which was very real in the UK at one point 
in time, that the college professors and lecturers wanted to create a 
high priesthood of those who understood C and damn the rest.

Meanwhile their payrolls and pensions were being processed with COBOL or 
PL/I or Pascal. And those folks _really do scream_ if not paid on time.

-- 
Paul Sture
0
paul.nospam (2164)
10/6/2009 11:42:41 PM
On Tue, 06 Oct 2009 18:39:42 -0400, JF Mezei wrote:

> From what I have been told, some of the C library functions have been
> implemented as macros now so that the code is embedded in the mainline
> and allowing compiler optimisations.
> 
> For instance, character conversions functions such as toupper, tolower,
> isalpha, isnum etc are now implemented as macros, not functions.

That used to be common in the Microsoft compilers (typical). However, 
those macros were generally broken in that their semantics were not quite 
the same as their functional equivalent (e.g. toupper just stripped off a 
bit). Some were renamed to (e.g.) _toupper, because the standard now 
mandates toupper as a proper function.

However...section 7.26 of the standard is the interesting one (and I 
didn't know this, but the standard happened to be right beside me). It 
says that ALL names starting with 'str', 'mem' (for example) are 
reserved, no matter what files are included! There are other examples 
such as whole function names such as 'cerf'.

This is obviously just to future-proof programs, and in practice I doubt 
that it matters. Compilers would not generally check this; as said 
before, it's a library thing.


-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
10/6/2009 11:48:37 PM
Bob Eager <rde42@spamcop.net> wrote:
(snip)
 
< However...section 7.26 of the standard is the interesting one (and I 
< didn't know this, but the standard happened to be right beside me). It 
< says that ALL names starting with 'str', 'mem' (for example) are 
< reserved, no matter what files are included! There are other examples 
< such as whole function names such as 'cerf'.
 
< This is obviously just to future-proof programs, and in practice I doubt 
< that it matters. Compilers would not generally check this; as said 
< before, it's a library thing.

Many compilers now generate those functions inline, without calling
an actual function.  That would only be true for the ones actually
implemented, such as strcat and memcpy, but they reserved them all
to allow for future additions.

If you try to write your own strcat, it is likely on current
compilers never to be called.

-- glen
0
gah (12851)
10/7/2009 12:43:44 AM
On Wed, 07 Oct 2009 00:43:44 +0000, glen herrmannsfeldt wrote:

> Bob Eager <rde42@spamcop.net> wrote:
> (snip)
>  
> < However...section 7.26 of the standard is the interesting one (and I <
> didn't know this, but the standard happened to be right beside me). It <
> says that ALL names starting with 'str', 'mem' (for example) are <
> reserved, no matter what files are included! There are other examples <
> such as whole function names such as 'cerf'.
>  
> < This is obviously just to future-proof programs, and in practice I
> doubt < that it matters. Compilers would not generally check this; as
> said < before, it's a library thing.
> 
> Many compilers now generate those functions inline, without calling an
> actual function.  That would only be true for the ones actually
> implemented, such as strcat and memcpy, but they reserved them all to
> allow for future additions.
> 
> If you try to write your own strcat, it is likely on current compilers
> never to be called.

I'd be interested to know which compilers. Can you cite some examples, 
please?




-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
10/7/2009 6:36:21 AM
On Wed, 07 Oct 2009 06:36:21 +0000, Bob Eager wrote:

> On Wed, 07 Oct 2009 00:43:44 +0000, glen herrmannsfeldt wrote:
> 
>> Bob Eager <rde42@spamcop.net> wrote:
>> (snip)
>>  
>> < However...section 7.26 of the standard is the interesting one (and I
>> < didn't know this, but the standard happened to be right beside me).
>> It < says that ALL names starting with 'str', 'mem' (for example) are <
>> reserved, no matter what files are included! There are other examples <
>> such as whole function names such as 'cerf'.
>>  
>> < This is obviously just to future-proof programs, and in practice I
>> doubt < that it matters. Compilers would not generally check this; as
>> said < before, it's a library thing.
>> 
>> Many compilers now generate those functions inline, without calling an
>> actual function.  That would only be true for the ones actually
>> implemented, such as strcat and memcpy, but they reserved them all to
>> allow for future additions.
>> 
>> If you try to write your own strcat, it is likely on current compilers
>> never to be called.
> 
> I'd be interested to know which compilers. Can you cite some examples,
> please?

Sorry - I should have said "...and in which that behaviour can't easily 
be turned off".



-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
10/7/2009 6:47:21 AM
Bob Eager <rde42@spamcop.net> wrote:
> On Wed, 07 Oct 2009 00:43:44 +0000, glen herrmannsfeldt wrote:
(snip regarding C str... functions)
 
>> Many compilers now generate those functions inline, without calling an
>> actual function.  That would only be true for the ones actually
>> implemented, such as strcat and memcpy, but they reserved them all to
>> allow for future additions.
 
>> If you try to write your own strcat, it is likely on current compilers
>> never to be called.

> I'd be interested to know which compilers. Can you cite some examples, 
> please?

In just one test on one version of gcc, it seems to inline strcpy
with -O1 or higher, but not for -O0, the default.

-- glen
0
gah (12851)
10/7/2009 7:12:35 AM
On Wed, 07 Oct 2009 07:12:35 +0000, glen herrmannsfeldt wrote:

> Bob Eager <rde42@spamcop.net> wrote:
>> On Wed, 07 Oct 2009 00:43:44 +0000, glen herrmannsfeldt wrote:
> (snip regarding C str... functions)
>  
>>> Many compilers now generate those functions inline, without calling an
>>> actual function.  That would only be true for the ones actually
>>> implemented, such as strcat and memcpy, but they reserved them all to
>>> allow for future additions.
>  
>>> If you try to write your own strcat, it is likely on current compilers
>>> never to be called.
> 
>> I'd be interested to know which compilers. Can you cite some examples,
>> please?
> 
> In just one test on one version of gcc, it seems to inline strcpy with
> -O1 or higher, but not for -O0, the default.

But not if you use -fno-builtin ...





-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

0
rde42 (1163)
10/7/2009 12:29:37 PM
 JF Mezei wrote:
> Re: C and buffer overflows.
> 
> Is there a language which keeps 2 values for each string: amount
> allocated and amount currently in use ?

    The STR$ routines in the VMS RTL and, IIRC, the latest Fortran
    standard, support dynamic length strings.  This allows the allocated
    and used length to be the same.

0
koehler2 (8314)
10/7/2009 1:10:00 PM
Bob Eager <rde42@spamcop.net> wrote:
< On Wed, 07 Oct 2009 07:12:35 +0000, glen herrmannsfeldt wrote:
 
<> Bob Eager <rde42@spamcop.net> wrote:
<>> On Wed, 07 Oct 2009 00:43:44 +0000, glen herrmannsfeldt wrote:
<> (snip regarding C str... functions)
  
<>>> Many compilers now generate those functions inline, without calling an
<>>> actual function.  That would only be true for the ones actually
<>>> implemented, such as strcat and memcpy, but they reserved them all to
<>>> allow for future additions.

<>> I'd be interested to know which compilers. Can you cite some examples,
<>> please?
 
<> In just one test on one version of gcc, it seems to inline strcpy with
<> -O1 or higher, but not for -O0, the default.
 
< But not if you use -fno-builtin ...

Sure.  But since the standard reserves str... names your program
is already non-standard.  It may still do what you want, with
or without such compiler options.  

Many programs assume twos complement arithmetic, but the C
standard does not.  Many programs assume short is 16 bits,
but the standard does not.  If you know which features are part
of the standard then you can decide to follow the standard
and use only standard features, or not.  Your choice.

-- glen
0
gah (12851)
10/7/2009 1:10:01 PM
> C is a really simple language, and though people may argue about it,
> it is really very much like PDP-11 Macro assembler. You can get yourself
> into trouble by not understanding what you are doing, but to compensate
> for that, you can pretty much do *anything* you want to do.
> 

That's about the best description so far. It's a very sharp tool and 
like all such things, should be used responsibly...

Regards,

Chris
0
ChrisQ
10/7/2009 2:46:35 PM
On 5 Oct 2009 09:25:25 -0500, koehler@eisner.nospam.encompasserve.org
(Bob Koehler) wrote:

>In article <ha6oek$gn9$02$1@news.t-online.com>, Michael Kraemer <M.Kraemer@gsi.de> writes:
>> 
>> That's not a problem of null termination,
>> it's a problem of writing to an area you do not own.
>
>   It's a problem of the called routine having no way of preventing you
>   from writing to an area you do not own.  Other languages do actually
>   prevent it.
>
>> This may happen in any language, i.e.
>> Assuming a fixed size of your data objects
>> because it would never ever been exceeded
>> (Y2K comes to mind).
>> In C, one would have used sth like
>> aBuffer = calloc( strlen(someString)+1, sizeof(*aBuffer) )
>
>   In Fortran, one would pass a string (CHARACTER), and the language 
>   definition requires that the called function has access to the
>   allocated length of the buffer, although this is implemented
>   different ways by different compilers, and the function can prevent 
>   the buffer from being overwritten.
>

This may be neither here nor there, but I recall supporting a program
written in FORTRAN/Fortran on VMS (VAX and Alpha) which started
completely misbehaving/crashing/acting strange all around.

After much investigation, and lots of treks through run/debug, I
finally tracked things down to a variable at the top-most level of the
program being modified from inside a subroutine to which it was never
passed.

It turned out that during a recompile/relink, the variables were
mapped diffferently and a string/character variable that was receiving
more data than allowed by it's declaration statement was now
overwriting this other variable due to the overflow (the variables
were now being mapped into sequential places in memory).

How it worked before the memory mapping was rearranged must have been
a complete "happy accident".  The bug was in that code from day 1 but
had somehow never surfaced before it was recompiled to take advantage
of improvements in a new version of the Fortran compiler.
0
notValid (52)
10/7/2009 8:53:21 PM
On Mon, 05 Oct 2009 14:48:02 -0400, "Richard B. Gilbert"
<rgilbert88@comcast.net> wrote:

>Bob Koehler wrote:
>> In article <7ire14F32vm9nU2@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>>> And once again we blame the language for the incompetence (or just plain
>>> laziness) of the programmers.
>> 
>>    That's like blaiming the carpenter who loses his hand to a circular
>>    saw without a blade guard.  The saw should have had the blade guard.
>> 
>
>Yes but the carpenter should not have used a power saw without a blade 
>guard.  You may remove or disable blade guards for your convenience but 
>if you do you deserve whatever happens to you.

The analogy between C programming and the blade guard on the saw would
make sense to me if we agreed that C programming "guards" are similar
to me buying a saw, but having to build my own blade guard to keep
safe.

In the saw's blade guard example, though, the company that makes the
saw designs and implements the blade guard on the product.  There is
no such thing for C programming, and instead everyone is left to
implement their own safeguards.

0
notValid (52)
10/7/2009 8:56:01 PM
In article <nuvpc5ppo1sdropbtajvfdas7t7l6i5mbk@4ax.com>,
	jls <notvalid@yahoo.com> writes:
> On Mon, 05 Oct 2009 14:48:02 -0400, "Richard B. Gilbert"
> <rgilbert88@comcast.net> wrote:
> 
>>Bob Koehler wrote:
>>> In article <7ire14F32vm9nU2@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>>>> And once again we blame the language for the incompetence (or just plain
>>>> laziness) of the programmers.
>>> 
>>>    That's like blaiming the carpenter who loses his hand to a circular
>>>    saw without a blade guard.  The saw should have had the blade guard.
>>> 
>>
>>Yes but the carpenter should not have used a power saw without a blade 
>>guard.  You may remove or disable blade guards for your convenience but 
>>if you do you deserve whatever happens to you.
> 
> The analogy between C programming and the blade guard on the saw would
> make sense to me if we agreed that C programming "guards" are similar
> to me buying a saw, but having to build my own blade guard to keep
> safe.
> 
> In the saw's blade guard example, though, the company that makes the
> saw designs and implements the blade guard on the product.  There is
> no such thing for C programming, and instead everyone is left to
> implement their own safeguards.

You are assuming the analogy was the guard when in fact it is the proper
use of the tool.  Using the saw without a guard is improper use.  Writing
C programs without the proper knowledge of the effects of various actions
resulting in bad programs is not the languages fault.

And for those who seem to think this is a C unique problem, I have seen
numerous overflow problems in both COBOL and Fortran programs.  I have
even written programs in COBOL to specifically demonstrate that behaviour.
I have seen programs in Fortran that had wierd "segment violation" (for
want a better term) errors that just seemed to disappear when a programmer
inserted PRINT statements into the code to try and debug it.  Anyone care
to guess why this would happen?  :-)

No programming language is immune to the effects of errors.  That's why
we study and learn and experiment and write programs in a constant effort
to improve our ability to write programs. "If it was easy, everyone would
do it", Tom Hanks in "A League of Their Own".  :-)

bill
 

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
10/7/2009 9:35:39 PM
Bill Gunshannon wrote:
> In article <nuvpc5ppo1sdropbtajvfdas7t7l6i5mbk@4ax.com>,
> 	jls <notvalid@yahoo.com> writes:
>> On Mon, 05 Oct 2009 14:48:02 -0400, "Richard B. Gilbert"
>> <rgilbert88@comcast.net> wrote:
>>
>>> Bob Koehler wrote:
>>>> In article <7ire14F32vm9nU2@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>>>>> And once again we blame the language for the incompetence (or just plain
>>>>> laziness) of the programmers.
>>>>    That's like blaiming the carpenter who loses his hand to a circular
>>>>    saw without a blade guard.  The saw should have had the blade guard.
>>>>
>>> Yes but the carpenter should not have used a power saw without a blade 
>>> guard.  You may remove or disable blade guards for your convenience but 
>>> if you do you deserve whatever happens to you.
>> The analogy between C programming and the blade guard on the saw would
>> make sense to me if we agreed that C programming "guards" are similar
>> to me buying a saw, but having to build my own blade guard to keep
>> safe.
>>
>> In the saw's blade guard example, though, the company that makes the
>> saw designs and implements the blade guard on the product.  There is
>> no such thing for C programming, and instead everyone is left to
>> implement their own safeguards.
> 
> You are assuming the analogy was the guard when in fact it is the proper
> use of the tool.  Using the saw without a guard is improper use.  Writing
> C programs without the proper knowledge of the effects of various actions
> resulting in bad programs is not the languages fault.
> 
> And for those who seem to think this is a C unique problem, I have seen
> numerous overflow problems in both COBOL and Fortran programs.  I have
> even written programs in COBOL to specifically demonstrate that behaviour.
> I have seen programs in Fortran that had wierd "segment violation" (for
> want a better term) errors that just seemed to disappear when a programmer
> inserted PRINT statements into the code to try and debug it.  Anyone care
> to guess why this would happen?  :-)
>


Show me the Fortran code and I can probably figure it out.  I used to do 
that sort of thing for a living 1970-1994.  If you have a WATFOR or 
WATFIV compiler it will probably point out one or more errors in the code.

0
rgilbert88 (4439)
10/8/2009 2:54:06 AM
In article <pMWdnUsa5dUmyVDXnZ2dnUVZ_sOdnZ2d@giganews.com>,
	"Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> Bill Gunshannon wrote:
>> In article <nuvpc5ppo1sdropbtajvfdas7t7l6i5mbk@4ax.com>,
>> 	jls <notvalid@yahoo.com> writes:
>>> On Mon, 05 Oct 2009 14:48:02 -0400, "Richard B. Gilbert"
>>> <rgilbert88@comcast.net> wrote:
>>>
>>>> Bob Koehler wrote:
>>>>> In article <7ire14F32vm9nU2@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>>>>>> And once again we blame the language for the incompetence (or just plain
>>>>>> laziness) of the programmers.
>>>>>    That's like blaiming the carpenter who loses his hand to a circular
>>>>>    saw without a blade guard.  The saw should have had the blade guard.
>>>>>
>>>> Yes but the carpenter should not have used a power saw without a blade 
>>>> guard.  You may remove or disable blade guards for your convenience but 
>>>> if you do you deserve whatever happens to you.
>>> The analogy between C programming and the blade guard on the saw would
>>> make sense to me if we agreed that C programming "guards" are similar
>>> to me buying a saw, but having to build my own blade guard to keep
>>> safe.
>>>
>>> In the saw's blade guard example, though, the company that makes the
>>> saw designs and implements the blade guard on the product.  There is
>>> no such thing for C programming, and instead everyone is left to
>>> implement their own safeguards.
>> 
>> You are assuming the analogy was the guard when in fact it is the proper
>> use of the tool.  Using the saw without a guard is improper use.  Writing
>> C programs without the proper knowledge of the effects of various actions
>> resulting in bad programs is not the languages fault.
>> 
>> And for those who seem to think this is a C unique problem, I have seen
>> numerous overflow problems in both COBOL and Fortran programs.  I have
>> even written programs in COBOL to specifically demonstrate that behaviour.
>> I have seen programs in Fortran that had wierd "segment violation" (for
>> want a better term) errors that just seemed to disappear when a programmer
>> inserted PRINT statements into the code to try and debug it.  Anyone care
>> to guess why this would happen?  :-)
>>
> 
> 
> Show me the Fortran code and I can probably figure it out.  I used to do 
> that sort of thing for a living 1970-1994.  If you have a WATFOR or 
> WATFIV compiler it will probably point out one or more errors in the code.
 
Sorry, that was almost 30 years ago when I, too, was doing it for
living.  It was  Fortran IV on a Univac 1100 running Exec-8.  Of
course, the programs in question were also proof that it is not
only C that gets used for the wrong purposes.  These were business
applications written in Fortran by engineers who needed something
to doto keep them busy during slow summers.  Fortran was the only
language they knew.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
10/8/2009 4:36:57 AM
On 2009-10-08, Bill Gunshannon <billg999@cs.uofs.edu> wrote:
> It was  Fortran IV on a Univac 1100 running Exec-8.  Of
> course, the programs in question were also proof that it is not
> only C that gets used for the wrong purposes.  These were business
> applications written in Fortran by engineers who needed something
> to doto keep them busy during slow summers. 

A friend of mine wrote a compiler in Microsoft's FORTRAN for CP/M.
-- 
roger ivie
rivie@ridgenet.net
0
rivie (670)
10/8/2009 5:21:27 AM
Bill Gunshannon wrote:
> In article <pMWdnUsa5dUmyVDXnZ2dnUVZ_sOdnZ2d@giganews.com>,
> 	"Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>> Bill Gunshannon wrote:
>>> In article <nuvpc5ppo1sdropbtajvfdas7t7l6i5mbk@4ax.com>,
>>> 	jls <notvalid@yahoo.com> writes:
>>>> On Mon, 05 Oct 2009 14:48:02 -0400, "Richard B. Gilbert"
>>>> <rgilbert88@comcast.net> wrote:
>>>>
>>>>> Bob Koehler wrote:
>>>>>> In article <7ire14F32vm9nU2@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>>>>>>> And once again we blame the language for the incompetence (or just plain
>>>>>>> laziness) of the programmers.
>>>>>>    That's like blaiming the carpenter who loses his hand to a circular
>>>>>>    saw without a blade guard.  The saw should have had the blade guard.
>>>>>>
>>>>> Yes but the carpenter should not have used a power saw without a blade 
>>>>> guard.  You may remove or disable blade guards for your convenience but 
>>>>> if you do you deserve whatever happens to you.
>>>> The analogy between C programming and the blade guard on the saw would
>>>> make sense to me if we agreed that C programming "guards