View previous topic :: View next topic
|
Author |
Message |
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. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
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. |
|
Back to top |
|
|
gylbharat
Active Member
Joined: 31 Jul 2009 Posts: 565 Location: Bangalore
|
|
|
|
Can you please explain the exact requirement in detail... this would help us in giving solutions.... |
|
Back to top |
|
|
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 |
|
Back to top |
|
|
gylbharat
Active Member
Joined: 31 Jul 2009 Posts: 565 Location: Bangalore
|
|
|
|
Are these business rules in the cobol program? |
|
Back to top |
|
|
satishboddu
New User
Joined: 02 Aug 2011 Posts: 17 Location: India
|
|
|
|
yes Bharat,
they are the businnes rules in the cobol program |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
satishboddu wrote: |
we are trying to incorporate business rules in to DB2 tables and prevent hard coding values and 'IF' checks in the code |
If I were you,
I would extend my knowlede
and learn about db2 constraints and db2 triggers.
These can be combined with a well designed business rules table
that could be modified.
Or even code a 'table driven' cobol module to cause conformance.
but, that must be well designed, also. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
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. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
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. |
A few -places i've been wanted to have their processes driven by external rules tables. What they found (very lae in testing) was that maintenance to the table(s) could cause the rules to "fire" in different orders. No matter how you implement, this will be unacceptable. |
|
Back to top |
|
|
satishboddu
New User
Joined: 02 Aug 2011 Posts: 17 Location: India
|
|
|
|
Thank you all for your replies... the discussion is closed. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10886 Location: italy
|
|
|
|
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 |
|
Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
|
|
|
|
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. |
|
Back to top |
|
|
|