Re: Level check problem - chgpf

[Vern Hamberg <vhamberg@xxxxxxxxxxx>]

 Dennis

Are you sure of this? I think the FILE level ID is the timestamp of when 
the file is created. I just made a copy of the source for a PF and 
compiled the copy. The format level IDs were identical, since they are 
based on data types and other things, as described here in database fle 
management docs -

The server assigns a unique level identifier for each record format when 
it creates the associated file. The server uses the following 
information to determine the level identifier:

   * Record format name
   * Field name
   * Total length of the record format
   * Number of fields in the record format
   * Field attributes (for example, length and decimal positions)
   * Order of the field in the record format


Am I missing something? Ake's example has the same format level IDs and 
different file level IDs, which I'd expect. AFAIK, only format level IDs 
are looked at when using CPYF - I wonder what message he is really 
getting. I just tried a CPYF to the file I just created. I didn't use 
the CHGPF, as he did, over a duped file that was then made multi-member, 
so I may have a different test case.

Vern

On 8/17/2010 4:03 AM, Dennis Lovelady wrote:
> Where you went wrong was in changing the two files independently.  The
> system uses timestamp to generate the format level ID, and the timestamps of
> the two files cannot match.  It doesn't matter that the format names, field
> names etc. are the same since those don't generate the format level ID.
>
> To correct this, create a new log file and repopulate it.  Then eliminate
> the old (save it first).  Here's one way:
>
> CPYF lib/DATAFILE lib/NEWLOG CRTFILE(*YES) TOMBR(some_unique_value)
> CPYF lib/OLDLOG lib/NEWLOG FROMMBR(*ALL) TOMBR(*FROMMBR) FMTOPT(*MAP)
> RNMOBJ lib/OLDLOG *FILE SAVEME
> RNMOBJ lib/NEWLOG *FILE OLDLOG
>
> Or thereabouts.
>
> Dennis Lovelady
> http://www.linkedin.com/in/dennislovelady
> --
> "The direct use of force is such a poor solution to any problem, it is
> generally employed only by small children and large nations."
>          -- David Friedman
>
>
> > I started out with one data file and a log-file that was created as a
> > copy of same file (CRTDUPOBJ). The log file has then been changed to
> > allow multiple members.
> >
> >
> >
> > Now when new fields had to be added to the data file we also had a need
> > to keep the log file format in synch.
> >
> >
> >
> > I did a CHGPF of the log file with the SRCFILE parameter and indicated
> > the source member that was used for the re-compile of the data file.
> >
> >
> >
> > As far as I can see both files have the same record size, fields, field
> > types and field lengths.
> >
> >
> >
> > Despite this I get a level check when using the CPYF to copy data from
> > one file to the other.
> >
> >
> >
> > Where did I go wrong - OR is the only safe way to reformat files the
> > old trusted way of recompile and manual copying of the data?
> >
> >
> >
> > File level id:s:
> >
> > Data file            1100813084024
> >
> > Log file               1100813084348
> >
> >
> >
> > Format id:
> >
> > Data file            42A0FD7F7A38F
> >
> > Log file               42A0FD7F7A38F
> >
> >
> >
> >
> >
> >
> >
> > Med vänlig hälsning / Best regards
> >
> >
> > Åke H Olsson
> >
> >
> >
> > Box 433   SE 551 16  Jönköping   Sweden   visit: Brunnsgatan 11
> >
> > phone: +46 (0)36 342976   mobile: +46 (0)705 482976 fax: +46 (0)36 34
> > 29 29
> >
> > ake.olsson@xxxxxx<mailto:ake.olsson@xxxxxx>      www.pdb.se
> >
> >
> >
> >
> >
> > This e-mail and any attachments may contain confidential and privileged
> > information. If you are not the intended recipient, please notify the
> > sender immediately by return e-mail, delete this e-mail and destroy any
> > copies. Any dissemination or use of this information by a person other
> > than the intended recipient is unauthorized and may be illegal.