Dynamic COBOL Code using DB2

satishboddu · New User Joined: 02 Aug 2011 Posts: 17 Location: India

Hello,

I have certain piece of code which is dynamic and likely to change for every Quarter,so i have thought of putting such COBOL code into a Db2 table and allow the users(technical) to change the code from a a CICS screen. I would like to fetch this code in to my COBOL program and then execute it without compiling it.
I would like to know if this is really possible!! If yes how??

Thanks,
Satish Boddu.

Bill Woodger · Posted: Tue Aug 02, 2011 2:14 pm

No, you can't dump a piece of Cobol source somewhere (anywhere), read the source into your program at run-time, and then run it.

Cobol on a mainframe is not interpreted, it is compiled.

And no, you will not be able to stick a chunk of compiled code somewhere, read it into your program and expect it to do anything meaningful.

You can include parameters somewhere on a dataset/database/whereever and included code in your, source-and-then-compiled, program to operate off the parameters.

gylbharat · Posted: Tue Aug 02, 2011 3:20 pm

Can you please explain the exact requirement in detail... this would help us in giving solutions....

satishboddu · New User Joined: 02 Aug 2011 Posts: 17 Location: India

@gylbharat
we are trying to incorporate business rules in to DB2 tables and prevent hard coding values and 'IF' checks in the code.

@Bill Woodger: Are there any alternatives to overcome this?? Pls suggest

gylbharat · Posted: Tue Aug 02, 2011 4:44 pm

Are these business rules in the cobol program?

satishboddu · New User Joined: 02 Aug 2011 Posts: 17 Location: India

yes Bharat,

they are the businnes rules in the cobol program

dbzTHEdinosauer · Posted: Tue Aug 02, 2011 5:01 pm

Bill Woodger · Posted: Tue Aug 02, 2011 5:08 pm

If you have rules "somewhere", external to your program, you can have a program read the rules.

Then you can have Cobol code which interrogates the rules and behaves accordingly.

If you update the rules, the program when it next interrogates them behaves according to the new rules.

If going this route, you should always validate the rules as a whole before acting on them. The location of the validation can depend on where you store the rules. If you get your rules from SYSIN or PARM for instance, the validation will be in your program. If you get the rules from a database, then the program which stored them can validate the cohesion of the rules once data entry/update is complete. Having something in the database/file to indicate that the data is validated is a good idea, then test that in the Cobol and reject if not valid.

You do not want to have something fancy with rules that have "loop-holes" so that you can screw up your system without changing anything but your rules.

dick scherrer · Posted: Tue Aug 02, 2011 7:43 pm

Hello,

satishboddu · New User Joined: 02 Aug 2011 Posts: 17 Location: India

Thank you all for your replies... the discussion is closed.

enrico-sorichetti · Posted: Wed Aug 03, 2011 6:20 pm

implementing business rules based on external table is not something likely to get answers on a forum!

unless the people from SAP are willing to disclose the SAP logic which does it

don.leahy · Posted: Wed Aug 03, 2011 6:49 pm

I have seen this sort of thing implemented a couple of times. It is no trivial task to maximize flexibility; the cost is always increased complexity. One system I saw was so flexible that they developed a cobol program that acted as a quasi compiler. This program translated user input (entered via online screen) into a series of instructions in a proprietary format that were then processed by another program. The user input had to be coded using a very arcane procedure that only one person in the company was trained in. An elaborate test facility also had to be built so that the end user could write and test his "code" before releasing it to production.

The cost and risk of building such an infrastructure needs to be weighed against the cost of having a programmer change a program every quarter or so.