OpenVMS.org (Archiv) dcl.OpenVMS.org (Archiv) HPE OpenVMS OpenVMS Technical Journal VMS Software Inc.
de.openvms.org - Für die deutschsprachige VMS-Community [OpenVMS Swoosh]
Hosted by
PDV-Systeme GmbH
Aktuell | Suchen | Archiv | Eintragen | Über uns | Disclaimer | Kontakt
Links zum Artikel

Navigation

Rubriken

RSS Feeds

de.OpenVMS.org

Benutzer
Gäste online: 8
Benutzer online: 0


Login
Benutzername:

Passwort:


[Einen Benutzer anlegen]


OpenVMS.org ist jetzt OpenVMSNews.com. Links, die auf den alten Site verweisen, funktionieren nicht.


Der OpenVMS-Fachberater: Fallstricke von F$LOCATE und anderen Funktionen
Der OpenVMS-Fachberater - 01-Apr-2003 00:00 UTC
von Bob Gezelter

Code, der fast korrekt ist, ist schädlich, und er begegnet mir oft im Consulting-Alltag. Während ich kürzlich an einem Problem eines Klienten arbeitete, lief mir ein Beispiel dafür über den Weg: ein fast korrekter Gebrauch von F$LOCATE, um festzustellen, ob ein Prozeß ein bestimmtes Privileg oder einen bestimmten Identifier innehat. Der Fehler lag nicht bei F$LOCATE, es war die Weise, wie F$LOCATE (oder jede andere Index-Funktion) benutzt wurde.

In diesem Fall fand ich den Fehler in der ausgelieferten Version eines größeren OpenVMS-Produkts, das nicht von HP stammt. Dieses Produkt enthielt sowohl diesen Programmierfehler als auch ein Kompatibilitätsproblem mit seiner Verwendung des logischen Namens LNM$FILE_DEV (auf das ich in einer zukünftigen Kolumne eingehen werde).

Dieser Artikel wird sich mit dem ersten der beiden Probleme beschäftigen: der häufig falschen Verwendung der lexikalischen Funktion F$LOCATE. Der Fehler fällt in die Kategorie "funktioniert oft die meiste Zeit". Damit erscheinen seine Fehlschäge unvorhersagbar und irregulär. Die Auswirkungen, wenn er auftritt, erscheinen ebenso unregelmäßig und unvorhersagbar. Die höchste Ironie ist, dass der Unterschied zwischen dem korrekten und dem falschen Code weniger als 10 (zehn) Zeichen beträgt.

Betrachten wir den folgenden Testfall:

$ X = "USER_PAY"
$ Y = "REMOTE,DIALUP,KUMQUAT,USER_PAYROLL"
$ IF F$LOCATE(X, Y) .NE. F$LENGTH(Y) THEN -
    WRITE SYS$OUTPUT "User has USER_PAY permission"

Wenn man das obige Beispiel ausführt, sieht man, dass etwas nicht stimmt. Der Benutzer hat den Identifier USER_PAY nicht, der Code hat ihn dennoch "gefunden". Wie sieht die Symptomatik dieses Fehlers aus?

Die Pathologie des Fehlers ist der Vergleich mit einem Teil-Element, und nicht mit einem kompletten Element. Der Autor des Code hat es versäumt, die beiden Zeichenketten in Begrenzerzeichen einzufassen (in diesem Fall ","). Die Korrekturmaßnahme besteht im Einfassen der Zeichenketten in Begrenzungszeichen, um F$LOCATE am Beginn und Ende zu verankern. Dies stellt bei einer Übereinstimmung sicher, dass es sich um ein komplettes Element handelt.

Der korrekte Code für den obigen Fall sieht so aus:

$ X = "USER_PAY"
$ Y = "REMOTE,DIALUP,KUMQUAT,USER_PAYROLL"
$ IF F$LOCATE(",''X',", ",''Y',") .NE. F$LENGTH(",''Y',") THEN -
    WRITE SYS$OUTPUT "User has USER_PAY permission"

Wenn man sich die Fälle genau anschaut, fällt auf, dass die Fehler in wenigstens zwei verschiedenen Situationen auftreten:

  • die Zeichenkette, nach der gesucht wird, ist der Beginn einer anderen Zeichenkette, die am Ende der Möglichkeiten auftritt

  • die Zeichenkette, nach der gesucht wird, ist Teil einer anderen Zeichenkette in der Liste (d.h. es gibt einen weiteren Identifier, der genauso endet).

Oft treten diese Probleme in Code auf, der die Identifier- oder Privilegien-Listen prüft, welche die lexikalische Funktion F$GETJPI zurückliefert. Jedoch können sich sich auch an anderen Stellen manifestieren, besonders bei der Überprüfung von Eingaben.

Generell gesprochen ist dies ein Beispiel dafür, was passieren kann, wenn Implementierung und Design nicht gründlich genug sind. Die Größe Ihrer Orgranisation ist unerheblich; am Ende wird Code von Menschen geschrieben, und er wird Fehler enthalten. Es ist unsere Verantwortlichkeit als IT-Experten, wachsam nach Fehlern Ausschau zu halten, ob sie uns unmittelbar betreffen oder erst in Zukunft. Was heute ein kleiner Fehler ist, kann morgen den Betrieb anhalten.



Über den Autor:

Robert Gezelter, CDP, Software Consultant, Gastredner und Schulungsleiter hat mehr als 25 Jahre internationaler Consulting-Erfahrung im privaten und öffentlichen Sektor. Mr. Gezelter ist ein st regelmäßiger Gastredner auf technischen Konferenzen weltweit, z.B. HPETS (früher DECUS).

Er hat ausgiebig mit OpenVMS seit der ersten Release von VAX/VMS 1978 gearbeitet. Er hat ausgiebig in den Bereichen Computerarchitektur, Betriebssysteme, APIs, Netzwerke, Sicherheit und verwandten Bereichen gearbeitet.

Seine Publikationen umfassen Artikel in Network World, Open Systems Today, Digital Systems Journal, Digital News und Hardcopy. Auch hat er am Computer Security Handbook, 4. Auflage (Wiley, 2002) mitgearbeitet.

Mr. Gezelter ist per Email zu errreichen unter gezelter@rlgsc.com.


Original auf www.openvms.org

Links zum Thema: | Version zum Drucken

< Der OpenVMS-Fachberater: Logische Namen (Teil 5) | Serverkonsolidierung - Zurück in die Zukunft >

HP-Benutzergruppen

Events

Websites

Blogs

Freie VMS-Accounts

[Future Forward] OpenVMS: 30 Jahre, und es geht weiter

Der 25. Oktober 2007 markiert das 30te Jubiläum der VMS V1.0 Release. Drei Dekaden Exzellenz, von anderen Betriebssystemen unerreicht. Von VAX über Alpha bis Integrity, OpenVMS ist die Kraft hinter den kritischsten Anwendungen auf der Welt!


Bei HP:

- HP feiert 30 Jahre OpenVMS
- Ein Grußwort von Ann McQuaid, General Manager HP OpenVMS Systems Division

In der Gemeinschaft und der Presse:
- ComputerWorld: Während sich OpenVMS der 30 nähert, graben Benutzer Videos aus DECs Blütezeit aus
- InternetNews: OpenVMS ist 30, und immer noch stark
- InformationWeek: VMS Betriebssystem ist 30 Jahre alt; Kunden sind überzeugt, dass es für immer halten kann
- Enterprise Open Source Magazin: Happy Birthday, OpenVMS

OpenVMS® is a trademark of HP.
All other trademarks are those of their owners.