Transcript Managing Your Lawson System MSPs and CTPs
Managing Your Lawson System
MSPs and CTPs
Ron Wright netASPx Corp.
CTP Definition
Lawson’s Definition: "Critical Transfer Packages ( CTP's )"
are individual "high priority" fixes that are available to download immediately without waiting for the scheduled Maintenance Service Package.
• Many CTPs released every week
MSP Definition
Lawson’s Definition: "Maintenance Service Packages ( MSP's )"
consist of scheduled, periodic groupings of individual, critical fixes. Each new Transfer Package is built upon the previous one, so all fixes are included in the newest available CTP.
• Released every 2-3 months • NOT installed like a collection of CTPs!
MSP: When and How Often
netASPx applies all MSPs • Give MSPs time for critical problems to be resolved (1 month) • Review CTPs released within 2 weeks of an MSP for applicability • Watch Topica mailing lists for impressions (http://www.topica.com/lists/Lawson_SysAdmin)
MSP: Experiences
• Call volume increases for a short duration after • Issues are often serious in nature • Number of issues and severity closely related to the amount and quality of the testing performed!
• Develop test plans with end user involvement.
• Test processes and programs, not just programs • Write down the cutoff CTP for easy retrieval. Useful knowledge for most CTPs installs.
CTP: When and How Often
• Other than those reviewed after an MSP, CTPs are applied only upon an issue • CTPs are more problematic than MSPs • netASPx has applied over 150 unique CTPs since October, 2002
Application Maintenance Toolset
Suite of utilities for installing applications and applying MSPs and CTPs • Downloaded from support.lawson.com (Transfer Packages) • Includes lasetup, appmetaload, patchcompile, and the metadata load and dump programs
lasetup initial
• Used for a new installation or point release • Clears out $LAWDIR//Admin/install.log
• Overwrites source files without backup • Performs sysloads
lasetup staged (MSP)
• Files are staged to a designated location then compared to program code in productline • Programs found to be more recent than code in the MSP are not replaced • Metadata in $LAWDIR//metadata • All files and metadata to be replaced are backed up to $LAWDIR//backup/-MSP# • Metadata more recent then the MSP is first overwritten in the GEN database then reloaded
Backing out an MSP
Preparation: • Complete data backup (expsysdb -s) • Backup of LADBDIR and LAWDIR Optional prep step: • sysdump (more options for recovery)
Backing out an MSP (cont)
2.
3.
4.
5.
Restore Procedure: 1.
Backup data (if unsure of backup or potential exists that updated data may need to be retrieved) 6.
7.
Drop tables (bldxxxddl –UDq ) Restore LADBDIR and LAWDIR Startladb bldxxxddl –Uq Restore data (impexp) startlaw
lasetup patch (CTP)
• Files to be replaced are compared for more recent versions. More recent versions are not replaced.
• Replaced program files and metadata are backed up to: $LAWDIR//backup/ • GEN data not updated yet
appmetaload (CTP & MSP)
• Applies changes to the GEN database related to a program or library • Used during MSP install to reload “Reverted” metadata • Information related to workfiles, messages, etc. loaded for you. No more manual entry,, except… • Database changes (dbdef) not handled
patchcompile (CTP)
• Determines all programs related to the patch that must be recompiled and submits them.
• Optionally creates a script to submit all compiles.
Backing out a CTP
• 1.
2.
3.
4.
No prep required Copy program files from $LAWDIR//backup/ back to appropriate location Go through “meta” directories (ex. Metagl) and run appropriate metaload program for each file found. ( ex. metaloadmsg AP20.msg ) If manual database changes were done, those must be reversed manually. (dbdef, blddbdict, dbreorg) Recompile productline or rerun patchcompile
Under the Covers
Version comparison: • Version compared using the first line in every program file. This line has: • Any change to the file changes the chksum value. If chksum doesn’t match the header, version ignored and program overwritten in all circumstances.
• To bypass this behavior: perl $GENDIR/bin/addversions –s {version} {file}
Under the Covers (cont)
• Metaload series of programs update all elements associated with the item being updated. It does not perform a merge within the GEN database.
• Be careful if you run the metadump programs. They do not write to stdout. Files in the current directory are overwritten.
• Metadump files fairly easy to read. Most contain “prefix” of GEN tables to be updated. Confirm prefix by running dmpdict GEN
. Look for index (ie. PGMSET1 - PGM is prefix)
Handling Program Modifications
• Use the UNIX diff utility to see changes. (works on NT too with MKS Toolkit or others) diff $LAWDIR/dev8/backup/12345/apsrc/AP20PD $LAWDIR/dev8/apsrc/AP20PD • diff can also create a merged version of two programs for you: diff –D12345 $LAWDIR/dev8/backup/12345/apsrc/AP20PD $LAWDIR/dev8/apsrc/NA20PD (merged program will not compile until edited)
CTPs: Merging Modifications (copied programs)
7.
8.
9.
1.
2.
3.
Apply CTP Look in the install.log for a list of updated program files and metadatafiles related to the original program(s) Dump the same metadata info for the copied program (metadumpwrk, metadumplib, etc) (Note: Do not run the metadump commands in a directory with existing metadata files. They will be overwritten.) Make backup copies of files to be merged (cp MY01PD MY01PD.backup) 4.
Edit merged versions. All code needing attention will be bracketed with “#ifdef” or “#ifndef” to “#endif” (Keep the version line from the CTP) Load merged metadata: metaloadmsg pl MY01_new.msg
Recompile program Cleanup as desired (MY01*.msg, MY01PD.backup)
5.
6.
7.
8.
9.
1.
2.
3.
4.
CTPs: Merging Modifications (programs modified in place)
Apply CTP Look in the install.log for a list of files and metadata replaced by the CTP. Make backup copies of files to be merged: cp $LAWDIR/pl/ifsrc/CU01PD $LAWDIR/pl/ifsrc/CU01.2345
Edit merged versions. All code needing attention will be bracketed with “#ifdef” or “#ifndef” to “#endif” (Keep the version line from the CTP) Load merged metadata: metaloadmsg pl $LAWDIR/pl/metadata/ifmeta/CU01.msg
Recompile program Cleanup as desired (MY01*.msg, MY01PD.1234) 1.
Optional: If you would like any future CTPs or MSPs to not overwrite your merged program with an older version: Get version from the header of each CTP’d file (2 nd field) 2.
• Backup source and do a pgmdump for each of your modified programs • Apply MSP • Backup the MSP metadata and code before putting your modifications back in place. Do pgmdump and create copies of source files for programs modified.
• pgmload from your pre-MSP • Create metadumps for relevant metadata from install.log or looking at $LAWDIR//metadata • Create merged versions of metadata and code.
#!/bin/ksh pl=$1 pc=$2 pl_u=$(echo $pl | tr 'a-z' 'A-Z') pc_u=$(echo $pc | tr 'a-z' 'A-Z') for type in msg pgm do eval metadump${type} $pl $pc done rngdbdump -n gen workfile1 -f filename -v productline=$pl_u programcode=$pc_u \ | while read workfile do metadumpwrk $pl $pc $workfile done
• •
A Strategy for “dbdef” and Other Manual Changes from CTPs
– Breakout each manual step from the README.html into a separate file. The filename should contain the earliest CTP number that contained this step (found in the README.html). Keep in a safe place. If during the manual step an existing value was changed (ex. new field size), this is a good place to keep a record of the original value for backout and audit trail purposes.
Example: $LAWDIR/pl/metadata/manual/12345_dbdef and $LAWDIR/pl/backup/PATCH13579/12345_dbdef After an MSP it is now easy to identify manual steps that must be completed after the MSP is applied.