Ford Credit

PUPS
Implementation

Ford Credit PUPS Implementation

Background

PUPS Overview

Login

PUPS Migration Process

Approvers

Training

Support
Build Team Off-Hours Coverage for the COMPASS Platform
COCS Off-Hours Coverage for Legacy Applications
PUPS Tool Support

7
7
7
7

System Maintenance

Mainframe Delete Requests

Security
Roles
Post Migration Audit

8
8
8

Frequently Asked Questions (FAQs)

Type of change

9
10

For Approvers Only

12

For Submitters Only

Submitting Builds
Production Emergencies
Auto Relink
Changing the Migration Request
Security

13
13
13
13
13
13

/var/www/apps/conversion/tmp/scratch_2/313857181.doc
Last revision: 5/14/02

Page 2

Ford Credit PUPS Implementation

Revision History
Author
Becky Million

Date
07/30/99

Becky Million
Becky Million
Becky Million
Bob Leggett
Bob Leggett

03/09/00
06/26/00
10/20/00
11/22/00
03/22/01

Description
Initial Revision for launch of COMPASS application
on Facility G.
Updated for Facility A Implementation
Updated for JCLA and JCLG activities
Updated to include timings for Production releases.
Updated to include Element Type CA7JCL.
Updated to include Environment "I" in Activity FCA1.

/var/www/apps/conversion/tmp/scratch_2/313857181.doc
Last revision: 5/14/02

Page 3

Ford Credit PUPS Implementation

Background
PUPS is the new Ford Credit standard tool for building and migrating mainframe code.
The PUPS (Production Update Processing System) application was developed by the Material Planning & Logistics
(MP&L) group at Ford Motor Company. PUPS has been implemented in the following Ford Motor Company
locations: Material Planning & Logistic (MP&L), Brazil, Argentina, Purchasing and Finance, with and estimated
500 developers trained to use the tool by August, 1999.
The purpose of this document is to describe the PUPS Implementation at Ford Credit. It is a supplement to the
documentation handed out at the training session. Refer to your training handouts for specific information on using
the PUPS application.

PUPS Overview
PUPS Organization
Activity

Module

Elements

People

Activity is the highest level in PUPS and is dedicated to a group of programs that share the same migration path.
Module further defines an activity. Elements and People are attached to a module.
Elements are the programs within the module.
People are the developers and approvers authorized to work within the module.
PUPS supports four environments, Test, Integration, Education and Production. This chart shows how the PUPS
environments correspond to the COMPASS Platform and Legacy Application environments.
Facility

Activity

Description

Module

Description

Facility A

FCA1

ALL

All Source
Code

Facility A

FCA2

Non-IMS
programs for
Legacy
Applications
IMS programs for
Legacy
Applications

ALL

All Source
Code

Facility A

JCLA

Production JCL

ALL

Production

/var/www/apps/conversion/tmp/scratch_2/313857181.doc
Last revision: 5/14/02

PUPS
Environments
T Staging
I Integration
E Quality Assurance
P -- Production
T Staging
I -- Integration
E Quality Assurance
P -- Production
P -- Production
Page 4

Ford Credit PUPS Implementation

JCL
COBOL
Programs

Facility G

CMPG

COMPASS
Platform
(Development)

ALL

Facility G

CMPG

COMPASS
Platform
(Development)

RPC

RPC Shell
Programs

Facility G

JCLG

Production JCL

ALL

Facility H

CMPH

ALL

Facility H

CMPH

Facility H

JCLH

COMPASS
Platform
(Production)
Production JCL
monitored by
TS&O
COMPASS
Platform
(Production)

Production
JCL
COBOL
Programs

T Staging
I -- Integration
E FRST
P -- Quality Assurance
T Staging
I -- Integration
E Education/FRST
P -- Quality Assurance
P -- Production
I Staging
P -- Production

RPC

RPC Shell
Programs

I Staging
P -- Production

ALL

Production
JCL

P -- Production

Login
During the set-up period on each facility, it will be necessary to use the following clist upon login:
'fcrla07.comm.clist(dev)'
This clist will eventually become the Ford Credit development clist 'fcdba.comm.clist(dev)'

/var/www/apps/conversion/tmp/scratch_2/313857181.doc
Last revision: 5/14/02

Page 5

Ford Credit PUPS Implementation

PUPS Migration Process

Step
1

Action
Modify source code
Search for other developers who have the code checked out
Check out the element
Modify the element
Copy the source code to the staging library:
Facility A: FCU@BLD.PROD.STAGING.LIBRARY
Facility G: FCU@BLD.STAGING.LIBRARY
(Refer to Main Steps For Developers Using PUPS Migration Tool document
handed out at PUPS Training.)
Build Migration Request

Responsible Party
Developer

Developer

Approve migration request (see Approver section for requirements for each
environment.)

Approver

Submit the migration

Submitter

Monitor the "In-Flight" screen for build status, completion and failures.

Developers,
Submitter

At this time, the submitter role is handled by two separate teams: The Build Team and COCS. The Build Team is
responsible for migrations that occur on Facility G and H for the COMPASS platform. COCS is responsible for
legacy application migrations on Facility A.

Approvers
Environment
IT

Approver
Submitter

FRST

QTM

QA

Project Leader or Supervisor

PROD

Project Leader or Supervisor

Process
The submitters will monitor the In-Flight screen and will
approve and submit Migration Requests for the IT
environment.
The QTM Team will monitor the In-Flight screen and
will approve Migration Requests for the FRST
environment. This is a COMPASS environment and
exists only on Facility G.
QA Migration Requests will be approved by the
application's Supervisor or Project Leader on the InFlight screen.
COMPASS
For migration requests to the Production environment on
Facility H:
Complete the CMR form
Get a signature systems and business approvers
Deliver to the Build Team.
Legacy Applications
For migration requests to the Production environment on
Facility A: Submit a PUPS Build Request.
Note: If your changes require coordination of JCL and

/var/www/apps/conversion/tmp/scratch_2/313857181.doc
Last revision: 5/14/02

Page 6

Ford Credit PUPS Implementation

Environment

Approver

Process
CA7 changes you must fill out a PMR form and submit
it to COCS.

Training
MP&L provides training to each application team upon implementation of PUPS. Training for new developers is
provided upon request through Joe Mooney (JMOONEY1) at MP&L.

Support
Build Team Off-Hours Coverage for the COMPASS Platform
The Build Team is available 24x7 for emergency builds to correct an immediate problem in the Production
environment. Contacts are listed in order below. The developer is responsible for submitting the necessary
paperwork and signatures the following business day.
Contact
Primary Duty Analyst
Secondary Duty Analyst

PROFS ID
FCBTPRIM
FCBTSECD

COCS Off-Hours Coverage for Legacy Applications

Contact

PROFS ID

PUPS Tool Support

When developers have a problem using the PUPS tool they should first look to members of their team for assistance.
Once this resource is exhausted, contact the Build Team.
Contact
Members of the application team

Who should make contact

Developer

CDS ID or Mailing List

COMPASS Platform the Build

Team.

Developer

COMPASS Platform
fc_bldteam@www.client.ford.com

Legacy Applications -- Computer

Operations.

Application Infrastructure -- Technical

Support
MP&L

Build Team or COCS

Technical Services

Legacy Applications
JBOND2
KDUNCAN1
JMCCONN4
RALLEN31
AWEST6
RCHALELA
RHENRY1
JMOONEY1

System Maintenance
System maintenance is coordinated by the Application Infrastructure -- Technical Support team.
/var/www/apps/conversion/tmp/scratch_2/313857181.doc
Last revision: 5/14/02

Page 7

Ford Credit PUPS Implementation

Mainframe Delete Requests
Source code can be deleted by creating a delete request (#90 Build Delete Request - Delete Element from the
Application). Delete requests must be approved by an authorized approver and submitted. The delete request
remains in the history log. Note: This functionality replaces the Build Team's "Mainframe Delete Request" form.

Security
To use PUPS, each user must have the following:

A CDS record. PUPS uses information from CDS to populate its data tables.
A RACF ID that allows the user access to the appropriate Facility. The RACF ID must also belong to the Group
FCU@FC1. When requesting new RACF IDs, it is a good idea to model the ID after one that already uses
PUPS.
A PUPS security record. The specific privileges given to PUPS users depends upon the role of the user (See
Below).

Roles
Access the PUPS functionality is set up by roles. The Build Team will set up security for new developers.
Role
Approver
Approver/QTM
Developer
Submitter

Privilege
Checkout, Request, Cancel, Elmupd T, Approve, Contacts
Approve
Checkout, Request, Cancel, Elmupd T
Checkout, Request, Cancel, Approve, Submit, Elmupd T, Elmupd I, Elmupd E, Elmupd
P, Security

Post Migration Audit

The GAO requires that 10% of all migration requests and 100% of all emergency requests have a "Compare Report"
generated. Therefore, every 99th Production migration request and all emergency requests will be flagged. The
Compare Report must be reviewed and approved by a supervisor or project leader before the source code can be
migrated again.

Frequently Asked Questions (FAQs)

What is needed to create a Migration request from the TEST environment?

Anytime you modify source code, PUPS expects the RACF of the checkout, migration request and the owner of the
source code in the staging library to be the same. If you do not have the code checked out and the source code in the
staging library does not belong to you, PUPS will not allow you to create a migration request.
The order is as follows:
1. Check out the source code
2. Copy the code into the staging library
3. Create a migration request
Checkout RACF

RACF

/var/www/apps/conversion/tmp/scratch_2/313857181.doc
Last revision: 5/14/02

Page 8

Ford Credit PUPS Implementation

Migration
Request

/var/www/apps/conversion/tmp/scratch_2/313857181.doc
Last revision: 5/14/02

Owner of Source
in Staging Library

Page 9

Ford Credit PUPS Implementation

My Project Leader is not in today. How can I find out who else can approve my
request?
To find a list of approvers for your activity, go to the User Security Maintenance screen (#22). Do an inquiry
<PF17> on all the entries who have "approve" checked within the activity and module. If you do not recognize the
RACF ID, use the who (w) action to bring up the CDS record.

What is the process for adding new code to PUPS?

To add source code to PUPS:
1. Create an element profile. This defines the element to the PUPS tool.
2. Check out the program using the "n" (new) action.
Tips:
Only one developer can check out a new program.
Program source code cannot exist in the staging library.

When are Checkout Records needed?

Checkout records are required when source code is being modified. Check out records are not required when
migrating from one secure environment to another (i.e., "I" to "E").

How do I create a checkout record for an item already modified in the test library?
This scenario should occur for programs modified before the launch of PUPS. The recommended business practice
is to check source code out before you modify it. Before you can create a migration request, you must:
1. Create a checkout record (doesn't matter which environment).
2. Copy the source code into the staging library (FCU@BLD.PROD.STAGING.LIBRARY for Facility A or
FCU@BLD.STAGING.LIBRARY for Facility G)

How can I find out the names of the libraries used in PUPS in order to make sure my
program loaded?
To find the libraries, go to the Department Libraries (#45) screen. Enter the environment (or leave blank for all).
Once there you can browse any element in the library.

Can the Build Team create a Build Migration Request for a developer after hours?
No. The Build Team cannot create a Build Migration Request and approve the same request. The developer is
required to create the request. Once completed, the Build Team can approve and submit the request.

What are the Element Types?

Element Types are: Batch, Online, Subroutine, Copylib, Include, CA7JCL. The element type will be retrieved by
the tool if the Element Name is unique within the activity.

When can COMPASS changes be moved into Production?

For COMPASS Application Full Releases and Weekly Production Releases:

Type of change
MPP Weekly Release
BMP Weekly Release
Emergency Fix*

Date/Time released to
Production
2:45 AM Wednesday
8:00 AM - 1:00 PM Friday
Upon Request

/var/www/apps/conversion/tmp/scratch_2/313857181.doc
Last revision: 5/14/02

The signed CMR must be

received by*
COB Monday
COB Wednesday

Page 10

Ford Credit PUPS Implementation

* Risk assessments are required for all emergency fixes and CMRs that are received after the cut-off.

Pre-Release Verification in Systems S or Branch UV

Pre-release verification is used primarily to verify that the PC portion of the COMPASS application built properly.
When the Business and Systems agree, non-disruptive MPPs can be built one week early for verification purposes.
Remember: There is only one set of Production libraries! Pre-release verification occurs in Production.

I have a MPP change that I didn't submit. Can you just build it during the day?
No!! MPPs are interactive programs and must be moved to Production at a time when the COMPASS Branches and
Service Centers are not using the system. Most of the MPPs cannot be changed during business hours without
risking Production.

Within PUPS, some developers are notified when their jobs complete and others are
not. How can I be notified when jobs complete?
The notification is a function of TSO, not PUPS. Within PUPS, you can check the notification setting by typing TSO
PROFILE at the command line. The notification is a toggle, you will see either INTERCOM or line. The notification
is a toggle, you will see either INTERCOM or NOINTERCOM (among other settings in the profile).
To activate the intercom, type TSO PROFILE INTERCOM at the command line.

How can I get a hardcopy of the Compile Listing and Compare Report?
There is a new utility called "PUPS Print" that allows a developer to print OUTLIST or COMPARE datasets. The
utility can be accessed from the TSO main panel by selecting Applications (O) and PUPS Print (PC). The developer
must supply the environment, element name and report type.

When migrating both copybooks and programs in PUPS, how can I get the programs
to "wait" for the copybooks to finish processing?
First, build the migration request for the copybook; next, build the request for the calling program. When the calling
program is requested, PUPS will notify the user that the calling program will wait for the copybook to be migrated.
Please note: This action will not occur the first time a copybook is migrated as the Element Cross Reference is
updated upon each build.

When does the JCL sweep job run?

The sweep job runs Monday through Saturday at 3:30 PM on Facilities A, G and H. The Build Team checks the
PUPS in-flight queue at 3:00 PM. At this time, the last JCL jobs of the day are submitted to the sweep library.

It's after 3:30 PM and I need a JCL change for tonight's run. How can I get this
done?
After 3:30 PM, there are two things you must do. 1) Submit a request for a "special" that will run for that evening.
(Specials are handled by TS&O as per their process). 2) Create a change request in PUPS that can be submitted by
the Build Team on the next business day. This will make the change permanent.

/var/www/apps/conversion/tmp/scratch_2/313857181.doc
Last revision: 5/14/02

Page 11

Ford Credit PUPS Implementation

For Approvers Only

To approve a migration request you must be set-up as an approver in the PUPS tool. The steps are:
1.

Log on

2.

At the COMPASS Developers CLIST menu, take the default option.

3.

Enter PM at the options line to start the PUPS Migration tool.

4.

Go to the In-Flight Screen (#10)

5.

Search for Migration requests within the activity and module.

Use <PF17> to bring up the inquiry screen
Enter Activity. Leave Module blank and you will pick up requests for any module within your activity.

6.

Submitters:
QTM:
Supervisors and
Project Leaders:

7.

8.

Look for Migration requests where the "TO" environment is "I"

Look for Migration requests where the "TO" environment is "E"
Look for Migration request where the "TO" environment is "P"
and for legacy applications where "TO" environment is "E"

Actions (AC column):

"A" to approve the request
"C" to cancel the request. This action will post a "Cancel status message to the History
"P" to pull back your approval. This action will leave the migration request in "to be built"
approval.
"X" allows you to view the details of the migration request.

Table.
status for later

"R" For submitters only, they can recall the status from Submitted to Approved without
approval.

losing the

When the appropriate action has been taken, use <PF3> to back out of the screen.

/var/www/apps/conversion/tmp/scratch_2/313857181.doc
Last revision: 5/14/02

Page 12

Ford Credit PUPS Implementation

For Submitters Only

At this time, the submitter role is handled by two separate teams: The Build Team and COCS. The Build Team is
responsible for migrations that occur on Facility G and H for the COMPASS platform. COCS is responsible for
legacy application migrations on Facility A.

Submitting Builds
1.

The Build Team and COCS will monitor the In-Flight screen (#10) for new Migration Requests for their
respective applications.

2.

For migration requests to the Integration environment, the Build Team and COCS will approve. All other
environments, the submitters will wait for the authorized approver to approve the migration request. (See
section"For Approvers Only").

3.

Submit build requests by going to the Submit Request(s) screen (#30)

Actions (AC column):
"s" to submit the request
"x" to view the details of the request

4.

Monitor the In-Flight Screen (#10) for information regarding the build status, completion and failure of
submitted jobs

Production Emergencies
For emergency requests, the developer will check out source code, copy the modified source code to the staging
library and build a migration request. The migration type on the request will be Immediate.
The Build Team will change the Migration type on the request from "I" to "E", signifying that the job is being built
as an emergency. The "E" migration type takes the place of the supervisor's or project leader's approval. PUPS will
notify the supervisors listed as contacts. No follow-up is required by the submitting team.

Auto Relink
The PUPS tool has been designed to automatically relink programs that use a subroutine, when the auto relink
option flag has been set in the migration request. This flag is set by the developer. PUPS builds migration requests
for the programs that will be relinked and put them in "approved" status.
The auto relink has a limit of 50 programs. If there is a need to relink more than 50 programs, the developer must
notify the submitting team. The submitters will change the Migration type on the request from "I" to "IR" or "W" to
"WR" and will then submit the request.

Changing the Migration Request

To change a migration request:
Go to Build Migration Request (#5)
Use Inquiry (<PF17>) to search for the request
Enter a "C" (change) at the top of the screen
Modify the Migration Type.

Security
The submitters are responsible for updating security records. Use the Role definitions found in the Security section
of this document to Add (A), Change (C) or Delete (D) security records.

/var/www/apps/conversion/tmp/scratch_2/313857181.doc
Last revision: 5/14/02

Page 13

Ford Credit PUPS Implementation

/var/www/apps/conversion/tmp/scratch_2/313857181.doc
Last revision: 5/14/02

Page 14