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 ProC, ProCobol, 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?