In this desert land ... 3B1 hints...

[supervinx]

At last !
I got the mouse (thanks to G.H. !)!

Now I'm playing a little with the 3B1.

It has a "reduced" 3.0INTL.
Some commands are missing (this is not unreasonable, 20MB of HD are a
limited amount of space...)

The 3B1 started with a custom menu (they duplicated the .profile in every
account...).

The system is not very stable, sometimes the window manager hangs,
or the echo disappears, or the all the lines become underlined ...

I removed the custom menu from the .profile and tried to install some
additional software (gzip, tar, mtools). Gnuplot ends with a segmentation
faults every time I call a builtin function.
gcc needs /usr/include files, which aren't there.

There's a Ryan McFarland Cobol compiler.

The install and tutor directories are complete.

I'm not planning a full backup (how many floppies ? Too many...),
so I'm thinking about reinstalling, may be a 3.5.

There are some things that I must know, before reinstalling ?

BTW, the 3B1 starts with some windowed messages, then a textual login and a
textual shell. It's correct or something else is missing ?


--
http://www.supervinx.com/Retrocomputer

[Dave McGuire]

On 01/13/2013 09:08 AM, supervinx wrote:
> At last !
> I got the mouse (thanks to G.H. !)!
>
> Now I'm playing a little with the 3B1.

Excellent. These are grand little machines.

> It has a "reduced" 3.0INTL.
> Some commands are missing (this is not unreasonable, 20MB of HD are a
> limited amount of space...)

In my teen years, when the 3B1/7300 was new, I worked at a retail
computer store that sold and serviced those machines. The very first
one we got had a 10MB disk, and it easily held everything except (if I
recall correctly) the development kit.

> There's a Ryan McFarland Cobol compiler.

Hmmm, I wonder if that's been archived anywhere.

> BTW, the 3B1 starts with some windowed messages, then a textual login and a
> textual shell. It's correct or something else is missing ?

That's correct. Normally the windowing system ("ua", User Agent)
would be started after login, but the login itself is textual.

-Dave

--
Dave McGuire, AK4HZ
New Kensington, PA

[David B. Horvath, CCP]

In article <kcuf51$dag$1...@tdi.cu.mi.it>, nes...@libero.it says...

>
>There's a Ryan McFarland Cobol compiler.
>

I have a copy of that with manuals and floppies (no idea how good they are).
I hung onto it after divesting of all my other 3b1/7300 because a former co-
worker asked me to hold onto it for them. Well, I never heard from them
again. So I'd love to find a good home for them.

- David

--
David B. Horvath, CCP
Consultant, International Lecturer, Adjunct Professor
Author of "UNIX for the Mainframer" and other books.
*** remove "nosuch" when replying ***

[supervinx]

Il Tue, 05 Feb 2013 00:16:50 +0000, David B. Horvath, CCP ha scritto:

> In article <kcuf51$dag$1...@tdi.cu.mi.it>, nes...@libero.it says...
>>
>>There's a Ryan McFarland Cobol compiler.
>>
>>
> I have a copy of that with manuals and floppies (no idea how good they
> are). I hung onto it after divesting of all my other 3b1/7300 because a
> former co- worker asked me to hold onto it for them. Well, I never heard
> from them again. So I'd love to find a good home for them.
>
> - David

Where do you live ? Better, how far do you live ? ;)
My address is
supervinx
@
libero.it

(So you can guess, I live in Italy...)



--
http://www.supervinx.com/Retrocomputer

[Dave McGuire]

On 02/04/2013 07:16 PM, David B. Horvath, CCP wrote:
>> There's a Ryan McFarland Cobol compiler.
>
> I have a copy of that with manuals and floppies (no idea how good they are).
> I hung onto it after divesting of all my other 3b1/7300 because a former co-
> worker asked me to hold onto it for them. Well, I never heard from them
> again. So I'd love to find a good home for them.

I wouldn't mind that at all. I am (slowly) building what will be a
public computer museum here in Pittsburgh. You're in the Philly area?

[Thad Floryan]

On 2/11/2013 5:30 PM, Dave McGuire wrote:
> On 02/04/2013 07:16 PM, David B. Horvath, CCP wrote:
>>> There's a Ryan McFarland Cobol compiler.
>> I have a copy of that with manuals and floppies (no idea how good they are).

>> [...[
>[...]

Interesting article referenced in today's Slashdot:

<http://www.itworld.com/career/341879/cobol-will-outlive-us-all>

:-)

Thad

[Dave McGuire]

On 02/14/2013 05:12 PM, Thad Floryan wrote:
>>>> There's a Ryan McFarland Cobol compiler.
>>> I have a copy of that with manuals and floppies (no idea how good they are).
>>> [...[
>> [...]
>
> Interesting article referenced in today's Slashdot:
>
> <http://www.itworld.com/career/341879/cobol-will-outlive-us-all>
>
> :-)

How deeply terrifying. 8-|

[Bill Gunshannon]

In article <kfkbht$2bv$1...@mail.neurotica.com>,

Dave McGuire <mcg...@neurotica.com> writes:
> On 02/14/2013 05:12 PM, Thad Floryan wrote:
>>>>> There's a Ryan McFarland Cobol compiler.
>>>> I have a copy of that with manuals and floppies (no idea how good they are).
>>>> [...[
>>> [...]
>>
>> Interesting article referenced in today's Slashdot:
>>
>> <http://www.itworld.com/career/341879/cobol-will-outlive-us-all>
>>
>> :-)
>
> How deeply terrifying. 8-|
>

OK, I have to ask.... Why?

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Dave McGuire]

On 02/15/2013 07:50 AM, Bill Gunshannon wrote:
>>> Interesting article referenced in today's Slashdot:
>>>
>>> <http://www.itworld.com/career/341879/cobol-will-outlive-us-all>
>>>
>>> :-)
>>
>> How deeply terrifying. 8-|
>>
>
> OK, I have to ask.... Why?

Hi Bill!! It's nice to see you here.

(yes I owe you a reply, busy week!)

As to why it's terrifying...I just don't particuarly like COBOL; I
find it to be horrifically "unclean". Powerful, important, and
ubiquitous, yes, but unclean. ;)

[Thad Floryan]

On 2/25/2013 6:35 PM, Dave McGuire wrote:
> [...]

> As to why it's terrifying...I just don't particuarly like COBOL; I
> find it to be horrifically "unclean". Powerful, important, and
> ubiquitous, yes, but unclean. ;)

FWIW, Googling "GNU COBOL" reveals:

<http://cobolforgcc.sourceforge.net/>

<http://www.opencobol.org/>

<http://savannah.gnu.org/projects/cobol>

<http://administratosphere.wordpress.com/tag/gnu-cobol/>

<http://directory.fsf.org/wiki/COBOL_for_gcc>

and many, many more. :-)

FWIW, I've written only 2 COBOL programs since I began using computers
in the 1960s and both programs were solely to test the compiler I had
installed at a client site. At that time I was programming mostly in
assembler on a large variety of systems.

A number of years ago I read something about a runtime speed test
between COBOL and FORTRAN on some system and COBOL won hands down.
As I recall, the rationale for COBOL being faster was due to its
code optimizations given the sheer volume of data that's processed
worldwide using COBOL.

Just now Googling "speed test cobol versus fortran" finds a bunch.
I found this snippet to be VERY interesting:

<http://en.wikipedia.org/wiki/Cobol#Legacy>
"
" COBOL programs are in use globally in governmental and military
" agencies, in commercial enterprises, and on operating systems
" such as IBM's z/OS, Microsoft's Windows, and the POSIX families
" (Unix/Linux etc.). In 1997, the Gartner Group reported that 80%
" of the world's business ran on COBOL with over 200 billion lines
" of code in existence and with an estimated 5 billion lines of new
" code annually.

Thad

[Bill Gunshannon]

In article <kgh724$t0a$1...@mail.neurotica.com>,

Dave McGuire <mcg...@neurotica.com> writes:
> On 02/15/2013 07:50 AM, Bill Gunshannon wrote:
>>>> Interesting article referenced in today's Slashdot:
>>>>
>>>> <http://www.itworld.com/career/341879/cobol-will-outlive-us-all>
>>>>
>>>> :-)
>>>
>>> How deeply terrifying. 8-|
>>>
>>
>> OK, I have to ask.... Why?
>
> Hi Bill!! It's nice to see you here.
>
> (yes I owe you a reply, busy week!)
>
> As to why it's terrifying...

Clowns are terrifying. Stephan King is terrifying. COBOL is just
another programming language designed for a specific domain. Hardly
anything there to be terrifying.

> I just don't particuarly like COBOL;

That's another matter entirely. I don't like a lot of languages
but I have technical reasons for that dislike and the only thing
terrifying about it is that other people still use them even with
those serious (and often security related) problems.

> I
> find it to be horrifically "unclean". Powerful, important, and
> ubiquitous, yes, but unclean. ;)

Can't imagine aht would be considered "unclean" in any language
much less COBOL. If there was an "unclean" language I would think
it was PHP.

[Bill Gunshannon]

In article <512C3F7F...@thadlabs.com>,

Thad Floryan <th...@thadlabs.com> writes:
> On 2/25/2013 6:35 PM, Dave McGuire wrote:
>> [...]
>> As to why it's terrifying...I just don't particuarly like COBOL; I
>> find it to be horrifically "unclean". Powerful, important, and
>> ubiquitous, yes, but unclean. ;)
>
> FWIW, Googling "GNU COBOL" reveals:
>
> <http://cobolforgcc.sourceforge.net/>
>
> <http://www.opencobol.org/>
>
> <http://savannah.gnu.org/projects/cobol>
>
> <http://administratosphere.wordpress.com/tag/gnu-cobol/>
>
> <http://directory.fsf.org/wiki/COBOL_for_gcc>
>
> and many, many more. :-)

And if you read them you would find that most are dated more than a
decade ago as that is how long GNU COBOL has been dead.

But there have been others and OpenCOBOL is actually quite good.
Too bad WATBOL never got released to the Open Source world.

>
> FWIW, I've written only 2 COBOL programs since I began using computers
> in the 1960s and both programs were solely to test the compiler I had
> installed at a client site. At that time I was programming mostly in
> assembler on a large variety of systems.
>
> A number of years ago I read something about a runtime speed test
> between COBOL and FORTRAN on some system and COBOL won hands down.
> As I recall, the rationale for COBOL being faster was due to its
> code optimizations given the sheer volume of data that's processed
> worldwide using COBOL.
>
> Just now Googling "speed test cobol versus fortran" finds a bunch.
> I found this snippet to be VERY interesting:
>
> <http://en.wikipedia.org/wiki/Cobol#Legacy>
> "
> " COBOL programs are in use globally in governmental and military
> " agencies, in commercial enterprises, and on operating systems
> " such as IBM's z/OS, Microsoft's Windows, and the POSIX families
> " (Unix/Linux etc.). In 1997, the Gartner Group reported that 80%
> " of the world's business ran on COBOL with over 200 billion lines
> " of code in existence and with an estimated 5 billion lines of new
> " code annually.
>

Interesting considering that speed was never a particular target of
COBOL. BUt then, it wasn't for Fortran either, I guess.

[Thad Floryan]

On 2/26/2013 5:13 AM, Bill Gunshannon wrote:
> In article <512C3F7F...@thadlabs.com>,
> Thad Floryan <th...@thadlabs.com> writes:

>> [...]

>> FWIW, I've written only 2 COBOL programs since I began using computers
>> in the 1960s and both programs were solely to test the compiler I had
>> installed at a client site. At that time I was programming mostly in
>> assembler on a large variety of systems.
>>
>> A number of years ago I read something about a runtime speed test
>> between COBOL and FORTRAN on some system and COBOL won hands down.
>> As I recall, the rationale for COBOL being faster was due to its
>> code optimizations given the sheer volume of data that's processed
>> worldwide using COBOL.
>>
>> Just now Googling "speed test cobol versus fortran" finds a bunch.
>> I found this snippet to be VERY interesting:
>>
>> <http://en.wikipedia.org/wiki/Cobol#Legacy>

>> [...]

>
> Interesting considering that speed was never a particular target of
> COBOL. BUt then, it wasn't for Fortran either, I guess.

Hi Bill,

Compilers of the 1960s and 1970s didn't have the optimizations we find
in today's products which is why many of us coded large database systems
in assembly language as I did for PDP-10s, XDS-940s, Xerox Sigma series,
CDC 3300s, Burroughs B5500s, VAXen, DECsystem-20s, etc. for the speed
and tricks that could be performed (esp. on PDP-10s and DECsystems).

Another factoid I remember from the COBOL vs. Fortran speed test article
was the "better" compiler designers were assigned to the COBOL compiler
due to efficiencies needed given the massive amounts of data processed
by programs written in COBOL.

I have no real interest in COBOL other than musing it's still widely
used. Nowadays (and for some time now) I program in C. One of my
programs, tprobe, was really popular:

<http://drdobbs.com/184402700> search for 'tprobe' on that page

The shortest URL I can find for an archive of tprobe is this one:

<http://ae-www.technion.ac.il/pkgs/g-k/in/tprobe/tprobe>

since comp.sources.unix and most of its archives vanished. I can't
even find an archive for my ftimes program so I placed it here
which displays fine using Firefox and presumably other browsers
(and feel welcome to download and use it; instructions at the
beginning of the file and via 'ftimes -h'):

<http://thadlabs.com/FILES/ftimes.c> 7kB

I didn't write a man page for it because doing so would have taken
about 2-3 times longer than designing and coding the program as it
did for tprobe. I'm still looking for a "better" way of creating
man pages and I'm persuing several leads I found yesterday.

ftimes really came in handy when I was recently experimenting with
the Open Indiana clone of Solaris 11 because it wasn't clear what
grub menu.lst file was actually being used so I could modify it for
a multi-boot system. Given the ZFS file system, the choices were
/boot/grub/menu.lst and /rpool/boot/grub/menu.lst. Turns out it was
the /rpool one (based on ftimes revealing the 'access' time) so I
could add the following lines to it to begin the system build with
several internal disks:

title Windows 7 Service Pack 1
rootnoverify (hd1,0)
chainloader +1

and everything worked fine.

Thad

[DoN. Nichols]

On 2013-02-26, Thad Floryan <th...@thadlabs.com> wrote:

[ ... ]

> Compilers of the 1960s and 1970s didn't have the optimizations we find
> in today's products which is why many of us coded large database systems
> in assembly language as I did for PDP-10s, XDS-940s, Xerox Sigma series,
> CDC 3300s, Burroughs B5500s, VAXen, DECsystem-20s, etc. for the speed
> and tricks that could be performed (esp. on PDP-10s and DECsystems).

I suspect that COBOL came out so well was because it used
decimal arithmetic based on integers, while FORTRAN does a lot of work
with REAL data types (floating point), and trig functions as well.

[ ... ]

> I have no real interest in COBOL other than musing it's still widely
> used. Nowadays (and for some time now) I program in C. One of my
> programs, tprobe, was really popular:
>
> <http://drdobbs.com/184402700> search for 'tprobe' on that page

I remember it well -- and it has saved me several times,
especially back in the Sun-3 days. :-)

Thank You!

> The shortest URL I can find for an archive of tprobe is this one:
>
> <http://ae-www.technion.ac.il/pkgs/g-k/in/tprobe/tprobe>

Worth having, indeed. (Well ... if you have old Sun systems, at
least. :-)

A pity that there were not more SCSI cards made for the 3B1 (was
it you how had it, or one of the other regulars?). I somehow can't
imagine tprobe running on the floppy tape system. (Not that an install
tape was an option anyway -- you had to install the whole OS and the
drivers for the floppy tape before you could use it for anything. :-)

> since comp.sources.unix and most of its archives vanished. I can't
> even find an archive for my ftimes program so I placed it here
> which displays fine using Firefox and presumably other browsers
> (and feel welcome to download and use it; instructions at the
> beginning of the file and via 'ftimes -h'):
>
> <http://thadlabs.com/FILES/ftimes.c> 7kB

Just grabbed it. Thanks.

> I didn't write a man page for it because doing so would have taken
> about 2-3 times longer than designing and coding the program as it
> did for tprobe. I'm still looking for a "better" way of creating
> man pages and I'm persuing several leads I found yesterday.

Remember the documentation system used with Donald Knuth's epic
text formatting program? Merged the documentation and the (Pascal,
IIRC) source.

> ftimes really came in handy when I was recently experimenting with
> the Open Indiana clone of Solaris 11 because it wasn't clear what
> grub menu.lst file was actually being used so I could modify it for
> a multi-boot system. Given the ZFS file system, the choices were
> /boot/grub/menu.lst and /rpool/boot/grub/menu.lst. Turns out it was
> the /rpool one (based on ftimes revealing the 'access' time) so I
> could add the following lines to it to begin the system build with
> several internal disks:
>
> title Windows 7 Service Pack 1
> rootnoverify (hd1,0)
> chainloader +1
>
> and everything worked fine.

I'll have to remember that when I start to play with the Open
Indiana package. A pity it doesn't support UltraSPARC systems. I'm
running the Solaris 10 from before the Oracle takeover, since I do not
like the terms for downloading the later versions.

Enjoy,
DoN.

--
Remove oil spill source from e-mail
Email: <BPdnic...@d-and-d.com> | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

[Dave McGuire]

On 02/26/2013 08:00 PM, DoN. Nichols wrote:
> I'll have to remember that when I start to play with the Open
> Indiana package. A pity it doesn't support UltraSPARC systems. I'm
> running the Solaris 10 from before the Oracle takeover, since I do not
> like the terms for downloading the later versions.

OpenIndiana does indeed support SPARC! I have it running right now on
a V480 and a T2000.

A very dedicated guy named Martin Bochnig sacrificed practically
everything in his personal life in order to bring it into being. An
installable DVD image was released a few weeks ago.

I (currently) depend on Solaris 10...I share your reservations about
Oracle. They're really making a mess of things, and they don't seem to
understand how or why.

-Dave

--
Dave McGuire
Port Charlotte, FL

[Bill Gunshannon]

In article <512D49A...@thadlabs.com>,

Speed was never a serious concern in my early COBOL (or Fortran) days
(Univac-1100) but I had a boss who wrote a complete screen placement
package for COBOL on that 1100 in ASM.

>
> Another factoid I remember from the COBOL vs. Fortran speed test article
> was the "better" compiler designers were assigned to the COBOL compiler
> due to efficiencies needed given the massive amounts of data processed
> by programs written in COBOL.

LIke I said, in my experience neither speed nor true efficiency was ever
a real concern. One of the places I did COBOL even looked into a high
level COBOL generator package to add yet another layer of abstraction
in the mix (1981-1982 timeframe). Thankfully, it was resoundingly
rejected by all my peers. But not for efficiency reasons. :-)

>
> I have no real interest in COBOL other than musing it's still widely
> used. Nowadays (and for some time now) I program in C. One of my
> programs, tprobe, was really popular:
>
> <http://drdobbs.com/184402700> search for 'tprobe' on that page
>
> The shortest URL I can find for an archive of tprobe is this one:
>
> <http://ae-www.technion.ac.il/pkgs/g-k/in/tprobe/tprobe>
>
> since comp.sources.unix and most of its archives vanished. I can't
> even find an archive for my ftimes program so I placed it here
> which displays fine using Firefox and presumably other browsers
> (and feel welcome to download and use it; instructions at the
> beginning of the file and via 'ftimes -h'):
>
> <http://thadlabs.com/FILES/ftimes.c> 7kB
>

http://ftp.sunet.se/pub/usenet/ftp.uu.net/comp.sources.unix/

> I didn't write a man page for it because doing so would have taken
> about 2-3 times longer than designing and coding the program as it
> did for tprobe. I'm still looking for a "better" way of creating
> man pages and I'm persuing several leads I found yesterday.

Surely you don't find nroff all that difficult!! :-)

>
> ftimes really came in handy when I was recently experimenting with
> the Open Indiana clone of Solaris 11 because it wasn't clear what
> grub menu.lst file was actually being used so I could modify it for
> a multi-boot system. Given the ZFS file system, the choices were
> /boot/grub/menu.lst and /rpool/boot/grub/menu.lst. Turns out it was
> the /rpool one (based on ftimes revealing the 'access' time) so I
> could add the following lines to it to begin the system build with
> several internal disks:
>
> title Windows 7 Service Pack 1
> rootnoverify (hd1,0)
> chainloader +1
>
> and everything worked fine.
>

Solaris 11?? Guess I have been away from that sector for a while now.
I think 8 or 9 was the last I tried. Now, where did I leave that Ultra
Sparc. :-)

[David B. Horvath, CCP]

In article <kfc5vh$dbm$1...@mail.neurotica.com>, mcg...@neurotica.com says...

I *am* in the Philly area. Tell me more about your museum (email would be my
preference, I don't check netnews that often any more).

[DoN. Nichols]

On 2013-02-27, Dave McGuire <mcg...@neurotica.com> wrote:
> On 02/26/2013 08:00 PM, DoN. Nichols wrote:
>> I'll have to remember that when I start to play with the Open
>> Indiana package. A pity it doesn't support UltraSPARC systems. I'm
>> running the Solaris 10 from before the Oracle takeover, since I do not
>> like the terms for downloading the later versions.
>
> OpenIndiana does indeed support SPARC! I have it running right now on
> a V480 and a T2000.

Oh! Good news! I appear to have found the wrong web page for
it, as there was mention only of the X86 flavor.

> A very dedicated guy named Martin Bochnig sacrificed practically
> everything in his personal life in order to bring it into being. An
> installable DVD image was released a few weeks ago.

Great! (The result -- not his sacrifice.)

Do you have the URL handy?

(And how about getting it on the 3B1 to keep on topic? :-)

Somehow -- I don't think that will happen with a max of 4 MB of
RAM -- or virtual memory. :-) I don't even think that SunOs 4.1.1 (the
last BSD flavored os for the Sun 3 machines (Motorola 68020 -- for
those who don't know -- I'm *sure* that you know).

> I (currently) depend on Solaris 10...I share your reservations about
> Oracle. They're really making a mess of things, and they don't seem to
> understand how or why.

They like to control things too tightly. Like the requirement
that you have a service contract to move to a newer version of Solaris
-- other than for a one month trial run. No exceptions for hobby users,
which is certainly what I am. It is killing off the SPARC in my
opinion.

[Thad Floryan]

It's nice we're seeing some activity in this group after a
l-o-n-g hiatus! :-)

On 2/27/2013 5:01 PM, DoN. Nichols wrote:
> [...]

> Somehow -- I don't think that will happen with a max of 4 MB of
> RAM -- or virtual memory. :-) I don't even think that SunOs 4.1.1 (the
> last BSD flavored os for the Sun 3 machines (Motorola 68020 -- for
> those who don't know -- I'm *sure* that you know).

> [...]

Hi Don,

I'm not sure what you were implying about the Sun 3 machines
above.

I still have several Sun-3/60 "pizza box" systems here that
work fine and they all have 24MB RAM. See:

<http://en.wikipedia.org/wiki/Sun-3>

Actually. the last BSD-flavored Sun was SunOS 4.1.4
aka Solaris 1.1.2. Looking at the back of the box right
now it reads:

Welcome to Solaris 1.1.2. Solaris 1.1.12 includes
both SunOS 4.1.4 and bug fixes for OpenWindows version 3.

Solaris 1.1.2 includes the following features:

- Integrated support for the performance-enhanced Sun
HyperSPARC CPU module on MBus, uniprocessor
SPARCStation10 and SPARCStation20 systems

- Integrated improvements to support SPARCStation5
including audio support and cg6 framebuffer support

- A software upgrade from SunOS 4.1.x to SunOS 4.1.4
and an updated version of OpenWindows containing over
75 of the latest OpenWindows bug fixes

- Integration of over 100 key operating system bug fixes
to the Solaris 1.1.1 version B release

The box is 3" thick and packed with manuals and CDs. This
is for the SPARC systems -- I have a bunch of IPXs in addition
to SS10 and SS20 and several clones thereof.

I seem to recall, but wouldn't swear, I have SunOS 4.1.4 on
the Sun-3/60 systems also but it's not equivalently listed
as Solaris -- the "Solaris" appellation was strictly for
the SPARC machines -- and I'll have to check my closet storage
for the SunOS tapes to verify the last Sun-3 version.

Thad

[DoN. Nichols]

On 2013-02-28, Thad Floryan <th...@thadlabs.com> wrote:
> It's nice we're seeing some activity in this group after a
> l-o-n-g hiatus! :-)

Even if we are cheating by talking about Suns. :-)

> On 2/27/2013 5:01 PM, DoN. Nichols wrote:
>> [...]
>> Somehow -- I don't think that will happen with a max of 4 MB of
>> RAM -- or virtual memory. :-) I don't even think that SunOs 4.1.1 (the
>> last BSD flavored os for the Sun 3 machines (Motorola 68020 -- for
>> those who don't know -- I'm *sure* that you know).
>> [...]
>
> Hi Don,
>
> I'm not sure what you were implying about the Sun 3 machines
> above.

Sun-3 was 68020, which should be mostly compatible with the
68010 on the 3B1 family. *But* Sun (like the 3B1, but different) have
their own design of memory management hardware -- so the memory
management for SunOs 4.1.1 would have to be re-written to use the 3B1's
memory management. (And the Sun-3 family could use up to at least 64 MB
of RAM (for the VME based systems, at least.)

> I still have several Sun-3/60 "pizza box" systems here that
> work fine and they all have 24MB RAM. See:
>
> <http://en.wikipedia.org/wiki/Sun-3>

Right -- which is *quite* a bit more than the 4MB max of the
3B1/7300/Unix-PC. IIRC, the 3/60 could use either 24 MB of 1MB SIMMs,
or 6MB of 256K SIMMs.

> Actually. the last BSD-flavored Sun was SunOS 4.1.4
> aka Solaris 1.1.2.

Right -- but that was for the Sun4 (SPARC) world, not the Sun3
(68020).

I've still got the CD-ROM for installing 4.1.4 on SPARC systems.

> Looking at the back of the box right
> now it reads:
>
> Welcome to Solaris 1.1.2. Solaris 1.1.12 includes
> both SunOS 4.1.4 and bug fixes for OpenWindows version 3.

[ ... ]

> The box is 3" thick and packed with manuals and CDs. This
> is for the SPARC systems -- I have a bunch of IPXs in addition
> to SS10 and SS20 and several clones thereof.
>
> I seem to recall, but wouldn't swear, I have SunOS 4.1.4 on
> the Sun-3/60 systems also but it's not equivalently listed
> as Solaris

I believe not. Sun stopped the Sun3 OS line with 4.1.1B (a
"Jumbo" patch), which fixed a lot of things, but not one particular bug
for the Sun3 4.1.1. That bug was a problem in the SCSI disk drivers.
IIRC, it was at the threshold of 2GB that the problem hit. It worked
fine for most things, but when it came time to swap in a substitute for
a bad block, it used a lower level of the write command which topped out
at 2GB. The result would be that if you had (say) a 4GB drive, and it
originally formatted fine, you were fine until a bad block needed to be
substituted. At that point, it would point to one of the (typically
two) cylinders of spare blocks, and try to write to that instead of the
bad one. But the upper bits of the block address were cut off, so it
would overwrite someplace in the lower 2GB of the disk. A real pain to
diagnose, until you knew what was happening. *And* -- it was most
likely going to corrupt crucial system files, not user data. :-)

They included a fix for this in the SPARC Jumbo patch for 4.1.1,
but not the Sun3 Jumbo patch.

As far as I know, this was to encourage people to move to the
SPARC line, and the Sun3 line was EOL'd. They also said that anyone who
could get or copy the media for the Sun3 OS was free to use it on other
Sun3 machines. (Not exactly the way Oracle plays. :-)

> -- the "Solaris" appellation was strictly for
> the SPARC machines -- and I'll have to check my closet storage
> for the SunOS tapes to verify the last Sun-3 version.

If you can find anything past 4.1.1B in the Sun3 line, I will
feel that you have accomplished a miracle. :-)

BTW I used to compile tprobe with a maximum blocking (63k, 126b) in
the interests of speed and efficiency. A pity that it did not
have a way to encode the blocking at the beginning of the data
stream. I was in the habit of saving a file image of each tape,
including the 4.1.1 and the Jumbo patch therefor.

Thanks again,

[Dave McGuire]

On 02/27/2013 08:45 PM, Thad Floryan wrote:
> I seem to recall, but wouldn't swear, I have SunOS 4.1.4 on
> the Sun-3/60 systems also but it's not equivalently listed
> as Solaris -- the "Solaris" appellation was strictly for
> the SPARC machines -- and I'll have to check my closet storage
> for the SunOS tapes to verify the last Sun-3 version.

Hi! Nope...The last release of SunOS for Sun3 machines was 4.1.1_U1.
The last release (BSD-based) for SPARC was 4.1.4_U1.

[Dave McGuire]

On 02/27/2013 06:21 PM, David B. Horvath, CCP wrote:
>>>> There's a Ryan McFarland Cobol compiler.
>>>
>>> I have a copy of that with manuals and floppies (no idea how good they
> are).
>>> I hung onto it after divesting of all my other 3b1/7300 because a former
> co-
>>> worker asked me to hold onto it for them. Well, I never heard from them
>>> again. So I'd love to find a good home for them.
>>
>> I wouldn't mind that at all. I am (slowly) building what will be a
>> public computer museum here in Pittsburgh. You're in the Philly area?
>

> I *am* in the Philly area. Tell me more about your museum (email would be my
> preference, I don't check netnews that often any more).

Private reply sent.

[DoN. Nichols]

Since we have a number of Sun-using people here, I'll take a
chance and ask.

I recently got a Sun StorEdge T3+ RAID disk array -- Fibre
Channel disks and interface to the computer.

It has two redundant power supplies, each with a rechargeable
battery installed to keep it running long enough to flush to disk after
a power failure.

They really want those batteries to work, so they have a time
fuse on them -- starting from the day the power supply is installed, and
at the end of two years, they declare themselves as "failed". One is
failed now, and the other on the 9th of this month.

I have a battery pack on order to replace the one in the power
supply, and once it is installed, I plan to rebuild the old battery pack
and put it into the other power supply.

One problem though -- Sun expected most to swap power supplies
to swap batteries (and I think the expiration date is recorded in the
power supply somewhere, not in the system's own memory.) The
maintenance manual tells how to physically replace the battery in the
power supply (four screws, disconnect a connector inside, put in the new
one and reinstall screws and then power supply). Needless to say, I
can't get a service contract on this (I didn't buy it direct from Sun or
from Oracle), and the actual cost of the unit (with 9 36 GB FC-AL drives
installed and working) was *free* -- given to me at a hamfest.

The problem with replacing the batteries inside the power
supplies is that the system has no way of knowing that the battery is
new. (20 NiMH Sub-C cells, FWIW).

There is a way to reset the time after swapping the batteries.
But it requires using the ".bat" command. This command, as with all
other commands starting with '.', is locked out so the unit's OS claims
that it does not recognize the command. What is needed is a way to tell
the OS that it is legal to recognize the commands. (Looking at the
binary of the OS, I find all the dot commands listed, so I know that
they are in there.

I know that to reset the password (null out the root password),
it has to be interrupted in the early stages of booting, and then the
command "set flags " and a long hex number -- 0x4 and a bunch of zeros.
This causes it to reset the password to a null one during booting, so
you can set a new one which you know. :-)

I'm presuming that a variant of this is what is needed, but what
value should be set is not clear. I've tried everything from 0x8(plus
all those zeros) down through 0x1 and it does not work. So it needs to
be a combination of more than one bit set. (I also tried 0xffffffff)
and nothing works.

So -- I'm hoping that someone here knows the magic number which
will allow me to make this work -- and make it worth while putting in
180 GB drives instead of the 36 GB drives.

Oh yes -- I had to take compressed air to it to clean out all
the dust of the ages, but it is now clean and runs fine other than the
battery problem. (And yes, I could just plug it into a UPS with the
rest of the servers in my collection, but as long as it thinks that it
is depending on failed batteries, it sets the cache to write-through
instead of write-behind -- so is is slower.

BTW -- one search of a discussion forum on Oracle's site says
that the magic code is in the "Field Enginner's SEE", but I have not h
heard of this before -- let alone seen one.

Apparently, if I had an older version of the firmware, I could
access the ".bat" command directly -- but with the current version:

T3B Release 3.2.6 Mon Feb 5 01:00:35 MST 2007

things are tighter. (Apparently, from experience, they have also reset
the battery expire time to 36 months instead of 24 months, which
suggests an even later version of the firmware. :-)

Thanks to anyone who can help me.

[Dave McGuire]

On 03/06/2013 12:25 AM, DoN. Nichols wrote:
>> Hi! Nope...The last release of SunOS for Sun3 machines was 4.1.1_U1.
>> The last release (BSD-based) for SPARC was 4.1.4_U1.
>
> Since we have a number of Sun-using people here, I'll take a
> chance and ask.
>
> I recently got a Sun StorEdge T3+ RAID disk array -- Fibre
> Channel disks and interface to the computer.
>

...

> There is a way to reset the time after swapping the batteries.
> But it requires using the ".bat" command. This command, as with all
> other commands starting with '.', is locked out so the unit's OS claims
> that it does not recognize the command. What is needed is a way to tell
> the OS that it is legal to recognize the commands. (Looking at the
> binary of the OS, I find all the dot commands listed, so I know that
> they are in there.

The "dot commands" are enabled by typing "sun" command, which will
prompt you for a password. If you enter that correctly, the dot
commands will be enabled. I don't know that password, but I'm pretty
sure it's static and not resettable. I am trying to contact an old
friend who worked at Sun during the T3's heyday to see if he knows it.
I'd be surprised if he didn't. I will post again when I learn more.

[DoN. Nichols]

On 2013-03-09, Dave McGuire <mcg...@neurotica.com> wrote:
> On 03/06/2013 12:25 AM, DoN. Nichols wrote:
>>> Hi! Nope...The last release of SunOS for Sun3 machines was 4.1.1_U1.
>>> The last release (BSD-based) for SPARC was 4.1.4_U1.
>>
>> Since we have a number of Sun-using people here, I'll take a
>> chance and ask.
>>
>> I recently got a Sun StorEdge T3+ RAID disk array -- Fibre
>> Channel disks and interface to the computer.
>>
> ...
>> There is a way to reset the time after swapping the batteries.
>> But it requires using the ".bat" command. This command, as with all
>> other commands starting with '.', is locked out so the unit's OS claims
>> that it does not recognize the command. What is needed is a way to tell
>> the OS that it is legal to recognize the commands. (Looking at the
>> binary of the OS, I find all the dot commands listed, so I know that
>> they are in there.
>
> The "dot commands" are enabled by typing "sun" command, which will
> prompt you for a password.

I finally figured that out, and started on a search for the
password for that.

> If you enter that correctly, the dot
> commands will be enabled. I don't know that password, but I'm pretty
> sure it's static and not resettable. I am trying to contact an old
> friend who worked at Sun during the T3's heyday to see if he knows it.
> I'd be surprised if he didn't. I will post again when I learn more.

I actually figured out where to find it, after reading that it
was supposed to be in the "SEE" book (which I had not previously thought
of.) Then I decided to go deeper into the _Sun System Handbook_ CD from
April 2005 (which replaced the Field Engineer's Handbook which was in
dead-tree format).

I went into the "search" part, and typed the maximum number of
search terms allowed (three) as "t3+", ".bat", and "password", and got
about a dozen papers of which at least three contained the password, and
several others some otherwise quite useful information.

Intersting was the annotation beside each mention of the
password. "Under no circumstances give this password to customers!" :-)

FWIW, I went through the binary of the OS with strings, and did
not find the password string in there at all -- so it is hashed in some
way. Not sure how secure it is, so I'm using a different root password
in that machine -- especially since it does not allow me to ssh into it,
just ftp and telnet, so the password is exposed on the local net (unless
I go through the serial port, after ssh connecting to the system to
which that serial port is connected. :-)

I've now got two batteries in there which pass the refresh/test
cycle (and am going to order a bunch of Sub-C NiMH cells to make spares
for a year or two downstream). And I now have a zfs on the single large
filesystem/virtual disk and am copying from another ZFS true raidz2
array with a failed drive which I have not yet been able to replace.
This will give me a bit more freedom to work on the drives in that array
(a EuroLogic tray, FWIW).

Does anyone else here need/want that password?

Thanks much,