>> The classiccmp server is broken.
>
>Or something is doing horrible things to throttle bandwidth at his new provider.
>I've seen stalls for a minute on ftp wgets (which is how I sync bitsavers),
>lots of random 503's on web accesses, and random POP login failures.
When I access either my site or the mailing list, through the web I get:
------
Service Temporarily Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Apache/2.2.23 (FreeBSD) PHP/5.3.18 with Suhosin-Patch mod_ssl/2.2.23 OpenSSL/0.9.8x DAV/2 Server at www.classiccmp.org Port 80
------
This appears to be a 503 originating at this server.
When I access my site, I see individual 503 errors on many (sometimes most) of the photo link accesses.
I would guess that the wgets fails becase it get s a 503 error, probably not knowing what it means, only that
the accessed failed - and retries until it gets through which is what is taking a minite - (I've sat hear reclicking
links for nearly a minite trying to open a message in the archive).
To me it looks like a server problem.
Dave
--
dave13 (at) Dave Dunfield
dunfield System/Firmware development services: www.dunfield.com
(dot) com Classic computers: http://www.classiccmp.org/dunfield
Dear DG-Addicts,
I am running RDOS (within simh) and I can readily compile
and run Algol programs in this environment. Now want to
compile Algol programs to be loaded stand-alone onto a
8k store machine via paper tape. To do this, a library
called SOS.LB is needed (at least the linker complains, that
it is missing) and so the question is whether some one
out there has already compiled stand alone programs
using RDOS and probably has the SOS.LB for Algol, and
eventually further files required, available?
I already tried to get in touch with people involved in
these web sites
http://www.chookfest.net/nova3/paper-tapes.htmlhttp://www.ludd.luth.se/~ragge/nova/swdocs.html
but so far I have not got hands on the Algol stand alone
stuff. BTW: I do NOT want to use the stand-alone tool
chain, but generate the programs using the RDOS (because
this is more convenient). Any hints are welcome,
best regards,
Erik.
A friend, Gerald Heitel [gheitel at gmail.com], not a member of this group has
an IBM PC Portable in "mint condition" with original manuals and several
software programs, floppy discs, etc. He offered it to the Computer History
Museum, but they said that they already had one in their collection. He is
seeking to contribute to a computer museum or sell to a private collector at
a nominal price.
Contact Gerry directly if interested or can help find a home.
Tom
Hi Guys,
I used to mess about with RSTS/E when I was a kid, and even managed to
get into trouble with ASU and the folks that worked at the remote
sites... banned, basically.
(I went on to work there years later after the PDP11s had been scrapped...)
Anyhow, I've been running one I built from tape with simh for ages...
it's accessible on line via my bbs (telnet bbs.cortex-media.info)
I've got an old, incomplete version of dungeon on there. I've found a
more complete version in Fortran. What is the best way to get the
files onto the emulated disk so I can build it?
Would it be better to install decnet or use kermit or what?
thanks,
John
--
Yoyodyne Propulsion Systems: "The Future Begins Tomorrow"
Visit us at: http://www.yoyodyne-propulsion.net
--------
"Gregor Samsa awoke one morning to discover that he had been
transformed into a giant cockroach." Nah, it's too good.
--Max Bialystock
> > Do either of:
> >
> > $ REPLY /ENABLE
> > $ SHOW ERROR
> >
> > show up any problems? You might need:
> >
> > $ SET TERMINAL /BROADCAST
> >
> > and/or
> >
> > $ SET BROADCAST=ALL
> >
> > with REPLY /ENABLE if you are doing this on the console and something has
> > disabled broadcasts on the console.
>
> Any of these would probably be great, but I should probably be a little
> more clear; it's not really responding at all to input after I respond
> to a prompt. After the carriage return, it just sits there and doesn't
> even echo anything, though as I mentioned, anything running elsewhere
> (like MONITOR) still seems to keep going.
>
It's me who should have been clearer.
Do the REPLY /ENABLE and friends before the problem shows up in the hope of
seeing a message giving details about the problem when it does show up.
You might see something like "Mount verification is in progress." for example.
Do the SHOW ERROR anytime and if anything (other than a tape drive, terminal
or any sort of virtual device) shows a non-zero error count, investigate the
reason for it. Particularly watch for MEMORY or CPU errors. If your disk
device starts clocking errors just before the system stalls, that would tend
to point the finger in its direction.
$ SHOW SYSTEM
is the one command I know of that will usually execute when almost all others
fail due to resource starvation. Using it to look at what states processes
are in will give clues about what resources they might be waiting for.
> > $ SHOW MEMORY /POOL /FULL
> >
> > will give a vast number of figures. If "Free space" is low and "Current size"
> > is much bigger than "Initial size" and approaching "Maximum size", you may be
> > running into problems with non-paged pool.
>
> The free space numbers seem fine and always have, but I haven't run
> it while doing something like an install. I'll have to try that.
> The pool space numbers don't seem terribly large, but I'm not quite
> sure what nominal ones are.
The numbers will vary depending on your hardware and configuration. What
matters is that that "Free space" is not approaching zero when "Current size"
is already as big as "Maximum size" which means there is no scope for further
automatic expansion of the pool size. If you have plenty of free space, you
are ok. If you don't have any free space but "Current size" is less than
"Maximum size", you are still ok.
Another approach to this sort of thing is to crash the system when it becomes
unresponsive and analyse the resultant crash dump afterwards. Probably better
to try the AUTOGEN first though.
Regards,
Peter Coghlan.
It doesn't say if they're free, for sale cheap or what but there is a
goodly stack of IBM documentation available in the Albuquerque area:
http://albuquerque.craigslist.org/bks/3766923247.html
(not mine, not in the area)
-j
The subject says it all, is anyone working on archiving TI-99/4A software?
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com | OpenVMS Enthusiast |
| | Photographer |
+----------------------------------+----------------------------+
| My flickr Photostream |
| http://www.flickr.com/photos/33848088 at N03/ |
| My Photography Website |
| http://www.zanesphotography.com |
hi. I was on the list, for two boards, but am on vacation. Will contact you in a 11 days
Andrew Lynch <LYNCHAJ at YAHOO.COM> wrote:
>Hi!
>
>Here is an update on available S-100 board PCBs! I've sent out many of the
>PCBs and they are almost gone.
>
>There are 21 of the S-100 IDE V2 reorder PCBs and 2 of the new S-100 bus
>terminator/prototyping board PCBs.
>
>There are 2 of the S-100 LAVA PCBs available.
>
>http://s100computers.com/My%20System%20Pages/IDE%20Board/My%20IDE%20Card.htm
>
>http://n8vem-sbc.pbworks.com/w/browse/#view=ViewFolder¶m=S-100%20bus%20t
>erminator
>
>http://s100computers.com/My%20System%20Pages/Lava-10%20Board/LAVA-10%20Board
>.htm
>
>The S-100 PCBs cost the same as before ($20 each).? However due to
>unforeseen extreme price increases in shipping by USPS I am forced to change
>shipping costs.
>
>Shipping in the US will be $3 for a single PCB and $2 for each additional
>PCB.? Shipping internationally will be $10 for a single PCB and $3 for each
>additional PCB.? This is for the bare basics USPS first class postage with
>no tracking or insurance.? The builder assumes all risk of delivery as per
>usual arrangement.
>
>I apologize for the large price increase on shipping but this is out of my
>hands.? The USPS is in dire financial trouble and is raising prices on
>shipping.? It affects us all and is most unfortunate.? These boards are
>provided "at cost" so there is no margin to absorb any shipping price
>increases.? I have to pass them along.
>
>If you would like one or more S-100 PCBs please send a PayPal to
>LYNCHAJ at YAHOO.COM
>
>Thanks and have a nice day!
>
>Andrew Lynch
>
>
Having got the PSU repaired in my recently acquired MV/2500 I now find
(as expected) that the disks are u/s and I need the microcode etc.
Does anyone know of a functioning example?
Steve
--
/Stephen Merrony
Email: steve at stephenmerrony.co.uk
http://stephen.homedns.org/dg//
>
> > VMS has a process called ERRFMT which logs errors in a binary file called
> > sys$errorlog:errlog.sys - the way to get a detailed human readable report of
> > the contents of that file used to be ANALYZE /ERROR but I don't think that
> > works any more. Maybe someone else can chime in and suggest what the current
> > way is.
>
> Nope, that DEFINITELY still works. Many, many screens full of error
> log printing. :-) I'll pore over those, then.
>
Good stuff. It must be only Alpha (and maybe Itanium?) it's messed up on then.
You can rename sys$errorlog:errlog.sys to .old for example if you want to
get rid of the accumulated errors and start afresh. ERRMFT will create a new
errlog.sys the next time it has something to log. Alternatively,
$ ANALYZE /ERROR /SINCE=time
will only report on errors after the specified time (or date), or just plain:
$ ANALYZE /ERROR /SINCE
will report on errors logged today.
>
> > Keep an eye out also for operator messages relating to the PU and DU devices
> > after doing a REPLY /ENABLE, SET TERMINAL, SET BROADCAST etc.
>
> Should those not be enabled on the main console at boot? That's
> what I'm conversing with. Just for fun, I'll make double sure.
>
In principle, yes. However, exactly what happens varies depending on the VMS
version and the type of hardware it is running on (workstation type machine
versus server type machine) so it's best to confirm that something has not
disabled operator messages when booting completed.
Regards,
Peter Coghlan.
I have a DECWriter II that needs a new home. It's located near
Portland, local pickup only.
I have no idea if it works or not, as I've never tried to power it on
in the 15 or so years I've owned it. The plans I had for it have
evaporated, and it takes up room I need.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com | OpenVMS Enthusiast |
| | Photographer |
+----------------------------------+----------------------------+
| My flickr Photostream |
| http://www.flickr.com/photos/33848088 at N03/ |
| My Photography Website |
| http://www.zanesphotography.com |
>
> > I suspect the manual is saying that a typical workload on a more capable VAX
> > than an MVII would need 24 MB for good performance. I think you should be able
> > to get by with rather less memory than that, particularly if you don't have a
> > graphics card.
>
> That was essentially my assumption as well, but I'm just not 100%
> sure if the pool adjustments I made to install it threw things
> out of whack for my system. This is a slight bit beefier than an
> MVII, but not by a lot. At some point in the near future, I'm
> acquiring a VAX4000, which has a bit more to it; this one is
> probably mostly going to be a curiosity or at most a file/DNS
> server.
>
Apologies - I don't know where I picked up MVII from - I must have been reading
something else and confused myself. I should have paid more attention to the
subject line.
>
> > It should not be necessary to reinstall to see the effect of not running
> > TCP/IP services. Just comment out the command to start it
> > (probably in sys$manager:systartup_vms.com) and reboot.
>
> That part was simple, but I have no clue as of yet how to back out
> the adjustments I made to the pool to run TCP/IP because I don't
> fully understand AUTOGEN yet. I'll get there eventually, but I
> need a stable system first and I can afford to throw the baby out
> with the bathwater at the moment. :-) It's all in the Essentials
> manual, but that's 500 pages, so it'll be a while before I'm done
> reading it.
>
The purpose of AUTOGEN is to get your system parameters set to appropriate
values for your workload and to make them consistent with each other and with
the resources available on your system. Once you get your system stable,
you don't need AUTOGEN any more :-)
It's not necessary to back out previous changes - just tell AUTOGEN what
parameters you need updated for software you have installed (by adding records
to sys$system:modparam.dat as recommended in the appropriate installation
manual) and then letting AUTOGEN sort it all out.
If you have never run AUTOGEN, you might get a few surprises the first time you
do but in the long run, I think it is better to make a habit of running it after
any changes to the system. That way you have a better idea what to expect each
time and there is less lightlyhood of big dramatic changes which might result
when you have made many changes and put off doing an AUTOGEN for some time.
Maybe it might be worth while trying it out in simh to get a feel for it?
It's certainly possible to modify system parameters manually but I think it's
better to build up experience by watching what AUTOGEN does before going down
that road.
Regards,
Peter Coghlan.
> Ah, OK. So I get some PUA0: errors ticking up every so often, most
> of which are right after the system has had some "hiccup" of non-
> interactivity for several minutes. Some initial research indicates
> that the PU device is the UDA controller, which is what I believe
> the CQD-220 masquerades as (more or less). Right now, after three
> hours of sitting basically idle, it's logged 26 errors.
>
> So I'll have to check that out. It could be something as simple as
> balky SCSI termination, since I do have 4 devices in the chain and
> the terminator is a Jaz drive using internal termination. I'll
> play with it some. Hopefully it's not the hard drive going bad,
> since my supply of SCSI drives is essentially dry. It's a bit
> worrisome that it's the PU device going bad rather than the DU
> device, but I'm not 100% sure how VMS logs the errors, so it could
> be what I suspect.
>
VMS has a process called ERRFMT which logs errors in a binary file called
sys$errorlog:errlog.sys - the way to get a detailed human readable report of
the contents of that file used to be ANALYZE /ERROR but I don't think that
works any more. Maybe someone else can chime in and suggest what the current
way is.
Keep an eye out also for operator messages relating to the PU and DU devices
after doing a REPLY /ENABLE, SET TERMINAL, SET BROADCAST etc.
Regards,
Peter Coghlan.
> > With VAX/VMS, having lots of physical memory is neither necessary nor
> > sufficient. More important is how the virtual memory system is configured.
> > Perhaps you are low on pagefile space or non-paged pool or something like
> > that?
>
> I was musing on this while reviewing the install manual and it does
> mention that at least 24 MB physical memory is necessary for TCP/IP
> 5.1. I don't know how hard and fast that is, but it's possible that
> the changes I made to the pool allocation per the manual have
> destabilized the system. Since I don't have much running on there,
> I've reinstalled from scratch to see if I have the same problem with
> no TCP/IP installed/running.
>
I would worry more about DECWindows needing large amounts of memory rather
than TCP/IP but having said that, I've always used Multinet rather than TCP/IP
services so I don't know a lot about it.
I suspect the manual is saying that a typical workload on a more capable VAX
than an MVII would need 24 MB for good performance. I think you should be able
to get by with rather less memory than that, particularly if you don't have a
graphics card.
It should not be necessary to reinstall to see the effect of not running TCP/IP
services. Just comment out the command to start it
(probably in sys$manager:systartup_vms.com) and reboot.
Regards,
Peter Coghlan.
I thought I was going to acquire an RS/6000 so I started buying spare
parts. Plans changed ...
Let me know if you need P/N 68X6356 (FRU 70F9976) which are 8MB SIMMs or
P/N 32G8212 which are 16MB SIMMs. These came in a 'Bag O' Memory' so
they are untested, but they were properly stored.
They are not free - shipping cost and beer money will do fine though.
Mike
Date: Sat, 4 May 2013 22:04:38 -0400
From: David Riley <fraveydank at gmail.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: uVAX 3900 out to lunch after inactivity
Message-ID: <0315AF5D-BB77-464C-9BD6-FE312DDCE21A at gmail.com>
Content-Type: text/plain; charset=us-ascii
The long saga of making my recent KA655 acquisition work
continues! It's been mostly smooth sailing since I got
a decent Plextor drive, but there's one persistent problem.
Under VMS 7.3, after a longish period of inactivity (I've
seen it after a few hours, but I've not been able to
narrow it down beyond that), it seems to just kind of go
out to lunch. VMS is still *running*... if I have a
Telnet session running MONITOR, the clock will still update
and the activity meters still move (a little; they show
very little activity, but that's expected since there's not
a lot going on on the machine yet). But if I terminate
MONITOR (it responds interactively to ctrl-C, etc) and try
to run anything else (say, HELP), it stops responding.
Other terminals are totally unresponsive. If I try to
open a Telnet session, TCP connects but no other traffic
happens.
This also happens if I turn TCP/IP off. I'm running with
16 MB RAM, which should be enough for a machine that's not
really running much yet, and if I were having memory issues
I would expect things like existing MONITOR sessions to
have serious problems.
If anyone has any idea what might be going on here, I'm
all ears.
I have seen this behavior a number of times when the disk
has gone offline for some reason. I'm not sure there
is a simple way to tell when the drive can no longer
be accessed. Obviously, there will be no error logging
of the condition, except that VMS may write some buffered
error messages on the next boot that may offer a clue.
Jon
>
> The long saga of making my recent KA655 acquisition work
> continues! It's been mostly smooth sailing since I got
> a decent Plextor drive, but there's one persistent problem.
> Under VMS 7.3, after a longish period of inactivity (I've
> seen it after a few hours, but I've not been able to
> narrow it down beyond that), it seems to just kind of go
> out to lunch. VMS is still *running*... if I have a
> Telnet session running MONITOR, the clock will still update
> and the activity meters still move (a little; they show
> very little activity, but that's expected since there's not
> a lot going on on the machine yet). But if I terminate
> MONITOR (it responds interactively to ctrl-C, etc) and try
> to run anything else (say, HELP), it stops responding.
> Other terminals are totally unresponsive. If I try to
> open a Telnet session, TCP connects but no other traffic
> happens.
>
> This also happens if I turn TCP/IP off. I'm running with
> 16 MB RAM, which should be enough for a machine that's not
> really running much yet, and if I were having memory issues
> I would expect things like existing MONITOR sessions to
> have serious problems.
>
> The only other correlation I can think of is that this
> seems to happen most when I've just installed a layered
> product, so it could have something to do with the CD
> still being mounted. On the other hand, I tend to leave
> the machine alone and unattended for long periods of time
> for product installs, so correlation is necessarily not
> very trustworthy here.
>
> I can still issue a break from the terminal and boot again
> from the console firmware, so that still seems fine.
>
> If anyone has any idea what might be going on here, I'm
> all ears.
>
Do either of:
$ REPLY /ENABLE
$ SHOW ERROR
show up any problems? You might need:
$ SET TERMINAL /BROADCAST
and/or
$ SET BROADCAST=ALL
with REPLY /ENABLE if you are doing this on the console and something has
disabled broadcasts on the console.
In older versions of VMS,
$ ANALYZE /ERROR
used to be very useful for spotting behind-the-scenes hardware problems and
worked straight out of the box but it was replaced in later versions (on Alpha
at least - I'm not sure about VAX) by
$ DIAGNOSE /TRANSLATE
which required extra software to be installed and possibly licensed first.
I lost track of what happened after that but I think that was replaced
again by something else equally difficult to make use of :-(
Your disk could be going to sleep but it seems unlikely that it would
recover by just halting and rebooting the system.
With VAX/VMS, having lots of physical memory is neither necessary nor
sufficient. More important is how the virtual memory system is configured.
Perhaps you are low on pagefile space or non-paged pool or something like
that?
Use
$ SHOW MEMORY /FILES
to check how much free pagefile space you have.
$ SHOW MEMORY /POOL /FULL
will give a vast number of figures. If "Free space" is low and "Current size"
is much bigger than "Initial size" and approaching "Maximum size", you may be
running into problems with non-paged pool.
If there are no hardware problems, an AUTOGEN might well help. For best
results, it should be done after whatever activity that might have used up
resources but it's obviously no good if the machine stops responding in the
middle of the AUTOGEN procedure. Tell AUTOGEN to save feedback and use it
when calculating new system parameters. It will complain that the machine
wasn't up for 24 hours but tell it to do it anyway.
$ @SYS$UPDATE:AUTOGEN HELP
for further details.
Regards,
Peter Coghlan.
> > Do either of:
> >
> > $ REPLY /ENABLE
> > $ SHOW ERROR
> >
> > show up any problems? You might need:
> >
> > $ SET TERMINAL /BROADCAST
> >
> > and/or
> >
> > $ SET BROADCAST=ALL
> >
> > with REPLY /ENABLE if you are doing this on the console and something has
> > disabled broadcasts on the console.
>
> Any of these would probably be great, but I should probably be a little
> more clear; it's not really responding at all to input after I respond
> to a prompt. After the carriage return, it just sits there and doesn't
> even echo anything, though as I mentioned, anything running elsewhere
> (like MONITOR) still seems to keep going.
>
It's me who should have been clearer.
Do the REPLY /ENABLE and friends before the problem shows up in the hope of
seeing a message giving details about the problem when it does show up.
You might see something like "Mount verification is in progress." for example.
Do the SHOW ERROR anytime and if anything (other than a tape drive, terminal
or any sort of virtual device) shows a non-zero error count, investigate the
reason for it. Particularly watch for MEMORY or CPU errors. If your disk
device starts clocking errors just before the system stalls, that would tend
to point the finger in its direction.
$ SHOW SYSTEM
is the one command I know of that will usually execute when almost all others
fail for reasons of resource starvation. Using it to look at what states
processes are in will give clues about what resources they might be waiting for.
> > $ SHOW MEMORY /POOL /FULL
> >
> > will give a vast number of figures. If "Free space" is low and "Current size"
> > is much bigger than "Initial size" and approaching "Maximum size", you may be
> > running into problems with non-paged pool.
>
> The free space numbers seem fine and always have, but I haven't run
> it while doing something like an install. I'll have to try that.
> The pool space numbers don't seem terribly large, but I'm not quite
> sure what nominal ones are.
The numbers will vary depending on your hardware and configuration. What
matters is that that "Free space" is not approaching zero when "Current size"
is already as big as "Maximum size" which means there is no scope for further
automatic expansion of the pool size. If you have plenty of free space, you
are ok. If you don't have any free space but "Current size" is less than
"Maximum size", you are still ok.
Another approach to this sort of thing is to crash the system when it becomes
unresponsive and analyse the resultant crash dump afterwards. Probably easier
to try the AUTOGEN first though.
Regards,
Peter Coghlan.
Hi!
Here is an update on available S-100 board PCBs! I've sent out many of the
PCBs and they are almost gone.
There are 21 of the S-100 IDE V2 reorder PCBs and 2 of the new S-100 bus
terminator/prototyping board PCBs.
There are 2 of the S-100 LAVA PCBs available.
http://s100computers.com/My%20System%20Pages/IDE%20Board/My%20IDE%20Card.htmhttp://n8vem-sbc.pbworks.com/w/browse/#view=ViewFolder¶m=S-100%20bus%20t
erminator
http://s100computers.com/My%20System%20Pages/Lava-10%20Board/LAVA-10%20Board
.htm
The S-100 PCBs cost the same as before ($20 each).? However due to
unforeseen extreme price increases in shipping by USPS I am forced to change
shipping costs.
Shipping in the US will be $3 for a single PCB and $2 for each additional
PCB.? Shipping internationally will be $10 for a single PCB and $3 for each
additional PCB.? This is for the bare basics USPS first class postage with
no tracking or insurance.? The builder assumes all risk of delivery as per
usual arrangement.
I apologize for the large price increase on shipping but this is out of my
hands.? The USPS is in dire financial trouble and is raising prices on
shipping.? It affects us all and is most unfortunate.? These boards are
provided "at cost" so there is no margin to absorb any shipping price
increases.? I have to pass them along.
If you would like one or more S-100 PCBs please send a PayPal to
LYNCHAJ at YAHOO.COM
Thanks and have a nice day!
Andrew Lynch