> In article<daf845aa-2c41-4e3c-9688-2d95efc86...@do4g2000vbb.googlegroups.com>, "vmsmang...@earthlink.net"<vmsmang...@earthlink.net> writes:
>> Of course localhost is also defined in both files as 127.0.0.0
> Is that a typo? On all my systems localhost is 127.0.0.1. IIRC
> localhost can actually be any number within 120.0.0.0/24 .
The local network is really an A-class network, so the proper definition is 127.0.0.0/8
And yes, the previous poster must have been confused. 127.0.0.0 is not a legal host address, either if you have 127.0.0.0/8 or 127.0.0.0/24. A host part of all zeros or all ones are not allowed.
But really, 127.0.0.0/24 is also a slight misconfiguration, if anyone is doing that. Not that it will be important enough to make any practical difference...
> > In article<daf845aa-2c41-4e3c-9688-2d95efc86...@do4g2000vbb.googlegroups.com>, "vmsmang...@earthlink.net"<vmsmang...@earthlink.net> writes:
> >> Of course localhost is also defined in both files as 127.0.0.0
> > Is that a typo? On all my systems localhost is 127.0.0.1. IIRC
> > localhost can actually be any number within120.0.0.0/24.
> The local network is really an A-class network, so the proper definition
> is127.0.0.0/8
> And yes, the previous poster must have been confused. 127.0.0.0 is not a
> legal host address, either if you have127.0.0.0/8or127.0.0.0/24. A
> host part of all zeros or all ones are not allowed.
> But really,127.0.0.0/24is also a slight misconfiguration, if anyone is
> doing that. Not that it will be important enough to make any practical
> difference...
> Johnny
I did make a typo for localhost. It actually is 127.0.0.1
> And yes, the previous poster must have been confused. 127.0.0.0 is not a > legal host address, either if you have 127.0.0.0/8 or 127.0.0.0/24. A > host part of all zeros or all ones are not allowed.
I once had a sysgen of HP-UX for three ethernet ports running on
a system with only one. It wasn't happy not to have an address
for the other ports, so I gave them 127.1.0.1/16 and 127.2.0.1/16,
and lo0 127.0.0.1/16.
That was before the private addresses were allocated, or at least
before I knew about them, about 1990. Ran fine that way for many
years.
It might be that some systems will accept requests on 127.*.*.* anyway.
> But really, 127.0.0.0/24 is also a slight misconfiguration, if anyone is > doing that. Not that it will be important enough to make any practical > difference...
Well, the allocation was made before CIDR, maybe even before subnets.
It seems to me that even /30 would work just fine.
> On Apr 5, 2:38 pm, Jan-Erik Soderholm<jan-erik.soderh...@telia.com>
> wrote:
>> vmsmang...@earthlink.net wrote 2012-04-05 22:21:
>>> Here is the reaponse to Jan-Erik's reply:
>> Hi. Sorry if I was a bit "short" earlier, but I usualy (and
>> I know others too) find hard output better then rewritten
>> descriptions of something. :-)
>>> COUGAR$ tcpip show ver
>>> HP TCP/IP Services for OpenVMS Alpha Version V5.7
>>> on an AlphaServer DS20 500 MHz running OpenVMS V8.4
>> OK. My system says :
>> $ tcpip sh ver
>> HP TCP/IP Services for OpenVMS Alpha Version V5.7 - ECO 3
>> on an AlphaServer DS25 running OpenVMS V8.4
>> $
>> Are you able to goto ECO 3 ?
>> No idea if that "solves" anything of course, it's just
>> a thought. There is usualy no reason *not* to apply ECO's.
The conservative approach is to NOT apply ECOs, or upgrades
unless they fix a problem that YOU HAVE or add a feature that
that you NEED.
It's not always possible but you should be conservative
in applying patches and upgrades when possible; especially
if your system is working properly.
Fixes have been known to break working systems. Sometimes they
don't even fix the problem(s) that they are supposed to fix!
Upgrades may create new problems! TEST before installing upgrades,
or fixes in production!
> (snip)
>> And yes, the previous poster must have been confused. 127.0.0.0 is not a
>> legal host address, either if you have 127.0.0.0/8 or 127.0.0.0/24. A
>> host part of all zeros or all ones are not allowed.
> I once had a sysgen of HP-UX for three ethernet ports running on
> a system with only one. It wasn't happy not to have an address
> for the other ports, so I gave them 127.1.0.1/16 and 127.2.0.1/16,
> and lo0 127.0.0.1/16.
> That was before the private addresses were allocated, or at least
> before I knew about them, about 1990. Ran fine that way for many
> years.
The "private" ranges have been around a long time. I don't remember for sure about 192.168, or the 172.whatever, but 10.0.0.0/8 have been "reserved" for much longer than that. It's the old arpanet, and have been reserved and forbidden on the Internet since way before 1990.
> It might be that some systems will accept requests on 127.*.*.* anyway.
Oh, I doubt any system would accept requests to 127.*.*.*, it will be one specific address, and it would surprise me if it wasn't the address you configured for the interface.
>> But really, 127.0.0.0/24 is also a slight misconfiguration, if anyone is
>> doing that. Not that it will be important enough to make any practical
>> difference...
> Well, the allocation was made before CIDR, maybe even before subnets.
> It seems to me that even /30 would work just fine.
That's why the "practical difference" comment. It will work with just about anything, but the "proper" network definition is 127.0.0.0/8. It's that whole A-class network that was reserved for local use, even though it's way too much normally.
I know of one tricky use of it. ntpd defines different type of local time references as different addresses on the local network.
And yes, even though we now have CIDR instead of the classes, it's still 127.0.0.0/8.
> On 4/5/2012 7:20 PM, vmsmang...@earthlink.net wrote:
>> On Apr 5, 2:38 pm, Jan-Erik Soderholm<jan-erik.soderh...@telia.com>
>> wrote:
>>> vmsmang...@earthlink.net wrote 2012-04-05 22:21:
>>>> Here is the reaponse to Jan-Erik's reply:
>>> Hi. Sorry if I was a bit "short" earlier, but I usualy (and
>>> I know others too) find hard output better then rewritten
>>> descriptions of something. :-)
>>>> COUGAR$ tcpip show ver
>>>> HP TCP/IP Services for OpenVMS Alpha Version V5.7
>>>> on an AlphaServer DS20 500 MHz running OpenVMS V8.4
>>> OK. My system says :
>>> $ tcpip sh ver
>>> HP TCP/IP Services for OpenVMS Alpha Version V5.7 - ECO 3
>>> on an AlphaServer DS25 running OpenVMS V8.4
>>> $
>>> Are you able to goto ECO 3 ?
>>> No idea if that "solves" anything of course, it's just
>>> a thought. There is usualy no reason *not* to apply ECO's.
> The conservative approach is to NOT apply ECOs, or upgrades
> unless they fix a problem that YOU HAVE or add a feature that
> that you NEED.
Right. Now, in the case of TCPIP Services, these are not like
usual "patches". The 5.7-ECO3 was simply the latest kit. In the
case of TCPIP Services, they are always full and complete kits.
So I never "applied an ECO" or did any "upgrade".
Now, as far as I can see right now, it is the non-ECO kit that
is supplied on the ALPHA084.ISO, I do not remember where I
got the ECO3 kit. It is not (now) on the FTP site where the
ISO's are.
> It's not always possible but you should be conservative
> in applying patches and upgrades when possible; especially
> if your system is working properly.
> Fixes have been known to break working systems. Sometimes they
> don't even fix the problem(s) that they are supposed to fix!
> Upgrades may create new problems! TEST before installing upgrades,
> or fixes in production!
<vmsmang...@earthlink.net> wrote:
> I am really embarassed about my original post. I know I should have
> provided a great deal more information. Since I have been working with
> and using VMS since 5.4 I know how important it is to have complete
> information. So, here goes.
> The Alphaserver DS20 has 1 GB memory, 1 cpu, and a mylex raid
> controller. DRA0 is the VMS 7.3.2 system disk, DRA1 is a spare disk,
> and DRA2 is a 3 member RAID 5 device with a spare drive.
> The Apple iMac G5 is a Power Mac with 1 GB memory.
> Both systems have a hosts file, TCPIP$HOST.DAT on the DS20 and etc/
> hosts on the iMac. Here is the contents of that file and is the same
> for both systems.
> Both systems and the Printserve are connected to a 5 port network
> switch. 2 printers are attached to the Printserver, a laserjet and an
> inkjet.
> Both systems can print to both printers and can also ping each other
> and the Printserver.
> To prepare for the 8.4 upgrade I did an image backup from DRA0: to
> DRA1:. I also did an image backup of DRA0: to mag tape.
> The intent is to Upgrade DRA0: from 7.3-2 to 8.4.
> This will be fairly long so I am going to break it down into several
> smaller posts.
> Again, my apologies to everyone who replied.
> Bill LaCounte, aka VMSmangler
Not sure if you are still having a problem, but remember than PING is
a low level tool which does not involve TCP or UDP. This means if you
can't "PING by ADDRESS" (pinging by name sometimes introduces other
problems like typos in your host file, DNS problems, etc.) then you
can forget about all the other stuff. At this point there are only a
few things that make any difference:
1) your IP address
2) your NET mask
3) maybe your MAC address
Going back to basics for a moment, remember that there are only a
couple of decision points here:
1) use the netmask to compare your address with the destination
address. This tells the stack if the destination is on is on your
subnet or not.
2) if the destination device is not on your subnet, then you need to
locate the nearest gateway which will handle the request for you. If
you know the address of the gateway then you will still need to use
ARP to locate the gateway's MAC address.
3) if on your subnet, then use ARP to determine the MAC address of he
destination device.
(I still remember a 5-day Synoptics class on networking back in 1992
where the instructor forced us to learn the following mantra which was
recited before every lecture: "All communications is done at the MAC
layer)
Okay so you say the Mac it working properly. Get a copy of WireShark
(replaces Ethereal) and use it to monitor the traffic between the
Alpha and the Printserver. Can you see the ARP request and response?
Can you see the MAC-to-MAC ping and response?
p.s. be sure to inspect the netmask of all devices involved.
> <vmsmang...@earthlink.net> wrote:
> > I am really embarassed about my original post. I know I should have
> > provided a great deal more information. Since I have been working with
> > and using VMS since 5.4 I know how important it is to have complete
> > information. So, here goes.
> > The Alphaserver DS20 has 1 GB memory, 1 cpu, and a mylex raid
> > controller. DRA0 is the VMS 7.3.2 system disk, DRA1 is a spare disk,
> > and DRA2 is a 3 member RAID 5 device with a spare drive.
> > The Apple iMac G5 is a Power Mac with 1 GB memory.
> > Both systems have a hosts file, TCPIP$HOST.DAT on the DS20 and etc/
> > hosts on the iMac. Here is the contents of that file and is the same
> > for both systems.
> > Both systems and the Printserve are connected to a 5 port network
> > switch. 2 printers are attached to the Printserver, a laserjet and an
> > inkjet.
> > Both systems can print to both printers and can also ping each other
> > and the Printserver.
> > To prepare for the 8.4 upgrade I did an image backup from DRA0: to
> > DRA1:. I also did an image backup of DRA0: to mag tape.
> > The intent is to Upgrade DRA0: from 7.3-2 to 8.4.
> > This will be fairly long so I am going to break it down into several
> > smaller posts.
> > Again, my apologies to everyone who replied.
> > Bill LaCounte, aka VMSmangler
> Not sure if you are still having a problem, but remember than PING is
> a low level tool which does not involve TCP or UDP. This means if you
> can't "PING by ADDRESS" (pinging by name sometimes introduces other
> problems like typos in your host file, DNS problems, etc.) then you
> can forget about all the other stuff. At this point there are only a
> few things that make any difference:
> 1) your IP address
> 2) your NET mask
> 3) maybe your MAC address
> Going back to basics for a moment, remember that there are only a
> couple of decision points here:
> 1) use the netmask to compare your address with the destination
> address. This tells the stack if the destination is on is on your
> subnet or not.
> 2) if the destination device is not on your subnet, then you need to
> locate the nearest gateway which will handle the request for you. If
> you know the address of the gateway then you will still need to use
> ARP to locate the gateway's MAC address.
> 3) if on your subnet, then use ARP to determine the MAC address of he
> destination device.
> (I still remember a 5-day Synoptics class on networking back in 1992
> where the instructor forced us to learn the following mantra which was
> recited before every lecture: "All communications is done at the MAC
> layer)
> Okay so you say the Mac it working properly. Get a copy of WireShark
> (replaces Ethereal) and use it to monitor the traffic between the
> Alpha and the Printserver. Can you see the ARP request and response?
> Can you see the MAC-to-MAC ping and response?
> p.s. be sure to inspect the netmask of all devices involved.
> > <vmsmang...@earthlink.net> wrote:
> > > I am really embarassed about my original post. I know I should have
> > > provided a great deal more information. Since I have been working with
> > > and using VMS since 5.4 I know how important it is to have complete
> > > information. So, here goes.
> > > The Alphaserver DS20 has 1 GB memory, 1 cpu, and a mylex raid
> > > controller. DRA0 is the VMS 7.3.2 system disk, DRA1 is a spare disk,
> > > and DRA2 is a 3 member RAID 5 device with a spare drive.
> > > The Apple iMac G5 is a Power Mac with 1 GB memory.
> > > Both systems have a hosts file, TCPIP$HOST.DAT on the DS20 and etc/
> > > hosts on the iMac. Here is the contents of that file and is the same
> > > for both systems.
> > > Both systems and the Printserve are connected to a 5 port network
> > > switch. 2 printers are attached to the Printserver, a laserjet and an
> > > inkjet.
> > > Both systems can print to both printers and can also ping each other
> > > and the Printserver.
> > > To prepare for the 8.4 upgrade I did an image backup from DRA0: to
> > > DRA1:. I also did an image backup of DRA0: to mag tape.
> > > The intent is to Upgrade DRA0: from 7.3-2 to 8.4.
> > > This will be fairly long so I am going to break it down into several
> > > smaller posts.
> > > Again, my apologies to everyone who replied.
> > > Bill LaCounte, aka VMSmangler
> > Not sure if you are still having a problem, but remember than PING is
> > a low level tool which does not involve TCP or UDP. This means if you
> > can't "PING by ADDRESS" (pinging by name sometimes introduces other
> > problems like typos in your host file, DNS problems, etc.) then you
> > can forget about all the other stuff. At this point there are only a
> > few things that make any difference:
> > 1) your IP address
> > 2) your NET mask
> > 3) maybe your MAC address
> > Going back to basics for a moment, remember that there are only a
> > couple of decision points here:
> > 1) use the netmask to compare your address with the destination
> > address. This tells the stack if the destination is on is on your
> > subnet or not.
> > 2) if the destination device is not on your subnet, then you need to
> > locate the nearest gateway which will handle the request for you. If
> > you know the address of the gateway then you will still need to use
> > ARP to locate the gateway's MAC address.
> > 3) if on your subnet, then use ARP to determine the MAC address of he
> > destination device.
> > (I still remember a 5-day Synoptics class on networking back in 1992
> > where the instructor forced us to learn the following mantra which was
> > recited before every lecture: "All communications is done at the MAC
> > layer)
> > Okay so you say the Mac it working properly. Get a copy of WireShark
> > (replaces Ethereal) and use it to monitor the traffic between the
> > Alpha and the Printserver. Can you see the ARP request and response?
> > Can you see the MAC-to-MAC ping and response?
> > p.s. be sure to inspect the netmask of all devices involved.
> I am back in the Seattle area and have the iMac with me. I won't be
> able to use the DS20 until Tuesday when I get home to Coeur d'Alene,
> Idaho.
This part looks OKAY to me. Nice to see that device WE0 does not
display "NOARP". Most people will already notice that the netmask is a
bit restrictive for a "10" network but that setting is not wrong (the
RFCs just consider it not-natural). Anyway, when I executed the same
command on an OpenVMS-7.3-2 system, it produced almost identical
results:
BTW, you might have produced a similar display by typing:
TCPIP> sho config inter
###
If you displayed the contents of the host database like this:
TCPIP> sho host/local
then I am surprised that you did not see a line like:
127.0.0.1 LOCALHOST, localhost
But as I said previously, PING is a very low level tool which uses
almost none of this stuff when pinging by address. The command looks
like this:
TCPIP> ping /address=142.180.221.226/noroute
PING 142.180.221.226 (142.180.221.226): 56 data bytes
64 bytes from 142.180.221.226: icmp_seq=0 ttl=64 time=7 ms
64 bytes from 142.180.221.226: icmp_seq=1 ttl=64 time=0 ms
64 bytes from 142.180.221.226: icmp_seq=2 ttl=64 time=0 ms
64 bytes from 142.180.221.226: icmp_seq=3 ttl=64 time=0 ms
The "/noroute" switch is only valid when staying on the same subnet
(which is what you are doing)
next you would want to check your arp tables like so right after your
PING:
TCPIP>sho arp
If you do not see an entry for your printserver, then
1) either an arp request never went out
2) the printserver never received the arp
3) the printserver ignored the arp
4) the printserver never answered back with a MAC
5) the Alpha wasn't able to place the MAC in the arp table
That's why you need to check further with a sniffer.
###
Stuff for hackers: if you were certain the OpenVMS platform was okay,
you might want to sniff from within VMS like so:
$ tcpdump :== $sys$system:tcpip$tcpdump.exe
$ tcpdump -?
Version 2.2.1
Usage: tcpdump [-BdeflmnNOqStvxX] [-s snaplen] [-c count] [-b buffers]
[-r filename] [-w filename] [-F filter] [expr]
$ tcpdump
tcpdump: listening on WE0
Filtering in user process
> <vmsmang...@earthlink.net> wrote:
> > On Apr 14, 9:37 am, Neil Rieck <n.ri...@sympatico.ca> wrote:
> > > On Apr 4, 6:58 pm, "vmsmang...@earthlink.net"
> > > <vmsmang...@earthlink.net> wrote:
> > > > I am really embarassed about my original post. I know I should have
> > > > provided a great deal more information. Since I have been working with
> > > > and using VMS since 5.4 I know how important it is to have complete
> > > > information. So, here goes.
> > > > The Alphaserver DS20 has 1 GB memory, 1 cpu, and a mylex raid
> > > > controller. DRA0 is the VMS 7.3.2 system disk, DRA1 is a spare disk,
> > > > and DRA2 is a 3 member RAID 5 device with a spare drive.
> > > > The Apple iMac G5 is a Power Mac with 1 GB memory.
> > > > Both systems have a hosts file, TCPIP$HOST.DAT on the DS20 and etc/
> > > > hosts on the iMac. Here is the contents of that file and is the same
> > > > for both systems.
> > > > Both systems and the Printserve are connected to a 5 port network
> > > > switch. 2 printers are attached to the Printserver, a laserjet and an
> > > > inkjet.
> > > > Both systems can print to both printers and can also ping each other
> > > > and the Printserver.
> > > > To prepare for the 8.4 upgrade I did an image backup from DRA0: to
> > > > DRA1:. I also did an image backup of DRA0: to mag tape.
> > > > The intent is to Upgrade DRA0: from 7.3-2 to 8.4.
> > > > This will be fairly long so I am going to break it down into several
> > > > smaller posts.
> > > > Again, my apologies to everyone who replied.
> > > > Bill LaCounte, aka VMSmangler
> > > Not sure if you are still having a problem, but remember than PING is
> > > a low level tool which does not involve TCP or UDP. This means if you
> > > can't "PING by ADDRESS" (pinging by name sometimes introduces other
> > > problems like typos in your host file, DNS problems, etc.) then you
> > > can forget about all the other stuff. At this point there are only a
> > > few things that make any difference:
> > > 1) your IP address
> > > 2) your NET mask
> > > 3) maybe your MAC address
> > > Going back to basics for a moment, remember that there are only a
> > > couple of decision points here:
> > > 1) use the netmask to compare your address with the destination
> > > address. This tells the stack if the destination is on is on your
> > > subnet or not.
> > > 2) if the destination device is not on your subnet, then you need to
> > > locate the nearest gateway which will handle the request for you. If
> > > you know the address of the gateway then you will still need to use
> > > ARP to locate the gateway's MAC address.
> > > 3) if on your subnet, then use ARP to determine the MAC address of he
> > > destination device.
> > > (I still remember a 5-day Synoptics class on networking back in 1992
> > > where the instructor forced us to learn the following mantra which was
> > > recited before every lecture: "All communications is done at the MAC
> > > layer)
> > > Okay so you say the Mac it working properly. Get a copy of WireShark
> > > (replaces Ethereal) and use it to monitor the traffic between the
> > > Alpha and the Printserver. Can you see the ARP request and response?
> > > Can you see the MAC-to-MAC ping and response?
> > > p.s. be sure to inspect the netmask of all devices involved.
> > I am back in the Seattle area and have the iMac with me. I won't be
> > able to use the DS20 until Tuesday when I get home to Coeur d'Alene,
> > Idaho.
> This part looks OKAY to me. Nice to see that device WE0 does not
> display "NOARP". Most people will already notice that the netmask is a
> bit restrictive for a "10" network but that setting is not wrong (the
> RFCs just consider it not-natural). Anyway, when I executed the same
> command on an OpenVMS-7.3-2 system, it produced almost identical
> results:
> BTW, you might have produced a similar display by typing:
> TCPIP> sho config inter
> ###
> If you displayed the contents of the host database like this:
> TCPIP> sho host/local
> then I am surprised that you did not see a line like:
> 127.0.0.1 LOCALHOST, localhost
> But as I said previously, PING is a very low level tool which uses
> almost none of this stuff when pinging by address. The command looks
> like this:
> TCPIP> ping /address=142.180.221.226/noroute
> PING 142.180.221.226 (142.180.221.226): 56 data bytes
> 64 bytes from 142.180.221.226: icmp_seq=0 ttl=64 time=7 ms
> 64 bytes from 142.180.221.226: icmp_seq=1 ttl=64 time=0 ms
> 64 bytes from 142.180.221.226: icmp_seq=2 ttl=64 time=0 ms
> 64 bytes from 142.180.221.226: icmp_seq=3 ttl=64 time=0 ms
> The "/noroute" switch is only valid when staying on the same subnet
> (which is what you are doing)
> next you would want to check your arp tables like so right after your
> PING:
> TCPIP>sho arp
> If you do not see an entry for your printserver, then
> 1) either an arp request never went out
> 2) the printserver never received the arp
> 3) the printserver ignored the arp
> 4) the printserver never answered back with a MAC
> 5) the Alpha wasn't able to place the MAC in the arp table
> That's why you need to check further with a sniffer.
> ###
> Stuff for hackers: if you were certain the OpenVMS platform was okay,
> you might want to sniff from within VMS like so:
> $ tcpdump :== $sys$system:tcpip$tcpdump.exe
> $ tcpdump -?
> Version 2.2.1
> Usage: tcpdump [-BdeflmnNOqStvxX] [-s snaplen] [-c count] [-b buffers]
> [-r filename] [-w filename] [-F filter] [expr]
> $ tcpdump
> tcpdump: listening on WE0
> Filtering in user process
I am finally back home now and have addressed the TCP/IP issue with
VMS 8.4. Here is what I have done.
I ordered a wireless router and wireless modem so eventually I can get
rid of dial-up internet service. To support the router I reassigned
the IP address of the Printserver.
I changed it from 10.1.1.10 to 10.1.1.4. I made this change on the
Printserver, the iMac G5 and on the VMS 7.3-2 system. Everybody can
ping everybody.
Device DRA2 is a 3 member Raid 5 device and is mounted whether I boot
DRA1 (VMS 7.3-2) or DRA0 (VMS 8.4). I put a copy of SYS$SYSTEM:TCPIP
$HOST.DAT on DRA2.
I then shutdown 7.3-2 and booted 8.4.
When 8.4 was up I copied the hosts file from DRA2 to its proper
position in sys$syatem. I then purged and renamed the file as version
1 and made sure the logical name
was correct (TCPIP$HOST). It was correct.
Now it was time to test. VOILA! I was able to ping the iMac G5 and the
Printserver. I then performed a print test. The file printed out just
fine.
I don't know what the true sollution was. It could be from changing
the IP address from 10.1.1.10 to 10.1.1.4 or (and this is more likely)
copying the 7.3-2 host file.
What is interesting is this: the host file on 7.3-2 is 90 blocks on
disk. This same file on the 8.4 system is 108 disk blocks.
Whatever the reason, VMS 8.4 is now working just fine on my
Alphaserver DS20.
My thanks to everyone for their help and suggestions.
On Wednesday, April 25, 2012 10:39:09 AM UTC-7, vmsma...@earthlink.net wrote:
[...]
> I don't know what the true sollution was. It could be from changing
> the IP address from 10.1.1.10 to 10.1.1.4 or (and this is more likely)
> copying the 7.3-2 host file.
> What is interesting is this: the host file on 7.3-2 is 90 blocks on
> disk. This same file on the 8.4 system is 108 disk blocks.
Just on this last point, I *suspect* you are doing a DIRECTORY/SIZE
on the file(s), no? Try instead DIRECTORY/SIZE=ALL . The size
difference you are seeing, if I'm correct, is just the difference
in the disk cluster size on the two system disks, not the used
space in the file. The cluster size is set when the disk is initialized. (Of course, you could also do a DIFFERENCE and
verify the contents of the two files are identical.)
> On Wednesday, April 25, 2012 10:39:09 AM UTC-7, vmsma...@earthlink.net wrote:
> [...]
> > I don't know what the true sollution was. It could be from changing
> > the IP address from 10.1.1.10 to 10.1.1.4 or (and this is more likely)
> > copying the 7.3-2 host file.
> > What is interesting is this: the host file on 7.3-2 is 90 blocks on
> > disk. This same file on the 8.4 system is 108 disk blocks.
> Just on this last point, I *suspect* you are doing a DIRECTORY/SIZE
> on the file(s), no? Try instead DIRECTORY/SIZE=ALL . The size
> difference you are seeing, if I'm correct, is just the difference
> in the disk cluster size on the two system disks, not the used
> space in the file. The cluster size is set when the disk is
> initialized. (Of course, you could also do a DIFFERENCE and
> verify the contents of the two files are identical.)
> -Ken
I have to retract my success announcement. I was still running the
7.3-2 system when the pinging and printing was successfull.
Changing the IP address made no difference. Likewise the change in the
host file size.
As to the change in file size, I moved the host file from DRA1: to
DRA2: before copying it to DRA0: DRA0/1: has a cluster size of 18.
DRA2 has a cluster size of 48. Hence the difference.
Now, alas, I still have the problem that the 8.4 system cannot ping
nor print to the printserver.
On Thursday, April 26, 2012 4:57:46 PM UTC-7, vmsma...@earthlink.net wrote:
> On Apr 25, 10:55 am, Ken Fairfield <ken.fairfi...@gmail.com> wrote:
> > On Wednesday, April 25, 2012 10:39:09 AM UTC-7, vmsma...@earthlink.net wrote:
> > [...]
> > > I don't know what the true sollution was. It could be from changing
> > > the IP address from 10.1.1.10 to 10.1.1.4 or (and this is more likely)
> > > copying the 7.3-2 host file.
> > > What is interesting is this: the host file on 7.3-2 is 90 blocks on
> > > disk. This same file on the 8.4 system is 108 disk blocks.
> > Just on this last point, I *suspect* you are doing a DIRECTORY/SIZE
> > on the file(s), no? Try instead DIRECTORY/SIZE=ALL . The size
> > difference you are seeing, if I'm correct, is just the difference
> > in the disk cluster size on the two system disks, not the used
> > space in the file. The cluster size is set when the disk is
> > initialized. (Of course, you could also do a DIFFERENCE and
> > verify the contents of the two files are identical.)
> > -Ken
> I have to retract my success announcement. I was still running the
> 7.3-2 system when the pinging and printing was successfull.
> Changing the IP address made no difference. Likewise the change in the
> host file size.
> As to the change in file size, I moved the host file from DRA1: to
> DRA2: before copying it to DRA0: DRA0/1: has a cluster size of 18.
> DRA2 has a cluster size of 48. Hence the difference.
> Now, alas, I still have the problem that the 8.4 system cannot ping
> nor print to the printserver.
> Bill
It is now late August and the problem is solved. Starting in May and continuing through September I am
having to deal with medical problems. However, that has not stopped me from ordering a new iMac from Apple. Now that the new iMac is set up properly I am getting back to getting VMS 8.4 to run on my DS20.
I rebooted VMS 7.3-2 which is very reliable for network printing. I then re-read the TCP/IP installation manual and realized I had missed 2 key elements. One of the SYSTEM account quotas was too low so I increased that on the 7.3-2 system. THe other missed element was in modparams.dat. I needed to increase gblpages and gblsects. Which I did and then used autogen and restarted.
I then booted the new 8.4 CD and did a backup/image from DRA1 (7.3-2 syustem) to DRA0. When that finished I performed an upgrade to 8.4 on DRA0. The upgrade went very smooth and was successfuil. After the necessary reboot the upgrade was finally done.
At this point I testing pinging my old iMac G5, my new iMac, and the HP Jetdirect Printserver. All of the pings were successfull. As a further test I printed documents to both printers and they were successful. By the way the printers are not exactly new. They are an HP Laserjet 2100M and an HP Business Inkjet 2250.
I have since checked out all of the startup file with the templates and they are good.
I then installed the new C and Fortran compilers.
I also made up CD inserts for the 4 disks containing VMS 8.4. These inserts include the shark and hobbyist logos. Let me know if anyone is interested. They are in iWork/Pages format and also as a PDF.
But the best news is that VMS 8.4 is up and running great on my DS20.
Bill
William S. LaCounte
Coeur d'Alene, Idaho
b...@lacounte.com
