Hier wird versucht, eine Einfachst-Einführung der wichtigsten Grundgedanken zu geben. Um welche Dateien es geht, steht ganz unten.

Das Ausgeben von Daten, auch Exportieren genannt, gehört bei jedem Datenbanksystem zu den wichtigsten Aufgaben. Denn jede Datenbank ist dazu da, bei Bedarf jederzeit Daten herausrücken zu können. allegro hat dafür eine eigene Sprache, die Exportsprache, mit der man das Ausgeben von Daten in allen Einzelheiten so programmieren kann, wie es in einer konkreten Situation gebraucht wird. Wenn man Daten über das Exportmenü des Windows-Programms ausgeben lässt (früher mit F4 beim DOS-Programm), wird dafür in Wirklichkeit fast immer eine Parameterdatei gebraucht. Hier soll gezeigt werden, was das eigentlich ist.

Im Prinzip steht alles im Handbuchkapitel 10, das mit einer ausführlichen Erklärung des Konzepts beginnt. Mancher Leser findet es trotzdem unverdaulich - wir wissen das. Deshalb dieser Text, der das Kapitel zwar nicht ersetzt, aber hoffentlich den Einstieg erleichtert.

Hinweis: Seit es die FLEX-Makrosprache gibt, kann man in a99/alcarta und avanti auch mit dem FLEX-Befehl write, also ohne Exportsprache, Daten ausgeben. Aber man kann nicht alles damit machen, z.B. die Titelanzeige kann man damit nicht gestalten: dafür braucht man eine Parameterdatei, die sog. "Anzeigeparameter". Im Normalfall ist das die mitgelieferte Datei D-WRTF.APR.

Zur Sache nun. Gespeicherte allegro-Daten sehen immer so aus:
(Wichtig für Nicht-allegro-Kenner: Datenfelder werden nicht mit Namen benannt, sondern mit Nummern)

Die gespeicherten Datenelemente oder Felder beginnen, wie man sieht,  mit # und einer Nummer: Die erlaubten Nummern und ihre Bedeutung stehen in einer Konfigurationsdatei; beim Standardmodell ist das die Datei $A.CFG, man spricht auch von der A-Konfiguration oder vom A-Schema (--> Dokumentation). Der Buchstabe A tritt dann auch in den Namenserweiterungen aller Export- und Import-Parameterdateien auf - wenn man einen Namen wie  D-WRTF.APR oder CAT.API sieht, weiß man: das sind Parameterdateien für das A-Schema. (Mehr dazu weiter unten.) Wenn Sie wollen, können Sie jetzt gleich mal reinschauen in Ihre CFG. Die erlaubten Nummern können Sie aber auch mit Alt+y sehen (im Programm a99), dann erscheinen sie links im Auswahlfeld.
(Anm.: Das $ im Namen $A.CFG geht zurück auf den Versionswechsel von V12 zu V13, siehe Handbuch Anh.A.5. Wenn es $A.CFG und A.CFG beide gibt, nehmen die Programme die $A.CFG, d.h. die A.CFG hat dann keine Wirkung. (Trotzdem: alte CFGs, also V12 oder früher, funktionieren auch noch mit der aktuellsten Version.)

Wenn man oft Daten eingibt, sind einem die Nummern ja schnell geläufig. Wenn Daten aber für Endbenutzer angezeigt werden müssen oder wenn man irgendwelche Listen zu erstellen hat oder Ausgabedateien, dann sollen dabei keine numerierten Daten erscheinen, sondern z.B. eine Anzeige wie diese: (vergleichen Sie das mit dem, was oben steht)

Also etwas gänzlich anderes. Wie kann man das erreichen? Mit einer Export-Parameterdatei. Das ist eine schlichte ASCII-Textdatei, und darin muss die Vorschrift für das Programm stehen, was es mit den Datenfeldern machen soll - damit herauskommt, was man wirklich sehen will.
Damit das herauskommt, was man hier sieht, müsste man eine recht komplizierte Parameterdatei schreiben. Zum Glück gibt es die schon: sie heißt D-WRTF.APR und wird von a99 und alcarta verwendet, um die Daten anzuzeigen. Die Datei D-WRTF.APR wäre aber als Einstieg, als erstes Beispiel, viel zu lang und zu schwierig.

Sie wollen jetzt sicher wissen: wie sieht die einfachste mögliche Parameterdatei aus? Was muss da drinstehen, damit etwas Sinnvolles passiert?
So sieht sie aus (nur drei Zeichen - noch kleiner geht's wirklich nicht.) :

Dadurch wird dem Programm gesagt: Gib den Inhalt von Feld #20 aus.
Das Ergebnis wäre (bei dem oben gezeigten Satz):

Mehr nicht. Die Grundidee der Exportparameter ist also sehr einfach, wir nennen sie mal Grundregel 0:

Minimum ist ein einziges Feld, siehe oben. Sollen nur Verfasser und Titel herauskommen, sähe die Liste so aus:

Und das hier käme heraus:

Denn man hat ja nicht gesagt, was zwischen den beiden Feldinhalten stehen soll - der Computer kann sich das nicht selber ausdenken, also schreibt er nichts dazwischen. Man muss zwar die Feldnummern als Liste untereinander schreiben, das ist die Grundregel, aber dadurch werden nicht automatisch zwei Ausgabezeilen gemacht. Das könnte man so veranlassen:

Tip zum Ausprobieren: Machen Sie sich schnell mal eine Datei  test.apr, in der die zwei Zeilen stehen und sonst nichts. Legen Sie diese Datei in den Ordner der Demo-Bank.
Dann starten Sie die Demo-Bank mit a99 und geben im Schreibfeld diesen FLEX-Befehl:  x exp p test.  Sofort wird test.apr geladen und für die Anzeige verwendet - Das Ergebnis wird sofort sichtbar. test.apr ist nun aktiv bis zum Ende der Sitzung oder zum nächsten Laden anderer Parameter.

Das C wirkt hier als Steuerzeichen und löst eine neue Zeile aus – und zwar vor der #20 und nur, wenn diese auch belegt ist. Dann sieht das Ergebnis so aus:

Damit haben wir zwei einleuchtende Grundregeln:

1. Nummern der gewünschten Felder untereinander schreiben

2. Ein C hinter die Feldnummer schreiben, wenn deren Inhalt auf eine neue Zeile soll

und damit kann man schon ziemlich weit kommen: man kann alle gewünschten Datenfelder in jeder gewünschten Reihenfolge ausgeben lassen.
Nochmal der Hinweis: wenn das betreffende Feld (oben die #20) nicht belegt ist, wird keine neue Zeile gemacht, d.h. die Anweisung  #20 C  wird ganz ignoriert.

Mit diesem Wissen kann man auch schon eine kompliziertere Parameterdatei einigermaßen verstehen: man findet darin nämlich immer eine Liste von Feldnummern, die jeweils auf eigener Zeile stehen und mit dem Zeichen # beginnen. So sieht immer der Hauptteil einer Parameterdatei aus.

Die nächste Grundregel, eine sehr wichtige und sehr einfache, ist diese:

3. Zeilen, die mit Leerzeichen anfangen, werden nicht verarbeitet.

Es ist damit ganz leicht, Kommentare in eine Parameterdatei zu schreiben: nur ein Leerzeichen an den Anfang der Zeile, oder zwei, und schon kümmert das Programm sich nicht darum. Sehr leicht kann man also auch Zeilen unwirksam machen, die man gerade nicht braucht, aber später vielleicht wieder. Schauen wir uns dieses Beispiel an:

Man erhält als Ausgabe:

denn die Zeile   #40 C  wird nicht verarbeitet, weil sie mit einem Leerzeichen beginnt.
Und noch eine wichtige, etwas überraschende Regel:

4. Stehen in einer Zeile zwei oder mehr Leerzeichen hintereinander, wird der Rest der Zeile nicht verarbeitet.

Dadurch kann man ganz leicht Kommentare in eine Befehlszeile hineinschreiben, nicht nur zwischen die Befehlszeilen. Wenn man also schriebe:

dann käme dasselbe heraus wie oben, denn vor den Bezeichnungen "Das ist der Titel" usw. steht jeweils mehr als ein Leerzeichen. An diese Regel muss man sich etwas gewöhnen, zugegeben: manchmal macht man aus Versehen zwei Leerzeichen und wundert sich, dass nicht das passiert, was man wollte.
Aber abschwächend kommt hinzu: Zwischen Anführungszeichen gilt diese Regel nicht. Warum? Das sehen wir gleich:

Nun weiter. Man will oft nicht nur die Feldinhalte exportieren, sondern noch gewisse Zusätze, z.B. so etwas:

Dann müsste man schreiben:

Dabei bedeutet z.B. die zweite Zeile: Nimm den Inhalt von #40, beginne aber zuerst eine neue Zeile und setze  Verf. :  an den Anfang.
(Ändern Sie Ihre Datei  test.apr  und geben Sie wieder den Befehl  x exp p test.)
Das kleine p ist ein Manipulationsbefehl, davon gibt es noch viele andere. Das p bedeutet "prefix" und bewirkt, dass eine Zeichenfolge VOR den Feldttext gesetzt wird, in diesem Fall eben "Verf. : "  Die Zeichenfolge muss hinter dem p innerhalb "..." stehen. Genauso gibt es ein "postfix", um etwas HINTER den Feldinhalt zu schreiben: dazu dient das große P.
Wenn Feld #40 nicht belegt ist, kommt statt dessen keine Leerzeile und auch  "Verf. : " erscheint nicht. 
Also: Manipulationsbefehle werden nur ausgeführt, wenn das betreffende Feld auch vorhanden ist. Sonst wird die gesamte Zeile nicht ausgeführt.
Nebenbei: Hinter "Jahr" stehen zwei Leerzeichen. Das macht aber nichts, denn zwischen Anführungszeichen hat das keine Wirkung, siehe oben.
Jetzt wird auch klar, warum in den Parametern jedes Feld auf eigener Zeile angegeben werden muss. Das liegt an dieser Regel:

5. Auf jedes Feld können beliebig viele Manipulationsbefehle angewendet werden, die den Feldtext verändern, bevor er ausgegeben wird.
   Die Befehle müssen neben der Feldnummer alle in derselben Zeile stehen und werden hintereinander von links nach rechts ausgeführt.
   Wenn das Feld nicht belegt ist, werden die Befehle nicht ausgeführt, es kommt sofort die nächste Zeile dran. 

Achtung: Zwischen zwei Manipulationsbefehlen, das ergibt sich aus Regel 4, muss genau ein Leerzeichen stehen. Sind es zwei oder mehr, entfällt der Rest. Daran muss man sich gewöhnen, deshalb wird's hier nochmal gesagt.

Jetzt erkennt man, dass komplizierter aussehende Befehle, wie z.B. dieser hier
#85 C b" ; " p"Bandnummer: " P"."
so schlimm gar nicht sind - man muss nur die Bedeutung der Manipulationsbefehle kennen. Und die kann man nachschlagen: Systemhandbuch, Kap. 10.2.6.3. (S. 194ff, Tabelle der M-Befehle)

Jetzt eine kleine Aufgabe: Was kommt bei unserem Beispiel-Datensatz heraus, wenn in den Parametern steht:

Richtig, das Ergebnis sieht so aus (Vor- und Nachname umgedreht):

Mit Kommentaren wird die Sache klarer:

Die nächste Grundregel ist auch wieder überraschend:

6. Statt mit # kann eine Befehlszeile auch mit ! anfangen. Der Unterschied zwischen beiden ist, dass zwei verschiedene Tabellen für die Umcodierung der Zeichen existieren können. Diese Tabellen werden definiert mit eigenen Befehlszeilen, die mit  p  anfangen für die #-Zeilen bzw. mit  q  für die !-Zeilen.

Mit den p- und q-Befehlen kann man jedem einzelnen Zeichen einen anderen Code zuordnen oder sogar eine ganze Zeichenfolge, die dann bei der Ausgabe automatisch statt des Zeichens ausgegeben wird.  Das sieht z.B. so aus:
p ä "ae"
Jedes ä wird dann automatisch durch ae ersetzt, aber nur in den mit # beginnenden Zeilen. Wenn es in den mit ! beginnenden Zeilen auch so sein soll, aber AE statt ae, muss man noch eine Zeile ergänzen:

Damit man nicht lange Listen solcher Befehle jedesmal in eine Parameterdatei mit hineinschreiben muss, kann man solche Listen auch in externen Dateien unterbringen und diese Dateien mit hinzuladen lassen. Dafür gibt es den Befehl t. Da wäre z.B. die Datei ad-utf.apt, sie enthält die Tabelle der Umcodierungen vom internen ASCII-Code in den Unicode-Standard UTF8. Wenn man in seine Exportparameter hineinschreibt:
tad-utf8
dann wird die Tabelle ad-utf.apt hinzugeladen und dadurch aktiviert.
Eine andere Standardtabelle ist  ad-aw.apt: sie wandelt den internen ASCII-Code in den Windows-Code um. Minimales Beispiel:

Titel und Verfasser werden dann in Windows-Codierung ausgegeben.
Wo muss so ein t-Befehl stehen? Das ist egal, denn er hat nichts mit einem bestimmten Feld zu tun – es sei denn, es stehen in der hinzuzunehmenden Datei nicht nur Codierungsbefehle, sondern auch Exportzeilen, die mit # oder ! beginnen. Es gilt Grundregel 7:

7. Eine Parameterdatei wird einmal geladen und beliebig oft ausgeführt.
   Nur die eigentlichen Exportbefehle, die mit # oder ! beginnenden Zeilen, müssen deshalb in der erwünschten Reihenfolge stehen, alle anderen Befehle können an beliebigen Stellen stehen. 

Für Programmierer: Nur die Zeilen mit # und ! werden wie ein Programm abgearbeitet, von oben nach unten also (es können aber Sprünge eingebaut werden), die anderen Zeilen werden nur beim Einlesen der Parameter verarbeitet (siehe Regel 7), um bestimmte interne Einstellungen vorzunehmen (d.h. Variablen zu belegen). Das Einlesen passiert nach Regel 7 nur einmal (und nicht immer wieder für jeden Datensatz), anschließend werden dann nur die Zeilen mit # und ! für jeden zu exportierenden Satz abgearbeitet, die anderen Zeilen nicht. Das hat zur Folge: wenn ein Basisparameter zweimal oder öfter angegeben ist, z.B. der Wert zl=..., dann wird nur der letzte wirksam. Im Handbuch finden Sie genaue Beschreibungen, wie ein Datensatz als Ganzes beim Export abgearbeitet wird (Kap. 10.2.6), und dann besonders, wie eine einzelne Befehlszeile ausgeführt wird (10.2.6.1). Wenn's mal komplizierter wird, können diese Beschreibungen sehr helfen...

Jetzt kommt die vorletzte Grundregel. Es gibt eine Anzahl von Basisparametern. Diese sind dafür da, bestimmte Werte zu setzen oder Schalter einzustellen, die das Verhalten des Exports beeinflussen. Da kommt einiges zusammen, aber meistens muss man nur wenige dieser Befehle geben. Denn:

8. Für jeden Basisparameter gibt es einen Standardwert, der automatisch genommen wird. Diese Default-Werte sind immer in sinnvoller Weise gewählt, damit man sie nicht jedesmal alle selber setzen muss. [Handbuch Kap. 10.1-5: die Basisparametern bilden 5 Gruppen und haben 2-buchstabige Namen, wobei jede Gruppe einen bestimmten Anfangsbuchstaben hat.]

Beispiel: Oft ist die Ausgabe eine Textdatei. Dabei macht das Programm dann einen automatischen Zeilenumbruch. Es muss dazu wissen, wieviele Zeichen maximal in eine Zeile sollen. Als Standard nimmt es 56 an - das war früher mal bei Katalogkarten sinnvoll. Wenn das Programm keinen Zeilenumbruch selber machen soll, weil das die nachfolgende Software übernimmt, etwa ein Textprogramm, dann setzt man
zl=0
Es ist nötig, an den Stellen, wo unbedingt eine neue Zeile beginnen soll, die dafür nötigen Codes selber einzubauen, z.B. die Codes 13 10 für eine TXT-Ausgabe, oder "<br>" für eine HTML-Ausgabe. Auch dafür gibt es einen Basisparameter:
ze="<br>"
Dieser Befehl würde immer dann die Zeichenfolge  <br>  ausgeben, wenn der Manipulationsbefehl  C  vorkommt.

Grundregel 9 ist vielleicht auch unerwartet:

9. Indexierung ist auch Export! Die Index-Einträge, die aus einem Datensatz hervorgehen, werden ebenfalls mithilfe der Exportsprache erzeugt. 

Elemente ohne Wenn und Aber
"Hmm," fragen Sie jetzt: "Wenn aber  Verf. :  herauskommen soll, und zwar auch dann, wenn #40 nicht belegt ist? Kann man keine Textelemente zwischen den Feldtexten ausgeben, und zwar immer, auch wenn die Felder nicht belegt sind? Die Manipulationsbefehle, so wurde ja gesagt, wirken nur dann, wenn die damit manipulierten Felder auch belegt sind."
Dafür gibt es den Text-Ausgabebefehl  #t{ ... } , wobei zwischen { ... } eine Steuerzeichenkette stehen muss: die kann aus beliebigem Text bestehen einschließlich Steuerzeichen, normaler Text immer zwischen "..." oder '...'.
Hier ein Beispiel
#t{ C "Schlagwörter:" C 9 }
Damit wird erreicht, dass an der betreffenden Stelle zuerst eine neue Zeile begonnen wird, dann "Schlagwörter:" hingeschrieben und dann nochmals eine neue Zeile, dann der Code 9 (= TAB-Zeichen). Man muss solche Befehle natürlich an den richtigen Stellen einfügen zwischen die normalen Ausgabezeilen, also zwischen die Zeilen mit # und !, damit das Gewünschte an der richtigen Stelle herauskommt. Aber Vorsicht: Was in solchen Zeilen steht, das wird nicht umcodiert (anders als die Datenfelder), sondern unverändert so ausgegeben, wie es dasteht. Bei Umlauten und anderen Sonderzeichen muss man darauf achten und ggfls. den richtigen Editor nehmen, um die Parameterdatei zu bearbeiten.

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-

Jetzt haben Sie die Grundlagen schon verstanden. Damit wird es Ihnen nun nicht schwerfallen, den Anfangsteil des Kapitels 10 zu lesen. Denn es gibt noch eine Menge andere Befehle, die alle ihren Sinn haben. Das Exportwesen ist ein weites Feld, daher kann es nicht simpel sein. Dazu gehört nicht zuletzt auch die Indexierung, wie wir nun gesehen haben. Denn auch die Registereinträge sind ja Dinge, die aus den Datensätzen heraus durch irgendwelche Umformungen entstehen, und diese Umformungen sind es, die man mit der Exportsprache machen kann.
Exportparameter sind sehr kompakt und deshalb wenig intuitiv. Sie arbeiten dafür aber extrem schnell, und das ist besonders für das Indexieren sehr wichtig. Mit XML und XSLT z.B. wären solche Leistungen nicht annähernd erreichbar.

Beispiele zum Ausprobieren
Als erstes etwas größeres Beispiel empfehlen wir eine Datei  d-simp.apr, die für eine einfache, katalogkartenähnliche Anzeige geeignet ist. Mit den Kenntnissen aus dieser Einführung und den darinstehenden Kommentaren werden Sie das meiste oder alles verstehen und dann sogar weiter ausbauen können. Sie können diese Parameter auf Ihre Platte kopieren und dann sogar sofort aktivieren, um zu sehen, was sie produzieren. (Um manuell zu aktivieren, im Schreibfeld eingeben: x disp p d-simp )
Als zweites Beispiel kommt die Protoyp-Datei für Bildschirmanzeige D-0.APR in Frage. Auch diese kann man sofort ausprobieren.

Rezept: Wenn man irgendeine Parameterdatei für die Anzeige ausprobieren will, dann im Menü „Anzeige“ mit dem Punkt „Anzeigeparameter wechseln“. Man wählt die gewünschte Datei dann aus der erscheinenden Liste aus, wobei man zwischen den Verzeichnissen auch umschalten kann: die Parameterdatei könnte im eigenen Datenverzeichnis, aber auch im Programmverzeichnis liegen.
Andere Methode: um die Datei xyz.apr auszuprobieren, dieses eingeben: x disp p xyz. Und dann ausgewählte Sätze anzeigen lassen, damit man die Wirkung sieht. Aber nicht bei jeder .APR-Datei kommt in der Anzeige etwas Gescheites heraus. (Dieselbe Testmethode geht beim DOS-PRESTO mit F2 F2 und dann Auswahl der Datei: + davorsetzen und Enter.)

Export ausprobieren
Um nun wirklich Daten in eine Datei zu exportieren, müssen die Exportparameter nicht für die Anzeige, sondern für den Export geladen werden. Das geschieht über das Menü "Export / Andere Exportparameter" oder per FLEX. Hier das Muster, wie man einen Export per FLEX vorbereitet und durchführt: (die roten Namen ersetzt man durch die der eigenen Dateien)

xport p d-simp        // Exportparameter d-simp.apr laden
open x ausgabe.txt    // Ausgabe soll in die Datei  ausgabe.txt
dow set               // Ergebnismenge ausgeben
close x               // Datei wieder schließen

Für das vertiefende Studium
Im Handbuch, Kap. 10.4, werden 10 Prototypen von Exportparameterdateien erwähnt, alle kommentiert, für unterschiedliche Aufgaben.

Hinweis: Viele Anwender arbeiten nur mit den Komfortmethoden des Exportmenüs. Fast alle diese Methoden benutzen irgendwelche Parameterdateien, ohne dass der Anwender es wissen muss, denn FLEX kümmert sich darum, sie im rechten Moment einzusetzen.

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-

Noch drei drängende Fragen werden Ihnen jetzt auf der Zunge liegen:

Wo müssen sich die Parameterdateien befinden?
Antwort: Auf dem Datenverzeichnis (wo die Datenbank liegt) oder auf dem Programmverzeichnis (wo a99.exe und die anderen Programme liegen).
Schlaumeier fragen sofort: Wenn es aber zwei verschiedene gibt mit demselben Namen, die eine hier und die andere dort? Dann wird immer die genommen, die auf dem Datenverzeichnis liegt. Vorteil: Parameter, die für mehrere Datenbanken gelten, brauchen nur einmal zu existieren, aber es kann immer noch für die eine oder andere Datenbank eine geänderte Version geben, und die muss dann auch bei der betr. Datenbank liegen - ist das nicht logisch?
Empfehlung: Wenn Sie eine der mitgelieferten Parameterdateien für Ihre Zwecke verändern (z.B. die D-WRTF.APR), dann kopieren Sie die veränderte auf Ihr Datenverzeichnis. So kann es bei einem Update nicht passieren, dass Ihre Privatversion wieder durch eine neue Standardversion überschrieben wird.  

Wie kann man sie bearbeiten?
Da es sich um ASCII-Dateien handelt, eignet sich Word nicht dafür. Am besten ist der mitgelieferte Texteditor X.EXE. Der ist sehr leicht zu benutzen, keinen anderen kann man schneller lernen, die wichtigsten Handgriffe lernt man in zwei Minuten. Er läuft unter allen Windows-Versionen, ist allerdings ein DOS-Programm, und wer gegen so etwas eine Aversion hat, kann WinVi nehmen, ein sehr gutes Freeware-Programm. Eine Alternative zu X ist auch der Microsoft-Editor edit.
Alternative im Windows-System: Man bearbeitet direkt im Anzeigefenster von a99. Geben Sie z.B. ein:  h i-1.apr . Dann sehen Sie die Datei i-1.apr, können sie bearbeiten und mit Alt+s  wieder speichern. Anderes Beispiel:  h d-w0.apr , die oben erwähnte einfache Anzeigeparameterdatei. Ändern, speichern (am besten unter anderem Namen), ausprobieren über Menü "Anzeige / Anzeigeparameter wechseln".

... und wie müssen sie heißen?
Die Namen darf man sich aussuchen, die Namenserweiterung (Dateityp) jedoch nicht. Sehr wichtig:
Kurze Namen: höchstens 8 Zeichen, nur Kleinbuchstaben, keine Leerzeichen, Umlaute oder andere Sonderzeichen
(Längere Namen funktionieren nur mit den Windows-Programmen.)
Der (verpflichtende) Dateityp (Namenserweiterung) ergibt sich aus zwei Dingen:

1. Die verwendete Konfigurationsdatei. Normalerweise ist das $A.CFG oder A.CFG. Der erste Buchstabe des Typs muss dann A sein. Wenn die Datenbank mit einer  N.CFG  arbeitet, muss es N  sein, usw.

2. Der Zweck der Parameter. Da gibt es drei Möglichkeiten:

PR Echter Export. Der Typ ist dann also  .APR

Beispiele: 
D-1.APR    : Die Standard-Anzeigeparameter für das DOS-Programm PRESTO
I-1.APR    : Damit kann man Daten im internen Format ausgeben lassen. Es entsteht eine sog. Grunddatei mit den richtigen Steuerzeichen. Man kann sie anschließend in eine andere Datenbank einspeisen (mit update.exe (s. Kap.9) oder index.exe (s. Kap.7))
D-WRTF.APR : Die Standard-Anzeigeparameter für das Windows-Programm a99

PT Nachlade-Tabelle, d.h. eine Datei, die mit t-Befehl in andere Parameter eingebunden wird. Der Typ ist dann .APT

Beispiele: 
I.APT      : Tabelle für die Umcodierung von Zeichen für das Indexieren (Einbindung in CAT.API)
SWL1.APT   : Tabelle mit Stoppwörtern für das Indexieren (Einbindung in CAT.API)
D.APT      : Tabelle für die Umcodierung DOS -> Windows (Einbindung z.B. in D-WRTF.APR)

PI Index-Parameter, d.h. die Vorschriften zur Bildung der Registereinträge. Der Typ dafür ist .API

Beispiel:
CAT.API    : Indexparameter für die Register des Standardsystems
Tip: Geben Sie F7 (in PRESTO oder a99), dann sehen Sie, was cat.api macht: Diese Parameter werden dann ausgeführt und man sieht als Ergebnis die Registereinträge, die zum aktuellen Datensatz gehören.

Achtung: Die Dateinamen sind hier mit Großbuchstaben geschrieben. Bei DOS und Windows ist das egal.  Bei Unix und Linux ist es nicht egal. Da ist es zwingend notwendig, sämtliche Namen, die mit allegro zu tun haben, immer und in jeder Situation vollständig klein zu schreiben. Nur so vermeidet man zeitraubenden Ärger mit nicht gefundenen Dateien... Vorsicht: Wenn man Dateien mit FTP oder Samba zwischen Win, Linux, Novell oder UNIX kopiert oder in Archivdateien packt, kann es passieren, dass die Namen mit Großbuchstaben ankommen oder abgeschnitten werden; dann muss man sie erst wieder korrekt umbenennen.
Der eigentliche Name, der Teil vor dem Punkt also, ist frei. Es wird empfohlen, sich dafür an ein paar Konventionen zu halten, die im Handbuch, Kap. 10.0 beschrieben sind. Damit behält man leichter den Überblick. Wir achten darauf, alle Standarddateien in Kleinbuchstaben auszuliefern sowie nur Namen mit maximal 8 Zeichen zu verwenden.