Re: Need to determine which version of a file a program has to work with

On 3/4/11 12:15 PM, Charles Wilt wrote:

The program in question was going to be moving data from one table
with a 10a field, 'ABC1234567', to another table in which the field
could have been either 7p0 (old), as 1234567, or 10a (new), as
'ABC1234567'.

insert into<...>
select<...>

I didn't think v5r4's implicit casting was up to the task...but if
it is....

No. Casting would not be up to the task for that scenario. Only if the data remained 'decimal' betwixt, in character string form in the 10a field, and numeric 7p0 in the other. With an actual change to the structure of the data [versus just data typing] to include non-decimal digits [and optional sign], that non-numeric[-digits] data prevents the casting.

Meanwhile, I think we got another solution that doesn't require the
program know what which destination format is in play..

Seems that after having asked a question for which a satisfactory answer was not offered by someone in the forum, for which a [better] solution was eventually found\decided upon by the OP, that solution could be shared for the benefit of others.? Hmmm, seems later, the means of implementation is described... maybe I should have removed this comment to avoid offending anyone ;-)

Basically, we've got a central corporate server and many distributed
field boxes. We've got to expand one of our file fields from 7p0 to
10a. Not only is the file in question used on both central and field
boxes, but the field is part of data that is transferred from
central to the field boxes and loaded via a CPYF.

So the new SQL would replace the CPYF, since obviously the CPYF will also be incapable of mapping the data between the changed fields?

The plan is to expand the central system first, then over a period
of weeks, roll the changes to the field boxes. Between the time the
central box converts and [when] all the field boxes are converted,
the data in 10a file from the central box would need to end up in
either the new 10a field or the old 7p0 field on a field box.

Thus the original question...

If the change kept the data as /decimal/ in both versions of the column definition, until after all nodes had completed the upgrade to 10a from 7p0, then the [implicit] cast would be good to go.

Without that consistency in the structure of the data however, that upgrade seems kinda ugly. I would rather add a new column 03a to the new version of the file, probably with NULL as default. The option to FMTOPT(*MAP *DROP) for CPYF between the two files should then function, but with the expected loss of the three bytes for any system still running the old version. That data loss is what makes the scenario "ugly". Perhaps not so ugly however, since, seems maybe there is only 'push' of data from the central to the field, so that loss can not result in potential confusion for data 'pull' from the field onto the central system.? Potentially problematic if there is no obvious way to know for sure [seem not, from the givens], that what originated as 'ABC1234567' which becomes 1234567 when pushed had perhaps originated as only 1234567 in a field-system before being pulled to the central-system or even that the value had originally been 'XYZ1234567' instead of 'ABC1234567' before being pushed.

In talking to the developer, it seems to me that we can simply have
[<ed> two] copies of the transmission file, the old 7p0 one and a new
10a one. The program containing the CPYF will be included in the
changes rolled to the field boxes to copy from the file [<ed> with
the matching record format].

So the resolution is to attempt two CPYF, ignoring the request which fails due to the condition CPF2960 RC1 and thus CPF2963.?

Regards, Chuck

On Fri, Mar 4, 2011 at 2:45 PM, CRPence wrote:

Any pros/cons to the above?

Does anybody have any additional ideas?

Perhaps... Is there really any requirement to know the difference?
There is implicit casting between the two types, and explicit
casing is legitimate to get a consistent type into the non-SQL
program variables.