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

2. 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

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

4. Environment Setup

5. 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

6. 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

7. 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

8. 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

9. 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)

10. Programming Tips

11.  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

12. 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

13. 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

14. Bonus: Free Labels

15. Bonus: Free Lookups

16. 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

17. Custom Copy Example

18. 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

19. Code Installation

20. 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

21. 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

22. 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

23. 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.)

24. 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.20140324)

25. 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

26. 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)

27. Support and Maintenance

28.  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

29. 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

30. 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

31. 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

32. Company Address Maintenance

33. Company Address: ~reports adctryrp.p 2+ 2.14.3 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

34. Company Address: ~screens

35. .NetUI Shows db:domain

36. Summary

37.  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

38. Questions?

39. Contact information  For further information or a copy of this presentation: Tammy Lonsberry (847) 628-4796 tlonsberry@sungate-solutions.com