× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




Our partner "dropped" the DDS off in one of their IFS directories for us to
retrieve and bring back to our 400...it was NOT in their qsys.lib but
rather some random directory/folder.

This is a little difficult to answer, since I don't know what's been done to the file. All I know is that it was once a DDS-based physical file on their iSeries. It would be more helpful to know what the file is *now* than what it used to be!


Do you know if it's a comma-delimited file now? or tab delimited? Or a flat text file? Or did they just take the binary data from the file and copy it from one place to another?

Do you know the exact command that they used to copy the file?


Once we received the file, our goal was to get the data into one of our 400
libraries (qsys.lib) so we could examine the information accordingly. When
we tried a GET from our partners box to a library in OUR Qsys.lib
directory, the file transferrred in gobble-de-gook when we did a simple
runqry command to view it.

The "gobbledy-gook" is likely some result of EBCDIC to ASCII translation.

And even if it worked, how would the system have "remembered the DDS" file positions...as this file is most definetly not meant to be transferred in a "flat record" format (1 long field).

You can transfer a PF in "one long field" format without any problems so long as you do it in binary mode throughout, and save it back to a new file with the exact same format.


So how can we retrieve a DDS-field delimited file from a non Qsys.lib IFS
directory and restore it on our box and into a standard library within
qsys.lib with the DDS definitions in tact?

If you really want to preserve everything about the file, though, you should get the business partner to create a SAVF (save file.) They can put that in their IFS for you to download. Assuming the data has been properly copied with something that does not alter anything (for example, FTP in binary mode) you should be able to restore the SAVF and get a file that's identical (verbatim) to the one on their system -- file description and all.


They create the save file like this:

CRTSAVF FILE(mylib/mysavf)
SAVOBJ OBJ(TheFile) LIB(TheLib) DEV(*SAVF) SAVF(mylib/mysavf)

Then they can use FTP to put it into the IFS:

FTP RMTSYS(localhost)
<userid & password>
ftp> namefmt 1
ftp> cd /ifsdir
ftp> binary
ftp> get /qsys.lib/mylib.lib/mysavf.file /ifsdir/myfile.savf
ftp> quit

Then you can get it from their system via FTP:

FTP RMTSYS(theirsystem)
<userid & password>
ftp> namefmt 1
ftp> cd /ifsdir
ftp> binary
ftp> get myfile.savf /qsys.lib/mylib.lib/mysavf.savf
ftp> quit

Then you can restore the actual file with the RSTOBJ command. The result should be an identical file, just as it would be if you had restored a backup from tape...



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.