1	Aufgabenstellung
Zur resourcenschonenden und produktionsunabhängigen Installation von S/390-Software (zLINUX, OS/390-Test) soll versucht werden, ein OS/390-System unter dem S/390-Emulator Hercules zu erstellen.
Diese Beschreibung stellt die Installationserfahrungen auf dem PC des Autors (derzeit PIII, 500MHz, Win2K) dar.
2	Software
2.1	CYGWIN
Das GNU-Produkt CYGWIN stellt einen UNIX-Emulator für Windows-Systeme dar. Damit kann bestimmte Software (z.B. LINUX-Pakete) direkt auf einem Windows-PC laufen oder sehr einfach darauf portiert werden.
Das Produkt wird installiert, indem das SETUP.EXE von http://www.cygwin.com heruntergeladen und auf dem PC mit Administratorrechten ausgeführt wird.
Der Autor benutzte die Methodik, erst einen Download from Internet, dann einen Install from local directory durchzuführen.
2.1.1	Download
Im weiteren Ablauf der Installation wird zunächst der Archiv-Pfad der Installationpakete, dann die Internet-Connection-Methode abgefragt. Bei zweiterem wurde angegeben, die IE5.5 Einstellungen zu benutzen. Der PC muss dann an der Firewall angemeldet sein.
Als Mirrorserver wurde ftp.uni-erlangen.de ausgewählt. Von dort wird die Paketliste heruntergeladen.
Es stellte sich im weiteren Verlauf heraus, dass zwei non-default-libs explizit für den Hercules-Emulator zur Installation ausgewählt werden müssen:
libbz2_0	Vers. 1.0.2-1
pcre		Vers. 3.7-1
2.1.2	Installation
Die Installation erfolgt nach dem Download, als Programmverzeichnis wurde
C:\Programme\cygwin
angegeben. Dies ist insofern interessant, als dort zunächst auch die „typischen“ UNIX-Verzeichnisse (/usr, /home usw.) angelegt werden.
Wenn alles soweit installiert ist, wird auf dem Desktop ein CYGWIN-Icon erstellt, mit dem eine bash-shell aufgerufen werden kann, die in ein /home/<username> Unterverzeichnis läuft.
2.2	Hercules
Der Hercules-Emulator wurde von der Website http://www.conmicro.cx/hercules/ heruntergeladen, und zwar das Paket http://www.conmicro.cx/hercules/hercules2165-i686f.exe (PII mit Fish-Thread-Optimierung).
Das Paket wird mit PKZIP entpackt und zwar in den Pfad
C:\Programme\hercules
Damit dieses Verzeichnis auch von CYGWIN nach Programmen durchsucht wird, wurde im cygwin-Home-Directory des UAHAAG1-Benutzers (/home/UAHAAG1) eine Datei .profile mit der Zeile PATH=%PATH%;/cygdrive/c/Programme/hercules erstellt. Später stellte es sich heraus, dass es wg. diverser dll´s mehr Sinn macht, stattdessen den DOS/Windows PATH-Befehl zu modifizieren.
Damit könnte der Emulator prinzipiell in einer CYGWIN bash-shell aufgerufen werden, wenn nicht die Konfigurationsdateien sowie das S/390-Operatingsystem fehlen würden.
2.3	Utilities
Damit das bestehende OS/390 des DSV sinnvoll für den Emulator eingesetzt werden kann, muss es auf dem Großrechner abgezogen werden. Hierfür stehen zwei Alternativen offen, von denen die zweite benutzt wurde:
2.3.1	TAPECOPY/RAWSTAPE
Diese beiden S/390 Assemblerprogramme sind im Hercules-Sourcenpaket im Unterverzeichnis ./util als fertiger Compile-Link-Go Job enthalten und werden mit der ASCII-Option per FTP in ein FB80-PDS des OS/390 übertragen.
Das TAPECOPY-Programm liest RECFM-U Dateien (DFDSS-Fulldump) auf Platte, von wo sie auf den PC transferiert werden können.
Das RAWSTAPE-Programm packt im Gegenzug die auf dem PC erstellten und ins MVS transferierten AWS-Dateien (P/390-Format, virtuelle Tapedatei) in eine RECFM-U aus.
Damit könnten Fulldumps in beiden Richtungen kopiert werden.
2.3.2	CCKDDUMP
Das Program CCKDDUMP ist ebenfalls ein S/390 Assemblerprogramm, welches von einem S/390-Plattenvolser einen Dump erstellt, komprimiert und in einem komprimierten Hercules CCKD-File ablegt, welches dann per FTP auf den PC geladen werden kann.
Der Vorteil ist, dass diese Datei auf dem PC sofort eine Platte darstellt, von der dann gebooted (IPL´d ;-) werden kann und diese Datei nur einen Bruchteil des Platzbedarfs der realen Platte hat.
2.4	Dump des OS/390 DSV-Notsystems
Damit CCKDDUMP im OS/390 gewandelt werden kann, muss zuvor die zlib (von http://www.gzip.org/zlib/ heruntergeladen werden) im OS/390 installiert werden.
Hinweise hierzu sind unter http://www.conmicro.cx/hercules/cckddasd.html erhältlich, folgend die Schritte im Einzelnen:
1.	Ein aktueller Stand der ZLIB wird von http://www.gzip.org/zlib/   heruntergeladen und binary ins OpenEdition gebracht (tar.gz)
2.	Dekomprimieren mit gunzip, entpacken mit tar -xvf
3.	Konvertieren mit iconv -f ISO8859-1 -t IBM-1047 <name>  >  <neupfad/name> von ASCII nach EBCDIC (Achtung: Output-Redirector-Zeichen muss sein !).
Tip: ich habe mir ein Shellscript gemacht, welches den
iconv -f ISO8859-1 -t IBM-1047 $1 > ../neu/$1
absetzt. Das ist nun für alle *.c und *.h durchführen.
4.	Diese umgesetzten Member z.B. per FTP in OS/390 PDS stellen. Transfermode ist dabei EBCDIC. Die .c-Files kommen in ein „libname.C“, die .h-Files in ein „libname.H“ PDS
5.	Die unter http://www.conmicro.cx/hercules/cckddasd.html beschriebenen Jobs absetzen. 
Achtung ! Vorher notwendige Modifikationen an ZCONF.H machen :
pragma map von compress auf COMPRESS, von compress2 auf COMPRES2, von uncompress auf UNCOMPRE

Ich habe unsere Versionen in die UAHAAG1.ZLIB.CNTL Dateien gestellt:
CCKDDZLI - wandelt die in den .C und .H PDSen stehenden Sourcen in eine .OBJ Bibliothek um
CCKDDZLP - macht einen "Prelink" (was immer das ist...)
CCKDDASM - wandelt das CCKDDUMP-Programm um.
6.	Die Bibliothek, in der das CCKDDUMP Loadmodule steht, muss für die Ausführung APF-authorisiert werden (SET PROG, SETPROG APF), sonst kommt es zu den bekannten Abends.
Für den weiteren Fortgang wurde mit CCKDDUMP die NOT280-Platte (OS/390 Einplatten-Notsystem) in eine Datei auf der Workplatte M0034C gestellt. Das Ergebnis war eine PS-Datei mit 6200 Tracks (350 Mbyte). Diese wurde mit FTP und binary auf den PC transferiert.
2.5	Hercules und Netzwerk
Da die im folgenden beschriebenen Fishpack.dll und tuntap32.dll im Windows-Suchpfad liegen müssen, wurde im Win2K mit der Systemsteuerung die PATH-Angabe um C:\Programme\hercules erweitert und diese dll´s dorthinein kopiert. Damit stehen auch alle Hercules-Programme ohne weitere Spezifikation zur Verfügung.
2.5.1	WinPcap (virtueller Windows-Netzwerkadapter)
Die Netzwerkkomponente CTCI-W32 wurde erst später im Rahmen der zLINUX-Installation eingebaut. Dazu muss zuerst ein Windows-Treiber heruntergeladen werden, der einen virtuellen Netzwerkadapter unter Windows simuliert: http://winpcap.polito.it/install/bin/WinPcap_2_3.exe. Dieses Programm installiert den Treiber beim Aufruf.
Hinweis: ein Versuch mit der WinPcap_3_0 scheiterte bereits beim Aufruf des hercules.
Der virtuelle Adapter kann nun zwar innerhalb des Windows-Rechners angesprochen werden. Soll er aber über das Firmennetz erreichbar sein, muss im Windows ein Registry-Eintrag gesetzt werden
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"IPEnableRouter"="1" (WIN2K/XP)
[HKEY LOCAL MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]
"EnableRouting"="1" (Win98/ME)
Damit wird Windows zu einem „IP-Forwarder“ und kann von Hercules aufs Netz routen. Im Netz selber müssen die Router einen Host-Eintrag erhalten (manuell oder von Windows über RIP).
2.5.2	Problem bei lokalen TCP-Verbindungen
Die lokale Verbindung zwischen Win2K-Trägersystem und hercules (172.16.19.250 und 172.16.19.251) funktionierte zunächst nur für ping und traceroute, ein telnet bzw. ftp waren in keiner Richtung möglich. Das Problem trat nicht auf, wenn von einem anderen Gerät aus auf Win2K oder hercules zugegriffen wurde.
Dies lag an einer Konfigurationseinstellung der 3com-Netzwerkkarte, bei der im Win2K-Treiber die Einstellung war, dass die IP-Prüfsummenberechnung auf der Kartenhardware durchführt werden.
Um das Problem zu beheben mussten im Win2K in den Netzwerkeinstellungen der 3com-Karte (LAN-Anbindung, 3com Ethernet, Konfigurieren, erweiterte Parameter) die Parameter „empf. Prüfsummenverschiebung“ und „übertr. Prüfsummenverschiebung“ von „aktiviert“ auf deaktiviert“ umgestellt und das Win2K rebootet werden.
Ping und traceroute scheinen also nur das Ankommen der Pakete, nicht aber den Paketinhalt zu verifizieren, die mit den obigen Einstellungen zunächst ohne Prüfsummen ausgetauscht wurden, da die Pakete ja nicht übers Netz, also auch nicht durch die Prüfsummenhardware der Karte liefen.
2.5.3	Aktivierung von WinPCap
Die für CTCI-W32 notwendige packet.dll wird nun nicht automatisch gestartet sondern muss einmal nach Start des Windows mit dem Programm testapp.exe aus dem Developper-Paket http://winpcap.polito.it/install/bin/WPdpack_2_3.zip aufgerufen werden (nur dieses Programm testapp.exe entpacken, am besten unter C:\Programme\hercules !).
Achtung: testapp.exe fragt den Netzwerkadapter ab und bringt dann endlose Traces, das Programm wurde an dieser Stelle mit CTRL-C abgebrochen !
Dieses Programm testapp.exe muss mit Administratorrechten aufgerufen werden (z.B. Shift-rechteMaustaste, „Ausführen als“), damit es den NPF-Treiber installieren darf. Geprüft wird die Funktion des Treibers durch „START“,„Ausführen“,msinfo32,“Softwareumgebung“,“Treiber“. In der Liste muss ein Netgroup Packet Filter („npf“ oder „NPF“) erscheinen.
Es zeigte sich, dass testapp.exe nur einmal nach Installation des Treibers aufgerufen werden muss, bei weiteren Win2K Restarts wird der npf-Treiber dann automatisch geladen.
2.5.4	Fishpack.dll
Anschliessend kann die Fishpack-Dll 
http://home.sprintmail.com/~dtrout/Hercules/FishPack-1.0.2.288-dll.zip
installiert werden. Diese wurde ebenfalls in C:\Programme\hercules kopiert.
2.5.5	TunTap32.dll
Ebenso wurde die TunTap32.dll
http://home.sprintmail.com/~dtrout/Hercules/TunTap32-1.0.2.360-dll.zip in C:\Programme\hercules installiert.
2.5.6	Hercules.cnf
Der Adapter wurde in die hercules.cnf als 
0C00    3088   CTCI-W32 172.16.19.251 00-50-DA-36-BA-23 1024 64
0C01    3088   CTCI-W32 172.16.19.251 00-50-DA-36-BA-23 1024 64
eingetragen. 172.16.19.251 war dabei die virtuelle Adresse des Hercules und die Macadresse die des Windows-Adapters (ipconfig /all).
In einem zweiten Versuch funktionierte auch die Win-IP-Adresse anstelle der MACADD:
0C00    3088   CTCI-W32 172.16.19.251 172.16.19.250 1024 64
0C01    3088   CTCI-W32 172.16.19.251 172.16.19.250 1024 64
Das Paar 0C00/0C01 ist im OS/390 bereits für die Cryptoboxen als 3088 definiert, daher könnte OS/390 den Adapter ebenfalls nützen.
3	Laufzeit
3.1	Erster Start des Hercules
Vor dem ersten Start des Hercules wurde eine Sampledatei der hercules.cnf aus dem Internet geladen und bearbeitet. In dieser Datei stehen die Parameter und Deviceinformationen. 
Die Adresse der EXTRA!-Emulation kann über den Devicetype festgelegt werden. Normalerweise wird sonst die Liste der in hercules.cnf eingetragenen 3270-Adressen von vorneher aufgefüllt, was nicht immer sinnvoll ist. Für eine feste Zuordnung wird im EXTRA! unter Optionen-Einstellungen-Verbindung-Allgemein-Bearbeiten-Terminal/Gerätetyp der voreingestellte Wert IBM-3279 so ergänzt: IBM-3279@0A81. Damit wird diese Session fest der Deviceadresse 0A81 zugeschlagen.
Der erste Start des Hercules begann mit der Meldung, dass eine Datei „tuntap32.dll“ nicht gefunden wird. Dies kann an dieser Stelle ignoriert werden, die tuntap32.dll wird normalerweise im Rahmen der CTCI-W32 (Channel-to-Channel-Link über TCPIP) benutzt und hier noch nicht benötigt.
Damit die Meldung nicht mehr kommt, wurde die tuntap32.dll aus TunTap32-1.0.2.360-dll.zip sowie die FishPack.dll aus FishPack-1.0.2.288-dll.zip in das Verzeichnis C:\Programme\hercules entpackt.
Um die Meldung in eine Datei zu bekommen, muss der Hercules mit hercules 0>a0 1>a1 2>a2 gestartet werden, da der Emulator sonst sofort den Bildschirm löscht.
Ein erster IPL wurde gemacht, indem das mit EXTRA! aus VM/ESA geladene IPL DDRXA S als Datei IPL.DDRXA.rdr mit 00C zugeordnet wurde. Hier zeigt sich das Problem, dass EXTRA! 6.5 den Bildschirm blockiert (TN3270 !). Mit „Verbindung trennen“ und „Verbindung wiederherstellen“ konnte dieses Problem gelöst werden
3.2	Erster Start von OS/390
Die zuvor vom OS/390 transferierte CCKDDUMP-Datei des DSV-Notsystems wurde dem Emulator als Adresse 459 bekannt gemacht.
Die Konsolzuordnung wurde bereits in Kap. 3.1 behandelt.
Ein IPL 459 brachte zunächst einen System-Abend 7A7A (A7A=ServiceProcessor-Problem), der davon herrührte, dass Hercules per default im ILF-Mode läuft (Integrated Linux Facility), auf dem aus Lizenzgründen kein OS/390 gestartet werden kann. Die Angabe des Parameters PGMPRDOS LICENSED in hercules.cnf schaltete diesen ILF-Mode dann ab.
Ein weiteres Problem war, dass auf der Console bei jeder neuen Zeile die Uhr erschien. Diese konnte zwar vor jedem Befehl mit der Taste Abruf (SYSREQ) weggedrückt werden, dies war aber lästig. Das Problem war jedoch schon vom Einsatz der IBM 2074-Steuereinheit bekannt und wird behoben indem die EXTRA!-Sessiondefinition der Emulator-Konsolsession (z.B. C:\programme\E!98\sessions\HERCMVS.EDP) in der [Terminal] Section durch den Parameter WCCResetClock=TRUE ergänzt wird.
4	zLINUX auf Hercules
4.1	Laden der Pakete
Von http://www.marist.edu/linuxvm/ wurden folgende Pakete heruntergeladen:
http://linux390.marist.edu/download/inst.pdf	Installation Guide [IGD]
http://linux390.marist.edu/download/image.tape.bin	IPL´able Tape-Image des Kernel
http://linux390.marist.edu/download/initrd.bin.gz	Initial RAM-Disk
http://linux390.marist.edu/download/initfs_small.tgz	Small Root-Filesystem (zum testen)
http://linux390.marist.edu/download/initfs_big.tgz	Big Root-Filesystem (optional) BIG
4.2	IPL zLINUX
4.2.1	Virtuelles Tapefile
Für den ersten IPL eines zLINUX wird ein virtuelles Tapefile (IBM-OMA-Format) benötigt, welches aus dem bootable Kernel, einem Parameterfile und einer RAMDISK besteht.
Virtuelle Tapefiles bestehen zunächst aus einer Beschreibungsdatei, welche für Hercules in einem Unterverzeichnis TAPES des beim Hercules-Aufruf aktuellen Verzeichnisses stehen. Diese Datei muss im sogenannten TDF-Format erstellt werden und enthält u.a. die Verweise auf die einzelnen „Banddateien“.
Nach diversen Beispielen wurde daher eine Datei /hercules/TAPES/zLINUX.boot.tdf mit folgendem Inhalt angelegt:
@TDF
TAPES/zLINUX/image.tape.bin		FIXED RECSIZE 1024
TAPES/zLINUX/parmfile.asc		TEXT  RECSIZE 1024
TAPES/zLINUX/initial.ramdisk_initrd.bin.gz FIXED RECSIZE 1024
TM
TM
EOT
4.2.2	Boot-Parameter
Der Clou ist, dass die Bootparameterdatei (parmfile.asc) in ASCII gehalten werden kann, da Dateien mit der Option TEXT von Hercules Tapehandler automatisch von ASCII nach EBCDIC umgesetzt werden.
Die Datei parmfile.asc enthielt zunächst den String:
 root=/dev/ram0 ro
Die virtuelle Banddatei wurde in der hercules.cnf als
0200    3420   /cygdrive/d/uahaag1/hercules/TAPES/zLINUX.boot.tdf
definiert, und anschliessend ein IPL 200 durchgeführt.
Die erste Linux-Konsole ist dabei die Hardwarekonsole. Hier muss man aufpassen, dass man kein Endlos-Command wie z.B. ping absetzt (bzw. mit –c 3 begrenzt), da kein CTRL-C möglich ist => es hilft dann nur noch stopall, quit, Neuaufruf ! Befehle an zLINUX werden in der Hercules-Hardwarekonsole mit einem voranstehenden Punkt (.) eingegeben.
4.2.3	Netzwerk über CTC
Im Rahmen des Startups von Compressed RAMDISK werden zunächst die Netzwerkparameter für die CTC-Verbindung abgefragt. Wenn alle Daten eingegeben wurden, wird die Konfiguration zur Überprüfung angezeigt und man muss mit YES bestätigen.
Configuration will be:
Host name        : w0273herc
IP address       : 172.16.19.251
Net mask         : 255.255.255.0
Peer IP address  : 172.16.19.250
Net address      : 172.16.19.0
DNS IP address   : 172.16.160.250
DNS search domain: dsv-gruppe.de
Is this correct (Yes/No) ?
Da die Verbindung zwischen dem Windows-Trägersystem und zLINUX per Telnet/FTP nicht funktionierte (s. Kap. Fehler! Verweisquelle konnte nicht gefunden werden.), wurde für die Installation über den Umweg „Telnet zu c10test1“, „Telnet von c10test1 zurück auf 172.16.19.251“ gearbeitet.
4.3	Platten formatieren
4.3.1	Erstellen der Volumes
Mit dem Hercules-Programm dasdinit wurden in einer CYGWIN-bash zunächst die cckd-Laufwerke ZLIN01.cckd und ZLIN02.3390 (letzteres für den Swapspace uncompressed mit 200 Cyl) angelegt.
dasdinit –z ./disk/ZLIN01.cckd 3390-3 ZLIN01
dasdinit  ./disk/ZLIN02.3390 3390-3 ZLIN02 200
Diese Platten können dem Hercules dynamisch mit dem Attach-Command untergeschoben werden, wurden aber auch in die hercules.cnf eingetragen. Nach einer verpatzten Installation erwies es sich als sinnvoll, die Root-Platte mit einem Shadowfile im Hercules zu definieren, damit werden Updates auf eine eigene Windows-Datei ausgelagert und können sehr einfach wieder entfernt werden. Wohlgemerkt: dies ist keine zLINUX-Funktion sondern eine Funktion des Hercules-Emulators und damit unabhängig vom S/390-Betriebssystem !
Hinweis: die Möglichkeit eines Shadowfile wurde hier zwar durch die Parameterangabe eingestellt, das Shadowfile wird aber erst erzeugt, wenn auf das Basisfile nicht zugegriffen werden kann, indem z.B. noch der Parameter ro (readonly) eingefügt wird:
attach 0127 3390 /cygdrive/d/uahaag1/hercules/disk/ZLIN01.cckd cache=60 sf=/cygdrive/d/uahaag1/hercules/disk/ZLIN01.cckd_1 ra=2 ro
attach 0128 3390 /cygdrive/d/uahaag1/hercules/disk/ZLIN02.3390 cache=60 sf=/cygdrive/d/uahaag1/hercules/disk/ZLIN02.3390_1 ra=2
4.3.2	Bekanntmachen der Volumes
Damit zLINUX diese Platten erkennt, muss im parmfile.asc folgender String eingetragen werden:
dasd=0127-0128 root=/dev/ram0 ro
Die weiteren Schritte wurden lt. Broschüre [IGD], „Chapter 4. Installation – native single image and LPAR – OS/390“ durchgeführt.
Die zuvor mit Hercules-dasdinit erstellten Platten wurden in einer zLINUX-shell formatiert (das ZLIN02 wird dabei als 200 Cyl Fullpack-Swap genutzt)
dasdfmt -b 4096 -f /dev/dasda
mke2fs -b 4096 /dev/dasda1
dasdfmt -b 4096 -f /dev/dasdb
mkswap /dev/dasdb1
chmod 600 /dev/dasdb1
swapon /dev/dasdb1
(Prüfen mit cat /proc/dasd/devices bzw. cat /proc/swaps)
4.3.3	BIG-Filesystem
Die so formatierten compressed-ckd-Plattendateien hatten auf dem Windows-Trägersystem zunächst eine Grösse von 8 MByte. Auf die ZLIN01 wurde das „Big“-Filesystem BIG wie folgt kopiert:
1.	Anlegen eines HFS im S1M3 mit ca. 120 MByte bzw. CYL(100 50)
2.	Mounten dieses Filesystems im S1M3 als /u/UAHAAG1/tmp und Transfer des BIG Filesystems mit FTP binary vom Windows-Download-Verzeichnis nach S1M3 auf dieses Filesystem.
3.	Im S1M3 SYS1.TCPPARMS(EXPORTFS) mit dem Mount-Verzeichnis (/hfs vorangestellt, -ro nachgestellt) eintragen und den NFS-Daemon mit F MVSNFS,EXPORTFS zu einem Refresh veranlassen.
4.	In der zLINUX-Rootsession zuerst mit mkdir /mnt/s1m3 einen Mountpoint einrichten, dann mit mount 172.25.1.133:/hfs/u/UAHAAG1/tmp /mnt/s1m3 durchführen.
5.	Mit mkdir /mnt/dasda1 und mount /dev/dasda /mnt/dasda das ZLIN01-Volume mounten
6.	Mit folgenden Befehlen das BIG Filesystem auf die ZLIN01-Volume entpacken:
cd /mnt/dasda1
tar xfzBp /mnt/s1m3/big.root.filesys_initfs_big.tgz
7.	Der Swapspace wird durch die Befehle
mkswap /dev/dasdb1
4.3.4	Anpassungen des BIG-Filesystem
Die fstab des BIG-Filesystems muss noch angepasst werden. Dazu wird ein Mountpoint erstellt (mkdir /mnt/dasda1) und das BIG-Filesystem gemounted (mount /dev/dasda1 /mnt/dasda1). Dort wird unter /mnt/dasda1/etc die fstab wie folgt modifiziert (die Zeile mit dem swapspace):
/dev/dasda1	/	ext2	defaults ,errors=remount-ro	0	1
/dev/dasdb1	swap	swap	defaults	0	0
none	/proc	proc	defaults	0	0
Die beim RAMDISK-Boot erstellen Konfigurationsdateien müssen noch in das BIG-Filesystem kopiert werden:
cp -rp /etc/sysconfig/network-scripts/ifcfg-ctc* /mnt/dasda1/etc/sysconfig/network-scripts/
cp -rp /etc/resolv.conf /mnt/dasda1/etc/
Hinweis: es erwies sich, dass beim folgenden IPL von ZLIN01 die Netzwerkparameter erneut abgefragt werden. Ob das Kopieren der beiden Konfig-Dateien an dieser Stelle überhaupt sinnvoll ist, wurde nicht getestet.
4.3.5	Vorbereiten und Durchführen IPL von ZLIN01
Vor dem IPL wird das Shadowfile für die ZLIN01 aktiviert. Damit können Änderungen an dieser Platte ab diesem Zeitpunkt einfach durch Löschen des Shadowfiles zurückgenommen werden. Dazu wird in hercules.cnf der Eintrag für die 127-Platte mit „ro“ ergänzt (s. auch Kap. 4.3.1).
Entsprechend der Broschüre [IGD] Chapter 4 wechselt man mit cd /mnt/dasda1/boot in das Bootverzeichnis des BIG-Filesystems.
Dort wird die bereits vorhandene IPL-Parameterdatei parmline angepasst:
dasd=0127-0128    root=/dev/dasda1 ro noinitrd
Anschliessend kann das Erstellen des IPL-Record (boot record) mit dem silo getestet:
/mnt/dasda1/sbin/silo -f image -d /dev/dasda -p parmline -b ipleckd.boot
und, sofern keine Probleme aufgetreten sind, durch Angabe des t2-Parameters auf die Platte geschrieben werden:
/mnt/dasda1/sbin/silo -f image -d /dev/dasda -p parmline -b ipleckd.boot –t2
Nach diesen Arbeiten kann das System mit shutdown oder halt angehalten (disabled wait) und mit IPL 127 neu gestartet werden.
Die Netzwerkparameter (s. Kap. 4.2.3) werden erneut abgefragt und zwar nur einmal, d.h. beim nächsten IPL werden die hier eingegebenen Parameter automatisch benützt !
An dieser Stelle ist nun das zLINUX mit dem BIG-Filesystem installiert, ein Apache Webserver, ein X-Client usw. werden mitgestartet, die DNS-Auflösung ist aktiv.
5	zLINUX auf VM/ESA 2.2
5.1	Bla
Bla
5.2	Bla
5.2.1	Readerfile
Bla
A. Haag, IVP1