MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » February 2014

Re: Data Transfer from i series to excel file or display give hexadecimal values fro date



fixed

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.






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact