Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

RPG - Moving whole records

1,124 views
Skip to first unread message

jlie...@gmail.com

unread,
Mar 15, 2007, 9:26:09 PM3/15/07
to
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.

So, I want to do one MOVEL(P) to move the entire record. RPG won't
let me use the record format name of the externally described file as
the from field of a MOVE.

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).

Any help out there,
Thanks in advance,
JLiesner

Ken Sims

unread,
Mar 15, 2007, 11:21:15 PM3/15/07
to
Hi -

On 15 Mar 2007 18:26:09 -0700, jlie...@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.

jlie...@gmail.com

unread,
Mar 15, 2007, 11:33:36 PM3/15/07
to

That's a big help. Thank you,
Jack

Chris Pando

unread,
Mar 16, 2007, 5:13:33 PM3/16/07
to
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!

Barbara Morris

unread,
Mar 16, 2007, 6:51:42 PM3/16/07
to
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

Kaj Julius

unread,
Mar 21, 2007, 8:36:51 AM3/21/07
to
-- 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.

CRPence

unread,
Apr 5, 2007, 1:44:43 AM4/5/07
to
.
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.

0 new messages