Re: [Allegro] war: import.exe und sehr große dateien (2GB-grenze) -> nachbeobachtungen -> kein qrix-problem, es ist nur MULTIX

[Klaus Lehmann]

guten tag herr berger,
nach einer ruhigen nacht, kann ich wieder ans thema angehen, auch 
dabei ihren beitrag dabei kommentierend...


1. ok. das ist ganz klar: diese diskussion betrifft nur ganz wenige.
wer hat schon datenbanken, die im index größer als 2GB sind.
das können nur "fremddatenbanken" sein. wer benutzt dieses?
obacht: die bayern haben ihre kostbaren TA's freigegeben! wer diese 
für allegro-zwecke nutzen will (ja /ich will/), der wird auch an die 
grenzen von multix wohl stossen werden.
trotzdem: das qrix-problem ist nicht für den alltag.



2a. was da unten steht, zu lesen ist, ist für mich sehr verständlich. 
darf ich ein lob aussprechen? "lob!" 
herr berger, in letzter zeit verstehe ich mehr von dem, was sie beitragen. es ist in einer verständlicheren 
sprache abgefasst als "früher". da ich dem manchmal vorkommenden 
programierkauderwelsch von anderen NICHT folgen kann und das auch gar nicht mag, denke ich, daß 
andere anwesende diese verständlichere ausdrucksweise auch als sehr positiv empfinden werden.



2b. die konsequenz dessen, was da unten geschildert wird
zitat: 
> Fazit: Versucht man fuer *32bit-Plattformen* die 2GB-Grenze zu umschiffen,
> muss man recht viel im Code aendern, staerker die unterschiedlichen Welten
, ist: mit echten 64bit-tools zu arbeiten, wenn man gewisse grenzen 
überschreitet oder schreiten muss. 
ein qrix.exe, welches nach unten kompatibel bleiben will, so umzubauen, daß es beiden welten 
(=lesbar/erzeugbarkeit von größer als 2GB-dateien), geht nicht. 
ein qrix.exe, welches nur in der 64bit-welt lebt, sei einfach zu bauen.
das hiesse, ein gespann index/qrix.exe für 64bit muß her. habe ich das 
richtig verstanden? allegro ist auf dem weg ins 64bit-wunderland! ;-)



3. der umbau, den ich für meine 6mill-datenbank vorhabe, stockt.
so einfach, wie es in "h multix" beschrieben wird ["Szenario 1"] ist 
es NICHT! meine probleme:
 einträge aus dem reg1 in ein aex-register/index zu verlagern, geht 
 nicht. in der cat.api sind zu viele(?) einträge, die als default 
 das register1 zu screiben nehmen, OHNE es explicit zu sagen 
 (mit "|1").
 als 2. versuch hatte ich versucht, die schlagworte nach aex zu 
 verlagern. hier kam der qrix.fehler! an was es genau lag, vermag ich 
 nicht mehr zu sagen. gestern nacht: nur noch ausmachen & pennen.
 als dritten versuch heute, nehme ich einen genau definierten 
 kleinen(!) block von einträgen, die keine(!) querbeziehungen zu 
 anderen registern haben, und verlagere ihn ins aex. 
 mal schauen. 3 stunden später hoffe ich dann, erfolg zu haben.

 
soweit so plusgut.
viele grüße
ihr klaus lehmann 
 
 
 
 
Guten Tag [Frau/Herr] Thomas Berger,
danke für Ihre Nachricht.
Am Donnerstag, 8. März 2012 um 23:39 schrieben Sie mir.
Ihre Nachricht finden Sie am Ende dieser eMail.

> Hallo Herr Lehmann,

>> ich begreife nicht, warum qrix keine datei fassen kann, die größer als 
>> "unsere" magische grenze ist??!! alle(?) programme unter win32, 
>> sowieso unter win64 können dateien fassen größer als 2,1GB
>> warum das 32bit qrix.exe nicht???? eine ernsthafte frage!

> Ich habe in den letzten Tagen mehr ueber das Problem gelernt,
> als ich mir je haette traeumen lassen dass es da zu lernen gab.

> Die relevanten Normierungen fuer die diversen Programmiersprachen
> ANSI-C und C++ aus verschiedenen Jahren und abstrakten
> Betriebsystemschnittstellen (POSIX etwa oder die Gnu Library) sollte
> man fuer moeglichst portierbare Programme naturgemaess moeglichst
> wenig verlassen. Fuer Dateien sind da etwa fopen() und fseek() der
> recht portable Standard, das heisst aber, dass hier nicht nur die
> Namen der Funktionen sondern auch die Datentypen ihrer Argumente
> und Rueckgabewerte ebenfalls spezifiziert sind. Und zwar als "long".

> Auf fast allen 32bit-Plattformen (das geht ja auf den Intel 386
> zurueck bzw. auf den MC 68020, Prozessoren, die Mitte der 1980er
> Jahre auf den Markt gekommen sind) ist long ein 32bit Integer.
> Vorzeichenbehaftet, da man in Dateien ggfls. auch zurueckspulen
> koennen will. Daher stammt dann die Grenze von 2GB fuer einzelne
> Dateien.

> Auf einer 64bit-Plattform "funktionieren" diese Standards auch
> heute noch ganz problemlos, dort ist ein "long" typischerweise
> 64 Bit breit, das versagt also erst bei einer Dateigroesse von
> 8 Exabyte (wofuer momentan noch Millionen der groessten
> handelsueblichen Platten zusammengeschaltet werden muessten).
> Reale Dateisysteme und Betriebssysteme moegen das derzeit noch
> staerker einschraenken: FAT32 (durchaus noch relevant fuer Speicher-
> karten) erlaubt etwa nur 4GB grosse Dateien, NTFS immerhin 16TB,
> Linux-Kernels auf 32bit-Systemen ohne die Setzung "CONFIG_LBD" (gibt
> es solche Systeme noch?) erlauben nur Platten und Dateien bis 2TB.
> Jedenfalls: 64bit-Programme auf 64bit-Betriebssystemen koennen
> identischen Quellcode mit ihren 32bit-Pendants haben und das 2GB-
> Problem loest sich dennoch automatisch in Luft auf.

> Fuer die 32bit-Plattformen gab es bereits in den 1990er-Jahren diverse
> Anstrengungen, auch auf 32bit-Plattformen das Nadeloehr "long" zu
> ueberwinden und die sind eigentlich auch seit 10 Jahren ueberall
> implementiert, aber eben jenseits der Standards (man konnte ja fseek()
> etc. nicht um-standardisieren). Microsoft bietet __fseeki64() an,
> unter Linux (bzw. glibc) gibt es zwei Ansaetze: open() und lseek()
> arbeiten eher low-level und haben nicht "long"-Argumente, sondern
> einen eigenen Typ off_t, der ueber einen Compiler-Schalter "transparent"
> von 32 auf 64 bit umgeschaltet werden kann; alternativ gibt es
> mit fseeko() einen Ersatz fuer fseek().

> Existierende Programme fuer 32bit-Plattformen muessen jedenfalls
> in Bezug auf I/O 1.) komplett umgeschrieben werden, damit sie mit Dateien
> groesser 2GB umgehen koennen, und es gibt 2.) a priori keine Art, sie
> so umzuschreiben dass sie weiterhin identisch auf M$ und Linux-
> oder Solaris-Plattformen laufen: Man muss daher also selber eine
> geeignete Abstraktionsschicht zwischenschalten.

> Dann gibt es noch ein drittes Problem, das speziell allegro betrifft,
> und zwar fuer die U**X-Plattformen, da die Microsoft-Plattformen
> standardisierte C-Laufzeitumgebungen besitzen bzw. man dem Benutzer
> eher vorschreiben kann, die aktuellen Servicepacks ihrer Betriebssyteme
> aufzuspielen (die dann die aktuellen MSCRT.DLL's enthalten) als einem
> Solaris-Nutzer, auf die aktuellste Version seines Betriebsystems auf-
> zuruesten: Von allegro-Modulen werden Binaries verteilt, fuer alle Windows-
> Plattformen genuegt dann eines (oder zwei, wenn man auch 64bit-Binaries
> verteilen will). "Nacktes" Unix geht hingegen von Compilation aus Sourcen
> auf der Zielplattform aus, Binaries werden fuer spezielle Distributionen
> in derem Kontext verteilt (und neue bzw. veraenderte Programme insbesondere
> nur fuer solche Distributionen, die noch aktiv gepflegt werden, heute also
> z.B. nur fuer RHEL 5 und RHEL 6, nicht mehr fuer RHEL 4). Bislang war das
> eigentlich nie ein Problem, ein avanti, der heute auf irgendeinem realen Linux-
> System (32bit i386) compiliert worden ist funktioniert auch auf allen anderen,
> selbst wenn deren Kernel-Versionsstaende recht stark voneinander abweichen
> (und nur darauf kommt es an, die Distribution - Debian, CentOS, OpenSUSE
> etc. - ist eher der organisatorische Rahmen fuer die Verteilung, Installation
> und Registrierung der individuellen Softwarepakete, die Distribution also ;-).

> Benoetigt man nun die erst in den letzten 10 oder weniger Jahren eingefuehrten
> Workarounds fuer die 2GB-Grenze und verlaesst damit staerker den Bereich der
> seit 15-20 Jahren etablierten Standards, wird das Riskio deutlich groesser,
> dass ein Binary auf einer realen, aber schrecklich alten Maschine gar nicht
> mehr funktioniert (beim selber Compilieren haette man oft sofort anhand der
> einschlaegigen Fehlermeldungen gemerkt, dass es auf der Maschine gar nicht
> funktionieren kann).

> Fazit: Versucht man fuer *32bit-Plattformen* die 2GB-Grenze zu umschiffen,
> muss man recht viel im Code aendern, staerker die unterschiedlichen Welten
> von M$ und U**X beruecksichtigen und kommt fuer konkrete Systeme mit
> mittel- oder sehr alter Hard- oder Software (FAT32, alte Linux-Kernels ohne
> CONFIG_LBD) dennoch u.U. nicht weiter (und deren Besitzer *wollen* ja
> wahrscheinlich auch keine 2GB-Monsterdateien mit allegro verarbeiten).

> Vermutlich wird es deutlich einfacher sein, die vorhandenen Module so
> zu ueberarbeiten, dass sie *auch* auf 64bit-Systemen (nativ) laufen
> und begleitend die Ansage zu machen, dass jemand, der Dateigroessen
> oberhalb 2GB verarbeiten will, das mit der 64bit-Version zu machen hat.
> Das ist ja schon lange keine exotische Technologie, meinen ersten 64bit-
> Linux-Server habe ich Ende 2005 beschafft und inzwischen schon wieder
> stillgelegt, den Microsoft Server 2008R2 (seit 2010 auf dem Markt?) gibt
> es ausschliesslich als 64bit-Version und fuer Desktops sieht es so aus,
> dass die beliebten, alten "MS-DOS"-16bit-allegro-Module deshalb rasant
> eingemottet werden, *weil* die Anwender zum grossen Teil 64bit-Betriebssysteme
> neu beschaffen und einsetzen, einfach *weil* vom Preis-Leistungsverhaeltnis
> guenstige Arbeitsspeichergroessen inzwischen so gross sind, dass ein
> 32bit-System bereits eine minimale Ausstattung nicht ganz nutzen kann...

> viele Gruesse
> Thomas Berger





-- 
Mit freundlichen Grüßen,
Ihr Klaus Lehmann
* http://allegronet.de * eMail: allegronet at t-online.de * phone: 03528-452 807(fax 809) * mobil: 0171-953 7843
* allegronet.de * Klaus Lehmann * D-01454 Radeberg * Kleinwolmsdorfer Str. 37
* Software für zufriedene Bibliothekare: 1000x bewaehrt und ergiebig
* Bereits 4x allegro-utf8. Buchen Sie die allegro-Roadshow
* Yes we can. Only with allegro. Yes we do. Allways with allegro.
* Internetkataloge & WebHosting für Allegro-C & Web 2.0 with VuFind
* 2011: Sponsor der Peter-Sodann-Bibliothek (Staucha)
* 2012: mit allegro-utf8 V3 und allegro-vufind auf der IFLA in Helsinki





Am Donnerstag, 8. März 2012 um 23:39 schrieben Sie:
> Hallo Herr Lehmann,

>> ich begreife nicht, warum qrix keine datei fassen kann, die größer als 
>> "unsere" magische grenze ist??!! alle(?) programme unter win32, 
>> sowieso unter win64 können dateien fassen größer als 2,1GB
>> warum das 32bit qrix.exe nicht???? eine ernsthafte frage!

> Ich habe in den letzten Tagen mehr ueber das Problem gelernt,
> als ich mir je haette traeumen lassen dass es da zu lernen gab.

> Die relevanten Normierungen fuer die diversen Programmiersprachen
> ANSI-C und C++ aus verschiedenen Jahren und abstrakten
> Betriebsystemschnittstellen (POSIX etwa oder die Gnu Library) sollte
> man fuer moeglichst portierbare Programme naturgemaess moeglichst
> wenig verlassen. Fuer Dateien sind da etwa fopen() und fseek() der
> recht portable Standard, das heisst aber, dass hier nicht nur die
> Namen der Funktionen sondern auch die Datentypen ihrer Argumente
> und Rueckgabewerte ebenfalls spezifiziert sind. Und zwar als "long".

> Auf fast allen 32bit-Plattformen (das geht ja auf den Intel 386
> zurueck bzw. auf den MC 68020, Prozessoren, die Mitte der 1980er
> Jahre auf den Markt gekommen sind) ist long ein 32bit Integer.
> Vorzeichenbehaftet, da man in Dateien ggfls. auch zurueckspulen
> koennen will. Daher stammt dann die Grenze von 2GB fuer einzelne
> Dateien.

> Auf einer 64bit-Plattform "funktionieren" diese Standards auch
> heute noch ganz problemlos, dort ist ein "long" typischerweise
> 64 Bit breit, das versagt also erst bei einer Dateigroesse von
> 8 Exabyte (wofuer momentan noch Millionen der groessten
> handelsueblichen Platten zusammengeschaltet werden muessten).
> Reale Dateisysteme und Betriebssysteme moegen das derzeit noch
> staerker einschraenken: FAT32 (durchaus noch relevant fuer Speicher-
> karten) erlaubt etwa nur 4GB grosse Dateien, NTFS immerhin 16TB,
> Linux-Kernels auf 32bit-Systemen ohne die Setzung "CONFIG_LBD" (gibt
> es solche Systeme noch?) erlauben nur Platten und Dateien bis 2TB.
> Jedenfalls: 64bit-Programme auf 64bit-Betriebssystemen koennen
> identischen Quellcode mit ihren 32bit-Pendants haben und das 2GB-
> Problem loest sich dennoch automatisch in Luft auf.

> Fuer die 32bit-Plattformen gab es bereits in den 1990er-Jahren diverse
> Anstrengungen, auch auf 32bit-Plattformen das Nadeloehr "long" zu
> ueberwinden und die sind eigentlich auch seit 10 Jahren ueberall
> implementiert, aber eben jenseits der Standards (man konnte ja fseek()
> etc. nicht um-standardisieren). Microsoft bietet __fseeki64() an,
> unter Linux (bzw. glibc) gibt es zwei Ansaetze: open() und lseek()
> arbeiten eher low-level und haben nicht "long"-Argumente, sondern
> einen eigenen Typ off_t, der ueber einen Compiler-Schalter "transparent"
> von 32 auf 64 bit umgeschaltet werden kann; alternativ gibt es
> mit fseeko() einen Ersatz fuer fseek().

> Existierende Programme fuer 32bit-Plattformen muessen jedenfalls
> in Bezug auf I/O 1.) komplett umgeschrieben werden, damit sie mit Dateien
> groesser 2GB umgehen koennen, und es gibt 2.) a priori keine Art, sie
> so umzuschreiben dass sie weiterhin identisch auf M$ und Linux-
> oder Solaris-Plattformen laufen: Man muss daher also selber eine
> geeignete Abstraktionsschicht zwischenschalten.

> Dann gibt es noch ein drittes Problem, das speziell allegro betrifft,
> und zwar fuer die U**X-Plattformen, da die Microsoft-Plattformen
> standardisierte C-Laufzeitumgebungen besitzen bzw. man dem Benutzer
> eher vorschreiben kann, die aktuellen Servicepacks ihrer Betriebssyteme
> aufzuspielen (die dann die aktuellen MSCRT.DLL's enthalten) als einem
> Solaris-Nutzer, auf die aktuellste Version seines Betriebsystems auf-
> zuruesten: Von allegro-Modulen werden Binaries verteilt, fuer alle Windows-
> Plattformen genuegt dann eines (oder zwei, wenn man auch 64bit-Binaries
> verteilen will). "Nacktes" Unix geht hingegen von Compilation aus Sourcen
> auf der Zielplattform aus, Binaries werden fuer spezielle Distributionen
> in derem Kontext verteilt (und neue bzw. veraenderte Programme insbesondere
> nur fuer solche Distributionen, die noch aktiv gepflegt werden, heute also
> z.B. nur fuer RHEL 5 und RHEL 6, nicht mehr fuer RHEL 4). Bislang war das
> eigentlich nie ein Problem, ein avanti, der heute auf irgendeinem realen Linux-
> System (32bit i386) compiliert worden ist funktioniert auch auf allen anderen,
> selbst wenn deren Kernel-Versionsstaende recht stark voneinander abweichen
> (und nur darauf kommt es an, die Distribution - Debian, CentOS, OpenSUSE
> etc. - ist eher der organisatorische Rahmen fuer die Verteilung, Installation
> und Registrierung der individuellen Softwarepakete, die Distribution also ;-).

> Benoetigt man nun die erst in den letzten 10 oder weniger Jahren eingefuehrten
> Workarounds fuer die 2GB-Grenze und verlaesst damit staerker den Bereich der
> seit 15-20 Jahren etablierten Standards, wird das Riskio deutlich groesser,
> dass ein Binary auf einer realen, aber schrecklich alten Maschine gar nicht
> mehr funktioniert (beim selber Compilieren haette man oft sofort anhand der
> einschlaegigen Fehlermeldungen gemerkt, dass es auf der Maschine gar nicht
> funktionieren kann).

> Fazit: Versucht man fuer *32bit-Plattformen* die 2GB-Grenze zu umschiffen,
> muss man recht viel im Code aendern, staerker die unterschiedlichen Welten
> von M$ und U**X beruecksichtigen und kommt fuer konkrete Systeme mit
> mittel- oder sehr alter Hard- oder Software (FAT32, alte Linux-Kernels ohne
> CONFIG_LBD) dennoch u.U. nicht weiter (und deren Besitzer *wollen* ja
> wahrscheinlich auch keine 2GB-Monsterdateien mit allegro verarbeiten).

> Vermutlich wird es deutlich einfacher sein, die vorhandenen Module so
> zu ueberarbeiten, dass sie *auch* auf 64bit-Systemen (nativ) laufen
> und begleitend die Ansage zu machen, dass jemand, der Dateigroessen
> oberhalb 2GB verarbeiten will, das mit der 64bit-Version zu machen hat.
> Das ist ja schon lange keine exotische Technologie, meinen ersten 64bit-
> Linux-Server habe ich Ende 2005 beschafft und inzwischen schon wieder
> stillgelegt, den Microsoft Server 2008R2 (seit 2010 auf dem Markt?) gibt
> es ausschliesslich als 64bit-Version und fuer Desktops sieht es so aus,
> dass die beliebten, alten "MS-DOS"-16bit-allegro-Module deshalb rasant
> eingemottet werden, *weil* die Anwender zum grossen Teil 64bit-Betriebssysteme
> neu beschaffen und einsetzen, einfach *weil* vom Preis-Leistungsverhaeltnis
> guenstige Arbeitsspeichergroessen inzwischen so gross sind, dass ein
> 32bit-System bereits eine minimale Ausstattung nicht ganz nutzen kann...

> viele Gruesse
> Thomas Berger