Please Don’t Do That! Common Programming Mistakes Tammy Lonsberry Sr. Programmer/Analyst Sungate Solutions, Inc.

About me  Tailoring and customizing Progress code for QAD users since 1995  Most versions (Mfg/Pro 7.3 – QAD EA 2013 SE)  All User Interfaces (CHUI, GUI, Desktop,.NetUI)  Progress and Oracle db’s  Active PEG member  Long time consultant with exposure to many different environments, processes, protocols … and many lessons learned, too often the hard way

Agenda  Environment Setup  Programming Tips  Code Installation  Support and Maintenance  Summary  Questions

Environment Setup

Environment Setup Basics  The basics include a minimum of 3 databases and 3 code environments  Databases:  Production  User Testing  Development  Code Environments:  Production  Test  Development

Directory Layout  Do: Keep custom code separate from QAD  Do: Keep 3 rd -party code separate from QAD  Do: Keep “layers” of directories for the separate code environments  Prod = top layer  Test = middle layer  Dev = lowest layer  Provide an easy way to peel away the customizations and 3 rd -party apps  Can run standard QAD with simple Propath change  Can run any code environment against any database  Better ability to isolate root cause of code issues

Propath Tips  Keep Propath consistent across all environments, UI’s, users .NetUI Propath should match non-.NetUI Propath  All end-users should use the same Propath  No source  Prod users = only Prod.r’s  Test users = Test then Prod  All developers should use the same Propath  Includes all source  Same directories in the same order  Eliminate guesswork; use, to get correct version of code Watch for stale copies in your start-up directory; in Test

Propath Examples  Production (no source) PROPATH=.  Startup directory /apps/qad/mods  Prod Mods (in-house custom code) /apps/qad/trm  Trade Management (TrM) /apps/qad  QAD /apps/qad/bbi  Test PROPATH=. /apps/qad/test  Test Mods /apps/qad/mods  Prod Mods /apps/qad/trm /apps/qad /apps/qad/bbi

Propath Examples  Development (full source) PROPATH=.  Startup directory /apps/qad/test  Test compiled.r’s /apps/qad/test/src  Test source code /apps/qad/mods  Prod compiled.r’s /apps/qad/mods/src  Prod source code /apps/qad/trm  TrM compiled.r’s /apps/qad/trm/src  TrM source /apps/qad/trm/xrc  TrM encrypted source /apps/qad  QAD compiled.r’s /apps/qad/src  QAD source /apps/qad/xrc  QAD encrypted source /apps/qad/bbi  QAD (misc. include files)

Programming Tips

 Goal: Make code easier to read, understand  Leads to faster investigation, troubleshooting, problem resolution Faster response time = happy users & management  Do: Add code comments  Messages  Place message text within comment to assist with code readability /*ITEM NUMBER DOES NOT EXIST*/ {pxmsg.i &MSGNUM=16 &ERRORLEVEL=3}  Use brief code comments to explain why  The “what” is obvious; the “why” is not Explain business reasons; these change over time Explain why this logic/algorithm/method was used

Programming Tips  Don’t: Abbreviate field or variable names  Prohibits ease & effectiveness of text searches  Ex: Never use code_fld for code_fldname  Do: Recycle & Reuse  Recognize reusable code segments  Eliminate redundant code No minimum number of lines; 2 lines repeated is too many Gets out of sync too easily Makes code unnecessarily lengthy, harder to read, harder to maintain  Use internal procedures, include.i files, external programs

Programming Tips  Do: Use QAD variables to gain bonus features  Example: Use part/part1, site/site1  Freebies include:  Field Labels (and their multi-language translations)  Field Lookup browses  Field Help

Bonus: Free Labels

Bonus: Free Lookups

Programming Tips  Custom copies – Think beyond the code  When creating a copy of a standard QAD program in order to rename it and customize it, also check for:  Lookup browses  Field labels  On screen  On output

Custom Copy Example

Programming Tips: Data  Code development often includes data, too  Examples of developer’s data:  When creating data:  Always add to Dev database first  Avoid:  Collisions with other developers  Mismatches  Out-of-sync scenarios Browses Drill-downs Field lookups Generalized Codes Labels Menu options Messages Program Information

Code Installation

Code Installation Do’s:  Do: Put source programs (.i,.p) in /src directory  Do: Put compiled code (.r) in applicable 2- letter subdirectories  Ex: /us/xx  Do: Keep all related.i’s,.p’s,.r’s in sync  Always installed together, into the same environment, at the same time  Follow this for all code, including:  ECO’s (patches)  Add-on modules  3 rd -party apps

Code Installation Don’ts:  Don’t: Put source programs in a 2-letter subdirectories  Or in any directory except /src  Don’t: Install.r without corresponding source  Don’t: Keep duplicate copies in multiple directories  Development directory should contain only code in active development  When complete, move it to Test  Test directory should contain only code waiting to be tested  When complete and approved, move it to Prod

Code Installation  Do: Devise and follow an installation process  Methods include:  Can use 3 rd party apps  Can develop your own scripts, programs  Can be completely manual  List the steps, then step the list  Self-documenting  Becomes an easy checklist  Assists with code version control  Increases overall environment stability

Code Installation  Do: Use code “check out” process  Ensures that only one person is working on a program at a time  Avoids coding conflicts  Avoids lost work, accidental overwrites  Sample check out method  Use a designated folder (ex: …/src/checkout)  Place a simple text file into this folder  File name = program name (ex: xxabc.p.txt)  Contents include: Developer name or initials Date Reason (ex: ECO #, project ID, case #, etc.)

Code Installation  Do: Keep source code history  Can do immediate roll-backs  Can do diff’s to determine version changes  Sample code history method  Use a designated folder (ex: …/src/history)  Copy current Prod version to this folder  Add a date extension (ex: xxabc.p )

Installation Includes Data, Too  Manage data in the same manner as code  Data and code move through the installation steps together; same place, same time  Dev  Test  Test  Prod  Data can be dumped and loaded  Don’t retype it into each database  Develop simple tailored versions of QAD’s dump/load procedures  Browses  With.NetUI, can use Browse Import/Export  Without.NetUI, dump/load applicable tables

Installation Example 1. Diff it  Compare your modified code to the existing version  Ensure the only changes are yours -- no more, no less  Do this for any environment (Test, Prod, etc.) 2. Keep history (Prod only)  Copy production code; add date extension 3. Install code & data  Includes source (.i,.p) and.r  Move, don’t copy  Load data into target database(s) 4. Remove check out file (Prod only)

Support and Maintenance

 No program is ever 100% final  Always keep in mind future modifications, enhancements, testing & troubleshooting  Don’t:  Develop a report without any selection criteria  Develop data exports, imports or interfaces without any selection criteria  Develop a program that executes fully by simply selecting it from the menu

Support and Maintenance  Do: Add more selection criteria than required  Reports, data exports, imports  Do: Provide a way to do quick & simple testing with a small number of records  Do: Provide a way to run every program and process outside of production  Especially useful for interfaces, data loads, automated jobs, processes requiring scripting or OS commands (such as FTP), etc.  Provide a way to test individual steps of a larger process

Support and Maintenance  Provide intuitive menu titles  Make it clearly obvious what type of program it is Maintenance Report Browse Utility  Provide enhanced descriptions  Add details about a program’s function as informative screen text Especially helpful for utility programs, data exports and imports Ensure text is visible in.NetUI

Support and Maintenance  Always change Company Address after a database refresh  Make it clear to users (and developers) what database they are logged into  Ensure that report titles always indicate the source database  Use 2.12 Company Address Maintenance  Change address for: ~reports ~screens ~taxes

Company Address Maintenance

Company Address: ~reports adctryrp.p Country Code Report Date: 03/13/14 Page: 1 Your Company Name **TEST** Time: 11:20:59 Alt Ctry Name EC NAFTA DEA GATT Group Type Code UAE UAE No No No No UKR Ukraine No No No No URY Uruguay No No No No USA United States of America No No No No US VEN Venezuela No No No No VIR Virgin Islands (U.S.) No No No No VNM Viet Nam No No No No WIN West Indies No No No No ZAF South Africa No No No No End of Report

Company Address: ~screens

.NetUI Shows db:domain

Summary

 Standards, policies and procedures – these are not your enemy!  Following best practices leads to:  Faster response time  Happier end-users  Lower IT support costs  Less stress, less headaches

Questions?

Contact information  For further information or a copy of this presentation: Tammy Lonsberry (847)