2. Upgrading SCT Banner

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

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

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

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

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

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

9. 8 SCT Banner patches and upgrades u Except for major upgrades, most enhancements and patches will be downloaded off the ActionWeb u 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 u These patch sets are compressed and encrypted u Must use a special program to decrypt (edread)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

34. 33 Step Sixteen u 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

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

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

37. 36 End of Session Any Questions?