Das Jahr 2000-Problem: der Countdown läuft

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.

Mit freundlicher Genehmigung von Tiki Küstenmacher

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?

Mit funkgesteuerter Uhr allein ist es nicht getan

Kein Grund zur Panik

Ursachen und Auswirkungen

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.

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.

Wie nähert man sich demJahr 2000-Problem?

1.	Man tut nichts und wartet, was mit den verschiedenen Rechnern und Anwendungen passiert.
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.
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.

Analysemethoden

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:

• Arbeiten die Programme mit Schutzfristen und einer Gültigkeitsdauer?
• Verwenden die Programme intern eine zweistellige Jahresangabe?
• Verwenden die Programme intern eine vierstellige Jahresangabe, aber für die Ein-und Ausgabe (z.  B. in Bildschirmmasken) eine zweistellige Darstellung?
• 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:

• Bei internen, lokalen oder globalen Variablen, Konstanten und Parametern
• in logischen Ausdrücken und Vergleichen
• in arithmetischen Ausdrücken (z. B. die Bestimmung der Arbeitstage zwischen zwei Terminen)
• in Ein- und Ausgabeanweisungen
• in Dateiattributen und Dateinamen
• in Datenbankfeldern (als Date-Format, und schlimmer noch, als Charakter-Format oder Integer)
• in Sortieranweisungen.

• Suche nach Feldern, Parametern, Konstanten und Variablen (Objekten) mit datumsrelevanten Namen
• Suche nach Feldern, Parametern, Konstanten und Variablen, die nach Größe und Datentyp mit gewisser Wahrscheinlichkeit Datumsdaten speichern können.
• Durchsicht der Dokumentation und der Bedienungsanleitungen sowie Befragung der Autoren, sofern diese noch greifbar sind.

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.

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).

Die Umstellung der Anwendung

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.

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:

1. Jahrhundert
2. Jahr
3. Monat
4. Tag
5. Stunde
6. Minute
7. Sekunde

Da diese interne Speicherung grundsätzlich verwendet wird, kann es natürlich bei der Speicherung keine Probleme mit der Jahrtausendwende geben. Es gibt allerdings genügend Möglichkeiten, die intern gespeicherten Informationen nicht zu benutzen, um damit seltsame Effekte zu produzieren. Ich denke dabei nicht nur an Programmierer, die CHARACTER-, INTEGER- oder REAL-Variablen für die Speicherung eines Datums verwenden.

Das Datum wird in einem festen Format mit einer Länge von 7 Byte wie folgt abgespeichert:

1. Byte Jahrhundert
2. Byte  -  Jahr
3. Byte  -  Monat
4. Byte  -  Tag
5. Byte  -  Stunde
6. Byte  -  Minute
7. Byte  -  Sekunde

Ein Beispiel zur Verdeutlichung:

drop table person;
create table person (name VARCHAR2(30), geburt DATE);

insert into person values('Bärbel', TO_DATE ('29-Feb-2000 15:30','DD-MON-YYYY HH24:MI'));

Mit der DUMP-Funktion können Sie z.B. die interne Darstellung des Datums in der Datumsvariablen selektieren.

select geburt, DUMP (geburt,16,1,7) "Hex" from person where name='Bärbel';

GEBURT ____________	Hex ___________________________________________
29.02.00	Typ=12 Len=7: 78,64,2,1d,10,1f,1

Typ=12	ist der Typ für das DATE-Format
Len=7	gibt die Länge an, mit der das Datum abgespeichert ist
78	Hex -> (1) 20	= 20. Jahrhundert
64	Hex -> (1) 00	= Jahr 00
2	Hex -> 2	= Monat Februar
1d	Hex -> 29	= Tag im Monat
10	Hex -> 16-	= 15 Stunden *)
1f	Hex -> 31-1	= 30 Minuten *)
1	Hex -> 1-1	= 0 Sekunden (seit 24:00 Mitternacht)

*) das letzte Bit ist bei Stunden und Minuten immer gesetzt

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.

Ein Beispiel soll dies wieder deutlich machen:

insert into person (name, GEB) VALUES
('Klaus', TO_DATE ('27-AUG-1939 12:50 A.M.',' DD-MON-YYYY HH:MI A.M.'));

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:

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.

Beispiel:
select TO_CHAR (ADD_MONTHS (geb, 1), 'DD-MON-YYYY') "Nächster Monat" from person where name = 'Klaus';

LAST_DAY
Damit können Sie den letzten Tag im Monat abfragen.

Beispiel:
select SYSDATE, LAST_DAY (SYSDATE) "Letzter Tag",
LAST_DAY (SYSDATE) - SYSDATE "Verbleibende Tage" from dual;

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.

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

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

ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY MM DD HH24:MI:SS'

das Format, oder mit

ALTER SESSION SET NLS_DATE_LANGUAGE = German

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.

Test und Inbetriebnahme

Die Datumsfunktionen und Routinen, die ein Datum verarbeiten, sollten auf jeden Fall noch mit den folgenden vier kritischen Datumswerten getestet werden:

9. 31. 1. 29.

September Dezember Januar Februar

1999 1999 2000 2000

Auch sollte in der Testumgebung der Übergang von einem Tag zum nächsten Tag an den folgenden Teminen überprüft werden:

vom 31. Dezember 1998 auf den 1. Januar 1999
vom 31. Dezember 1999 auf den 1. Januar 2000
vom 28. Februar 2000 auf den 29. Februar 2000
vom 29. Februar 2000 auf den 1. März 2000

Einige Tips und weitere Informationen

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.

Einige Jahr 2000-Mythen zum Schluß:

• Das Problem 2000 betrifft nur Mainframes und nicht UNIX-Systeme und schon gar nicht PCs
• Bei den PCs ist es ein reines BIOS-Problem, das durch Austausch beseitigt wird
• Man kann mit einem einfachen Abschalttest (Datum verstellen) die Probe aufs Exempel machen
• Mein PC ist neu, ich habe kein Problem
• Wir verwenden ORACLE als Datenbank, uns kann nichts passieren
• Es sind ja noch 2 Jahre Zeit
• Bis dahin haben wir nur noch neue, einwandfreie PCs und 64 Bit-UNIX-Systeme
• 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
• Die Sache ist nicht schwieriger als die Postleitzahlen-Umstellung
• Das Problem betrifft uns erst nach dem 31. Dezember 1999

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.

Dr. Klaus Hanauer, Tel. -2069, Email: hanauer@rz.uni-karlsruhe.de.

"Bitte keine Werbung einwerfen" - Spamming vor Gericht

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.

Das neue BelWü-ATM-Netz

Verbesserungen und erweiterte Möglichkeiten

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:

IP-Verkehr
Für den IP-Verkehr wurden die Bandbreiten deutlich erhöht. Ferner wurde die Betriebssicherheit durch mehr redundante Wege verbessert.

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.

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.

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.

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.

Neuer Compute-Server für kommerzielle Anwendungen

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).

ORIGIN 2000

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. Die alte NZ55 geht zum 28.2.98 außer Betrieb.

Verfügbare Anwendungen

NASTRAN
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.rz.uni-karlsruhe.de/~NASTRAN.

MAFIA
Programm zur Lösung der Maxwell-Gleichungen nach dem Finiten-Integrations-Algorithmus. Nähere Informationen: http://www.rz.uni-karlsruhe.de/~MAFIA.

Im Laufe der Zeit werden weitere Pakete angeboten werden.

Betriebsmodell

ls bzw. ll	zum Ansehen der Inhaltsverzeichnisses
cp	zum Kopieren von Daten
rm	zum Löschen von Daten
mv	zum Verschieben bzw. Umbenennen von Daten
man	zur Ausgabe von Manual-Seiten.

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. 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 Kommando

cd /home/ws/xx06

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/<Benutzernummer> bzw. über die Umgebungsvariable $RZANWHOME zur Verfügung stehen. Wenn Sie

cd $RZANWHOME

eingeben, landen Sie automatisch im richtigen Verzeichnis. Hier können Sie dann z. B. das Pre- und Postprocessing und alle sonstigen Arbeiten erledigen.
Als Batch-System wird Generic-NQS eingesetzt. Zur Kontrolle der Warteschlange und Ihrer Jobs stehen Ihnen drei weitere Programme zur Verfügung:

qstat -a
Mit diesem Kommando erhalten Sie alle notwendigen Informationen über die Jobs in den NQS-Warteschlangen

qdel [-k]
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.

qcat -e
Mit diesem Befehl wird die bis dahin erzeugte Fehlerdatei ausgegeben.

qcat -o
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.

qcat -o -t n=20
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.

Folgende Betriebsparameter wurden im NQS installiert:

Laufzeitklassen:	M(edium) L(ong)	max. 180 Min. > 180 Min.
Speicherklassen:	max.   256 MB max.   512 MB max. 1024 MB max. 2048 MB

Auf dieser Grundlage wurden folgende Queues eingerichtet:

M256: M512: M1024: L256: L512 L1024: L2048	max. 256 MB Hauptspeicher, max. 180 Minuten CPU-Zeit max. 512 MB Hauptspeicher, max. 180 Minuten CPU-Zeit max. 1024 MB Hauptspeicher, max. 180 Minuten CPU-Zeit max. 256 MB Hauptspeicher, unbegrenzte CPU-Zeit max. 512 MB Hauptspeicher, unbegrenzte CPU-Zeit max. 1024 MB Hauptspeicher, unbegrenzte CPU-Zeit max. 2048 MB Hauptspeicher, unbegrenzte CPU-Zeit

Den Namen der Queue müssen Sie beim Aufruf des paketspezifischen Submittierungsprogramm angeben.

ANSYS

ans53job

[-p PATH] [-c FILE18] [-j xxxx] [-q Queue] -p Name des Pfads, in dem das Input-File steht (optional) -c Name des Input-File (notwendig) -j Option, um filenn.dat in xxxxnn.dat zuändern (max. 4 Zeichen) -q Name der Queue:M256 M512 M1024 L256 L512L1024 L2048

NASTRAN

nasjob

-j Jobname (notwendig) -p Arbeitsverzeichnis -q Job-Queue

ABAQUS

abq56job

-j Jobname (notwendig) -i Inputfile (ohne .inp) -p Arbeitsverzeichnis -o Old-Job-Name (bei *RESTART,*POST OUTPUT und *POST FILE) -f new oder append -m analysis, datacheck, continue oder recover -c restart, select oder all -l environment, local, memory oder release -u User-Subroutine -q Job-Queue (notwendig)

MAFIA

mafia4job

-j Jobname (notwendig) -m MODUL -c COM-File [-p PATH]-j NAME] -q [Job-Queue] -m Name des MAFIA-Moduls, das ausgeführt werden soll. Erlaubt sind m400, s400, e400, t2400,t3400, w3400, ts2400, ts3400, p400 und oo400 bzw. die doppeltgenauen Module <MODUL> -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.

PERMAS V. 6.1:
Neues, voll parallelisiertes FE-Programm auf dem ParallelrechnerIBM RS/6000 SP

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.

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:

Datum: Zeit: Ort:	Donnerstag, 2.4.1998 14.00 Uhr RZ, Raum 217, 2. OG

PERMAS auf der IBM RS/6000 SP

An dieser Stelle soll nur gezeigt werden, wie PERMAS standardmäßig aufgerufen wird, wie der Prä-/Postprozessor PATRAN miteinbezogen wird, und wo man Beispiele und Dokumentationen findet.

Basis für einen PERMAS-Lauf ist die Eingabedatei <project>.dat und eine Kommandodatei <project>.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.

Vorausgesetzt, die Dateien <project>.dat und <project>.uci existieren schon, ruft man PERMAS an einem der Login-Knoten oder interaktiven Knoten der SP folgendermaßen auf:

permas <project>

-memory <Hauptspeicherbedarf in MB> -time <CPU-Zeit in Min.> -submit <Job-Klasse>

Der Job wird dann vom LoadLeveler weitervermittelt und auf einem Knoten seriell gerechnet. Will man parallel rechnen, sieht der Aufruf so aus:

permas <project>

-mod parallel -memory <Hauptspeicherbedarf in MB> -time <CPU-Zeit in Min.> -submit <Job-Klasse> -nodes <Anzahl der CPUs>

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 (<project>.pro, <project>.log) und die Ergebnisse (<project>.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:

• PATRAN-Aufruf p3
• über File —> New gibt man einen Database-Namen ein
• 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

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 <project>.db ein PERMAS-Eingabefile erzeugt werden. Dies geschieht an einem der interaktiven Knoten, wo man

permas <project> -vers patran3

aufruft. Zuvor muß ein UCI-File <project>.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 <project>.dato erzeugt, die als <project>.dat anschließend als PERMAS-Eingabedatei verwendet wird.

Der PERMAS-Lauf erzeugt, wenn im UCI-File die Zeile

DEFAULT SET POSTPROC=PATRAN
steht, je nach Ergebnisanforderung, einige Ergebnisdateien, die im PATRAN Postprocessing über das Analysis-Menü eingelesen werden können.
Beachten Sie, daß PATRAN derzeit auf der SP nur im lokalen Filesystem $TEMP_LOCAL ausgeführt werden kann.

Handbücher und Beispiele

• PERMAS User's Reference Manual I, II
• PERMAS Examples Manual
• PATRAN Door User's Manual
• PERMAS Release Notes
• PERMAS on Unix; Installation und Operations Manual

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

get_example

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

get_example <example>

eingeben.

Dr. Paul Weber, Tel. -4035, Email: Paul.Weber@rz. uni-karlsruhe.de.

PERMAS-Kurzportrait

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:

• Statik Lineares und nichtlineares Verhalten, Kontaktanalyse, Beulen
• Dynamik
  - Antwortverhalten im Zeit- und Frequenzbereich
  - modale und direkte Methoden
  - Fluid/Struktur-Akustik
• Thermodynamik Stationäre und instationäre Temperaturfelder
• Elektromagnetismus Magnetostatik, Elektrodynamik
• Entwurfsoptimierung Form- und Blechdickenoptimierung
• Zuverlässigkeitsanalyse Parameterstudien und Ausfallsicherheit
• Laminatanalyse Beschreibung und Analyse des Verbundaufbaus

• Geschwindigkeit Aktuelle Algorithmen und eine moderne Software-Architektur sorgen für kurze Rechenzeiten.
• Effizienz Auch die größten Modelle verarbeitet PERMAS mit wenig Zentralspeicher und Plattenplatz. Der Bedarf wird vor der Rechnung abgeschätzt.
• Produktivität Modellvarianten werden mit wenig Aufwandgleich miterledigt - komplexe Modelle können in hierarchische Teilstrukturen zerlegt werden.
• Zuverlässigkeit Das Modell wird vorab durchgecheckt, die Rechnung selbst auf Durchführbarkeit überprüft, viele tausend Systemmeldungen im Klartext  melden Unstimmigkeiten und weisen auf Fehler hin.
• Benutzerfreundlichkeit PERMAS unterstützt den Anwender mit zahlreichen Funktionen, die auch komplexe Berechnungen praktikabel machen. Kompetente Beratung steht über die Hotline jederzeit zur Verfügung.
• Integration PERMAS ist in diverse Prä-/Postprozessor- und CAD-Programme integriert. Zu weiteren Systemen besitzt PERMAS leistungsstarke Schnittstellen.

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 und Berechnung sind deutlich zusammengerückt.

Bei der Integration des Prä-/Postprozessors MEDINA und PERMAS wurde ein FE-Komplettpaket geschaffen, das höchste Funktionalität und Rechenleistung mit einem überaus schnellen Datenaustausch verbindet: Der Nutzen liegt im hohen Durchsatz an gerechneten Projekten. Darüberhinaus stehen Integrationen zu I-DEAS und PATRAN zur Verfügung.

Die in PERMAS integrierten Analysemodule sind:

• PERMAS-MQA das Grundmodul mit allen erforderlichen Funktionen zur Bedienung, Verwaltung und Qualitätssicherung des Berechnungsprozesses
• PERMAS-LS für alle statischen Steifigkeits- und Festigkeitsuntersuchungen bei linearelastischem Materialverhalten
• PERMAS-NLS  für Analysen unter Berücksichtigung geometrisch nichtlinearer Effekte und nichtlinearer Materialeffekte wie Plastizität oder Kriechen
• PERMAS-CA für Kontaktprobleme mit und ohne Reibung
• PERMAS-DEV zur Berechnung von dynamischen Eigenwerten und Eigenformen
• PERMAS-DRA zur Ermittlung des dynamischen Antwortverhaltens im Zeit- oder Frequenzbereich
• PERMAS-FS zur Untersuchung gekoppelter Fluid-Struktur-Akustik
• PERMAS-HT zur Ermittlung des stationären oder transienten Wärmeleitungsverhaltens, sowohl linear als auch nichtlinear
• PERMAS-BA zur Berechnung von Beullasten und Beulformen
• PERMAS-OPT zur automatischen Optimierung von Tragwerksentwürfen unter Einhaltung von vorgebbaren Zielen und Restriktionen
• PERMAS-EMS für Berechnungen in der Elektro- und Magnetostatik
• PERMAS-EMD allgemeine Elektrodynamik, z.B. Wellenausbreitung, Wirbelströme etc.
• PERMAS-RA zur Untersuchung bei unsicheren, statistisch verteilten Eingangsgrößen wie Lasten oder Werkstoffkennwerten
• 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. Kompetenz in allen Aspekten der Finite Elemente-Technologie bietet INTES seinen Kunden nicht nur über das High-End Softwaresystem PERMAS an. Auch in Dienstleistungen und einer bis ins Detail fundierten Beratung steht dem Kunden das gesamte Entwickler-Know how von INTES zur Verfügung.

Arbeitsschwerpunkte bei INTES sind:

• Entwicklung und Vertrieb von PERMAS
• Entwicklung neuer und effizienter numerischer Verfahren
• Entwicklung von Softwarelösungen für neue Hardwarearchitekturen (wie Parallelrechner)
• Kopplungen zwischen PERMAS und anderen Software-Systemen (wie CAD-Systeme und Prä-/Postprozessoren),
• Anwendungsberatung und Schulung

INTES Ingenieurgesellschaft für technische Software mbH
Schulze-Delitzsch-Straße 16
D-70565 Stuttgart
Telefon: +49-711-78499-0
Fax: +49-711-78499-10
Email: info@intes.de
http://www.intes.de.

Parallele Programme: Analyse und Debugging

Laufzeitanalyse paralleler Programme mit dem Analysetool Vampir

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:

• VampirTrace, einer Library, die während der Laufzeit des Programms Daten über die Nutzung der MPI-Funktionen sammelt, und
• Vampir, einem Visualisierungstool, das nach der Programmausführung eine detaillierte Analyse des Laufzeit- und Kommunikationsverhaltens ermöglicht.

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.rz.uni-karlsruhe.de/~Vampir/. Außerdem wird Vampir in einer Informationsveranstaltung am 9. März 1998 vorgestellt werden.

Nikolaus Geers, Tel. -3755, Email: geers@rz.uni-karlsruhe.de.

Paralleler Debugger TotalView auf IBM RS/6000 SP und SNI VPP 300

Auf den beiden Parallelrechnern IBM RS/6000 SP und SNI VPP 300 kann für das Debugging serieller und paralleler Programme ab sofort der Debugger TotalView eingesetzt werden. 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.

Ausführliche Informationen zu TotalView können im WWW unter der URL http://www.rz.uni-karlsruhe.de/~TotalView/ abgerufen werden. Außerdem wird TotalView in einer Informationsveranstaltung am 9. März 1998 (siehe Seite 22) vorgestellt.

Nikolaus Geers, Tel. -3755, Email: geers@rz.uni-karlsruhe.de.

Katalogisierung im WWW: Neues Angebot der Universitä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:

• plattformunabhängiges WWW-basiertes System
• Benutzung über jeden handelsüblichen WWW-Browser wie z. B. Netscape Navigator
• maskengeführte Katalogisierungsoberfläche
• einfache Bedienung
• Fremddatenübernahme aus dem Katalogdatenpool aller OLIX-Bibliotheken
• Katalogisierung nach RAK-WB mit Verwaltung von Serien und mehrbändigen Werken
• Schnelle und komfortable Suchmöglichkeiten nach allen wesentlichen Teilen der bibliographischen Beschreibung und lokalen Daten MAB-Unterstützung

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:

• UB Karlsruhe
• UB Kaiserslautern
• UB Mannheim
• UB Freiburg
• UB Tübingen
• UB Stuttgart
• Badische Landesbibliothek
• Württembergische Landesbibliothek

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.

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.

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.

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.

Veranstaltungen

IBM RS/6000 SP-Einführungskurs

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.

Datum: Zeit: Ort: Übungen:	30.3. - 3.4.1998 9.00-12.00 Uhr RZ, Raum 217, 2.OG
Zeit: Ort: Anmeldung:	14.00 - 17.00 Uhr RZ, Raum -101, UG 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.rz.uni-karlsruhe.de/~SP/.

Supercomputing: Ausbildung am Vektorrechner und Parallelrechner

Blockvorlesung 1112+1113 (2+2 SWS)

Datum: Zeit: Ort:	2.3.-7.3.98 (dritte Ferienwoche) Mo.-Fr. 8.30-10.00, 10.30-12.00 Uhr, Mo.-Do. 14.30-16.00 Uhr RZ, Raum 217, 2.OG
Prof. Dr. Willi Schönauer/Hartmut Häfner Übungen
Zeit: Ort:	Mo. 16.30-18.00 und weitere Termine (auch Sa. vormittag) RZ, Seminarraum 217 und Terminalraum

Inhalt
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).

Voraussetzung
UNIX-System, FORTRAN-Kenntnis. Im SS schließt sich ein Vertiefungspraktikum für Shared und Distributed Memory Supercomputer an. Eine Voranmeldung ist nicht erforderlich.

Nächster Termin: 5.10.-10.10.98

Programmieren II: UNIX-Welt, Programmiersprachen, effiziente Rechnernutzung

Blockvorlesung 1020+1021 (2+2 SWS)

Datum: Zeit: Ort:	16.2.-21.2.98 (erste Ferienwoche) Mo.-Fr. 8.30-10.00, 10.30-12.00 Uhr Mo.-Do. 14.30-16.00 Uhr Otto-Lehmann Hörsaal, Physik-Flachbau
Prof. Dr. Willi Schönauer/Hartmut Häfner Übungen am UNIX-System
Ort: Zeit:	Di. ab 16.30 Uhr und weitere Termine Terminalraum des Rechenzentrums

Inhalt
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.

Voraussetzung
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.

Nächster Termin: 21.9.-26.9.98.

Statistik: Einführungskurs SAS

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!

Kursbeginn: Ort: Kursende:	Montag, 23.3.1998, 9.00 Uhr RZ, Raum 217, 2. OG bzw. Übungen im Raum -112, UG Freitag, 27.3.1998, 17.00 Uhr

Programm:

Montag, 23.3.1998

9.00 - 9.45 10.00 - 12.00 14.00 - 15.00 15.00 - 17.00

Begrüßung der Teilnehmer, Vorstellung des Programms, Überblick über Statistikprogramme am Rechenzentrum Das SAS-System, SAS/DMS (Bildschirmoberfläche für SAS mit eigenem Editor), Literatur Aufbau von SAS-Programmen, Variablen, Daten, Dateien Betreute Übung

Dienstag, 24.3.1998

9.00  - 10.30 10.30  - 12.00 14.00 - 15.00 15.00 - 17.00

Eingabe von Daten in SAS Betreute Übung Ausgabe und einfache Auswertungen von Daten Betreute Übung

Mittwoch, 25.3.1998

9.00 - 10.15 10.15 - 12.00 14.00 - 15.30 15.30 - 17.00

Interaktive Dateneingabe, Maskenerstellung (SAS/FSP) Betreute Übung Graphische Darstellung von Daten (SAS/GRAPH) I Betreute Übung

Donnerstag, 26.3.1998

9.00 - 10.30 10.30  - 12.00 14.00  - 15.00 15.00  - 17.00

Graphische Darstellung von Daten (SAS/GRAPH) II Betreute Übung Statistische Prozeduren - Überblick und Beispiel (SAS/STAT) Betreute Übung

Freitag, 27.3.1998

9.00 - 10.15	Überblick über die Möglichkeiten von: - SAS/ETS (Zeitreihenanalyse) - SAS/OR (Operations Research) - SAS/IML (Interactive Matrix Language) - SAS/AF (Programmierung von Menüoberflächen - SAS an anderen Geräten, automatischer Ablauf
10.15 - 12.00 14.00 - 15.00 ab 15.00	Betreute Übung Zusammenfassung der Kursinhalte, Fragen, Abschlußdiskussion 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.

Literatur:
SAS Version 6 - Eine Einführung mit Beispielen.Skript zum Kurs.
Flury, Riedwyl: Angewandte multivariate Statistik.Stuttgart / New York 1983.

Textverarbeitung: Einführungskurs LaTeX

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.

Kursbeginn: Ort: Kursende:	Montag, 9.3.1998, 9.00 Uhr RZ, Raum 217, 2. OG bzw. Übungen in Raum -111, UG Freitag, 13.3.1998, 17.00 Uhr

Behandelte Themen

• Allgemeine Informationen über TeX und LaTeX
• Genereller Aufbau und Gliederung eines Dokuments
• Die vordefinierten Dokumenttypen und Änderungen des Layouts
• Standardschriften und die Verwendung zusätzlicher Schriften
• Silbentrennung, Umlaute und scharfes S
• Listen, Tabellen, Zitate, Fußnoten
• Einfache Graphiken
• Inhaltsverzeichnis, Literaturverzeichnis und weitere Verzeichnisse
• 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.

Literatur:
H. Kopka: LaTeX: Eine Einführung. Addison-Wesly, 1989.
L. Lamport: LaTeX, A Document Preparation System, User's Guide and Reference Manual. Addison-Wesly, 1985.
H. Partl, E. Schlegl, I. Hyna: LaTeX-Kurzbeschreibung. Im Rahmen der verschiedenen TeX-Installationen des RZ als LaTeX-Datei verfügbar.

Softwaretools TotalView und Vampir: Schulungskurs

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.

Datum: Zeit: Ort: Anmeldung:	Montag, 9. März 1998 10.00 Uhr bis 12.30 Uhr und 14.00 Uhr bis 17.00 Uhr RZ, Raum 062 (vormittags), Raum -101 (nachmittags) per Email an geers@rz.uni-karlsruhe.de

Finite Elemente: ABAQUS-Einführungskurs

In der Zeit vom 17. - 20. März 1998 findet wieder ein Einführungskurs in ABAQUS statt. Grundlage ist die Version 5.6. Es werden aber auch schon die Features der neuen Version 5.7 berücksichtigt.

Datum: Zeit: Ort: Anmeldung:	17.-20. März 1998 jeweils 9-13 Uhr und 14-16 Uhr RZ, Raum 217, 2. OG per Email an paul.weber@rz.uni-karlsruhe.de

Es werden keine speziellen Kenntnisse bei den Kursteilnehmern vorausgesetzt.

Programm:

1. Tag:

• Aufbau und Struktur von ABAQUS
• Organisation der ABAQUS-Dokumentation
• Einführendes Beispiel
• Erzeugung der Knoten und der Vernetzung mit ABAQUS-Kommandos

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 überspringen.

2. Tag:

• Elementebibliothek
• Materialeigenschaften
• ABAQUS am Rechenzentrum (Installation an der IBM RS/6000 SP, am FE-Server und anderen Workstations)

3. Tag:

• Lösungsalgorithmen
• Belastungsgeschichte, Prozeduren, Randbedingungen
• Lasten
• Restarts
• ABAQUS-Ausgabe

• ABAQUS/Post
• spezielle Problemlösungen:
  - Wärmeausbreitungsprobleme
  - gekoppelte Temperatur-/Spannungsprobleme
  - Eigenfrequenzen und -moden
  - dynamische Probleme

Alle Teilnehmer bekommen die Kursunterlagen zur Verfügung gestellt.

Dr. Paul Weber, Tel. -4035, Email: Paul.Weber@ rz.uni-karlsruhe.de.

Neu im Internet: Scientific Supercomputing

Ab sofort ist folgendes Buch auch im WWW verfügbar:

Willi Schönauer
Scientific 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.

Inhaltsverzeichnis:

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.	Introduction Prototypes with their Memory Bottlenecks Arithmetic Operations and Memory Bandwidth The Cray T90 The Fujitsu VPP300 (and VPP700) The IBM RS/6000 SP The Cray T3E and DEC Alpha Processors Performance Analysis Basic Considerations Concerning Data Structures Fortran, Autovectorization and Autoparallization, Programming Models Recurrences

Die restlichen Kapitel folgen, wie es der zeitliche Rahmen zuläßt. Das Buch entspricht in etwa dem Inhalt meiner Vorlesung "Supercomputing". Das Buch kann im WWW unter http://www.rz.uni-karlsruhe.de/UNI/RZ/Personen/rz03/book abgerufen werden.

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.