Reading the content of a SAVFILE on a Windows machine
TheOrbix
Is there a way (for instance with a utility program) to access the
content of a SAVFILE from a Windows machine?
I have received from one of my customers a SAVFILE generated from an
AS/400, and I'm trying to read the file content from a custom
application developed on Windows.
I don't know the AS/400 operating system, and as far as I have
understood by googling around, it seems that save files use a
proprietary format and are only used for backup/restore (or data
interchange) purposes on AS/400 systems.
If this is true... are there any third party utilities that can be
used to open and display (and maybe manipulate) the content of a save
file on Windows?
jonathan bailey
news:42e6e3f1-2783-4a92...@d27g2000yqf.googlegroups.com...
It is true, a save file or SAVF is such a format. I think I saw mention of a
pc
program which can read this format on this newsgroup. Use Google groups to
search for it. You are most likely better off asking for the data
re-presenting as say
a csv file. Iseries access also offers ODBC & several other programming
interfaces
for pc users, such as a .net database access object, which might be more
convenient.
--
Jonathan
TheOrbix
> "TheOrbix" <dario.orbec...@libero.it> wrote in message
Thanks Jonathan,
After writing the post I actually found another post that was
describing a small utility program for Windows, called ViewSavF
(downloadable from www.juliansoft.com), that allows to open, display
and export information stored in a SAVF file.
I still haven't tested it, but if it works well it could be a viable
way of extracting information from this type of AS/400 files.
Grim
> and export information stored in a SAVF file.
>
> I still haven't tested it, but if it works well it could be a viable
> way of extracting information from this type of AS/400 files.
What is it you and your customer are trying to do? Save files are use
to save, restore and Transfer ISeries objects. You are not going to
retrieve any information form those objects on anything except another
ISeries machine. Why is your customer even sending you a save file
and not a CSV or Tab Delimited file. There are much better ways to
send data.
CRPence
FWiW what is referred to as the "AS/400" is more likely instead,
an iSeries or System i, maybe even from a Power System with IBM i.
And the OS running on an AS/400 is the OS/400.
Consider that if the application were running under i5/OS, would
the application like to have the file data from the Win system, or
would the application want what was created by the Win BACKUP
utility? Probably the data, not a backup. So...
Presumably what is desired on the Windows application is
non-compacted, non-compressed, "record data". Probably then, either
data originating as rows of a SQL TABLE, or text stream [optionally
delimited as records, or less likely the binary stream] data from
/files/ on the AS/400. Thus what was sent, the save file, is
probably not desirable; that an alternate means of getting the data
should be pursued. One alternative is ODBC to get the row data
directly, another is to export the row data as text stream data
first and then use some network protocol [file transfer, file
system, etc.] to either send, retrieve, or access the stream data.
The "save file" is an alternate manner to make a /backup/ onto
the disks, as compared to normally making a backup onto other more
transportable [e.g. magnetic] media. Having made a backup to the
disks, the ability then exists to transport elsewhere the data of
the save file [in binary mode; i.e. not via a text-mode transport],
and\or to save the data to some other media [e.g. to tape] as though
the save had originally been done directly onto that media using the
first SAVxxx request [accomplished using the CL command SAVSAVFDTA].
The format of the data in the save file is specific to the backup
feature; i.e. in that sense, "proprietary". In this case, the
backup features of SAVLIB & SAVOBJ [or various other command or API
requests], are part of the OS rather than a vendor product.
Actual data [versus objects & data] can be /backed up/ in other
ways that are not going to be in the proprietary "save format", but
the /objects/ of the OS [an object-based system] must be saved as a
backup as part of the SAVxxx features whenever the SAVF *FILE object
is the target of the save\backup request; i.e. the /objects/ are
something only the OS will understand. For example the CL command
CPYTOTAP can copy database records from a SQL TABLE, onto a
"standard label" tape which can then be read on any system [possibly
requiring conversion from EBCDIC however] which can read *SL tapes.
Although a follow-up post suggests a feature had been found to
view the contents of the save file [possibly more than that], being
able to see what are the contents of the backup is not the same as
being able to access the objects or the data associated with those
objects; even less likely for the ability to change the objects or
their data, and still less ability to then restore back to a system
with OS/400, i5/OS, or the IBM i OS.
Regards, Chuck
Peter H. Coffin
> What is it you and your customer are trying to do? Save files are use
> to save, restore and Transfer ISeries objects. You are not going to
> retrieve any information form those objects on anything except another
> ISeries machine. Why is your customer even sending you a save file
> and not a CSV or Tab Delimited file. There are much better ways to
> send data.
Usually this kind of thing happens when someone that's not very
knowlegable about the i5 starts rummaging around for "something like a
zip file".
--
I think it's a beautiful day to go to the zoo and feed the ducks.
To the lions.
-- Brian Kantor
TheOrbix
> to save, restore and Transfer ISeries objects. You are not going to
> retrieve any information form those objects on anything except another
> ISeries machine. Why is your customer even sending you a save file
> and not a CSV or Tab Delimited file. There are much better ways to
> send data.
Yes, I agree with you. Having a CSV or Tab Delimited file would be
much better, but for some reasons this customer (it's a German
company) does not want to do this, and has asked me if I can work
using their save file.
Probably they don't like the extra effort of extracting the
information from their system and reformatting it in CSV format, so
they're hoping that I can open and read the content of the save file
on Windows.
What I need to do - ideally - is to extract the information from the
save file and import it in a custom application written in Visual
Basic used to process the data.
Clearly I don't have a direct access to the customer's server, so
there is no way to perform remote ODBC queries from the VB
application.
I think I will try to see how the Windows utility mentioned above, or
this other Java tool I found in another newsgroup:
http://www.anerty.net/software/file/jSAVF/.
In parallel, I'll try to convince the customer to export the data in
the good, old CSV format. Little more work for him, much less work for
me... :-)
TheOrbix
I fully understand that the save file format has been designed for
backup/purpose (or data interchange) on OS/400 systems, and that other
file formats would be much easier to deal with (for instance a CSV
file, or another a textual export format).
Unfortunately my customer prefers to export the information from his
system in the save file format (probably he does not like the extra
effort to generate a CSV output) and has asked if I could directly
extract the information from the save file and import it in the Visual
Basic custom application we use at work.
I have now found this freeware tool: http://www.anerty.net/software/file/jSAVF/
I have just downloaded the Java version of the tool and I've been able
to open the save file and dump its content in a TXT file. Next step
will be parsing the TXT file and importing it in the VB program...
fairly easy to do.
Grim
I found it very hard to believe any customer would send data to
another party via save files, when that the party doesn't have an
ISeries or have access to one . If this is indeed the case then you
should inform that customer that the data is useless and get it in a
format that can actually be used. I may be wrong but that utility you
downloaded looks like all its going to do is list what's in the save
file and not actually retrieve data.
When ever I see questions or situations like these posted, my first
thought is that this is a crude hacking attempt.
CRPence
A "TXT" file... That's funny. Hardly "text", since the contents
of the SAVxxx is implicitly, binary data.
Although possibly just too lazy to learn to do something perhaps
new to them and at least more appropriate, IMO more likely that the
expression "There is no cure for stupid" better describes their
situation.
The customer has to perform at least two operations regardless of
what they do to get the file to you. Currently they perform
something like the following three steps: 1. CRTSAVF 2. SAVOBJ 3.
FTP PUT binary stream The customer could just as easily perform the
following two steps: 1. CPYTOIMPF 2. FTP PUT text stream. The first
step in the latter example is a database file export; e.g. to a CSV
text stream.
There is simply no excuse for having anyone write an application
to interpret a proprietary data format when most utilities\tools
will both provide and support "common" [often for lack of
/standard/] data formats.
Regards, Chuck
Suarez
>
>In parallel, I'll try to convince the customer to export the data in
>the good, old CSV format. Little more work for him, much less work for
>me... :-)
Not at all, if they are willing to send you a savf they should be
doing:
Step1 SAVOBJ (the command issued to fill the savf)
Step2 directly ftp the savf to your server or first import on their
machine and then
Step3 send it to you via email.
To create a csv they must issue a simple system command
Step1 CPYTOIMPF
Step2 directly ftp the file to you or attach it to an email from the
ifs
It's the same amount of job (at least shorter creating to csv file)