RE: CPYFRMSTMF & character conversion

There records have CRLF delimiters, it's the data itself that doesn't. Typically I use CPYFRMIMPF to import comma, or TAB, separated data. These text files have no separators.

Your link doesn't work for me in Chrome, FF or IE.
This link: http://www-01.ibm.com/support/docview.wss?uid=nas8N1015514
Becomes this address: https://www.ibm.com/;www-01.ibm.com/support/docview.wss?uid=nas8N1015514



-----Original Message-----
From: Peter Dow [mailto:petercdow@xxxxxxxxx]
Sent: Wednesday, February 14, 2018 4:02 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: CPYFRMSTMF & character conversion

Hi Justin,

When you say "fixed-width", are you implying that there is no record delimiter (e.g. CrLf )?

A FLDDFNFILE is pretty simple (see
http://www-01.ibm.com/support/docview.wss?uid=nas8N1015514) -- you can use a source member for it.  As an example if you have 3 fields in the target file, named Fld1 (numeric 10.0), Fld2 (alpha 3) and Fld3 (alpha 5), and your fixed-width stream file has 2 of them, the field definition file would look like

Fld1 1 10 0
Fld3 11 15 0
*END

That's field name, start position, end position, and null character value.

Of course, if you have a lot of fields, it could get tedious.

--
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
petercdow@xxxxxxxxx <mailto:petercdow@xxxxxxxxx> pdow@xxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxx> /


On 2/13/2018 2:36 PM, Justin Taylor wrote:

You are correct, there are other French characters as well.

I'm confused by your responses. I assume this is because I didn't state the problem clearly, so let me try again.

We have an existing process that takes a fixed-width text file in the QNTC file system and uses CPYFRMSTMF to import it into a flat PF. The problem that came up is with French characters in the text file. Flat PF's must have CCSID of 65535, which prevents CCSID conversion. Externally-described PF's can have other CCSID values, but they're incompatible with CPYFRMSTMF. CPYFRMIMPF requires a FLDDFNFILE when copying fixed-width data, and I don't have one.


I have a fix deployed, using the IFS API's. I'm willing to continue this discussion, or drop it. I will defer to you.

Thanks



-----Original Message-----
From: Jon Paris [mailto:jon.paris@xxxxxxxxxxxxxx]
Sent: Tuesday, February 13, 2018 4:15 PM
To: Midrange-L Midrange-l <midrange-l@xxxxxxxxxxxx>
Subject: Re: CPYFRMSTMF & character conversion

But that requires translation!

I guess if you are certain that it is the only character that this will happen with you could always do a scan and replace on the string in the PF. But if you have an É in the source file there's likely to be other characters as well.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Feb 13, 2018, at 4:53 PM, Justin Taylor <JUSTIN@xxxxxxxxxxxxx> wrote:

This character needs to stay as-is:
É

Not become:
Ã■