Re: RPG File Input/Output Specs

[Stuart Rowe <rowestu@xxxxxxxxx>]

If you're reading from and writing to files with structures, do not use the
E (externally described) in the F-spec.  This is what causes the compiler to
generate the I and O specs.  You do not need either one really.  If you need
no particular conversion CPYF might do it for you -- I'm rarely so lucky...

Declare the files with F (program described) and a record length.  Leave off
the "rename" keyword as there will be no record formats defined.  The record
length should match the size of the respective structures.  Declare your
structures with qualified extname(filename) versus likerec(recname).  The
structures will end up defined the same and your code will be the same (read
into structure, write from structure) but you move the structure members
yourself.

Trick: If you absolutely need keyed OldFile, declare the key on the F-spec
with any old key position -- then if whatever file you open has a keyed
access path, it will use that access path regardless of what you put on the
F-spec.  As long as you're just reading and not chaining by partial keys or
anything, this trick works pretty well.

It's old-school, but works every time.

    FOldFile   IF   F  reclen     Disk    ExtFile( ConvertFrom ) UsrOpn
    FNewFile   O    F  reclen     Disk    ExtFile( ConvertTo ) UsrOpn

    D ds_New          DS                  qualified extname( ConvertFrom )
    D ds_Old          DS                  qualified extname( ConvertTo )

     /free

      // Prepare library list and open your files here

      read OldFile ds_Old;

      dow not %eof( OldFile );

        ds_New.Field1 = ds_Old.field1 + 64 + ds_Old.field2; // or whatever
you need to do
        etc...

        write NewFile ds_New;
        read OldFile ds_Old;
      enddo;

or something like that.

Stu



On Wed, Aug 11, 2010 at 15:16, Kurt Anderson
<kurt.anderson@xxxxxxxxxxxxxx>wrote:

> I've been writing some data conversion programs which read in an Old File
> and outputs to a New File.  Many of the field names are the same, although
> with different definitions.  I'm reading into a DS and outputting through a
> DS.  For example:
>
>     FOldFile   IF   E           K Disk    Rename( FileF: OldFileF )
>     F                                     ExtFile( ConvertFrom ) UsrOpn
>     FNewFile   O    E             Disk    Rename( FileF: NewFileF )
>     F                                     ExtFile( ConvertTo ) UsrOpn
>
>     D ds_New          DS                  LikeRec( NewFileF: *output )
>     D ds_Old          DS                  LikeRec( OldFileF: *input )
>
>         Read CvtCdrMstP ds_Old;
>         Write CdrMstF ds_New;
>
>
> That works fine.  It creates =I specs for OldFile, but no =O specs for
> NewFile, so there is no field conflict.
>
> But once I introduce a procedure into the program, it creates the =O specs
> for NewFile, which then causes a conflict because some fields share names
> between the files, but do not share the same definitions.
>
> Is there a reason for this?  All I know to do is to change the procedure to
> be a subroutine (shudder) and continue on my way.
>
> I was going to create a quick tiny version of this program to test with,
> but of course my WDSCi crapped out (well, hung up for about 3-5 minutes, so
> I had to force close it, resulting in some JVM error, now I'm going to
> reboot to get my memory back and I'm waiting for 15 Windows updates to
> apply...)
>
> I'm on v5r4.
>
> Thanks,
> Kurt
> --
> This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.