On 15-Feb-2014 10:41 -0800, Narayanan Pillai wrote:
On 02/15/2014 12:05 PM, Vernon Hamberg wrote:
With a packaged app, you can't change the files - the ISV has done
what they did for reasons, and they handle this stuff in their
programs.
So I suggest you use the setting to convert 65535 stuff - there's
really no other choice in your situation, I think.
Thank you, that was the point!
So the point was to elicit a response supporting a subtle assertion
that there is no simple resolution and\or that 'the force conversion'
somehow is _the_ simple /solution/ rather _the kludge_ that it is?
Getting a response that is a resignation to the fact that potentially
one must suffer with incorrect results because a software provider has
created their files in a manner that prevents a /simple/ transfer of the
data by the user? <-- Those are of course, rhetorical; undeserving of,
nor expecting, any reply.
Sometimes one inherits numbers as dates, 65535 as CCSIDs, DDS-defined
files; all as parts of production applications that one cannot change
without difficulties.
True. But even if the files can not be changed, that does not imply
the effects of transferring the data should be forced to give possibly
incorrect results. That is merely a choice; IMO, a poor choice.
If someone is given a car with no brakes and they want to move the
car to the bottom of the steep hill where the vehicle is parked, there
is no requirement that someone must then drive the car to the bottom of
the hill if the parts and\or the mechanic can not come to the car. That
would seem to be a somewhat reckless choice. Risks of negative effect
to both the driver and others, might be worth considering before driving
the mechanically deficient car. As a likely safer option... The car
could be towed to the bottom of the steep hill, if the brakes can not be
repaired where the car sits.
Similarly, the files need not be changed, to obtain the desired
representation of the data from those files; i.e. to move the data
elsewhere. The DB2 for i and especially its SQL interface [as does the
SQL generally] allow a variety of means to overcome various data
definitional issues. Thus there is typically a capability to safely
achieve what is necessary, by employing additional tooling, beyond the
most simplistic approach\tooling. And one need not choose a somewhat
reckless means to move the data, when other safer means exist.
When people get a-hold of these systems, they tend to ask "poor"
questions. In this case, the OP even found the answer himself ( and
had the courtesy to post a reply saying he had done so ). IMHO, to
dismiss these questions off-hand was counter-productive.
Who dismissed the question? Seems that everyone who replied to the
OP and to the followup by the author of the OP, was trying to assist.
FWiW:
I do admit I ignored the question originally, because I could make
little sense of the inquiry. I responded only after the followup, in
which the apparent problem was made more conspicuous by the OP, due to
what was their choice as a means to attempt to /correct/ the issue. My
response vitiating the claim for a *need* to implement a kludge, was
IMO, sage advice; as a warning of possible unintended effects occurring
along with the[ir] perceived correction. And as with all publicly
available fora, the advice\commentary offered in the responses is gratis
[or even gratuitous, in the non-gratis sense], and easily\freely ignored.
That the question even was asked, is strong evidence that the chosen
means as a /resolution/ poses risk; and those offering that kludge as an
apparent resolution without warning of caveats, are quite possibly
similarly unaware of why use of that option should be discouraged...
else one would hope they would have included a warning. The "it works
for me" simply does not apply generally as conclusive, for something so
wide in scope. Activating [and leaving established] the 'force
conversion' option, could prove problematic. My having warned against
its use versus having corrected the environment\definitional attributes,
might give pause to anyone considering the use of that 'force
conversion' option, such that they might take the time to learn what are
the effects and whether those effects may be negative for their
particular scenario; which implies of course, that leaving the option
activated generally, will affect future scenarios irrespective their
prior analysis for any possible negative effects. IOW, even if the
'force conversion' option is deemed functional for the transfer of a
particular file [with a particular set of data], the transfer of any
other file [or even the same file but with a different set of data]
while that 'force conversion' option is in-effect, may result in
undesirable [aka incorrect] output.
midrange.com
