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