SAVF´s zippen

[Miles]

Guten Morgen zusammen,

ich habe ein kleines Problem bei meinem CL.

Ich zippe ein paar SAVF Files und es funktioniert leider nicht, es wird nur eine SAVF File gepackt.

Wenn ich es manuell laufen lasse dann funktioniert dies.
Manuell heißt das ich die SAVF als TXT dateien erstelle die genau so heißen aber ohne Inhalt.

Die Orginal SAVF Files liegen bei einer größe von mehr als 10 GB, könnte die Größe mein Problem sein? Das es nicht fertig gezippt wird?

"
STRQSH CMD('Jar -cfM /home/HVGMB/transfer.zip +
/home/HVGMB/test.SAVF +
/home/HVGMB/test1.SAVF +
/home/HVGMB/test2.SAVF +
/home/HVGMB/test3.SAVF') "

Danke euch.

[KingofKning]

Dann stell doch mal das Protokoll auf CL-Befehle protokollieren und schau mal in das Joblog was er Dir dazu sagt.

Gruß
Gregor

[Fuerchau]

Stimmt !
Das IFS ist normalerweise auf 2GB-Dateien beschränkt.
Nur per 64BIT-C-Funktionen können größere Objekte bearbeitet werden.
Die QSH-Befehle verwenden aber nur 32-Bit.

[Sven Schneider]

Das dürfte doch aber nicht auf jar aus der Java 1.5 64bit SDK zutreffen.

Bei der neuen 32bit java-Version könnte das anders aussehen.

Lediglich bei tail steht es explizit in der Doku :
http://publib.boulder.ibm.com/infoce...rzahz/tail.htm

[BenderD]

lass ihn doch mal mehr erzählen (verbose ist dein Freund)...
@Baldur: das sieht aber in der Reference anders aus, von 2GB finde ich da (s.a. Sven) wenig
http://publib.boulder.ibm.com/infoce...rzaaxfscmp.htm
@Sven: mit der 32 oder 64 Bit JVM dürfte das eigentlich nix zu tun haben. jar arbeitet mit InputStream und OutputStream und schiebt die Daten durch. Wenn das bei 2GB stirbt (was m.E. noch offen ist), dann ist das aus meiner Sicht kein Feature und wenn das Dateisystem die Ursache wäre, dann ist das ein Armutszeugnis (das konnte Windows doch im vorigen Jahrtausend schon besser.

D*B

Guten Morgen zusammen,

ich habe ein kleines Problem bei meinem CL.

Ich zippe ein paar SAVF Files und es funktioniert leider nicht, es wird nur eine SAVF File gepackt.

Wenn ich es manuell laufen lasse dann funktioniert dies.
Manuell heißt das ich die SAVF als TXT dateien erstelle die genau so heißen aber ohne Inhalt.

Die Orginal SAVF Files liegen bei einer größe von mehr als 10 GB, könnte die Größe mein Problem sein? Das es nicht fertig gezippt wird?

"
STRQSH CMD('Jar -cfM /home/HVGMB/transfer.zip +
/home/HVGMB/test.SAVF +
/home/HVGMB/test1.SAVF +
/home/HVGMB/test2.SAVF +
/home/HVGMB/test3.SAVF') "

Danke euch.

[Sven Schneider]

mit der 32 oder 64 Bit JVM dürfte das eigentlich nix zu tun haben. jar arbeitet mit InputStream und OutputStream und schiebt die Daten durch.

Stimmt jar arbeitet ja nicht unter der JVM sondern ist Bestandteil der Java SDK und als Shell Command ausgeprägt.
(genaugenommen sind fast alle Java SDK Commands Shell Scripte, welche auf ein C++ ILE Programm QJVATOOLS verweisen)
Eins ist mir trotzdem aufgefallen. Wenn ich manuell

QSYS/CALL PGM(QSYS/QJVATOOLS) PARM('jar' '-J-Djava.version=1.5')

auf der OS/400 Commando-Zeile aufrufe, wird trotzdem eine JVM gestartet. Wofür eigentlich?
Wenn ich den gleichen Aufruf unter QSH mit

system QSYS/CALL PGM(QSYS/QJVATOOLS) PARM('jar' '-J-Djava.version=1.5')

mache, wird keine JVM gestartet.

Die Frage ist also benutzen die Java SDK Shell-Commands bzw. PGM QJVATOOLS die 64bit file API's ? (also z.B. statt write --> write64)
Hierzu konnte ich nichts in der IBM Doku finden.

Vielleicht liefert ja doch :

jar ...-v ...

hier mehr Info's.

[Fuerchau]

Leider gibts das Limit doch:
http://publib.boulder.ibm.com/infoce...ampfilesys.htm

Maximum size of a document2 GB - 1
Maximum file size that can be read or written using the iSeries™ Access File Server4 GB

[Pikachu]

Aber Dokumente liegen im DLS. Hier geht's vermutlich eher um Datenstromdateien (stream files).

[Fuerchau]

Stimmt, habe ich inzwischen auch entdeckt.
Streams können max. 1TB werden.

Allerdings stellt sich immer noch die Frage, ob das 32-Bit-Java auch die 64-Bit-API's verwendet.

Im Gegensatz zu Windows, die eine eigene 32-Bit-Funktion für Dateien > 2GB haben (neben den 64-Bit-Funktionen), kennt die AS400 nur 32- oder 64-Bit-Dateifunktionen.

[BenderD]

ad Java: die Java Sprachdefinition ist Plattform unabhängig und fordert klar:
- ein FileInputStream hat eine Methode skip(long l) zu haben
- long hat 64 Bit zu haben
ergo: Java muss 64 Bit können, sonst ist es kein Java und ein FileInputStream hat ca. 2TB zu können!
BTW: wäre ja ein Scherz, wenn ausgerechnet die JVM der AIX weniger können soll als die JVM des OS/400; i ist in Bezug auf Java Spielzeug im Vergleich mit p!

Eine ganz andere Sache ist es dann, wenn ein FileSystem nicht Java tauglich ist, im QDLS gilt für einen FileInputStream freilich die Limitierung von 2 GB, wenn er auf Platte soll.

Noch eine andere Sache könnte sein, was beim originären Frager und warum nicht klappt.

mfg

Dieter Bender

Stimmt, habe ich inzwischen auch entdeckt.
Streams können max. 1TB werden.

Allerdings stellt sich immer noch die Frage, ob das 32-Bit-Java auch die 64-Bit-API's verwendet.

Im Gegensatz zu Windows, die eine eigene 32-Bit-Funktion für Dateien > 2GB haben (neben den 64-Bit-Funktionen), kennt die AS400 nur 32- oder 64-Bit-Dateifunktionen.