On 2012-06-08 16:39, Paul_Koning at Dell.com wrote:
On Jun 8, 2012, at 3:00 AM, Johnny Billquist wrote:
On 2012-06-08 08:39, Boyanich, Alastair wrote:
Hi Johnny,
Your welcome. Yes, it's pretty chatty. MIPSPro and DECC are my favourite
C compilers as they're quite anal and chatty warning wise.
Yeah. gcc is stupid. They added -Wall several years ago, but apparently people got upset by it's anal reporting, so they dumbed it down. So -Wall does not turn on all warnings anymore. And I just don't have the enery right now to figure out what more switches I should throw on it to actually make it complain about everything...
If you really want lots of warnings, say -Wall -Wpedantic. But in fact -Wall is quite good in more recent versions of gcc. The issues mentioned before would certainly be caught by GCC 4.6 or later. Well, with one caveat: quite a number of the things that gcc can warn about are found as a consequence of the deeper analysis done when you turn on optimization. So you need at least -O1 and more likely -O2 if you want to get good warnings.
Actually, I didn't get any warnings with -Wall, for which the mips compiler complained about.
(Well, I had already fixed two issues, but the others gcc didn't complain about.)
Thanks, however. It was -Wpendantic that I was thinking of, even though I never seem to be able to remember the name.
But I still think it is backwards to have a -Wall, which do not enable all warnings. :-)
Johnny
On Jun 8, 2012, at 2:00 AM, Johnny Billquist wrote:
On 2012-06-08 01:13, Dave McGuire wrote:
On 06/07/2012 08:16 AM, Johnny Billquist wrote:
Any program that needs access to raw ethernet packets needs to run as
root. Promiscuous mode or not. Promiscuous mode itself has little to do
with this.
So if you want to run anything like a bridge or a router, you will need
to run it as root. Promiscuous mode is basically just allowing you to
share the same interface as the system is otherwise using, instead of
having to dedicate a separate ethernet interface for this.
Maybe you're just putting this another way, but promiscuous mode is
correctly defined a bit differently than this. When an Ethernet
controller is placed into promiscuous mode, its on-chip MAC address
filters, which normally either select or ignore inbound packets based on
their MAC address, are disabled. ALL packets are received by the
hardware and passed to the Ethernet driver in the OS, rather than only
the ones destined for that specific interface as defined by its MAC address.
I'm reasonably certain that you know this but were just explaining it
in a more abstract way...?
Yes. Well, actually I wasn't describing it in a more abstract way, but in a way more in terms of why you need promiscuous mode instead of what it actually does on the interface.
But reading it through now, I see that there was one implicit assumption in my text which I could have pointed out.
If you need to share the device with the system, while using a different MAC address, you need to place the device in promiscuous mode. And such is the case if we talk DECnet, since DECnet requires that you use a specific MAC address which is not the same as the default MAC address of a device.
That's true if you have a NIC and driver that only allows one individual address per physical MAC. Most modern NICs allow multiple individual addresses since the address filter is an exact match on N (say, 16 or so) addresses, and it doesn't care whether those are individual or multicast. The host OS drivers may or may not export that feature. If they do, then you don't need promiscuous mode. If they don't, or if the NIC is old enough that it can't do this, then you do.
paul
On Jun 8, 2012, at 3:00 AM, Johnny Billquist wrote:
On 2012-06-08 08:39, Boyanich, Alastair wrote:
Hi Johnny,
Your welcome. Yes, it's pretty chatty. MIPSPro and DECC are my favourite
C compilers as they're quite anal and chatty warning wise.
Yeah. gcc is stupid. They added -Wall several years ago, but apparently people got upset by it's anal reporting, so they dumbed it down. So -Wall does not turn on all warnings anymore. And I just don't have the enery right now to figure out what more switches I should throw on it to actually make it complain about everything...
If you really want lots of warnings, say -Wall -Wpedantic. But in fact -Wall is quite good in more recent versions of gcc. The issues mentioned before would certainly be caught by GCC 4.6 or later. Well, with one caveat: quite a number of the things that gcc can warn about are found as a consequence of the deeper analysis done when you turn on optimization. So you need at least -O1 and more likely -O2 if you want to get good warnings.
paul
On Thu, Jun 7, 2012 at 7:14 PM, Dave McGuire <mcguire at neurotica.com> wrote:
On 06/07/2012 08:35 AM, Jordi Guillaumes i Pons wrote:
According to this:
http://h71000.www7.hp.com/openvms/os/openvms-release-history.html
Support for the 4000/90 came in version 5.5-2 (1992). The 3300 was
supported in 5.0-2 and the 4000 mod. 2000 in 5.4-2. So none of my real
boxen can run 4.7.
Well you've gotta find yourself some more machines! 11/750s are
probably the most common of the 4.x-capable machines, though there don't
seem to be many left floating around.
Heh, then I would have to find also a new home and probably an attorney to handle de divorce demand ;)
I'll keep my mouth shut.. ;)
--
Dave McGuire, AK4HZ
New Kensington, PA
My wife refers to the 11/7xx boxes I worked on as my old girlfriends.
If one more piece of hardware
hits the house I'll need the same lawyer. As soon as I can find it a
good home I'm getting rid of my Vaxstation and going
to go to only emulated hardware under VMware Workstation/ESXi/XenServer at home.
Bill Pechter, N2RDI
Holmdel, NJ
--
d|i|g|i|t|a|l had it THEN. Don't you wish you could still buy it now!
pechter-at-gmail.com
On Thu, Jun 7, 2012 at 7:42 PM, Bob Armstrong <bob at jfcl.com> wrote:
Lunchboxes! :-) And there are images for new boot ROMs available for
those
which will allow you to boot from the on-board SCSI host adapter, ...
I've heard of this, but I haven't seen it. As I recall, the onboard SCSI
adapter uses programmed I/O (no DMA!) so it's really slow. For a TK50
nobody would ever notice, but for the system disk it's a problem. Better to
cluster boot one, diskless.
FWIW, an RD54 isn't necessary. The 2000 can easily be convinced to use
_any_ MFM drive, DEC or not. You can get VMS V4 on a 30 meg drive, maybe
even 20, if you're determined. Long ago I wrote up a little description of
all the VS 2000 disk formatter parameters, what they meant, and how to fake
them for non-DEC drives. Google ancient Usenet postings if you're
interested.
Bob
The real problem I've found lately is getting VMS V4 or V3.
I used to do installs of V2, V3, and V4 when I was at DEC.
It is really hard to find VMS installation media of the pre CD variety.
We really could use an archive site for stuff like this, but HP
would probably have a fit over the copyright.
Unfortunately, getting a legal archive will probably not happen.
Bill
--
d|i|g|i|t|a|l had it THEN. Don't you wish you could still buy it now!
pechter-at-gmail.com
We (all of us with Multinet, I think) see this problem occasionally. AFAIK
no one has come up with an adequate explanation, let alone a solution.
You can always turn off logging if it bothers you :-)
Bob
On 8 Jun 2012, at 10:58, Johnny Billquist <bqt at softjar.se> wrote:
Yes, a TZ87 (DLT2000) can read TK50 tapes and TK70 tapes as well.
Really? That is even better. I had a fleeting memory of the TZ87, but I
just assumed I must be remembering wrong.
That lines up, my DLT4000 is a TZ88 and won't, was the first DLT that
didn't read them IIRC
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
Lunchboxes! :-) And there are images for new boot ROMs available for
those which will allow you to boot from the on-board SCSI host adapter,
which is relatively slow (NCR5380-based) but still less painful than
trying to find, and then afford to purchase, an RD54.
I think someone even wrote a driver for VMS to use disks on that
controller. I have several of those machines; I really should look into
that. Does anyone have any further information on, or actual copies of,
those boot ROMs and/or the VMS device driver?
That's a patch for VAX/VMS 5.5-2 called PK2KDRVR which Wolfgang Moeller wrote
in response to the moaning years ago on comp.os.vms etc that the VS2000 would
be so much more useful if it could use SCSI disks. To his surprise, he found
there was very little interest in his solution. I was interested and I found
the patched driver worked well. I found I couldn't tell if it was slow or not
as the 2000 is so slow anyway! I never tried the patched boot ROMs as I boot
my 2000's from a 3100.
(How come I can remember this stuff and I have trouble remembering what
happened yesterday!)
Wolfgang also did patches for VS3100 boot ROMs which had problems booting
disks over 1GB in size.
I also have another patch he wrote which makes the floppy driver in a 2000
treat the drive as an RX23 instead of an RX33 making it possible for VMS to
correctly access 3.5in disks in a 2000.
I've put what I have on CEIRE::
(I can't find the original PK2KDRVR.ZIP so I've just zipped up the contents
of my PK2KDRVR directory which is likely what I got when I unzipped the
original zip file...)
Regards,
Peter Coghlan.
On 2012-06-08 11:10, Kari Uusim ki wrote:
On 8.6.2012 10:31, Mark Benson wrote:
On 8 Jun 2012, at 08:23, Dave McGuire<mcguire at neurotica.com> wrote:
I haven't tried cleaning TK50 heads in years, but I will (now that I
have a more respectable workspace) start trying that. I will let you
know how things go. I'll probably start digging into those within the
next month or two. Thank you for the suggestion!
I take it TK50 tapes won't read in a later drive?
Yes, a TZ87 (DLT2000) can read TK50 tapes and TK70 tapes as well.
Really? That is even better. I had a fleeting memory of the TZ87, but I just assumed I must be remembering wrong.
Johnny
On 2012-06-08 11:10, Dave McGuire wrote:
On 06/08/2012 05:08 AM, Mark Benson wrote:
The TK85 can read TK50s? I didn't know that! If that's the case,
it's likely that the TF85 (DSSI version) may as well, and I have one of those. That may be one more option to get my huge pile of TK50s read.
I had a feeling the later TKs read TK50. I read it on on of HP's DLT
compatibility docs but couldn't remember if it was TK50 or TK70 that
was the oldest compatible format. I have a SCSI-II DLT4000 drive (TK88
or 89??) and I know that doesn't read any old TK tapes, only DLT1,2
etc.
The general rule with most of those format is that the current drive
will read and write the current format, and read (but not write) the
previous format. There are of course exceptions, but not many.
Indeed. Such as the Tx85 reading both TK50 and TK70. :-)
Johnny