[Allegro] srch32 und includes im Datenbankverzeichnis - und Nachladungen

Di Okt 16 23:32:22 CEST 2012

Lieber Herr Berger, lieber Herr Eversberg, Liebe Listenleserinnen und -leser,

ich denke, dass es sinnvoll ist, wenn sich alle Teilprogramme
der "Allegro-Suite" bezüglich der Suchreihenfolgen gleich 
verhalten würden.

ThB:
> ist nicht gegeben und der Schalter -b wird auch nicht
> ausgewertet, um ein zweit-Datenverzeichnis zu deklarieren.

Der wird ja benötigt, damit Nachladungen funktionieren -
also ist das Datenbankverzeichnis kein Datenbankverzeichnis...?

Aber es stimmt: wenn man das so betrachtet, ist das Verhalten der 
srch.exe erklärbar. Also werde ich in Zukunft die benötigten 
Parameter immer vorher in's Arbeitsverzeichnis kopieren ...

Oder kann mich Herr Eversberg von dieser Bürde befreien?

Beim weiteren Testen bin ich auf einen zweiten Effekt
gestoßen, der auch mit dem (Nachlade-)Datenbankverzeichnis zu tun 
hat. Da mich das mächtig geärgert hat, hier der Versuch einer
knappen und hoffentlich unterhaltsamen Darstellung:

Ausgangssituation:
- windows 7 ultimate SP1
- drei Umgebungen, die identische Dateien enthalten (ich hatte 
  eine Systemabhängigkeit vermutet):
- eine liegt auf C:\ac_wb\sti-work  (lokal)
- eine liegt auf R:\ac_wb\sti-work  (Windows 2003-Server)
- eine liegt auf H:\ac_wb\sti-work  (Linux-Server/Samba3)
- es wird ein Suchlauf mit Export aus sss.alg aus einem
  Arbeitsverzeichnis unterhalb des Datenbankverzeichnisses gestartet
Aufruf:
{LW}:\ac_wb\sti-work\dbaux\aneg>{LW}:\ac_wb\srch32.exe -f4 -kasti -s0 _
-dsss.alg -b{LW}:\ac_wb\sti-work\sti -e{LW}:\ac_wb\sti-work\p-w-sti/sti-liste.rtf _
-P{LW}:\ac_wb\ -m0 -v0 -lGER

In der Parameterdatei werden Inhalte von Stammsätzen benötigt, die in der
Datei sti_249.ald stehen.

Das Procmon-Protokoll zeigt, dass die Datei, aus der nachgeladen 
werden soll, im Root-Verzeichnis des Laufwerks gesucht wird.

srch32 meldet während des Laufs je versuchter Nachladung etwas derartiges.
--------------------------------------------------------------------------------
recn=118302, wrong recn=-16843009, ci=-1, file#=249  rad=6797   press any key...

                a = allgemeines Menue
--------------------------------------------------------------------------------
- da es natürlich aus der falsch geöffneten Datei nichts laden kann.

(liefert die WoW64-Emulation für die nicht vorhandene Datei im Root-Verzeichnis 
keinen von srch32 bemerkbaren Fehler?)

Beispielhafter Auszug aus Procmon-LOG (etwas gekürzt die H:-Variante):

"srch32.exe","CreateFile","\\aneg-ts4\h\sti_249.ald","NAME NOT FOUND","Desired Access: Generic Read, Disposition: Open, Options: 
Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: n/a"

   (Das ist ja o.k. - es WIRD ja an falscher Stelle gesucht.)

"srch32.exe","CreateFile","\\aneg-ts4\h\sti_249.ald","SUCCESS","Desired Access: Generic Read, Delete, Disposition: OpenIf, Options: 
Synchronous IO Non-Alert, Non-Directory File, Random Access, Delete On Close, Attributes: N, ShareMode: Read, Write, 
AllocationSize: 0, OpenResult: Created"

   (Interessant: an dieser Stelle gibt es keine sti_249.ald ! Warum wird nach 
   dem Fehlschlag des ersten Versuchs noch einmal mit anderen Parametern probiert?
   Man beachte: Option "Delete On Close" - stammt das etwa aus WoW64?)

"srch32.exe","QueryDeviceInformationVolume","\\aneg-ts4\h\sti_249.ald","SUCCESS","DeviceType: Disk, Characteristics: Remote"
"srch32.exe","ReadFile","\\aneg-ts4\h\sti_249.ald","END OF FILE","Offset: 1.733, Length: 4.096, Priority: Normal"
"srch32.exe","ReadFile","\\aneg-ts4\h\sti_249.ald","END OF FILE","Offset: 1.733, Length: 4.096, Priority: Normal"
"srch32.exe","ReadFile","\\aneg-ts4\h\sti_249.ald","END OF FILE","Offset: 1.733, Length: 4.096, Priority: Normal"
"srch32.exe","ReadFile","\\aneg-ts4\h\sti_249.ald","END OF FILE","Offset: 1.733, Length: 4.096, Priority: Normal"
"srch32.exe","ReadFile","\\aneg-ts4\h\sti_249.ald","END OF FILE","Offset: 1.733, Length: 4.096, Priority: Normal"

   (5x eine nicht vorhandene Datei zu lesen versuchen - wozu?)

"srch32.exe","CloseFile","\\aneg-ts4\h\sti_249.ald","SUCCESS",""

   (Es bleibt an dieser Stelle keine Datei stehen, auch nicht mit Länge 0 - s.o.)

Das gleiche unter Windows 2000 liefert eine sinnvolle Fehlermeldung:
(B: ist C: des Win7-PC)

("_" = eingefügter Zeilenumbruch)

------------------------------------------------------------------------
B:\ac_wb\sti-work\dbaux\aneg>b:\ac_wb\srch32.exe -f4 -kasti -s0 _
-dsss.alg -bb:\ac_wb\sti-work\sti -eb:\ac_wb\sti-work\p-w-sti/sti-liste.rtf _
-Pb:\ac_wb\ -m0 -v0 -lGER
b:\ac_wb\uif4GER geoeffnet
B:\ac_wb\sti-work\dbaux\aneg\$asti.cfg geoeffnet
b:\ac_wb\s1.asp geoeffnet
Target files sss.alg
1 files on , first, last: sss.alg, sss.alg
durchsucht wird sss.alg
b:\ac_wb\sti-work\p-w-sti.apr geoeffnet
b:\ac_wb\d-rtf.apt geoeffnet
b:\ac_wb\d.apt geoeffnet
output=sti-liste.rtf wurde geoeffnet
Die Suche/Verarbeitung beginnt mit sss.alg
Suchbegriff: 0
b:\ac_wb\sti-work\sti.api geoeffnet

Datei b:\sti_249.ald nicht zugaenglich

B:\ac_wb\sti-work\dbaux\aneg>
------------------------------------------------------------------------
Hätte ich mal gleich mit Windows 2000 getestet ...

Dieser Aufruf (identische Verzeichnisinhalte):

h:\ac_wb\sti-work\dbaux\aneg>H:\kunden\wb-stauf\allegro\srch32.exe -f4 -kasti _
-s0 -dsss.alg -bH:\kunden\wb-stauf\allegro\sti-work\sti _
-eH:\kunden\wb-stauf\allegro\sti-work\p-w-sti/sti-liste.rtf _
-PH:\kunden\wb-stauf\allegro\ -m0 -v0 -lGER

läuft dagegen mit erfolgreichen Nachladungen sauber durch !!!
Andersherum hätte ich das ja verstanden, da hier die Pfadangaben viel länger
sind.

Da die Verzeichnisinhalte für die dargestellten Tests vom Allegro-
Programmverzeichnis, dem Datenbank-Verzeichnis und dem Startverzeichnis 
jeweils identisch sind - welche Möglichkeiten gibt's noch?

War da nicht schon mal was mit der srch.exe ... ? Na, hat's jemand gesehen?

Böse ist nur, dass sich das Programm srch32.exe nicht generell d'ran stößt, 
sondern scheinbar nur beim Öffnen von Datenbank-Dateien bei angeforderten
Nachladungen. Sonst wäre ich wohl eher drauf gekommen.

Viele Grüße
Anando Eger

PS: Wer's nicht gesehen hat - Auflösung ganz am Ende ;-)

---------------------------------------------------------------------
Anando Eger Datenverarbeitung
Herr Dipl.-Ing. Anando Eger
Gustav-Voigt-Str. 24
01156 Dresden
Tel.: +49 (0)351 454 1236  http://www.aneg-dv.de
Fax: +49 (0)351 454 1238  mailto:a.eger at aneg-dv.de
---------------------------------------------------------------------

On 16 Oct 2012 at 15:24, Thomas Berger wrote:

> Lieber Herr Eger, liebe Liste,
> 
> > Lädt srch[32].exe keine mit t eingebundenen Dateien aus dem
> > Datenbank-Verzeichnis nach, wenn die ?pr-Datei in diesem liegt?
> > 
> > Es scheint nur im aktuellen Arbeits- und Programmverzeichnis zu
> > suchen.
> 
> das war m.W. beim 16bit-SRCH unter Ihren Bedingungen auch
> nicht anders: Das Datenverzeichnis ist dasjenige, wo hier
> sss.alg liegt (also vermutlich das Arbeitsverzeichnis),
> eine Umgebungsvariable -d hat keinen Einfluss (Schalter -d)
> ist nicht gegeben und der Schalter -b wird auch nicht
> ausgewertet, um ein zweit-Datenverzeichnis zu deklarieren.
> 
> Man konnte natuerlich keinen expliziten Pfad fuer die
> Exportparameterdatei angeben und fuer srch32 waere zu
> fordern, dass ein fuer einge gewisse .apr genutzer Pfad
> auch (allerdings wann?) zu benutzen ist, um von dieser
> Datei benoetigte .apt/. at pt-Includes zu suchen.
> 
> viele Gruesse
> Thomas Berger
> 
> 
> 
> > 
> > Bedingungen:
> > - aktuelle srch.exe (hier im Beispiel als srch32.exe)
> > - Parameterdatei p-w-knd.apr im Datenbankverzeichnis, die 
> >   p-nelrtf.apt einbindet
> > - Aufruf (hier umgebrochen), aus 
> >   h:\kunden\wb-knd\allegro\katalog\dbaux\aneg\ 
> >   heraus:
> > 
> >   H:\kunden\wb-knd\allegro\srch32.exe 
> >     -f4 
> >     -ka 
> >     -s0 
> >     -dsss.alg 
> >     -bh:\kunden\wb-knd\allegro\katalog 
> >     -eh:\kunden\wb-knd\allegro\katalog\p-w-knd+nel.rtf 
> >     -Ph:\kunden\wb-knd\allegro\ 
> >     -m0 -v0 -lGER
> > 
> > (Ausschnitt aus Procmon-Log im Anhang)
> > 
> > Der Versuch, 
> > 
> > H:\kunden\wb-knd\allegro\H:\kunden\wb-knd\allegro\p-nelrtf. at pt
> > 
> > zu öffnen, scheint auch nicht o.k. Gerade noch einmal getetstet: 
> > Das gleiche Szenarium unter c:\allegro führt zu dem gleichen Fehler -
> > es wird C:\allegro\C:\allegro\p-nelrtf. at pt gesucht.
> > 
> > Viele Grüße
> > Anando Eger
> > 
> > ---------------------------------------------------------------------
> > Anando Eger Datenverarbeitung
> > Herr Dipl.-Ing. Anando Eger
> > Gustav-Voigt-Str. 24
> > 01156 Dresden
> > Tel.: +49 (0)351 454 1236  http://www.aneg-dv.de
> > Fax: +49 (0)351 454 1238  mailto:a.eger at aneg-dv.de
> > ---------------------------------------------------------------------
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Allegro mailing list
> > Allegro at biblio.tu-bs.de
> > http://sun250.biblio.etc.tu-bs.de/mailman/listinfo/allegro
> > 
> 

Auflösung: Die Pfadangaben enthielten einen Tiefstrich (ac_wb)
Herr Eversberg: läßt sich diese "Empfindlichkeit" evtl. noch ausmerzen?