Savf kopieren

[Joe]

Hallo Forum.


Ich muss eine sehr grosse SAVF von einer fremden AS400 auf mein System holen. Ein SNDNETF per SDLC Verbindung dauert zu lange. Die SAvf auf CD brennen geht nicht, weil ich vom PC
keinen Zugriff auf die AS400 habe. Ausnahme: Filetransfer mit
BOSANOVA. Der liest aber nur PF'S.

ALso meine Idee:
1. SAVF mit RPG-PGM in 528byte lange PF schreiben.
2. Diese PF auf den Client ziehen und auf CD brennen.
3. PF auf AS400 wieder in SAVF ausgeben und auspacken.

Pkt. 1 und 2 ist ok.

Und jetzt die Frage: Wie kann ich die Daten der PF wieder in eine SAVF ausgeben, damit diese auf der AS400 ausgepackt wird?
RPG bringt CPF5175.Code 1


Gruss Joe

[Fuerchau]

Statt RPG solltest du FTP auf der AS/400 verwenden.
"FTP LOOPBACK" startet FTP mit dem eigenen System.
Dann kannst du ganz einfach zwischen PF und SAVF kopieren.

Achtung: mit Binärmodus !

[Joe]

Dank für die schnelle Antwort.

Kapiert hab' ich das leider nicht.

Ist LOopback die AS400 oder ein FTP Unterbefehl?

Und wie schiebe ich dann die "gepackte" PF in eine SAVEFILE

Gruss Joe

[TARASIK]

Hallo Joe,
hier eine Hilfestellung:

Tricks and techniques for FTPing OS/400 save files

Joe Hertvik
23 Jan 2002, Rating 4.00 (out of 5)
Save files (SAVF) are great for transferring iSeries and AS/400 objects between OS/400-based machines. Whether it's a group PTF, a file, a library or even a licensed program, save files can quickly zip large amounts of information between two AS/400s, especially if the save files are transmitted via FTP.
Unfortunately, there's a little bit of misunderstanding about how to properly FTP save files between two AS/400s. There are a few simple, but hard-fast, rules that users must follow to successfully transfer save files. To that end, here's my formula for FTPing save files between iSeries and AS/400 machines.
1. Binary is best. -- For speed and accuracy, always choose Binary mode (TYPE I, or Image) FTP transfers between your AS/400s. Binary mode is specified by using the BIN FTP subcommand in your FTP session, as follows:
BIN
For more recent OS/400 versions, FTP may force you to use binary mode before it will transfer a save file.
Binary mode is called an Image transfer for good reason. Binary transfers mean that OS/400 FTP will create an exact mirror image of your save file on your target machine. The file is transferred bit-by-bit, and it is reassembled on the receiving machine exactly as it looks on the sending machine, with no EBCDIC translation performed. Incidentally, this also helps speed up your FTP transfer.
2. FTP sometimes creates your target save files correctly. -- This is where most people trying to FTP save files get tripped up: through mistakes caused by not understanding how FTP automatically creates save files on the target machine. There are two ways to insure that your save file is correctly created on your target machine, and the method you choose is dependent on how you specify the NAMEFMT parameter in your FTP session.
If you use NAMEFMT 0 in your FTP transfer -- where OS/400 libraries and objects are defined in a library/filename format -- the save file must already be present on your target system before the transfer begins, and it must also be identified to OS/400 as a save file. If the target save file isn't present, OS/400 will not transfer the file correctly and it will probably create a physical file, not a save file, to hold the results of your transfer. For NAMEFMT 0 transfers, you can use the Create Save File (Create Save File) command as follows to create the receiving save file on your target machine before the FTP session begins:
CRTSAVF FILE(TECHTARGET/FILENAME) TEXT('Save file for target machine')
Alternatively, an FTP client session can also create a save file on the target machine by using the FTP Remote Command sub-command (RCMD), which executes an OS/400 command on a remote machine. Here's an example of how you could create the same save file on a remote FTP host by using the RCMD command inside your session:
QUOTE RCMD CRTSAVF FILE(TECHTARGET/JOE) TEXT('Save file for target machine')
If you have the proper authority, any command that follows the 'QUOTE RCMD' string will be executed on the host AS/400 as if it were typed in on a command line. This is handy for executing almost any OS/400 command from inside an FTP session.
For FTP sessions that are run under NAMEFMT 1 -- where OS/400 file names are defined in the Integrated File System (IFS) format -- FTP will automatically create your save file correctly on the target machine when you fulfill two conditions: 1. You must use the IFS naming convention for your save file on your GET, MGET, PUT or MPUT sub-commands. 2. You must specify a .SAVF extension for the file being transferred. Here's what a simple PUT command would look like when transferring a save file in a NAMEFMT 1 FTP session:
PUT /QSYS.LIB/HERTVIK.LIB/JOE.SAVF /QSYS.LIB/TECHTARGET.LIB/JOE.SAVF
Because you specified the file as a save file (.SAVF), FTP will properly create the save file on your target machine -- if it's not already present -- using the target name specified in your PUT statement. Using PUT (or MPUT) in a NAMEFMT 1 session this way bypasses the need to create a new save file on your target system before the save is started.
3. An empty target save file is a beautiful thing. -- For transferring save files, an existing target save file must also be empty for the transfer to succeed. That means the file must either be newly created (through the CRTSAVF command or PUT technique as shown above) or you must clear the target save file before starting the transfer. You clear the target file by using the Clear Save File (CLRSAVF) command before the transfer begins, as follows:
CLRSAVF FILE(TECHTARGET/JOE)
Or you can execute this command inside your FTP session by, again, using the FTP RCMD sub-command:
QUOTE RCMD CLRSAVF FILE(TECHTARGET/JOE)
Either of those techniques will allow the target save file to be cleared, which will make for a successful transfer.
Given these rules, here's two FTP scripts that show how you would transfer the same save file from one AS/400 to another using either the NAMEFMT 0 or NAMEFMT 1 file naming conventions.
For a NAMEFMT 0 FTP transfer, a typical FTP save file transfer might use these commands:
NAMEFMT 0
BIN
QUOTE RCMD CRTSAVF FILE(TECHTARGET/JOE) TEXT('Save file for target machine')
QUOTE RCMD CLRSAVF FILE(TECHTARGET/JOE)
PUT HERTVIK/JOE TECHTARGET/JOE
QUIT
In this case, you may decide not to use both the CRTSAVF and CLRSAVF commands together, but I put them in this session sample for illustration.
For a NAMEFMT 1 FTP transfer, a typical FTP save file transfer might use these commands:
NAMEFMT 1
BIN
PUT /QSYS.LIB/HERTVIK.LIB/JOE.SAVF /QSYS.LIB/TECHTARGET.LIB/JOE.SAVF
QUIT
You could also execute the CLRSAVF command through QUOTE RCMD if the save file already exists on your target and it needs to be cleared before the transfer. Using a NAMEFMT 1 transfer makes it easier to create save files on your target system, but you have to code your GET, MGET, PUT and MPUT commands to proper specify file names in the IFS naming convention.
As you can see, transferring save files between AS/400s isn't that bad once you understand the rules. If you play around with the simple rules and techniques I discussed here, you'll be successfully FTPing save files between your AS/400 machines in no time.
Gruss TARASIK

[Fuerchau]

@TARASIK

eine hervoragende Beschreibung

[Joe]

Hallo Forum.

Nochmals vielen Dank für die ausführliche Beschreibung zu FTP.
Leider habe ich versäumt zu erwähnen, dass ich FTP nicht benutzen kann(darf).

Deshalb RPG und folgend der RPG Code.

Im ersten Schritt ist Infile eine Savefile. Diese wird in Outfile ausgegeben.
Im zweiten Schritt(also kopieren der Outfile zurück in die SAVF)
kommt der Fehler CPF5175. Falscher Datzensatz für Ausgabevorgang an Sicherungsdatei. Bedingungscode 1.

************************************************** * * Savf/Datei lesen und in Datei/Savf ausgeben
* ************************************************** **
FInFile IP F 528 DISK
FOutFile O F 528 DISK
IInFile nf
I 1 528 DATEN
OOutFile D
O Daten 528



Was läuft da falsch?

Joe

[rmittag]

REXX wird ( ganz zu Unrecht ) oft übersehen ist aber hier der wohl einfachste Weg :

'OVRDBF FILE(STDIN) TOFILE(YOURLIB/YOURPF)'
'OVRDBF FILE(STDOUT) TOFILE(YOURLIB/YOURSAVF)'
DO FOREVER
 PARSE LINEIN inputrecord
 IF inputrecord == '' THEN LEAVE
 SAY inputrecord
END
EXIT

[Fuerchau]

Schau dir die Beschreibung von CPF5175 an. Dies deutet ganz darauf hin, dass deine Quelldatei keine SAVF-Inhalte hat.

Dein PGM ist in Ordnung.
Am besten testest du es mit eine kleinen eigenen SAVF die du mit deinem Programm von einer SAVF in PF und wieder zurückkopierst.

Der weitere Grund könnte sein, dass deine Quelle von einem höheren Release stammt. In diesem Fall kannst du sowieso nichts machen als den SAV auf dem Quellsystem passend zum Zielsystem zu wiederholen (TGTRLS).