> It's odd that it worked > on releases prior to V5R3 though. Yes. V5R3 had a bunch of changes relating to CCSID 65535. In general, the old default of shipped systems was to use CCSID 65535 which means 'binary data -- do not ever translate this!' Many commands and applications had workarounds for this fact; Client Access has that 'translate 65535' check box, etc.
That is changing. Now, OS400 will no longer pretend that 65535 is 'probably 37.' It will honour 65535 as 'do not ever translate.' The memo to users explains this. http://publib.boulder.ibm.com/infocenter/iseries/v5r3/topic/rzaq9/rzaq9.pdf Don't try to follow the links in the Infocenter -- they're broken :-( 'CPYFRMIMPF and CPYTOIMPF command changes No conversion performed if TOFILE field has no CCSID or a 65535 CCSID In prior releases, the CPYFRMIMPF and CPYTOIMPF commands would create a temporary database file when copying a stream file to a database file. The temporary file was created with CCSID(*JOB). The temporary file was used as an intermediate file that the stream file was copied to before the import file text was processed and copied to the target database file. Any input stream file text was converted to the jobs CCSID when the stream file was copied to the temporary database file. If the target database file (TOFILE parameter) field did not have an explicit CCSID or had a CCSID of 65535, the copied import file text would remain in the jobs CCSID because it was already converted when the import file was copied to the intermediate, temporary database file. In V5R3, when the CPYFRMIMPF and CPYTOIMPF commands copy an import file from a stream file to a target database file, an intermediate database file is not used. If the TOFILE field does not have an explicit CCSID or has a CCSID of 65535, no text conversion will occur and the database file will contain the same hexadecimal code points that existed in the original stream file. If you need the text in the import file to be converted from the original CCSID, make sure that the TOFILE field CCSIDs are specified and are not 65535. For additional information on ways to handle CPYFRMIMPF and CPYTOIMPF command changes in V5R3, please refer to Informational APAR II13784. Record delimiter (RCDDLM) parameter change: RCDDLM(*ALL) will find the first occurrence of a single or double character combination of carriage-return and line-feed and use that value as the record delimiter. Character strings containing a null character (X'00') allowed only in binary fields: In previous releases, the CPYFRMIMPF and CPYTOIMPF commands treated character strings containing a null character (X'00') as acceptable values for any field. In V5R3, character strings containing a null character (X'00') are allowed only for binary type fields. Binary type fields are BINARY, VARBINARY, BLOB, CHAR FOR BIT DATA, or CHAR CCSID(65535). A null character (X'00') encountered in a non-binary field will produce a data mapping error.' Here is a link to the APAR: http://www-912.ibm.com/n_dir/nas4apar.NSF/1be1a5b61b213a6c86256c23007048f4/0cd39ad7f981e5bc86256e5400420e53?OpenDocument&Highlight=0,II13784 Check out PTF SI16247 for 5722SS1 Also, try creating this data area to get the V5R2 functionality back: CRTDTAARA DTAARA(QSYS/QCPTOIMPF) TYPE(*CHAR) LEN(6) VALUE('CPV5R2') --buck ------------------------ Yahoo! Groups Sponsor --------------------~--> Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/wbFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/Easy400Group/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
