Lesen Sie eine Cobol-Datei generiert

Ich bin derzeit am schreiben einer c# - Anwendung, die gehen, sitzen zwischen zwei vorhandenen apps. Ich weiß über die zweite Anwendung ist, dass es Prozesse, Dateien generiert, die von dem ersten. Die erste Anwendung ist geschrieben in Cobol.

Schritte:
1) Cobol-Anwendung schreibt einige Dateien und kopiert ein Verzeichnis.
2) Die zweite Anwendung nimmt sich diese Dateien auf und verarbeitet Sie.

Mein C# - app sitzen würde, zwischen 1) und 2). Es hätte abholen der erstellten Datei 1), Lesen Sie es, ändern Sie es und speichern Sie es, so dass die Anwendung 2)
weiß gar nicht, ich habe selbst dort gewesen.

Habe ich ein paar Probleme.

Erstens wenn ich eine Datei öffnen, generiert durch 1) im Editor, das meiste davon ist nicht lesbar, während andere Teile.
Wenn ich die Datei Lesen, ändern und speichern, ich muss speichern Sie die Datei mit der gleichen notation verwendet, die von der cobol-Anwendung, so dass app-2), der nicht weiß, Ive dort gewesen.

Ive versucht, Lesen Sie die Datei auf diese Weise, aber seine immer noch nicht lesbar:

Code:

        string ss = @"filename";

        using (FileStream fs = new FileStream(ss, FileMode.Open))
        {
            StreamReader sr = new StreamReader(fs);
            string gg = sr.ReadToEnd();
        }

Auch wenn ich finde einen Weg, um es lesbar (über irgendeine Art von encoding technique), ich fürchte, wenn ich die Datei erneut speichern, ich kann ändern Sie das ursprüngliche format.

Irgendwelche Gedanken? Vorschläge?

Sie müssen herausfinden, die Anbieter von COBOL -, dann finden Sie heraus, was das Datei-format ist. Es gibt keine einzelne "COBOL" - format.
Es wäre interessant zu wissen, welches format ist soll zu werden, ist es eine CSV ? Können Sie sprechen Sie mit dem Kerl, generieren Sie die Datei, um ihn zu Fragen, was die Datei enthalten sollte ?
COBOL ist älter als CSV.
Hoffentlich Passwörter und Kreditkarten-details. 🙂
Sehen Sie einige weitere Informationen [hier][1] [1]: stackoverflow.com/questions/5109302/...

InformationsquelleAutor rauland | 2011-02-02

c#cobol

27

Lesen Sie die COBOL-genned-Datei, die Sie brauchen, zu wissen:

Zuerst müssen Sie die record layout (Heft) für die Datei. Ein COBOL-Datensatz-layout wird in etwa so Aussehen:
```
01  PATIENT-TREATMENTS.
    05  PATIENT-NAME                PIC X(30).
    05  PATIENT-SS-NUMBER           PIC 9(9).
    05  NUMBER-OF-TREATMENTS        PIC 99 COMP-3.
    05  TREATMENT-HISTORY OCCURS 0 TO 50 TIMES
           DEPENDING ON NUMBER-OF-TREATMENTS
           INDEXED BY TREATMENT-POINTER.
        10  TREATMENT-DATE.
            15  TREATMENT-DAY        PIC 99.
            15  TREATMENT-MONTH      PIC 99.
            15  TREATMENT-YEAR       PIC 9(4).
        10  TREATING-PHYSICIAN       PIC X(30).
        10  TREATMENT-CODE           PIC 99.
```
Müssen Sie auch eine Kopie der IBM - Funktionsweise (S/360, S370, z/OS, ist eigentlich egal, für unsere Zwecke). Die Letzte von IBM verfügbar ist bei
- http://www-01.ibm.com/support/docview.wss?uid=isg2b9de5f05a9d57819852571c500428f9a (aber Sie benötigen einen IBM-account.
- Eine ältere edition ist verfügbar, gratis, im http://www.hack.org/mc/texts/principles-of-operation.pdf
Kapitel 8 (Dezimal Anweisungen) und 9 (Fließkomma-Überblick und Support-Anweisungen") sind die interessanten Teile für unsere Zwecke.

Ohne, dass Sie ziemlich viel verloren.

Dann, müssen Sie verstehen, COBOL-Datentypen. Zum Beispiel:
- PIC definiert eine alphameric formatierte Feld (PIC 9(4), beispielsweise 4 Ziffern, das könnte sein, gefüllt mit Leerzeichen, wenn Sie fehlt). Pic 999V99 5 Dezimalstellen, mit einer stillschweigenden dezimal-Punkt. So weiter und so fürdie.
- BINÄR ist [in der Regel] ein signed fixed point binary integer. Übliche Größen sind halfword (2 Bytes) und fullword (4 Oktetts).
- COMP-1 single precision floating point.
- COMP-2 ist double precision floating point.
Wenn die datasource ist ein IBM-mainframe -, COMP-1 und COMP-2 wird wahrscheinlich nicht sein IEE-Gleitkomma: es werden IBM base 16-überschuss 64 floating-point-format. Sie müssen so etwas wie die S/370 Principles of Operation, um Ihnen zu helfen, es zu verstehen.
- COMP-3 ist 'packed decimal', von unterschiedlicher Länge. Packed decimal-Format ist eine kompakte Form der Darstellung einer Dezimalzahl. Die Erklärung wird in etwa so Aussehen: PIC S9999V99 COMP-3. Dieser sagt, dass es signiert ist, besteht aus 6 Dezimalstellen, mit einer stillschweigenden dezimal-Punkt. Packed decimal stellt jede Dezimalziffer als knabbern, der ein Oktett (hex-Werte (0-9). Die hohe Ziffer für das Obere nibble der leftmost-Oktett. Das low-nibble des rechten Oktett ist ein hex-Wert A-F repräsentiert das Zeichen. Also die oben PIC - Klausel erfordert ceil( (6+1)/2 ) oder 4 Bytes. der Wert -345.67, vertreten durch die oben genannten PIC Klausel Aussehen wird 0x0034567D. Das eigentliche Zeichen der Wert abweichen (die Standardeinstellung ist C/positiv, D-negativ, aber A, C, E und F behandelt werden, als positiv, während nur B und D sind als negative behandelt). Wieder, finden Sie in der S\370 Principles of Operation für details auf die Darstellung.
Bezug auf COMP-3 ist gezont dezimal. Dies kann erklärt werden als "PIC S9999V99' (signiert, mit 5 Dezimalstellen, mit einer stillschweigenden dezimal-Punkt). Dezimalstellen, die in EBCDIC sind die hex-Werte 0xFO - 0xF9. 'Entpacken' (mainframe-Computer-Anweisung) nimmt einen packed decimal-Feld und verwandelt sich in ein character-Feld. Der Prozess ist:
- beginnen Sie mit der rechten Oktett. Umkehren, so dass die Zeichen nibble nach oben und legen Sie es in die ganz Rechte Byte des zielfelds.
- Arbeiten von rechts nach Links (Quelle und Ziel), entfernen Sie alle verbleibenden knabbern, der das packed decimal-Feld, und platzieren Sie es in das low-nibble des nächsten verfügbaren Oktetts im Ziel. Füllen Sie das high-nibble mit einem hex-F.
- Den Vorgang endet, wenn entweder die Quelle oder das Ziel-Feld ist erschöpft.
- Wenn das Ziel-Feld ist nicht erschöpft, wenn es Links aufgefüllt mit Nullen füllen Sie die restlichen Bytes mit den dezimalen '0' (oxF0).
Also unsere Beispiel-Wert, -345.67, wenn gespeichert mit dem Standard-Zeichen Wert (hex D), würde entpackt als 0xF0F0F0F3F4F5F6D7 ('0003456P', in EBDIC).

[Dort gehen Sie. Gibt es später ein quiz]
1. Wenn die COBOL-app lebt auf einem IBM-mainframe, auf dem sich die Datei umgewandelt wurde, aus seinem ursprünglichen EBCDIC nach ASCII? Wenn nicht, müssen Sie die Zuordnung Ihrer selbst (Tipp: es ist nicht unbedingt so einfach, wie das scheinen mag, denn dies könnte ein selektiver Prozess -- nur Zeichenketten umgewandelt (COMP-1, COMP-2, COMP 3 und BINÄRE ausgeschlossen werden, da Sie eine Folge von Binär-Byte). Schlimmer, es gibt mehrere Varianten von EBCDIC Darstellungen aufgrund der unterschiedlichen nationalen Umsetzung und der unterschiedlichen Druck-Ketten im Einsatz auf verschiedenen Druckern.
Oh...eine Letzte Sache. Die mainframe-hardware neigt dazu, wie verschiedene Dinge ausgerichtet halfword, word und doubleword-Grenzen, so dass der Datensatz-layout kann nicht direkt zuordnen, um die Bytes in der Datei, da kann es sein padding-Bytes eingefügt zwischen den Feldern zu erhalten, die benötigten word-alignment.

Glück.

Ich werde morgen wieder kommen und upvote - haben für heute. Ausgezeichnete Antwort. Sieht aus wie eine ziemlich gewaltige Aufgabe! 🙂
Es ist in der Regel nicht so schlimm wie es scheint. Die meisten COBOL-apps zu schreiben, die gerade Zeichen-format Datensätze. Sie selten sehen-floating-point in der wildnis, aber Sie könnte sehen, packed decimal-oder fixed point binary. Fixed point binary ist ein gerades 1:1-Zuordnung zu short oder int (außerhalb der big-/little-endian-Probleme). Packed decimal bisschen ein Aufwand, aber es ist nicht schlimm schreiben Sie eine Konvertierungs-routine konvertieren decimal.
-1 für nicht einschließlich ein Füllstoff in das Datensatz-layout 🙂
nicht mein Heft B^). Ich habe aus der mainframe-Welt für eine lange, lange Zeit, obwohl vor kurzem, ich habe zu gehen durch den Prozess der Erstellung ein Prozess periodisch zu importieren eines dump einer COBOL-Datei enthält eine Mischung aus text -, Binär und packed decimal-Daten und bringen Sie in das .Net/SQL-Server-Welt. Die Konvertierung von EBCDIC ist [meistens] ziemlich einfach, wie die .Net TextInfo unterstützt verschiedene EBCDIC-Codepages (037 und 500, für den Anfang). Hatte zu schreiben, einen packed decimal-to-decimal Konvertierungs-routine, und konvertieren Sie den festen Punkt, von big-endian zu little-endian. Einfach!
Wenn Sie angeben, SYNCHRONISIERT, die Mainframe-nichts tut für die Ausrichtung.

InformationsquelleAutor Nicholas Carey
2

Ich sehe aus den Kommentaren, die an Ihre Frage, die Sie sich mit den "klassischen" COBOL-batch-Datei-Struktur: Header-record, detail-Datensätze und trailer-record.

Dies ist wahrscheinlich eine schlechte Nachricht, wenn Sie sind verantwortlich für die Erstellung der trailer Rekord! Der typische "trailer" - Eintrag wird benutzt, um die end-of-Datei und ermöglicht die Kontrolle von Informationen, wie die Anzahl der Datensätze, die Ihr vorausgehen und verschiedene Prüfsummen-und/oder Gesamtergebnisse für die "detail" - Einträge. In anderen Worten, müssen Sie möglicherweise zu Lesen und zusammenzufassen, die die gesamte Datei, um den Anhänger. Hinzu kommt die Möglichkeit, dass ein Großteil der Daten in der Datei wird im Packed Decimal, Zoned Decimal-oder anderen COBOLish numerische Daten-Typen, Sie könnten eine harte Zeit.

Möchten Sie vielleicht zu Fragen, warum, den Sie hinzufügen, trailer Datensätze auf diese Dateien. In der Regel die "Anhänger" wird produziert von dem gleichen Programm oder eine Anwendung, die erstellt die "detail" - Einträge. Der Anhänger soll als eine Bestätigung, dass die sendende Anwendung/Programm schrieb alle Daten, die Sie gedacht war. Die Gesamtmengen der übersicht, zählt etc. verwendet werden von der empfangenden Anwendung, um zu überprüfen, dass die detail-Datensätze Stimmen überein mit den vorstehenden Angaben. Diese dienen soll, als eine weitere Bestätigung dafür, dass die sendende Anwendung nicht muff die Daten sichern, oder dass es nicht beschädigt wurde en-route (Nein, dass war kein Witz – aber vielleicht sollte es sein). Wenn ein "Mann in der Mitte" schafft der Trailer es Art von Niederlagen der ganze Zweck der übung (egal wie fehlerhaft es wurde möglicherweise mit zu beginnen).

+1 für mich daran erinnern, wie schlimm die Dinge geworden, wenn Insgesamt Felder überflutet, in dem trailer 🙂

InformationsquelleAutor
2
- Wäre es nützlich zu wissen, welchen Cobol-Dialekt, die Sie zu tun, weil es ist
  keine einzige Cobol-Format. Einige Cobol-Compiler (Micro-Focus) setzen Sie einen "Datei-Beschreibung" auf der Vorderseite-Dateien (Für Micro Focus VB /Indizierte Dateien).
- Haben Sie einen Blick auf die RecordEditor (http://record-editor.sourceforge.net/). Es hat eine Datei-Assistenten das könnte sehr nützlich sein für Sie.
  - In der Datei Wizard die Datei als Fixed-Width-Datei (am häufigsten in Cobol). Das Programm lässt Sie probieren verschiedene Record-Längen. Wenn Sie den richtigen Datensatz Länge der Textfelder sollte.
  - Letztere über den Assistenten gibt es Feld-Suche, die kann Blick für Binary, Comp-3, Text-Felder.
  - Gibt es einige Hinweise zur Verwendung des RecordEditor Wizard mit einer unbekannten Datei hier
    http://record-editor.sourceforge.net/Unkown.htm
- Es sei denn, die Datei kommt von einem Mainframe /AS400 ist es unwahrscheinlich, zu verwenden EBCDIC (cp037 - Codiert Seite 37 US EBCDIC), wird der text wahrscheinlich in Ascii.
- Die Datei enthält wahrscheinlich Packed-Decimal (Comp3) - und Binary-Integer-Daten. Die Meisten Cobols
  verwenden Big-Endian (für Comp-Ganzzahlen) auch auf Intel - (little-endian hardware).
- Einer Sache zu erinnern, mit Cobol PIC s9(6)V99 comp gespeichert ist, als eine Binäre ganze Zahl mit x'0001' Vertretung 0.01. So, es sei denn, Sie haben die Cobol-definition kann man nicht sagen, ob eine binäre 1 ist 1, 0.1, 0.01 usw.
InformationsquelleAutor Bruce Martin

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.