Need some ideas to get rid of more hardcoding. Currently when we post to the ledger from sales all the accounts and what amounts to use are hardcoded in the program. As I am trying to get rid of as much hardcoding as I can I am look for an idea or if someone has already solved this via some kind of file layout or ?? Some of the amount are added, some are subtracted.
Here is one example.
MOVE SPACES TO LEDGER-REC REPORT-LINE.
MOVE 1020 TO GL06-ACCOUNT.
MOVE "DM" TO GL06-COMPANY.
IF PASS-COMPANY = "DM"
COMPUTE GL06-AMOUNT = SA05-MTH-LIST-PRICE
SA05-MTH-FRT-PORTION
SA05-MTH-ACCRUAL-USAGE
SA05-MTH-BBR
SA05-MTH-DEMO
SA05-MTH-REBATE
SA05-MTH-BROKER-COMM
- SA05-MTH-QTY-DISCOUNT
- SA05-MTH-ALLOWANCE
SA05-MTH-PREMIUM
SA05-MTH-MISCELLANEOUS.
Changing things to be parameter driven has various levels, and it depends on how far you want to go.
1. You could change the inline constant into a named constant in working storage. That way the value has to be changed in only one location. (A working storage constant can be a level 78 item, or a 01 item with a value. eg)
78 TRIGGER-COMPANY VALUE "DM".
vs
01 TRIGGER-COMPANY PIC X(2) VALUE "DM".
2. You can create an editable text file, an "ini" file if you will. Then you put name/value pairs into the text file, and your program has to have a routine that opens the file, loops using read next to read all the lines, and tests for the name, and loads the value into the appropriate working storage variable. So you have to have one working storage variable for each value in the text file.
eg file)
TRIGGER-CO=DM
SALES-ACOUNT=1020
3. Similar to #2, but instead of using a text file, you create a new cobol file. Probably a relative file with record# of 1, or an indexed file with key value of 1. The record would consist of all the names you want to use to replace the hard-coded values. You create a new maintenance screen which allows you to enter/edit the values, and save them into your record. Then in your original program, you add the new file, read the record using key 1, and now you have all your constants already in named fields. And in the code, you replace the inline constants with the new names.
4. Depending on your needs, that settings file I mentioned in #3 could have a proper key, and you could grab a different set of constants based on some variable property. It doesn't sound like you need this.
It sounds like you should simply create working storage constants unless you need to be able to change these values. If you do, I recommend a new cobol settings file rather than importing a text file, because your maintenance function can enforce business rules and you avoid typing errors as people try to edit the text file.
#settings#refactor#hardcode#constants
