Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Update to TCP/IP problem with Alpha VMS 8.4
480 views
Skip to first unread message
vmsma...@earthlink.net
Apr 4, 2012, 6:58:08 PM4/4/12
to
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.
10.1.1.1 cougar Cougar COUGAR
10.1.1.3 imacg5 Imacg5 IMACG5
10.1.1.10 printserver Printserver PRINTSERVER
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
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.
10.1.1.1 cougar Cougar COUGAR
10.1.1.3 imacg5 Imacg5 IMACG5
10.1.1.10 printserver Printserver PRINTSERVER
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
Steven Schweda
Apr 4, 2012, 8:29:53 PM4/4/12
to Steven M. Schweda
> The Apple iMac G5 is a Power Mac with 1 GB memory.
Running some version of some OS?
> 10.1.1.1 cougar Cougar COUGAR
Have you ever seen a situation where case mattered in
these data?
> This will be fairly long so I am going to break it down
> into several smaller posts.
vmsma...@earthlink.net
Apr 4, 2012, 11:01:24 PM4/4/12
to
Shame on me again. The OS on the iMac G5 is OS X 10.4.11, the highest
version of "Tiger".
I am doing this posting piecemeal because I only have dialup service
and today the phone lines are really bad. It took 30 minutes just
to get this connection and it is only 45333 bps. Normally I get 50667.
I live in a rural area, the phone company cannot even provide DSL
and there is no cable. When I replace this 7 year old iMac in the next
couple of months I will be going with a wireless 4G setup.
Next posting will be tomorrow.
Bill L.
version of "Tiger".
I am doing this posting piecemeal because I only have dialup service
and today the phone lines are really bad. It took 30 minutes just
to get this connection and it is only 45333 bps. Normally I get 50667.
I live in a rural area, the phone company cannot even provide DSL
and there is no cable. When I replace this 7 year old iMac in the next
couple of months I will be going with a wireless 4G setup.
Next posting will be tomorrow.
Bill L.
vmsma...@earthlink.net
Apr 5, 2012, 2:31:21 PM4/5/12
to
On Apr 4, 8:01 pm, "vmsmang...@earthlink.net"
Prior to the installation of VMS 8.4 I ftp'd the VMS Installation
Manual, the New Features manual and the Release Notes from the
documentation directory on the installation CD, i.e. ALPHA084:
[ALPHA084.DOCUMENTAION]. I followed the instructions which included
purging log files etc. Everything looked good so I proceeded with the
installation.
I selected DECnet Phase IV over DECnet Plus and TCP/IP V5.7-13 was
automatically included. The installation went smoothly. When done I
exited the procedure and booted the new system. Once up it did it
magic with AUTOGEN and then restarted.
I then logged in as I normally do and everything seemed just fine. I
also did a few commands to see how the system looked, e.g. show
system, show memory, show queue and so on. It was at this point I
decided to print a file to the laserjet. It would not print. Instead
it kept resubmitting itself.
At this point I decided I had better check out TCP/IP.
I executed @SYS$MANAGER:TCPIP$CONFIG to check out the tcp/ip
configuration.
Here are the Client and Server screens (I removed blank lines and
leading spaces to save space):
HP TCP/IP Services for OpenVMS Client Components Configuration Menu
Configuration options:
1 - DHCP Client Disabled Stopped
2 - FTP Client Enabled Started
3 - NFS Client Disabled Stopped
4 - REXEC and RSH Disabled Stopped
5 - RLOGIN Enabled Started
6 - SMTP Disabled Stopped
7 - SSH Client Disabled Stopped
8 - TELNET Enabled Started
9 - TELNETSYM Enabled Started
A - Configure options 1 - 9
[E] - Exit menu
HP TCP/IP Services for OpenVMS Server Components Configuration Menu
Configuration options:
1 - BIND Disabled Stopped 12 - NTP Disabled
Stopped
2 - BOOTP Disabled Stopped 13 - PC-NFS Disabled
Stopped
3 - DHCP Disabled Stopped 14 - POP Disabled
Stopped
4 - FINGER Enabled Started 15 - PORTMAPPER Enabled
Started
5 - FTP Enabled Started 16 - RLOGIN Enabled
Started
6 - IMAP Disabled Stopped 17 - RMT Disabled
Stopped
7 - LBROKER Disabled Stopped 18 - SNMP Disabled
Stopped
8 - LPR/LPD Enabled Started 19 - SSH Disabled
Stopped
9 - METRIC Disabled Stopped 20 - TELNET Enabled
Started
10 - NFS Disabled Stopped 21 - TFTP Disabled
Stopped
11 - LOCKD/STATD Disabled Stopped 22 - XDM Disabled
Stopped
Since everything looked good I decided to run the TCP/IP IVP tests
(option 7).
The first test is for UDP/IP. It started but did not complete.
Normally this test is very fast.
I then did the same test via @SYS$TEST:TCPIP$IVP and the UDP/IP test
worked. The next test is for TVP/IP and it timed out.
Bill LaCounte
Manual, the New Features manual and the Release Notes from the
documentation directory on the installation CD, i.e. ALPHA084:
[ALPHA084.DOCUMENTAION]. I followed the instructions which included
purging log files etc. Everything looked good so I proceeded with the
installation.
I selected DECnet Phase IV over DECnet Plus and TCP/IP V5.7-13 was
automatically included. The installation went smoothly. When done I
exited the procedure and booted the new system. Once up it did it
magic with AUTOGEN and then restarted.
I then logged in as I normally do and everything seemed just fine. I
also did a few commands to see how the system looked, e.g. show
system, show memory, show queue and so on. It was at this point I
decided to print a file to the laserjet. It would not print. Instead
it kept resubmitting itself.
At this point I decided I had better check out TCP/IP.
I executed @SYS$MANAGER:TCPIP$CONFIG to check out the tcp/ip
configuration.
Here are the Client and Server screens (I removed blank lines and
leading spaces to save space):
HP TCP/IP Services for OpenVMS Client Components Configuration Menu
Configuration options:
1 - DHCP Client Disabled Stopped
2 - FTP Client Enabled Started
3 - NFS Client Disabled Stopped
4 - REXEC and RSH Disabled Stopped
5 - RLOGIN Enabled Started
6 - SMTP Disabled Stopped
7 - SSH Client Disabled Stopped
8 - TELNET Enabled Started
9 - TELNETSYM Enabled Started
A - Configure options 1 - 9
[E] - Exit menu
HP TCP/IP Services for OpenVMS Server Components Configuration Menu
Configuration options:
1 - BIND Disabled Stopped 12 - NTP Disabled
Stopped
2 - BOOTP Disabled Stopped 13 - PC-NFS Disabled
Stopped
3 - DHCP Disabled Stopped 14 - POP Disabled
Stopped
4 - FINGER Enabled Started 15 - PORTMAPPER Enabled
Started
5 - FTP Enabled Started 16 - RLOGIN Enabled
Started
6 - IMAP Disabled Stopped 17 - RMT Disabled
Stopped
7 - LBROKER Disabled Stopped 18 - SNMP Disabled
Stopped
8 - LPR/LPD Enabled Started 19 - SSH Disabled
Stopped
9 - METRIC Disabled Stopped 20 - TELNET Enabled
Started
10 - NFS Disabled Stopped 21 - TFTP Disabled
Stopped
11 - LOCKD/STATD Disabled Stopped 22 - XDM Disabled
Stopped
Since everything looked good I decided to run the TCP/IP IVP tests
(option 7).
The first test is for UDP/IP. It started but did not complete.
Normally this test is very fast.
I then did the same test via @SYS$TEST:TCPIP$IVP and the UDP/IP test
worked. The next test is for TVP/IP and it timed out.
Bill LaCounte
Jan-Erik Soderholm
Apr 5, 2012, 2:56:03 PM4/5/12
to
$ show queue <qn> /full ! on the printer queue
David Froble
Apr 5, 2012, 4:06:29 PM4/5/12
to
Regardless, you should be able to go to local IP addresses, if there is not a sub-net
issue, which from an earlier post, I think you have that covered.
It seems like perhaps TCP/IP cannot find a local ethernet interface. Just a wild ass guess.
vmsma...@earthlink.net
Apr 5, 2012, 4:21:44 PM4/5/12
to
On Apr 5, 1:06 pm, David Froble <da...@tsoft-inc.com> wrote:
No router in my configuration. When I ping the printserver it does
lookup the ip address (10.1.1.10) but times out whereas the piing to
the imacg5 does work using its ip address of 10.1.1.3.
Here is the reaponse to Jan-Erik's reply:
COUGAR$ tcpip show ver
HP TCP/IP Services for OpenVMS Alpha Version V5.7
on an AlphaServer DS20 500 MHz running OpenVMS V8.4
COUGAR$ sho que/fu sys$laserjet
Printer queue SYS$LASERJET, idle, on COUGAR::"tcpip
$queue:syslaserjet",
mounted form LETTER
<HP LaserJet 2100M>
/BASE_PRIORITY=4 /DEFAULT=(FEED,FORM=LETTER) /LIBRARY=LASERLIB
Lowercase
/OWNER=[SYSTEM] /PROCESSOR=TCPIP$TELNETSYM /NO_INITIAL_FF
/PROTECTION=(S:M,O:D,G:R,W:S) /SCHEDULE=(NOSIZE)
COUGAR$ sho que/fu syslaserjet
Server queue SYSLASERJET, idle, on COUGAR::, mounted form DEFAULT
/BASE_PRIORITY=4 /DEFAULT=(FEED,FORM=DEFAULT) Lowercase /
OWNER=[SYSTEM]
/PROCESSOR=TCPIP$LPD_SMB /PROTECTION=(S:M,O:D,G:R,W:S) /RETAIN=ERROR
And here is the response a few minutes later:
COUGAR$ sho que *laserjet
Printer queue SYS$LASERJET, idle, on COUGAR::"tcpip
$queue:syslaserjet",
mounted form LETTER
<HP LaserJet 2100M>
Server queue SYSLASERJET, busy, on COUGAR::, mounted form DEFAULT
Entry Jobname Username Blocks Status
----- ------- -------- ------ ------
30 TCPIP SYSTEM 2 Processing
COUGAR$
LPD Retrying failed job: TCPIP Number: 30 User: SYSTEM Status: %SYSTEM-
F-TIMEOUT
, device timeout
COUGAR$ sho que/fu *laserjet
Printer queue SYS$LASERJET, idle, on COUGAR::"tcpip
$queue:syslaserjet",
mounted form LETTER
<HP LaserJet 2100M>
/BASE_PRIORITY=4 /DEFAULT=(FEED,FORM=LETTER) /LIBRARY=LASERLIB
Lowercase
/OWNER=[SYSTEM] /PROCESSOR=TCPIP$TELNETSYM /NO_INITIAL_FF
/PROTECTION=(S:M,O:D,G:R,W:S) /SCHEDULE=(NOSIZE)
Server queue SYSLASERJET, idle, on COUGAR::, mounted form DEFAULT
/BASE_PRIORITY=4 /DEFAULT=(FEED,FORM=DEFAULT) Lowercase /
OWNER=[SYSTEM]
/PROCESSOR=TCPIP$LPD_SMB /PROTECTION=(S:M,O:D,G:R,W:S) /RETAIN=ERROR
Entry Jobname Username Blocks Status
----- ------- -------- ------ ------
30 TCPIP SYSTEM 2 Holding until 5-
APR-2012 13:05:09
Submitted 5-APR-2012 12:58:55.07 /FORM=DEFAULT /PRIORITY=100
File: _COUGAR$DRA0:[SYS0.TCPIP$LPD]TCPIP$TELNETSYM_TEMP_1.DAT;
53
/DELETE
Bill LaCounte
PS: I may not be able to reply more today. I have to prepare to leave
town for 2 weeks. I will have access to the newsgroup using my
daughters iPad though.
lookup the ip address (10.1.1.10) but times out whereas the piing to
the imacg5 does work using its ip address of 10.1.1.3.
Here is the reaponse to Jan-Erik's reply:
COUGAR$ tcpip show ver
HP TCP/IP Services for OpenVMS Alpha Version V5.7
on an AlphaServer DS20 500 MHz running OpenVMS V8.4
COUGAR$ sho que/fu sys$laserjet
Printer queue SYS$LASERJET, idle, on COUGAR::"tcpip
$queue:syslaserjet",
mounted form LETTER
<HP LaserJet 2100M>
/BASE_PRIORITY=4 /DEFAULT=(FEED,FORM=LETTER) /LIBRARY=LASERLIB
Lowercase
/OWNER=[SYSTEM] /PROCESSOR=TCPIP$TELNETSYM /NO_INITIAL_FF
/PROTECTION=(S:M,O:D,G:R,W:S) /SCHEDULE=(NOSIZE)
COUGAR$ sho que/fu syslaserjet
Server queue SYSLASERJET, idle, on COUGAR::, mounted form DEFAULT
/BASE_PRIORITY=4 /DEFAULT=(FEED,FORM=DEFAULT) Lowercase /
OWNER=[SYSTEM]
/PROCESSOR=TCPIP$LPD_SMB /PROTECTION=(S:M,O:D,G:R,W:S) /RETAIN=ERROR
And here is the response a few minutes later:
COUGAR$ sho que *laserjet
Printer queue SYS$LASERJET, idle, on COUGAR::"tcpip
$queue:syslaserjet",
mounted form LETTER
<HP LaserJet 2100M>
Server queue SYSLASERJET, busy, on COUGAR::, mounted form DEFAULT
Entry Jobname Username Blocks Status
----- ------- -------- ------ ------
30 TCPIP SYSTEM 2 Processing
COUGAR$
LPD Retrying failed job: TCPIP Number: 30 User: SYSTEM Status: %SYSTEM-
F-TIMEOUT
, device timeout
COUGAR$ sho que/fu *laserjet
Printer queue SYS$LASERJET, idle, on COUGAR::"tcpip
$queue:syslaserjet",
mounted form LETTER
<HP LaserJet 2100M>
/BASE_PRIORITY=4 /DEFAULT=(FEED,FORM=LETTER) /LIBRARY=LASERLIB
Lowercase
/OWNER=[SYSTEM] /PROCESSOR=TCPIP$TELNETSYM /NO_INITIAL_FF
/PROTECTION=(S:M,O:D,G:R,W:S) /SCHEDULE=(NOSIZE)
Server queue SYSLASERJET, idle, on COUGAR::, mounted form DEFAULT
/BASE_PRIORITY=4 /DEFAULT=(FEED,FORM=DEFAULT) Lowercase /
OWNER=[SYSTEM]
/PROCESSOR=TCPIP$LPD_SMB /PROTECTION=(S:M,O:D,G:R,W:S) /RETAIN=ERROR
Entry Jobname Username Blocks Status
----- ------- -------- ------ ------
30 TCPIP SYSTEM 2 Holding until 5-
APR-2012 13:05:09
Submitted 5-APR-2012 12:58:55.07 /FORM=DEFAULT /PRIORITY=100
File: _COUGAR$DRA0:[SYS0.TCPIP$LPD]TCPIP$TELNETSYM_TEMP_1.DAT;
53
/DELETE
Bill LaCounte
PS: I may not be able to reply more today. I have to prepare to leave
town for 2 weeks. I will have access to the newsgroup using my
daughters iPad though.
Ken Fairfield
Apr 5, 2012, 5:03:10 PM4/5/12
to
On Thursday, April 5, 2012 1:21:44 PM UTC-7, vmsma...@earthlink.net wrote:
[...BIG SNIP...]
> No router in my configuration. When I ping the printserver it does
> lookup the ip address (10.1.1.10) but times out whereas the piing to
> the imacg5 does work using its ip address of 10.1.1.3.
Since this thread doesn't have all the information in it, I can't
recall which IP address goes with what system or printer. :-(
The best I can interpret the above is, you ping the printerserver
by name and ping displays the host name ("printerserver") and it's
IP address (10.1.1.10) *as configured on the VMS system*. And
you get no response.
But ping to the imacg5 displays the imac's host name ("imacg5") and
it's IP address (10.1.1.3) *as configured on the VMS system*.
What does ping from the imacg5 to the printerserver show for
the printerserver's IP address?
<Basic troubleshooting here...>
-Ken
[...BIG SNIP...]
> No router in my configuration. When I ping the printserver it does
> lookup the ip address (10.1.1.10) but times out whereas the piing to
> the imacg5 does work using its ip address of 10.1.1.3.
recall which IP address goes with what system or printer. :-(
The best I can interpret the above is, you ping the printerserver
by name and ping displays the host name ("printerserver") and it's
IP address (10.1.1.10) *as configured on the VMS system*. And
you get no response.
But ping to the imacg5 displays the imac's host name ("imacg5") and
it's IP address (10.1.1.3) *as configured on the VMS system*.
What does ping from the imacg5 to the printerserver show for
the printerserver's IP address?
<Basic troubleshooting here...>
-Ken
Jan-Erik Soderholm
Apr 5, 2012, 5:38:08 PM4/5/12
to
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.
I upgraded to 8.4 a few weeks ago on my DS25, and as far
as I remember 5.7 ECO3 was the kit on the CD's (the CD's
distributed from HP lately).
So you are using both telnet and LPD as transport for
your queues?
But as Kenneth wrote, I'd not bother about the queueus
until after PING works. :-)
Jan-Erik.
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
>
$ 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.
I upgraded to 8.4 a few weeks ago on my DS25, and as far
as I remember 5.7 ECO3 was the kit on the CD's (the CD's
distributed from HP lately).
So you are using both telnet and LPD as transport for
your queues?
But as Kenneth wrote, I'd not bother about the queueus
until after PING works. :-)
Jan-Erik.
Steven Schweda
Apr 5, 2012, 6:37:53 PM4/5/12
to Steven M. Schweda
> Here are the Client and Server screens [...]
Considering that "ping" fails, I'd start with the
fundamental stuff, like, say, "1 - Core environment".
Perhaps I missed something, but I still don't know the IP
addresses and netmasks on any of the interfaces on any of the
systems/devices. (Or who's connected to what, how.)
tcpip show interface
ifconfig -a # "ifconfig en0" may be enough.
[I have no idea how to extract info from your printer
thing.]
As usual, showing actual commands with their actual output
can be more helpful than vague descriptions or
interpretations.
Considering that "ping" fails, I'd start with the
fundamental stuff, like, say, "1 - Core environment".
Perhaps I missed something, but I still don't know the IP
addresses and netmasks on any of the interfaces on any of the
systems/devices. (Or who's connected to what, how.)
tcpip show interface
ifconfig -a # "ifconfig en0" may be enough.
[I have no idea how to extract info from your printer
thing.]
As usual, showing actual commands with their actual output
can be more helpful than vague descriptions or
interpretations.
vmsma...@earthlink.net
Apr 5, 2012, 7:12:23 PM4/5/12
to
10.1.1.10. The hosts files on the VMS system and the iMac G5 are the
same.
Bill
vmsma...@earthlink.net
Apr 5, 2012, 7:17:28 PM4/5/12
to
On Apr 5, 2:03 pm, Ken Fairfield <ken.fairfi...@gmail.com> wrote:
the iMac.
10.1.1.1 cougar Cougar COUGAR
10.1.1.3 imacg5 Imacg5 IMACG5
10.1.1.10 printserver Printserver PRINTSERVER
Bill
vmsma...@earthlink.net
Apr 5, 2012, 7:20:08 PM4/5/12
to
On Apr 5, 2:38 pm, Jan-Erik Soderholm <jan-erik.soderh...@telia.com>
wrote:
The only patch that HP listed with the ISO file was this:
OPENVMS_ALPHA_8_4_UPDATE500.ZIP
I did install the patch (along with the PCSI patch) and neither had
any effect.
Bill
wrote:
OPENVMS_ALPHA_8_4_UPDATE500.ZIP
I did install the patch (along with the PCSI patch) and neither had
any effect.
Bill
David Froble
Apr 5, 2012, 8:32:44 PM4/5/12
to
I know this is rather basic, but perhaps overlooked.
At times after network problems, I have to power off and then back on my network printer.
I don't think I should have to do so, but, the world doesn't seem to care what I think ...
From what you've posted, and my feeble memory, your stuff SHOULD be working. I seem to
remember, and correct me if I'm wrong, that these devices were working well with VMS V7.3
or something like that. Still got the old system disk available?
Ok, I went back to old posts and read them. If it was me, I'd boot VMS from the backup
you made on DRA1 (You did do an image copy to the disk, right? Not to a save_set?)
Then I'd make sure all the hardware was working, (there are coincidences in the world),
and I'd re-check all the TCP/IP settings.
Finally, re-boot the V8.4 disk and re-check the TCP/IP settings. If it still doesn't
work, I'd be looking for a copy of the VMS V8.3 distribution. Note, if you do, be sure to
get TCPIP V5.6 ECO5. It is a total re-distribution of TCPIP so you don't need the earlier
stuff. We needed this upgrade to get SSH stuff working correctly.
PS - did you really mean the VMS system had a HOSTS.DAT file, or did you mean you did
TCPIP SET HOST mumble mumble ? I've never experienced a HOSTS file on VMS. Of course,
I've been accused of "not getting out much".
At times after network problems, I have to power off and then back on my network printer.
I don't think I should have to do so, but, the world doesn't seem to care what I think ...
From what you've posted, and my feeble memory, your stuff SHOULD be working. I seem to
remember, and correct me if I'm wrong, that these devices were working well with VMS V7.3
or something like that. Still got the old system disk available?
Ok, I went back to old posts and read them. If it was me, I'd boot VMS from the backup
you made on DRA1 (You did do an image copy to the disk, right? Not to a save_set?)
Then I'd make sure all the hardware was working, (there are coincidences in the world),
and I'd re-check all the TCP/IP settings.
Finally, re-boot the V8.4 disk and re-check the TCP/IP settings. If it still doesn't
work, I'd be looking for a copy of the VMS V8.3 distribution. Note, if you do, be sure to
get TCPIP V5.6 ECO5. It is a total re-distribution of TCPIP so you don't need the earlier
stuff. We needed this upgrade to get SSH stuff working correctly.
PS - did you really mean the VMS system had a HOSTS.DAT file, or did you mean you did
TCPIP SET HOST mumble mumble ? I've never experienced a HOSTS file on VMS. Of course,
I've been accused of "not getting out much".
Steven Schweda
Apr 5, 2012, 10:22:01 PM4/5/12
to Steven M. Schweda
> Here is the host file contents. It is the same on the VMS
> system and the iMac.
Sigh.
> system and the iMac.
> As usual, showing actual commands with their actual output
> can be more helpful than vague descriptions or
> interpretations.
If someone shows me an actual command like, say,
"cat /etc/hosts" or "tcpip show hosts" with its actual
output, then I have actual evidence of something. If someone
tells me what he believes to be true, then I have only
testimony of uncertain value (and, sometimes, of uncertain
meaning). Which of these is worth more to you?
> Have you ever seen a situation where case mattered in
> these data?
Note that "hosts" info says nothing about the properties
of any actual interface, only how names and addresses are
associated (somewhere).
> PS - did you really mean [...]
Note that showing actual commands with their actual output
normally removes any such uncertainty, which removal can
significantly increase efficiency in the exchange of actual
information.
Just a thought.
vmsma...@earthlink.net
Apr 5, 2012, 11:02:27 PM4/5/12
to
HP TCP/IP Services for OpenVMS Interface & Address Configuration Menu
Hostname Details: Configured=cougar, Active=cougar
Configuration options:
0 - Set The Target Node (Current Node: COUGAR)
1 - WE0 Menu (EWA0: TwistedPair 100mbps)
2 - 10.1.1.1/24 COUGAR Configured,Active
[E] - Exit menu
Enter configuration option:
TCPIP> ifconfig -a
LO0: flags=100c89<UP,LOOPBACK,NOARP,MULTICAST,SIMPLEX,NOCHECKSUM>
inet 127.0.0.1 netmask ff000000 ipmtu 4096
TN0: flags=80<NOARP>
TN1: flags=80<NOARP>
WE0: flags=c43<UP,BROADCAST,RUNNING,MULTICAST,SIMPLEX>
*inet 10.1.1.1 netmask ffffff00 broadcast 10.1.1.255 ipmtu 1500
The 2nd part provides more information.
On an earlier posting the localhost ip address should have been
127.0.0.1
Bill
vmsma...@earthlink.net
Apr 5, 2012, 11:06:53 PM4/5/12
to
On Apr 5, 8:02 pm, "vmsmang...@earthlink.net"
One last item before I head out of town for 2 weeks.
Since the problem appears to be in TCP/IP I went to the HP web site
and got the installation manual for TCP/IP V5.7 and the
troubleshooting manual V5.7.
After read the installation manual and checking the MODPARAMS file I
found I needed to increase ADD_GBLPAGES from 8100 to 12000 and also to
increase ADD_GBLSECTS from 65 to 160. The other parameters were OK. I
then used AUTOGEN with the command @SYS$UPDATE:AUTOGEN GETDATA
SETPARAMS NOFEEDBACK. Afterwards I examined AGEN$PARAMS.REPORT and the
results were good.
At the same time I revisited the VMS 8.4 installation manual. It turns
out I missed modifying one parameter for the SYSTEM account. I then
increased BIOLM from 100 to 400 on the SYSTEM account.
Finally I rebooted the 8.4 system, logged in and performed the same
test I had done before. Results were exactly the same!!!
Bill LaCounte
Since the problem appears to be in TCP/IP I went to the HP web site
and got the installation manual for TCP/IP V5.7 and the
troubleshooting manual V5.7.
After read the installation manual and checking the MODPARAMS file I
found I needed to increase ADD_GBLPAGES from 8100 to 12000 and also to
increase ADD_GBLSECTS from 65 to 160. The other parameters were OK. I
then used AUTOGEN with the command @SYS$UPDATE:AUTOGEN GETDATA
SETPARAMS NOFEEDBACK. Afterwards I examined AGEN$PARAMS.REPORT and the
results were good.
At the same time I revisited the VMS 8.4 installation manual. It turns
out I missed modifying one parameter for the SYSTEM account. I then
increased BIOLM from 100 to 400 on the SYSTEM account.
Finally I rebooted the 8.4 system, logged in and performed the same
test I had done before. Results were exactly the same!!!
Bill LaCounte
vmsma...@earthlink.net
Apr 5, 2012, 11:05:30 PM4/5/12
to
systems (and Mac OS X) it is called /etc/hosts
vmsma...@earthlink.net
Apr 5, 2012, 10:57:32 PM4/5/12
to
and it is still available.
DRA0: has the upgraded VMS 8.4 system.
It is still the case that with VMS 7.3-2 and the iMac g5 both can ping
each other and each can also piing the printserver.
Of course both systems can also print to the 2 printers attached to
the printserver.
Bill
Paul Sture
Apr 6, 2012, 4:27:39 AM4/6/12
to
On Wed, 04 Apr 2012 17:29:53 -0700, Steven Schweda wrote:
>
>> 10.1.1.1 cougar Cougar COUGAR
>
> Have you ever seen a situation where case mattered in
> these data?
>
That's an interesting question. I have created TCP/IP Services host
>
>> 10.1.1.1 cougar Cougar COUGAR
>
> Have you ever seen a situation where case mattered in
> these data?
>
names in both uppercase and lowercase (though not capitalised) for years.
I must have had some reason to do this, but I cannot remember why. I
don't think I would have done this purely because "It looks more
consistent on outputs", but maybe I did. Maybe it dates back to older
versions of software in use circa 1998.
--
Paul Sture
Jan-Erik Soderholm
Apr 6, 2012, 6:31:38 AM4/6/12
to
$ tcpip sho ver
HP TCP/IP Services for OpenVMS Alpha Version V5.7 - ECO 3
on an AlphaServer DS25 running OpenVMS V8.4
$
$ tcpip set host "abc2"/addr=1.2.3.5
$ tcpip sh host /local
1.2.3.4 ABC
1.2.3.5 abc2
As expected.
$ tcpip sho host abc*
1.2.3.4 ABC
OK, so abc* get uppercased by DCL (?).
$ tcpip sho host "abc*"
1.2.3.5 abc2
Case preserved, right ?
$ tcpip sho host ABC2
1.2.3.5 abc2
$ tcpip sho host ABC*
1.2.3.4 ABC
$ tcpip sho host ABC2*
1.2.3.5 abc2
Something more then case alone is going on.
$ tcpip sho host "abc*"
1.2.3.5 abc2
$ tcpip set nohost abc2
$ tcpip sho host "abc*"
1.2.3.4 ABC
Weird...
Bob Koehler
Apr 6, 2012, 11:43:03 AM4/6/12
to
In article <daf845aa-2c41-4e3c...@do4g2000vbb.googlegroups.com>, "vmsma...@earthlink.net" <vmsma...@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
>
> Of course localhost is also defined in both files as 127.0.0.0
localhost can actually be any number within 120.0.0.0/24 .
Bob Koehler
Apr 6, 2012, 11:45:49 AM4/6/12
to
In article <jlldje$r6u$1...@dont-email.me>, David Froble <da...@tsoft-inc.com> writes:
>
> At times after network problems, I have to power off and then back on my
> network printer.
>
(Gee, your posts are a bit too wide to be legible, I keep manually
>
> At times after network problems, I have to power off and then back on my
> network printer.
>
wrapping them).
Is this an older HP printer? When we were sharing one between
systems, we had to send the PCL once to permanently reduce the
timeout at the end of a print job or it seemed like the printer
would never allow a different host to connect.
Later HP printers didn't seem to have this issue.
Bob Koehler
Apr 6, 2012, 11:49:42 AM4/6/12
to
On Wed, 04 Apr 2012 17:29:53 -0700, Steven Schweda wrote:
>
>> 10.1.1.1 cougar Cougar COUGAR
>
> Have you ever seen a situation where case mattered in
> these data?
>
I seem to recall that it was the convention under ULTRIX to do
>
>> 10.1.1.1 cougar Cougar COUGAR
>
> Have you ever seen a situation where case mattered in
> these data?
>
the same name in different cases.
Don't know if the software actually cared, but on UNIX one tended
to assume it did.
David Froble
Apr 6, 2012, 12:48:43 PM4/6/12
to
If I had to guess at blame, I'd start with the cheap switches I use before looking at the
printer. I've had switches that needed a power cycle, usually after a thunder storm. If
it's a bad storm, with nearby lightening strike(s), then sometimes new switches are
required. Life is hell, and then you die ....
Johnny Billquist
Apr 6, 2012, 7:09:44 PM4/6/12
to
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...
Johnny
vmsma...@earthlink.net
Apr 6, 2012, 7:34:16 PM4/6/12
to
On Apr 6, 4:09 pm, Johnny Billquist <b...@softjar.se> wrote:
> On2012-04-06 17.43, Bob Koehler wrote:
>
> > In article<daf845aa-2c41-4e3c-9688-2d95efc86...@do4g2000vbb.googlegroups.com>, "vmsmang...@earthlink.net"<vmsmang...@earthlink.net> writes:
> On2012-04-06 17.43, Bob Koehler wrote:
>
> > 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
> >> 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
> 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
> difference...
>
> Johnny
glen herrmannsfeldt
Apr 6, 2012, 8:07:10 PM4/6/12
to
Johnny Billquist <b...@softjar.se> wrote:
(snip)
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.
-- glen
(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
> 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.
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...
It seems to me that even /30 would work just fine.
-- glen
Richard B. Gilbert
Apr 6, 2012, 8:27:51 PM4/6/12
to
On 4/5/2012 7:20 PM, vmsma...@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
> 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.
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>
Johnny Billquist
Apr 7, 2012, 4:10:42 AM4/7/12
to
On 2012-04-07 02.07, glen herrmannsfeldt wrote:
> Johnny Billquist<b...@softjar.se> wrote:
>
> (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
> Johnny Billquist<b...@softjar.se> wrote:
>
> (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.
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.
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.
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.
Johnny
Paul Sture
Apr 7, 2012, 5:32:09 AM4/7/12
to
time.
I've now remembered which project I did this for, and it involved multi-
platform clients and Oracle.
--
Paul Sture
Jan-Erik Soderholm
Apr 7, 2012, 6:33:16 AM4/7/12
to
Richard B. Gilbert wrote 2012-04-07 02:27:
> On 4/5/2012 7:20 PM, vmsma...@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
> On 4/5/2012 7:20 PM, vmsma...@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.
>
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.
Jan-Erik.
Neil Rieck
Apr 14, 2012, 12:37:16 PM4/14/12
to
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.
> 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.
Just my 2 cents worth :-)
Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
<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.
>
> 10.1.1.1 cougar Cougar COUGAR
> 10.1.1.3 imacg5 Imacg5 IMACG5
> 10.1.1.10 printserver Printserver PRINTSERVER
>
> Both systems and the Printserve are connected to a 5 port network
> 10.1.1.1 cougar Cougar COUGAR
> 10.1.1.3 imacg5 Imacg5 IMACG5
> 10.1.1.10 printserver Printserver PRINTSERVER
>
> 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.
Just my 2 cents worth :-)
Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
vmsma...@earthlink.net
Apr 14, 2012, 5:10:31 PM4/14/12
to
@sys$manager:tcpip$config
I selected Core services and got this information:
HP TCP/IP Services for OpenVMS Interface & Address Configuration Menu
Hostname Details: Configured=cougar, Active=cougar
Configuration options:
0 - Set The Target Node (Current Node: COUGAR)
1 - WE0 Menu (EWA0: TwistedPair 100mbps)
2 - 10.1.1.1/24 COUGAR Configured,Active
[E] - Exit menu
Enter configuration option:
TCPIP> ifconfig -a
LO0: flags=100c89<UP,LOOPBACK,NOARP,MULTICAST,SIMPLEX,NOCHECKSUM>
inet 127.0.0.1 netmask ff000000 ipmtu 4096
TN0: flags=80<NOARP>
TN1: flags=80<NOARP>
WE0: flags=c43<UP,BROADCAST,RUNNING,MULTICAST,SIMPLEX>
*inet 10.1.1.1 netmask ffffff00 broadcast 10.1.1.255 ipmtu 1500
Herre is the host database:
10.1.1.1 cougar Cougar COUGAR
10.1.1.3 imacg5 Imacg5 IMACG5
10.1.1.10 printserver Printserver PRINTSERVER
able to use the DS20 until Tuesday when I get home to Coeur d'Alene,
Idaho.
Neil Rieck
Apr 15, 2012, 6:40:28 PM4/15/12
to
On Apr 14, 5:10 pm, "vmsmang...@earthlink.net"
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:
TCPIP> ifconfig -a
LO0: flags=100c89<UP,LOOPBACK,NOARP,MULTICAST,SIMPLEX,NOCHECKSUM>
inet 127.0.0.1 netmask ff000000 ipmtu 4096
TN0: flags=80<NOARP>
TN1: flags=80<NOARP>
WE0: flags=c43<UP,BROADCAST,RUNNING,MULTICAST,SIMPLEX>
*inet 142.180.221.220 netmask ffffe100 broadcast 142.180.223.255
ipmtu 1500
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
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:
TCPIP> ifconfig -a
LO0: flags=100c89<UP,LOOPBACK,NOARP,MULTICAST,SIMPLEX,NOCHECKSUM>
inet 127.0.0.1 netmask ff000000 ipmtu 4096
TN0: flags=80<NOARP>
TN1: flags=80<NOARP>
WE0: flags=c43<UP,BROADCAST,RUNNING,MULTICAST,SIMPLEX>
ipmtu 1500
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
vmsma...@earthlink.net
Apr 25, 2012, 1:39:09 PM4/25/12
to
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.
Bill
Ken Fairfield
Apr 25, 2012, 1:55:21 PM4/25/12
to
On Wednesday, April 25, 2012 10:39:09 AM UTC-7, vmsma...@earthlink.net wrote:
[...]
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 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
> 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.
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
vmsma...@earthlink.net
Apr 26, 2012, 7:57:46 PM4/26/12
to
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
vmsma...@earthlink.net
Aug 29, 2012, 9:12:52 AM8/29/12
to
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
bi...@lacounte.com
0 new messages