RE: Level check problem - chgpf

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.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.