PeopleSoft nVision files can have 8 bytes for their names, and each name must be unique. However, Queries and nVision files can have the same names, if necessary. The Financials Team requires a different naming structure than the other project teams.

The following naming conventions apply to all U of U added nVision files:

Financials System:

Business Unit abbreviation:	Use 1 Character Business Unit Abbreviation
Tool abbreviation:	"V"
Application abbreviation:	Use 1 Character Application Abbreviation
Report Frequency abbreviation:	Use 1 Character Report Frequency Abbreviation
Sequential Number:	The first byte can be an alpha character, if needed. The numeric portion must be padded with leading zeros to fill the eight byte name.
Degree of Detail abbreviation:	Use 1 Character Degree of Detail Abbreviation
File Name Extension:	".XNV"

Format:

[Bus. Unit]

+

["V"]

+

[Application]

+

[Frequency]

+

[3 Digit Unique Number]

+

[Detail]

+

[".XNV"]

required

required

required

required

required

required

required

Example:
"UVGDK07S.XNV"

All other systems:

Required prefix:	"UV"
Application abbreviation:	Use 2-3 character Standard Project/Module Abbreviations
Sequential Number:	The first byte can be an alpha character, if needed. The numeric portion must be padded with leading zeros to fill the eight byte name.
File Name Extension:	".XNV"

Format:

["UV"]	+	[2-3 Character Application Abbreviation]	+	[3-4 Digit Unique Number]	+	[".XNV"]
required		required		required		required

Example:
"UVAD0012.XNV"

The production library/database should be used by the developer to assign the sequential number portion of the name. The developer is responsible for making sure the names assigned on a development library/database HAVE NOT already been used in production. ACS Quality Assurance WILL NOT check to be sure that a name being upgraded has not already been used by another developer. To reserve the sequential number portion of the name, developers should take the steps necessary to put an empty definition on the production library/database with the next sequential number.

All output files should have the same name as the nVision program that created them. If an nVision program creates more than one output file, then append an alphabetic character to distinguish the file names (a, b, c, etc.). The output files should have ".XLS" file name extension.

Strict adherence to these standards will prevent naming nVision files that cannot be identified back to a system or that overlay an existing object.

Return to Table of Contents

PeopleSoft (version 7.0 and higher) SQR programs can only have 8 bytes for their names, and each name must be unique.

SQR programs with related Process Definitions must have the exact same name as the Process Definition and the external program. The Process Definition only allows 8 character names, even though longer names can be used for other related object types.

The following naming conventions apply to all U of U added SQR programs:

Required prefix:	"US" for standard programs, or "UD" for Conversion/Database Synchronization programs
Application abbreviation:	Use 2-3 character Standard Project/Module Abbreviations
Sequential Number:	The first byte can be an alpha character, if needed. The numeric portion must be padded with leading zeros to fill the eight byte name.
File Name Extension:	".SQR"

Format:

Standard programs:	["US"]	+	[2-3 Character Application Abbreviation]	+	[3-4 Digit Unique Number]	+	[".SQR"]
Conversion/Database Synchronization programs:	["UD"]	+	[2-3 Character Application Abbreviation]	+	[3-4 Digit Unique Number]	+	[".SQR"]
	required		required		required		required

Examples:

Standard programs:	"USAD0012.SQR"
Conversion/Database Synchronization programs:	"UDAD0007.SQR"

If the SQR program is used in conjunction with a Crystal report, both the SQR program and the related Crystal report should have the same name.

All output files should have the same name as the SQR program that created them. If an SQR program creates more than one output file, then append an alphabetic character to distinguish the file names (a, b, c, etc.). The output files should have the appropriate file name extension for the type of file created (e.g., ".CSV" for comma delimited, ".TXT" for text, ".LIS" for PeopleSoft SQR output, etc.)

Strict adherence to these standards will prevent naming SQR programs that cannot be identified back to a system or that overlay an existing object.

Return to Table of Contents

PeopleSoft SQC copybooks can have very large names. However, good sense suggests keeping names a reasonable and manageable size, say, something less than 50 characters. Each name must be unique, and should be descriptive of the SQCs function.

The following naming conventions apply to all U of U added SQC copybooks:

Required prefix:	"US" for standard program copybooks, or "UD" for Conversion/Database Synchronization program copybooks
Application abbreviation:	Use 2-3 Character Standard Project/Module Abbreviations
Copybook Name:	Any combination of alpha/numeric characters less than about 50 characters. Name should be descriptive of the SQC's function.
File Name Extension:	".SQC"

Format:

Standard programs:	["US"]	+	[2-3 Character Application Abbreviation]	+	[Alpha/Num. chars. not to exceed about 50 bytes]	+	[".SQC"]
Conversion/Database Synchronization programs:	["UD"]	+	[2-3 Character Application Abbreviation]	+	[Alpha/Num. chars. not to exceed about 50 bytes]	+	[".SQC"]
	required		required		required		required

Examples:

Standard programs:	"ussr_interface_getval.sqc"
Conversion/Database Synchronization programs:	"udar_addr_parse.sqc"

For SQC coding and development practices, see Standard #7b.

Strict adherence to these standards will prevent naming SQC files that cannot be identified back to a system or that overlay an existing object.

Return to Table of Contents

PeopleSoft (version 7.0 and higher) COBOL programs can only have 8 bytes for their names, and each name must be unique.

The following naming conventions apply to all U of U added COBOL programs:

Required prefix:	"UB" for standard programs, or "UD" for Conversion/Database Synchronization programs
Application abbreviation:	Use 2-3 character Standard Project/Module Abbreviations
Sequential Number:	The first byte can be an alpha character, if needed. The numeric portion must be padded with leading zeros to fill the eight byte name.
File Name Extension:	".CBL"

Format:

Standard programs:	["UB"]	+	[2-3 Character Application Abbreviation]	+	[3-4 Digit Unique Number]	+	[".CBL"]
Conversion/Database Synchronization programs:	["UD"]	+	[2-3 Character Application Abbreviation]	+	[3-4 Digit Unique Number]	+	[".CBL"]
	required		required		required		required

Examples:

Standard programs:	"UBAD0012.CBL"
Conversion/Database Synchronization programs:	"UDAD0007.CBL"

If the COBOL program is used in conjunction with a Crystal report, both the COBOL program and the related Crystal report should have the same name.

All output files should have the same name as the COBOL program that created them. If a COBOL program creates more than one output file, then append an alphabetic character to distinguish the file names (a, b, c, etc.). The output files should have the appropriate file name extension for the type of file created (e.g., ".CSV" for comma delimited, ".TXT" for text, etc.)

Strict adherence to these standards will prevent naming COBOL programs that cannot be identified back to a system or that overlay an existing object.

Return to Table of Contents

PeopleSoft (version 7.0 and higher) COBOL copybooks can only have 8 bytes for their names, and each name must be unique.

The following naming conventions apply to all U of U added COBOL copybooks:

Required prefix:	"UB" for standard program copybooks, or "UD" for Conversion/Database Synchronization program copybooks
Application abbreviation:	Use 2-3 Character Standard Project/Module Abbreviations
Copybook Name:	Any combination of alpha/numeric characters not to exceed 8 byte name
File Name Extension:	".CBL"

Format:

Standard programs:	["UB"]	+	[2-3 Character Application Abbreviation]	+	[Alpha/Num. chars. not to exceed eight bytes]	+	[".CBL"]
Conversion/Database Synchronization programs:	["UD"]	+	[2-3 Character Application Abbreviation]	+	[Alpha/Num. chars. not to exceed eight bytes]	+	[".CBL"]
	required		required		required		required

Examples:

Standard programs:	"UBADWS01.CBL"
Conversion/Database Synchronization programs:	"UDADW05A.CBL"

For COBOL copybook coding and development practices, see Standard #7c.

Strict adherence to these standards will prevent naming COBOL copybook files that cannot be identified back to a system or that overlay an existing object.

Return to Table of Contents

The PeopleSoft Data Designer allows 18 bytes for record (table) names, and automatically prefixes all record names with "PS_". The limited size for PeopleSoft names requires the use of abbreviations for all names. If a proposed name will not fit into the 18 byte restriction, see the ACS Data Analysts for acceptable new or alternative abbreviations.

All custom PeopleSoft record names added by ACS developers will have the following components:

Automatic PeopleSoft prefix:	"PS_" (note: this is not shown in the Data Designer)
Optional prefix:	"AUDIT_" for audit records, or "R_" for temporary SQL records
Required prefix:	"UU_"
Record name/abbreviation:	Use Standard Word Abbreviations
Record name suffix:	Use Standard Record Name Type Suffix and Standard Project/Module Abbreviations

Format:

["PS_"]	+	["AUDIT_" or "R_"]	+	["UU_"]	+	[rec. names]	+	["_" + type suffix]	+	["_" + project/module abbreviation]
automatic		optional		required		required		required for Views and Sub-Records, optional for all others		optional

Example:
"UU_ACT_LOAD_VW"

ACS Data Analysts (DAs) will approve all new record names prior to implementation.

Return to Table of Contents

The PeopleSoft Data Designer allows 18 bytes for field (column) names. The limited size for PeopleSoft names requires the use of abbreviations for all names. If a proposed name will not fit into the 18 byte restriction, see the ACS Data Analysts for acceptable new or alternative abbreviations.

All custom PeopleSoft field names added by ACS developers will have the following components:

Required prefix:	"UU_"
Field name/abbreviation:	Use Standard Word Abbreviations
Field name suffix:	Use Standard Field Name Suffix

Format:

["UU_"]	+	[field name]	+	["_" + field suffix]
required		required		optional

Example:
"UU_MULT_SSN_ERR_CD"

ACS Data Analysts (DAs) will approve all new field names (except derived field names) prior to implementation. Derived Field Records are used for transitory processing and do not associate with a physical PeopleSoft table, so they do not have to be pre-approved, yet they must still follow this naming standard.

Return to Table of Contents

The PeopleSoft Page (formerly "Panel") Designer allows 18 bytes for Page names. The limited size for PeopleSoft names requires the use of abbreviations for all names. If a proposed name will not fit into the 18 byte restriction, see the ACS Data Analysts for acceptable new or alternative abbreviations.

All custom PeopleSoft Page names added by ACS developers will have the following components:

Required prefix:	"UU_"
Page name/abbreviation:	Use Standard Word Abbreviations
Page name suffix:	Use Standard Page Name Suffix (required for all except "Standard Pages")

Format:

["UU_"]	+	[Page name]	+	["_" + Page suffix]
required		required		required for all except "Standard Pages"

Example:
"UU_PRSP_PARMS_SBP"

Return to Table of Contents

The PeopleSoft Component (formerly "Panel Group") Designer allows 18 bytes for Component names. The limited size for PeopleSoft names requires the use of abbreviations for most names. If a proposed name will not fit into the 18 byte restriction, see the ACS Data Analysts for acceptable new or alternative abbreviations.

If the Component has only one Page, name the Component the same as the Page. If the Component has multiple Pages, give the Component a simple and intuitive name that is descriptive of its function. Developers should be influenced by how the users will naturally use the application.

Always save the Component as "Global."

All custom PeopleSoft Component names added by ACS developers will have the following components:

Required prefix:	"UU_"
Component name/abbreviation:	Use Standard Word Abbreviations

Format:

["UU_"]	+	[Component name]
required		required

Example:
"UU_ENRL_MSG_LOG"

Return to Table of Contents

The PeopleSoft Menu Designer allows 30 bytes for menu names. The limited size for PeopleSoft names may require the use of abbreviations for some names. If a proposed name will not fit into the 30 byte restriction, see the ACS Data Analysts for acceptable new or alternative abbreviations. The Menu Item Name in the PeopleSoft Project Menu Item Properties must be the same as the Menu Item Label.

Creating application windows, and defining menu bars and menu items within each window, actually defines what the user will see within the application. Menu names should be simple and intuitive, so users don’t have to second guess the contents or purpose of an application window or menu. The underlying record definition and Page definition names should not drive menu naming conventions--rather developers should be influenced by how the users will naturally use the application. For example, the Administer Personnel application window consists of menus that list Pages designed specifically for entering personal, job, and other information about employees. In addition to making menu names functionally easy to understand, they should be easy to read. PeopleSoft recommends that developers use mixed case for both application window and menu item names: "Administer Personnel" as opposed to "ADMINISTER PERSONNEL."

For Menu development Change Control procedures, see Standard #1f.

All custom PeopleSoft menu names added by ACS developers will have the following components:

Required prefix:	"UU_"
Menu name:	Use a simple, intuitive name so users don’t have to second guess the purpose of a menu

Format:

["UU_"]	+	[menu name]
required		required

Example:
"UU_Campus_Recreation"

Return to Table of Contents

The PeopleSoft Tree Manager allows 18 bytes for Tree names. The limited size for PeopleSoft names may require the use of abbreviations for tree names. ACS Data Analysts will create and maintain all Query Trees. ACS developers will contact the DA's when a Query Tree needs to be created or modified.

All custom PeopleSoft Query Tree names added by ACS developers will have the following components:

Required prefix:	"UU_"
Project abbreviation:	Use Standard Project Abbreviations
Page Name:	Name of the Page this Query Tree references (Use Standard Word Abbreviations if necessary)

Format:

["UU_"]	+	[Project Abbreviation]	+	["_" + Query Tree Name Abbreviation(s)]
required		required		required

Example:
"UU_HR_PERS_DATA"

A Query Tree will be created for each Menu Item. This will create a one to one relationship between an end user's Page security and their Query Tree security. This will require that more Query Trees will be created, but tree maintenance will be definitive. When a new table is added to a Page, the table will also need to be added to the associated Query Tree.

Return to Table of Contents

The PeopleSoft Query Tree Access Group Designer allows 30 bytes for Query Tree Access Group names. The limited size for PeopleSoft names may require the use of abbreviations for some names. If a proposed name will not fit into the 30 byte restriction, see the ACS Data Analysts for acceptable new or alternative abbreviations.

All custom PeopleSoft Query Tree Access Group names added by ACS developers will have the following components:

Required prefix:	"UU_"
Query Tree Access Group name:	Use a simple, intuitive name.

Format:

["UU_"]	+	[Query Tree Access Group name]
required		required

Example:
"UU_PERSONAL_DATA"

Return to Table of Contents

The PeopleSoft Application Designer allows 30 bytes for project names. ACS selective upgrade project names include a unique sequence number controlled either by the Project Team or by ACS Quality Assurance. If the Project Team Modification Number is used for the unique sequential number, it will allow all related modifications to be grouped within the same Application Designer project. If there is a need to group several modifications under one PeopleSoft Application Designer project, the ACS QA assigned system control number should be used for the unique sequence number.

For Project documentation procedures, see Standard #3a.

All PeopleSoft project names used by ACS developers will have the following components:

Required Project prefix:	Use 2 Character Standard Project Abbreviations
Sequential Number:	If Project Team modification number is available, use the modification number, or If Project Team modification number is NOT available, use ACS QA assigned system control number
Suffix:	If appropriate, add a modification number or project name suffix

Format:

With a Modification Number:	[2 Character Project Abbreviation]	+	[Project Team Modification Number]	+	[Modification Number Suffix]
Without a Modification Number:	[2 Character Project Abbreviation]	+	[QA System Control Number]	+	[Project Name Suffix]
	required		required		optional

Examples:

With a Modification Number:	"SA216" or "SA268_R0108"
Without a Modification Number:	"HR700013" or "SA700025_PAGES"

Return to Table of Contents

PeopleSoft Application Engine objects can have 8 bytes for their names, and each name must be unique within Application Engine and not be the same as SQR or COBOL programs.

The following naming conventions apply to all U of U added Application Engine objects:

Required prefix:	"UA"
Application abbreviation:	Use 2-3 character Standard Project/Module Abbreviations
Sequential Number:	The first byte can be an alpha character, if needed. The numeric portion must be padded with leading zeros to fill the eight byte name.

Format:

["UA"]	+	[2-3 Character Application Abbreviation]	+	[3-4 Digit Unique Number]
required		required		required

Example:
"UAAD0012"

The development database should be used by the developer to assign the sequential number portion of the name.

Strict adherence to these standards will prevent naming Application Engine objects that cannot be identified back to a system or that overlay an existing object.

Return to Table of Contents

PL/SQL Packages allow efficient selection of data from the Oracle tables. The Package names should clearly identify the system or function of the package to facilitate reuse.

The following naming conventions apply to all U of U added PL/SQL Database Packages:

Required prefix:	"UU_"
Package Description:	For single-system Packages, use 2-3 character Standard Project/Module Abbreviations For cross-system Packages, use a simple, intuitive name that describes the package function (use Standard Word Abbreviations)
Required Suffix:	"_PKG"

Format:

Single-system Packages:	["UU_"]	+	[2-3 Character Application Abbreviation]	+	["_PKG"]
Cross-system Packages:	["UU_"]	+	[Simple name using Standard Word Abbreviations]	+	["_PKG"]
	required		required		required

Examples:

Single-system Package:	"UU_HR_PKG"
Cross-system Package:	"UU_FIN_LNK_PKG"

Return to Table of Contents

PL/SQL Functions and Procedures allow efficient selection and manipulation of data from the Oracle tables. The Function and Procedure names should clearly identify the purpose of the Function or Procedure to facilitate reuse.

When naming a Function or Procedure, capitalize the first letter of each keyword so that it is easier to read and understand what the module is doing. The following naming conventions apply to all U of U PL/SQL Functions and Procedures:

Functional prefix:	Use a single word that describes the purpose of the PL/SQL Function or Procedure (e.g., "Get", "Calc", "Build") (use Standard Word Abbreviations)
Field Description:	Use simple intuitive abbreviations that identify the resulting data (use Standard Word Abbreviations)

Format:

[Word describing function]	+	[Abbrevations identifying resulting data]
required		required

Examples:
"GetEmplInfo"
"CalcBalAmt"

Return to Table of Contents

PL/SQL variable names should clearly identify the variable type and the data it holds.

When naming PL/SQL variables:

• Do not capitalize any characters in the name. This will identify the object as a variable rather than a function or procedure.
• Use anchor data types whenever possible (%TYPE).
• All variables should be initialized.
• All required parameters should have default values.
• All variables meant to indicate TRUE or FALSE should be BOOLEANS.

The following naming conventions apply to all U of U PL/SQL variable names:

Functional prefix:	"c_" for cursor names "e_" for user defined exceptions "g_" for package global variables "p_" for parameters "t_" for user defined types "v_" for local or program variable
Data Description:	Use simple intuitive abbreviations that identify the resulting data (use Standard Word Abbreviations)

Format:

[Functional prefix]	+	[Abbrevations identifying data]
required		required

Examples:
"p_empl_rec"
"c_empl"
"v_acct_cd"
"e_empl_prob"

Return to Table of Contents

PeopleSoft Jobs can only have 8 bytes for their names, and each name must be unique. The limited size for PeopleSoft Job names requires the use of abbreviations. If a proposed Job name will not fit into the 8 byte restriction, see the ACS Data Analysts for acceptable new or alternative abbreviations.

The following naming conventions apply to all U of U added PeopleSoft Jobs:

Required prefix:	"UU"
Job name abbreviation:	Use Standard Word Abbreviations

Format:

["UU"]	+	[Job name]
required		required

Examples:
"UUGRDLPS"
"UUQEMASS"
"UUHR0001"

Return to Table of Contents

The PeopleSoft Application Designer allows 30 bytes for navigator names. The limited size for PeopleSoft names may require the use of abbreviations for navigator names. If a proposed name will not fit into the 30 byte restriction, see the ACS Data Analysts for acceptable new or alternative abbreviations.

The internal name of the object can differ from the visible display name (Icon Description). However, it is recommended that internal and external names be the same, to simplify matching the two. For Business Process Maps and Business Processes, the display name is defined under File / Object Properties in the "Icon Description." For Activities, the Icon Description is available when you open a Business Process and right-click on an Activity icon. The display name should include the "UU" prefix, can be in mixed upper and lower case, and need not have the "_" separators. For internal names, use all uppercase characters with underscores in place of blanks (this is an Application Designer requirement).

All custom PeopleSoft navigator names added by ACS developers will have the following components:

Required prefix:	"UU_"
Project abbreviation:	Use Standard Project Abbreviations
Navigator Name:	Use a simple, intuitive name so users don’t have to second guess the purpose of a navigator (Use Standard Word Abbreviations if necessary)

Format:

["UU_"]	+	[Project Abbreviation]	+	["_" + Navigator Name Abbreviation(s)]
required		required		required

Examples:

Activities:	"UU_SC_ClassSchedule"
Business Processes:	"UU_AD_ADMISSIONS_NAVIGATORS"
Business Process Maps:	"UU_SR_REGISTRATION"

Strict adherence to these standards will prevent naming PeopleSoft navigators that cannot be identified back to a system or that overlay an existing object.

Return to Table of Contents

To ensure maintainability, all PeopleSoft UNIX directories will follow the naming, ownership and permission standards noted below.

File Transfers
The standard PeopleSoft directories ($PS_HOME/input, /out, and /log) will not be changed or affected in any way by this standard. All applications (and files) will reside in the ACS PeopleSoft directory structure, even if they do not access Oracle tables or run under the Process Scheduler.

When an ACS maintained system requires UNIX storage space for files that need to be transferred between ACS directory structures and external entities, the ACS developer can get the desired file transfer directories created by giving ACS Quality Assurance (QA) the names of the proposed directories. ACS QA will insure that all standards are followed, and will then give the request to ACS Security for directory creation.

All file transfer directories must conform to one of the following two formats:

Node	Definition	Comments
$PS_HOME	Set by psconfg.sh and contains the home directory of each database.	/ps/heprod, /ps/fsprod, /ps/hedev, /ps/fstest, etc.
APP	Standard application/module abbreviation.	See Standard Project/Module Abbreviations.
FUNCTION	A standard term to indicate the general nature of the process/file.	The following are the approved functions: arch = archive burn = to be burned to CD in = input data out = output data web = data accessible through the Web parm = parameter data work = temporary files defer = files deferred for later processing
SUB-APP (optional)	Standard application/module abbreviation.	See Standard Project/Module Abbreviations.

UNIX PeopleSoft Directories

$PS HOME/bin	Contains COBOL wrapper scripts and PeopleSoft-provided UNIX support files (appserver and process-scheduler support files)
$PS HOME/cblbin	Contains compiled COBOL programs
$PS HOME/src/cbl	Contains source COBOL programs
$PS_HOME/sqr	Contains PeopleSoft-provided sqrs in all environments
$PS_HOME/wip	Contains locally-developed sqrs in non-production environments
$PS_HOME/modprod	Contains locally-developed sqrs in production environments

Directory User-ownership and Permissions
The directories will be owned by the corresponding UNIX userid ("owner") [hedev, fsdev, heprod, fsprod, etc.]. In each database, and for each directory, the owner will have "rwx" permission on the directory. The owner may gain its privileges to access specified files within a directory through the user-ownership permissions, but the owner most always be granted access privileges through a file's group-ownership permissions (see Directory Group-ownership and Permissions).

Directory Group-ownership and Permissions
The owner (fsdev, hedev, etc.) will be added to each group that is assigned group-ownership of a directory. In each database, and for each directory, the group will have "rws" permission on the directory. The "set-groupid" bit will be implemented on each directory so that new files created inside each directory will automatically be assigned to the directory's group-owner.

It will be the responsibility of a user creating a new file in a directory to set the group-permissions so that the database owner will have the required access (read, write, execute) to the new file. Depending on the Value of the user's umask at the time of file creation, a "chmod" command may be required to grant the proper group-permission to any given file. See online "man" pages on "umask" and "chmod" for additional information.

Directory Other-ownership and Permissions
Each directory will be "world readable" and "world executable", but never "world writeable". This standard will allow ACS staff to search a directory (do an "is") and to execute a directory ("cd" to it) in all cases.

Directory Group-ownership Assignments
The group-ownership in each directory has been assigned to facilitate the required access to maintain development and to support each environment. The "progrmrs" group will consist of all PeopleSoft support staff (programmers, SAs, DAs, fix/QA/security personnel). The "gaps" group will consist of fix/upgrade and QA personnel. The "psupg" group will consist of fix analyst personnel.

NOTE: "psupg" will be the group-owner of all the directories named below in DEMO databases.

$PS HOME/bin:	"qaps" will be the group-owner of /bin in all non-DEMO databases
$PS HOME/cblbin:	"progrmrs" will be the group-owner of /cblbin in DEV databases "qaps" will be the group-owner of /cblbin in non-DEV databases
$PS HOME/src/cbl:	"progrmrs" will be the group-owner of /src/cbl in DEV databases "qaps" will be the group-owner of /src/cbl in non-DEV databases
$PS_HOME/sqr:	"psupg" will be the group-owner of /sqr in all databases
$PS_HOME/wip:	"progrmrs" will be the group-owner of /wip in DEV databases "qaps" will be the group-owner of /wip in all non-DEV databases
$PS_HOME/modprod:	"qaps" will be the group-owner of /modprod directory in all production databases

Note: $PS_HOME/install/pscbl.mak will be readable and executable by "progrmrs" in DEV databases, by "qaps" in non-DEV databases, and by "psupg" in DEMO databases.

The group-ownerships as assigned in Directory Group-ownership Assignments will allow programmers to develop, compile, and execute COBOL programs in DEV, as well as create and modify SQRs (in "$PS_HOME/wip") in DEV. ACS staff will be able to read COBOLs and SQRs in all databases. The fix and QA personnel will be able to compile, copy and move COBOLs and SQRs as required in all databases. Fix personnel will create new COBOLs and SQRs only as required by delivered fixes; upgrade requests will continue to be routed through Quality Assurance.

Return to Table of Contents

The PeopleSoft Component Interface Designer allows 30 bytes for Component Interface names. The limited size for PeopleSoft names may require the use of abbreviations for all names. If a proposed name will not fit into the 30 byte restriction, see the ACS Data Analysts for acceptable new or alternative abbreviations.

All custom PeopleSoft Component Interface names added by ACS developers will have the following elements:

Required prefix:	"UU_"
Component Interface name:	Use Standard Word Abbreviations
Component Interface name suffix:	"_CI"

Format:

["UU_"]	+	[Component Interface name]	+	["_CI"]
required		required		required

Example:
"UU_AWARD_ACCEPT_CI"

Return to Table of Contents

The PeopleSoft Message Node Designer allows 15 bytes for Message Node names. The limited size for PeopleSoft names may require the use of abbreviations for some names. If a proposed name will not fit into the 15 byte restriction, see the ACS Data Analysts for acceptable new or alternative abbreviations.

The node definition names for the Local Nodes should be unique across all databases (for example, do not have DEV and TEST databases with a local node named "UU_MY_LOCALNODE"). The node definition names and locations you define in the PeopleSoft Application Messaging Gateway lookup table must match the definitions you create in Application Designer. (For full information about messaging, see Application Messaging in PeopleBooks.)

All custom PeopleSoft Message Node names added by ACS developers will have the following components:

Required prefix:	"UU_"
Message Node name:	Use a simple, intuitive name and if necessary, use Standard Word Abbreviations.

Format:

["UU_"]	+	[Message Node name]
required		required

Example:
"UU_ASTRA_PROD"

Return to Table of Contents

3a.  Documentation - PeopleSoft Objects

Each new or modified PeopleSoft object definition (Business Process, Business Process Map, Process Definition, Field, Menu, Page, Component, Record, Job, Message Catalog Entries, Message Channels, Message Definitions, Message Nodes), if possible, must have the changes documented as part of the object definition.

For U of U added objects, fill out all Object Properties edit boxes (Description and Comments).
For delivered PeopleSoft object modifications, the changes must be fully described in the Object Properties, Comments edit box, and developers are encouraged to add a meaningful Description if one does not exist.
Exception: Translate value additions/modifications DO NOT need to be documented in the Object Properties.
Exception: Process Definitions can not be documented in the Object Properties, but instead must be documented in the Long Description field of the Process Definition.
For all Projects, fill out all Project Properties edit boxes (Description and Comments).

The Description must clearly and succinctly describe the object or project, and should not be a restatement of the name.

Comments should be added to the beginning of existing text, not the end. The Comment's descriptive text must be in the following format:


UU_MOD mm/dd/yyyy PR#=SSSNNN SYS#=SSSNNNNNN Developer-Name (Last, First)
Description of U of U addition or modification...
...
...


During an upgrade, the descriptive text will appear on the Comparison Reports, and will thus be very valuable in understanding the Object changes. The first line contains the unique strings "UU_MOD", "PR#=", and "SYS#=" (optional) for quickly finding all U of U modifications with the PeopleTools SEARCH utility. If other descriptions have already been added to the documentation, the new text should be inserted at the top of the previous entries and should include a new "UU_MOD ..." header line.

For additions/changes to Menus, the Menu Bar Name and Menu Item Label should be documented in the Object Properties as part of the UU_MOD comments.

If the PeopleSoft object is a menu that will submit a batch SQR or COBOL program, a description of the menu path and all called programs should be added to the comments at the top of the SQR or COBOL program (see Standard #3c Documentation - SQRs and SQCs or Standard #3d Documentation - COBOL Programs). This will make it easy for developers working on the SQR or COBOL program to know the menu that executes the program.

See the Glossary for a definition of the Modification Control Number (PR#=) and the optional System Control Number (SYS#=)

Return to Table of Contents

Each U of U addition or modification of PeopleCode will have the following format (see also Standard #7a Coding and Development Practices - PeopleCode):

/*UU_MOD mm/dd/yyyy PR#=SSSNNN SYS#=SSSNNNNNN Developer-Name (Last, First) */
/* Description of U of U addition or modification... */
/* ... */
/* ... */
PeopleCode statements...
...
...
/*END_UU_MOD mm/dd/yyyy */

Return to Table of Contents

Each U of U modification of an SQR or SQC will have the following components (see also Standard #7b Coding and Development Practices - SQCs):

1. A history comment fully describing the modifications (including the modification number) should be added to the existing header comments. If the SQR or SQC does not have header comments, they should be added using the format for U of U developed programs defined below.
2. For ACS modifications of delivered PeopleSoft SQRs and SQCs, all code lines that are replaced with new code lines should be commented out and comments added to identify the old code and why it was replaced.
3. For ACS modifications of delivered PeopleSoft SQRs and SQCs, SQR or SQC changes involving one line or a block of lines will have the following format:

   !UU_MOD mm/dd/yyyy PR#=sssnnn SYS#=sssnnnnnn Developer-Name (Last, First)
   ! Simple description of U of U modification...
   ! ...
   ! ...
   SQR statements...
   ...
   ...
   !END_UU_MOD mm/dd/yyyy
   

4. For ACS modifications of delivered PeopleSoft SQRs and SQCs, SQR or SQC changes involving many lines or many blocks of lines can have the following format (a full description of the modification must be documented in the SQR program header comments):

   SQR statement... !UU_MOD mm/dd/yyyy PR#=sssnnn Developer-Name (Last, First)
   

Each U of U developed SQR or SQC will have the following components:

1. If the SQR or SQC is cloned from another, remove the original header comments that no longer apply, and add new header comments (including a reference to the original program). Any code lines that are replaced with new code lines need not be retained, but it may be appropriate to include comments describing the changes.
2. If the SQR or SQC replaces a delivered PeopleSoft SQR or SQC, include a standard SQR/SQC header comment section in both the new SQR/SQC and the original delivered PeopleSoft SQR/SQC. The original delivered PeopleSoft SQR/SQC header comment should indicate that a local version of the program has been created, giving the name of the local program, the mod number, etc. The header comment in the new SQR/SQC should indicate that it is a local version of the PeopleSoft delivered SQR/SQC, giving the name of the original program, the mod number, etc.
3. All SQRs must document the method used to invoke the program in the EXECUTION section of the header comments. If the program is invoked by a PeopleSoft Menu, completely document the menu path. If the program is not invoked through a menu, completely describe how to execute the program.
4. The optional MAINTENANCE NOTES section may include the following: Rerun instructions, testing instructions, a list of programs called by this program, and any other information that may be useful for future maintenance of the program.
5. The SQR or SQC will include the following comments at the top of the program:

   !***********************************************************************
   ! UU_MOD SQR NAME: xxxxxxxx
   !***********************************************************************
   ! DESCRIPTION: Description of U of U program...
   ! ...
   ! ...
   !
   ! CONTROL #'S: PR#=sssnnn SYS#=sssnnnnnn
   !
   ! INPUT: Input sources...
   !
   ! OUTPUT: Output files and reports...
   !
   ! EXECUTION: Describe how program is invoked...
   !
   ! EXTERNAL SCRIPTS: External scripts (PERL, etc.)...
   !
   ! MAINTENANCE NOTES: Rerun and testing instructions, list pgms. called...
   !
   ! AUTHOR: University of Utah, ACS
   !
   ! HISTORY:
   ! Developer-Name (Last, First) mm/dd/yyyy Original Development
   ! Developer-Name (Last, First) mm/dd/yyyy PR#=sssnnn (if different from above) Description of U of U modification...
   ! ...
   ! ...
   !***********************************************************************
   

During an upgrade and when the SQR or SQC is reviewed, the descriptive text will be very valuable in understanding the SQR/SQC and its changes.

See the Glossary for a definition of the Modification Control Number (PR#=) and the optional System Control Number (SYS#=)

Return to Table of Contents

Each U of U modification of a COBOL program will have the following components (see also Standard #7c Coding and Development Practices - COBOL Copybooks):

1. A history comment fully describing the modifications (including the modification number) should be added to the existing header comments. If the program does not have header comments, they should be added using the format for U of U developed programs defined below.
2. For ACS modifications of delivered PeopleSoft COBOL programs, all code lines that are replaced with new code lines should be commented out and comments added to identify the old code and why it was replaced.
3. For ACS modifications of delivered PeopleSoft COBOL programs, the COBOL changes will have the following format:

   *UU_MOD mm/dd/yyyy PR#=sssnnn SYS#=sssnnnnnn Developer-Name (Last, First)
   * Simple description of U of U addition or modification...
   * ...
   * ...
   COBOL statements...
   ...
   ...
   *END_UU_MOD mm/dd/yyyy
   

Each U of U developed COBOL program will have the following components:

1. If the program is cloned from another, remove the original header comments that no longer apply, and add new header comments (including a reference to the original program). Any code lines that are replaced with new code lines need not be retained, but it may be appropriate to include comments describing the changes.
2. If the program replaces a delivered PeopleSoft COBOL program, include a standard COBOL header comment section in both the new program and the original delivered PeopleSoft program. The original delivered PeopleSoft COBOL header comment should indicate that a local version of the program has been created, giving the name of the local program, the mod number, etc. The header comment in the new program should indicate that it is a local version of the PeopleSoft delivered program, giving the name of the original program, the mod number, etc.
3. All COBOL programs must document the method used to invoke the program in the EXECUTION section of the header comments. If the program is invoked by a PeopleSoft Menu, completely document the menu path. If the program is not invoked through a menu, completely describe how to execute the program.
4. The optional MAINTENANCE NOTES section may include the following: Rerun instructions, testing instructions, a list of programs called by this program, and any other information that may be useful for future maintenance of the program.
5. If the Stored Statments (DMS scripts) that relate to a COBOL program are modified, comments describing the changes to the Stored Statements should also be included in the header section of the COBOL program as well as the DMS script.
6. The COBOL program will include the following comments in the Identification Division:

   ************************************************************************
   * UU_MOD PROGRAM NAME: xxxxxxxx
   ************************************************************************
   * DESCRIPTION: Description of U of U program...
   * ...
   * ...
   *
   * CONTROL #'S: PR#=sssnnn SYS#=sssnnnnnn
   *
   * INPUT: Input sources...
   *
   * OUTPUT: Output files and reports...
   *
   * EXECUTION: Describe how program is invoked...
   *
   * MAINTENANCE NOTES: Rerun and testing instructions, list pgms. called...
   *
   * AUTHOR: University of Utah, ACS
   *
   * HISTORY:
   * Developer-Name (Last, First) mm/dd/yyyy Original Development
   * Developer-Name (Last, First) mm/dd/yyyy PR#=sssnnn (if different from above) Description of U of U modification...
   * ...
   * ...
   ************************************************************************
   

During an upgrade and when the COBOL program is reviewed, the descriptive text will be very valuable in understanding the program and its changes.

See the Glossary for a definition of the Modification Control Number (PR#=) and the optional System Control Number (SYS#=)

Return to Table of Contents

Each U of U PL/SQL Package/Function/Procedure will have the following components (see also Standard #7g Coding and Development Practices - PL/SQL Packages/Functions/Procedures):

1. A history comment fully describing the modifications (including the modification number) should be added to the existing header comments. If the code does not have header comments, they should be added using the format for U of U developed programs defined below.
2. All code lines that are replaced with new code lines should be commented out and comments added to identify the old code and why it was replaced.
3. The code changes will have the following format:

   /*UU_MOD mm/dd/yyyy PR#=sssnnn SYS#=sssnnnnnn Developer-Name (Last, First)
   /* Simple description of U of U addition or modification...
   /* ...
   /* ...
   PL/SQL statements...
   ...
   ...
   /*END_UU_MOD mm/dd/yyyy
   

Each U of U developed PL/SQL Package/Function/Procedure will have the following components:

1. If the code is cloned from another, remove the original header comments that no longer apply, and add new header comments (including a reference to the original code). Any code lines that are replaced with new code lines need not be retained, but it may be appropriate to include comments describing the changes.
2. The PL/SQL code program will include the following comments at the top of the code (For a complete sample of PL/SQL code, see comments example code.):

   /************************************************************************
   /* UU_MOD PL/SQL NAME: xxxxxxxx
   /************************************************************************
   /* DESCRIPTION: Description of U of U PL/SQL code...
   /* ...
   /* ...
   /*
   /* CONTROL #'S: PR#=sssnnn SYS#=sssnnnnnn
   /*
   /* INPUT: Input sources...
   /*
   /* AUTHOR: University of Utah, ACS
   /*
   /* HISTORY:
   /* Developer-Name (Last, First) mm/dd/yyyy Original Development
   /* Developer-Name (Last, First) mm/dd/yyyy PR#=sssnnn (if different from above) Description of U of U modification...
   /* ...
   /* ...
   /************************************************************************
   

During an upgrade and when the PL/SQL code is reviewed, the descriptive text will be very valuable in understanding the code and its changes.

See the Glossary for a definition of the Modification Control Number (PR#=) and the optional System Control Number (SYS#=)

Return to Table of Contents

Each U of U developed script will have the following components:

1. If the script is cloned from another, remove the original header comments that no longer apply, and add new header comments (including a reference to the original script). Any script commands that are replaced with new command lines need not be retained, but it may be appropriate to include comments describing the changes.
2. All scripts must document the method used to invoke the script in the EXECUTION section of the header comments. If the script is invoked by a PeopleSoft Menu, completely document the menu path. If the script is not invoked through a menu, completely describe how to execute the script.
3. The optional MAINTENANCE NOTES section may include the following: Rerun instructions, testing instructions, a list of programs called by this script, and any other information that may be useful for future maintenance of the script.
4. The script will include the following comments at the top of the program:

   ########################################################################
   # SCRIPT NAME: xxxxxxxx
   ########################################################################
   # DESCRIPTION: Description of U of U script...
   # ...
   # ...
   #
   # CONTROL #'S: PR#=sssnnn SYS#=sssnnnnnn
   #
   # RELATED SCRIPTS: Related scripts (PERL, etc.)...
   #
   # EXECUTION: Describe how script is invoked...
   #
   # JOBSTREAM: Document each job step in the script...
   #
   # MAINTENANCE NOTES: Rerun and testing instructions, list pgms. called...
   #
   # AUTHOR: University of Utah, ACS
   #
   # HISTORY:
   # Developer-Name (Last, First) mm/dd/yyyy Original Development
   # Developer-Name (Last, First) mm/dd/yyyy PR#=sssnnn (if different from above) Description of U of U modification...
   # ...
   # ...
   ########################################################################
   

During an upgrade and when the script is reviewed, the descriptive text will be very valuable in understanding the script and its changes.

See the Glossary for a definition of the Modification Control Number (PR#=) and the optional System Control Number (SYS#=)

Return to Table of Contents

Stored statements are used by COBOL programs. The statements themselves are stored in PS_SQLSTMT_TBL. The statements get into the table (inserts, updates, deletes) by means of DataMover DMS scripts. DMS scripts that need UU mods are stored on the P: drive in the DEV directory (e.g., P:\he890d\src\cbl\modss). (see also Standard #6h Coding and Development Practices - Stored Statements)

Each U of U modification of a Stored Statements script file (DMS script) will have the following components:

1. A history comment fully describing the modifications (including the modification number) should be added to the existing header comments. If the program does not have header comments, they should be added using the format for U of U developed scripts defined below.
2. For ACS modifications of delivered PeopleSoft Stored Statement scripts, all code lines that are replaced with new code lines should be commented out and comments added to identify the old code and why it was replaced.
3. For ACS modifications of delivered PeopleSoft Stored Statement scripts, the script changes will have the following format:

   *UU_MOD mm/dd/yyyy PR#=sssnnn SYS#=sssnnnnnn Developer-Name (Last, First)
   * Simple description of U of U addition or modification...
   * ...
   * ...
   Stored Statements...
   ...
   ...
   *END_UU_MOD mm/dd/yyyy
   

Each U of U developed Stored Statement script will have the following components:

1. If the script is cloned from another, remove the original header comments that no longer apply, and add new header comments (including a reference to the original script). Any code lines that are replaced with new code lines need not be retained, but it may be appropriate to include comments describing the changes.
2. If the script replaces a delivered PeopleSoft Stored Statement script, include a standard Stored Statement script header comment section in both the new script and the original delivered PeopleSoft script. The original delivered PeopleSoft Stored Statement script header comment should indicate that a local version of the script has been created, giving the name of the local script, the mod number, etc. The header comment in the new script should indicate that it is a local version of the PeopleSoft delivered script, giving the name of the original script, the mod number, etc.
3. The optional MAINTENANCE NOTES section should include any information that may be useful for future maintenance of the script.
4. If the Stored Statments (DMS scripts) that relate to a COBOL program are modified, comments describing the changes to the Stored Statements should also be included in the header section of the COBOL program as well as the DMS script.
5. The Stored Statement script will include the following comments at the top of the script:

   ************************************************************************
   * UU_MOD SCRIPT NAME: xxxxxxxx
   ************************************************************************
   * DESCRIPTION: Description of U of U script...
   * ...
   * ...
   *
   * CONTROL #'S: PR#=sssnnn SYS#=sssnnnnnn
   *
   * INPUT: Input sources...
   *
   * OUTPUT: Output files and reports...
   *
   * MAINTENANCE NOTES: Rerun and testing instructions, list pgms. called...
   *
   * AUTHOR: University of Utah, ACS
   *
   * HISTORY:
   * Developer-Name (Last, First) mm/dd/yyyy Original Development
   * Developer-Name (Last, First) mm/dd/yyyy PR#=sssnnn (if different from above) Description of U of U modification...
   * ...
   * ...
   ************************************************************************
   

During an upgrade and when the Stored Statement script is reviewed, the descriptive text will be very valuable in understanding the script and its changes.

See the Glossary for a definition of the Modification Control Number (PR#=) and the optional System Control Number (SYS#=)

Return to Table of Contents

4a.  PeopleSoft Tables - PeopleSoft Object Modifications

When modifying PeopleSoft objects the following must be observed:

1. Open the PeopleSoft object, and add comments explaining the changes (see Standard #3a). Make the needed changes.
2. If a Data Designer field is being added, include the prefix "UU_" to the new field name (see Standard #2i).
3. Save the object definition.
4. For Data Designer record definition changes, notify the ACS Data Analyst (DA) that the record definition has been modified. The DA will review the changes. The programmer or DA should then create an SQL DDL script file for adding the fields to the affected table (see Standard #4b).

Renaming fields in the Data Designer should NEVER be performed, because the Data Designer renames the field EVERYWHERE it is referenced. A new field should be created rather than rename an existing field.

Changes to Data Designer field characteristics apply to the field on ALL record definitions, Pages, reports, etc.. Because of the significant impacts to other objects and systems, an ACS Data Analyst (DA) must approve any field characteristic changes BEFORE they are made.

ORACLE security does not allow the PeopleSoft "SQL Create Table"/"Execute SQL Now" function. Because of the severe impacts resulting from dropping and recreating a table, security controls prevent developers from running SQL DDL script files against PeopleSoft databases.

Return to Table of Contents

PeopleSoft tables are created by the ACS Database Administrators (DBAs) using SQL DDL script files. ACS Data Analysts (DAs) will review all changes to PeopleSoft data objects (PeopleCode objects excepted). The table to be created must have the prefix "UU_" as part of its table name (see Standard #2h).

ACS Programmers should discuss all data object changes with the DA assigned to the project before making the PeopleSoft data changes. The Programmer or DA will generate an SQL DDL script file. The DA will review the script for approval. The naming convention for the script file will be: "D" + [yy] + [Julian date] + [two character sequence number] + ".SQL" (Example: D9712801.SQL). Script files do not need consecutive sequence numbers. The ACS developer creating the script file (Programmer or DA) should retain the script file because it can be reused when the object changes are upgraded to the TEST and PROD environments.

The DA will move the approved script file into the DBA network drive repository (...\PSOFT\DMS). If a script file exists in this sub-directory, the DBAs will assume that it is ready to be applied. The DBAs will use the script file to apply the changes against the appropriate PeopleSoft database.

When the script has been successfully run, the DBAs will move it to another network sub-directory (...\PSOFT\DMSDONE). The script files will be retained only until they are backed-up (usually only a few days). ACS developers will have read only access to these network sub-directories.

Script files must begin with comments that have the following format and supply the noted information:

- - Name of person submitting SQL script.
- - Name of developer requesting database changes.
- - PeopleSoft Subsystem/System for which change is being made.
- - Database where change is being made.
- - Brief description of purpose of the changes.
- - Modification Control No. and/or System Control No. to which the database change applies.
- - Date script was created.

Return to Table of Contents

Creating, altering, or deleting tables in any PeopleSoft database can only be performed by the ACS Database Administrators (DBAs). ACS staff can use tools such as SQL Query to view or modify data (if given security), but ACS staff cannot alter, delete, or create tables.

Return to Table of Contents

Any changes to the PeopleSoft Translate Table must comply with the following procedure:

1. Review planned changes with the ACS Data Analyst (DA) assigned to the system to assess impacts to related objects and systems.
2. Fill out the XLAT Value Log-sheet and submit to the DA assigned to the system.
3. The DA will approve the changes and update the translate table. Developers and users will not be able to modify the translate table.

Return to Table of Contents

SQLExec code must never contain a COMMIT or ROLLBACK, never CREATE or DROP tables, and never perform any other DBA only functions. The ACS Development Team Leader is responsible for approving all SQLExec code prior to running the code. The Development Team Leader has the option of using peer walkthroughs to approve SQLExec code.

Return to Table of Contents

ACS developers inserting columns in a PeopleSoft table MUST declare all column names when doing an Insert into a PeopleSoft table. If all new columns are not declared, SQL assumes a positional relationship between the columns and the inserted variables. This can cause problems when tables are changed. For example, some of the tables in version 8 have had new columns added in the middle of the table. This means that positions have changed from that point on, and unless developers have modified their programs to reflect this change, the wrong data could be inserted into a column and not know it.

Return to Table of Contents

In order to avoid problems with Oracle, ACS developers creating queries should also create an alias for all tables accessed in the SQL created.

An example of an SQL statement with a fully qualified sub-select:

   Select p1.deptid, p1.fund_code, p1.descr
   from ps_uu_program_fsvw p1
   where p1.setid = 'UNIV'
   and  p1.program_code = '05490'
   and  p1.effdt = (select max(p2.effdt) 
          from ps_uu_program_fsvw p2 
          where p2.setid = p1.setid 
          and  p2.program_code = p1.program_code
          and  p2.effdt <= TO_DATE('2002-07-25','YYYY-MM-DD'))
   and p1.eff_status = 'A'

Return to Table of Contents

5a.  PeopleCode Standards - Viewing PeopleCode

If a developer views existing PeopleCode but does not make any changes to the code, DO NOT save the PeopleCode. If nothing was changed and the developer saves the PeopleCode when exiting the editor, the PeopleCode editor will re-save the code and increment the internal PeopleSoft version number for the code. Then, when the system is upgraded to the next system release from PeopleSoft, the upgrade compare reports will indicate that the PeopleCode has been changed. This would consume significant unnecessary labor to confirm that in reality no changes were made to the code.

Return to Table of Contents

There should be a maximum of three Derived Field Records per application (not including those supplied by PeopleSoft):

UU_GLOBAL_[application abbreviation] Contains functions to access GLOBAL variables.
UU_FUNCLIB_[application abbreviation] Contains all external PeopleCode functions.
UU_DERIVED_[application abbreviation] Contains the derived work fields.

Return to Table of Contents

Build a "derived" field record definition in the Data Designer. It should be named "UU_GLOBAL_[application abbreviation]". There should be one of these per application (e.g., UU_GLOBAL_TT for the Trouble Ticket System).

Define one field in the Derived Field Definition. Call it "UU_GLOBAL_FUNCTIONS". Using the PeopleCode "FieldFormula" type, code a function to access (and update) the value for a Global Variable. There should be one function for each Global Variable. See ACS PeopleSoft Technical Support for sample functions.

Return to Table of Contents

Build a "derived" field record definition in the Data Designer. It should be named "UU_FUNCLIB_[application abbreviation]". There should be one of these per application (e.g., UU_FUNCLIB_TT for the Trouble Ticket System).

Return to Table of Contents

Whenever a section of PeopleCode is identical between two code types within the same Record or between multiple Records, the programmer should determine if the PeopleCode could be run as an External PeopleCode function. If the programmer feels the PeopleCode could be an External PeopleCode function, he/she should review the PeopleCode with an ACS Software Engineer (SE) for possible inclusion in the appropriate UU_FUNCLIB. If approved as a function, the SE will identify to which function library field the code should be attached. The existence of the new function should be communicated to all members of the programming team, so it could be used instead of developing redundant code.

Return to Table of Contents

All developers need to take personal responsibility to follow these practices. You never know the negative impact your modifications can cause.

6a.  Coding and Development Practices - PeopleCode

The following practices must be observed when modifying existing PeopleCode (see also Standard #3b Documentation - PeopleCode):

• NEVER delete anything.
• ALWAYS comment out any line which is being changed or deleted.
• ALWAYS put your name, date of change, and Modification Number with any and all modifications.
• ALWAYS put as good a description of the change as possible in the PeopleCode. It is essential that other developers understand your changes.

Return to Table of Contents

The following practices must be observed when creating or modifying an SQR (see also Standard #3c Documentation - SQRs and SQCs):

• ALWAYS develop new programs using structured programming techniques (including paragraph naming conventions).
• ALWAYS put your name, date of change, and Modification Number with any and all modifications.
• ALWAYS put as good a description of the change as possible in the header of the SQR. It is essential that other developers understand your changes.
• ALWAYS include appropriate control totals in each output report. If no report is generated that details the SQR results, add a control totals report. The control totals report must also print all run control parameters.
• ALWAYS include the following SQCs:

  setupdb.sqc - defines things such as database platform-specific date formats

  setenv.sqc - defines things like database-specific file paths

• ALWAYS reference the appropriate FILEPREFIX variable as defined in SETENV.SQC for any internal PeopleSoft SQR output files. (For interface file locations see Standard #7f Coding and Development Practices - Input/Output File Locations)
• SQR/SQC files will only exist in the development and test databases if they are undergoing development or are being upgraded/fixed. This is necessary to save space and to make it easier to determine what SQR/SQC files are being worked on or tested. All SQR/SQC files will only reside in Demo and production.
• No SQR/SQC programs will reside on the "P" drive. No clients or ACS developers have any need to run SQR programs from the replicated drive. Developer tools do not require that SQR/SQC files reside on this drive.
• Autosys requires that all U of U developed SQRs be API-aware. The code sample shown below will make an SQR API-aware and must be added to all U of U developed SQRs. The do Stdapi-Init is normally part of the initialization procedure and should be the first or second instruction executed, and do Stdapi-Term must be the last instruction executed (extraneous messages will be generated if it is not executed last).

  Begin-Report
  

  do Init-Report
  

  do ...
  

  do Stdapi-Term
  

  End-Report

  begin-procedure Init-Report
  

  move 'PGMNAME' to $Report-ID
  

  do Stdapi-Init
  

  do ...
  

  end-procedure

  #include 'stdapi.sqc' !Routines to update run status

Return to Table of Contents

The following practices must be observed when modifying an existing SQC (see also Standard #3c Documentation - SQRs and SQCs):

• NEVER delete anything.
• ALWAYS comment out any line which is being changed or deleted.
• ALWAYS put your name, date of change, and Modification Number with any and all modifications.
• ALWAYS put as good a description of the change as possible in the header of the SQC. It is essential that other developers understand your changes, and that if you have a new, modular procedure, that anyone can determine if your SQC is one which they can use.
• ALWAYS use the "find" command to identify all SQRs using the SQC. If the SQC is used by another program, the proposed changes MUST be reviewed and approved by the team's lead programmer (or each programmer responsible for the affected SQRs).
• SQR/SQC files will only exist in the development and test databases if they are undergoing development or are being upgraded/fixed. This is necessary to save space and to make it easier to determine what SQR/SQC files are being worked on or tested. All SQR/SQC files will only reside in Demo and production.
• No SQR/SQC programs will reside on the "P" drive. No clients or ACS developers have any need to run SQR programs from the replicated drive. Developer tools do not require that SQR/SQC files reside on this drive.

Return to Table of Contents

The following practices must be observed when creating or modifying a COBOL program (see also Standard #3d Documentation - COBOL Programs):

• ALWAYS develop new programs using structured programming techniques (including paragraph naming conventions).
• ALWAYS put your name, date of change, and Modification Number with any and all modifications.
• ALWAYS put as good a description of the change as possible in the header of the COBOL program. It is essential that other developers understand your changes.
• ALWAYS include appropriate control totals in each output report. If no report is generated that details the program results, add a control totals report. The control totals report must also print all run control parameters.
• All COBOL source must reside in each database. This is necessary because some upgrades/fixes require a recompilation of all COBOL programs.
• No COBOL programs will reside on the "P" drive. No clients or ACS developers have any need to run COBOL programs from the replicated drive. Developer tools do not require that COBOL programs reside on this drive.

Return to Table of Contents

The following practices must be observed when modifying an existing COBOL Copybook (see also Standard #3d Documentation - COBOL Programs):

• NEVER delete anything.
• ALWAYS comment out any line which is being changed or deleted.
• ALWAYS put your name, date of change, and Modification Number with any and all modifications.
• ALWAYS put as good a description of the change as possible in the header of the copybook. It is essential that other developers understand your changes, and that if you have a new, modular procedure, that anyone can determine if your copybook is one which they can use.
• ALWAYS use the "find" command to identify all COBOL programs using the copybook. If the copybook is used by another program, the proposed changes MUST be reviewed and approved by the team's lead programmer (or each programmer responsible for the affected COBOL programs).
• All COBOL source must reside in each database. This is necessary because some upgrades/fixes require a recompilation of all COBOL programs.
• No COBOL programs will reside on the "P" drive. No clients or ACS developers have any need to run COBOL programs from the replicated drive. Developer tools do not require that COBOL programs reside on this drive.

Return to Table of Contents

The following practices must be observed when adding/modifying PL/SQL Packages, Functions or Procedures:

• CREATING DATABASE OBJECTS vs. SQCs: Database objects should be created to access/get data from database. This will help reduce the overhead. SQCs should be created to perform data manipulation such as adding, verifying if a record matches the length, value comparison. In other words, create an SQC for any non database related functions.
• COMMENTS: (See also Standard #3e Documentation - PL/SQL Packages/Functions/Procedures) At the beginning of every PL/SQL Package, Function, Procedure and block, comments should explain what the Package, Function, Procedure, or block is supposed to do. After each variable declaration, a single line comment should indicate how the variable will be used. Comment the following structures: IF, FOR LOOP and WHILE. Also, if there exists nested IF structures, add a small comment on each END IF to clearly identify which IF it ends. (Comments example code.)
• VARIABLE NAMES: (See also Standard #2s Naming Conventions - PL/SQL Variable Names) The variable names should clearly identify the variable type and the data it holds. When naming PL/SQL variables: Do not capitalize any characters in the name. This will make it is easier to read and understand how the variable is used. Use anchor data types whenever possible (%TYPE). All variables should be initialized. All required parameters should have default values. All variables meant to indicate TRUE or False should be BOOLEANS. Prefix all PL/SQL variable names with the following: "c_" for cursor names, "e_" for user defined exceptions, "g_" for package global variables, "p_" for parameters, "t_" for user defined types, "v_" for local or program variable. The remainder of the name should be simple intuitive abbreviations that identifies the resulting data. (Variable Names example code.)
• CAPITALIZATION: Reserved words are in uppercase (e.g., BEGIN, DECLARE, IF, ELSE). SQL and PL/SQL Built-in functions are in uppercase (e.g., SUBSTR, COUNT, NVL, TO_CHAR). Predefined types are in uppercase (e.g., NUMBER, BOOLEAN, DATE, VARCHAR2). SQL keywords are in uppercase (e.g., SELECT, FROM , INTO, UPDATE, WHERE). Database Objects are in lowercase (e.g., ps_job, ps_paycheck). Variables are in lowercase (e.g., p_param, v_variable, g_global) (See Standard #2s Naming Conventions - PL/SQL PL/SQL Variable Names). User code is called in lowercase (e.g., my_procedure, my_package.afunction). Functions and procedures capitalize the first character of each keyword (e.g., GetAcctDescr, CalcBalAmt) (See Standard #2r Naming Conventions - PL/SQL Function & Procedure Names). (Capitalization example code.)
• INDENTATION: Indent each line within the block by two spaces. Indent IF-THEN-ELSE by two spaces. Indent FOR LOOPS by two spaces. SQL statements should be indented and side aligned (either right or left justified). SQL statements should wrap with the comma on the following line after each: column in the SELECT, table in the FROM, condition in the WHERE, column in the ORDER/GROUP BY. Modules with more than one parameter should wrap after each parameter with the comma on the following line. (Indentation code examples.)
• CURSORS: When it is necessary to reference values from cursor1 in cursor2, the value should be passed in as a variable, not referenced in cursor2. (Cursors example code.)
• EXCEPTION HANDLING: Exception handling should be meaningful. Do not use WHEN OTHERS as the only exception. However, all exceptions should have a WHEN OTHERS clause in order to trap the error. (Exception Handling example code.)
• USE OF GLOBALS: Global use should be as limited as possible. Use package globals and parameters whenever feasible. (Use of Globals example code.)
• HARD CODING VALUES: Hard coding values should be avoided as much as possible. If you must hard code, you should do it in a package global that is a constant. That way, if you ever have to change any of the hard coded values, they are all in one place. (Hard Coding Values example code.)

Return to Table of Contents

PeopleSoft error and explanatory messages are stored in the Message Catalog, and organized by message set number. Each message set consists of a category of messages, ranging from PeopleTools Message Bar Items and PeopleCode Runtime Messages to application messages. The messages get called by the Error, Warning, Message Box, MsgGet, and MsgGetText built-in PeopleCode functions. Each message set consists of one or more rows of messages identified by a Message Number. See PeopleBooks for information on defining and using Message Sets and the Message Catalog.

The following standards apply to Message Sets:

• PeopleSoft Message Set Numbers: Message set numbers from 1 through 19,999 are reserved for exclusive use by PeopleSoft. ACS developers are not to use Message Set numbers below 20,000. Added or modified message set numbers less than 20,000 may be overwritten in future upgrades, and comparison reports do not indicate any Message Set upgrade conflicts.
• ACS Message Set Numbers: Message set numbers from 20,000 through 28,999 are for ACS created application messages. Message set numbers above 28,999 should not be used. Any available message set number between 20,000 and 28,999 can be selected for a new message set. ACS developers are to use the next available Message Number when inserting new Messages within Message Sets.
• Message Set Descriptions: The Description and Short Description apply to the Message Set, not to an individual message. The Description should be a simple, intuitive description of the set of messages (i.e., "HR Label Page Messages"). Message Sets are "sets of messages", not individual messages.
• Message Explanations: Each Message within the Message Set must have a complete Explanation that fully explains the condition causing the message to appear and the appropriate user response. The last line of the Explanation must contain an ACS "Mod Marker" in the following format:
  UU_MOD mm/dd/yyyy PR#=SSSNNN SYS#=SSSNNNNNN.
  See the Glossary for a definition of the Modification Control Number (PR#=) and the optional System Control Number (SYS#=).

Return to Table of Contents

Stored statements are used by COBOL programs. The statements themselves are stored in PS_SQLSTMT_TBL. The statements get into the table (inserts, updates, deletes) by means of DataMover DMS scripts. DMS scripts that need UU mods are stored on the P: drive in the DEV directory (e.g., P:\he890d\src\cbl\modss).

The following procedure is used most often during install of groups of fixes, but also applies if a production problem is being solved at other times:

1. Before making a change to the DMS script, the assigned programmer should backup the existing script by renaming the script with a second node of today's date (i.e., FAPTRMU1.20040319.DMS) and copying the script to the "old" folder. CAUTION: If in the middle of a fix cycle, the script at the top level may represent what's run in a lower database, such as HEDEV, while the older script in the "old" folder may be the one valid for production (until the fixes move up to production).
2. The programmer then makes the changes to the DMS script (including documentation defined in Standard #3g Documentation - Stored Statements)
3. Now, the DMS script needs to be run in the appropriate database. The Upgrade team normally runs the DMS scripts (a DA can also run the script if needed). The Upgrade team also need to incorporate this script into their install checklist for the group of fixes, so that the DMS script is run in each database as the fixes move up. The logs of the DMS script runs are stored in the "log" folder.

Return to Table of Contents

Modification Control Number (PR#=) - The Modification Control Number is a required as part of all object and program documentation. It is assigned and controlled by the ACS System Analyst assigned to the project. It is in the format of sssnnn, where sss is the two or three character unique system or sub-system identification code (i.e., "GL" for General Ledger, "AP" for Accounts Payable, etc.) and nnn is a unique three-digit sequential number.

Structured Programming - A programming technique for developing source code logic that employs a top-down refinement strategy to produce code built from a small set of logical constructs (chiefly, the sequence construct, the decision construct, and the loop construct).(Sample structure chart for a simple program.)

System Control Number (SYS#=) - The System Control Number (SYS#=) is optional for object and program documentation. It is assigned using the ACS Quality Assurance PeopleSoft Project Number Assignment web page (to access the assignment web page from the "Inside ACS" (Sun Spot) web page, select "PeopleSoft", "QA Documents", "Get a Project Number!"). It is in the format of sssnnnnnn, where sss is the two or three character unique system or sub-system identification code (i.e., "GL" for General Ledger, "AP" for Accounts Payable, etc.) and nnnnnn is a unique six-digit sequential number.