Hallo,
ich muss oft viele Fixes von CA vom PC auf den MVS-Großrechner übertragen. Dabei kommen die Fixes zum Teil in ASCII, zum Teil in EBCDIC, z.B. QO12345.TXT oder QO23456.BIN. Sie sind also an der Endung eindeutig zu identifizieren. Nun möchte ich diese Fixes am Großrechner in eine PO-Datei übertragen. Dabei sind als Namen nur 8 Zeichen zulässig, also fällt die Erweiterung weg. Dies läßt sich im TC sehr einfach im Transferdialog mit "*" realisieren. Leider geht dabei die Möglichkeit des "Transfermodus Automatisch" verloren (alle Dateien werden binär übertragen, da Erweiterung=" "), der TC nimmt offensichtlich den Zieldateinamen und nicht den Quelldateinamen zur Identifizierung, war meiner Ansicht nach nicht sinnvoll ist. Läßt sich da was machen ?
Viele Grüße
Helmut
Bug: FTP Transfermodus Automatisch
Moderators: white, Hacker, Stefan2
Evtl in 2 portionen kopieren?
Erst alle *.bin auswählen und binär kopieren und dann alle txt und die als text.
Im Prinzip ist aber richtig, dass der TC die automatische erkennung anhand der Quelldateien vornehmen sollte. Finde ich.
sheepdog
Erst alle *.bin auswählen und binär kopieren und dann alle txt und die als text.
Im Prinzip ist aber richtig, dass der TC die automatische erkennung anhand der Quelldateien vornehmen sollte. Finde ich.
sheepdog
"A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete fools."
Douglas Adams
completely foolproof is to underestimate the ingenuity of complete fools."
Douglas Adams
-
SanskritFritz
- Power Member
- Posts: 3693
- Joined: 2003-07-24, 09:25 UTC
- Location: Budapest, Hungary
@waelder:
Alle *.txt-Dateien schon auf dem PC in EBCDIC konvertieren und dann alles in einem Aufwasch binär übertragen? Na gut, Sheepdogs Vorschlag ist da dann wohl doch um einiges effizienter
Nur mal aus Neugier: Hast Du noch keine trüben Erfahrungen gemacht, die Zeichensatzkonvertierung dem ftp zu überlassen? Wir haben hier Schnittstellenpartner, die in EBCDIC anliefern (ftp-Transfer UNIX -> zOS), deren Dateien vor Wirkeinsatz aber nochmals von einem Host-Job konvertiert werden müssen. ftp und Host (bzw. Zielanwendung) haben zu einigen "Sonderzeichen" unterschiedliche Auffassungen, wie diese zu codieren seien (Beispiel: "@"-Zeichen kommt nicht als solches an)... liegt wohl an unterschiedlichen "Codepages"...
Alle *.txt-Dateien schon auf dem PC in EBCDIC konvertieren und dann alles in einem Aufwasch binär übertragen? Na gut, Sheepdogs Vorschlag ist da dann wohl doch um einiges effizienter
Nur mal aus Neugier: Hast Du noch keine trüben Erfahrungen gemacht, die Zeichensatzkonvertierung dem ftp zu überlassen? Wir haben hier Schnittstellenpartner, die in EBCDIC anliefern (ftp-Transfer UNIX -> zOS), deren Dateien vor Wirkeinsatz aber nochmals von einem Host-Job konvertiert werden müssen. ftp und Host (bzw. Zielanwendung) haben zu einigen "Sonderzeichen" unterschiedliche Auffassungen, wie diese zu codieren seien (Beispiel: "@"-Zeichen kommt nicht als solches an)... liegt wohl an unterschiedlichen "Codepages"...
-
SanskritFritz
- Power Member
- Posts: 3693
- Joined: 2003-07-24, 09:25 UTC
- Location: Budapest, Hungary
@SanskritFritz:
Doch, doch, eine Zeichensatzkonvertierung findet statt... schickt man z.B. eine ASCII/ANSI-Datei vom PC per ftp im "Auto"- bzw. "Text"-Modus auf ein MVS-/OS390-/zOS-System, wird der Zeichensatz nach EBCDIC konvertiert und entsprechend umgekehrt. Wie dabei ausgehandelt wird, welche Seite wie konvertiert, ist mir leider nicht bekannt, wäre für einen ftp-Laien wie mich aber schon mal interessant...
Das Ende eines Datensatzes auf einem MVS-/OS390-/zOS-Host wird übrigens nicht durch <CR> / <LF> / <CR><LF> gekennzeichnet. Statt dessen haben die Sätze einer Datei entweder eine feste Länge (FB = fixed blocked) oder eine variable Länge (VB = variable blocked), bei denen die Infos zur Satzlänge in 4 "Verwaltungsbytes" je Datensatz enthalten sind. Schickt man eine PC-Datei zum Host, setzt ftp dies auch korrekt um. Umgekehrt ist's ein Problem, wenn man eine VB-Datei binär zum PC überträgt. Man hat dann keinerlei Anhaltspunkt, wo ein Datensatz endet und der nächste anfängt
. Holt man die Datei im "Text"-Modus, dann werden vom ftp korrekt Zeilenumbrüche eingefügt (handelt es sich um strukturierte Dateien mit gepackten Feldern usw., dann ist die Datei leider trotzdem für die Tonne, da die Infos der gepackten Felder in der empfangenen Datei nicht mehr rekonstruierbar sind... vom ftp "geschrottet")
@waelder:
Bitte verzeih' diese laienhafte Darstellung... ich bin kein Host-Profi.
EDIT: "Zeichensatz" ist bezüglich ASCII/ANSI/EBCDIC wohl nicht der richtige Begriff... "Zeichencodierung" trifft's besser
Doch, doch, eine Zeichensatzkonvertierung findet statt... schickt man z.B. eine ASCII/ANSI-Datei vom PC per ftp im "Auto"- bzw. "Text"-Modus auf ein MVS-/OS390-/zOS-System, wird der Zeichensatz nach EBCDIC konvertiert und entsprechend umgekehrt. Wie dabei ausgehandelt wird, welche Seite wie konvertiert, ist mir leider nicht bekannt, wäre für einen ftp-Laien wie mich aber schon mal interessant...
Das Ende eines Datensatzes auf einem MVS-/OS390-/zOS-Host wird übrigens nicht durch <CR> / <LF> / <CR><LF> gekennzeichnet. Statt dessen haben die Sätze einer Datei entweder eine feste Länge (FB = fixed blocked) oder eine variable Länge (VB = variable blocked), bei denen die Infos zur Satzlänge in 4 "Verwaltungsbytes" je Datensatz enthalten sind. Schickt man eine PC-Datei zum Host, setzt ftp dies auch korrekt um. Umgekehrt ist's ein Problem, wenn man eine VB-Datei binär zum PC überträgt. Man hat dann keinerlei Anhaltspunkt, wo ein Datensatz endet und der nächste anfängt
. Holt man die Datei im "Text"-Modus, dann werden vom ftp korrekt Zeilenumbrüche eingefügt (handelt es sich um strukturierte Dateien mit gepackten Feldern usw., dann ist die Datei leider trotzdem für die Tonne, da die Infos der gepackten Felder in der empfangenen Datei nicht mehr rekonstruierbar sind... vom ftp "geschrottet")@waelder:
Bitte verzeih' diese laienhafte Darstellung... ich bin kein Host-Profi.
EDIT: "Zeichensatz" ist bezüglich ASCII/ANSI/EBCDIC wohl nicht der richtige Begriff... "Zeichencodierung" trifft's besser
@Sheepdog
Genau so mache ich es. Ist aber ziemlich lästig, wenn man das öfter machen muss.
@SanskritFritz
Bei CA liegen die Dateien auf einem Unix-Server. Wenn ich von dort binär übertrage, erhalte ich alle Daten in 1 Zeile. Der Großrechner braucht dieselben Daten in 80 Zeichen langen Zeilen.
@van Dusen
Die "faienhafte Darstellung" ist völlig korrekt.
Zeichensatzprobleme sind unwahrscheinlich, da die *.txt Dateien rein alphanumerischen Inhalt haben (ZAPs).
@ghisler
Wird dieses Problem als "offizieller Bug" anerkannt?
Viele Grüße
Helmut
Genau so mache ich es. Ist aber ziemlich lästig, wenn man das öfter machen muss.
@SanskritFritz
Bei CA liegen die Dateien auf einem Unix-Server. Wenn ich von dort binär übertrage, erhalte ich alle Daten in 1 Zeile. Der Großrechner braucht dieselben Daten in 80 Zeichen langen Zeilen.
@van Dusen
Die "faienhafte Darstellung" ist völlig korrekt.
Zeichensatzprobleme sind unwahrscheinlich, da die *.txt Dateien rein alphanumerischen Inhalt haben (ZAPs).
@ghisler
Wird dieses Problem als "offizieller Bug" anerkannt?
Viele Grüße
Helmut
