Custom .skn file - can't update metadata

Here's the order of steps when adding a KEY to a system code:

1. skndef productline systemcode then add your key.
2. kndef productline and again add the key
3. srgen
4. recompile the program(s) that uses the key

Steps when migrating skn to a different productline
1. metadumpskn productline systemcode >> syscode.skn
2. copy syscode.skn to where the location of the new prodline
3. metaloadskn prodline syscode.skn

Posted By Sam Simpson on 02/11/2011 09:48 AM
Here's the order of steps when adding a KEY to a system code:

1. skndef productline systemcode then add your key.
2. kndef productline and again add the key
3. srgen
4. recompile the program(s) that uses the key

Steps when migrating skn to a different productline
1. metadumpskn productline systemcode >> syscode.skn
2. copy syscode.skn to where the location of the new prodline
3. metaloadskn prodline syscode.skn

Thank you!  I think this must have been what we did last time but we had a heck of a time figuring it out. 

Okay...so I did the metadumpskn, and then copied that file back to the metadata (I renamed/saved the delivered file.)
So our mod is now in metadata.  But since we already did the skndef, kndef, srgen and all that, what does metaloadskn do for us?  Our customization is already in GEN.  It seems like metaloadskn would be redundant. Is there something else that gets changed?

When you dumped the skn did you scrutinize the file if your MOD is really there? Your appmetadiff has an error because pa.skn is not a valid parameter. This utility only finds difference between GEN and the metadata. Another thing, your custom key is it upper or lower?

Posted By Sam Simpson on 02/11/2011 10:31 AM
When you dumped the skn did you scrutinize the file if your MOD is really there? Your appmetadiff has an error because pa.skn is not a valid parameter. This utility only finds difference between GEN and the metadata. Another thing, your custom key is it upper or lower?

Yes.  I opened the PA.skn file and our mod really is there.  I literally compared the two files to find the differences.  I just noticed however, that the header line - the one that gives the version number, is NOT in the new .skn file.  Shouldn't that be there? 
Also, I have not rerun the apmetadiff as it takes a dang hour to run.  I was assuming that it would not show any differences this time...but I will run it again to see.

******* PA.skn 26 <3324891987>

I have all skn on all sys codes and I could not find the version number either. I don't usually do appmetadiff because as you said it takes a long time. I usually do an sql to gen database and the table name is CFKEYNBR. This is where I can compare the metada against gen easily.

Yep...I just ran a SQL query and checked that the mod is there, in both SYSKEYNBR and CFKEYNBR.  The key number is a mixed case by the way.  I didn't even realize that there were so many, and so many of them are mixed case as well.  (It's been a while since I've looked at this skn stuff. How quickly the mind goes. :-) )

I think this is the only .skn file mod we've had to deal with...otherwise we'd be more well-versed in how to handle them when it comes up.  So you are saying that none of your modded skn files have the version number line in there?  Do you see any reason for me to run the metaloadskn?  Still not sure what that would do for me, since the GEN files are already correct.

As to the parameters on appmetadiff - this is what is shown in LID:

Syntax:
 perl /appmetadiff [-d][-s] ProductLine [Metadata Files...]

Examples (Windows):
 perl %gendir%\bin\appmetadiff testline
 perl %gendir%\bin\appmetadiff -d -s testline CU01.msg ifmeta
 perl %gendir%\bin\appmetadiff -d testline t*meta *.wrk armeta/*.msg

Arguments:
 ProductLine    : product line to process
 Metadata Files : optional - metadata selections to process

Metadata Files parameters can be a metadata subdirectory, metadata filename,
or both.  The subdirectory or filename can include wildcards just like the ls
or dir command.  Each parameter is treated separately, just like ls and dir.

From that, I would have thought that using "PA.skn" as a parameter would work.  Should I have included the folder path, maybe?

*edit...well that wasn't it.  I added the folder path and it made no difference.  Really...the syntax is pretty clear here.  What am I missing?

I usually just run this to sync the whole prodline, anything that shows up in the log is worth my time to look into.

perl %gendir%\bin\appmetadiff -d prodline
(display items with differences between GEN and prodline)

perl %gendir%\bin\appmetadiff -s prodline
(sync items with differences between GEN and prodline)

kick it off before you go to lunch, check it at %lawdir%\prodline\admin\appmetadiff.log after you came back from lunch.

We've never "synched up" the entire product line...we never had any reason to, and apparently no one here was ever instructed to do it. Go figure.    We have all kinds of differences showing between GEN and metadata...guess we'll be taking a look at that.

Oh..just so you'll know, I spoke to Lawson about this command error, and it turns out that there is a bug. You are supposed to be able to run appmetadiff for a specific file or folder.  PT 183880 was opened for it...and at some point I guess they'll fix it.