LRZ-Mitteilungen Oktober 1998

Verteiler für dieses Rundschreiben

Diese Mitteilungen sind im Benutzerarbeitsraum und in der Anmeldung im LRZ-Gebäude sowie an den Außenstationen des LRZ erhältlich und über

abrufbar. Sie werden auch an alle Lehrstühle der Münchner Hochschulen sowie an alle anderen bayerischen Hochschulen versandt. Übersichten über die Netzbenutzung am LRZ sind über

erhältlich.

---

Einige wichtige Telefonnummern:

LRZ-Hotline: für alle Fragen	(089) 289-28800
LRZ-Anmeldung ( Benutzersekretariat)	(089) 289-28784 und (089) 289-28886
	Telefax: (089) 289-28761

---

Herausgeber:

Anschrift:

Redaktion:

Weitere Informationen zu folgenden Terminen finden Sie in den Beiträgen der vorliegenden bzw. der angegebenen Mitteilungen

13.11.1998	Ablauf der Anmeldefrist für die Veranstaltung Statistikpakete: Firmenpräsentationen
16.11.1998	Neustrukturierung der Maildienste im MHN
26.11.1998	Personalversammlung
30.11.1998	Ablauf der Anmeldefrist zur Teilnahme an einer Campuslizenz für Insure++
02.12.1998	Benutzerdiskussion
03.12.1998	Statistikpakete: Firmenpräsentationen
08.12.1998	Einführungskurs: SGML und Stylesheets
10.12.1998	Benutzerdiskussion
31.12.1998	Betriebsende des Rechners Cray Y-MP EL
31.12.1999	Endgültiger Ablauf der Möglichkeit, das Jahr-2000-Problem in den Griff zu bekommen! (Siehe Zum Jahr-2000-Problem in den LRZ-Mitteilungen Nr.4 vom August 1998)

Beachten Sie bitte auch unser aktuelles Kursangebot! in den LRZ-Mitteilungen Nr. 4 vom August 1998

Im Dezember 1998 finden wieder zwei Benutzerdiskussionen statt, die sich mit Fragen des Betriebs der LRZ-Systeme, des Hochschulnetzes, der sonstigen Dienstleistungen und mit der allgemeinen Entwicklung des Rechenzentrums beschäftigen werden. Termine sind:

und

Wir bitten unsere Benutzer, von diesem Angebot zur direkten Diskussion mit zuständigen LRZ-Mitarbeitern regen Gebrauch zu machen.

Wegen einer Personalversammlung der Beschäftigten des Leibniz-Rechenzentrums werden am

die Beratung und das Benutzersekretariat geschlossen und Mitarbeiter des LRZ nicht erreichbar sein. Die Zugänglichkeit zu den Rechnern und Arbeitsräumen wird dabei jedoch nicht eingeschränkt. Die Hotline ist in dieser Zeit mit einem "Notdienst" besetzt. Wir bitten um Ihr Verständnis.

Das LRZ hat einige Firmen eingeladen, ihre Statistikpakete vorzustellen.

Die diesjährige Veranstaltung des LRZ zum Thema Statistik setzt sich als Ziel, einige unter unserer Benutzerschaft weniger bekannte Programmpakete vorzustellen. Aus diesem Grunde nehmen bei dieser Veranstaltung Vertreter von im LRZ-Bereich gut etablierten Programmen wie SAS und SPSS nicht teil: Dafür aber werden Pakete vorgestellt, für die einige LRZ-Benutzer Interesse gezeigt haben:

Für die letzten drei Pakete sind Campus-Vereinbarungen schon abgeschlossen bzw. implementiert worden. Im Falle von S-Plus hoffen wir durch diese Veranstaltung genügend Interesse zu wecken, daß auch dort eine solche Vereinbarung zustande kommen kann.

Diese Veranstaltung findet statt:

Wir bitten um Voranmeldungen bis spätestens Freitag, den

bei Frau Bezold-Chatwin, Tel. (089) 289-28716 oder bei mir.

Die Berechtigung zur Nutzung von LRZ-Systemen (mit persönlichem Login) wird im Rahmen eines DV-Projekts erteilt, das von der jeweiligen Einrichtung jährlich verlängert werden muß.

Ein DV-Projekt am LRZ ist als organisatorischer Rahmen notwendig, wenn Angehörige einer Einrichtung oder von dieser Einrichtung (etwa im Rahmen von Diplomarbeiten) betreute Studenten LRZ-Rechner benutzen möchten, für die ein persönliches Login erforderlich ist. Dagegen sind die allgemeinen Dienstleistungen des LRZ wie Beratung in DV-Fragen, Beschaffung von Software oder Versand der LRZ-Mitteilungen nicht an die Existenz eines DV-Projekts gebunden. Die Verlängerung von sogenannten Studentenkennungen, die vom LRZ direkt vergeben werden, ist von dieser Aktion für DV-Projekte von Einrichtungen nicht betroffen und erfolgt unabhängig davon, jeweils semesterweise.

Die Aufforderung zur Verlängerung für das Jahr 1999 mit den üblichen Unterlagen (Anschreiben, Übersicht über am LRZ gespeicherte Daten, Formblätter usw.) wird in den nächsten Wochen an die Leiter der jeweiligen Einrichtungen verschickt; die derzeitigen Master User werden per E-Mail davon verständigt. Beachten Sie bitte, daß jetzt in vielen Fällen darauf verzichtet werden kann, LRZ-Benutzerausweise anzufordern und zu vergeben. Denn seit Dezember 1996 ist für die Nutzung aller LRZ-PCs eine persönliche Kennung erforderlich; damit ist ein wesentlicher Grund für die Vergabe eines Benutzerausweises weggefallen. Ein Benutzerausweis ist daher nur noch notwendig, wenn der betreffende Benutzer Schriften oder Software im LRZ-Benutzersekretariat erwerben oder ausleihen möchte und nicht über einen Studenten- bzw. Dienstausweis verfügt.

Dagegen ist es weiterhin unbedingt erforderlich, daß der jeweilige Master User bei der Vergabe einer persönlichen LRZ-Kennung das Formblatt "Erklärung des Endbenutzers" ausfüllen und unterschreiben läßt. Diese Formblätter werden in geringer Anzahl mit den Verlängerungsunterlagen versandt und können kopiert werden. Sie können auch formlos beim LRZ-Benutzersekretariat bzw. beim Betreuer angefordert werden; außerdem sind sie online abrufbar unter http://www.lrz-muenchen.de/wir/kennung/.

In der Praxis werden die Verlängerungen leider häufig sehr spät, teilweise erst weit im folgenden Jahr eingereicht. Das hat für die Nutzer u.U. eine ärgerliche Unterbrechung ihrer Arbeitsmöglichkeiten zur Folge. Denn falls ein Projekt zum Jahresende ausläuft und nicht verlängert wird, geschieht folgendes: Nutzer von LRZ-Hochleistungssystemen (VPP700, IBM SP2, Cray T90) werden ab Anfang Dezember beim Login gewarnt; ab Anfang des neuen Jahres sind dann jedenfalls keine Batchjobs mehr möglich. Nutzer anderer LRZ-Plattformen erhalten Anfang des Jahres einen entsprechenden Hinweis per Mail; ab Anfang März wird generell kein Login mehr zugelassen. Davon betroffene Nutzer sollten sich umgehend an ihren Master User wenden.

Moderne Textverarbeitungsprogramme sind in der Regel elektronische Papierbogenimitate mit komfortablen Schreib- und Gestaltungstools. Sämtliche Konzepte für den Umgang mit diesen Produkten zielen auf eine Ausgabe auf Papier ab. Im Verlauf des Schreibens entstehende Textstrukturen werden optisch voneinander abgesetzt, so wie es auch später auf dem Papier sein wird. Dieses Konzept läßt aber wenig Spielraum für andere Verwendungsmöglichkeiten des derart erfaßten Textes, z.B. Veröffentlichung im World Wide Web (WWW).

Alte Zeiten – neue Zeiten

Der Erfolg des Menschen gegenüber anderen Lebewesen dieser Erde ist, so eine weithin akzeptierte Meinung, nicht zuletzt auf seine Sprachfähigkeit zurückzuführen. Durch Sprache können wir Wissen weitergeben, so daß für die anderen, denen wir unsere Kenntnisse mitteilen, die Erfahrung am eigenen Leibe nicht notwendig ist. Eine der evolutionsgeschichtlich betrachtet noch sehr jungen Erfindungen ist die Loslösung des gerade beschriebenen Erfahrungsaustausches von einer zeitlichen und akustischen Nähe zwischen Lehrer und Lernendem: die Schrift.

War das Schreiben, früher auch als Kunst des Schreibens bezeichnet, in vergangenen Epochen wenigen, speziell dazu ausgebildeten Personen vorbehalten, so ist es heute in der modernen Gesellschaft zu jedermanns Sache erklärt worden.

Insbesondere die Vermittlung von Wissen, die ja, wie schon eingangs bemerkt, ein erklärtes Ziel des Schreibens ist, kann mittels Schreibkunst durch alle Wissenden selbst erfolgen.

Bis vor kurzem bestand für die meisten die Schreibkunst darin, die erarbeiteten Erkenntnisse "zu Papier zu bringen" - und nicht etwa "zu Stein", "zu Tontafel" oder gar "zu Bildschirm".

Die Zeiten ändern sich: Eine wachsende Informationsflut nährt den Wunsch, darin schnell an die wesentliche Information zu gelangen. Mitteilungen gehen nicht mehr auf Papier zum Empfänger, sondern werden elektronisch kodiert versandt: als E-Mail, WWW-Seiten, auf CDs. Wir suchen nicht mehr in Karteikästen voll mit Kartonkärtchen, sondern befragen den Bibliotheks-OPAC (Online Public Access Catalogue) oder Suchmaschinen wie AltaVista.

Und die Information selbst? Sie wird – wie seit Jahr und Tag – "zu Papier" gebracht. Wir sind gewöhnt, Texte optisch zu strukturieren, durch Wechsel von Fonts, Zeilenabständen und Einrücktiefen, eine Methode, die speziell für gedruckte Versionen geeignet ist. Moderne Textverarbeitungsprogramme unterstützen dieses Vorgehen durch WYSIWYG ("What you see is what you get"), der Autor schreibt am Bildschirm wie auf einem Blatt Papier, eine möglicherweise sogar vorhandene logische Struktur des Textes bleibt im Inneren des Texteditors verborgen. Dieser Ansatz für die Texterfassung ist nicht mehr problemlos anwendbar auf Texte, die den erweiterten Ansprüchen der elektronischen Datenbearbeitung wie Recherchierbarkeit, Ausgabe auf verschiedensten Medien usw. genügen sollen.

Ein typisches Beispiel

Betrachten wir folgendes Beispiel: Ein Institut ist an einem wissenschaftlichen Projekt beteiligt. Die Arbeiten erfolgen in Kooperation mit einem Institut in den USA. Projektbeschreibungen, Zeitpläne, Aufgabenverteilungen und Ergebnisberichte werden in MS-Word geschrieben.

1. Szene: Die Texte müssen zwecks Korrekturlesen, Ergänzungen usw. zwischen Deutschland und USA hin- und hergeschickt werden. Es stellt sich heraus, daß die Kollegen in den Staaten eine neuere Version von Word haben und die Texte dort erst konvertiert werden müssen. Die dort konvertierten Texte sind aber mit der älteren Version in Deutschland nicht mehr lesbar. Alle betroffenen Autoren benötigen ein entsprechendes Software-Upgrade.

2. Szene: Teile der Texte sollen/müssen ins WWW. Es sind Texte von mehreren Papierseiten Länge – zu lang, um sie als jeweils eine Web-Seite abzulegen – und das erzeugte Layout ist ebenfalls unbefriedigend. Es beginnt eine mühevolle Zergliederung und Anpassung der aus Word konvertierten Texte – in Handarbeit. Die Übung wiederholt sich selbstverständlich bei jeder Änderung im Original, es schleichen sich Fehler ein, die Versionen beginnen zu divergieren.

3. Szene: Um das Projekt bekannt zu machen, wurde die zugehörige Website bei verschiedenen Suchmaschinen angemeldet. Ein solcher Robot hat die Seiten "besucht", wie man dem Serverlog entnehmen kann, aber das Projekt erscheint kaum jemals in den Trefferlisten. Ein Blick auf die HTML-Quelle verrät eine der möglichen Ursachen: Die Webseiten enthalten die in HTML vorgesehene <title>-Angabe gar nicht, ebenso fehlen jegliche HTML-Überschriften-Levels, vermeintliche Überschriften wurden in Wirklichkeit durch komplizierte Font-Angaben in der HTML-Quelle beschrieben. Die Suchmaschinen plazieren jedoch Treffer in Titeln und Überschriften weiter oben in die Trefferlisten, bzw. indizieren überhaupt bloß diese Teile der Webseiten!

Fazit: Ein Text, der elektronisch recherchierbar sein soll – und zwar nicht nur durch eine Volltextsuche, die, wie man an den Suchmaschinen im WWW immer wieder sieht, nur bedingt nützlich ist – muß bereits eine innere Struktur besitzen, die Kriterien zur Suche liefert. Eine solche Struktur kann sicher nicht das Seitenlayout sein, denn wen interessieren bei der Suche schon Texte, in denen das Wort "SGML" in Helvetica bold 14pt vorkommt. Eine Suche nach "SGML" in Überschriften und Titeln von Texten wäre da wohl fruchtbarer. Diese kann aber nur dann gelingen, wenn auch die elektronischen Suchmaschinen Überschriften und Titel als solche erkennen können.

Texte von Format und mit Struktur

Komplexe Datenbestände kommen ohne eine vor der Erfassung festzulegende logisch-inhaltliche Strukturierung nicht aus. Das ist jedem einsichtig, der eine typische Datenbankanwendung implementiert: Man definiert erst die Datensätze und Datenfelder, bevor man mit der Eingabe der Daten selbst beginnt. Diese Strukturiertheit ist Mitbestandteil der Leistungsfähigkeit von Datenbanken. Für Texte wird dieser Ansatz bisher jedoch noch relativ selten gewählt.

Es ist sinnvoll, die logische Struktur, die dem Dokumenttyp innewohnen soll, irgendwo festzulegen. Autoren schreiben ihre Texte dann aufsetzend auf diesem Strukturgerüst. Erst in einem zweiten Schritt wird festgelegt, wie bestimmte Textstrukturen auf dem Ausgabemedium letztendlich darzustellen sind. Eine solche Zweistufigkeit hat aber noch einen weiteren Vorteil: Will man den Text nicht nur auf einem Medium veröffentlichen, sondern auf mehreren, muß man nur noch die Layout-Beschreibung, das Stylesheet, entsprechend anpassen, die logische Struktur bleibt ja erhalten.

In den meisten modernen Textverarbeitungssystemen sind inhaltliche Struktur und Layout zwar durchaus unterscheidbar, aber dennoch eng miteinander verflochten – ihr erklärtes Ausgabemedium ist ein Ausdruck auf Papier. Es macht ja auch bei der Textaufbereitung für Papier keinen Unterschied, ob man für Überschriften eine fette Schrift wählt oder den Umweg über Struktur und Layout geht – das erscheint sogar eher umständlich. Die Strukturierung und Differenzierung in Struktur und Layout, oft auch als Style bezeichnet, zahlt sich erst aus, wenn der zu erstellende Text eines oder gar mehrere der folgenden Kriterien erfüllt:

Bereich Ausgabemedium

• Ausgabe in mehreren Medien (Papier, WWW, ...)
• Bearbeitung in unterschiedlichen Rechner- und Software-Umgebungen (Projektberichte, Autorenkooperationen, etc.)

Bereich Lebenserwartung

• länger, mehrere Monate, Jahre
• "ewig", Archive und ähnliches

Verwendung nicht "nur" zum Lesen

• Recherche
• interaktives Arbeiten (Online-Schulungen)
• Datenbanken
• dynamische Textgenerierung

Standards für die Texterfassung

Viele Firmen bieten Software-Lösungen an, mit denen ein großer Teil der obigen Ansprüche befriedigt werden kann. Für viele Zwecke wird das sicher auch ausreichen. Allerdings gibt es unter Umständen weitere, sehr wesentliche Gesichtspunkte, die ebenfalls bedacht sein sollten:

• Brauche ich diesen Text später wieder und wird die Software dann noch in der Lage sein, ihn zu lesen und zu bearbeiten? (Eine Reihe bekannter Software-Lösungen scheitert bereits an diesem Punkt, wobei der Zeitraum "später" nicht einmal drei Jahre umfaßt.)
• Wird mein Text auch von anderen in möglicherweise vollkommen anderen Software-Umgebungen bearbeitet werden?
• Möchte ich mich für immer an die einmal ausgewählte Software zur Textverarbeitung binden oder mir die Möglichkeit offen halten, auf andere Produkte umsteigen zu können?

Diese Überlegungen führen zwangsläufig dazu, eine Standardisierung der Textverarbeitungsprozesse zu fordern. Hier tritt SGML, die Standard Generalized Markup Language, in den Vordergrund, eine – wie der Name schon verrät – standardisierte Form der Textverarbeitung, die alle bisher genannten Problembereiche berührt. Bekannt geworden durch eine einfache SGML-Anwendung, nämlich HTML, die Textauszeichnungssprache des WWW, findet man immer mehr Texterfassungssoftware, die sich zumindest rudimentär mit diesem Standard beschäftigt. Für das WWW wird XML (eXtensible Markup Language) als einfachere Version entwickelt. Auf seiten der Layoutbeschreibungen oder Stylesheets ist die Standardisierung noch nicht ganz so weit fortgeschritten, jedoch deutet die Entwicklung hier immer wieder auf DSSSL (Document Style Syntax and Specification Language, sprich: dissel) bzw. die einfachere Version für WWW, XSL (eXtensible Style Language).

SGML (ISO-Standard 8879:1986) ist frei von proprietären Ansätzen, offen dargelegt in einem international anerkannten Standard, und gewinnt im Bereich Texterfassung zunehmend an Bedeutung. Dabei ist SGML eine Entwicklung der frühen achtziger Jahre, die aber bisher im wesentlichen nur von Bibliotheken und Verlagen eingesetzt wurde. Erst durch HTML gelangte es an eine breitere Öffentlichkeit. DSSSL (ISO/IEC-Standard 10179:1996) entstand aus der Forderung, die Präsentation eines mit SGML-Methoden erfaßten Textes ebenfalls mit Hilfe eines internationalen Standards zu beschreiben, der für die Darstellung nicht mehr an proprietäre Produkte gebunden ist.

DTDs – weltweit verwendbare Dokumentvorlagen

SGML und DSSSL sind keine fertigen Anwendungen wie Word, HTML oder LaTeX, die man unmittelbar zur Texterfassung einsetzen kann. Zum SGML-Dokument gehört eine Vorlage – eine sogenannte Document Type Definition (DTD), die man vor der Texterfassung erstellen muß und die eine formale Beschreibung der logisch-inhaltlichen Struktur eines bestimmten Dokumenttyps ist. Ein DSSSL-Stylesheet wird ebenfalls unabhängig vom tatsächlichen Text als allgemeine Vorlage für einen bestimmten Dokumententyp, also eine bestimmte DTD, geschrieben.

Die Entwicklung einer DTD und zugehöriger Stylesheets ist eine anspruchsvolle Aufgabe, die genaue Kenntnisse der Standards und eine möglichst genaue Analyse der zu erfassenden Texte voraussetzt. Glücklicherweise gibt es aber eine Reihe von fertigen DTDs, die kostenlos zur Verfügung stehen. HTML ist – wie schon erwähnt – die am weitesten verbreitete DTD, aber nur für einen kleinen Teil von Texten geeignet. Zur Erfassung wissenschaftlicher Arbeiten, insbesondere im geisteswissenschaftlichen Bereich, sei die Text Encoding Initiative (TEI) genannt, die eine modulare DTD entwickelt hat, mit der auch individuelle Anpassungen noch vorgenommen werden können, ohne auf vorgefertigte Module verzichten zu müssen. Für technische Dokumentationen steht die DocBook-DTD zur Verfügung, die unter der Obhut der Davenport Group speziell zur Dokumentation von Software entwickelt wird. Dafür geeignete Stylesheets kann man bereits über das Web erhalten.

Eine durchaus realistische Zukunftsperspektive könnte sein, daß DTDs und passende Stylesheets für viele andere, unterschiedlichste Dokumenttypen angeboten werden (kostenlos oder auch kommerziell) oder bereits in Textverarbeitungssystemen direkt verwendbar sind, so daß eine eigene Entwicklung in vielen Fällen nicht mehr notwendig ist.

Es macht sicherlich keinen Sinn, ab sofort alle Texte nur noch mit SGML-Methoden zu erfassen. Aber man sollte darüber nachdenken, ob SGML für ein neues Projekt oder eventuell auch für bereits bestehende Textsammlungen auf Dauer nicht doch die einfachere und günstigere Lösung sein könnte.

Für Interessierte:

Wer sich etwas intensiver mit diesem Thema beschäftigen möchte oder muß, ist herzlich eingeladen zum Einführungskurs "SGML und Stylesheets":

einem Streifzug durch die Welt der Standards zur Texterfassung.

Ein Beitrag im nächsten Rundschreiben wird sich – stärker praxisorientiert – der Frage annehmen, wie und womit man Texte mit SGML und Stylesheets erfassen kann.

Das Leibniz-Rechenzentrum (LRZ) der Bayerischen Akademie der Wissenschaften ist das regionale Rechenzentrum für alle Hochschulen Münchens, bayerisches Hochleistungsrechenzentrum und Betreiber des Münchner Hochschulnetzes.

Die nachfolgenden Stellenangebote waren bereits in den LRZ-Mitteilungen vom August 1998 veröffentlicht.

Für den Bereich PC-Administration suchen wir zum 1. Januar 1999 eine(n)

Unsere Anforderungen:

• Abgeschlossenes Fachhochschulstudium,
• fundierte Kenntnisse in den Bereichen PC-Betriebssysteme (bes. Windows 95/NT) und PC-Vernetzung (bes. Windows NT, Novell Netware, TCP/IP),
• fundierte Kenntnisse in PC-Hardware und Peripherie-Technologien,<
• umfassende Kenntnisse in den gängigen PC-Anwendungen,
• Fähigkeit zum selbständigen Arbeiten und zur Integration in unsere PC-Teams,
• kreatives Engagement für das zukünftige Arbeitsgebiet.

Ihre Aufgabengebiete:

• Mitarbeit bei der Administration der PCs und PC-Netze im Haus und in den öffentlichen Pools des LRZ,
• Beratung bei der Hardware- und Software-Auswahl,
• Mitarbeit bei den allgemeinen Aufgaben der Gruppe "PC-Betreuung und Graphik".

Die Anstellung erfolgt nach BAT. Schwerbehinderte werden bei gleicher Eignung bevorzugt.

Für nähere Auskünfte stehen zur Verfügung:

oder

Schriftliche Bewerbungen mit den üblichen Unterlagen senden Sie bitte an:

Für den Bereich PC-Administration in der Abteilung Benutzerbetreuung suchen wir zum 1. Januar 1999 eine/n

Unsere Anforderungen:

• Abgeschlossenes EDV-orientiertes Universitätsstudium,
• fundierte Kenntnisse in den Bereichen PC-Betriebssysteme (bes. Windows 95/NT) und PC-Vernetzung (bes. Windows NT, Novell Netware, TCP/IP),
• fundierte Kenntnisse in PC-Hardware und Peripherie-Technologien,
• umfassende Kenntnisse in den aktuellen PC-Anwendungen,
• Fähigkeit zum selbständigen Arbeiten und zur Integration in unsere PC-Teams,
• kreatives Engagement für das zukünftige Arbeitsgebiet

Ihre Aufgabengebiete:

• Erarbeitung von Musterkonfigurationen für PC-Server und PC-Arbeitsplätze,
• Mitarbeit bei der Administration der PCs und PC-Netze im Haus und in den öffentlichen Pools des LRZ,
• Beratung bei der Hardware- und Software-Auswahl,
• Mitarbeit bei den allgemeinen Aufgaben der Gruppe "PC-Betreuung und Graphik".

Die Anstellung erfolgt nach BAT. Schwerbehinderte werden bei gleicher Eignung bevorzugt.

Für nähere Auskünfte stehen zur Verfügung:

oder

Schriftliche Bewerbungen mit den üblichen Unterlagen senden Sie bitte an:

Für die Abteilung Kommunikationsnetze wird für den Ausbau und Betrieb des Münchner Hochschulnetzes zum 1.10.1998 ein

gesucht.

Das Aufgabengebiet umfaßt die

• Beratung der Hochschulinstitute in Netzfragen,
• Koordination der notwendigen Installationsmaßnahmen inklusive deren Überwachung zusammen mit den beteiligten Behörden und Institutionen,
• Koordination bei der Installation, Inbetriebnahme und Wartung von aktiven Netzkomponenten, wie Router und Switches.

Es werden Kenntnisse von Daten- und Sprachnetzen, die Bereitschaft zur Aneignung neuer Kenntnisse auf dem zukünftigen Arbeitsgebiet, weitgehend selbständiges Arbeiten, jedoch auch Teamfähigkeit erwartet. Ein erfolgreich abgeschlossenes Studium an einer Fachhochschule setzen wir voraus.

Die Anstellung erfolgt nach BAT und kann je nach Ausbildung und Berufserfahrung bis zur Vergütungsgruppe III erfolgen. Schwerbehinderte werden bei gleicher Voraussetzung bevorzugt.

Interessenten wenden sich bitte zu einer ersten Kontaktaufnahme oder für nähere Auskünfte an:

oder

Schriftliche Bewerbungen mit den üblichen Unterlagen senden Sie bitte an:

Gesucht werden für die Abteilung Kommunikationsnetze zum baldmöglichsten Zeitpunkt:

Aufgabengebiete:

• Evaluation und Betreuung von Netzmanagement-Anwendungen,
• Evaluation und Betreuung von Netzkomponenten und Netztechnologien,
• Beratung von Benutzern,
• Mitarbeit bei den allgemeinen Aufgaben der Gruppe Netzplanung.

Praktische Erfahrungen mit Kommunikationsnetzen werden erwartet. Ein erfolgreich abgeschlossenes Universitätsstudium setzen wir voraus.

Die Anstellung erfolgt nach BAT und ist vorerst auf zwei Jahre beschränkt. Schwerbehinderte werden bei gleicher Eignung bevorzugt. Interessenten wenden sich bitte zu einer ersten Kontaktaufnahme oder für nähere Auskünfte an:

oder

Schriftliche Bewerbungen mit den üblichen Unterlagen sind zu richten an:

Gesucht werden für die Abteilung Kommunikationsnetze zum baldmöglichsten Zeitpunkt

Aufgabengebiet:
Für das vom DFN-Verein (Verein Deutsches Forschungsnetz) geförderte Pilotprojekt Gigabit Testbed Süd zum Aufbau einer Gigabit-Infrastruktur im Münchner Einzugsgebiet und zwischen den Standorten München, Erlangen (zukünftig auch Berlin) soll hier

• Unterstützung bei Planung und Aufbau des Gigabit-Testbeds Süd, Test von neuester Netzwerktechnologie (Switches, Router, Software),
• Betreuung von innovativen Benutzerprojekten aus dem Bereich Metacomputing, medizinische Bildbearbeitung sowie Bildverarbeitung und Erstellung und Verteilung Multimedia-basierter Lehrangebote

geleistet werden.

Qualifikationen:
Abgeschlossenes Universitätsstudium, Diplom in Informatik oder Mathematik bzw. auch Ingenieurwissenschaften mit Nebenfach Informatik.

Darüberhinaus sollte der (die) Bewerber(in) über (Teil-)Kenntnisse in den Bereichen

• IP, ATM, Gigabit Ethernet
• Switching, Routing
• digitale Bildverarbeitung, Audio-Video Codecs
• Unix, C, Perl

verfügen. Von den Bewerbern werden Teamfähigkeit und die Bereitschaft zur Aneignung fehlender Kenntnisse auf dem zukünftigen Arbeitsgebiet erwartet.

Nähere Informationen zu den Gigabit-Testbed Projekten des DFN finden sich unter

Die Anstellung erfolgt nach BAT im Rahmen des vom Verein Deutsches Forschungsnetz (DFN) geförderten Pilotprojektes. Die Stellen sind vorerst auf zwei Jahre befristet. Schwerbehinderte werden bei gleicher Eignung bevorzugt.

Interessenten wenden sich bitte zu einer ersten Kontaktaufnahme oder für nähere Auskünfte an:

oder

Schriftliche Bewerbungen mit den üblichen Unterlagen sind zu richten an:

Gesucht wird für die Abteilung Rechensysteme zum baldmöglichsten Zeitpunkt

Aufgabengebiet:
Aufbau eines verteilten Filesystems auf der Basis von DCE/DFS von "The Open Group", ein System verteilter Fileserver für eine sehr große Anzahl heterogener Clients.

Zur Zeit setzt das LRZ das verteilte Filesystem AFS (Andrew File System) ein. AFS soll durch DCE/DFS (Distributed Computing Environment/Distributed File Services) ersetzt werden. In dem dafür verantwortlichen Team wird ein(e) vierte(r) Mitarbeiter(in) gesucht, die (der) Initiative und Zielstrebigkeit mit Phantasie und Teamgeist vereint. Im Bereich der neuen, zukunftsorientierten Technologie DCE/DFS ergeben sich eine Reihe interessanter, herausfordernder Aufgaben:

• Installation und Konfiguration einer DCE-Produktionszelle im LRZ-Netz
• Planung und Durchführung der Migration von AFS nach DFS im Bereich der vernetzten Unix-Workstations
• Anbindung der PC-Welt (NT, Win95) an DCE
• Einbindung unserer Hochleistungsrechner in DCE
• Anbindung von DFS an das Archiv- und Backupsystem des LRZ (ADSM)
• Evaluierung und Einsatz von DCE-Management-Werkzeugen
• Untersuchungen des Datendurchsatzes von DCE bei verschiedenen Netztechnologien

Praktische Erfahrungen in einem oder mehreren der folgenden Gebiete sind von Vorteil:

• Unix-Betriebssysteme
• Netz- und Client-Server-Konzepte
• DCE (Distributed Computing Environment)
• AFS (Andrew File System)
• ADSM (Adstar Distributed Storage Manager)

Die Anstellung erfolgt nach BAT. Die Stelle ist vorerst auf zwei Jahre befristet. Schwerbehinderte werden bei gleicher Eignung bevorzugt.

Interessenten wenden sich bitte zu einer ersten Kontaktaufnahme oder für nähere Auskünfte an:

oder

Schriftliche Bewerbungen mit den üblichen Unterlagen sind zu richten an:

Für die Teilnehmer an der Maple- bzw. der Mathematica-Campuslizenz des LRZ wurde jeweils eine Mailingliste eingerichtet, über die der jeweilige Benutzerkreis schnell und direkt über Neuerungen informiert werden kann (z.B. über das Eintreffen neuer Versionen).

Alle Teilnehmer an den beiden genannten Campuslizenzen, von denen mir die Mailadressen bekannt sind, wurden bereits per Mail über die Einrichtung der Mailinglisten informiert. Dieser Beitrag richtet sich daher hauptsächlich an weitere Teilnehmer der beiden Campuslizenzen, deren Mailadressen mir nicht vorliegen und die daher noch nichts von der Existenz der neuen Mailinglisten wissen.

Die beiden Mailinglisten haben die Namen

bzw.

Um in die Mailingliste für Maple aufgenommen zu werden, müssen Sie eine Mail mit dem Inhalt (nicht Subject!)

an

schicken. Analog dazu erfolgt die Anmeldung für die Mathematica-Mailingliste durch eine Mail mit dem Inhalt

Von einem unserer Benutzer wurde angeregt, für Insure++ eine Campuslizenz anzuschaffen. Insure++ ist ein Software-Paket der Firma ParaSoft, das die Entwicklung von C- und C++-Programmen auf Unix- und Windows-Plattformen unterstützt. Bei Interesse an diesem Produkt bitten wir um eine entsprechende Rückmeldung.

Insure++ besteht aus den folgenden Tools:

• Das Kerntool von Insure++ ist ein Debugger mit graphischer Benutzeroberfläche, der – so die Produktbeschreibung – alle Arten von Speicherverwaltungs- und Speicherzugriffsfehler findet (u.a. Lesen oder Schreiben über das Ende von Speicherbereichen, nicht initialisierte oder "wilde" Pointer, Fehler bei Stringmanipulationen, inkompatible Deklaration von Variablen).
• Inuse ist eine Art "Malloc-Monitor", d.h. ein Tool, mit dem man die (dynamische) Speicherbelegung visualisieren und dadurch eventuelle Fehler oder Schwächen in der Speicherverwaltung finden kann.
• Mit dem Tool TCA (Total Coverage Analysis) kann man sich anzeigen lassen, welche Programmteile ausgeführt und damit getestet wurden.

Insure++ ist für alle gängigen Unix-Plattformen und für Windows 95/98/NT verfügbar. Auf den Unix-Plattformen werden alle gängigen C- und C++-Compiler unterstützt, auf den Windows-Plattformen nur Visual C++.

Ausführliche Informationen zu Insure++ finden Sie am Web-Server der Firma ParaSoft. Die Einstiegsseite von ParaSoft erreichen Sie über

einen "Quick Overview" über Insure++ enthält die Seite

Bei Interesse können Sie sich über diesen WWW-Server auch eine Testlizenz holen und das Produkt ausprobieren.

Falls Sie Interesse an einer Campuslizenz für Insure++ haben, so melden Sie sich bitte möglichst bald, spätestens aber bis Ende November 1998 bei mir. Über Preise (für Anschaffung und jährliche Wartung) kann erst etwas gesagt werden, wenn feststeht, wieviele Institute bzw. Lehrstühle sich an einer Campuslizenz beteiligen würden.

Um den Mißbrauch von Mailservern im MHN als Spam-Relays zu unterbinden, ist eine Umstrukturierung des Mailverkehrs im MHN notwendig. Zudem werden neue zentrale Mail-Relay-Rechner im LRZ in Betrieb genommen.

Die ersten beiden Teile dieses Beitrags richten sich an alle Administratoren, die einen Mailserver im Münchner Hochschulnetz (MHN) betreiben. Es wird beschrieben, was diese tun müssen, damit weiterhin Mail empfangen werden kann, nachdem ab 16. Nov. 1998 der direkte Empfang von Mail aus dem Internet gesperrt wird. Der letzte Teil dieses Beitrags richtet sich an alle, die die Maildienste des LRZ in Anspruch nehmen.

1. Sperrung von Port 25 (SMTP)

Ein großer Teil von Ihnen wird bereits ein Opfer eines "Spammers" geworden sein. Wie schon im Oktober 1997 im Artikel Mißbrauch von Rechnern im Münchner Hochschulnetz als Spam-Relay

beschrieben, mißbrauchen Spammer Rechner im MHN, um ihre unerwünschten (kommerziellen) Werbemails in alle Welt zu verteilen. Im Laufe des vergangenen Jahres hat es sich gezeigt, daß jeden Tag mindestens ein Rechner im MHN auf diese Weise mißbraucht wurde. Das Ganze artete in ein massives Hase-Igel-Spiel aus. Wenn ein Rechner "dicht" gemacht wurde, d.h. die neuste Software installiert und so konfiguriert wurde, daß das Relaying von Spam verhindert wurde, suchte sich der Spammer einfach den nächsten Rechner aus.

In einigen Fällen war und ist es nicht möglich den Rechner "dicht" zu machen. Den betroffenen Administratoren bot das LRZ an, alle Mail über die zentralen Mailrelays des LRZ zu leiten, anstatt die Mails selbst in die weite Welt zu versenden. Auf diesen zentralen Relays wurden Filter eingesetzt, die versuchten, nachträglich Spams von regulärer Mail zu unterscheiden und die Weiterleitung dieser Spams zu verhindern. Auf diese Weise wurden im Schnitt pro Nacht Mails an 210.000 Empfänger (35 Empfänger pro Mail) gelöscht. Es konnten in der Regel keine Fehlermeldungen zurückgesandt werden, da die Absendeadressen gefälscht waren. Trotz dieser Maßnahme wurden immer noch Spams weitergeleitet, da kein Filter hundertprozentig funktionieren kann. Die Pflege dieser Filter nimmt einen großen Teil der zur Administration der Mailserver zur Verfügung stehenden Zeit ein, die für andere Dinge wesentlich sinnvoller verwendet werden könnte.

Die Weiterleitung von Spams führte auch dazu, daß Rechner aus dem MHN auf "blacklists" landeten, d.h. daß von diesen Rechnern keine Mail, also auch keine reguläre Mail, mehr entgegen genommen wurde. Gerade diese Woche hat sich beispielsweise der Internet Service Provider AOL bei uns über die Spams aus dem MHN beschwert.

Alles in allem führte dies zu einem Zustand, der so nicht weiter anhalten kann. Aus diesem Grund hat sich das LRZ entschlossen, das Übel sozusagen an der Wurzel zu packen. Eine bessere Strategie ist es, nicht erst alle Mails in das MHN hereinzulassen und anschließend die Spam-Mails abzufangen, die das MHN wieder verlassen wollen, sondern bereits den Empfang der Spam-Mails aus dem Internet zu blockieren, bevor sie ins MHN gelangen.

Daher wird der direkte Empfang von E-Mail aus dem Internet ins MHN am B-WiN-Eingang für eine große Anzahl von Mailservern gesperrt (Sperrung von Port 25), wie dies bereits bei einer großen Anzahl von Universitäten im B-WiN des DFN der Fall ist. Diese Maßnahme tritt am

in Kraft.

Einige ausgezeichnete Mailserver können weiterhin Mails direkt empfangen. Gut wäre es, wenn diese Rechner zwischen regulären Mails und Spam-Mails unterscheiden könnten. Nachdem dies aber nicht möglich ist, werden die Mails in zwei andere Klassen eingeteilt und zwar

• Mails an Empfänger im MHN
• Mails an Empfänger außerhalb des MHN

Die erste Gruppe von Mails wird durchgelassen, die zweite Gruppe von Mails wird nicht angenommen. Nachdem die zweite Gruppe zu 98 % aus Spam-Mails besteht, hat man damit schon einen wesentlichen Schritt gemacht. Leider werden dadurch Spam-Mails an Empfänger im MHN nicht erfaßt.

Aus Performance-Gründen können am Router zum B-WiN nur eine kleine Anzahl dieser Rechner eingetragen werden, Neben den beiden zentralen Mailrelays des LRZ

gehören dazu Mailserver, die entweder ein hohes Aufkommen an Mail haben, oder für eine größere Anzahl an Maildomains zuständig sind und die nachgewiesenermaßen gegen das Relaying von Spam-Mails gesichert sind. Der Nachweis geschieht in der Regel über den Dienst Anti-Relay-Test unter

Alle anderen Mailserver können keine Mail mehr direkt aus dem Internet empfangen (sie können hingegen weiterhin Mails nach außen senden). Der Empfang von Mail kann nur indirekt geschehen, indem die Mail zuerst von einem der ausgezeichneten Mailserver empfangen und anschließend an den eigentlichen Mailserver weitergeleitet wird. Durch die Einführung spezieller MX-Records im DNS kann dies erreicht werden. Das genaue Vorgehen ist im WWW-Server des LRZ beschrieben unter

2. Migration auf die neuen zentralen Mailrelays des LRZ

Bisher diente als zentrales Mailrelay eine Sun-SS20 (sunsrv5.lrz-muenchen.de) mit einem weiteren Rechner als Hardware-Backup. In Zukunft werden zwei Sun-Ultra-2 eingesetzt, die sich gegenseitig vertreten:

und

Beide Rechner besitzen gespiegelte Platten, die gegenseitig bei Ausfall übernommen werden können. Geschützt durch eine USV gegen kurzfristige Stromausfälle, sollte daher immer wenigstens einer der beiden Rechner zur Verfügung stehen. Leistungsmäßig sollten auch keine Probleme auftreten. Das momentane Aufkommen an Mails (33.000/40.000 empfangene/verschickte Mails pro Tag) können die Rechner in ca. 1 Stunde abarbeiten, es bestehen also noch genügend Reserven.

Bei der Migration von den alten auf die neuen Server ändert sich für Benutzer von LRZ-Mailservern nichts. Es gilt weiterhin, daß Mail an mailout.lrz-muenchen.de geschickt werden soll. Administratoren lokaler Mailserver, die die Mails zur Weiterleitung an das LRZ schicken (sogenanntes Forwarding), müssen hingegen folgendes beachten:

• Geschieht das Forwarding über einen Domainnamen, wie z.B. bei sendmail, dann benutzen Sie bitte die Adresse mailout.lrz-muenchen.de (bitte nicht mehr dfvgate.lrz-muenchen.de oder cd1.lrz-muenchen.de nutzen, diese Adressen gelten schon seit langem nicht mehr). Bitte benutzen Sie nur mailout.lrz-muenchen.de und nicht mailrelay1 oder mailrelay2, sonst haben Sie bei Ausfall eines der beiden Rechner keinen Backup und Ihre Mail bleibt liegen!
• Geschieht das Forwarding hingegen über eine der IP-Adressen 129.187.13.1, 129.187.13.15 oder 129.187.10.15, wie z.B. bei Novellservern, die den Mailserver Mercury einsetzen, dann benutzen Sie bitte die IP-Adresse 129.187.254.111. Diese Adresse gehört zu mailout.lrz-muenchen.de und wird bei Ausfall des Servers (manuell) auf den anderen Server umgeschaltet.

Mailserver, die für den Empfang von Mail als Backupsystem die sunsrv5.lrz-muenchen.de oder noch die cd1.lrz-muenchen.de benutzen (Eintrag eines MX-Records mit Verweis auf einen dieser Rechner), müssen jetzt die Mailrelays mailrelay1.lrz-muenchen.de und mailrelay2.lrz-muenchen.de konfigurieren.

Benutzen Sie zur Konfiguration ebenfalls die Anleitung unter

Diese Konfigurationsmaßnahmen sollten so bald wie möglich ausgeführt werden und müssen ebenfalls bis zum 16. November 1998 abgeschlossen sein. Danach stehen die alten Rechnernamen und IP-Adressen nicht mehr zur Verfügung.

3. Regeln der neuen zentralen Mailrelays des LRZ

Mit der Einführung der oben beschriebenen Maßnahmen werden auch eine Reihe neuer Regeln für den Betrieb der zentralen Mailrelay-Rechner eingeführt. So eine Sammlung von Regeln wird im Internet als Policy bezeichnet. Die genaue Beschreibung der einzelnen Regeln mit Begründung und Auswirkung auf unsere Kunden finden sie unter

Bitte lesen Sie unbedingt die Beschreibung dieser Regeln im WWW, damit Sie verstehen, warum wir diese Maßnahmen einführen müssen, auch wenn manche der Maßnahmen für den einzelnen eine Umstellung seiner Gewohnheiten erfordert. Dort ist auch beschrieben, wann die einzelnen Regeln in Kraft treten und was der Einzelne ändern muß

Zu den wichtigsten Neuerungen gehört:

• Eine Mail aus dem Internet wird nur angenommen, wenn
• • der Empfänger sich im MHN befindet (Spam-Relay-Blocking, keine Mails von außen nach außen);
  • der sendende Rechner sich korrekt ausweist (Domain im HELO-Protokollelement stimmt mit sendender IP-Adresse überein), Vortäuschung anderer Hosts wird nicht akzeptiert;
  • die Mailadressen im Umschlag der Mail (MAIL FROM und RCPT TO) syntaktisch korrekt sind;
  • an den Absender der Mail (MAIL FROM) eine Fehlermeldung zurückgeschickt werden kann (Domain der Absendeadresse ist im DNS konfiguriert).
  
  
• Mails, die über Wählmodem verschickt werden, müssen
• • über die zentralen Mailrelays geleitet werden (mailout.lrz-muenchen.de, entspricht der Default-Konfiguration)
  • in der Absendeadresse (MAIL FROM) eine Domain aus dem MHN haben (Subdomain von tu-muenchen.de, uni-muenchen.de etc). Es werden keine fremden Absendedomains mehr akzeptiert.
• Die Größe der Mails bei Empfang bzw. Versand wird auf 20.000.000 Bytes (ca. 20 MByte) beschränkt.

Weitere Regeln, die zur Zeit in der Diskussion sind und hauptsächlich der Abwehr von Spams dienen sollen:

• Keine direkte Annahme von Mails von den Wählzugängen der großen Internet Service Provider (ISP) wie att.net, compuserve.com, ibm.net, mci.net, sprint.net, psi.net und uu.net an Empfänger im MHN (zu 99% Spams von außen nach innen). Mails sollen in diesen Fällen über die Mailserver der ISPs verschickt werden. Von dort gelangen sie dann zu den Empfängern im MHN. ISPs können damit auf ihre Kunden, die Spam-Mails versenden, reagieren.
• Annahme von Mails von großen Mailboxprovidern nur von deren Mailservern, nicht aber von anderen ISPs. Dadurch kann die Absendeadresse nicht gefälscht werden, ohne daß der Provider Eingriffsmöglichkeiten hat. Diese Policy wird bereits von einigen Providern eingesetzt.
• Kennzeichnung von Mails, die aus sogenannten Spammer-Domains kommen, z.B. Hosts auf der "Real Time Blocking List" (RBL) (s. http://maps.vix.com/rbl/), zum Zwecke der einfacheren Filterung.
• Filter gegen Spams, die vom jeweiligen Empfänger ein- und ausgeschaltet werden können.

Der Rechner Cray Y-MP EL wurde 1992 im Zuge der Installation mehrerer Vorrechner zum damaligen Landesvektorrechner Cray Y-MP8 beschafft, zu dem er voll kompatibel war. Nach dem Austausch der Cray Y-MP8 gegen den Rechner Cray T94 ist diese Kompatibilität nicht mehr gegeben. Letzterer benutzt bei der Zahlendarstellung das auch bei allen Workstations und PCs übliche und standardisierte IEEE-Format anstatt einer an den früheren Cray-Rechnern verwendeten proprietären Zahlendarstellung.

Obwohl voriges Jahr die Wartungskosten für den Cray Y-MP EL erheblich reduziert werden konnten, entsprechen nach 6 Jahren die laufenden Kosten nicht mehr der Leistung des Rechners. Auch die Anzahl der Nutzer ist stark abgesunken. Das Leibniz-Rechenzentrum hat daher beschlossen, den Rechner

stillzulegen.

Benutzer dieses Rechners werden daher gebeten, ihre Daten und Programme auf andere Rechner zu migrieren. Funktional ist der Cray T94 mit der gleichen Software in neueren Versionen ausgerüstet. Die Migration sollte vor Weihnachten 1998 abgeschlossen sein, damit ein reguläres Abschalten möglich ist.

Die Plattenkapazität am VPP700 wird demnächst erweitert. Der zusätzliche Platz soll Projekten mit großem Bedarf zugute kommen. Interessierte Benutzer können noch Einfluß auf Einzelheiten des Betriebskonzepts nehmen.

Die Plattenkapazität am Fujitsu VPP700 wird demnächst um etwa 270 GB erweitert. Damit entspricht das LRZ dem Wunsch einiger Benutzergruppen nach mehr Plattenplatz für Projekte mit sehr großem Bedarf.

Das LRZ plant, den zusätzlichen Plattenspeicher wie folgt zu nutzen:

Es wird ein einziges Dateisystem mit einer Kapazität von ca. 270 GB gebildet. Das neue Dateisystem steht allen Benutzern des VPP700 offen; die Nutzung wird jedoch nur auf besonderen Antrag hin für einzelne Projekte und nur für beschränkte Zeit gestattet. Das Dateisystem wird nicht auf Band gesichert. Es ist vom Typ VFL (UFS-Dateisysteme sind auf 32 GB beschränkt) und heißt /ptmp_vfl_large.

Falls Sie das neue Dateisystem nutzen möchten, so wenden Sie sich bitte an die VPP-Betreuer, am besten per E-Mail an

Bitte geben Sie Ihren Platzbedarf an, sowie den Zeitraum, für den Sie diesen Platz benötigen. Richten Sie bitte auch Wünsche oder Anregungen hinsichtlich des oben skizzierten Betriebskonzepts an diese Adresse. Bei Bedarf wird das LRZ eine Sitzung der potentiellen Nutzer einberufen, auf der Einzelheiten der Nutzung diskutiert werden können.

Der voraussichtliche Liefertermin für die neuen Platten ist Oktober/November 1998.

Ein neues, leicht zu steuerndes Beleglesegerät Kaiser OMR 40 ist im LRZ installiert. Es ersetzt das alte Modell OMR 30.

Die Technologie des OMR ("Optical Mark Reading") unterstützt das Einlesen von speziellen Markierungsbögen: Mit Bleistift oder (neu mit diesem Gerät) Kugelschreiber ausgefüllte Kästchen (sogenannte "bubbles") werden "eingescannt" und die Daten in eine ASCII-(generell lesbare) Datei übertragen. Neu mit dem OMR 40 ist auch die Möglichkeit, beidseitig gedruckte Bögen zu lesen. Der neue Belegleser steht im Scanner-Raum (S1537) des LRZ.

Die Steuerung des Geräts wird über das Programm ScanTools realisiert, das am PC neben dem Gerät installiert ist. Dieses Programm arbeitet auf der Basis eines Abbilds eines eingescannten Bogens: Eckpunkte bestimmter Felder werden markiert, der Bogen eingescannt, und die markierten Felder definiert als zum Beispiel alphabetische oder numerische Felder. Das Gerät verfügt über eine "Mark Discrimination"-Technik, die es erlaubt, mit großer Treffsicherheit zwischen echt markierten und zum Beispiel ausradierten Feldern zu unterscheiden. Beim Einlesen trennt das Gerät nicht erfolgreich eingelesene Bögen, verarbeitet aber die restlichen; so daß die Korrektur der "falschen" Bögen getrennt vom Einlesevorgang durchgeführt werden kann.

Bögen, die bisher vom auslaufenden OMR 30 gelesen wurden, können problemlos auch mit dem OMR 40 verarbeitet werden.

Eine schriftliche Einleitung zum Arbeiten mit dem OMR 40 ist in Vorbereitung. Falls Sie dieses Gerät einsetzen wollen, bitte ich um Anmeldung bei mir.

Anhang

Aktuelle Landes-, Campus- und Sammellizenzen am LRZ

Zur Zeit können mehrere Software-Produkte für Zwecke der Lehre und Forschung zu günstigen Bedingungen über das LRZ bezogen werden. Dieser Anhang enthält sowohl eine Kurzbeschreibung dieser Programme als auch eine Übersichtstabelle, die deren Verfügbarkeit an verschiedenen Plattformen zusammenfaßt. Landeslizenzen sind gesondert gekennzeichnet. Umfangreiche Produktsammlungen sind kursiv dargestellt. Weitere Einzelheiten sind unter

zu finden.

			Plattformen
Produkt		Landes-Lizenz?	Personal-Computer	Unix- Systeme (Unix)
3D Studio MAX	3D-Animationssoftware der Firma Autodesk	Nein	Windows 95 Windows NT
Adobe	Verschiedene Software-Produkte der Firma Adobe		Windows Mac	nur einige Produkte für verschiedene Unix-Systeme
AIT	Cray-Workstation-Verbindungswerkzeuge	Ja		SunOS 4.1 IRIX 3.3 + ULTRIX 4.1
AFS	verteiltes Dateisystem			X
AMD	Autodesk Mechanical Desktop  Zusatzpaket zu AutoCAD für die 3D- Konstruktion im Anwendungsbereich Maschinenbau		Windows 95 Windows NT
AutoCAD	2D-/3D-Computer-Aided-Design-System der Firma Autodesk  Release 13 oder 14		DOS Windows 3.x (nur Rel.13) Windows 95 Windows NT	Sun Solaris (nur Rel.13) HP-UX IBM AIX SGI Irix
AVS	Visualisierungssystem	Ja	Windows 95Windows NT	X
BSD/386	Unix-Implementierung für PC		PC ab 386
Corel	Verschiedene Softwarepakete der Firma  Corel WordPerfect Suite u.a.		DOS Windows Macintosh	gängige Unix-Plattformen
DECcampus	Anwender- und System-Software der Firma DEC			versch. DEC- Betriebs- Systeme
ESRI	Geographische Informationssysteme		Windows	X
FTN90	Fortran-90-Compiler der Firmen NAG und Salford für DOS-PCs		DOS
FuLP	Verschiedene Softwareprodukte der Firma Inprise (vormals Borland)	Ja	Windows DOS
HP-Software	Compiler und weitere System-Software der Firma HP			HP-UX 9.0  HP-UX 10.0
IBM-Software	Compiler und weitere Software der Firma IBM			IBM AIX
IDL	Grafik- und Bildverarbeitung		Windows Linux Macintosh	X
IMSL	Fortran-Unterprogrammbibliothek		X	X
Interleaf	HighEnd DIP-System	Ja	Windows 95 Windows NT	Sun DEC, IBM HP
KHOROS	Visualisierungssystem	Ja		X
Lars	Archivierungs- und Recherche-System  (Bezug über ASKnet)		DOS Windows
LRZ-Grafik	Grafikpaket	Ja	DOS	X
Maple	Computer-Algebra-System		Windows OS/2 Macintosh	X
Mathematica	Computer-Algebra-System		Windows  Macintosh	X
Micrografx	Verschiedene Produkte aus dem Bereich Grafik	Ja	Windows
MLA	Netware und weitere Produkte der Firma Novell		DOS
NAG	Fortran-Unterprogrammbibliothek	Ja	DOS	X
OnNet	TCP/IP für PCs (Bezug über ASKnet)		Windows
OnNet32	TCP/IP für PCs (Bezug über ASKnet)		Windows 95 Windows NT
OSF/DCE	Verteilte Anwendungen			X
OSF/Motif	Toolkit für Window System X11			X
PC/TCP	TCP/IP für PCs   (Bezug über ASKnet)		DOS Windows
PC-TeX	Textsatzsystem Tex (incl. LaTeX)		DOS Windows
Pro/Engineer	CAD/CAM-3D-Modellierer für den Bereich Maschinenbau	Ja	Windows 95 Windows NT	X
SAS	Statistik-Programmsystem		Windows 3.1 Windows 95 Windows NT
ScholarPAC	Software und Betriebssystem-Wartung von Sun Microsystems GmbH		X 86	Solaris
Select	Microsoft-Software aus den Bereichen Anwender-, System- und Server-Software		DOS Windows Macintosh Windows NT
Softbench	CASE-Tool			HP-UX SunOS 4.1.x Solaris 2.x
Dr. Solomons Anti-Virus Toolkit	Software zum Schutz gegen Computerviren	Ja	DOS Windows 3.x Windows 95 Windows NT (Workstation) OS/2 Novell- Netware 3.x/4.x Macintosh
SPSS	Statistik-Programmsystem		DOS Windows 95/98/NT Macintosh
StarOffice	Office-Paket der Firma StarVivision		DOS Windows Mac OS/2	Solaris Linux Irix
SYSTAT	Statistik-Programm		Windows 95 Macintosh
Trumpet Winsock	TCP/IP für MS-Windows (mit PPP)		Windows 3.x
TUSTEP	System von Textverarbeitungsprogrammen		DOS Linux
UniChem	Quantenchemieprogramm	Ja		IRIX 3.3.1 + IRIX 4.0.1 +
Varsity	Compiler und weitere Software der Firma SGI			Silicon Graphics

X: auf allen gängigen Plattformen der jeweiligen Rubrik verfügbar
+: diese Systemversion oder höher
Kursiv gedruckt sind die Namen umfangreicher Produktsammlungen