Introduction

We use the Special Event/Shortcourse Dataset to load the Room Scheduling System with events that are scheduled even before classes. The dataset contains things such as building hours, partial control hours, special reservations, construction, and other special events that should be scheduled before classes can be.
During production, unique numbers in the Course Schedule are resequenced multiple times in order to ensure classes are in the correct Course Schedule Order (which can get out of sync as departments are adding classes and cancelling classes throughout the course scheduling process). When we resequence, we 'unload/reload' all of the class day reservations in GPCs, including the courses (based on file 60 records), and any events scheduled in the Room Scheduling System. The dataset allows us to put the reservations made back into the Room Scheduling System each time we dump and reload throughout production.
We start to work on the dataset before we rollover the semester, and is maintained through the end of course schedule production (over a period of several months).

Class Days vs. No-Class Days

As class timelines only affect class days, we only dump and reload class days. Thus, no-class day reservations can be documented in the 'No-Class Day' txt file and then made directly in the Room Scheduling System as soon as all requests have been received and vetted.

Timing

It is necessary to do almost all of the work on the dataset before the beginning of Original Phase, as building/control hours, construction, and reaching out to event stakeholders can all be done in advance.
1. The GPC list is created around 1 month before the course scheduling roll-over. (By the GPC point person)
2. Stakeholders are contacted in the same timeframe.
The dataset should be complete before automated scheduling. While the dataset can be uploaded at any time, the first unload/reload is the first step of HAL (automated scheduling), so the reservations will not show up in the room scheduling system until this point.
1. When the dataset is uploaded (and each time it is re-uploaded) AUDTSPEC should be ran to make sure all dates are in the current semester.
2. After the first unload/reload, we can also run a conflicts report to track any conflicts internally within the dataset.
From the first unload/reload until post production, any changes to the dataset will need to be both scheduled in the Room Scheduling System, as well as updated in the text document. The updated text document will then need to be reloaded into the mainframe.
1. When we unload the RSS reservation will be deleted; but the text document in the mainframe will replace the reservation.
After final unload/reload, all TBA reservations can be made in the room scheduling system after the semester-long events have been deleted. Remove 'TBA' from the title at this point.
All reservation confirmation emails for dataset stakeholders should be double-checked one final time before sending out emails the day advance copy/CSU opens. (final review)
1. Send out confirmations by copying and pasting confirmations into emails rather than sending directly from the RSS, as the confirmation can be included in the ongoing email chain.

Naming Conventions

Dataset Naming

We have one dataset for each semester:

Fall: sttd1573
Spring: sttd1572
Summer: sttd1574

Confirmation Numbering Systems

Each dataset (for each semester) has three parts:

Building hours and partial control: Numbered CCYYS-1000x
1. The reservations should be in order by building and room (as reflected on the GPC list) however to facilitate proofreading.
2. Note that we use different confirmation numbers for different reservation purposes in the same building. For example, building hours in GDC will have a different confirmation code than partial control agreements in GDC.
3. This step uses the Building and Control Hours Spreadsheet (see below section)
Construction: Numbered CCYYS-2000X
1. Coordinate with the construction point person to ensure that any known construction projects are blocked out in the dataset.
2. Confirmation numbers should be in order by building and room.
Special Events: Numbered CCYYS-3000X
1. All other reservations including class meetings.
2. Space new special event dataset reservations out in increments of five. This ensures that reservations that are longer will have enough confirmation numbers to keep them grouped together.
3. In summer only, start orientation requests at confirmation code CCYYS-3500X, and space out each day in increments of five. When orientation adds additional requests, we like to be able to keep reservations for each day together in a cohesive manner.

Formatting of Dataset**

Each entry must be formatted in a standardized form in order for the text file to be read correctly by the system – and thus properly reserved in the room scheduling system. Reservations take two forms: single day or semester-long. Each entry is separated by a row of dashes to designate a new entry.

Single Day Requests*

------------------------------------------
MMDDYY*TIME*TIME*BLDG*RM#10DIGITCONFCODE
Office/Department Requesting
Person in Charge (EID)
Contact Person (EID)
Event Title/Description
Initials of Updater
------------------------------------------
For example, a request for December 3^rd, 2016 for Institutional Testing might be as follows:
------------------------------------------
120316*0630*1400*UTC*4.132*2016930001*
Learning Sciences
Mellanie Patterson (mpe65)
Mellanie Patterson (mpe65)
Institutional Testing
NET
------------------------------------------

Semester-Long Requests*

Semester-long requests follow the same format as above, with days of the week replacing the date:
----------------------------------
MTWTH*1500*1900*ART*1.102*2016930002*
DEPARTMENT OF ART AND ART HISTORY
Janet Bizzell (jbizz)
Janet Bizzell (jbizz)
Lecture Series
NET
----------------------------------
*Remember, class days are all days of the week except for Sundays. You cannot include more than five days in a single entry. Therefore, if you need to block off all "class days" for a room you will need to create two separate entries for the room (one for MTWTHF, and one for S). (Since Sundays are never class days they would never be represented in these datasets). Days of the week must be in capital letters (so Thursday must be indicated as TH not Th). Event beginning and ending times use a standard 24-hour clock format (without AM or PM designations). Rooms are scheduled from 0630 to 2345 in standard 24-hour clock format (or 6:30 AM to 11:45 PM).

- Up to 5 reservations can be entered on one dataset entry; for example, MTWTHFS would be six different reservations, the dataset entry would have to be entered as MTWTHF with S separate.
  TBA Requests
  Some requestors will only need a room for part/half of a semester. Rather than reserving these rooms by individual date in the dataset (which is tedious, and more prone to error), the rooms should be reserved as a semester-long reservation, and can later (after the final unload/reload) be added to the room scheduling system as day-by-day reservations.
  These reservations should be documented in the 'TBA' file. The event title must begin with 'TBA'
  Example:
  In the Special Event Dataset:
  MTWTH*1700*2200*UTC*3.102*2016930003*
  RED MCCOMBS SCH OF BUSINESS
  Amy Janecka (amj3258)
  Amy Janecka (amj3258)
  TBA McCombs Recruitment Services Events
  NET
  In the TBA file:
  20169-30003
  amj3258, 5-10pm
  TBA McCombs Recruitment Services Events
  UTC 3.102, 3.104, 3.110, 3.112
  August 24, 25, 29, 30, 31
  September 1, 6, 7, 8, 12, 13, 14, 15, 19, 20, 21, 22, 26, 27, 28, 29
  October 3, 4, 5, 6, 10, 11
  'Rolling Over' the Dataset
  
  Preparation

Create a new folder on the server for the new YYS, and save copies of documents from the last like semester into the folder. The folder should contain three text documents, and two folders
1. The dataset itself (named sttd157X)
2. No Class Days document (list of requests for no-class days to be made in RSS)
3. TBAs (List of events in DS as semester-long that will be converted to date by date)
4. 'Correspondence' folder for emails
5. 'Backup' folder to save copies of the dataset as we make edits- the backup copy will also be saved in this folder.
Copy forward the above documents from the last like semester folder.
Download a copy of the like semester dataset from the server.

\\austin.utexas.edu\disk\reg\Registrar\Course Scheduling\2. Production Phases\Original Phase\Short Course Dataset\Upload-Download to Mainframe.docx

1. Save the downloaded dataset as a backup in the last like semester folder (in the Backup folder)

Soliciting Requests for Upcoming CCYYS

Once the server folders have been created and formatted, requests can be solicited from stakeholders. The stakeholders will be the same as those from the preceding like semester. Any new requests must be approved by the Assistant Registrar.

Use folders from the last like semester to find emails in order to identify stakeholders.
1. Any one-time-exceptions from the last like semester should have been labeled 'OTE;' these stakeholders should NOT be contacted again, as they do not carry forward
2. Typically the stakeholders are as follows:

Long Semesters (Fall/Spring)

Institutional and Standardized Testing – Mellanie Patterson Nazy Sheikhzadeh
GDC Partial Control Requests – Liz Flynn Terry Tibby Jasmine Gonzalez Michaela Cicero
College of Pharmacy Events and Meetings – Janet Larsen
Art Lecture Series –Michelle Fandrich
McCombs Recruitment Services Events – Cynthia Vassallo (1^st) Mandy Kious (2^nd) Shannon Hickson Amy Janecka (TBA request; reserve semester long and break up into date by date reservation confirmations after final resequence); Only should be given business classrooms, as they that is why they are in the dataset.
Construction – Jill Stewart

Summer

Institutional and Standardized Testing – Nazy Sheikhzadeh Mellanie Patterson
GDC Partial Control Requests – Liz Flynn Terry Tibby Jasmine Gonzalez Michaela Cicero
College of Pharmacy Events and Meetings – Janet Larsen
Art Lecture Series – Janet Bizzell
Breakthrough- Steven Miller Kaley Aguero Ricardo Avila (Needs RG 750. Typically must schedule in conflict with Institutional Testing/Orientation)
Language Institute – Denise Beachum (Needs RG 750)
Orientation – Celena Miller/ Cristian Jennifer Carter (Use 3 confirmation numbers each for day 1, 2, and 3 of freshman orientation to allow for future changes without running out of space)
DO NOT Reach out, but if we receive a request from Texas Summer: Texas Summer gets added to DS for RLP rooms only. Trumps anyone else also asking for room. This is per an informal agreement w Dr. Tenbarge. The request would come from Maggie Wilhite. (TBA request; reserve semester long and break up into date by date reservation confirmations after final resequence)
Construction – Jill Stewart

Use the email templates (Email Template A, below) to solicit requests from stakeholders. Be sure to ask for EIDs of both the person in charge and the contact person. Give a deadline of 1-2 weeks for their responses.
1. NOTE that GDC has until the end of original phase to send in their requests; the email template to reach out is slightly different for this building. See Email Template B

Editing and Updating Dataset*

Logistics

Class days are all days of the week except Sunday. In order for the dataset in *UEDIT to populate RSS correctly, you cannot include more than five days in a single entry.
Days of the week must be in capital letters (so Thursday must be indicated as TH not Th).
Event beginning and ending times use a standard 24-hour clock format (without AM or PM designations). Rooms are scheduled from 0630 to 2345 in standard 24-hour clock format (or 6:30 AM to 11:45 PM).
Editing the existing dataset to include new days and times is preferable in order to keep consistent formatting.
As the unload/reload process never affects class days, these reservations can be made in the room scheduling system as soon as the system is available to make reservations. For consistency, coordinate reservation confirmation codes with class day reservations in the dataset.

- - - Remember that summer is very different. ****

Start with building and partial control hours in the dataset (Reservation confirmation # CCYYS-1000X). Use the Building and partial control hours spreadsheet saved on the server to edit/check last semester's hours for accuracy.
1. Again, no-class days can (and should) be made directly in the RSS and documented in the 'No-Class Day' txt file.

\\austin.utexas.edu\disk\reg\Registrar\Course Scheduling\1.General Purpose Classrooms\GPC Master Lists\Building & Control Hours.xlsx

Coordinate construction (Reservation confirmation #CCYYS-2000X) with team member who is point person for construction projects. This person should look at the immediately preceding semester's projects and reach out to the project managers to ensure that the projects will be complete by the start of the new semester.
1. In the summer, Jill Stewart (Senior Project Manager, Project Management Division for the Classroom, Office & Auxiliary Section) should also be contacted regarding any construction projects. (See GPC maintenance documentation for more information)
2. Don't forget no-class days in the RSS!
As dataset requests are returned from stakeholders, save the emails in the file on the server, and update the dataset with requested rooms and dates. Pay attention to any no-class day requests, as these should be added to the 'no-class day' document, and reserved in the RSS.

*As a note, *UEDIT can be updated for minor changes instead of having to re-upload and the dataset for one-character (or so) updates.

To add a line, put cursor in first column of text; type '.i' to insert line; '.d' will delete
Once changes have been made, the changes can be saved by typing 'rsave' in the first row and first column of the text. Leave the text file and re-enter to double check.

Proof Dataset

NOTE: It is *very important to ensure that the room number inputted into the text document actually exists and is the correct room!

After all (or most) requests have been received and added/updated in the dataset, have a colleague double check the dataset requests with the text documents.
Have the colleague also check the no-class day reservations made in the room scheduling system with the requests and the text document.
1. No-class day reservations are best checked with the Delsey letter and the semester-long reservations report
2. Once the class-day reports have been uploaded, they should also be checked with the Delsey letter and the semester-long reservations report

Upload Dataset to the Mainframe

The dataset can be uploaded to the mainframe at any point between 'rolling over' the semester and the first unload/reload which happens as the first step of automated scheduling (Hal). After it has been uploaded into the RSS (at Hal), any changes must be made to the text document, and that document will need to be re-uploaded to the mainframe to replace the existing document.
For a how-to/specific steps for uploading the dataset:

Tools

SSH Secure Shell SFTP Transfer Client (https://its.utexas.edu/bevoware/download/)
- Stache Password for rgsched is already incorporated in new desktop version of SSH Secure Shell SFTP Transfer Client
Mainframe

Naming

Note that naming is case sensitive and file name has to be LOWERCASE on the server or job will fail

sttd1572 will always be the name of the spring short course dataset
sttd1573 will always be the name of the fall short course dataset
sttd1574 will always be the name of the summer short course dataset

When to Upload/Download

The dataset should be downloaded at least once when CSP is making preparations to work on the dataset for a new semester. The dataset for the last like semester should be downloaded from the mainframe, and saved as a back-up copy in the last like semester folder.

For example, if CSP is starting work on the 179 semester, the 169 dataset should be downloaded from the mainframe and saved in the 169 folder on the server with a title indicating that it is a back-up ("sttd1573.169.backup")

Anytime edits are made to the text document dataset after the initial upload (which normally happens before original phase), the text document saved on the server should be re-uploaded to the mainframe to replace the now out-of-date dataset. Note that edits to the dataset will not be reflected on the RSS until the next unload/reload. SO if changes are being made between HAL and the final unload/reload, changes should be made in the room scheduling system IN ADDITION to the text file- otherwise conflicts can be scheduled.

Summary

Uploading the text file to the mainframe/vice versa is a two-step process:

Transferring the file from the server to the secure file upload system;
Transferring the file from the file upload system to the

To download the file it is the reverse!

Downloading Dataset

Make sure *UEDIT is closed (in the mainframe)
Transfer file from mainframe to secure file upload
1. *TXTASK
2. Command: SSJ; Name: RGJGFTPH; Version: P; Department: RG

Select the job version to download by marking an 's' in the corresponding blank

Once the job has ran to transfer the file (can check *UTQA to confirm), login to the 'rgsched' account on the transfer.its.utexas server (also known as the secure file uploading system/SSH Secure Shell SFTP Transfer Client). Logon information is saved in Stache.
1. The file should be on the right-hand side of the screen

Download the file into the appropriate folder on the server by selecting and dragging file.

Uploading Dataset

Transfer file from server to transfer.its.utexas.edu (STFP client)
1. Open SSH Secure Shell SFTP Transfer Client (aka transfer.its.utexas.edu)
2. Log into 'rgsched' account (using logon information found in Stache)
3. Upload or drag dataset file into transfer server
4. Confirm that the transfer has processed using the transfer queue box at the bottom of the window.
5. You are done with the SSH Secure File Transfer- you can close it out!

If a dialogue box pops up and asks if you want to replace a file, select 'yes'.

Go to the mainframe to delete existing file:
1. Mainframe: *UEDIT
2. Library: o3, Member: 'dataset name'.
3. Tab down to delete. Mark X.

1. You can check to ensure that the file has been deleted by hitting 'enter' again with the library and member information inputted as in part 'b.' above. You should receive the message 'Member not found'.

Upload file via Mainframe
1. Mainframe: *TXTASK
2. Command: SSJ, Name: RGJGFTPH, Version: P, Dept: RG
3. Mark 's' next to the appropriate action

Check dataset is uploaded in Mainframe: *UEDIT
1. Library: o3, Member: 'dataset name'

The file should appear as expected. Confirm correct file is uploaded by scrolling down to view most recent changes made.
To navigate:

F1 brings you back to the top
F4 scrolls down

Run AUDTSPEC/Conflicts Report

Once the dataset has been uploaded to the mainframe, AUDTSPEC should be ran. (Dataset does not have to be loaded to the RSS in order for this job to audit the file.) The output from this job will indicate if a date in the dataset is outside of the date range for the CCYYS in question, such as a holiday (or any no-class days) or the intersession before or after the term.

For detailed steps on running AUDTSPEC, including additional job limitations see:

Introduction

AUDTSPEC is a job used to audit the dataset information for any dates that do not belong in the dataset. This job will identify most dates that are improperly input into the system, as well as any dates that fall outside of the dates in the table for the semester in question.

Job Limitations - Typos

Note that the job will only identify days that are inputted correctly and fall outside of the academic calendar/that are inputted as an unrecognizable date. Typos that result in a different date that falls during the same semester will not be flagged by the job as incorrect.
For example, the system can recognize that this entry for July 6^th, 2017 is incorrect (as the year should be '17' not '2017');
------------------------------------------
07062017*0630*1400*UTC*2.112A*2016930001*
Learning Sciences
Mellanie Patterson (mpe65)
Mellanie Patterson (mpe65)
Institutional Testing
AH
------------------------------------------
But the job will not be able to recognize the error in this entry for July 6^th, 2017 (the date entered is actually for June 7^th, which also falls during the summer semester, and is a valid date):
------------------------------------------
060717*0630*1400*UTC*2.112A*2016930001*
Learning Sciences
Mellanie Patterson (mpe65)
Mellanie Patterson (mpe65)
Institutional Testing
AH
------------------------------------------

Job Limitations – Conflicts

This job will also not check conflicts between reservations. Once the dataset has been loaded into the Room Scheduling System, a conflicts report should be ran to ensure that there are no conflicting reservations for class days.

Job Limitations – Incorrect Rooms

Incorrect or non-existent rooms are also not recognized by the job. It is very important to ensure that the room number inputted into the dataset actually exists, and is the correct room! Inputting the wrong room information can be a major headache if you think you have blocked out a room that doesn't exist. It can be very difficult to remove 'reservations' made in the dataset in rooms that don't actually exist.

Running the Job

In *TXTASK, input:

Command: ssj
Name: rgjgsch1
Version: p
Dept: rg

Hit <enter> several time until you start to see the AUDTSPEC jobs:

RGNWASR2 – Spring
RGNWASR6 – Summer
RGNWASR9 – Fall

Insert a 'Y' in the blank space corresponding to the job needed.
1. When prompted, input YYS for semester in question.
The job will spit out a control card to your GreenOutput, and will print a copy of the actual report.
Evaluate the report for any dates that are indicated as out of the semester dates. Make changes as necessary.
The audit does not check for room conflicts of any sort. Run a conflicts report once the dataset has been loaded into the Room Scheduling System.
1. Intentional conflicts must be documented. Suggestions to track conflicts include printing out GPC lists and highlighting in different colors who has what. Alternatively, you can keep a spreadsheet and sort alphabetically by building to determine if there are any room conflicts among the special reservations.

Working conflicts report documentation:
\\austin.utexas.edu\disk\reg\Registrar\Course Scheduling\12. Internal Projects\Streamlined Documentation-in progress\Functional Processes\Working Reports\Conflict in GPC Report (NRNWCMCG).docx

Maintaining the Dataset

The dataset needs to be maintained throughout production of the semester course schedule. After the dataset has been uploaded to the mainframe for the first time (before Hal), every time an update needs to be made, it must be made in both the text document and the mainframe.
After Hal, any reservation that is changed will have to be updated on the text document, in the mainframe and in the room scheduling system, as the mainframe file is only uploaded to the room scheduling system with every unload/reload.
Larger changes are best done by editing the text document and re-uploading it to the mainframe; small changes/corrections can be done separately by editing *UEDIT and the text file.

Finishing and Confirming Dataset Reservations

Final Unload/Reload

After the final unload/reload at Advance Copy, TBA reservations should be made as day-by-day events and then delete semester-long reservations in the room scheduling system.

Send Confirmations

Dataset reservations can be sent to stakeholders the day Advance Copy and CSU opens. Reservations should be copied and pasted into the ongoing email chains with stakeholders.
Any changes after this point can simply be made in the room scheduling system; there is no need to update the dataset or the text document with requestor changes. (Especially as we no longer send out last year's reservations for stakeholders to use.)

Email Templates

Email Template A

This email should be used for all stakeholders with the exception of GDC (use template B):
Hi <span style="color: #ff0000"><ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="ff99de4e-ff3a-480b-9012-bbe34dfefbbe"><ac:plain-text-body><![CDATA[[contact]

, \\ Scheduling is preparing to schedule rooms for the

[semester, year]

. I wanted to touch base regarding your request for

[insert event]

. If you require a reservation for the

[semester year]

semester, please let me know and send me \[day(s) or date(s)\]/time(s) by

[month date, year]

. Please be sure to include the EID and name of both the contact person for this event, and the person in charge of the event in your request. \\ Important dates for the

[semester, year]

semester include:]]>

Class days:
[day-day]
Final Exam days: <span style="color: #ff0000"><ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="13c09a85-fb9e-41a0-b9bd-9279304b139c"><ac:plain-text-body><![CDATA[[day-day]
\\ To see what rooms we are able to schedule, please take a look at our most recent General Purpose Classroom list online at [http://registrar.utexas.edu/staff/rooms|http://registrar.utexas.edu/staff/rooms]. The Academic Calendar dates for this semester can be found online at [http://registrar.utexas.edu/calendars|http://registrar.utexas.edu/calendars]. Please also keep in mind that Sundays, holidays and days after the last class day are no class days. \\ As a reminder, if this event is inviting non-UT participants to campus, or charging a fee, an RG 750 form will be necessary before we can process your request for rooms. The form can be found by following the below link. [https://utexas.app.box.com/v/rg750|https://utexas.app.box.com/v/rg750] \\ Please let me know if you have any questions. \\ Thank you, \[Your Name\] \\]]>
Email Template B

Hi Liz, (cc: Patti)
Our department preparing to schedule C S special priority event requests to be scheduled in partial control GPCs in GDC for the [semester year] which begins <span style="color: #ff0000"><ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="68c12a29-e7f3-4b5f-ba37-b0c0028e6a70"><ac:plain-text-body><![CDATA[[first class date]
and ends
[last class date]
. Please send us your
[semester year]
requests as early as possible.* Just a reminder that these partial control requests cannot exceed 50% of the GPC-controlled time on a particular day. \\ Thank you, \[Your Name\] \\ *Do not set arbitrary deadline for GDC requests. Computer Science has *until the end of Original Phase* to report requests in partial control GPCs in GDC. *GDC Partial Control Rooms (1.304, 2.216, 4.304, 5.302)* *M-F 8:00 am-12:30 pm* Computer science classes will have priority if requested by original phase. The earlier the request is received, the better. +Computer Science department to provide list by original phase of no more than four to five repeating non-class activities that should be scheduled in partial control GPCs between 8:00 a.m.-12:30 p.m. These partial control requests cannot exceed 50% of the GPC-controlled time on a particular day. Following original phase (distributed), the room becomes available for other departmental class/non-class activities between 8:00 a.m.-12:30 p.m.+ \\]]>
Email Template C – Construction Projects

Hi Jill,
I hope this email finds you well. Our office is preparing to work on the
[semester year]
course schedule with the first class day beginning
[first class date]
and the last class day being
[last class date]
. I wanted to reach out to you to see if you knew of any construction projects that will affect the availability of general purpose classrooms during this time.

Please let us know when you have a moment. Thank you!

Browser not supported