You are here:

At the beginning of the Construct Stage, you are fortunate that many things have already been done for you.  Because of the hybrid approach taken during the design phase, a lot of the actual coding has been completed (although not actually applied).  Below is an overview of what has been done to this point and what is expected of you.

During the Analysis process, research was completed to determine all existing objects impacted by the Peoplesoft 8.3 version upgrade.  At Duke Energy, great pains have been taken to stay ‘vanilla’.  This has been and will continue to be one of the foundations of this installation.  Even so, the changes for upgrading from version 7.5 to 8.3 have had widespread impact.  The vast majority of the impact has been to the Duke ‘home grown’ standalone batch COBOL processes written to access the PS operational databases.

Once identified, all the batch objects were evaluated in consideration of the 8.3 impacts.  Any changes have been documented in two ways:

1.	A design ‘packet’ has been completed, reviewed for accuracy and filed.  This packet details the changes necessary 
2.	The batch object has been ‘checked out’ and the changes documented in Duke’s version control system (ChangeMan).  The changes have been coded but not actually applied.  The current code remains in place but commented as affected.  The replacement or changed code exists but is currently commented out.

So you can see what we mean when we say a hybrid design was accomplished.  Since the changes have been coded already, we can and do anticipate an accelerated Construct and Unit Test phase.  This is where you are……ready to begin transitioning these coded objects to install the commented out code and unit test in preparation for System testing which will begin in July.

 

Where do I go to find……..  

You’re wondering where to find things.  Below are listed the locations of some commonly used data.  You will use this reference information often and it will quickly become part of your memory bank.

Source	Library/Dataset	Instance (ADS vs. PRDA)
Production COBOL Program	DKLMS.HR.BASE.SOURCE(P054xxxx)	ADS
Production SQR Program	DKLMS.HR.BASE.SQRSRC(P054xxxx)	ADS
Production JCL	DKLMS.HR.BASE.JCL(u054xxxx)	ADS
Production DCLGENS/Copy members	DKLMS.HR.BASE.INCLUDE(xxxxxxxx)
DKLMS.COM.BASE.INCLUDE(xxxxxxxx)	ADS
8.3 Construct - Bind JCL	DK054.PS.APPUPG83.BINDLIB(B054XXXX)	ADS
8.3 Construct - JCL	DK054.PS.APPUPG83.JCL(E054XXXX)	ADS
8.3 Construct - Sequential Parmlib	DK054.PS.APPUPG83.PARMLIB(XXXXXXX)
DK054.PS.APPUPG83.PGMPARMS(XXXXXXX)	ADS
8.3 Construct – Includes (DCLGENS/Copy members)	DKLMS.HR.UT.INCLUDE(xxxxxxxx)	ADS
8.3 Construct – Test DASD	TS054.uuuuuuu.pppppppp.xxxxxxxxxx

Where ‘uuuuuuu’ = your TSO ID
‘pppppppp’ = program creating the dataset
‘xxxxxxxxxx’ = meaningful dataset description	ADS

In most cases, you will create the execution and bind JCL in order to unit test your code changes.  At this stage, you will not be creating system test JCL.  In fact, you will unit test your programs/objects from the staging libraries of ChangeMan.  All promotions to Unit Test will be done later by a single point of contact (SPOC/ UT Gatekeeper).  This is done to maintain the version control process in effect to stay synchronized with our multiple development environments.  

In addition to the hardcopy documentation (filed design packets), the same information is available online in the HRMS Artifact Index 2002 database.  

Armed with the information above, and assuming you have been able to navigate your way through Lotus Notes, you now have access to the analysis and design work completed to this point.  After reviewing this material, you are ready to charge ahead into ChangeMan to see how the designs have been coded into the existing ‘packages’.


 
What do I do……..

In a nutshell, you are expected to complete coding and unit test the objects/programs assigned to you.  You will accomplish the coding within ChangeMan.  Then, following successful compilation (staging), you will conduct a unit test guided by the unit test plan (UTP) which is part of your design packet.  The unit test results will be reviewed for accuracy and completeness.

Let’s break this section down to two main components and a quick note about standards:

1.	ChangeMan Usage
2.	Testing Practices
3.	Standards

 

ChangeMan

ChangeMan is accessed via option O.3 of ISPF. It is also used to develop/modify and compile programs. It is also used to control all migration of batch objects from development to production.  As previously stated, the programs/objects you will working with have already been ‘checked out’ from the production ‘baseline’ library into change packages where the designed changes have been coded but left commented out.  Let’s walk through an example start to finish.  First, option O.3 of ISPF brings you to this screen….


From this screen, select option 1 (Build) 
 
The following screen will appear…..


Select Option 6 (Stage)



 
This is the next screen to appear….


Select option 2 (component list) and enter the package# which is referenced in the object modification document of your design packet.  In this example, the package# is YHR2000096.

 
The following screen will appear….


Because we have specified only one program/object will be in a package, you will only see one item listed.  In this case, program P054MEDF.  From here, you will enter an ‘E’ (edit) as the line command beside the desired program. 
  
 Important Note:  
If you enter an ‘E’ and receive the message ‘*ERROR’ under the Request column (far right), then try entering ‘UC’ (unlock component) as the line command.  The word ‘UNLOCKED’ will then show under the Request column and you should be able to enter an ‘E’ and get into edit.

 
The edit screen will appear as follows:


From here, you have access to most ISPF functions and can edit to make changes.

First…… verify the 8.3 changes have been correctly referenced at the bottom of the ‘History of Changes’ section.  Update the Programmer name in the history section to add your name (not ID) as the modifier in addition to the name of the designer.

Then review the design documents and the program code to make sure what you see in the program matches what you see in the design.  If there are discrepancies, please bring them to the attention of your team lead.  Do not assume which is correct in the event of conflicting design vs. code.

 
Here is the history of changes for the 8.3 Upgrade entry…….

 
You will notice the TPR# REGS-59NLHE.  All changes entered for this program should be commented (by line) with the last 6 characters of the TPR# (59NLHE), so do a find for this number to locate the changes. 

 Again, do not depend solely on what you see in the program or what you see in the design documents.  Use them in tandem to make sure the designer did not miss something in one place or the other.  Raise a flag whenever something is different between the two sources.  Most likely, the designer is still on site and can add insight as to why something is the way it is.

 
An example of the type of change you will see is shown here……

 
You can the last 6 characters of the TPR# are referenced in the two sections above.  The commented line should replace the uncommented line, so just reverse the comment.  Do not delete the code.  We are basically reversing the comments to apply the changes and leave a history of what it had been previously. 

 
Making the change to the first section shown on the previous screen and exiting (using F3) will bring you to this screen….


This is a comparison that shows line by line what you changed.  You can page down, etc until you’re satisfied the changes you see are the changes you made.  Hit the F3 again to exit.

 
Upon hitting F3 from the comparsion, the following screen will appear.  However, if this is your first time in ChangeMan, you may have to enter it all.  This is just setting a batch job to compile or stage the program with the changes you just applied. 


 

If you do not want to compile the program at this point, just hit the F3 key.  To continue with the compile/stage, hit enter 

 
Hitting ‘Enter’ from the previous screen will bring you to this panel where you specify compiler options…

 
Again to abort the compile/stage, hit the F3 key.  To continue with the compile, hit ‘Enter’.  As mentioned before, you may have to enter the data on this panel the first time but it will be retained for future usage.  

One note of caution:  The DB2 Precompile is set to YES but sometimes will revert back to NO.  Make it a habit to verify this data.

If your compile is successful, the package component will be ‘activated’.  

 


While ChangeMan is used to ‘load’ objects to the production environment, it is the edit/construct mode of ChangeMan that you will use most.

General information about ChangeMan and how we are using it for our purposes.

	Package Title:  	Identifies batch object and contains a cross reference to TPR#
	Application:	YHR2
	DAP#:		6181
	Package Type:	PLANNED
	Package Time:	PERM
	Remote Site:	PRDB
	Install Date:	20020903
	Install Time:	0001 - 2359 
	
The staging libraries for a YHR2 packages are named:  DKLMS.CMNSTAGE.YHR2.#xxxxxx.yyy
						(where ‘xxxxxx’ = the pkg #  (ex. 001816)
							    	and  ‘yyy’  = pkg type  (ex.  LOD, SRC, etc))
	
	
	
	This is by no means all the information you need to know about ChangeMan but it will get you started.
	
 
	
Testing	

Once you have completed the changes and the package has been ‘activated’, you are ready to test.   Although the UTPs created during Design are relatively thorough, they are by no means 100% complete.  The coding consultants should lookout for any additional conditions that they can think of and add the conditions to the UTP.

Unit Testing Guidelines
•	Compare/Parallel – When possible, a ‘parallel’ test should be the constructor’s first choice when performing the unit test.  A ‘parallel’ test should be conducted when the program produces output, writes an extract file or creates results that can be visibly compared.
•	Test Conditions in a UTP – In some cases, it will not be possible to execute a ‘parallel’ test due to the fact that some programs perform updates/inserts.  If this is the case, test conditions within the UTP should be used for testing purposes.  The majority of design packets will contain an updated version of the program’s UTP with updated test conditions.  All the new test conditions, which are usually referenced by highlighted text, must be executed and successfully met.  Some of the older/previous test conditions will also need to be executed.  The team lead will assist in identifying which test conditions should be tested.
•	Special Cases – There will be cases where the constructor will not be able to perform a ‘parallel’ test and, due to the fact that some design packs do not contain a UTP, will not be able to meet test plan conditions.  This will usually be the case for the programs that have only been modified to remove the ‘#’ sign in affected field names.  When this is the case, the following steps/conditions must be met in order to perform a unit test:
•	Program must be compiled and executed.
•	Program results (error messages, error reports, control reports, etc) must be captured via screen shots, printouts, etc.
•	For programs that perform updates/inserts, affected records should be….
a.	Pulled up and verified on-line via screen shots and printouts.
b.	Updated on-line.
c.	Saved on-line.

You will be testing in the PSHR??? instance.  This means you will need to ‘bind’ your programs to this instance.  Sample Bind JCL will be provided and should be program specific and stored for reference in the BINDJCL PDS discussed earlier in this section.  When setting up test JCL, follow the naming standard shown previously.  You will need to create test datasets (again, reference the naming conventions listed earlier).

At Duke Energy, the Unit Test results are documented and provided to a reviewer (UT Reviewer) who reviews them.  To make this process smoother, there are several things you can do.  Consult a Duke employee or an experienced consultant to get a feel for the process.  Beyond that, here are a few tips.

•	For each test condition, provide printed materials that show how the data looked prior to the test, what test data was used, and the results after the test.  
•	Make sure all ‘expected results’ can be clearly identified
•	Highlight specific cases that are applicable to the test case
•	Print reports headers/footers, etc. to verify dates, page #’s
•	‘Foot’ any control reports.  Don’t make the reviewer search and add.



Additional Pointers

•	When creating test datasets, use LABEL=RETPD=nnnn, where nnnn is a 1 to 4-digit number specifying the number of days that the dataset must be kept before it can be deleted

•	When creating test datasets, use SPACE=(TRK,(15,XX),RLSE) where XX is the max number of tracks needed.  All primary space requested is allocated and secondary space is released if not needed.   
     						


	Parm Entry Tables
	
The following tables are used to avoid the hard coding of parameters and valid values in the batch obejcts you are working with:

PS_D_PGM_PARM_TBL
PS_D_PGM_PARM_CO
PS_D_PARM_ENTRY
PS_D_REPORT_TBL

Testing for parameters should be in most Unit Test Plans.   If not, add them.  Please make sure that the following situations are covered. 

		Parameter row does not exist at all on PS_D_PARM_ENTRY.
		Parameter row exists with no parameter information.
		Parameter row exists with valid data.
		Parameter row exists with invalid data

 
	
	Standards

Since most of the coding has been designed and exists in the packages you will be working with, this overview will not deal with a lot of the standards and practices developed and followed during this effort.  Be assured, however that strict enforcement of design and coding standards will take place.  Code reviews and Unit Test Reviews will be conducted to verify these standards and practices are not compromised.

One aspect of standards we do want to cover is the entry of common messages used in the batch objects you will be working with.	These Error Messages must be entered into instance PSHRJOB and are stored on PS_MESSAGE_CATALOG.  There is an automated daily process that will proliferate error messages as well as other parameter related data to the correct instances to aid the development and testing process. Documentation on entering messages into PeopleSoft can be found in the Construct Stage Artifact Index der @Admin (by Gary Shroyer).  Index name is Construct – Message Catalog Entry.