Hi -

On 15 Mar 2007 18:26:09 -0700, jliesner@gmail.com wrote:

>I sure don't want to have to describe all the fields in a data
>structure, and then move them one by one to the data structure (so I
>can then WRITE the program described file from the data structure).

If the field names in the data structure have the same names as the
fields in the externally described file you don't have to do any
moves.

If you're using RPG IV you can create the data structure from the same
record format as the externally described file using E DS and EXTNAME
so you don't have to describe the fields in the data structure.

--
Ken
http://www.kensims.net/
Opinions expressed are my own and do not necessarily represent the views
of my employer or anyone in their right mind.

That's a big help. Thank you,
Jack

On Mar 15, 8:26 pm, jlies...@gmail.com wrote:
> I can't believe I've never run into this before in RPG, but....
>
> We are selecting records from an Externally Described file, and then
> writing those records to a programmed Described file, and then FTPing
> the program described file (not allowed to FTP an externally described
> file) off into the ether somewhere.

.... snip ...

If you can describe your selection criteria in a CPYF, then
create a physical file the same length as the externally
described file and CPYF ... FMTOPT(*NOCHK).

HTH,

Chris
--
www.brilligware.com
Home of MineSweeper5250!

Ken Sims wrote:
>
> If you're using RPG IV you can create the data structure from the same
> record format as the externally described file using E DS and EXTNAME
> so you don't have to describe the fields in the data structure.
>

That was possible in RPG III, too.

FMYFILE IF E DISK
IRECDS E DSMYFILE

-- snip
>and then FTPing
> the program described file (not allowed to FTP an externally described
> file) off into the ether somewhere.

Are you sure about this restriction? I know this is true for CPYTOSTMF but
to the best of my knowledge, FTP has no qualms about using externally
described files.

..
FTP transfers data, records, either binary or text. Database files
may not be all text, such that translation/conversion of text is
problematic. Databases typically provide export into a known text
encoding and format [e.g. .csv form] and then corresponding import
facilities to take the pure text and convert the text 'records' into
rows, in the internal form required in the target database.
FTP on System i may provide some limited [maybe even robust; maybe
only using BINary? I've not reviewed any doc describing] support for
ability to transfer a database file between like System i5 setups, but I
have never wasted my time with the assumption that every request will
function as intended; there are plenty of examples I've seen where it
will not work; e.g. especially with DBCS encoding where a 0x0F in a
packed decimal is also a shift character. The data may transfer without
errors due to a sufficiently correct record transport, yet the target
file may appear incorrect as a database row until the problem is well
investigated. Or the data transfer may issue errors for which the
origin may not be obvious until the actual data and database field types
are well investigated.

Regards, Chuck
-- All comments provided "as is" with no warranties of any kind whatsoever.

Kaj Julius wrote:
> -- snip
>> and then FTPing
>> the program described file (not allowed to FTP an externally described
>> file) off into the ether somewhere.
>
> Are you sure about this restriction? I know this is true for CPYTOSTMF but
> to the best of my knowledge, FTP has no qualms about using externally
> described files.