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

[Fischer, Thomas]

Hallo Herr Eversberg,

> > 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.)
> >
> Fehlendes -kX  hat Default  -ka  zur Folge. Das macht nicht upd.exe
> oder update.job, sondern acon. Oder kriegen Sie eine Fehlermeldung,
> wenn Sie -k weglassen, und wenn ja, wie lautet sie?

wie Sie erwarten wird dann eine *.adx-Datei gesucht und nicht gefunden.

> > 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.)
> >
> Wir erledigen das in "optsget.inc", die Meldung wird aber lauten
>    HINWEIS: Option -S ist veraltet und wirkungslos
> denn "unterstützt" ist in solchem Zusammenhang ein skurriler
> Wortgebrauch, wie beliebt er auch sei.

Umso besser.

> > 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.
> Ihr Hang zur Abstraktion wird nicht allgemein geteilt. Von mir auch nicht.
>
> > 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.
> Es wird da angelegt, wo das Programm (in diesem Fall der acon startende
> Prozess) läuft.

Das wäre genau die Information, die ich mir dort wünschen würde.

> -- Völlig unsinnig ist es,
> > dass index bei -ebuch versucht, mit einer Parameterdatei "buc" zu
> > arbeiten.
> Ja, aber es ist eben auch ein Fehler, die Option ohne /datenpfad
> anzugeben. Da müssen wir schauen, ob sich eine Fehlermeldung rauskitzeln
> läßt. Immerhin sagt die Doku in 12.1 zu -e:
>     (/ bzw. + darf nicht fehlen)

Bei anderen Programmen wird ja gefordert:
Die vorgeschriebene Form ist  -e param/outfile  oder  -e param+outfile
Bei index ist aber der zweite Parameter ein *Verzeichnis*.
Da könnte natürlicherweise (wenn fehlend oder leer) das aktuelle Verzeichnis gewählt werden.
Ein Dateiname ist wohl nicht sinnvoll zu raten.
Ansonsten wäre eine Fehlermeldung besser als die Suche nach "buc".

>   -- 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.
> Doch, in 12.1 steht auch:
> "Der Dateiname outfile ist ggfls. einschließlich eines Verzeichnisnamens
> anzugeben"

Ist "C:" ein Verzeichnisname?

>   -- 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.
> Was hatten Sie denn in dem Falle eingegeben?

Das kommt aus dem letzten Brief:
5. 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
C:\allegro\LIST\OPRD.Pdx not found in C:\allegro\LIST

>   -- 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.
> Wurde er nicht, das ist zugegebenermaßen ein Unterschied. Oder wurde
> zusätzlich eine Option -b mit dem Datenbanknamen angegeben? Das geht
> auch noch immer.

Nein, nur ein %-B% in den Umgebungsvariablen.

> > 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.
> und wo nicht?

Das obige Beispiel
C:\allegro\LIST\OPRD.Pdx not found in C:\allegro\LIST
finde ich keine klare Fehlermeldung.

> >>> 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?
> >
> Das sollte immer gehen. Wo geht es nicht?

Ich hatte ja den Punkt bei index -eOPRD/. versucht, mal mit (in C:\Allegro\LIST\), mal ohne (in M:\LIST\) Erfolg.

> > 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,
> Nun, vermutlich weil der ganze Prozeß dort seinen Anfang nahm.

Und warum schreibt protoq dann
Target: path=C:
?

Mit freundlichen Grüßen
Thomas Fischer