Upgrading SCT Banner

1. Upgrading SCT Banner

2. Upgrading SCT Banner • The process of maintaining SCT Banner involves frequent upgrades for both enhancement and error correction purposes • These tasks will involve using: • ActionWeb • Patches • Upgrades

3. ActionWeb - Services • ActionWeb is SCT's web site for: • Information on the SCT Banner products • FAQs • Finding information on defects • Finding and downloading patches • Entering technical request contacts • You must be a valid SCT customer

4. ActionWeb - Account • Requires setting up an account • Specific username and password • Uses reverse IP lookup • To set up an account: • Start at http://www.sct.com • Click on Client Support • In the ActionWeb Users box, click where prompted ("If you do not have a valid User ID and Password, then Click Here to continue."). • Click the ActionWeb FAQs link below, if needed

5. ActionWeb - Options • After logging into the account, the ActionWeb home page displays several options • On the main page there are entries for: • Recent News • Instructions for downloading patches • How to sign up for SCT listservs • SCT Banner Release Schedule • SCT Banner FAQs

6. ActionWeb - Menus • On the left side of the main page are a set of menus: • Profile - This is your personal profile • Contacts - Contacts opened by your institution • Extended Search - Extensive search of the SCT databases • Known Issues - Defect searches • FAQs - Various SCT Banner FAQs • Upgrades - Request SCT Banner documentation and upgrades

7. ActionWeb - Support • ActionWeb is one of the available avenues to report SCT Banner problems • ActionLine is also available • Both ActionWeb and ActionLine go into the same helpdesk pool • ActionMail

8. SCT Banner patches and upgrades • Except for major upgrades, most enhancements and patches will be downloaded off the ActionWeb • As issues are resolved and error corrections developed, these fixes will be bundled into patch sets and posted on the ActionWeb's electronic download site • These patch sets are compressed and encrypted • Must use a special program to decrypt (edread)

9. Finding patches • The first step is to use the Known Issues search engine to locate defect and associated patch numbers • New patch postings are also broadcast on the SCT listserve BPOST • Once the proper patches are located, invoke the download gadget to retrieve them

10. Downloading patches • There is a web gadget that allows for easy packaging and downloading of patches and the decryption program • Follow the directions on the main ActionWeb page for downloading patches to set it up • Set up a directory structure to download and decompress/decrypt these patches

11. Installing patches • Once the patch is downloaded, decompressed, and decrypted, review the install instructions • Most downloads involve new software or database objects, which will need to be: • Migrated to proper software directory • Compiled as needed • Installed into the database as needed

12. Managing patches • Patch management is one of the most challenging of the SCT Banner maintenance duties • A methodology and conventions for storing, testing, and applying patches should be developed • Patch installation does not necessarily coincide with upgrade installations

13. SCT Banner Upgrades • SCT Banner upgrades come in two types: • Cumulative • Interim • Upgrades are applied in two parts: • Upgrade applied to the database • Upgrade applied to the software

14. Upgrade dependencies • Each SCT Banner product has its own upgrade procedure • These upgrades must be applied in a particular order to build dependencies properly • There is a dependency matrix for all upgrades in the SCT Banner general FAQ section • Read Page Five of the Upgrade Installation Guide

15. Database Upgrades • GOSTAGE is a PL/SQL program that builds a database upgrade script based on two SCT Banner upgrade tables: • GUBSMOD - Holds Modification Identifier • GURSSQL - Holds Modification SQL • Creates and runs a file called DOMOD.SQL which will apply all of the upgrade changes to the database

16. Software Upgrades • The upgrade to the software happen in sync with the database upgrade • All changes to source code is migrated to the software tree during this stage • All Pro*C, Pro*Cobol, and Forms executables are compiled and moved to the appropriate executable trees • Forms executables probably need to migrate to other servers

17. Managing Upgrades • How many upgrades - the bare minimum • Remember the O/S and Oracle • The database server is not the only upgrade • Timing the upgrades • READ THE UPGRADE DOCUMENTS • Media verification

18. Step One • READ THE USER RELEASE NOTES! • Distribute them • Make copies • Users will make upgrade timing decisions based upon them

19. Step Two • Backups • The databases • Make sure you have a cold backup • Check on disk space if in archivelog mode • The SCT Banner directories • This will replace the existing files

20. Step Three • Restricting access • Revoke user access • Change user passwords • Restricted Mode • Stopping the named listener • Change the port number so you can access the database while doing the upgrade

21. Step Four • Position to the correct directory • Make sure you are doing the correct upgrade • Make sure the paths are set • DO IT EVERY TIME YOU RESTART THE UPGRADE!

22. Step Five • Edit the login.sql file • DO IT FOR EACH DATABASE! • Create a subdirectory for each database within the upgrade for the SPLPREF variable • Change the passwords? • PAY CLOSE ATTENTION TO THE TABLE SIZING!! • Site-specific changes may be affected

23. Step Six • Nruready.sql • Modification tables • GUBSMOD • GURSSQL • Possibly a set of these tables for each product • The import error message • Verify the import

24. Step Seven • You are provided several lists of changes that should be reviewed before any upgrade. • You may need to resize tablespaces and quotas • Items can be deleted, increased, added of modified • Tables • Indexes • Views • Stored objects • Objects, options and menus are now modified as part of GOSTAGE

25. Step Seven (cont.) • Changes the database structure The GOSTAGE Process GUBSMOD GURDMOD GOSTAGE GURSSQL domod.sql xURVERS domod.sql

26. Step Eight • Migrate from stage to permanent directories • Check that you are pointing to the correct SCT Banner code tree • Extra migration step for the forms • Unix users should verify which type of link is used (soft vs. hard)

27. Step Nine • Compile the COBOL programs • Uses the make file or com file • Run in the background • Not required for subsequent databases

28. Step Ten • Compile the C programs • Uses the make file or com file • Run in the background • Not required for subsequent databases

29. Step Eleven • Baseline data changes • Dynamic help • Role level security objects • Rule codes • Graphs • Data conversion • Performed after structural changes • Each one is specific • Very seldom used

30. Steps Twelve and Thirteen • Forms and Reports • Now done on the forms server • Review each file for necessary include files • Make site-specific changes • Passwords • Connect strings

31. Step Fourteen • Letter generation/population selection variables need recompilation • When necessary, the instructions are very explicit • Not done very often

32. Step Fifteen • Referential Integrity created in Step 7 • This step may disable some of the constraints

33. Step Sixteen • If there are any reports that involve changes to the database or data dictionary, this step lists the reports and how to create the output listings

34. Step Seventeen • The final run of the GOSTAGE process • Renames the original domod.sql and listab1.lst files • Drops all obsolete tables • Drops temporary objects • Updates xURVERS table

35. Step Eighteen • Verify the upgrade • Part A • The GURALTR script finds all invalid objects owned by the BANINST1 and recompiles them • Part B • Re-synchronize any changes to classes • Part C • Run Xrudone.sql

36. End of Session Any Questions?