Windows 2000
8.0.3 ESP7

To prepare for our BSI 8 upgrade, I just ran the lawappinstall utility for the CTP that contains this required patch. (166913). Reading the instructions for this process (this is new to me) I think I am officially in patch hell. There is a readme file (and a delta readme file too) that I am supposed to analyze and determine what the impact is on our existing programs?? I am definitely in over my head...and at this point I really don't know what to do. I can open yet another case with Lawson, but since I've had about 4 in the last couple of days, I thought I'd check with you guys and see what the next step should be. Thanks.

It's not too bad. I have never worked with Lawson on Windows so I'm guessing on some of this stuff.

I'm assuming your on some version BSI 7.0x

1) Put the Environment Patches in first. For 8.0.3.7 that's #166922. It's just a mass update of programs including the new cmptfxxxx file for compiling the BSI interface.

2) Put the application patch in. For 8.0.3.7 that's #166913.

Double check to make sure I got those patches right :thumb:

3) Download the BSI software. Right now it's 8.0F. Both client and server.

4) If you are not at the latest 7.0 version of BSI. I would suggest you update to the latest 7.0 version before going on. You just need the client portion for this and not the server.

4a) Acquire from BSI the passwords for the latest version of 7.0 and the latest version of 8.0F.

4b) Ask BSI for access to the BASE data for 8.0F. They will send you directions for where that is located.

5) Backup your BSI database.

6) Update to the latest reg bulletin for 7.0

7) Use the BSI client to backup/export your custom data. BSI has documentation on this.

8) Update your current client to the latest 7.0 version.

9) Use the BSI client to backup/export your custom data in VERSION 7.0 format. Use readable names, i.e. version7.0L_backup_101707.bak

-- Backup your database again.

10) THIS IS THE SINGLE MOST IMPORTANT STEP. USE THE BSI CLIENT/EXPORT FUNCTION TO BACKUP YOUR CUSTOM DATA IN VERSION 8.0 FORMAT. NAME IT SOMETHING READABLE, I.E. VERSION7.0_BACKUP_8.0FORMAT.BAK

11) Create another database or create another tablespace in the same database as you are currently using for taxfactory.

12) Create an id called TF80 and make sure it has the same rights as the TF70. Make sure they are separated.

13) Run the SQL script that comes with the server(or client..i forget) download for TF80 your appropriate database to create the schema for TF80

14) If everything goes right you now have objects, i.e. tables, views, etc under the TF80 id.

15) Wipe any and all existence of TF70 client from your PC. If you don't the TF80 client tries to use the ODBC connection setup for TF70 and messes it all up.

16) Install the TF80 client

17) Setup the ODBC connection to the database when it asks you.

18) If everything goes well you are now connected to the database.

19) Load the BASE DATA for TF80 in to your new database. This takes some time go have a beer. :lala:

20) Load the the custom data that you saved in version 8.0 format.

21) Copy the three api files 'libexpat.a', 'libtf8<yourmachine_os>.a', and 'libz.a' to %LAWDIR%/apps/tf80

22) Modify your lawson.env file to point to the right location for BSI: DATABASE, TAXFACTORY directory, id and passwords

23) Restart lawson with new environment settings

24) Run cmptfx<your database> to compile the api interface for BSI

25) Run lapm productline prtf to test and see if you can connect to your new bsi database.

And your done. Sort of. Now you have to your users test it.

LOL, you can't follow "It's not too bad" with a 25 step process and keep a streight face.

Good work documenting it though. Thanks :bow:

Heck I couldn't even keep a straight face on that one. :rofl: My ESP7 upgrade is done, and the last environment patch I applied as part of that also included 166922, so I'm good there.

The step that is giving me pause is the application patch - as I have never done one before. It appears to me (reading the delta readme file) that there are many programs impacted. Just a quick run through the list shows at least one program that we have "cloned" and customized - and I'm not sure yet (as I sit here at home past midnight STILL thinking about this!! :blink: ) but there may be more. So...how do you tackle that? Do the coders do a line by line code compare for such programs? This really took me by surprise - I thought I'd be done by now and ready to hand off to the testers. :nix:

Of course, now that I see your (fantastic - thank you! :bow: ) documentation for the BSI upgrade, I don't think I'd have been done by now anyway. :banghead:

Here's the thing about application patches. Don't worry about it. :rofl:

Seriously. I've put in a billion patches and the process right now is much better than it ever has been before -- you won't be able to catch everything. And if there is a problem with a program you contact lawson. If your worried about it a lot here is what I would before applying the patch:

1) backup your data
2) backup your schema (bldxxx -TI productline > prodline.sql)
3) sysdump -e prodline prodline_sysdump.dmp (dump all the programs, tokens, etc)
4) copy your $LAWDIR/apps/productline some where -- mostly you just need the source and lib directories

If you can't reverse the patch for whatever reason. Then you use the above the backups to restore to the way it was.

Applying the patches -- You have probably read it but here is a quick synopsis:

A) perl $GENDIR/bin/lawappinstall update productline --- put's all the changes, updates, the programs, metadata, table changes (oh yeah, they can change the database too), etc..

--- When you do this a directory called in the $LAWDIR/apps/productline/backup is created with that patch number and all the files, etc that it replaced. In case you have to go back.

B ) perl $GENDIR/bin/lawappinstall activate productline --- this actually makes the changes happen in the productline; rebuilds the dictionary; asks you to make those changes in the database, compiles all the programs.


-- Before actually doing this go to your $LAWDIR/apps/productline/int directory and remove everything there -- that's where all your compile join's are done. Always double check your in the right directory before doing that though obviously.


C) Look in $LAWDIR/apps/productline/Admin for the install.log, and you can find all the affected programs by the ' M' and ' m' (and there is a deliberate space in first spot).

D) Look in $LAWDIR/apps/productline/Admin for the patchcompile.log and it will tell you all the files that were compiled.

The delta file is good but doesn't always give you the whole picture. Also, if you want to know what the differences were between your customizations and the new stuff -- use this program called BeyondCompare from http://www.scootersoftware.com/

It allows you to compare the differences in files and folders. I was going to say diff, but diff is very hard to read. With BeyondCompare you can do side by side comparison.

Most of the time we find the problems later and fix them. You can't catch everything and I've given up worrying all the time about it; I tried to be as prepared as I can (i.e. multiple backups -- you can't have enough) and usually it works out.

Btw my manager helped push the whole delta file thing because we always had a problem knowing what it really affected.

Thanks. Seriously. That helps a lot. We do have a file compare utility that we use for side-by-side compares - probably a similar utility.

In the cmd window where I ran the lawappinstall cmd, it returned quite a bit of information...I pasted a few lines here. Is this saying that these commands WILL be run when the patch is "activated"?? So a dbreorg WILL be required..and it runs it runs it for you? (Sorry - I know these are rather basic questions...beleive it or not I have the CTP install guide right in front of me, but it doesn't really explain this in any detail.)

Possible modifications - None.
Database preparation.
Would execute bldckp here.
Would execute setsfl here.
Would execute setnotused here.
Would execute blddbdict here.
Database preparation successful.
Would execute dbreorg here.
Would execute Job Conversions here.
Executing patchcompile with the preview option.
patchcompile execution successful.
Run Srgen - No.
Program Compiles - Programs would be compiled during the installation. The list
of these programs can be found in preview.log.
Would execute apploadcsv here.

Oh...and on those "M"s in the preview.log - that is referencing changes that we have made in those files?

I just answered that last question for myself. Yep.

It's hard to say from that if it actually modifies the database. It will rebuild the dictionary to see if there are any changes and if so, then it will ASK you if you want to make the changes. If you say no it will stop the activation process and you will to have restart it later.

The dbreorg is one thing I would always because cautious about. If it wants to do a dbreorg say no, then at the command prompt type 'dbreorg -l prodline' to find out what will be affected.

Now it depends on what it's doing. If it's going to modify a current table then I would suggest doing somesort of backup just in case. Both data and schema. After that first big mistake I always make a gazillion backups just in case. :bonk:

Okay...I'm just being cautious as I am completely out of my box on this. We had a few of those "M"s show up on the preview.log so we are in midst of determining how to handle those.

So far, I think I much prefer environment patches to application patches!!!

Have guys really modified those programs?

Also, if your applying multiple patches you can just do 'update' until your done and then just have to run 'activate' once. It will apply all the patches you have put in.

Cool...that's good to know.

As far as the "M"s, I think there were only 3 or 4 of them where we actually needed to merge our changes, though very minor. One was actually a Lawson-recommended fix where we had to increase the value of an occurs clause to correct a payroll error. I would expect (hope and pray) that we don't have many of these types of things...generally if we need to change a program, we "clone" it and leave the vanilla one, vanilla.