CampusConnect Administration

1. CampusConnect Administration JAM 2003 Sessions T07 and T31 David R. Tilton Indianapolis (317) 570-6990 Andrew C. Stoffel Knoxville (865) 523-9506

2. Agenda • System Environment • SIS and FAS systems • New Terms and Data Maintenance • Special Logicals • Optional Fields • Defining Faculty Access with Identifiers • “Holds” • SSL information • New Online Billing Calculations

3. Not on the agenda • ADMweb • Presented yesterday by Mike Womack and Pete Sciarrotta • Credit Card procedures • Presented this afternoon by Tom Borchart

4. Environment • CampusConnect needs a happy home… • Alpha OpenVMS • TCP/IP • Compaq Secure Web Server (CSWS) (Apache) …soon to be hpSWS? • CampusConnect Software • Optional Interface JICS • Web Browser • And Patches, Patches, Patches (a.k.a. ECOs)

5. Environment - OpenVMS • OpenVMS version 7.2-2 • Minimum supported version for current Apache • Released Fall 2001 • OpenVMS version 7.3 • Released Summer 2001 • OpenVMS version 7.3-1 • Released Summer 2002 • Strongly preferred version

6. Environment – OpenVMS patches • Patches/ECOs to VMS are important. • Every version has patches. • Lots of VMS patches – which should you choose? • DecThreads patches in particular • How does engineering test patches?

7. Environment – TCP/IP • Compaq TCP/IP Services for OpenVMS • Minimum version now stated as 5.1ECO4 • TCP/IP 5.3 ECO2 highly recommended • 5.3 requires VMS 7.2-2 or later • Multinet from Process Software has never been officially supported.

8. Multinet has never been officially supported! What was that about Multinet?

9. Environment – TCP/IP patches • Compaq TCP/IP ECOs are replacement versions • V5.1 ECO 4 (5.1-154) • V5.1 ECO 5 (5.1-155) • V5.3 ECO 1 (5.3-181) • V5.3 ECO 2 (5.3-182) • Three sites have known cases of chronic system crashing related to TCP/IP w/versions prior to v5.1ECO4 • Suggest use of 5.1ECO5 or 5.3 ECO2 • Upgrade cautiously if using LPD print Queues

10. Environment – ApacheWeb Server • CSWS 1.3 Update 2 Latest version • Update 2 can be applied without (and includes) Update 1 • CSWS 1.2 Update 6 suggested for VMS7.2-1 systems • Requires SYSGEN CHANNELCNT at least 1024 (all versions) • Various SYSUAF requirements

11. CampusConnect Software • Good News! Product remains in very active development. • Bad News! Active development means there are many version variants. • Working to standardize versions better. • CampusConnect is comprised of many more individual file components than any of our other products.

12. Environment – Client Web Browser • Recommended, and typical use is MS Internet Explorer Versions 5.5 and 6.0 • Also expect success with IE v5.0 and Netscape 4.73-4.76 • Note - Netscape versions 4.7x all report as v4.7 • Macintosh IE 5.1 should be compatible • Many, many version variants with patches

13. Environment – cont. • Proper environment has been a moving target • Many combinations of versions are possible and many will work to some extent • UCX (TCP/IP name prior to v5.0) has “special feature” that breaks quickly under Apache use • Same feature emulated by Multinet through v4.3

14. New Terms and Data Maintenance • SIS_Terms file contains 1 record per term which may display in termcode drop down box • Contains 4 dates in each record • Frequently the source of user problems • Pseudo Terms can also be created with filters

15. SIS_Terms Date Fields • Beginning/First Schedule Date • Last Add Date • Last Drop Date • Last Schedule Date • Date 1 must be earlier than Date 2 • Date 3 almost always same as Date 2 • Date 4 must be in the future to see term

16. Last Drop Date • Probably not your actual last day to drop courses • It is the last day that the computer will allow students to drop via the web. • Typically set to the last day of a “free” drop/add period, and therefore usually equals the last add date

17. Add and Drop dates • In most recent versions, both dates can be overridden by optional date fields in the COURSE file. • If COURSE file date fields are present, and contents are non-blank, its value is used, otherwise value from SIS_Terms is used.

18. Last Schedule Date • Last date that term is displayed in term selection list in any option. • Should be set later than end of term to allow for Report Cards to be viewed. • Should be set to a date earlier than when corresponding Type 1 records are removed from REGDAT

19. SIS_Terms File • Errors in setting dates a frequent support call issue. Misunderstood usage or inadvertent year errors overlooked. • SIS_Terms used to generate .DAT files which directly control the system. • DAT files are rebuilt upon first use after midnight. • Delete the .DAT files to cause data changes to be effective immediately.

20. RegCode File DPT records • REGCODE records with keys starting with “DPT” are used to build the drop down list to select departments. The Field 2 contents of these records appear in the display. • Therefore, any COURSE file records containing a .DEPARTMENT data that will not translate via REGCODE will be inaccessible to web registration.

21. RegCode File DPT records (2) • If using the Portal API, any DEPARTMENT value MUST be properly represented in REGCODE. • Although RegCode DPT records were always supposed to have been entered routinely, some clients have used the registration system without keeping this data current.

22. RegCode File DPT records (3) • This department data is also stored in a DAT file as described previously. To have any REGCODE DPT changes or additions to take effect immediately, delete the DAT file; otherwise changes will not appear until after midnight.

23. Course File .COURSECODE field • Records add to the COURSE file must have a unique value in the .COURSECODE field to be properly recognized by CampusConnect. • Another frequent support call problem

24. Apache$Root:[Conf]Httpd.conf • Text file which controls options and parameters for the Apache web server. • Actual parameter settings are interspersed between comments something like a DCL procedure. • Make changes with extreme caution! • Change take effect on next startup of Apache.

25. Apache$Root:[Conf]Httpd.conf • Parameters effect the number of processes Apache can run, so you may wish to change values seasonally. For version 1.3 Update 2: • MinSpareServers • A small number 3-5 • MaxSpareServers • Approximately 3x expected concurrent users if doing drop/add • Approximately 1x expected concurrent users if not • StartServers • Equal to MaxSpareServers • MaxClients • try 3 times # of concurrent users

26. Special Logical Names • Logical names used to control many CampusConnect features • Logical names usually defined in [Campus_ConnectV2]Login.com, or they may be in an SIS_Config.com file or FAS_Config.com file called by Login.com. • CC may use logical names which can be created system-wide or per process.

27. Special Logical Names • System-wide logicals make for easy, on the fly control of CampusConnect. • Note timing of changing a logical name value in LOGIN.COM on a process logical – It is executed when an Apache thread is initiated….and the thread may process many transactions before regenerating itself.

28. Special Logical Names • CC$SIS_Timeout controls when an automatic logout should be performed based upon user idle time of a student user logging into CampusConnect with an ID number and PIN. The timeout allow will be equal to 30seconds times the value of this logical.

29. Special Logical Names • CC$Course_Filter may be defined to a value that matches a field name found in both the Student and Course files. Students flagged with a particular piece of data in this field will only be allowed to select from courses flagged with the same value (such as a campus code).

30. Special Logical Names • CC$Dept_SortField controls which RegCode field is used to sort the list of departments appearing in the department drop-down boxes. • CC$DEPT_LIST may be defined as a text file to override the list of Departments that CampusConnect would automatically build. If used, strongly suggest that the file is not a .DAT file type. • CC$ALLOW_AUDIT to activate allowing students to select a class for Audit

31. Special Logical Names • There are CC$function_ENABLED logicals defined system wide to a value of either TRUE or FALSE to enable or disable a function button throughout the system for all users. • Similar CC$ADV_function_ENABLED for faculty users.

32. Special Logical Names • CC$Web_Depts may be defined to indicate the maximum number of crosslistings a course could have into various other departments. A field should be created in COURSE for each of these with a fieldname of .WEBDEPT1, .WEBDEPT2, etc. Default is zero.

33. Optional Fields • Student File .OKWebReg • Requires logical CC$Use_OKFlag to activate • Students with a “Y” can use drop/add • Consider the options to populate and/or clear this value via batch for various groups of students.

34. Optional Fields • Student File .HOLDn • Additional hold fields may be defined – discussed later. • Course File .WebExclude • A “Y” value suppresses this record from appearing in CampusConnect Drop/Add

35. Optional Fields • Course File .CCAvailDate • Overrides default value from SIS_Terms for this class section. • Course File .CCDropDate • Overrides default value from SIS_Terms for this class section. • Course File .CCAddDate • Overrides default value from SIS_Terms for this class section.

36. Optional Fields • Course File .WebDeptn • Contains crosslisted department code. • RegCode File .WebExclude • Causes a DPT record in Regcode to be excluded from the department list if the field contains a “Y”.

37. Defining Faculty Access Typical setup for a faculty member • Authorize a Username with • a unique UIC number • /ACCOUNT to be a valid value for FAS, typically ADVISOR. • Create a unique GENERAL identifier, usually comprised of a standard prefix followed by the username. • GRANT/ID idname username

38. Defining Faculty Access (2) 4. Add a diskquota record for the new UIC if diskquotas are used on the home drive. 5. Create a unique directory owned by the UIC, typically named the same as the username. 6. Define a mail forwarding command to route any mail sent to this new username to an appropriate mailbox.

39. Defining Faculty Access (3) 7.Optionally create or copy a login.com file for the user. If Telnet is not intended to be utilized by this user, the login.com may contain LOGOUT or perhaps allow the user to change their password and then force them to logout. 8.Place Identifier in the .OWNERID field of COURSE records taught by this person to allow grading and roster access to these class sections. (Default is no access.)

40. Defining Faculty Access (4) 9.Place Identifier in .AdvRegID field of any STUDENT record which needs to be restricted for only this person to advise. (Default is blank meaning all authorized FAS users may access student record.)

41. Defining Faculty Access notes • Identifiers are created through Authorize Add/ID command. • Identifiers may be UIC-based or “GENERAL” (without a UIC value mapped to it). • A UIC-based Identifier is usually automatically created when adding a new username with a value equal to the username.

42. Defining Faculty Access notes (2) • Therefore, when we must add a general identifier for this user, the username is already in use as a UIC-based identifier, so it is unavailable for assignment as a general identifier. We suggest you append a prefix onto the front of the username; using the same prefix for ALL of your FAS users.

43. Defining Faculty Access notes (3) • This then allows you to add a code prefix of this value to the COURSE .OWNERID field and the STUDENT .ADVREGID fields. Then the data entered into these fields may now be simply the username.

44. Holds based upon Student Data Holds are used to block a student from certain functions. For instance, we could tell the system to not allow a student that is on Financial Hold to access his or her transcript. • First select a field in the Student File which will be used to control a specific kind of hold. Typically this will be an existing data element.

45. Holds based upon Student Data (2) 2.Add a fieldname to Student pointing to this field number, and name the field Hold and a digit, such as Hold1, Hold2, Hold3, etc. Normal installation will have predefined Hold1 to point to the Academic Hold Field and Hold2 to point to the Financial Hold field. Use the next sequential Hold number.

46. Holds based upon Student Data (3) 3. Consider adding a code prefix to this field if one does not already exist. 4. Create (if needed) translation records in RegCode for each unique data value found in this new .HOLDx field.

47. Holds based upon Student Data (4) 5. Update these translation records, flagging the appropriate DISOPTIONx fields with a “Y” for any CampusConnect menu button which you wish to disable for a student that has this value in their record in their Hold field.

48. Holds based upon Student Data (5) For example, if a student has an “A” in field .HOLD1, and .HOLD1 has a code prefix of “ABC”, CampusConnect will search the RegCode file for a record with a key value of “ABCA”. If it finds the record, it will scan all of the .DISOPTION fields. Any field found marked will disable the corresponding CampusConnect Menu items.

49. Overrides to registration problems • STUDENT$DFLT_ACCESS is bit encoded logical which allows a student to automatically override selected problems, such as time conflict. • ADVISOR$DFLT_ACCESS allows an advisor to do the override.

50. Intermission