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



Hi Dave,

> Using Scott Klement's tutorial on "Working with IFS in RPG", I have
> written (using the term "written" loosely) a program to read a PC file
> (a text file in csv style format - Sample of data:
> "392033962","P","150","","","","","","","220.56750","0","-37380","0","0","03102004)
> from a software package.

Okay, so this file is being created by a PC application, and you're
reading it in an RPG program, right?


> The RPGIV program scans the data for ,"- and rearranges the data so
> that the negative sign is after the number.  (When I changed this using
> Word Pad, CPYFRMSTMF then correctly interpreted the number and copied to
> our iSeries file.)

Okay, now I'm confused.  If you're just reading the file, how are you
changing it?!  Obviously you're not just reading it... :)


> I have set up the open so that, I think, CCSID 00819 will be used for ASCII.
>     c                   eval      outfile = open('/QDLS/ANZCHKS/AZPCFile':
>      c                                  O_TRUNC + O_CREAT + O_WRONLY
>      c                                   +O_CODEPAGE:
>      c                                  S_IRWXU + S_IRWXG +S_IRWXO :
>      c                                   819)

Now I'm even more confused.  You would not be able to read ANYTHING from a
file opened with this statement, as O_TRUNC on a stream file is like
CLRPFM on a PF -- it empties the file.

Not to mention the fact that you've specified O_WRONLY ("Write only")

Okay, I'm going to just forget your previous statement that you're reading
the file and assume that you're writing the file ;)


> However, my problem now is that the CCSID seems to be incorrect.  The
> CPYFRMSTMF command gives this error (edited for space)
[SNIP]
> I am sure that there is an error on my part somewhere but I cannot
> figure out what it is.

The problem (which you doubtless already know) is that the data is written
to the file as EBCDIC, but you've marked the file with an 819 codepage.

What you need to understand is that the O_CODEPAGE flag tells the API that
you'll be passing a codepage as an optional parameter to the API.  It does
NOT specify that the data be translated to or from that codepage.

When you specify the O_CREAT flag and the file needs to be created, the
system will use that codepage as the codepage number that's assigned to
the new stream file.

This is the tricky part: When you specify the O_TEXTDATA flag, then the
system uses the codepage to indicate the OUTPUT of the read() command, and
the INPUT of the write() command.  In other words, it's the codepage of
the data in your RPG program, rather than the codepage of the data on the
file itself.

If you look at the ASCII text example in the tutorial, you'll see that it
opens the file twice.  The first time it creates it and assigns it a
codepage.  The second time, it does NOT specify a code page (but rather,
uses teh default codepage of your job) and specifies O_TEXTDATA.  This
way, the data will be converted from your job's codepage to the file's
codepage automatically.

Here's the sample program I'm referring to:
http://www.scottklement.com/rpg/ifs_ebook/ch5ascii.html

Starting in V5R2, they added a new flag, O_TEXT_CREAT that allows you to
both create the file and start the translation process in one open.  I
wrote an article about that for the Club Tech iSeries Programming Tips
newsletter, which you can read at the following link if you have a
professional membership to the iSeries Network:
http://www.iseriesnetwork.com/clubtech/index.cfm?fuseaction=ShowNewsletterIssue&ID=17806


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.