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

[CRPence <CRPbottle@xxxxxxxxx>]

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.