Having issues with generating an SMFLUP for SMTABS in 7.7.x

If you are having issues with getting all your meta-data changes into SMFLUP from SMTABS, like I was here are some changes that you can add to UTR999 and UTR998 to shorten the key to be updated and reconstitute the key for updating.

UTR999 (Generate SMFLUP):
1036 if smflup.file_name$="SMTABS" then { ! Take PCOND$ value and shorten by substituting spaces for $00$ and add one $00$ to the shortened value to expand later.
1037 short_key$=k2$(1,12)+cvs(sub(k2$(13,80),$00$," "),3)+$00$+k2$(93)
1038 smflup.key_updated$=short_key$ ! New key will be less than 64 and fit in SMFLUP.
1039 }

1236 if smflup.file_name$="SMTABS" then { ! Take PCOND$ value and shorten by substituting spaces for $00$ and add one $00$ to the shortened value to expand later.
1237 short_key$=k1$(1,12)+cvs(sub(k1$(13,80),$00$," "),3)+$00$+k1$(93)
1238 smflup.key_updated$=short_key$ ! New key will be less than 64 and fit in SMFLUP.
1239 }

1406 if smflup.file_name$="SMTABS" then { ! Take PCOND$ value and shorten by substituting spaces for $00$ and add one $00$ to the shortened value to expand later.
1407 short_key$=k1$(1,12)+cvs(sub(k1$(13,80),$00$," "),3)+$00$+k1$(93)
1408 smflup.key_updated$=short_key$ ! New key will be less than 64 and fit in SMFLUP.
1409 }

UTR998 (Update files from SMFLUP):
0656 if smflup.file_name$="SMTABS" then { ! Reconstitute KEY_UPDATED$ from the first 12 characters, then the next segment up to the first $00$ after position 13, padded to 80 with $00$, and add the last piece from the $00$ after position 13.
0657 long_key$=smflup.key_updated$(1,12)+pad(smflup.key_updated$(13,pos($00$=smflup.key_updated$(13))),80,$00$)+smflup.key_updated$(13+pos($00$=smflup.key_updated$(13)))
0658 smflup.key_updated$=long_key$ ! Restore key length original size...
0659 }

I have generated an SMFLUP file using the changes but have not as of yet, used the process to update the files from SMFLUP. The SMFLUP file does have all the SMTABS records that I was missing from the update of my incremental install 7.7.3.

You can use at your own risk. I guarantee, double your money back - so 2 x $0.00, you get the idea!

HTH anyone that has had issues with SMTABS.

Find more posts tagged with

Comments

Legacy Contributor

Could you provide a few more details:

1) Was there a specific error at a certain line, or was the problem that SMTABS records just weren't getting updated from SMFLUP (i.e., they seemed to just "disappear")?

2) Which version of FACTS were you upgrading from that had SMFLUP and/or SMTABS with this key length problem?

Eddy Vittini

Todd,

I had made changes in version 7.7.0 to the Vendor and Customer existing tabs and added new ones (10 & 11 for ARF910) and when I applied the 7.7.3 incremental I was left with missing SMTABS records.

The records that I had changed in tabs 2 - 5, but only got the changes for tab 5, and when I added 10 & 11 to ARF910 I only got back tab 11.

The key to SMTABS is comprised of PROG$ (up to 12), PCOND$ (up to 80), Z9 (up to 3), and tab number (up to 2) and that exceeds the field in SMFLUP for key_updated$ (64).

When you update any other META-DATA file that has a PCOND$ in the key, that field (PCOND$) is the last field and NOT padded to its full length. However, in SMTABS the PCOND$ value is in the middle of the key and MUST maintain is FULL LENGTH of 80 thereby causing the issues with records in SMFLUP.

I did not get any errors while processing the 7.7.3 incremental, just all of my changes to SMTABS (I only got a small percentage back). Luckily they were in SMTABS.MOD and I just wrote a Q&D to get the missing records from SMTABS back from SMTABS.MOD!

Hope I answered your questions.

There is a topic in the Infor365 Knowledge base about the problems with SMTABS (Defect #278537) if you would like more information.

Legacy Contributor

Rob,

It seems you have an old version of SMFLUP. The current version has the key structure of :
[1:1:8]+[2:1:110]+[3:1:1]+[6:1:30]

It is also an EFF file. This changed in one of the later 7.6 incrementals after I reported a similar issue with SMPRMT records.

Ken

Eddy Vittini

Ken,

You are indeed correct, I had an old SMFLUP file from my merging of data from 7.6 into 7.7 and that old file was sitting there when I applied the 7.7.3 incremental. I found the "original" 7.7.0 SMFLUP file in the SM directory and replaced the old 7.6 SMFLUP file and re-ran a generate SMFLUP process and got all my records in the SMFLUP file.

After missing my SMTABS records and having to recover them from SMTABS.MOD, I search the Knowledge Base and found the noted defect, so I just assumed that the issue was still open.

Thanks for pointing out the defect was with my SMFLUP file.

Bob

Legacy Contributor

I have updated the KB article stating the defect was voided and explaining the problem was caused by the use of an old SMFLUP.

Steve

Copyright © 2025 Infor. All rights reserved.