AS400 SAVLIB format

[boborama]

I have what appears to be a SAVLIB from an AS400 that I need "data" from. Our AS400 seems incompatible with the format (media isn't the problem). I've been following what little I know about SAVLIB - 528 byte blocks (512 + RRN + checksum) and I can move from one L/D OBJECT DESCRIPTOR to the next using the Records To Next field in the descriptor. In several instances that offset into the file places me "short" of the next descriptor. Perhaps at another 240 byte record of some kind " QRY" - does anybody here have more detailed info on SAVLIB formats? Perhaps the valid "TYPES" 0x19db, 0x0b90, 0x0c90 etc?

Any help would be appreciated.

 

[MdnghtPgmr]

You should be able to just use the RSTLIB command. Are you unable to restore using that command?

 

[jmanj]

SAVLIB is an AS400 command to save Library into a media devices such as tape. Depending on how you saved the library, you can use RSTLIB to restore the Library into disk. If your purpose is to get a file from the Library and restore it, then use RSTOBJ.

 

[boborama]

Yes it's very strange.. I actually received a Bzip of a TAR archive burned onto CD. After decompressing the Bzip file...I found the TAR archive to contain a single huge file - why you would TAR a single file I'm clueless. The single file "appears" to be some sort of SAVLIB - I've moved that file to an AS400 but it doesn't seem to know what it is...can't RSTLIB...can't RSTOBJ -- tried to "view" info about the File - system says it's unknown. Ultimately... I want to restore select "objects?" (files to me) and then FTP them to a Unix system to utilize the fixed length data therein. So...why not just build a Unix RSTLIB/RSTOBJ function.. sounds like fun right? -- I know - AS400's and Unix don't get along too well. I've been able to build a basic "Table of Contents" display on Unix by moving from one Descriptor to the next (yes...even though the first object seems to contain a information about the objects saved) So...I'm trying to write a program that mimics RSTLIB/RSTOBJ - but it would really help if I had more detailed info about how these things are nomally coded. The format of this thing is so similar to my usual SAVLIBs (I've examined some that I can read on my AS400) that I can navigate this raw data with my program and very minor modifications. So please...If there is a technical reference guide online somewhere that describes the "organization" of a SAVLIB please tell me where I might find it. I can deal with the EBCDIC thing and floating point / packed binaries etc - that's no problem. I hope the thing isn't a proprietary IBM crowd - can only be read by one particular OS trade secret.

 

[flapeyre]

Before you try anything else, first ask the person who gave you the CD what version/release of OS/400 they have. They can create a save file that can go back two release levels. If you are more than two release levels behind his, you will not be able to restore the save file that he created.

In that case,you might do better just to have him create ASCII files (using the CPYTOIMPF command) for you to import, rather than a save file. More CD's but less hassle than save files.

Me transmitte sursum, Caledoni!

 

[boborama]

I can try to find out what version of OS/400 he has...but his system is running a "software package" such that he probably has little interface to the actual OS. He probably chooses a "backup" menu function of some sort. Since you bring up release levels, what if he is more than two levels behind me? - Are newer OS's always backward compatible? I've heard there are SAVLIB dfferences for CISC versus RISC processor based machines - perhaps this could be an issue as well? My AS400 is software (and storage) deprived. Just the basic OS - so restoring files is tedious without being able to "script" the process. Media could add problems some day too. I have access to a dozen (or more) different tape drives - but only one on the AS400. Thus the ability to restore files in Unix would be a tremendous time saver and limit the amount of "work" required of the non-tech savy end users. Hey -- I really do appreciate everyone's timely response THANKS!

 

[jmd0252]

If he is using a CISC machine,, you have a huge problem. Seems like the last release of the CISC OS400,, was like 3.2. While UNIX and the OS400, are similar under the hodd,, you are not going to get from one to the other, very easily.

 

[Mercury2]

Maybe the huge file burned on the CD could have been zipped to fit the CD size ? It could it be a SAVF created on the AS400 and burnt onto the PC burner.
Just try to FTP (BIN) and DSPSAVF to the AS400 after decompressing the Bzip file.
Pls let us know.

 

[jmanj]

My hunch is that the file was sent to IFS using either CPYTOIMPF or CPYTOSTMF commands then zipped, tarred and ftped to the local disk and copied to cd. Try reversing the process.

 

[boborama]

That's basically the first thing I tried... The CD contained the Bzip file, which was undoubtedly done so the 700+ MB would fit on a CD. The un-zipped file was a TAR - I have no idea why since the archive only cointained a single file. After expanding the 1-file archive I found a file which appeared to be an AS400 save. I assume the save was created and ftp'ed to a Unix/Linux system for "backup" by compressing and burning to disk as I had received. So I reversed the process but was unable to restore or display anything from that file with the 400. Perhaps this will help: In the "L/D OBJECT DESCRIPTOR" things - the number of blocks to next is supposed to be at offset 0xcc but it seems to be at offset 0x44 - other pieces look "correct" the QSRDSSPC.1 descriptors have a type of 0x19db just like they are supposed to - and the "L/D ..." text is right at offset 0x92 ...just like it ought to be. The data probably isn't an import file since there are no sensible delimiters between fields etc. It most definitely could be a STREAM -- but a stream of what? Should be a stream of a SAVF...but my 400 can't read it...and the format doesn't appear quite right (when compared to a binary inspection of my normal SAVF files and what little documentation I have on SAVF format). So I am starting with what I can do. Using one of my nomal and readable SAVF's I'm trying to design a program to replicate the AS400 restore process...then adaptation to this unknown but very similar format should be much easier.

 

[Mercury2]

When reversing the process, have you ftp'ed the file with BINARY option to a previously created AS400 SAVF ?

 

[boborama]

Yes...I did use the binary option in ftp. I'll probably give this another try - just in case "something went wrong" - but it really doesn't invalidate my desire to bypass the AS400 entirely. I have nothing against the machine... It's just that the "files" are going to be ftp'ed to a Unix box once restored anyway. My AS400 is a glorified file loader. It's a tough problem isn't it? I mean nobody hides the format of a TAR or CPIO or ZIP file etc. Lot's of tools to extract from those. But SAVF??? Oh...nooooo - you can only read that on a 400. The format? IBM could tell us...but then they'd have to kill us.

 

[Mercury2]

We can just guess, that's all.