Hello!
Oh nertz! There goes my chance out an airlock.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Wed, Oct 2, 2013 at 7:38 PM, Dave McGuire <mcguire at neurotica.com> wrote:
On 10/02/2013 07:37 PM, Sampsa Laine wrote:
Eurgh. Can you pick something OTHER than google groups? ;)
Nah, too lazy.
I'm not at all interested in another annoying Google Groups list..sorry.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 10/02/2013 07:37 PM, Gregg Levine wrote:
What's wrong Cory? Peeved that you did not think of it first?
I think he's peeved because Google Groups blows. Setting up a mailing
list is not difficult, and we already HAVE an alternate list (dectec)
that just doesn't ever get used for whatever reason.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 10/02/2013 07:37 PM, Sampsa Laine wrote:
Eurgh. Can you pick something OTHER than google groups? ;)
Nah, too lazy.
I'm not at all interested in another annoying Google Groups list..sorry.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Since this has come up a few times as a recommendation (but without
details on how to do it), I figured I'd provide my [really terse
and unclean] notes on how to set up a SIMH/VAX image you can use
to temporarily satellite boot VAXen into a cluster just to lay a
fresh copy of VMS down onto them (and then on reboot have the
targets be standalone machines).
Please let me know if you have suggestions for cleaning this up!
I'd love feedback for this.
Also, apologies to Oleg & co in Area 63, that's just the random area I
chose when writing these notes up and it's only used for the
satellite boot host temporarily. Feel free to clean that up
for "your" install!
Note that this assumes OpenVMS VAX 7.3. You could swap this around for any
5.x/6.x/7.x version without much trouble.
Make sure you have nothing you care about on any of the drives,
read carefully, and use your brain to properly adjust device
names/paths/addresses/etc for your install. These were just
written up/tested with two simh instances (one for boot host, one
for satellite).
simh config looks like:
;;; vms.ini
set cpu 256m
set cpu idle=vms
set console telnet=4000
set cpu conhalt
;
load -r conf/ka655x.bin
;
attach nvr conf/nvram.bin
;
set rq0 ra72
att rq0 disk/ra72-0.img
;
set rq3 lock
set rq3 rrd40
attach -r rq3 dist/your_vms_vax_install_cd.iso
;
set rl disable
set ts disable
set tq enable
set tq tk70
;
set dz disable
set vh enable
set vh lines=16
attach -am vh 3000
;
set xq enable
; DECnet Phase IV node 63.1
set xq mac=AA-00-04-00-01-FC
; this will probably be completely different depending on
; your simh release and host OS
att xq e1000g0
;;;; END
boot install media.
standalone:
$ backup dua3:vms073.b/save_set dua0:/init /list
halt, reboot.
set boot dua0
boot
install just these:
The following options will be provided:
OpenVMS library
OpenVMS optional
OpenVMS Help Message
DECnet Phase IV
SYSTEM: <whatever>
SYSTEST: <whatever>
FIELD: <whatever>
SCSNODENAME: CLBOOT
SCSSYSTEMID: 64513 (1024*[area]64 + [node]1)
skip loading PAKs for now
set UTC for timezone
(box reboots)
log in as SYSTEM
load your PAKs
edit SYS$SYSTEM:MODPARAMS.DAT
should have:
SCSNODE="CLBOOT"
SCSSYSTEMID=64513
VAXCLUSTER=0
add these:
WINDOW_SYSTEM=0
DUMPFILE = 0 ! Disallow AUTOGEN to create or size dump file
MIN_INTSTKPAGES=20
MIN_CHANNELCNT=255
MIN_SPTREQ=6000
MIN_GBLPAGES=100000
MIN_GBLPAGFIL=6024
MIN_GBLSECTIONS=550
MIN_NPAGEDYN=5374720
MIN_NPAGEVIR=23675136
MIN_PAGEDYN=274000
MIN_PQL_MBYTLM=40000
save the file: (^z)
apply these changes:
@sys$update:autogen getdata shutdown nofeedback
going to make SYSTEM's password not expire to make life easy
for the moment:
set def sys$system
run authorize
UAF> modify system/FLAG=NODISUSER/NOPWDEXPIR
^z
get the cluster configured:
set def SYS$MANAGER
@cluster_config_lan
1. ADD CLBOOT to existing cluster, or form a new cluster.
Will the LAN be used for cluster communications (Y/N)? y
Enter this cluster's group number: 4095
###http://h71000.www7.hp.com/doc/731final/4477/4477pro_003.html#cluster_group_number
#The cluster group number uniquely identifies each OpenVMS Cluster system
on a LAN. This number must be from 1 to 4095 or from 61440 to 65535.
#Rule: If you plan to have more than one OpenVMS Cluster system on a LAN,
you must coordinate the assignment of cluster group numbers among system
managers.
Enter this cluster's password: <whatever>
Will CLBOOT be a boot server [Y]? y
Enter a value for CLBOOT's ALLOCLASS parameter [0]: 1
#http://h71000.www7.hp.com/doc/84final/4477/4477pro_010.html#disk_alloclass
#6.2.2 Specifying Node Allocation Classes
#A node allocation class can be assigned to computers, HSG or HSV
controllers. The node allocation class is a numeric value from 1 to 255
that is assigned by the system manager.
#The default node allocation class value is 0. A node allocation class
value of 0 is appropriate only when serving a local, single-pathed disk.
If a node allocation class of 0 is assigned, served devices are named
using the node-name$device-name syntax, that is, the device name prefix
reverts to the node name.
#The following rules apply to specifying node allocation class values:
#When serving satellites, the same nonzero node allocation class value
must be assigned to the serving computers and controllers.
#All cluster-accessible devices on computers with a nonzero node
allocation class value must have unique names throughout the cluster. For
example, if two computers have the same node allocation class value, it is
invalid for both computers to have a local disk named DGA0 or a tape named
MUA0. This also applies to HSG and HSV subsystems.
#System managers provide node allocation classes separately for disks and
tapes. The node allocation class for disks and the node allocation class
for tapes can be different.
#The node allocation class names are constructed as follows:
#$disk-allocation-class$device-name
#$tape-allocation-class$device-name
#Caution: Failure to set node allocation class values and device unit
numbers correctly can endanger data integrity and cause locking conflicts
that suspend normal cluster operations.
#Figure 6-5 includes satellite nodes that access devices $1$DUA17 and
$1$MUA12 through the JUPITR and NEPTUN computers. In this configuration,
the computers JUPITR and NEPTUN require node allocation classes so that
the satellite nodes are able to use consistent device names regardless of
the access path to the devices.
#Note: System management is usually simplified by using the same node
allocation class value for all servers, HSG and HSV subsystems; you can
arbitrarily choose a number between 1 and 255. Note, however, that to
change a node allocation class value, you must shut down and reboot the
entire cluster (described in Section 8.6). If you use a common node
allocation class for computers and controllers, ensure that all devices
have unique unit numbers.
Does this cluster contain a quorum disk [N]? n
Do you want to run AUTOGEN now [Y]? y
<reboots>
set up LANCP to handle MOP booting
MCR LANCP
LANCP> LIST DEVICE/MOPDLL
LANCP> DEFINE DEVICE XQA0:/MOPDLL=ENABLE
(or on one line: MCR LANCP SET DEV XQA0:/MOPDLL=ENABLE)
... if you're running decnet and you want to populate LANCP with
nodenames/hw addrs
from NCP, run this...
@SYS$EXAMPLES:LAN$POPULATE.COM
READY TO ROCK!!!!
for every satellite, on the master:
@CLUSTER_CONFIG_LAN and select
1. ADD a VAX node to the cluster.
### installing VMS from a remote CD on a satellite-booted node:
$ mount/over=id $1$dua3:
(that's $ALLOCLASS$REMOTEDEVICE:)
$ MOUNT/FOREIGN DUA0:
$ backup $1$dua3:[000000]vms073.b/save_set dua0:/init /image/verify/list $
DISMOUNT DUA0:
$ MOUNT/OVER=ID DUA0:
$ COPY $1$dua3:[000000]vms073.* DUA0:[000000]
### if you want DECWindows you'll need DECW073.* too
$ DISMOUNT DUA0:
$ @SYS$SYSTEM:SHUTDOWN
(make sure to pick REMOVE_NODE)
SET BOOT DUA0:
BOOT
...
set up the satellite:
### FROM http://labs.hoffmanlabs.com/node/192
OpenVMS Satellite Bootstrap with LANCP
LANCP is used by the CLUSTER_CONFIG_LAN.COM to configure the MOP satellite
bootstrap.
MOP downloads can be performed using LANCP. LANCP is available on V6.2 and
later (the following shows V8.3 syntax), and can be enabled to service
cluster and DECserver MOP service (download) requests.
An OpenVMS Alpha satellite at the hardware address 01-02-03-04-05-06:
$ RUN SYS$SYSTEM:LANCP
SET NODE HLSAT1 -
/ADDRESS=01-02-03-04-05-06
/FILE=APB.EXE -
/ROOT=HL_ALPHA_SYS: -
/BOOT_TYPE=ALPHA_SATELLITE
An OpenVMS VAX satellite at the hardware address 11-22-33-44-55-66:
$ RUN SYS$SYSTEM:LANCP
SET NODE VAXSYS/ADDRESS=11-22-33-44-55-66 -
/FILE=NISCS_LOAD.EXE -
/ROOT=HL_VAX_SYS: -
/BOOT_TYPE=VAX_SATELLITE
The /BOOT_TYPE keyword value is ALPHA_SATELLITE, I64_SATELLITE,
VAX_SATELLITE, and (for everything else) OTHER.
To enable MOP operations on a specific or on all network devices, see the
LANCP command DEFINE DEVICE /ALL /MOPDLL=NOEXCLUSIVE, or potentially
/MOPDLL=(ENABLE,EXCLUSIVE)
OpenVMS I64 systems and Integrity servers do not use MOP in any form in
the console bootstrap processing. To perform a satellite bootstrap of an
Integrity Itanium host, you must establish the necessary settings within
the EFI console for a network bootstrap, and must configure a bootp and
tftp and PXE server to respond to the EFI console request; a PXE server.
OpenVMS I64 and OpenVMS Alpha systems running V8.* releases can service
PXE requests from OpenVMS I64 hosts.
These download services are typically implemented using the host-based
InfoServer support.
### END
-Ryan
Hello!
What's wrong Cory? Peeved that you did not think of it first?
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Wed, Oct 2, 2013 at 7:35 PM, Cory Smelosky <b4 at gewt.net> wrote:
On Wed, 2 Oct 2013, Sampsa Laine wrote:
I understand BQT's point about keeping the signal/noise ratio good on the
main technical HECnet list, but sometimes random conversations start etc.
For these cases I created hecnetrandom at googlegroups.com, open to anyone (if
spam becomes an issue I'll tighten the security a tad)
This is NOT a replacement for this awesome mailing list that I have
enjoyed and learnt many thing from over nearly a decade. I just feel that
there is a community spirit in HECnet that would probably be best expressed
on another mailing list.
Eurgh. Can you pick something OTHER than google groups? ;)
The address for the group is hecnetrandom at googlegroups.com , just send any
mail and you will be subscribed to it.
I think this will lower the random noise in the main HECnet list yet could
be amusing for the people who enjoy the social aspect of retrocomputing /
networking..
sampsa <sampsa at mac.com>
mobile +358 40 7208932
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On 10/02/2013 06:57 PM, Cory Smelosky wrote:
Write it directly.
Backup can do that right? I don't have to right disk images to disk in
VMS too often. ;)
No. This is what I've done to write tape images to tapes:
$ INIT/ERASE MUA0: ""
$ MOUNT/FOREIGN/BLOCK=512 MUA0:
$ COPY <filename> MUA0:
$ DISMOUNT/UNLOAD MUA0:
Can anyone (Brian S?) say if this will work with disk as the
destination device as well? I'd guess yes, but I haven't done it
myself, at least not recently enough that I remember.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Hello!
Does this mean that your new space would be interested in my wild
attempts at humor aimed at two to three individuals in this space?
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Wed, Oct 2, 2013 at 7:32 PM, Sampsa Laine <sampsa at mac.com> wrote:
I understand BQT's point about keeping the signal/noise ratio good on the main technical HECnet list, but sometimes random conversations start etc. For these cases I created hecnetrandom at googlegroups.com, open to anyone (if spam becomes an issue I'll tighten the security a tad)
This is NOT a replacement for this awesome mailing list that I have enjoyed and learnt many thing from over nearly a decade. I just feel that there is a community spirit in HECnet that would probably be best expressed on another mailing list.
The address for the group is hecnetrandom at googlegroups.com , just send any mail and you will be subscribed to it.
I think this will lower the random noise in the main HECnet list yet could be amusing for the people who enjoy the social aspect of retrocomputing / networking..
sampsa <sampsa at mac.com>
mobile +358 40 7208932
On Wed, 2 Oct 2013, Sampsa Laine wrote:
I understand BQT's point about keeping the signal/noise ratio good on the main technical HECnet list, but sometimes random conversations start etc. For these cases I created hecnetrandom at googlegroups.com, open to anyone (if spam becomes an issue I'll tighten the security a tad)
This is NOT a replacement for this awesome mailing list that I have enjoyed and learnt many thing from over nearly a decade. I just feel that there is a community spirit in HECnet that would probably be best expressed on another mailing list.
Eurgh. Can you pick something OTHER than google groups? ;)
The address for the group is hecnetrandom at googlegroups.com , just send any mail and you will be subscribed to it.
I think this will lower the random noise in the main HECnet list yet could be amusing for the people who enjoy the social aspect of retrocomputing / networking..
sampsa <sampsa at mac.com>
mobile +358 40 7208932
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
I understand BQT's point about keeping the signal/noise ratio good on the main technical HECnet list, but sometimes random conversations start etc. For these cases I created hecnetrandom at googlegroups.com, open to anyone (if spam becomes an issue I'll tighten the security a tad)
This is NOT a replacement for this awesome mailing list that I have enjoyed and learnt many thing from over nearly a decade. I just feel that there is a community spirit in HECnet that would probably be best expressed on another mailing list.
The address for the group is hecnetrandom at googlegroups.com , just send any mail and you will be subscribed to it.
I think this will lower the random noise in the main HECnet list yet could be amusing for the people who enjoy the social aspect of retrocomputing / networking..
sampsa <sampsa at mac.com>
mobile +358 40 7208932