Re: IFS to IFS...DDS to DDS -- MIDRANGE-L

Rick,

Instead of bringing the file to your 400 try to FTP it to your PC.  Any
Windows PC has an FTP client.  Go into an MS-DOS command line and run the
FTP command.  Do a get of the file to a .txt file on your pc.  Examine the
file on your PC to determine it's format.  You may need to transfer the file
in both Binary and ASCII modes and examine each.

If you transfer in binary and open the file and it's readable then it's
already in ASCII in their IFS directory.  If it's not readable then it's
likely in EBCDIC.  If it's in EBCDIC then you might need to do an ASCII
transfer to your PC to examine the format further.

The file might have comma or tab field separators or it might just be a raw
data dump of the file with no separators or formatting.  If the file has
comma or tab field separators you might need to copy the file to a work file
then use the CPYFRMIMPF to convert the file into your data file.

There is one possible problem.  If the file is in ASCII format on their IFS
from a raw data dump it could have problems.  If it contains any sort of odd
numeric (negative zoned, packed, binary, etc) then those fields were not
converted correctly.  The other end will have to fix the bungled data before
you can FTP it over.

Paul

-- 
Paul Morgan
Senior Programmer Analyst - Retail
J. Jill Group
100 Birch Pond Drive, PO Box 2009
Tilton, NH 03276-2009
Phone: (603) 266-2117
Fax:   (603) 266-2333
"CZE Midrange" <CZEMidrange@xxxxxxxxxx> wrote
in message
news:OFF0A053FD.5EA8D475-ON85256FBE.007BE345-85256FBE.007BE346@xxxxxxxxxxxxx
>
>
>
>
>
> File copied in binary  mode.
>
> -----midrange-l-bounces@xxxxxxxxxxxx
wrote: -----
>
>
> To: Midrange Systems Technical Discussion
<midrange-l@xxxxxxxxxxxx>
> From: Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>
> Sent by: midrange-l-bounces@xxxxxxxxxxxx
> Date: 03/08/2005 05:24PM
> Subject: Re: IFS to IFS...DDS to DDS
>
> > 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)
>
> 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)
>
> 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...
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email:
MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
>  Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
> -- 
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email:
MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>