Û¥-x@ €‰Vw Uv$v$$v$v$v$v$v2v2v2v2v2vNvF”v.ÂvÆvÊvÎvÒvÒvÒvÒvÒvÒvÒvÒvÒvÒvÒvÒv4wÒvÒvÒvÒv¬° @UEBER = Das Jahr 2000-Problem: der Countdown läuft @UEBER = Das Jahr 2000-Problem: der Countdown läuft @AUTOR FUNKTIN = Dr. Klaus Hanauer Für viele Computer- und Softwaresysteme, die nur zweistellige Datumsangaben verwenden, hält das Jahr 2000 eine Fülle von Problemen bereit. Die Aufgaben der IT-Verantwortlichen in diesem Zusammenhang sind seit langem bekannt: Es sind nicht weniger als sämtliche DV-Systeme auf das Problem 2000 hin zu überprüfen und gegebenenfalls zu modifizieren. Also unsere zentralen Großrechner, Supercomputer, UNIX-Systeme und PCs. Tools und Anwendungen für Endbenutzer ebenso wie anwenderspezifische Fortran-, C- oder Pascal-Programme oder vom Anwender geschriebene Makros, Skripts oder Prozeduren. Auch der Datenaustausch mit anderen Institutionen ist zu überprüfen und eventuell umzustellen. Werden z.B. regelmäßig von einem Anbieter Daten (Meßergebnisse, Börsendaten usw.) geliefert, dann müssen bei einer Datumsformat-Änderung alle nachfolgenden Programme angepaßt werden. Ähnliches kann passieren, wenn Institute in bestimmten Projekten Daten, in denen Datumsangaben vorkommen, weltweit zur Verfügung stellen. Auch die Gebäudeinfrastruktur mit Zutrittskontrollen, Klimatechnik, Fernmeldetechnik (ISDN) und Aufzugssteuerungen müssen überprüft und für das Jahr 2000 tauglich gemacht werden. Diese Bereiche, zu denen auch die städtischen Infrastrukturen gehören (z.B. Ampelsteuerungen) liegen zwar nicht in der Zuständigkeit eines Universitätsrechenzentrums, aber wer sonst als die DV-Spezialisten soll die dortigen Mitarbeiter auf ein Problem aufmerksam machen, das aus Computern resultiert? @UEBER LINIEN = Mit funkgesteuerter Uhr alleinist es nicht getan Bei einem kürzlichen Zeitungsinterview, bei dem ich selbst auch einen kleinen Beitrag lieferte, wurde das Problem von einem für die städtische Infrastruktur Verantwortlichen mit der Bemerkung abgetan, die verwendeten Rechner würden, was das Datum und die genaue Uhrzeit anbelangt, ja von einer präzisen Funk-uhr gesteuert und könnten deshalb überhaupt kein Jahr 2000-Problem haben. Diese Aussage zeigt deutlich, daß das sehr vielschichtige Problem oft nicht verstanden, und die Tragweite nicht erkannt wird. Wäre es mit einer genauen, funkgesteuerten Uhr getan, dann könnte ich zumindest für die Anwender in der Universität Karlsruhe den Artikel hier beenden, denn die meisten Rechner der Universität Karlsruhe (nicht nur im Rechenzentrum) können einen Time Server nutzen, der immer funkgesteuert über die exakte Uhrzeit und das exakte Datum verfügt und diese Angaben auch über das Netz verteilen kann. Aber leider ist das Problem so leicht nicht aus der Welt zu schaffen. @UEBER LINIEN = Kein Grund zur Panik @BODY VORN = Bevor ich in die Einzelheiten gehe, das Problem näher beschreibe und Lösungsmöglichkeiten vorschlage, möchte ich noch folgendes bemerken: Eigentlich gibt es für verantwortliche Leiter von Organisationen, die mit Rechnern arbeiten, keinen Grund, in Panik zu geraten. Seit mindestens einem Jahr erscheinen in allen Zeitschriften, die sich im weitesten Sinne mit IT-Techniken befassen, fast wöchentlich Berichte, die auf das Jahr 2000-Problem hinweisen oder über gewonnene Erfahrungen bei Projekten berichten. Unter den Stichworten “The Year 2000”, “Y2K”, “The Time Bomb”, “The Millennium Bug”, “The Millennium Virus” und “Century Date Change” erschienen unzählige Artikel und Berichte. Kein IT-Verantwortlicher auf der Welt kann behaupten, nichts von dem Problem gewußt zu haben. Erstaunlich sind deshalb neueste Umfrageergebnisse, bei denen ein recht großer Anteil der Befragten immer noch behauptet, über das Problem noch nicht nachgedacht zu haben. Andere haben es wiederum ganz eilig mit den Datumsfelder-Umstellungen. Der Abschlußtermin dieses Projektes ist nicht aufschiebbar (dies ist ein sehr seltener Fall). Sein Umfang ist schwer abzuschätzen und die Menge der Aufgaben, die in der verbleibenden Zeit zu bewältigen sind, wächst ohne unser Zutun. Alle Hoffnungen richten sich auf Tools. Die sollen die Arbeit möglichst automatisch und komplett erledigen. Erstaunlicherweise glauben Anwender in diesem Fall sogar, was die Hersteller nicht einmal versprechen.  Dies ist, wenn man der “Computerwoche” glauben kann, ein sicheres Zeichen von Panik. @UEBER LINIEN = Ursachen und Auswirkungen Die Ursache für die Störungen von Computerprogrammen im Jahre 2000 ist ein zu klein dimensioniertes Feld für die Jahreszahl. Aus Bequemlichkeit, Platzgründen oder Gedankenlosigkeit wurden viele Jahre lang für die Jahreszahl nur zweistellige Datumsangaben verwendet. Wer also im Jahr 1964 geboren ist, wird im Jahr 2000 bei zweistelliger Rechnung mit 00 - 64 = -64 Jahren im fehlerhaften Programm ausgewiesen. @BODY VORN = Nicht nur Anwendungen sind betroffen Programme mit Datumsvergleichen wie älter/jünger, später/früher und größer/kleiner werden dann ins Gegenteil umgekehrt. Wie später noch am Beispiel des PC gezeigt wird, ist das Problem aber nicht nur auf Anwendungsprogramme beschränkt. Unterhalb der Anwendung liegt ein weiteres Datumsproblem im Betriebssystem und im verwendeten Kalender (Sommer-/Winterzeit, Zeitzonen, Schaltjahre usw.), und noch eine Stufe darunter, in der Hardware bzw. beim PC im BIOS. Am Beispiel des PC läßt sich das Problem am besten verdeutlichen (da bei UNIX-Systemen und allen anderen Rechnern immer endliche Felder für Zähler und Datumsangaben verwendet werden, treten früher oder später auch hier Probleme auf (wenn die Rechner bis dahin noch existieren). Es gibt fünf Elemente im PC, die seine Datumsfunktionsfähigkeit beeinflussen. Dies sind die CMOS Real Time Clock (RTC), das BIOS, das Betriebssystem, die systemnahe Software sowie die Anwendungen. Alle diese Systemteile können mit dem Datum arbeiten, es lesen und verändern. Beim Einschalten (Boot-Vorgang) des PC ruft das BIOS die RTC auf und übergibt Datum und Uhrzeit an das Betriebssystem. Danach arbeiten praktisch drei Uhren. Vielleicht haben Sie selbst schon mal erlebt, daß man bei verschiedenen Anwendungen (z.B. Datenbankprogrammen) durch unterschiedlichen Gang der Uhren (z. B. gewollte Zeitverschiebungen) unterschiedliche Zeitangaben erhält, je nachdem nach welcher Uhr sich die Anwendung richtet. PCs, die am 1.1.2000 (Samstag) den 1.1.1900 (Montag) anzeigen, haben ein offensichtliches Problem im BIOS oder in der RTC oder in beiden. Aber auch ein richtiges Datum am 1.1.2000 ist noch keine Gewähr für das richtige Arbeiten des PC. Tage oder Wochen später können die PCs noch mit der Zeitangabe durcheinander kommen. Zu den Empfehlungen, was hier zu tun ist, kommen wir später. Sie können aber jetzt schon, da wir uns von der Hardware ausgehend erst auf der zweiten von fünf Stufen befinden, sehen, wie komplex das ganze Problem ist. Wenn wir schon an dieser Stelle etwas genauer die Hardware und das BIOS angeschaut haben, dann bietet es sich gleich an, noch auf eine weitere Zeitbombe hinzuweisen. Ich habe schon von den endlich dimensionierten Zählern und den endlichen Übergabefeldern (Schnittstellen) in den Programmen gesprochen. Hier wird bei vielen Systemen mit einem sogenannten Referenzjahr und einer Fenstertechnik gearbeitet, um das absolute Datum zu bilden. Irgendwann läuft nun jeder Zähler über, d. h. irgendwann bleibt jeder heute im Einsatz befindliche Rechner, wenn er nicht umgebaut wird, stehen (Time-black-out). Alle derzeit im Betrieb befindlichen UNIX-Systeme mit einem Referenzdatum von 1970 werden mit einem 32 Bit-Zähler am 19.1.2038 ihren Geist aufgeben. Probleme können aber schon viel früher auftreten, wenn man nämlich am 20. Januar 2008 laut gesetzlicher Vorschrift ein Verfallsdatum von 30 Jahren für die Software vergeben werden muß und dieses abgewiesen wird. Natürlich kann man hier die neuen 64 Bit-Rechner dagegenhalten, aber im Universitätsumfeld kann es in bestimmten Laborsystemen 32 Bit-Rechner noch lange geben. @BODY VORN = Kalenderwirrwarr weiteres Problem Neben den geschilderten Problemen, die auf die zweistellige Darstellung der Jahreszahl zurückzuführen sind und den Problemen mit den 32 Bit-Countern, möchte ich noch auf ein drittes Problem hinweisen, nämlich den Streit um die Kalenderformel. Das Problem 2000 zieht, wie könnte es anders sein, einen Rattenschwanz weiterer Schwierigkeiten nach sich. Eines dieser Folgeprobleme ist die Schaltjahrberechnung. Da es auf der Welt heute eine Vielzahl von unterschiedlichen Kalendern gibt, haben es sogar Anbieter von modernen Programmiersprachen vorgezogen, den Kalenderwirrwarr erst gar nicht (oder noch nicht) zu implementieren. Wie jeder weiß, ist bei unserem Kalender ein Jahr, das sich ohne Rest durch vier teilen läßt, ein Schaltjahr. Nicht jeder weiß aber, daß Jahrhundertjahre keine Schaltjahre sind, obwohl sie durch vier teilbar sind. Und viele Kalenderformel-Programmierer wußten offensichtlich nicht, daß alle ohne Rest durch 400 teilbaren Jahre aber doch wieder Schaltjahre sind. Dies bedeutet, daß in dem einen oder anderen Programmsystem der 29. Februar 2000 nicht existiert. Hier sind leider mal die unwissenden Programmierer fein raus, die nur davon ausgegangen sind, daß alle durch vier teilbaren Jahre Schaltjahre sind. An diesem Beispiel zeigt sich die Problematik der gesamten Softwareentwicklung. Diejenigen, die nur an einer einzigen Stelle in der Firma oder in der Institution eine Routine zur Schaltjahrberechnung haben, können aufatmen. Allen anderen, die in vielen Anwendungen und in unzähligen Unterprogrammen und Bibliotheken Schaltjahrberechnungen durchführen, reicht die Zeit bis zum 1.1.2000 eventuell nicht mehr aus, wenn erst jetzt mit der Umstellung begonnen wird. Die anderen beiden Umstellungen “Zweistellige Jahreszahl” und “32 Bit- Counter” sind ja auf jeden Fall vordringlich zu analysieren und zu beheben. @UEBER LINIEN = Wie nähert man sich demJahr 2000-Problem? Es gibt für die Anwender der Universität Karlsruhe mehrere Möglichkeiten an das Jahr 2000-Problem heranzugehen. @AUSRUECKEN 2 = 1. Man tut nichts und wartet, was mit den verschiedenen Rechnern und Anwendungen passiert. @AUSRUECKEN 2 = 2. Man entwickelt ganz neue Softwareversionen oder man steigt teilweise auf “Standardsoftware” um, die vom Hersteller als tauglich für das Jahr 2000 ausgewiesen wird. @AUSRUECKEN 2 = 3. Für Anwender, die seit Jahren ihre eigene Software entwickeln, besteht der beste und risikoärmste Weg darin, ihre Systeme auf das neue Datumsformat umzustellen. Bei allen Lösungen im Anwendungsbereich ist jedoch die Gefahr, die, wie oben geschildert, auch aus den vier darunterliegenden Schichten (beim PC) resultiert, nicht zu vernachlässigen. Beim ersten Fall liegt natürlich Fahrlässigkeit vor und es ist viel zu riskant, darauf zu setzen, daß schon alles gut gehen wird. Die zweite Möglichkeit kann bei einer Neuentwicklung sehr teuer werden, wenn sie nur im Hinblick auf das Jahr 2000 durchgeführt werden muß. Im Zuge anstehender neuer Versionen kann sich der zusätzliche Aufwand aber auch in erträglichen Grenzen halten. Der Vorteil bei einem solchen Re-Engineering liegt in der bequemen Nutzung aller Test- und Integrationstools, die für die Softwareentwicklung zur Verfügung stehen. Der Nachteil ist, daß diese Prozedur sehr langwierig ist und es für manche Neuentwicklungen schon zu spät ist. Die dritte Möglichkeit ist eine gezielte Analyse und Umstellung der Datumsfelder, die eine zweistellige Jahreszahl enthalten, in allen betroffenen Programmen. Die folgenden Abschnitte sind als Hinweise und Empfehlungen zu verstehen, die Krise Jahr 2000 zu meistern. Die Hinweise beziehen sich auf Anwendungen wie sie in einem Universitätsumfeld vorwiegend auftreten. Dabei ist immer zu beachten, daß die beste Anwendung nichts nutzt, wenn das darunter liegende Betriebssystem falsche Werte liefert oder die Hardware streikt. @UEBER LINIEN = Analysemethoden Der erste Schritt auf dem Weg zur Jahr 2000-Fähigkeit ist die Analyse der Software. Sie hat das Ziel, all die Stellen zu identifizieren, bei denen Änderungen notwendig sind, also der datumsrelevanten Programmteile. Zunächst soll einmal untersucht und festgestellt werden, welche Anwendungen betroffen sind. Dies dürfte schon die erste Hürde sein. Viele werden behaupten, in den Programmen kommt überhaupt kein Datum vor und Zeitberechnungen werden auch nicht durchgeführt. Also müssen wir nichts tun. Wer so etwas voreilig behauptet, handelt vermutlich fahrlässig, sollte nochmal nachdenken und die Anwendungen auf folgendes hin überprüfen: @BODY BLICK 1 = Arbeiten die Programme mit Schutzfristen und einer Gültigkeitsdauer? @BODY BLICK 1 = Verwenden die Programme intern eine zweistellige Jahresangabe? @BODY BLICK 1 = Verwenden die Programme intern eine vierstellige Jahresangabe, aber für die Ein-und Ausgabe (z.  B. in Bildschirmmasken) eine zweistellige Darstellung? @BODY BLICK 1 = Arbeiten die Programme mit dem Datum von Dateien (Datei erzeugt, zuletzt geändert usw.) oder verwenden sie Datumsangaben für Dateinamen? Diese Überprüfung kann nur anhand der Dokumentation (sofern vorhanden) und über den  Quellcode des Programmes erfolgen. Hier sind alle Programmiersprachen eingeschlossen. Die Programme, bei denen eine zweistellige Darstellung zu kritischen Programmfehlern führt, müssen überarbeitet werden. Wie wir später noch sehen werden, bedeutet dies aber nicht automatisch, daß Sie eine vierstellige interne Darstellung verwenden müssen. Es gibt auch andere Möglichkeiten mit einer zweistelligen Jahreszahl richtige Programme zu schreiben. Auch die Eingabe- und Ausgabemasken müssen Sie nicht notwendigerweise von zwei auf vier Stellen aufbohren. Oft steht der Platz auf dem Bildschirm auch gar nicht zur Verfügung. An das “00” in einer Bildschirmmaske muß man sich halt gewöhnen. Also nochmal, nicht jedes Programm mit einer internen oder externen zweistelligen Jahreszahldarstellung stürzt ab oder liefert falsche Ergebnisse. Das Erkennen datumsrelevanter Programmteile stützt sich auf das Erkennen von Datumsfeldern, und wo innerhalb dieser Felder welche Datumsinformation abgelegt ist. Diese Datumsobjekte können je nach verwendbarer Programmiersprache (FORTRAN, C, PASCAL, SQL, PL/SQL) an folgenden Stellen auftreten: @BODY VORN = @BODY BLICK 1 = Bei internen, lokalen oder globalen Variablen, Konstanten und Parametern @BODY BLICK 1 = in logischen Ausdrücken und Vergleichen @BODY BLICK 1 = in arithmetischen Ausdrücken (z. B. die Bestimmung der Arbeitstage zwischen zwei Terminen) @BODY BLICK 1 = in Ein- und Ausgabeanweisungen @BODY BLICK 1 = in Dateiattributen und Dateinamen @BODY BLICK 1 = in Datenbankfeldern (als Date-Format, und schlimmer noch, als Charakter-Format oder Integer) @BODY BLICK 1 = in Sortieranweisungen. @BODY VORN = Es gibt kaum exakt formale Möglichkeiten, alle Datumsfelder zu erkennen. Man ist darauf angewiesen, diese aufgrund der Variablennamen, der Feldnamen, der Feldgröße, des Datentyps und der hoffentlich vorhandenen Programmdokumentation zu identifizieren.  Zu Beginn der Suche nach datumsrelevanter Information haben sich folgende Methoden als sinnvoll erwiesen und in der Praxis durchgesetzt: @BODY BLICK 1 = Suche nach Feldern, Parametern, Konstanten und Variablen (Objekten) mit datumsrelevanten Namen @BODY BLICK 1 = Suche nach Feldern, Parametern, Konstanten und Variablen, die nach Größe und Datentyp mit gewisser Wahrscheinlichkeit Datumsdaten speichern können. @BODY BLICK 1 = Durchsicht der Dokumentation und der Bedienungsanleitungen sowie Befragung der Autoren, sofern diese noch greifbar sind. @BODY VORN = @BODY VORN = Käufliche Tools an Universität kaum einsetzbar Die Kriterien, nach denen gesucht wird, sind zunächst ganz allgemeiner Natur (z. B. kommt die Zeichenfolge ‘datum’, ‘dat’ oder ‘date’ in Vereinbarungen vor) und können dann aber nach fachspezifischen Gesichtspunkten erweitert werden. So werden z.B. Variablen, die bestimmte datumsabhängige Informationen enthalten, bei Programmen aus der Geologie mit anderen Bezeichnungen versehen als bei einem Programm zur Lohnbuchhaltung. Mit wachsender Erfahrung kommt man von Programm zu Programm auch zu immer besseren und treffsicheren allgemeinen Kriterien. Obwohl die genannten Methoden nicht vollständig formal sind, müssen sie wegen der auftretenden Datenmengen in der praktischen Anwendung toolgestützt sein. Im Universitätsfeld, in dem mit sehr vielen unterschiedlichen Programmiersprachen gearbeitet wird und in dem unterschiedliche Betriebssysteme und Hardware im Einsatz sind, kann man davon ausgehen, daß sich mit käuflichen Tools wenig ausrichten läßt. Wir müssen davon ausgehen, daß sich die Umstellung nicht vollständig automatisieren läßt. Eine Vergabe an Fremdfirmen kommt aus Kostengründen für ein Universitätsinstitut auch nicht in Frage. @BODY VORN = RZ richtet “Softwarebörse Jahr 2000” ein Jeder in der Universität, der spezielle Tools für seine Applikationen entwickelt hat, sollte diese zusammen mit seinen Erfahrungen in einem gemeinsamen Pool zur Verfügung stellen, um anderen die Arbeit zu erleichtern. Der Autor dieses Artikels ist für jeden Hinweis dankbar und wird auf dem WWW-Server des RZ eine “Softwarebörse Jahr 2000” einrichten. Die am Markt befindlichen Tools beziehen sich vorwiegend auf alte Datenbankanwendungen in Verbindung mit COBOL- oder Assembler-Programmen. Wenn nach der oben beschriebenen Methode vorgegangen wird, dann bekommt man zumindest Startwerte von Variablen und Feldern und kann anschließend unter Berücksichtigung der Semantik der Programmiersprache eine Datenflußanalyse durchführen. Bei einer solchen Analyse wird der Weg der in der Anfangsvariablen vorhandenen Datumsinformationen zu anderen Variablen und Feldern verfolgt. Hier kann man die bei modernen Compilern und Entwicklungstools vorhandenen Analysetools gut einsetzen. Um es noch einmal zu betonen: für Programme, die auf den Anlagen des Rechenzentrums und auf den Institutsrechnern laufen, sind die am Markt befindlichen Analysetools oft nicht geeignet oder auch zu teuer. Zuerst sollten Sie deshalb mit dem Rechenzentrum sprechen, sich für eine erste Analyse eventuell selbst ein kleines Programm schreiben oder die Analysemöglichkeiten der Standardcompiler ausnutzen (Debugmöglichkeiten). @UEBER LINIEN = Die Umstellung der Anwendung Unter Umstellung versteht man das Ändern des Codes und gegebenenfalls des Datenbestandes, so daß die Anwendung Jahr 2000-fähig wird. Wenn es sich um Standardanwendungen eines Herstellers handelt, lassen Sie sich sofort eine neue Version kommen, die auch über das Jahr 2000 hinaus ablauffähig ist. Wenn es den Hersteller der Software nicht mehr gibt, dann ist es an der Zeit, sofort auf ein neues Nachfolgeprodukt umzusteigen. Schauen Sie auch mal auf die umfangreichen Softwareangebote des Rechenzentrums und lassen Sie sich von der Abteilung Rechneranwendungen beraten. @BODY VORN = 1. FORTRAN- und C-Programme Wenn es sich um eine am Institut selbst entwickelte Software handelt, dann sollte der Quellcode auf jeden Fall noch vorhanden sein. Es gibt dann mehrere Umstellungsstrategien. Die naheliegendste und von vielen als “sauberste” bezeichnete Lösung besteht in der Beseitigung der Ursache des Problems, nämlich in der Erweiterung der Jahresfelder von zwei auf vier Dezimalstellen. Wie früher schon einmal erwähnt, muß dies nicht unbedingt bedeuten, daß Sie auch Ihre Bildschirmmasken auf vier Stellen erweitern, da hier die schnelle Eingabe und der Platzbedarf vieler Datumsfelder auf der Maske gegen vier Stellen spricht. Die als Felderweiterung bekannte Strategie hat den Vorteil, daß sie für alle kommenden Jahrtausende gültig ist und zur konzeptionellen Klarheit und Übersichtlichkeit der Programme beiträgt. Probleme gibt es dann in dieser Beziehung erst wieder nach dem Jahr 9999, wegen anderer Unzulänglichkeiten aber schon sehr viel früher (siehe Datenbanken oder 32 Bit-UNIX-Systeme). Diese radikale Methode hat aber auch Nachteile, die dazu führen, daß sie recht selten zur Anwendung kommt. Es müssen unter Umständen alle alten Datenbestände ebenfalls migriert werden, und bei verteilten Systemen ein eventuell stattfindender Datenaustausch über das Netz zusammen mit allen beteiligten Partnern umgestellt und angepaßt werden. Das am weitesten verbreitete Verfahren ist die Einführung eines Jahrhundertfensters. Dieses Verfahren läßt die Datenformate unverändert und hat deshalb keinen Einfluß auf alte Datenbestände und Austauschformate. Allerdings ist dieses Verfahren auf einen Zeitraum von 100 Jahren beschränkt, was in manchen Fällen nicht ausreicht. Wenn wir z.B. personenbezogene Daten halten und dabei über hundert Jahre alte Personen verwalten, bekamen wir in der Vergangenheit schon Probleme. Außerdem erfordert die Festlegung der zeitlichen Positionierung des Jahrhundertfensters eine genaue Kenntnis der Anwendung. Ein Beispiel aus vielen alten FORTRAN-Programmen verdeutlicht diese Fenstermethode. Wenn z. B. das Geburtsdatum eines Menschen im Jahre 2001 mit 27.3.39 angegeben wurde, dann wird zunächst das aktuelle Jahr aus der zweistelligen Jahreszahl nach folgender Methode berechnet: Ist die Jahreszahl kleiner als 50, dann wird 2000 zur Jahreszahl addiert, ist sie größer als 50, dann sind wir noch im 20. Jahrhundert, und es wird 1900 addiert. Entsprechend geht man beim Geburtsdatum vor. Ist der Wert größer oder gleich dem aktuellen Jahr (39 ist größer als 1), dann wird zum Geburtsjahr 1900 addiert, ist der Wert kleiner als das aktuelle Jahr, dann wird 2000 addiert. Wie gesagt, das geht schief (auch in den heutigen Programmen), wenn jemand älter als 100 Jahre ist. Das dritte Umstellungsverfahren ist sehr technisch orientiert und eigentlich ein Rückschritt in die Bit-Spar-Zeit. Man verwendet eine binäre Verschlüsselung der Jahreszahl in zwei Bytes. Da man binär in 16 Bits 216 = 65536 Zahlen unterbringen kann, stellt die Jahrtausendwende hier kein numerisches Problem dar.  Die Verständlichkeit leidet natürlich und alle auf das so dargestellte Datum zugreifenden Unterprogramme müssen geändert werden. Ein Vorteil ist dagegen, daß man durch geschickte Wahl der Verschlüsselung dafür sorgen kann, daß das bisherige alte Datum ungeändert neben dem neuen Wertebereich liegen bleibt, und somit zur Laufzeit erkannt wird, ob es sich um ein neues oder altes Datum handelt. @BODY VORN = 2. Datenbankanwendungen Das relationale Datenbanksystem ORACLE ist als Standard in der Universität Karlsruhe eingeführt. ORACLE hat für das Datum einen eigenen Datumstyp vorgesehen (den übrigens nicht alle Anwendungen verwenden). Der Bereich einer Datumsvariablen vom Typ DATE reicht vom 1. Januar 4712 vor Christus bis zum 31. Dezember 4712 nach Christus. Ich glaube, daß wir uns für die Zeit danach jetzt noch keine Gedanken machen müssen. Beim ORACLE-Datentyp DATE werden intern, unabhängig davon, wie die Daten erzeugt wurden, immer folgende Informationen gespeichert: @BODY TABS = 1 Jahrhundert @BODY TABS = 2. Jahr @BODY TABS = 3 Monat @BODY TABS = 4. Tag @BODY TABS = 5. Stunde @BODY TABS = 6. Minute @BODY TABS = 7. Sekunde @BODY TABS = Da diese interne Speicherung grundsätzlich verwendet wird, kann es natürlich bei der Speicherung keine Probleme mit der Jahrtausendwende geben.<%-3> Es gibt allerdings genügend Möglichkeiten, die intern gespeicherten Informationen nicht zu benutzen, um damit seltsame Effekte zu produzieren. <%-4>Ich denke dabei nicht nur an Programmierer, die CHARACTER-, INTEGER- od<%-3>er REAL-Variablen für die Speicherung eines Datums verwenden.<%0> Das Datum wird in einem festen Format mit einer Länge von 7 Byte wie folgt abgespeichert: @BODY TABS = 1. Byte Jahrhundert @BODY TABS = 2. Byte  -  Jahr @BODY TABS = 3. Byte  -  Monat @BODY TABS = 4. Byte  -  Tag @BODY TABS = 5. Byte  -  Stunde @BODY TABS = 6. Byte  -  Minute @BODY TABS = 7. Byte  -  Sekunde @BODY TABS = @BODY VORN = Ein Beispiel zur Verdeutlichung: @BODY TABS = drop table person; @BODY TABS = create table person (name VARCHAR2(30), geburt DATE); @BODY TABS = insert into person values(‘Bärbel’, TO_DATE (‘29-Feb-2000 15:30’, @BODY TABS = ‘DD-MON-YYYY HH24:MI’)); Mit der DUMP-Funktion können Sie z.B. die interne Darstellung des Datums in der Datumsvariablen selektieren. @BODY TABS = select geburt, DUMP (geburt,16,1,7) “Hex” from person where name=’Bärbel’; @BODY TABS = GEBURT   Hex @BODY TABS = 29.02.00 Typ=12 Len=7: 78,64,2,1d,10,1f,1 @BODY TABS = Typ=12 ist der Typ für das DATE-Format @BODY TABS = Len=7 gibt die Länge an, mit der das Datum abge- speichert ist @BODY TABS = 78 Hex ->> (1) 20 = 20. Jahrhundert @BODY TABS = 64 Hex ->> (1) 00 = Jahr 00 @BODY TABS = 2 Hex ->> 2 = Monat Februar @BODY TABS = 1d Hex ->> 29 = Tag im Monat @BODY TABS = 10 Hex ->> 16- = 15 Stunden *)1f Hex ->> 31-1 = 30 Minuten *) @BODY TABS =  1 Hex ->> 1-1 = 0 Sekunden    (seit 24:00 Mitternacht) @BODY TABS = *) das letzte Bit ist bei Stunden und Minuten immer gesetzt @BODY TABS = @BODY VORN = Formate und Filter für die Ein- und Ausgabe von Datumswerten Die Probleme in den alten Anwendungen wurden dadurch ausgelöst, daß man aus Bequemlichkeit in den letzten Jahren das Jahrhundert einfach bei allen Programmen (FORTRAN- oder C-Programmen oder in SQL) weggelassen hat. Wenn man 92 eingibt, bedeutete dies bisher 1992, und was noch schlimmer ist, man hat oft das Jahrhundert (1900) fest in die Programme hineincodiert. Ein ganzer Industriezweig lebt nun seit einiger Zeit davon, alle COBOL-, FORTRAN-, C- und SQL-Programme nach diesem unsinnigen ‘Jahrhundertschlendrian’ zu durchsuchen und ihn möglichst automatisch bzw. halbautomatisch zu beseitigen. Das Problem liegt also in den Anwendungen und nicht in der Datenbank selbst. Es fängt damit an, daß Sie sich ORACLE-Umgebungsvariablen definieren, um z.B. die Sprache auszuwählen (Sortierung nach deutschem Alphabet), die interne Zahlendarstellung zu definieren oder eine Standardvorgabe für das Datumsformat festzulegen (z. B. NLS_DATE_FORMAT DD-MON-YY). Diese Definitionen sind natürlich ganz bequem, da man sie auf Instanzebene, Sitzungsebene oder auf SQL-Anweisungsebene jeweils neu setzen und ändern kann, aber auf der anderen Seite auch sehr gefährlich, da man immer wissen muß, welchen Filter man gerade benutzt. Hinzu kommen noch die gegenseitigen Abhängigkeiten der einzelnen Umgebungsvariablen. So hat das Setzen der Sprache auch durchaus einen Einfluß auf das Datumsformat. Die ORACLE-Umgebungsvariable NLS_DATE_FORMAT muß, wenn man über das Jahr 2000 hinaus plant, unbedingt auf DD-MON-YYYY gesetzt werden. Diese Einstellung sollte bereits beim Hochfahren der Instanz wirksam werden, damit alle Benutzer und Programme standardmäßig mit dieser Einstellung arbeiten. In Sonderfällen kann diese ORACLE-Umgebungsvariable auch mit der ALTER SESSION-Anweisung gesetzt oder verändert werden. Eine weitere Möglichkeit, die allerdings Programmänderungen voraussetzt, ist die Verwendung eines entsprechenden Formates beim Aufruf der TO_DATE Funktion auf SQL-Ebene. @BODY VORN = Ein Beispiel soll dies wieder deutlich machen: @BODY VORN = insert into person (name, GEB) VALUES @EINRUECKEN = (‘Klaus’, TO_DATE (‘27-AUG-1939 12:50 A.M.’,’ DD-MON-YYYY HH:MI A.M.’));<%-9> Mit allen Datumsvariablen können Sie beliebige Arithmetik betreiben. Es gibt, wie später noch erklärt wird, viele praktische und nützliche Datumsfunktionen. Ganze Zahlen in arithmetischen Ausdrücken sind immer Tage. So ist SYSDATE + 1 der morgige Tag. SYSDATE + (10/1440) ist 10 Minuten später von jetzt an gerechnet. Multiplizieren oder dividieren sollten Sie Datumsvariablen allerdings nicht. Einige Datumsfunktionen sollen Ihnen die Umstellung erleichtern. Anstelle eigener Programme können Sie eventuell auf die folgenden standardisierten Routinen zurückgreifen: @BODY VORN = ADD_MONTHS Um ganze Tage können Sie ein Datum einfach durch die Addition oder Subtraktion einer ganzen Zahl manipulieren. Bei Monaten ist dies wegen der unterschiedlichen Zahl der Monatstage nicht ganz so einfach, hier hilft die Funktion ADD_MONTHS. (Bitte beachten Sie das Plural-S am Ende der Funktion. Die Regeln, nach denen die einzelnen Datumsfunktionen arbeiten, können Sie im Server SQL Reference Manual nachlesen. @BODY VORN = Beispiel: @EINRUECKEN = select TO_CHAR (ADD_MONTHS (geb, 1), ‘DD-MON-YYYY’) “Nächster Monat” from person where name = ‘Klaus’; @BODY VORN = LAST_DAY @BODY VORN = Damit können Sie den letzten Tag im Monat abfragen. @BODY VORN = Beispiel: select SYSDATE, LAST_DAY (SYSDATE) “Letzter Tag”, LAST_DAY (SYSDATE) - SYSDATE “Verbleibende Tage” from dual; @BODY VORN = MONTHS_BETWEEN Anzahl der Monate zwischen zwei Datumswerten. Eine ganze Zahl ist das Ergebnis, wenn es sich um den gleichen Monatstag bzw. den jeweils letzten Tag im Monat handelt. In den anderen Fällen wird ein Rest auf der Basis eines 31-Tage-Monats berechnet. @BODY VORN = Beispiel: select MONTHS_BETWEEN(TO_DATE(‘01-01-2000’,’MM-DD-YYYY’),TO_DATE(‘12-15-1997’,’MM-DD-YYYY’)) “Monate bis zum Crash” from dual; Ergebnis: Monate bis zum Crash     24,548387 @BODY VORN = Datumsformate Da Sie vermutlich in Ihren Datenbankanwendungen als Standardformat für das Jahr ‘YY’ gesetzt haben, kann es natürlich Probleme beim Wechsel vom Jahr 1999 zum Jahr 2000 oder bei personenbezogenen Daten von Menschen, die älter als 100 Jahre sind, geben. Auch die Formate der zweistelligen Eingabemasken müssen überprüft werden. Verwenden Sie jedoch schon jetzt als Standardformat für das Jahr ‘YYYY’ dann kann nichts passieren. Hinweisen möchte ich Sie aber auch noch auf das Jahrhundertformat ‘CC’ oder ‘SCC’ und die Jahresdarstellung nach ISO-Standard (I, IY, IYY, IYYY). Nützlich, wenn auch nicht empfehlenswert, kann auch die Darstellung des Jahres durch ‘RR’ sein. Dieses Format wurde für diejenigen geschaffen, die unbedingt zweistellig über die Jahrtausendwende hinweg kommen wollen. Hier gibt es vier verschiedene Fälle, je nachdem, ob man sich in einem aktuellen Jahr kleiner oder größer 50 befindet und ob die angegebene Jahreszahl kleiner oder größer 50 ist. Das Jahrtausend spielt dabei keine Rolle, man bekommt unter diesen Randbedingungen immer das gleiche Ergebnis. Die Datumsformate können wie schon oben erwähnt, auf Instanz-ebene, auf Sessionebene und auf SQL-Ebene gesetzt werden. Wenn Sie keinen Einfluß auf die Instanz haben, dann können Sie z.B. mit @BODY VORN = ALTER SESSION SET NLS_DATE_FORMAT = ‘YYYY MM DD HH24:MI:SS’ @BODY VORN = das Format, oder mit @BODY VORN = ALTER SESSION SET NLS_DATE_LANGUAGE = German @BODY VORN = die Datumssprache für diese Sitzung neu festlegen. Sie können natürlich in jedem Programm eine dem Endanwender angepaßte Form wählen, auch wenn immer auf die gleichen Daten zugegriffen wird. Dies trifft nicht nur auf das Datum zu, sondern auch auf alle anderen Datenbankattribute wie Sortierungen und das Währungsformat. @UEBER LINIEN = Test und Inbetriebnahme Das Ziel der Tests ist es, nachzuprüfen, ob die Programme zeitverschoben über die Jahrtausendwende genau so arbeiten wie bisher. Sie sollten deshalb die Programme jetzt zuerst mit aktuellen Daten testen (und nach erfolgreichem Test auch sofort in Betrieb nehmen). Hat man ein Testumfeld für heutige Verhältnisse erstellt, dann muß man alle Datumsinformationen in das neue Jahrtausend verschieben. Führt man dies von der Hardware bis zu der Anwendung konsequent durch, dann hat man durch diese “Zeittransformation” einen Idealfall konstruiert, von dem in der Praxis allerdings oft etwas abgewichen werden muß. Denken Sie aber auch daran, noch einige Jahre in das neue Jahrtausend hineinzugehen, da nicht alle Probleme schon am 1. oder 2. Januar 2000 auftreten. Die Datumsfunktionen und Routinen, die ein Datum verarbeiten, sollten auf jeden Fall noch mit den folgenden vier kritischen Datumswerten getestet werden: @BODY TABS =  9. September 1999 @BODY TABS = 31. Dezember 1999 @BODY TABS =  1. Januar 2000 29. Februar 2000 @BODY TABS = Auch sollte in der Testumgebung der Übergang von einem Tag zum nächsten Tag an den folgenden Teminen überprüft werden: @BODY TABS = vom 31. Dezember 1998 auf den 1. Januar 1999 @BODY TABS = vom 31. Dezember 1999 auf den 1. Januar 2000 @BODY TABS = vom 28. Februar 2000 auf den 29. Februar 2000 @BODY TABS = vom 29. Februar 2000 auf den 1. März 2000 @UEBER LINIEN = Einige Tips und weitere Informationen Nicht in Panik geraten, heute noch handeln, und die Dinge nicht auf morgen verschieben, lautet die Devise. Die Vorbeugungsmaßnahmen für das Jahr 2000 haben absolute Priorität. Gehen Sie nicht davon aus, daß sich alles automatisieren läßt. Das Jahr 2000-Problem ist nicht allein auf Anwendungen beschränkt. Die Gefahr, daß das Datum nur mit zweistelliger Jahreszahl in den Chips geführt wird, besteht durchaus. Und wenn die Jahreszahl dann nur zweistellig weitergereicht oder vom Betriebssystem nicht auf vier Stellen erweitert wird, dann besteht Handlungsbedarf. @BODY VORN = Einige Jahr 2000-Mythen zum Schluß: @BODY BLICK 1 = Das Problem 2000 betrifft nur Mainframes und nicht UNIX-Systeme und schon gar nicht PCs @BODY BLICK 1 = Bei den PCs ist es ein reines BIOS-Problem, das durch Austausch beseitigt wird @BODY BLICK 1 = Man kann mit einem einfachen Abschalttest (Datum verstellen) die Probe aufs Exempel machen @BODY BLICK 1 = Mein PC ist neu, ich habe kein Problem @BODY BLICK 1 = Wir verwenden ORACLE als Datenbank, uns kann nichts passieren @BODY BLICK 1 = Es sind ja noch 2 Jahre Zeit @BODY BLICK 1 = Bis dahin haben wir nur noch neue, einwandfreie PCs und 64 Bit-UNIX-Systeme @BODY BLICK 1 = Unter UNIX gibt es das Problem gar nicht. Es existiert schließlich die C-Standard-Library , außerdem das normale Programm TIME() mit einer Manualpage @BODY BLICK 1 = Die Sache ist nicht schwieriger als die Postleitzahlen-Umstellung @BODY BLICK 1 = Das Problem betrifft uns erst nach dem 31. Dezember 1999 @BODY VORN = <%-2>Ganz zum Schluß noch nützliche Literaturhinweise. Fast jede Woche erscheinen Artikel in allen IT-Fachzeitschriften mit Hinweisen zu der Jahr 2000-Umste<%0>llung: iX Magazin Computer Woche Computer Zeitung it Management Datenbank Fokus usw. Einen Einstieg, viele gute Ratschläge und viele Anbieter von Umstellungstools finden Sie auch unter http://www.year2000.com. @BODY VORN = Dr. Klaus Hanauer, Tel. -2069, Email: hanauer@rz. uni-karlsruhe.de. @UEBER = “Bitte keine Werbung einwerfen” - Spamming vor Gericht @AUTOR FUNKTIN = Rechtsanwalt Dr. Stefan Ernst, Freiburg/Br. Durch Beschluß vom 14.10.1997 hat das Landgericht Traunstein eine einstweilige Verfügung erlassen, die feststellte, daß das unverlangte Senden von Werbematerial an einen Email-Privatanschluß gegen das deutsche Wettbewerbsrecht verstoße. Der folgende Beitrag erläutert Inhalt und Reichweite dieser Entscheidung. Die Frage, ob Unternehmen für ihre Werbung auch auf Telekommunikationseinrichtungen zurückgegreifen dürfen, hat die Rechtsprechung schon des öfteren beschäftigt. Unverlangte Werbung über Telefon, Telefax und Btx ist unzulässig. Diese Fragen sind inzwischen, zum Teil mehrfach, höchstrichterlich geklärt worden. Die Gründe hierfür sind offenbar. Der eigentliche Zweck der Geräte wird beeinträchtigt. Die Erreichbarkeit des Adressaten wird eingeschränkt - je mehr Werbung umso stärker. Telefax-Werbung kostet zudem Papier, Btx-Werbung Telefonkosten beim Abruf der Nachrichten. Diese Rechtsprechung kann auf Werbung per Email ohne weiteres übertragen werden. Die juristische Literatur ist sich in dieser Frage nahezu einig. Auch eine Kennzeichnungspflicht für Werbung hilft hier nicht weiter. Auch gekennzeichnete Werbemails müßten auf dem Email-Zentralrechner des Providers gespeichert werden - sofern dessen Platz ausreicht. Irgendwann liefen auch seine Anschlüsse sämtlichst über. Das Löschen von Werbung auf dem Host kostet zudem ebenfalls Rechner- und Telefonzeit. Hinzu tritt ein ganz besonders gewichtiges Argument. Wäre Email-Werbung erlaubt, würde der gesamte elektronische Briefverkehr schnell als solcher ad absurdum geführt. Durch die ungemein preiswerte Möglichkeit, massenhaft Werbung zu versenden, würde in Kürze das Netz überquillen. Private Emails hätten kaum eine Chance, im Meer von Reklame aufzutauchen. Schon deshalb muß das unverlangte Versenden von Emails im geschäftlichen Verkehr zu Wettbewerbszwecken unzulässig sein. Der Beschluß des LG Traunstein ist die erste gerichtliche Äußerung zu dieser Frage. Man mag bei der Bewertung der Entscheidung einschränkend festhalten, es sei lediglich ein Verfügungsverfahren gewesen, in dem ein Untergericht geurteilt habe. Dazu ist aber zu bemerken, daß das sachliche Ergebnis des Landgerichts Traunstein der ganz herrschenden Meinung in der juristischen Literatur entspricht, die fast durchgehend der Ansicht ist, daß Email-Werbung wettbewerbswidrig sei. Auch deshalb ist zu erwarten, daß der Beschluß auch in der nächsten Instanz gehalten wird. Die Entscheidung ist uneingeschränkt zu begrüßen. Diese Rechtsfrage hat im übrigen auch Bedeutung für Emails, die von ausländischen Providern kommen. Deutsches Wettbewerbsrecht ist stets dann anwendbar, wenn der Ort der Interessenkollision in Deutschland liegt. Eine ausländische Firma kann sich also nicht auf weitergehendes fremdes Recht berufen, wenn sie die von ihr beworbenen Produkte auch in Deutschland anbietet. Inwieweit sich ein entsprechendes Urteil, insbesondere beim reinen Online-Vertrieb aus dem Ausland, durchsetzen läßt, ist eine andere Frage. @UEBER = Das neue BelWü-ATM-Netz @AUTOR FUNKTIN = Dr. Bruno Lortz @UEBER LINIEN = Verbesserungen und erweiterte Möglichkeiten Das BelWü-Netz ist jetzt komplett auf ATM (Asynchronous Transfer Mode) umgestellt. Provider ist die Stuttgarter Firma TESION (vormals CNS), eine Tochtergesellschaft des Badenwerks, der EVS und der Schweizer Telecom. Angeschlossen sind das MWK, alle Landesuniversitäten und sechs Fachhochschulen in Aalen, Eßlingen, Heilbronn, Offenburg, Pforzheim und Ravensburg-Weingarten. Das ATM-Management führt das Rechenzentrum der Universität Karlsruhe durch. Das neue Landesnetz bietet eine Reihe von Verbesserungen und neuen Möglichkeiten: @BODY VORN = IP-Verkehr Für den IP-Verkehr wurden die Bandbreiten deutlich erhöht. Ferner wurde die Betriebssicherheit durch mehr redundante Wege verbessert. @BODY VORN = Telefonverkehr Eine BelWü-Arbeitsgruppe arbeitet an einem Projekt mit dem Ziel, Telefonverkehr über das BelWü zu übertragen. Diese Gruppe hat bereits einige vielversprechende Versuche durchgeführt. Derzeit gibt es einen Testbetrieb, an dem das MWK in Stuttgart und die Universitäten Mannhein und Ulm teilnehmen. @BODY VORN = Direkte ATM-Verbindungen landesweit Es besteht jetzt auch die Möglichkeit, landesweit direkte Verbindungen zwischen zwei oder auch mehreren Endgeräten zu schalten. Die Verbindungen werden stundenweise, in Ausnahmefällen auch tageweise geschaltet. Periodische Schaltungen (z. B. jeden Donnerstag von 10 bis 12 Uhr) sind ebenfalls möglich. <%-2>Dieser Dienst ist für Aufgaben vorgesehen, die unbedingt ATM benötigen, um eine hohe Dienstqualität zu bieten. Typische Anwendungen sind Videokonferenzen und die Übertragung von Lehrveranstaltungen. <%0> Voraussetzung für diesen Dienst ist, daß direkte ATM-Verbindungen von den Endgeräten zu den jeweiligen Rechenzentren und von dort zum BelWü geschaltet werden können. Ansprechpartner für die Uni Karlsruhe ist Herr Strebler, Tel. -2068, Email: strebler@rz.uni-karlsruhe.de. @UEBER = Neuer Compute-Server für kommerzielle Anwendungen @AUTOR FUNKTIN = Rolf Mayer Zum Ende des Jahres wurde als Ablösung des HP 9000/755-Computeservers NZ55 eine vielfach leistungsfähigere Silicon Graphics ORIGIN 2000 beschafft (Infos: http://www.sgi.com/origin/ 2000/desk.html). Die Maschine verfügt über 8 Prozessoren (R10000, 195 MHZ, 4 MB secondary cache), 3 GB Hauptspeicher sowie 140 GB Plattenplatz (16 Platten, gestriped über 4 Ultra-SCSI-Kanäle)und ist über die Adresse rzanw1 (rzanw1.rz. uni-karlsruhe.de) erreichbar. Einen Zugang zum Rechner erhalten Sie über die Betriebsauskunft, Raum -156 im UG des RZ, Tel. -3751, Email: ba@rz.uni-karlsruhe. de. @BODY VORN = Die alte NZ55 geht zum 28.2.98 außer Betrieb. @UEBER LINIEN = Verfügbare Anwendungen @BODY VORN = Als Anwendungen stehen Ihnen auf dieser neuen Maschine zunächst folgende Pakete zur Verfügung: @BODY VORN = @BODY VORN = ANSYS @BODY VORN = Finite-Elemente-Programm zur Lösung von statischen und dynamischen, linearen und nichtlinearen Festigkeitsproblemen<%-3>. Nähere Informationen:  http://www. uni-karlsruhe.de/~ANSYS. @BODY VORN = @BODY VORN = <%-3>ABAQUS <%0> @BODY VORN = Finite-Elemente-Programm zur Lösung strukturmechanischer Probleme mit besonderen Anwendungsschwerpunkten (Umformtechnik, große Verschiebungen und Rotationen, große Dehnungen, Beulen, Bruchmechanik, Kontaktprobleme, gekoppelte Wär<%-3>me- und Spannungsanalysen, Akustik, ...) Nähere Informationen: http://www.uni-karlsruhe.de/~ABAQUS. @BODY VORN = @BODY VORN = NASTRAN @BODY VORN = Finite-Elemente-Programm für strukturmechanische Probleme (statische und dynamische Probleme, geometrisch und physikalisch nichtlineare Probleme, lineare Probleme, Wärmeausbreitung, Akustik, Design-Optimierung, ...) Nähere Informatione: http://www. uni-karlsruhe.de/~NASTRAN. @BODY VORN = @BODY VORN = MAFIA @BODY VORN = <%-3>Programm zur Lösung der Maxwell-Gleichungen nach dem Finiten-Integrations-Algorithmus. Nähere Informationen: http://www.uni-karlsruhe.de/~MAFIA.<%0> @BODY VORN = Im Laufe der Zeit werden weitere Pakete angeboten werden. @UEBER LINIEN = Betriebsmodell Das System wird als reiner Batch-Rechner ähnlich dem NZ55-Betriebsmodell betrieben. Das Einloggen auf der Maschine ist zwar möglich, es kann jedoch nur ein sehr begrenzter UNIX-Befehlsumgang genutzt werden: @BODY TABS = ls bzw. ll zum Ansehen der Inhaltsverzeichnisses @BODY TABS = cp zum Kopieren von Daten @BODY TABS = rm zum Löschen von Daten @BODY TABS = mv <%-2>zum Verschieben bzw. Umbenennen von<%0> Daten @BODY TABS = man zur Ausgabe von Manual-Seiten. @BODY TABS = Wenn Sie sich an der Maschine einloggen, landen Sie in Ihrem lokalen HOME-Verzeichnis. Hierbei handelt es sich um ein großes und schnelles Dateisystem mit temporärem Charakter, d. h. die Daten werden weder gesichert, noch sollten Dateien über längere Zeit auf den Platten verbleiben. <%-2>Dateien, die über längere Zeit nicht mehr benutzt wurden, werden bei Bedarf gelöscht. Parallel hierzu steht Ihnen Ihr zentrales HOME-Verzeichnis, das Ihrem HOME-Verzeichnis an unseren Workstations entspricht, zur Verfügung. Dieses erreichen Sie über den Pfad /home/ws/Benutzernummer. Sollte Ihre Benutzernummer xx06 sein, so können Sie mit dem Komman<%0>do cd /home/ws/xx06 @BODY VORN = in Ihr zentrales HOME-Verzeichnis gelangen. Sie sollten Ihre wichtigen Dateien immer hierher kopieren. Analog wird das lokale HOME-Verzeichnis der rzanw1 an den Workstations des Rechenzentrums unter dem Pfad /home/rzanw/<> bzw. über die Umgebungsvariable $RZANWHOME zur Verfügung stehen. Wenn Sie cd $RZANWHOME @BODY VORN = eingeben, landen Sie automatisch im richtigen Verzeichnis. Hier können Sie dann z. B. das Pre- und Postprocessing und alle sonstigen Arbeiten erledigen. @BODY VORN = Als Batch-System wird Generic-NQS eingesetzt. Zur Kontrolle der Warteschlange und Ihrer Jobs stehen Ihnen drei weitere Programme zur Verfügung: @BODY VORN = qstat -a @BODY VORN = Mit diesem Kommando erhalten Sie alle notwendigen Informationen über die Jobs in den NQS-Warteschlangen @BODY VORN = qdel [-k]  @BODY VORN = Mit dem qdel-Kommando können Sie Ihre Jobs aus der Warteschlange löschen. Um wartende Jobs zu löschen, können Sie das Kommando ohne die k-Option ausführen. Bereits gestartete Jobs können Sie nur durch Angabe der k-Option abbrechen. Mit dem qcat-Kommando können Sie bereits zur Laufzeit Ihres Programms die Ausgabedateien Ihres Jobs ansehen. @BODY VORN = qcat -e @BODY VORN = Mit diesem Befehl wird die bis dahin erzeugte Fehlerdatei ausgegeben. @BODY VORN = @BODY VORN = qcat -o @BODY VORN = Mit diesem Befehl werden die bis dahin protokollierten Ausgaben angezeigt. Vorsicht! Diese Dateien können sehr groß sein! Da oft nur das Ende der Ausgabedatei interessant ist, benutzen Sie daher am besten das folgende Kommando. @BODY VORN = @BODY VORN = qcat -o -t n=20 @BODY VORN = Mit der t-Option werden die letzten n Zeilen der Ausgabedatei angezeigt. Die Kommandos können Sie von allen Workstations des RZ und allen Institutsworkstations, die über die “Kleine Baumschule” verfügen, absetzen. Jeder Befehl muß aus Sicherheitsgründen mit der Passworteingabe authentifiziert werden. Wenn Sie sehr viele solcher Transaktionen durchführen möchten, kann es sinnvoll sein, sich direkt am SGI-Computeserver einzuloggen. Die ständige Eingabe des Passwortes entfällt somit. Dies können Sie auf die gewohnte Art und Weise entweder mit rlogin, telnet oder slogin (sehr viel sicherer) tun. @BODY VORN = Folgende Betriebsparameter wurden im NQS installiert: @BODY VORN = @BODY TABS = Laufzeitklassen: M(edium) max. 180 Min. @BODY TABS = L(ong) >> 180 Min. @BODY TABS = Speicherklassen: max.   256 MB @BODY TABS = max.   512 MB @BODY TABS = max. 1024 MB @BODY TABS = max. 2048 MB @BODY TABS = @BODY VORN = Auf dieser Grundlage wurden folgende Queues eingerichtet: @BODY VORN = M256: max. 256 MB Hauptspeicher, max. 180 Minuten CPU-Zeit @BODY VORN = M512: max. 512 MB Hauptspeicher, max. 180 Minuten CPU-Zeit @BODY VORN = M1024: max. 1024 MB Hauptspeicher, max. 180 Minuten CPU-Zeit @BODY VORN = L256: max. 256 MB Hauptspeicher, unbegrenzte CPU-Zeit @AUSRUECKEN = L512: max. 512 MB Hauptspeicher, unbegrenzte CPU-Zeit @BODY VORN = L1024: max. 1024 MB Hauptspeicher, unbegrenzte CPU-Zeit @AUSRUECKEN = L2048: max. 2048 MB Hauptspeicher, unbegrenzte CPU-Zeit Den Namen der Queue müssen Sie beim Aufruf des paketspezifischen Submittierungsprogramm angeben. @BODY VORN = ANSYS @BODY TABS = ans53job<%-2> [-p PATH] [-c FILE18] [-j xxxx]<%0>   [-q Queue] -p <%-3>Name des Pfads, in dem das Input<%-2>-<%-3>File <%-2>steht (optional)<%0> -c Name des Input-File (notwendig) -j <%-2>Option, um filenn.dat in xxxxnn.dat zu<%0>ändern (max. 4 Zeichen) -q Name der Queue:M256 M512 M1024 L256 L512L1024 L2048 @BODY VORN = NASTRAN @BODY VORN = nasjob -j Jobname (notwendig) -p Arbeitsverzeichnis -q Job-Queue @BODY VORN = ABAQUS @BODY VORN = abq56job -j Jobname (notwendig) -i Inputfile (ohne .inp) -p Arbeitsverzeichnis -o <%-3>Old-Job-Name (bei *RESTART,*POST OUTPUT und *POST FILE) -f new oder append -m analysis, datacheck, continue oder recover<%0> -c restart, select oder all -l <%-4>environment, local, memory oder release<%0> -u User-Subroutine -q Job-Queue (notwendig) @BODY VORN = MAFIA @BODY VORN = mafia4job -m <%-3>MODUL -c COM-File [-p PATH]-j NAME] -q [Job-Queue] -m Name des MAFIA-Moduls, das ausgeführt werden soll. <%-2>Erlaubt sind m400, s400, e400, t2400,t3400, w3400, ts2400, ts3400, p400 und oo400 bzw. die doppeltgenauen Module<%-2> <ODUL>> -c Name des COM-Files, in dem die MAFIA-Anweisungen stehen -p Name des Pfades, in dem das COM-File steht -j Name der Ausgabedatei (optional) Default: MAFIA_JOB.xnn -q Job-Klasse Sollten Sie Fragen oder Anregungen haben, setzen Sie sich bitte mit Rolf Mayer, RZ, Tel. -6435 oder Dr. Paul Weber, RZ, Tel. -4035 in Verbindung. @UEBER = PERMAS V. 6.1: Neues, voll parallelisiertes FE-Programm auf dem ParallelrechnerIBM RS/6000 SP @AUTOR FUNKTIN = Dr. Paul Weber <%-2>PERMAS ist ein FE-Programm, das von der Firma INTES GmbH in Stuttgart entwickelt und vertrieben wird (siehe dazu das Kurzportrait S. 15). PERMAS läuft auf allen gängigen Computersystemen, insbesondere in Karlsruhe ist die parallelisierte Version für die IBM RS/6000 SP interessant.<%0> Dank einer Kooperation zwischen INTES und dem Rechenzentrum, steht PERMAS allen Angehörigen der Universität Karlsruhe zur Nutzung zur Verfügung. Eine Informationsveranstaltung zu PERMAS findet statt am: @BODY TABS = Datum: Donnerstag, 2.4.1998 @BODY TABS = Zeit: 14.00 Uhr @BODY TABS = Ort: RZ, Raum 217, 2. OG @UEBER LINIEN = PERMAS auf der IBM RS/6000 SP PERMAS läuft auf allen Knoten der SP. Eine genaue <%-2>Beschreibung der PERMAS-Umgebung und eine Kurz-einfü<%0>hrung findet man demnächst auf der WWW-<%-2>Seite http://www.uni-karlsruhe.de/~PERMAS/. <%-3>An dieser Stelle soll nur gezeigt werden, wie PERMAS standardmäßig aufg<%0>erufen wird, wie der Prä-/Postprozessor PATRAN miteinbezogen wird, und wo man Beispiele und Dokumentationen findet. Basis für einen PERMAS-Lauf ist die Eingabedatei <>.dat und eine Kommandodatei <>.uci. Die Eingabedatei enthält die Modell- und Problembeschreibung und wird entweder editiert oder von einem Prä-/Postprozessor erzeugt. Bei komplizierten Strukturen bietet sich bei der Karlsruher Installation an, PATRAN als Prä- und Postprozessor zu verwenden. <%-2>Vorausgesetzt, die Dateien <>.dat und <>.uci existieren schon, ruft man PERMAS an einem der Login-Knoten oder interaktiven Knoten de<%0>r SP folgendermaßen auf: @BODY TABS = permas <> -memory < cherbedarf in MB>> @BODY TABS = -time <> @BODY TABS = -submit <> Der Job wird dann vom LoadLeveler weitervermittelt und auf einem Knoten seriell gerechnet. Will man parallel rechnen, sieht der Aufruf so aus: @BODY TABS = permas <> -mod<%0> parallel @BODY TABS = -memory < bedarf in MB>> @BODY TABS = -time <> @BODY TABS = -submit <> @BODY TABS = -nodes <> @BODY TABS = Die PERMAS-Umgebung ist standardmäßig so eingestellt, daß die temporären Dateien in das lokale Scratchfilesystem $TEMP_LOCAL gelegt werden. Nach erfolgreichem PERMAS-Lauf gibt es einige Dateien, in denen Informationen über den PERMAS-Lauf (<>.pro, <>.log) und die Ergebnisse (<>.res ) stehen. Rechnet man parallel, gibt es für jeden beteiligten Prozessor solche Dateien. Bei komplizierten Geometrien ist es mühsam, die Eingabedatei selbst zu erstellen. Man benutzt dazu Präprozessoren, mit denen man interaktiv das FE-Modell erzeugt. Am Rechenzentrum steht - in Verbindung mit PERMAS - dazu PATRAN3 auf den interaktiven Knoten zur Verfügung. Ein PERMAS-Modell wird in PATRAN3 unter der PERMAS-Präferenz erstellt: @BODY BLICK 1 = PATRAN-Aufruf p3 @BODY BLICK 1 = über File —>> New gibt man einen Database-Namen ein @BODY BLICK 1 = es erscheint ein Fenster mit einer Schaltfläche  Change Template, die angeklickt wird; in der sich öffnenden Datei-Auswahlbox wählt man permas_template.db <%-3> Anschließend kann man wie üblich das FE-Modell generieren, wobei einige Namenskonventionen berücksichtigt werden müssen (s. PATRAN-Door User’s Manual). Am Ende muß aus dem Database-File <>.db ein PERMAS-Eingabefile erzeugt werden. Dies geschieht an einem der interaktiven Knoten, wo man<%0> @BODY TABS = permas <> -vers patran3 @BODY VORN = aufruft. Zuvor muß ein UCI-File <>.uci erzeugt werden, das in etwa wie folgt aussieht: DFAULT SET MODL=OFF DEFAULT SET POSTPROC=PATRAN NEW INPUT  READ PATRAN FILE=pmodel.db EXPORT  MODEL DESCRIPTION STOP Es wird eine Datei <>.dato erzeugt, die als <>.dat anschließend als PERMAS-Eingabedatei verwendet wird. Der PERMAS-Lauf erzeugt, wenn im UCI-File die Zeile DEFAULT SET POSTPROC=PATRAN @BODY VORN = steht, <%-3>je nach Ergebnisanforderung, einige Ergebnisdateien, die im PATRAN Postprocessing über das<%0> Analysis-Menü eingelesen werden können. Beachten Sie, daß PATRAN derzeit auf der SP nur im lokalen Filesystem $TEMP_LOCAL ausgeführt werden kann. @UEBER LINIEN = Handbücher und Beispiele <%-2>Die PERMAS-Handbücher und Release Notes liegen im<%-3> Verzeichnis /usr/common/rzserv/permas/do<%-2>c als komprimierte PostScript-Files vor. Dies sind @BODY BLICK 1 = PERMAS User’s Reference Manual I, II @BODY BLICK 1 = PERMAS Examples Manual @BODY BLICK 1 = PATRAN Door User’s Manual @BODY BLICK 1 = PERMAS Release Notes @BODY BLICK 1 = <%-3>PERMAS on Unix; Installation und Operations Manual<%0> Das Examples Manual enthält auch eine kompakte Kurzeinführung in die Nutzung von PERMAS. Die dort beschriebenen Beispiele liegen auch online als Tar-File in /usr/common/rzserv/permas/exa vor. Man kann sich hieraus gezielt die Beispieldateien herausziehen. Durch Eingabe von @BODY TABS = get_example @BODY VORN = wird am Bildschirm ein Inhaltsverzeichnis ausgegeben, durch das man sich weiter durcharbeiten kann, bis man zum gewünschten Beispiel kommt. Man kann aber auch direkt @BODY TABS = get_example <> @BODY VORN = eingeben. @BODY VORN = Dr. Paul Weber, Tel. -4035, Email: Paul.Weber@rz. uni-karlsruhe.de @UEBER LINIEN = PERMAS-Kurzportrait @AUTOR FUNKTIN = INTES GmbH, Stuttgart @AUTOR FUNKTIN = PERMAS ist ein allgemeines Finite-Elemente-Softwaresystem für Berechnungen in Mechanik, Wärmeleitung, Elektrodynamik, Akustik und Optimierung und wird seit mehr als einem Jahrzehnt in vielen Branchen erfolgreich eingesetzt. PERMAS kann einfache und gekoppelte Analysen für verschiedenste Problemstellungen durchführen: @BODY BLICK 1 = StatikLineares und nichtlineares Verhalten, Kontaktanalyse, Beulen @BODY BLICK 1 = Dynamik - Eigenformen und -frequenzen - Antwortverhalten im Zeit- und Frequenzbereich - modale und direkte Methoden - Fluid/Struktur-Akustik @BODY BLICK 1 = ThermodynamikStationäre und instationäre Temperaturfelder @BODY BLICK 1 = Elektromagnetismus Magnetostatik, Elektrodynamik @BODY BLICK 1 = Entwurfsoptimierung Form- und Blechdickenoptimierung @BODY BLICK 1 = Zuverlässigkeitsanalyse<%-4> <%0>Parameterstudien und Ausfallsicherheit @BODY BLICK 1 = LaminatanalyseBeschreibung und Analyse des Verbundaufbaus <%-2>PERMAS bietet die Möglichkeit, alle Arten von Modellen mit vertretbarem Aufwand an Manpower und <%0>Hardware zu berechnen: @BODY BLICK 1 = GeschwindigkeitAktuelle Algorithmen und eine moderne Software-Architektur sorgen für kurze Rechenzeiten. @BODY BLICK 1 = EffizienzAuch die größten Modelle verarbeitet PERMAS mit wenig Zentralspeicher und Plattenplatz. Der Bedarf wird vor der Rechnung abgeschätzt. @BODY BLICK 1 = ProduktivitätModellvarianten werden mit wenig Aufwandgleich miterledigt - komplexe Modelle können in hierarchische Teilstrukturen zerlegt werden. @BODY BLICK 1 = ZuverlässigkeitDas Modell wird vorab durchgecheckt, die Rechnung selbst auf Durchführbarkeit überprüft, viele tausend Systemmeldungen im Klartext  melden Unstimmigkeiten und weisen auf Fehler hin. @BODY BLICK 1 = BenutzerfreundlichkeitPERMAS unterstützt den Anwender mit zahlreichen Funktionen, die auch komplexe Berechnungen praktikabel machen. Kompetente Beratung steht über die Hotline jederzeit zur Verfügung. @BODY BLICK 1 = IntegrationPERMAS ist in diverse Prä-/Postprozessor- und CAD-Programme integriert. Zu weiteren Systemen besitzt PERMAS leistungsstarke Schnittstellen. <%-3>Die Vollintegration von PERMAS in das CAD-System CATIA erlaubt umfassende FE-Analysen im CATIA-"Look-and-Feel": Die CAD/CAE-Prozeßkette ist auf höchstem Niveau definiert, Konstruktion <%0>und Berechnung sind deutlich zusammengerückt. <%-3>Bei der Integration des Prä-/Postprozessors MEDINA und PERMAS wu<%0>rde ein FE-Komplettpaket geschaffen, das höchste Funktionalität und Rechenleistung mit einem überaus schnellen Datenaustausch verbindet: <%-3>Der Nutzen liegt im hohen Durchsatz an gerechneten Projekten. Darüberhinaus stehen Integrationen zu I-DEAS und PATRAN zur Verfügung.<%0> @BODY VORN = Die in PERMAS integrierten Analysemodule sind: @BODY BLICK 1 = PERMAS-MQA das Grundmodul mit allen erforderlichen Funktionen zur Bedienung, Verwaltung und Qualitätssicherung des Berechnungsprozesses @BODY BLICK 1 = PERMAS-LS für alle statischen Steifigkeits- und Festigkeitsuntersuchungen bei linearelastischem Materialverhalten @BODY BLICK 1 = PERMAS-NLS  für Analysen unter Berücksichtigung geometrisch nichtlinearer Effekte und nichtlinearer <%-2>Materialeffekte wie Plastizität oder Kriechen<%0> @BODY BLICK 1 = PERMAS-CA für Kontaktprobleme mit und ohne Reibung @BODY BLICK 1 = PERMAS-DEV zur Berechnung von dynamischen Eigenwerten und Eigenformen @BODY BLICK 1 = PERMAS-DRA zur Ermittlung des dynamischen Antwortverhaltens im Zeit- oder Frequenzbereich @BODY BLICK 1 = PERMAS-FS zur Untersuchung gekoppelter Fluid-Struktur-Akustik @BODY BLICK 1 = PERMAS-HT zur Ermittlung des stationären oder transienten Wärmeleitungsverhaltens, sowohl linear als auch nichtlinear @BODY BLICK 1 = PERMAS-BA zur Berechnung von Beullasten und Beulformen @BODY BLICK 1 = PERMAS-OPT zur automatischen Optimierung von Tragwerksentwürfen unter Einhaltung von vorgebbaren Zielen und Restriktionen @BODY BLICK 1 = PERMAS-EMS für Berechnungen in der Elektro- und Magnetostatik @BODY BLICK 1 = PERMAS-EMD allgemeine Elektrodynamik, z.B. Wellenausbreitung, Wirbelströme etc. @BODY BLICK 1 = PERMAS-RA zur Untersuchung bei unsicheren, statistisch verteilten Eingangsgrößen wie Lasten oder Werkstoffkennwerten @BODY BLICK 1 = PERMAS-LA für die Analyse von Bauteilen aus Mehrschichtverbundwerkstoffen PERMAS steht auf allen gängigen Workstations zur Verfügung. Als PC-Version besitzt PERMAS auch einen eigenen Prä-/Postprozessor, der für die Belange von Konstrukteuren und Gelegenheitsanwendern ausgelegt ist. Das Komplettpaket heißt FELIX und zeigt eine hohe Intuitivität, Funktionalität und Grafikleistung. INTES wurde 1984 als FE-Technologie-Unternehmen gegründet. <%-2>Kompetenz in allen Aspekten der Finite Elemente-Technologie bietet INTES seinen Kunden nicht nur über das High-End Softwaresystem PERMAS a<%0>n. Auch in Dienstleistungen und einer bis ins Detail fundierten Beratung steht dem Kunden das gesamte Entwickler-Know how von INTES zur Verfügung. @BODY VORN = Arbeitsschwerpunkte bei INTES sind: @BODY BLICK 1 = Entwicklung und Vertrieb von PERMAS @BODY BLICK 1 = Entwicklung neuer und effizienter numerischer Verfahren @BODY BLICK 1 = Entwicklung von Softwarelösungen für neue Hardwarearchitekturen (wie Parallelrechner) @BODY BLICK 1 = Kopplungen zwischen PERMAS und anderen Software-Systemen (wie CAD-Systeme und Prä-/Postprozessoren), @BODY BLICK 1 = Anwendungsberatung und Schulung @BODY VORN = INTES will seinen Kunden ein kompetenter Partner in allen Belangen der Finite-Elemente-Methode sein. Die Zufriedenheit der Kunden mit Software und Service ist daher oberstes Firmenziel. @BODY VORN = <%-4>INTES Ingenieurgesellschaft für technische Software mbH<%0> @BODY VORN = Schulze-Delitzsch-Straße 16 @BODY VORN = D-70565 Stuttgart @BODY VORN = Telefon: +49-711-78499-0 @BODY VORN = Fax: +49-711-78499-10 @BODY VORN = Email: info@intes.de @BODY VORN = http://www.intes.de. @UEBER = Parallele Programme: Analyse und Debugging @UEBER LINIEN = Laufzeitanalyse paralleler Programme mit dem Analysetool Vampir @AUTOR FUNKTIN = Nikolaus Geers Vampir (Visualization and Analysis Tool for MPI Resources) ist ein Tool zur Analyse des Laufzeitverhaltens paralleler Programme, das am Zentrum für angewandte Mathematik (ZAM) des Forschungszentrums Jülich entwickelt und von der Firma Pallas GmbH als kommerzielles Produkt vermarktet wird. Vampir stellt ein einfach zu handhabendes, jedoch sehr mächtiges Werkzeug dar, das dem Anwendungsprogrammierer viele wertvolle Hinweise für die Optimierung paralleler Programme liefert. Es besteht aus zwei Komponenten: @BODY BLICK 1 = VampirTrace, einer Library, die während der Laufzeit des Programms Daten über die Nutzung der MPI-Funktionen sammelt, und @BODY BLICK 1 = V<%-2>ampir, einem Visualisierungstool, das nach der Programmausführung eine detaillierte Analyse des Laufzeit- und Kommunikationsverhaltens ermöglicht.<%0> Am Rechenzentrum der Universität Karlsruhe ist VampirTrace auf der IBM RS/6000 SP installiert, während das Visualisierungstool Vampir auf allen IBM RS/6000 Workstations, den HP Workstations unter HP-UX 10.20 sowie auf allen SGI Workstations genutzt werden kann. Weitere Informationen zu Vampir findet man im WWW unter http://www.uni-karlsruhe.de/ ~Vampir/<%-3>. Außerdem wird Vampir in einer Informationsveranstaltung am 9. März 1998 (siehe Seite 22) vorgestellt werden. Nikolaus Geers, Tel. -3755, Email: geers@rz.uni-karlsruhe.de. @UEBER LINIEN = Paralleler Debugger TotalView auf IBM RS/6000 SP und SNI VPP 300 @AUTOR FUNKTIN = Nikolaus Geers Auf den beiden Parallelrechnern IBM RS/6000 SP und SNI VPP 300 kann für das Debugging serieller und paralleler<%-2> Programme ab sofort der Debugger TotalView eingesetzt wer<%0>den. TotalView ist ein herstellerunabhängiger Debugger, der auf vielen Parallelrechnern eingesetzt wird und sich durch eine einfach zu bedienende graphische Oberfläche auszeichnet. Mit TotalView können sowohl C und C++ als auch FORTRAN (FORTAN 77 und FORTRAN 90) Programme bearbeitet werden. TotalView kann als paralleler Debugger für Programme eingesetzt werden, die mittels MPI parallelisiert wurden. Für PVM-Applikationen besteht die Möglichkeit, jede einzelne Task unter Kontrolle von TotalView auszuführen. <%-3>Ausführliche Informationen zu TotalView können im WWW unter der URL http://www.uni-karlsruhe. de<%0>/~TotalView/ a<%-2>bgerufen werden. Außerdem wird TotalView in einer Informationsveranstaltung am 9. März 1998 (siehe Seite 22) vorgestellt.<%0> @BODY VORN = Nikolaus Geers, Tel. -3755, Email: geers@rz.uni-karlsruhe.de. @UEBER = Katalogisierung im WWW:Neues Angebot der Universitätsbibliothek    @AUTOR FUNKTIN = Dr. Michael MönnichUniversitätsbibliothek KARIN (KARlsruher INformationssystem) ist ein EDV-System für die Katalogisierung in wissenschaftlichen Bibliotheken. KARIN wurde an der Universitätsbibliothek als OS/2-System entwickelt und wird seit 1991 in Bibliotheken der Universität Karlsruhe eingesetzt. Die mit KARIN erfaßten Daten fließen in den Online-Institutskatalog ein und können über das OLIX-System der Universitätsbibliothek recherchiert werden (http://www.ubka.uni-karlsruhe.de/hylib/ olinka_suchmaske.html). Der Katalog enthält 226.226 Titel mit 264.271 Bestandsdaten von 57 Fakultäts-, Instituts- und Lehrstuhlbibliotheken (Stand Januar 1998). Da OS/2 als Betriebssystem kontinuierlich an Bedeutung verliert, wurde die Funktionalität des PC-basierten Clientsystems KARIN auf eine WWW-Plattform portiert und steht seit Herbst 1997 als WWW-KARIN zur Verfügung. KARIN bietet für den Anwender folgende Vorteile: @BODY BLICK 1 = plattformunabhängiges WWW-basiertes System @BODY BLICK 1 = Benutzung über jeden handelsüblichen WWW-Browser wie z. B. Netscape Navigator @BODY BLICK 1 = maskengeführte Katalogisierungsoberfläche @BODY BLICK 1 = einfache Bedienung @BODY BLICK 1 = Fremddatenübernahme aus dem Katalogdatenpool aller OLIX-Bibliotheken @BODY BLICK 1 = Katalogisierung nach RAK-WB mit Verwaltung von Serien und mehrbändigen Werken @BODY BLICK 1 = Schnelle und komfortable Suchmöglichkeiten nach allen wesentlichen Teilen der bibliographischen Beschreibung und lokalen Daten @BODY BLICK 1 = MAB-Unterstützung @BODY VORN = @BODY VORN = Beispielseiten findet man im WWW unter http:// <%-2>www.ubka.uni-karlsruhe.de/wwwkarin.html.<%0> @BODY VORN = Fremddatenübernahme In den OLIX-OPACS der wissenschaftlichen Bibliotheken sind über 4 Millionen Katalogaufnahmen enthalten. Diese Daten können mit KARIN beim Katalogisieren kopiert werden. Erfahrungsgemäß können ca. 70 Prozent der Titelaufnahmen übernommen werden, aufwendige Schreibarbeiten entfallen und Tippfehler werden vermieden. Folgende Kataloge sind z.Zt. verfügbar: @BODY BLICK 1 = UB Karlsruhe @BODY BLICK 1 = UB Kaiserslautern @BODY BLICK 1 = UB Mannheim @BODY BLICK 1 = UB Freiburg @BODY BLICK 1 = UB Tübingen @BODY BLICK 1 = UB Stuttgart @BODY BLICK 1 = Badische Landesbibliothek @BODY BLICK 1 = Württembergische Landesbibliothek @BODY TABS = Datenhaltung Mit KARIN werden Buchdaten direkt online im Institutskatalog der Bibliotheksbestände der Universität Karlsruhe erfaßt. Die Datenhaltung erfolgt zentral auf dem UNIX-Server der Universitätsbibliothek. Rechnerkapazität für eine Datenbank ist in den einzelnen Bibliotheken somit nicht notwendig. @BODY VORN = Betreuung durch die UB Der Einsatz von KARIN in den einzelnen Bibliotheken wird von der Universitätsbibliothek intensiv betreut. Hierzu zählt nicht nur eine ausführliche Einweisung in die Bedienung des Systems, sondern auch die Einweisung in die Katalogisierungsregeln und gegebenenfalls die Erledigung von komplizierten Katalogaufnahmen durch die Mitarbeiter der Universitätsbibliothek. Die Nutzung von WWW-KARIN wie auch die Betreuung durch die UB ist für Einrichtungen der Universität kostenlos. @BODY VORN = Technische Voraussetzungen für KARIN Die wichtigste Voraussetzung für den Einsatz von KARIN ist ein Anschluß an das Rechnernetz der Universität bzw. ein Internetzugang. Jeder beliebige Rechner mit einem grafischen WWW-Browser wie Netscape Navigator ist geeignet. @BODY VORN = Ansprechpartner Falls Sie weitere Informationen wünschen, wenden Sie sich bitte an Dr. Michael Mönnich, Tel. -2298, oder an Frau Eckl, Tel. -3128, Email: eckl@ubka. uni- karlsruhe.de. @UEBER = Veranstaltungen @UEBER LINIEN = IBM RS/6000 SP-Einführungskurs @AUTOR FUNKTIN = Nikolaus Geers Das Rechenzentrum der Universität Karlsruhe veranstaltet in der Woche vom 30. März bis zum 3. April 1998 einen Einführungskurs für zukünftige Nutzer des Parallelrechners IBM RS/6000 SP. Dieser Kurs wendet sich sowohl an Anwendungsprogrammierer und andere Nutzer der IBM RS/6000 SP, die bisher keine Erfahrungen im Einsatz von Parallelrechnern haben, als auch an Anwender, die bereits auf anderen Parallelrechnern gearbeitet haben, sich jedoch mit der Nutzung der IBM RS/6000 SP am Rechenzentrum der Universität Karlsruhe vertraut machen möchten. Vorausgesetzt werden grundlegende Kenntnisse in UNIX sowie in einer der Programmiersprachen FORTRAN oder C. Der Kurs umfaßt neben einer Übersicht der wichtigsten Parallelrechnerkonzepte eine Diskussion der Hard- und Software der IBM RS/6000 SP, eine Vorstellung der lokalen Betriebsumgebung und eine ausführliche Beschreibung der verschiedenen Parallelisierungsmethoden auf der SP. Dies wird ergänzt durch die Vorstellung verschiedenster Tools, die bei der Programmentwicklung und -optimierung eingesetzt werden können. Außerdem werden Optimierungsstrate-gien behandelt, die zu einer deutlich effizienteren Nutzung des Parallelrechners beitragen können. Während die einzelnen Themen vormittags in Form von Vorträgen vorgestellt werden, besteht nachmittags die Gelegenheit, Übungen auf der IBM RS/6000 SP durchzuführen. Im Rahmen dieser Übungen können sowohl vorbereitete Übungsaufgaben bearbeitet als auch eigene Programme auf der SP installiert werden. @BODY TABS = Datum: 30.3. - 3.4.1998 @BODY TABS = Zeit: 9.00-12.00 Uhr @BODY TABS = Ort: RZ, Raum 217, 2.OG @BODY TABS = @BODY TABS = Übungen: @BODY TABS = Zeit: 14.00 - 17.00 Uhr @BODY TABS = Ort: RZ, Raum -101, UG @BODY TABS = Anmeldung: per Email an geers@rz. uni-karlsruhe.de Weitere Informationen zur IBM RS/6000 SP und zu diesem Kurs finden Sie im WWW unter der URL: http://www.uni-karlsruhe.de/~SP/. @UEBER LINIEN = Supercomputing: Ausbildung am Vektorrechner und Parallelrechner @AUTOR FUNKTIN = Prof. Dr. Willi Schönauer @BODY VORN = Blockvorlesung 1112+1113 (2+2 SWS) @BODY TABS = Datum: 2.3.-7.3.98 (dritte Ferienwoche) @BODY TABS = Zeit: Mo.-Fr. 8.30-10.00, 10.30-12.00 Uhr Mo.-Do. 14.30-16.00 Uhr @BODY TABS = Ort: RZ, Raum 217, 2.OG @BODY TABS = @AUTOR FUNKTIN = Prof. Dr. Willi Schönauer/Hartmut Häfner @BODY TABS = Übungen @BODY TABS = Zeit: Mo. 16.30-18.00 und weitere Termine (auch Sa. vormittag) @BODY TABS = Ort: RZ, Seminarraum 217 und Terminalraum @BODY TABS = @BODY VORN = Inhalt @BODY VORN = Die Vorlesung behandelt die Grundlagen für die effiziente Nutzung von Vektorrechnern und Parallelrechnern (Supercomputern). Es werden die Prototypen des Vektorrechners, des Superskalarprozessors und der daraus aufgebauten Shared Memory und Distributed Memory Parallelrechner vorgestellt. Dann werden für die wichtigsten Aufgaben der numerischen Mathematik die Datenstrukturen und Algorithmen für eine effiziente Nutzung dieser Rechnerarchitekturen behandelt. Es ist beabsichtigt, zwei Vektorrechner sowie zwei Parallelrechner im Detail zu diskutieren und in den Übungen zu nutzen (Übungsschein). @BODY VORN = @BODY VORN = Voraussetzung @BODY VORN = UNIX-System, FORTRAN-Kenntnis. Im SS schließt sich ein Vertiefungspraktikum für Shared und Distributed Memory Supercomputer an. Eine Voranmeldung ist nicht erforderlich. @BODY VORN = Nächster Termin: 5.10.-10.10.98 @UEBER LINIEN = Programmieren II: UNIX-Welt, Programmiersprachen, effiziente Rechnernutzung @AUTOR FUNKTIN = Prof. Dr. Willi Schönauer @BODY VORN = Blockvorlesung 1020+1021 (2+2 SWS) @BODY TABS = Datum: 16.2.-21.2.98 (erste Ferienwoche) @BODY TABS = Zeit: Mo.-Fr. 8.30-10.00, 10.30-12.00 Uhr Mo.-Do. 14.30-16.00 Uhr @BODY TABS = Ort: <%-2>Otto-Lehmann Hörsaal, Physik-Flachbau<%0> @BODY TABS = @AUTOR FUNKTIN = Prof. Dr. Willi Schönauer/Hartmut Häfner @BODY VORN = Übungen am UNIX-System @BODY TABS = Zeit: Di. ab 16.30 Uhr und weitere Termine @BODY TABS = Ort: Terminalraum des Rechenzentrums @BODY VORN = Inhalt @BODY VORN = Bereitstellung des “Handwerkszeugs” zur effizienten Benutzung des UNIX-Systems zur Bearbeitung von Ingenieurproblemen. Es werden skizzenhaft behandelt: Hardware, Betriebssystem, Assembler, Steuersprache, Programmiersprachen, Programmiermethodik, effizientes numerisches Rechnen. Ein handschriftliches Skriptum ist bei Kellner + Moessner erhältlich. @BODY VORN = @BODY VORN = Voraussetzung @BODY VORN = <%-2>Grundkurs Programmieren oder eigene Programmiererfahrung. Die Beherrschung des UNIX-Systems ist selbst wieder Voraussetzung für die Ausbildung am Supercomputer. Eine Voranmeldung ist nicht erforderlich<%0>. @BODY VORN = Nächster Termin: 21.9.-26.9.98. @UEBER LINIEN = Statistik: Einführungskurs SAS @AUTOR FUNKTIN = Dr. Klaus Braune Der nächste SAS-Einführungskurs (Statistical Analysis System) findet vom 23.3. bis 27.3.1998 statt.  Ziel des Kurses ist das Kennenlernen und Anwenden von SAS. Vorkenntnisse sind für die Kursteilnahme nicht erforderlich. Die erworbenen Kenntnisse können an Workstations oder PCs eingesetzt werden. Die statistischen Grundlagen sind nicht Lehrstoff des Kurses! @BODY TABS = Kursbeginn: Montag, 23.3.1998, 9.00 Uhr @BODY TABS = Ort: RZ, Raum 217, 2. OG bzw. Übungen im Raum -112, UG @BODY TABS = Kursende: Freitag, 27.3.1998, 17.00 Uhr @BODY TABS = @BODY VORN = Programm: @BODY VORN = Montag, 23.3.1998 @BODY VORN =  9.00 -  9.45 Begrüßung der Teilnehmer, Vorstellung des Programms, Überblick über Statistikprogramme am Rechenzentrum @BODY VORN = 10.00 - 12.00 Das SAS-System, SAS/DMS (Bildschirmoberfläche für SAS mit eigenem Editor), Literatur @BODY VORN = 14.00 - 15.00 Aufbau von SAS-Programmen, Variablen, Daten, Dateien @BODY VORN = 15.00 - 17.00  Betreute Übung @BODY VORN = @BODY VORN = Dienstag, 24.3.1998 @BODY VORN =  9.00  - 10.30 Eingabe von Daten in SAS @BODY VORN = 10.30  - 12.00 Betreute Übung @BODY VORN = 14.00 - 15.00 Ausgabe und einfache Auswertungen von Daten @BODY VORN = 15.00 - 17.00 Betreute Übung @BODY VORN = Mittwoch, 25.3.1998 @BODY VORN =   9.00 - 10.15 Interaktive Dateneingabe, Maskenerstellung (SAS/FSP) @BODY VORN = 10.15 - 12.00 Betreute Übung @BODY VORN = <%-2>14.00 - 15.30 G<%0>raphische Darstellung von Daten (SAS/GRAPH) I @BODY VORN = 15.30 - 17.00 Betreute Übung @BODY VORN = Donnerstag, 26.3.1998 @BODY VORN =  9.00 - 10.30 Graphische Darstellung von Daten (SAS/GRAPH) II @BODY VORN = 10.30  - 12.00 Betreute Übung @BODY VORN = 14.00  - 15.00 Statistische Prozeduren - Überblick und Beispiel (SAS/STAT) @BODY VORN = 15.00  - 17.00 Betreute Übung @BODY VORN = Freitag, 27.3.1998 @BODY VORN =  9.00 - 10.15  Überblick über die Möglichkeiten von: - SAS/ETS (Zeitreihenanalyse) - SAS/OR (Operations Research) - SAS/IML (Interactive Matrix Language) - <%-2>SAS/AF (Programmierung von Menüoberflächen) - SAS an anderen Geräten, automatischer Ablauf @BODY VORN = 10.15 - 12.00 Betreute Übung @BODY VORN = 14.00 - 15.00 Zusammenfassung der Kursinhalte, Fragen, Abschlußdiskussion @BODY VORN = ab 15.00 Betreute Übung Der Kurs findet im Raum 217, die Übungen im Raum -112 des Rechenzentrums statt (unter AIX). Die Teilnehmerzahl ist auf 25 begrenzt. Zur Anmeldung liegen vorbereitete Listen in der Betriebsauskunft aus (Herr Weih, Tel. -3751). Weitere Informationen zu SAS und zum SAS-Kurs finden Sie im WWW unter http://www.rz.uni-karlsruhe.de/~rz32/sas.html). @BODY VORN = Literatur: @BODY VORN = SAS Version 6 - Eine Einführung mit Beispielen.Skript zum Kurs. @BODY VORN = Flury, Riedwyl: Angewandte multivariate Statistik.Stuttgart / New York 1983. @UEBER LINIEN = Textverarbeitung:Einführungskurs LaTeX @AUTOR FUNKTIN = Dr. Klaus Braune LaTeX ist ein auf TeX aufbauendes Makropaket, mit dessen Hilfe sich auf relativ einfache Weise Dokumente mit mathematischen Formeln, Abbildungen und Querverweisen erstellen lassen. In der Zeit vom 9.3. bis 13.3.1998 findet ein Einführungskurs in LaTeX statt. Ziel des Kurses ist es, LaTeX kennenzulernen und die Erstellung von Texten mit Hilfe von LaTeX zu erlernen. Die Übungen zum Kurs finden unter UNIX statt. Für die Teilnahme am Kurs sind keine Vorkenntnisse erforderlich. Die im Kurs erworbenen Kenntnisse können bei der Textverarbeitung an PCs ebenso angewendet werden wie auf Workstations und Großrechnern. @BODY TABS = Kursbeginn: Montag, 9.3.1998, 9.00 Uhr @BODY TABS = Ort: RZ, Raum 217, 2. OG bzw. Übungen in Raum -111, UG @BODY TABS = Kursende: Freitag, 13.3.1998, 17.00 Uhr @BODY VORN = Behandelte Themen @BODY BLICK 1 = Allgemeine Informationen über TeX und LaTeX @BODY BLICK 1 = Genereller Aufbau und Gliederung eines Dokuments @BODY BLICK 1 = Die vordefinierten Dokumenttypen und Änderungen des Layouts @BODY BLICK 1 = Standardschriften und die Verwendung zusätzlicher Schriften @BODY BLICK 1 = Silbentrennung, Umlaute und scharfes S @BODY BLICK 1 = Listen, Tabellen, Zitate, Fußnoten @BODY BLICK 1 = Einfache Graphiken @BODY BLICK 1 = Inhaltsverzeichnis, Literaturverzeichnis und weitere Verzeichnisse @BODY BLICK 1 = Setzen mathematischer Formeln Die Teilnehmerzahl ist auf 50 begrenzt. Zur Anmeldung liegen vorbereitete Listen in der Betriebsauskunft aus (Herr Weih, Tel. -3751). Weitere Informationen zu TeX und zum LaTeX-Kurs finden Sie im WWW unter http://www. rz.uni-karlsruhe.de/~rz32/tex.html. @BODY VORN = Literatur: @BODY VORN = H. Kopka: LaTeX: Eine Einführung. Addison-Wesly, 1989. @BODY VORN = L. Lamport: LaTeX, A Document Preparation System, User’s Guide and Reference Manual. Addison-Wesly, 1985. @BODY VORN = H. Partl, E. Schlegl, I. Hyna: LaTeX-Kurzbeschreibung. Im Rahmen der verschiedenen TeX-Installationen des RZ als LaTeX-Datei verfügbar. @UEBER LINIEN = Softwaretools TotalView und Vampir:Schulungskurs @AUTOR FUNKTIN = Nikolaus Geers Im Rahmen einer gemeinsamen Veranstaltung mit dem Forschungszentrum Karlsruhe findet am 9. März 1998 ein Schulungskurs zu den Softwaretools TotalView und Vampir statt. Neben der Präsentation der Funktionen dieser Pakete wird insbesondere auf die Nutzung von TotalView und Vampir auf den Rechnern  IBM RS/6000 SP und SNI VPP 300 eingegangen. Nachmittags besteht die Möglichkeit, mit diesen Programmierhilfsmitteln auf der SP bzw. dem VPP zu arbeiten, wobei Hilfestellungen von Seiten des Rechenzentrums und der Firma Pallas GmbH, dem Distributor beider Pakete, gegeben werden. @BODY TABS = Datum: Montag, 9. März 1998 @BODY TABS = Zeit: 10.00 Uhr bis 12.30 Uhr und 14.00 Uhr bis 17.00 Uhr @BODY TABS = Ort: RZ, Raum 062 (vormittags), Raum -101 (nachmittags) @BODY TABS = <%-2>Anmeldung:<%0> per Email an geers@rz.uni-karlsruhe. de<%-2> @UEBER LINIEN = Finite Elemente: ABAQUS-Einführungskurs @AUTOR FUNKTIN = Dr. Paul Weber In der Zeit vom 17. - 20. März 1998 findet wieder ein Einführungskurs in ABAQUS statt.<%-2> Grundlage ist die Version 5.6. Es werden aber auch schon die Features der neuen Version 5.7 berücksichtigt.<%0> @BODY TABS = Datum: 17.-20. März 1998 @BODY TABS = Zeit: jeweils 9-13 Uhr und 14-16 Uhr @BODY TABS = Ort: RZ, Raum 217, 2. OG @BODY TABS = <%-2>Anmeldung: <%0>per Email an paul.weber@rz.uni- karlsruhe.de<%-2> Es werden keine speziellen Kenntnisse bei den Kursteilnehmern vorausgesetzt. @BODY VORN = Programm: @BODY VORN = 1. Tag: @BODY BLICK 1 = Aufbau und Struktur von ABAQUS @BODY BLICK 1 = Organisation der ABAQUS-Dokumentation @BODY BLICK 1 = Einführendes Beispiel @BODY BLICK 1 = Erzeugung der Knoten und der Vernetzung mit ABAQUS-Kommandos <%-2>Der erste Tag wendet sich an Interessenten, die bisher noch mit keinem FE-Programm vertraut sind. Benutzer, die sich schon etwas auskennen bzw. die ihre Modelle mit I-DEAS, PATRAN oder anders als mit ABAQUS-Kommandos erzeugen, können diesen Tag<%0> <%2>überspringen.<%0> @BODY VORN = 2. Tag: @BODY BLICK 1 = Elementebibliothek @BODY BLICK 1 = Materialeigenschaften @BODY BLICK 1 = ABAQUS am Rechenzentrum (Installation an der IBM RS/6000 SP, am FE-Server und anderen Workstations) @BODY VORN = 3. Tag: @BODY BLICK 1 = Lösungsalgorithmen @BODY BLICK 1 = <%-2>Belastungsgeschichte, Prozeduren, Randbedingungen<%0> @BODY BLICK 1 = Lasten @BODY BLICK 1 = Restarts @BODY BLICK 1 = ABAQUS-Ausgabe @BODY VORN = @BODY VORN = 4. Tag: @BODY BLICK 1 = ABAQUS/Post @BODY BLICK 1 = spezielle Problemlösungen: - Wärmeausbreitungsprobleme - gekoppelte Temperatur-/Spannungsprobleme - Eigenfrequenzen und -moden - dynamische Probleme @BODY VORN = Alle Teilnehmer bekommen die Kursunterlagen zur Verfügung gestellt. Dr. Paul Weber, Tel. -4035, Email: Paul.Weber@ rz.uni-karlsruhe.de. @UEBER = Neu im Internet:Scientific Supercomputing @AUTOR FUNKTIN = Prof. Dr. Willi Schönauer Ab sofort ist folgendes Buch auch im WWW verfügbar: @BODY VORN = Willi SchönauerScientific Supercomputing: Architecture and Use of Shared and Distributed Memory Parallel Computers Rechenzentrum Universität Karlsruhe, 1998 Bis jetzt sind 11 von 18 Kapiteln des oben genannten Buches im Internet zu lesen. Es sind die gescannten Seiten meiner handschriftlichen Vorlagen. @BODY VORN = Inhaltsverzeichnis: @BODY VORN =  1. @ Introduction @BODY VORN =  2. @ Prototypes with their Memory Bottlenecks @BODY VORN =  3. @Arithmetic Operations and Memory Bandwidth @BODY VORN =  4. @The Cray T90 @BODY VORN =  5. @The Fujitsu VPP300 (and VPP700) @BODY VORN =  6. @The IBM RS/6000 SP @BODY VORN =  7. @The Cray T3E and DEC Alpha Processors @BODY VORN =  8. @Performance Analysis @BODY VORN =  9. @Basic Considerations Concerning Data Structures @BODY VORN = 10. @Fortran, Autovectorization and Autoparallization, Programming Models @BODY VORN = 11. @Recurrences Die restlichen Kapitel folgen, wie es der zeitliche R<%-2>ahmen zuläßt. Das Buch entspricht in etwa dem Inhalt meiner Vorlesung “Supercomputing”. Das Buch kann i<%-3>m WWW unter http://www.rz.uni-karlsruhe.de/ UNI/<%-2>RZ/Personen/rz03/book abgerufen werden.<%0> @UEBER = Personalia Frau Barbara Rath ist als Vertretung von Frau Monika Riecke seit dem 20. November 1997 als Fremdsprachensekretärin angestellt. Ihr Aufgabengebiet umfaßt alle mit der Leitung des Rechenzentrums zusammenhängenden Sekretariatsaufgaben. Ihr Arbeitsplatz befindet sich im RZ, Raum 305, Tel. -3754, Email: rath@rz.uni-karlsruhe.de. Herr Dipl.-Ing. Ralf Wigand ist seit dem 1.2.1998 in der Abteilung Information und Beschaffungsservice  halbtags als wissenschaftlicher Mitarbeiter angestellt. Zu seinem Aufgabengebiet gehört die Leitung des Micro-BITs, die Betreuung und Weiterentwicklung der NICK-PCs sowie zum Teil die Administration des WWW-Servers der Universität. Sein Arbeitsplatz befindet sich im RZ, Raum 006.2, Tel. -4868, Email: wigand@rz.uni-karlsruhe.de. uˆ€‰žÛ'Ð æ /Øþ4 W 'Ë'‰/š/'>W>æBCœHºHK"K„V‰V‡X Xee£e~q›qt:t}užu{w§wíwüw퀡…È… ˆ2ˆUŽVš_›¬œ¸œP`™ž¾ž-¢£¥‰¥ˆ¦“¦4¨;¨™©ž©ÃªÓª™»©»û» ¼ã¼è¼?½D½›½¡½ù½þ½Q¾V¾¨¾®¾¿ ¿À¿Ç¿pÂyÂ¥Ãû÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷ûñû÷û÷û÷û÷û÷ûëû÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û  [¥Ã­Ã1È8È Î+ÏÐÐ:Ð?ÐZÐ^ÐIãcãèèªé°éê êÛêëê)ë;ënëë·ëÎëì$ìäìóìaímíîîªî¼îƒïœï`ðnðó§ó6ô@ô¹ôÃôeõnõ©õ³õö ökötöºöÃöA÷J÷‰÷“÷øøcømøÄøÍøJùSù¨Ë< A Óèp~´Ì¸ÞÑâæì  4 8 l v ƒ ˆ ¬ ° Ô û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷û÷`Ô Þ <"`"o"u"¦"«"ÿ"#r#{#ˆ##Þ#â#'$/$­&¼&ƒ'“'´'(<(`(o(u(§(¬())q)r))—)ž)®)»)À)ö)ú)-*5*¼+É+½,Í,¬.·.ã.ç.3/€µÙÛ')Ë­òÀ æ /ÉËþ§Ä% ' W ï!Ë"'Ë'<(>(ª(¬(d)f)**Z+ .y/š/s02!2w2Ç2p3 4 47Ë8Ú849m9Ù9 :<:ª:Ò:á:h<j<Û<€= >>W>@A×BÙBCqDþDäFŒHºHöJøJ"KOYP7R°UxXzXççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççç& Рp@ à°€P ðÀ!QzX X[[[[5[L[a[y[‘[ª[¹[q]s]Î]ð]^/^M^n^^±^À^ï^ñ^4_£_¥_ `k`m`Û`VaXa—aùaüaOb½bcVc¢cîc~dïdIeXe£eámn nwnønúnÀpnqqq§q`sbs{stttFtˆtŠt¢tunupuªu£v¥v½vnwpw{w³wÞwàwççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççç& Рp@ à°€P ðÀ!Qàwüw`y£}¥} ~~2~4~Œ~Ž~Ý€ÿ‚šƒœƒÀƒâƒ„)„¡„£„ß„…X…‘…È…¹†þ‡ˆ2ˆ›ˆüˆh‰ ‰ï‰ŠzŠ>‹‘‹Û‹ê‹’ŒžŒ®ŒÀŒÏŒàŒçŒ‚ÔŽSŽUŽÏ‘–•˜š"šDšFšƒš\›_›JœœŸœ¸œ?AC`ŠžŒž¾žîŸÀ g¡Ò¡¢ççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççç& Рp@ à°€P ðÀ!Q¢+¢-¢££ ¤’¤”¤Ð¤ø¤e¥t¥‰¥l¦{¦š¦¨'¨>¨}©Œ©¡©iªxª³ªÓª£«¬e¬­¬­j­y­:°<°k°m° ² ²8²:²á²ð²³ƒ³·³-´/´f´³µ>¶@¶s¶Ç¶Ö¶·ô·¸>¸Ï¸Ñ¸7»9»}»Œ»Â»ì»î»¼=¼^¼¼Ž¼Ö¼ë¼2½G½Ž½¤½ì½¾C¾ççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççç& Рp@ à°€P ðÀ!QC¾Y¾›¾±¾ô¾ ¿M¿O¿±¿³¿Ç¿6ÀKÀÓÀèÀMÁbÁßÁôÁaÂcÂy¢ÂéÂþÂDÃYÖØíÃÞÃ%Ä:ăĘÄÞÄóĽÅÒÅÆ*ÆƤÆïÆÇnǃÇÅÇÚÇ"È$È8ÈjÈßÈôÈËˈËËûË̘̭ÌêÌìÌÍêÍ Î Î1Ï3ÏÅÏÐÐ-ÐMÐvÐ¥ÐÑTÒøÓëÔççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççç& Рp@ à°€P ðÀ!QëÔíÔ^Õ­Õ÷ÕùÕ‰Ö‹ÖßÖEד×Ý×+Ø:ØäØ>ÚNÛ–ÛÕÛTÜ0Ý7Ý„Þ†ÞÔÞÖÞaßcß•ßÏßñßàPàuà§àÊàÌàá·á¹áóá±â9ãcãä!äWääªäÐäåå=æPæRæŒæŽæBçDçŠçŒç¤ç¦ç÷çèDèWè8é˜é˜éšéñé ê7êvê£êËêë^ë§ëìQìççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççç& Рp@ à°€P ðÀ!QQìÒìÔìQíôíšîsïPðûðýðíñNóPóó&ô©ôUõ™õðõ[öªö1÷y÷øSø´ø:ù•ù—ùÌú.ü0übü—üàüGý½ýîýýý¸þÿ1ÿQÿxÿœÿ¿ÿÿÿ4…¦¨ËÍ«6äæíÞ!s”G _ « û : < A C È Ñ l§Ë!€3ççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççç& Рp@ à°€P ðÀ!Q3BÄÆèMkŽ«Èå.ac~¥§Ì©«ÞÂÄâ‹¥Õöø‡×Ù ' P _ v Ÿ Ç !!°!"-"/"`"b"™"ò"#*#e#{#Ñ# $$/$‘& &¼&t'v'¤'(-(/(`(b(š(ó(8)G)ƒ)®)é)* *5* +¯+Ì+ççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççç& Рp@ à°€P ðÀ!QÌ+®,°,Þ,-1-3-^..Ÿ.Ö.&/]/l/„/¤/,0 0ô0#121T1Ž1½126282Z2°2Þ283f3f3h3Œ3Û3 4f4•4—4¸4ÿ4,5Z5‘5Ó56?6š6Ã6Å6¨7<8>8W8¨89B9e9g9:Ð;Ò;<V<Ž<<°<í</=|=É=>5>Y>­>Ü>Þ>e?ñ?ó? @ççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççç& Рp@ à°€P ðÀ!Q @Q@Ë@aA¦AÇAÉA D D9DDßD5EnEE‘E_F‰FÀFëFGGIG—G™G²G´GÊGüG4H\H«H­HÃIàIJ+J¡J£JºJÞJ*KCK]K}KŒK¢K¿KëKLQL}L£L²LøLúL?MvM¢M¤MÙMÛMŒNŽN"O$OFOYOwOŠOÄO×OP%PBPUP…P˜P»PÎPQQ=Qççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççççç& Рp@ à°€P ðÀ!Q=QQQ‘Q£QøQ R&R(RPSRSRSTSiSkSmSoSqSsS]T¼T¾TÀTÂTÄTÆTÈTÊTÌTÎTÐTÒT…V‡V‡V‰Vçççççççççççççççççççççççççççççççççâ& Рp@ à°€P ðÀ!"F  Þ U‰V€¥ÃÔ s4‰V¬­®¯€zXàw¢C¾ëÔQì3Ì+ @=Q‰V°±²³´µ¶·¸¹º. Tms Rmn RSymbol"Helv1þMS LineDraw U"neÐaw