AW: [Allegro] Schmerzloser Umstieg vom alten update auf update.job

[Fischer, Thomas]

Hallo Herr Eversberg,

schönen Dank für die prompte Antwort.
Nach meinen Erfahrungen würde ich sagen, dass zum schmerzlosen Umstieg zumindest die folgenden Regeln zu beachten sind (bzw. der update.job entsprechend zu ergänzen ist).

1. Das neue Update braucht einen Parameter -k, in dem der Konfigurationsbuchstabe angegeben wird. (Ich weiß nicht, warum update den raten konnte und acon nicht.)

2. Etwaige Parameter -S müssen entfern werden. (Ich weiß wiederum nicht, was der im Kontext von acon überhaupt ausmachen würde und fände es besser, wenn statt den Prozesses abzubrechen einfach eine Meldung "Der Parameter -S wird nicht unterstützt" ins Protokoll geschrieben würde.)

3. Die Auswertung den Datenquellenparameter ist wahrscheinlich schon immer problematisch gewesen, vielleicht kann hier ja ein wenig (sanft) aufgeräumt werden. Ich finde durchgängig die "Erklärung am Beispiel" nicht so hilfreich wie eine etwas formalere Beschreibung. Z.B. die Erklärung

-e cat/bibl             Indexproduktion (Funktion INDEX -f7) mit Param. CAT.API;  CAT.ADX wird auf  ALLEGRO\BIBL\  erzeugt.

kann nur für spezielle Situationen stimmen. Ich vermute, dass im Allgemeinen ein Verzeichnis "bibl" im aktuellen Ausgangsverzeichnis angelegt wird.

Hier noch ein paar Vorschläge:
-- In 12.1 sollte bei dem Parameter -d in der Spalte "anwendbar bei Programm" q ergänzt werden.
   Dann steht da auch eine Antwort auf meine Frage 3.
-- Völlig unsinnig ist es, dass index bei -ebuch versucht, mit einer Parameterdatei "buc" zu arbeiten.
-- Hilfreich wäre für -e und -d ein einfacher und eindeutiger Bezug auf das aktuelle Verzeichnis,
   besser noch relative Pfade der Art ..\bibl.
   Soweit ich sehe wird auch nirgends erwähnt, dass auch absolute Pfade angegeben werden können.
-- Aussagen wie
        C:\allegro\LIST\OPRD.Pdx not found in C:\allegro\LIST
   finde ich irritierend, wenn die Datei OPRD.Pdx in C:\allegro\LIST\ existiert.
   Wenn acon die Datenbank OPRD schon richtig gefunden hat (wie?), dann sollte es seine Arbeit machen.
-- Vielleicht könnte geklärt werden, welche Aufrufe das alte update tolerierte und das neue nicht (und warum).
   Bei uns lief seit über 10 Jahren
        update -dC:\ALLEGRO\LIST -uGRUND.PLG ...
   problemlos im Verzeichnis LIST, ob der Name der Datenbank seitdem irgendwann einmal verbindlich gefordert wurde, weiß ich nicht.

> > 3. Darauf muss man dann qrix loslassen. Welche Bedeutung hat der
> > Parameter -d in qrix -fq -dbuecher -ebuch/buecher -ka im Beispiel 7.1
> > a1) eigentlich?
> Er sagt, wo die Daten liegen. Daß sie ii... heißen, weiß qrix selber,
> andere kann es mit Option -fq nicht verarbeiten.
> ("Datenquelle : wo sind die zu verarbeitenden Daten?" steht in Kap. 12)
>
> > gibt aber wohl das Verzeichnis an, in dem nach ii-Dateien gesucht
> > wird. Ist es klar, dass im aktuellen Verzeichnis gesucht wird, wenn
> > man das weglässt? Oder muss man dafür ein -d. oder etwas Ähnliches
> > angeben?
> Das müßte auch ich erst eruieren. Also besser angeben und fertig.

Ich hoffe, dass dann die entsprechende Aussage aus 12.1 -d stimmt:

Wenn  -d  nicht angegeben ist, entnimmt das Programm den Datenpfad
aus der Umgebungsvariablen  -d .
Fehlt auch diese, gilt das aktuelle Arbeitsverzeichnis.


> > 4. Der Befehl C:\allegro\update -uVKFKAT.PLG -kP -fm30
> > -dC:\allegro\LIST -PC:\allegro -n1 -S -L -m0 liefert aufruf =
> > C:\allegro\acon -jC:\allegro\update -uVKFKAT.PLG -kP -fm30
> > -dC:\allegro\LIST -PC:\allegro -n1 -S -L -m0 LIST.Pdx not found in
> > C:\allegro und damit den Hinweis, dass der -d-Parameter wohl nicht
> > als Datenverzeichnis interpretiert wird (warum wird eigentlich in
> > C:\allegro gesucht?)
> Das letzte Element in Option -d muß der Datenbankname sein, richtig wäre
> also   -dc:\allegro\list\oprd. Es geht auch  -dc:\allegro\list -boprd.
> SONST wird konsequent angenommen, daß LIST der Datenbankname ist und
> sie in c:\allegro residiert. Leider wird Envir. -B nicht ausgewertet,
> wenn -d angegeben ist; sinnvoll wäre evtl., das im update.job zu machen.
> Sind beide nicht als Option angegeben, dann werden sie aber aus dem
> Envir. entnommen - eine ärgerliche Inkonsequenz? Sollten wir sie
> beheben?

Ja, das wäre mir lieb, wenn grundsätzlich bei fehlenden Parametern die entsprechenden Umgebungsvariablen genommen würden und bei deren Fehlen geeignete Standardwerte. Falls es die nicht gibt, wünsche ich mir einen Abbruch mit informativer Fehlermeldung, das klappt im Prinzip ja schon ganz gut.
Die Meldungen in protok und protoq könnten dahingehend aufgeräumt werden, dass durchgängig CR LF (von mir aus auch einer der beiden) zur  Zeilentrennung eingesetzt würde, derzeit gibt es da LF, CR LF und LF CR, das macht nicht jeder Texteditor klaglos mit.

> Der update.job ist ein wenig intolerant, unbekannte Optionen ignoriert
> er nicht, sondern beschwert sich und tut nichts. Ist das zu pingelig?

Wenn sie irrelevant sind: s.o.

> > 8. C:\allegro\update -uVKFKAT.PLG -kP -fm30 -dC:\allegro\LIST\OPRD
> > -PC:\allegro -n1 -L -m0 läuft schließlich durch.
> >
> Da ist ja auch alles korrekt.
>
> > Auch hier ist mir nicht klar, wie man sich effektiv auf das aktuelle
> > Verzeichnis bezieht.
> Versuchen Sie  -d.\oprd

Das ist ein Spezialfall meines obigen Desiderats. Wo geht das noch?

> > 9. Leider funktioniert das Verfahren nicht mehr nach Übertragung auf
> > einen anderen Server: M:\index -f71 -eOPRD/. -dGRUND.PLG -PM: -n1
> > -kP nennt zwar die Datei in GRUND.P8G um, erzeugt aber das ii1 und
> > die Datenbank OPRD_1.pld aber leider in C:\WINDOWS\system32 Da muss
> > ich noch den -e-Parameter ändern, "." klappt also nicht...
> >
> Was war denn der Ausführungsort dabei? (In c:\windows\system32 haust
> cmd.exe, und der startet  index ... .)

Ich rufe die ganzen Programme über eine Batchdatei auf:

C:\Windows\System32\cmd.exe
C:\Windows\System32>M:
M:\>cd LIST
M:\LIST>PRD

Die ruft dann eine weitere Batchdatei auf und los geht's.
Wieso dann wieder etwas in C:\Windows\System32 landet ist, mir schleierhaft, ich habe es auch nur durch eine globale Suche im Explorer gefunden.
protoq gibt in diesem Fall an:

Source=M:\LIST\
GRUND.PLG
Target: path=C:

In C:\ kommt aber nichts an.

Mit freundlichen Grüßen
Thomas Fischer