Re: code page/CCSID for CPY***IMPF and STMF

>From the CCSID help:
Note:  A file created with no DDS when FILETYPE(*DATA) is 
specified has a CCSID of 65535, regardless of the job CCSID
value. 

Why would it care?  I don't know.  Technically you could have a different 
CCSID on each field (I think).  Maybe because that's rather hard to 
implement on this kind of file?  You and I would assume the CCSID of the 
file.

Now... how did we work around that?  Let me think...

If it makes you vomit, I hear you.
CRTPF FILE(ROB/MYFILE) RCDLEN(10)
upddta rob/myfile
CPYTOIMPF FROMFILE(ROB/MYFILE) 
          TOSTMF('/rob/xyz.txt')
          STMFCODPAG(*PCASCII) 
          RCDDLM(*CRLF) 
Looks like excrement to me.
rmvlnk '/rob/xyz.txt'
CPYTOSTMF FROMMBR('/qsys.lib/rob.lib/myfile.file/myfile.mbr'
                  ) 
          TOSTMF('/rob/xyz.txt') 
          CVTDTA(*AUTO) 
          DBFCCSID(*FILE) 
          STMFCODPAG(*PCASCII) 
dspf '/rob/xyz.txt'
doesn't look bad.  Since it's a program described file I think we stopped 
using CPYTOIMPF and used CPYTOSTMF.  What advantage is there to CPYTOIMPF 
on a program described file?

Some more data from the help you might want to look at:
Specify the CCSID to be used.  More information about CCSIDs is
in the Globalization topic in the iSeries Information Center at
http://www.ibm.com/eserver/iseries/infocenter. 


Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





rick baird <rick.baird@xxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
02/08/2005 03:23 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: code page/CCSID for CPY***IMPF and STMF






Rob,

On Tue, 8 Feb 2005 14:51:00 -0500, rob@xxxxxxxxx <rob@xxxxxxxxx> wrote:

> That ain't going to work.
> 
> We did a CHGSYSVAL QCCSID to 37.

ooh.
 
> Try a CHGJOB CCSID(37) then your steps (including deleting the file and
> the CRTPF) again to test.  If successful, then figure out a time to do 
the
> CHGSYSVAL QCCSID and make the leap.  Really didn't cause any issues. 
He!!

You don't sound all that confident.  ;)

This is interesting:  I did a CRTPF CCSID(37) without changing my job,
and it told me that "CCSID 37 not allowed with file type *DATA".   Why
would it care?

I then changed my job to CCSID(37) and did the same thing, same
message.  not specifying the CCSID let me create the file, but the
resulting object had a CCSID of 65535.   Is this expected behaviour?

> I think I did it midday.
>
> This is the long term solution.  You will hear of all sorts of 
workarounds
> and temporary fixes like the data area (which will be removed in a 
future
> release).  However IBM is giving a hard push to getting off of 65535 and
> picking a different CCSID.

I agree, but I hate flying blind here.

Where can I learn a little more about code pages and CCSID?  I didn't
find infocenter very helpful.

thanks,

Rick

> Rob Berendt
> --
> Group Dekko Services, LLC
> Dept 01.073
> PO Box 2000
> Dock 108
> 6928N 400E
> Kendallville, IN 46755
> http://www.dekko.com
> 
> rick baird <rick.baird@xxxxxxxxx>
> Sent by: midrange-l-bounces@xxxxxxxxxxxx
> 02/08/2005 02:09 PM
> Please respond to
> Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> 
> To
> Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> cc
> 
> Subject
> Re: code page/CCSID for CPY***IMPF and STMF
> 
> 
> Rob,
> 
> >>When you try to copy the file back to the IFS, what are you copying
> from?
> 
> flat physical file - CRTPF RCDLEN(80) CCSID(*JOB)
> user CCSID is *sysval
> sysval for CCSID is 65535
> 
> >>What is the CCSID and/or code page of that file?
> 
> 65535
> 
> The original file received from the bank is a stream file - CCSID 37.
> I get the file via FTP.
> 
> Thanks,
> 
> Rick
> 
> >
> > Rob Berendt
> > --
> > Group Dekko Services, LLC
> > Dept 01.073
> > PO Box 2000
> > Dock 108
> > 6928N 400E
> > Kendallville, IN 46755
> > http://www.dekko.com
> >
> > rick baird <rick.baird@xxxxxxxxx>
> > Sent by: midrange-l-bounces@xxxxxxxxxxxx
> > 02/08/2005 01:30 PM
> > Please respond to
> > Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> >
> > To
> > Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> > cc
> >
> > Subject
> > code page/CCSID for CPY***IMPF and STMF
> >
> >
> > Can someone point me to a clear and concise document that explains
> > code page - CCSID topics and how to effectively use them when
> > transfering files of various CCSIDs from physicals to stream files
> > using the CPY***IMPF or STMF commands?
> >
> > Ever since upgrading to V5R3, a ton of my CPYFRMIMPF and CPYTOIMPF
> > commands have broken.   I know about the PTFs, and the data area to go
> > back to V5R2 versions of the commands, but some things are still are
> > just not working right anymore, and I'm ticked off about.
> >
> > in one case, i have a flat file from the bank, and it has a leading
> blank.
> >
> > I do a cpyfrmimpf to a flat PF, using RMVBLANK(*NONE) but it still
> > trims the first blank of the first record before stopping the trim.
> >
> > When I recieve the file from the bank, it's indeciferable when opened
> > in notepad, but copies up to the iseries just fine (except for the
> > blank described above).  But I can't copy the same file back to the
> > IFS.   I used to be able to do a CPYTOIMPF STMFCODPAG(*PCASCII) and I
> > could get an ascii readable stream file no matter the code page of the
> > source file - not any more.
> >
> > I've done a work around for the trim, but if they fix it in a
> > subsequent PTF, it'll break again.
> >
> > Thanks in advance,
> > --
> > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> > list
> > To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> > or email: MIDRANGE-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/midrange-l.
> >
> > --
> > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> > To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> > or email: MIDRANGE-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/midrange-l.
> >
> >
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
> 
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
> 
>
-- 
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.