Banner Development Environment

This document attempts to represent the current status of the development environment, current policies for development, and documentation of useful procedures for development. Since this document is supposed to reflect the world as it should be, we aim for it to be complete and precise. When changes are made here, you will be notified by email. Please email me your questions and or suggestions about this document.

Only minor changes have been made to the standards in this document since its previous update in 2001. However, some items may still be out-of-date. In particular, this document does not yet address Workflow objects.

If you have any comments or questions about a portion of the document, please let me know.

Who is Eligible?

Active Faculty or Staff

Policy Regarding Updates to Ellucian-Supplied Code

Updates to baseline code will only be applied when installing patches from Ellucian or an approved third-party vendor, or when instructed by Ellucian in the course of resolving a problem. Exceptions must be approved by the CIO.

When such an item is to be changed, the baseline version will remain in its original location in the code tree and be appended with the Banner Version. Likewise, the OU modified version should be appended with the Local Version. The locally modified version must be placed in the corresponding shadow location under $BANNER_HOME/oakmods. For example, if you are changing $BANNER_HOME/general/misc/gjajobs.shl, you would have versions named like below. Also, you will name the OU Modified version with the you will place your modified copy in $BANNER_HOME/oakmods/general/misc/gjajobs.shl. You will then go to the $BANNER_LINKS directory and create a symbolic link to the location of the local modification.

• $BANNER_HOME/general/misc/gjajobs.shl.banner#####
• $BANNER_HOME/general/misc gjajobs.shl.local#####
• $BANNER_HOME/oakmods/general/misc/gjajobs.shl (The $BANNER_LINKS/gjajobs.shl should point to here)

This policy does not apply to locally developed code, non-Ellucian delivered. Please refer to the article on Creating a new Banner object.

Shell script conventions

Handling Passwords

When a script must request a password from a user, it should not be displayed on the user's screen. For shell scripts, this can be accomplished using the following code.

# Prompt for the ORACLE password
while [ "$PW" = "" ]
do
 echo "Enter password: "
 stty -echo
 read PW
 stty echo
done

Whenever possible, shell scripts needing to access the database should do so using the ID of the person running the script. In some cases, the ID of a different Banner user may be required; you must obtain approval from the DBA to create such jobs. The $BANNER_HOME directory for each database contains a file called .siboleth, which will have a line for each Banner schema owner and some other Banner accounts. Each line is of the form "USERID/password". In TEST, UTS staff may grep the file to get the line for the account you need, and use awk to separate the ID from the password. You may use the following example to build code to obtain the password for your job:

GENLPRD_PW=`grep GENLPRD $BANNER_HOME/.siboleth | awk -F/ '{print $2}'`
exp genlprd/$GENLPRD_PW log=/tmp/dualjunk.log file=dualjunk.exp tables=dual

You should use an environment variable to temporarily store any passwords that you use during the course of a job. If you must save the ID and password in a file, then you MUST set the permissions on the file so that only the user running the job can read the file, and you MUST also delete the file when you are done using it. An example is:

BANINST1_ID=`grep BANINST1 $BANNER_HOME/.siboleth`
echo "$BANINST1_ID" > tools/baninst1.rc
chmod 600 tools/baninst1.rc
sqlplus -s $(cat tools/baninst1.rc) @gzraltr_compile_invalid
rm tools/baninst1.rc

Be especially mindful of the use of backquotes (`) and single quotes (') in the above examples. If your code uses quoting that is different from the above examples, it will not work.

Job Output Security

As you may know, Banner classes and Oracle roles are used in Banner to allow and to restrict access to certain data. However, output from Banner jobs run on the job server have never been subject to the same restrictions - anyone witth access to the jobsub output directory could download the output of any Banner job, regardless of their classes and roles. In July 2016, we made changes to the $BANNER_HOME/general/misc/gjajobs.shl (for Banner jobs) and the $AW_HOME/exec/AW_BANNER to restrict job output access to only those persons who are authorized to submit those jobs. This works for jobs where the output files contain the job's ONE UP number in the file name.

Whenever possible, the output of a Banner job should contain BOTH the name of the job that created it and the ONE UP number from the job run (e.g. gzrjenv_68802.log, pwrtrpt_5925101.msg, &c).

In cases where this is not possible (e.g. the job creates an extract file for an external agency, and that agency requires the file to have a specific name), your shell script MUST contain the following snippet of code after your sqlplus statement so that the job's submitters may access the output:

ssh -i /usr/local/etc/secure_connect.id oracle@localhost chmod 660 $BANJOBS_HOME/utlfile/szrvger.txt
GENLPRD_PW=`grep GENLPRD $BANNER_HOME/.siboleth | awk -F/ '{print $2}'`
sqlplus GENLPRD/$GENLPRD_PW @gzrlusr $PROG > $BANJOBS_HOME/gzrlusr_${ONE_UP}_2.lis
echo > $BANJOBS_HOME/gzrlusr_acls_${ONE_UP}_2.shl
cat $BANJOBS_HOME/gzrlusr_${ONE_UP}_2.lis | grep -E "^USER" | while read strLine
do
    strName=`echo $strLine | awk '{print $2}'`
    if [ "`eval echo ~$strName | colrm 2`" == "/" ]
    then
        echo "setfacl -m user:$strName:r-- $BANJOBS_HOME/utlfile/your_output_file" >> $BANJOBS_HOME/gzrlusr_acls_${ONE_UP}_2.shl
        ## the above statement is an example - you must include a copy of the above statement for each output file created by the given job which does not have the ONE_UP number in the name
    fi
done
echo "exit 0" >> $BANJOBS_HOME/gzrlusr_acls_${ONE_UP}_2.shl
ssh -i /usr/local/etc/secure_connect.id oracle@localhost sh $BANJOBS_HOME/gzrlusr_acls_${ONE_UP}_2.shl What does this code do anyway?

You may note that some shell script code contains the following lines:

if [ -f temp1.sql ]
then
 /bin/rm temp1.sql
fi
#
if [ -f temp2.sql ]
then
 /bin/rm temp2.sql
fi
#
if [ -f temp3.sql ]
then
 /bin/rm temp3.sql
fi

This code is specific to the RCMATCH process in Financial Aid, which creates temporary SQL scripts, runs them, and deletes them afterward. Since the first programmer on our staff who created a Banner shell script used rcmatch.shl as the model, this code was left in because they didn't know why it was there. Unless the SQL script that is called by your shell script specifically created the temporary files temp1.sql, temp2.sql or temp3.sql, you should remove the above section of code from your shell script.

You may also note that some shell script code contains the following lines:

###########################################
# not sure what this does most SCT
# shells have it so leave it
###########################################
N=
C=
if echo "\c" | grep c >/dev/null 2>&1; then
   N='-n'
else
   C='\c'
fi

This code is used to determine how the operating system implements the echo command. When the echo command is executed, both $N and $C are used when you want the echo to not include a carriage return; this is useful when the shell script needs to prompt the user for information. For example:

echo $N "Enter user-name:" $C

So, now that you know what it does, please remove the "not sure what this does" comment; it looks more professional.

Generating E-mail

All jobs that generate e-mail messages must adhere to the following standards:

• All e-mail notifications initiated by scripts or processes must be sent to listserv or department addresses, or to groups defined in /etc/aliases on the job server. No hard-coded individual e-mail address should ever be included in a script or process as a notification mechanism'; in particular, no notice is EVER to go to individual members of UTS.
• General listservs already exist for operations and other generic purposes. Existing listservs should be reused whenever possible.
• If a new listserv is required for e-mail distribution, the appropriate form from the UTS Accounts web page must be submitted.
• Generated messages should contain in a prominent place a statement similar to the following: "This message was automatically generated by the system. Please do not reply to it. If you wish to report a problem with the process that created this message, please send e-mail to uts@oakland.edu ."

​​​​Additional Support

• OU Technology Center
• 44 Oakland Center
• Rochester, MI 48309-4479
• (248) 370-4357
• Office Hours: M-F 8:00am - 5:00pm