|
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. > >
As an Amazon Associate we earn from qualifying purchases.
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.