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



I don't think the kludge will work in V5R4...IBM has a PTF that seems to
fix the CCSID problem...and the truncation is 'working as designed'. The
PTFs are SI18900 and SI18637. The truncation APAR is SE17667...here's
the text...

PROBLEM SUMMARY:                                                 
..                                                               
 The output of CPYTOIMPF for a fixed length character field       
 export, using delimited output without any string delimiter,     
 no longer truncates the character data for the last field       
 as it did in past releases.  Note: This of course, applies to   
 a single field file; where the last field is the first and       
 only field.  kwd: STRDLM(*NONE)                                 
.                                                                 
 The same was found to occur also, for a varying length           
 character field where data in the database was not already       
 properly trimmed; i.e. where SELECT LENGTH(FieldName) shows     
 that there are blank pad characters beyond the last non-blank   
 character that are included in that length.                     
.                                                                 
                                                                  
                                                                  
                                                                  
                                                                  
                                                                  
                                                                  
PROBLEM CONCLUSION:                                               
See COMMENTS:                                                     
                                                                  
                                                                  
TEMPORARY FIX:                                                   
                                                                  
COMMENTS:                                                         
..                                                               
 The feature had never trimmed blanks except on the               
 last field for the noted scenario.  The outcome now,             
 although different, is still valid.  The result is               
 now also more consistent, since the last field will             
 now be padded, just as all of the preceding fixed-               
 length character fields in that export request.                 
.                                                                 
 The current output is a side effect of a r530 fix               
 for *FIXED format data.  For a *FIXED export, the               
 the last field will now remain correctly padded                 
 to the defined maximum length, just as all of its               
 preceding fields have always been.  That correction             
 to the export allows any import features to avoid               
 the accidental treatment of the EOR characters as               
 part of the fixed data.  And for delimited export               
 as given, the last field is now generated the same               
 as the preceding fields; thus the result for the                 
 last field is consistent with the other fields.                 
.                                                                 
 There is no specific intent to change the delimited             
 export behaviour, since it is both sufficiently                 
 correct and even more consistent than in the past.               
 However, possible consideration will be made to add             
 in a future release, the ability to request to trim             
 the data on an export <like the RMVBLANK parameter               
 on the import>.  And that would apply to all fields             
 rather than just the last.                                       
.                                                                 
 This is one of the changes resulting from the                   
 mentioned rewrite of the import/export db copy                   
 features in the r530 MTU.                           

> -------- Original Message --------
> Subject: CPYTOIMPF/CPYFRMIMPF was RE: [WDSCI-L] RE: 5.1.2.5 vs 6.0
> co-existence and 5.2.1.5 removal
> From: rob@xxxxxxxxx
> Date: Fri, August 26, 2005 12:22 pm
> To: Websphere Development Studio Client for iSeries
> <wdsci-l@xxxxxxxxxxxx>
> 
> Getting rather off list, but truncation was not the only issue with 
> CPYTOIMPF/CPYFRMIMPF.  Another was this nasty CCSID conversion that 
> started changing all of our data to meaningless characters.
> 
> Rob Berendt
> -- 
> Group Dekko Services, LLC
> Dept 01.073
> PO Box 2000
> Dock 108
> 6928N 400E
> Kendallville, IN 46755
> http://www.dekko.com
> 
> 
> 
> 
> 
> "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx> 
> Sent by: wdsci-l-bounces@xxxxxxxxxxxx
> 08/25/2005 09:11 PM
> Please respond to
> Websphere Development Studio Client for iSeries <wdsci-l@xxxxxxxxxxxx>
> 
> 
> To
> "'Websphere Development Studio Client for iSeries'" <wdsci-l@xxxxxxxxxxxx>
> cc
> 
> Subject
> RE: [WDSCI-L] RE: 5.1.2.5 vs 6.0 co-existence and 5.2.1.5 removal
> 
> 
> 
> 
> 
> 
> Okee dokee.  While I am not trivializing the lack of backward
> compatibility here, I would like to point out that the situation was a
> pretty tough act to follow.
> 
> 1. You found an iSeries command that gave you the results you needed to
> send a file to a rigidly designed third party program.
> 
> 2. IBM changed the command so that it no longer matched the third party
> program.
> 
> 3. There existed at least two solutions to work around the change in the
> command (use a VARCHAR, or trim the file after generating it).
> 
> 4. Another command existed that gave you the desired results.
> 
> All in all I'm thinking the iSeries did pretty well despite the lack of
> backward compatibility.
> 
> Personally, I'd still have liked to see an option that would allow the
> command to work like it used to; the lack thereof is to my mind a rather
> serious flaw in IBM's decision-making process. 
> 
> Joe
> 
> 
> > From: Gerald Kern
> > 
> > Problem was this file is sent to MS 2K server where a thrid party app
> > (biztalk or some custom code - I'm not sure what it is) picks it up
> and
> > processes it and sends it to our electronic medical records app. For
> some
> > reason the extra blanks caused that app to think there was 'unknown'
> data
> > in
> > the file and it was generating an error report. Unfortunately this
> (EMR)
> > is
> > a third party product not under my direct control and I don't want to
> pay
> > to have the application changed to eliminate a benign 'problem'.
> 
> -- 
> This is the Websphere Development Studio Client for iSeries  (WDSCI-L) 
> mailing list
> To post a message email: WDSCI-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/wdsci-l
> or email: WDSCI-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/wdsci-l.
> 
> -- 
> This is the Websphere Development Studio Client for iSeries  (WDSCI-L) 
> mailing list
> To post a message email: WDSCI-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/wdsci-l
> or email: WDSCI-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/wdsci-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.