Home > Archive > Cobol > September 2005 > Modernization of COBOL Applications
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Modernization of COBOL Applications
|
|
|
|
I've been thinking about the modernization of COBOL applications running on
a mainframe environment so I decided to work on a rambling set of questions.
Seems to me that there is growing move to "enable" mainframe functions with
the littlest effort possible. I've seen the obvious solutions that are move
the application to a Unix flavor...or port some portion to .NET framework,
however, I was thinking more of the case where the existing function is
appropriate and what was needed was an extension out into the new world. I
am looking at the old application branching out as well as how new
requirements can be solutioned in an existing environment using new
tooling/design patterns.
For the existing case. If you can imagine - we have a module that updates a
customer from some green screen. I would want to enable the update function
as a callable service. All authorization and authentication issues aside -
the desire would be to have a module that can be called by "either" the CICS
transaction or via, say, a SOAP service request.
I don't see immediately how the architecture of a typical COBOL application
would manage to accomplish this easily. For existing function, it seems
that there is a multi phase approach that is required - the extraction of
business rules that define the operation (what is needed to update a
customer), the extraction of the logic rules (who and how is this allowed)
and the creation of the presentation of the rules. Finally, there is the
communication of the request to the actual transaction. For the new
functions, it would be a much easier as it would be a case of just designing
the modules with those business rules truly externalized in the first place.
Would it seem more appropriate that the a new calling module be "non CICS"
and call the CICS module...and leaving the CICS green screen transactions as
just with the function externalized...or does it make more sense to
completely decouple the CICS from the act of updating the customer account?
Can CICS call a non CICS program now that I think about it..? *It's been a
while ;-) *
In my mind, it makes more sense to remove the CICS subsystem from the
equation - but then I'm left with what is the best option to implement the
transaction based activities...should I have a daemon running unders USS on
z/OS or some other method of application triggering....? CICS has been
updated recently to be pretty flexible in terms of some web enablement but I
just don't like the idea of it. Is that *dumb* of me?
Should I look at migrating or using a z/Linux LPAR as the front door? Seems
to bring into play a lot of uneccessary networking - I don't believe that
there is a communication channel supported...
I'm also looking at the same ideas for non CICS based items that are today
Batch based but have some scope for function use. The same question exists
here...is there a standard transaction processor to use ?
Anyone have any good resources? Anything on creating mainframe web services
framework - which, whilst not exactly what I'm looking at, would give me
some good pointers. Is there a decent example of how to setup portals for
new functions...so for example, creating a portal so that an operations team
could look at the current system status, or help desk look at customer
configurations..etc..or setting up LDAP for authorizations, or UDDI
registry, etc etc?
To reiterate - I am not looking to move to Unix/Windows flavor platform
(except if it can be resident on a mainframe). If you believe the
Windows/Unix is the only "real" method to do this type of work..I'd be
interested to know why?
I think ultimately, I'd be really interested in something that was like the
http://www.droplets.com/ which seems to be a pretty neat deployment method
for mainframe activity :-)
My final question - if I may be so bold - is that reading online I see a lot
of the function that is being enabled is simple presentation layer type
items (so registering for a plane seat on the web versus on a green screen)
or access to people's tax records.....does anyone know of a real example of
a mainframe application being enabled to provide some function that could
not be implemented using some Host-On-Demand, Java 3270 emulator ? In other
words, any true b2b type activity ?
This last question I didn't actually do any research yet, so I will probably
go find some of those white paper customer success stories...so unless it is
off the top of your head don't worry too much :-)
I will read this again tomorrow to see if it still makes sense...and make
updates if necessary....
MANY thanks in advance...
JCE
| |
|
| In article <sLPVe.68865$p_1.47526@tornado.tampabay.rr.com>,
jce <defaultuser@hotmail.com> wrote:
[snip]
>For the existing case. If you can imagine - we have a module that updates a
>customer from some green screen. I would want to enable the update function
>as a callable service. All authorization and authentication issues aside -
>the desire would be to have a module that can be called by "either" the CICS
>transaction or via, say, a SOAP service request.
Where do the customer data 'live' (mainframe/elsewhere) and in what format
(flat file/VSAM/database)?
>
>I don't see immediately how the architecture of a typical COBOL application
>would manage to accomplish this easily. For existing function, it seems
>that there is a multi phase approach that is required - the extraction of
>business rules that define the operation (what is needed to update a
>customer), the extraction of the logic rules (who and how is this allowed)
>and the creation of the presentation of the rules.
Let me sing this back to see if I'm learning the song.
1) Initiate customer update request.
A) Does the initiating user have any customer update authority?
i) No - send 'not you, buddy' notice and terminate transaction
ii) Yes - CONTINUE.
2) Prepare to and accept user input to identify customer for update.
3) Validate input
A) is input in valid format (all letters/numbers in the right places)?
i) No - send 'bad format' message and GO TO 2)
ii) Yes - see if customer exists in system
a) No - send 'not here - re-enter or use A)dd function'
and GO TO 2)
b) Yes - does user have auth to update this class of customer?
1) No - send 'lowly peon' msg and GO TO 2
2) Yes - CONTINUE
4) Prepare to and accept user input to modify identified customer.
5) Validate input
A) is input in valid format (codes entered are valid update types)?
i) No - send bad code(s) msg and GO TO 4)
ii) Yes - are codes valid for this kind of customer?
a) No - send 'not for this one, you don't' msg and GO TO 4)
b) Yes - send 'are you sure?' msg and get response
1) is response valid?
A) No - send 'Y/N, please?' msg and GO TO 5.A.ii.b
.... etc.
Now... the question of 'the extraction of business rules' and 'the
extraction of logic rules' is where it gets sticky. Take the example of
an insurance-claims system. It seems logical and businesslike to allow
for a claim to be made for the treatment of uterine infections... BUT NOT
if the policy's group doesn't have a rider to cover such treatments...
.... then it's OK... BUT NOT IF the claimant is a male...
.... BUT IF the claimant is a male who has a female relative who is also
covered by the policy then it's OK...
.... BUT NOT IF the claimant is a male who has a female relative who is
also covered who has had a hysterectomy...
.... BUT IF the claimant is a male who has a female relative who is also
covered who has had a hysterectomy AND the date of the hysterectomy is
greater than the date of the uterine infection treatment (someone left the
claim in a drawer for six months) then it's OK...
.... BUT NOT IF the claimant is a male who has a female relative who is
also covered who has had a hysterectomy AND the date of the hysterectomy
is greater than the date of the uterine infection treatment (someone left
the claim in a drawer for six months) AND the date of the uterine
infection treatment precedes the effective date for policy's rider which
covers such treatments...
.... et and cetera. I think I'll stop now.
(note to newbies - it might be helpful to keep situations like this in
mind the next time you ask 'why would *anyone* code an IF statement that
goes on for four-and-a-half pages of greenbar?')
(addendum to note to newbies - if you need to then ask a Local Geezer
'What is 'greenbar'?')
DD
| |
| Jeff Lanam 2005-09-14, 6:55 pm |
| On Wed, 14 Sep 2005 14:14:10 +0000 (UTC), docdwarf@panix.com () wrote:
>
>
>(addendum to note to newbies - if you need to then ask a Local Geezer=20
>'What is 'greenbar'?')
>
Big paper windows.
| |
|
| In article <4jkgi19m5eqpsa2b1plqtmth0ctrlro9m2@4ax.com>,
Jeff Lanam <jeff-dot-lanam@hp-dot-com-not.net> wrote:
>On Wed, 14 Sep 2005 14:14:10 +0000 (UTC), docdwarf@panix.com () wrote:
>
>
>
>Big paper windows.
Or maybe a drinking-establishment specialising in concoctions containing
chartreuse.
DD
| |
| William M. Klein 2005-09-14, 6:55 pm |
| I have ZERO "real-world" experience doing this, but I do follow a number of
vendors who provide solutions/products targeted at this. A couple things you
might want to look at (even if it is just for ideas) are:
WebSphere Developer for zSeries at:
http://www-306.ibm.com/software/awdtools/devzseries/
or
Micro Focus Express Enterprise Edition "Component Generator", see:
http://supportline.microfocus.com//...30/mx30indx.htm
and look for the "Component Generator" documentation.
--
Bill Klein
wmklein <at> ix.netcom.com
"jce" <defaultuser@hotmail.com> wrote in message
news:sLPVe.68865$p_1.47526@tornado.tampabay.rr.com...
>
> I've been thinking about the modernization of COBOL applications running on a
> mainframe environment so I decided to work on a rambling set of questions.
>
> Seems to me that there is growing move to "enable" mainframe functions with
> the littlest effort possible. I've seen the obvious solutions that are move
> the application to a Unix flavor...or port some portion to .NET framework,
> however, I was thinking more of the case where the existing function is
> appropriate and what was needed was an extension out into the new world. I
> am looking at the old application branching out as well as how new
> requirements can be solutioned in an existing environment using new
> tooling/design patterns.
>
> For the existing case. If you can imagine - we have a module that updates a
> customer from some green screen. I would want to enable the update function
> as a callable service. All authorization and authentication issues aside -
> the desire would be to have a module that can be called by "either" the CICS
> transaction or via, say, a SOAP service request.
>
> I don't see immediately how the architecture of a typical COBOL application
> would manage to accomplish this easily. For existing function, it seems that
> there is a multi phase approach that is required - the extraction of business
> rules that define the operation (what is needed to update a customer), the
> extraction of the logic rules (who and how is this allowed) and the creation
> of the presentation of the rules. Finally, there is the communication of the
> request to the actual transaction. For the new functions, it would be a much
> easier as it would be a case of just designing the modules with those business
> rules truly externalized in the first place.
>
> Would it seem more appropriate that the a new calling module be "non CICS" and
> call the CICS module...and leaving the CICS green screen transactions as just
> with the function externalized...or does it make more sense to completely
> decouple the CICS from the act of updating the customer account? Can CICS call
> a non CICS program now that I think about it..? *It's been a while ;-) *
>
> In my mind, it makes more sense to remove the CICS subsystem from the
> equation - but then I'm left with what is the best option to implement the
> transaction based activities...should I have a daemon running unders USS on
> z/OS or some other method of application triggering....? CICS has been
> updated recently to be pretty flexible in terms of some web enablement but I
> just don't like the idea of it. Is that *dumb* of me?
>
> Should I look at migrating or using a z/Linux LPAR as the front door? Seems
> to bring into play a lot of uneccessary networking - I don't believe that
> there is a communication channel supported...
>
> I'm also looking at the same ideas for non CICS based items that are today
> Batch based but have some scope for function use. The same question exists
> here...is there a standard transaction processor to use ?
>
> Anyone have any good resources? Anything on creating mainframe web services
> framework - which, whilst not exactly what I'm looking at, would give me some
> good pointers. Is there a decent example of how to setup portals for new
> functions...so for example, creating a portal so that an operations team could
> look at the current system status, or help desk look at customer
> configurations..etc..or setting up LDAP for authorizations, or UDDI registry,
> etc etc?
>
> To reiterate - I am not looking to move to Unix/Windows flavor platform
> (except if it can be resident on a mainframe). If you believe the
> Windows/Unix is the only "real" method to do this type of work..I'd be
> interested to know why?
>
> I think ultimately, I'd be really interested in something that was like the
> http://www.droplets.com/ which seems to be a pretty neat deployment method for
> mainframe activity :-)
>
> My final question - if I may be so bold - is that reading online I see a lot
> of the function that is being enabled is simple presentation layer type items
> (so registering for a plane seat on the web versus on a green screen) or
> access to people's tax records.....does anyone know of a real example of a
> mainframe application being enabled to provide some function that could not be
> implemented using some Host-On-Demand, Java 3270 emulator ? In other words,
> any true b2b type activity ?
>
> This last question I didn't actually do any research yet, so I will probably
> go find some of those white paper customer success stories...so unless it is
> off the top of your head don't worry too much :-)
>
> I will read this again tomorrow to see if it still makes sense...and make
> updates if necessary....
>
> MANY thanks in advance...
>
> JCE
>
>
>
>
>
| |
| Joe Zitzelberger 2005-09-14, 9:55 pm |
| In article <sLPVe.68865$p_1.47526@tornado.tampabay.rr.com>,
"jce" <defaultuser@hotmail.com> wrote:
> I've been thinking about the modernization of COBOL applications running on
> a mainframe environment so I decided to work on a rambling set of questions.
>
> Seems to me that there is growing move to "enable" mainframe functions with
> the littlest effort possible. I've seen the obvious solutions that are move
> the application to a Unix flavor...or port some portion to .NET framework,
> however, I was thinking more of the case where the existing function is
> appropriate and what was needed was an extension out into the new world. I
> am looking at the old application branching out as well as how new
> requirements can be solutioned in an existing environment using new
> tooling/design patterns.
I think the easiest way to accomplish this is to expose your current
functions as web services.
Is this a 3270 green screen only? Or can clients access the app via
tcp/ip, appc, mqseries, etc?
There are products that will do transparent conversion of green screens
into web services. GT-Software comes to mind. So does something called
"ScreenSurfer", but I can't remember who makes that.
> For the existing case. If you can imagine - we have a module that updates a
> customer from some green screen. I would want to enable the update function
> as a callable service. All authorization and authentication issues aside -
> the desire would be to have a module that can be called by "either" the CICS
> transaction or via, say, a SOAP service request.
If your apps are set up with business modules that can be invoked to
perform their function without the screens. IBM has a SOAP for CICS
example out there. I haven't used it and can't speak about it.
> Would it seem more appropriate that the a new calling module be "non CICS"
> and call the CICS module...and leaving the CICS green screen transactions as
> just with the function externalized...or does it make more sense to
> completely decouple the CICS from the act of updating the customer account?
> Can CICS call a non CICS program now that I think about it..? *It's been a
> while ;-) *
CICS is going to help you load-balance, scale and ease your networking
code. And you can call non-CICS programs all you want -- it is actually
quite a bit faster than a LINK or XCTL.
Why would you want to rewrite all of that...
> I think ultimately, I'd be really interested in something that was like the
> http://www.droplets.com/ which seems to be a pretty neat deployment method
> for mainframe activity :-)
Interesting...
| |
| Pete Dashwood 2005-09-15, 3:55 am |
|
<docdwarf@panix.com> wrote in message news:dg9b7i$e0l$1@reader1.panix.com...
> In article <sLPVe.68865$p_1.47526@tornado.tampabay.rr.com>,
> jce <defaultuser@hotmail.com> wrote:
>
> [snip]
>
>
> Where do the customer data 'live' (mainframe/elsewhere) and in what format
> (flat file/VSAM/database)?
>
>
> Let me sing this back to see if I'm learning the song.
>
> 1) Initiate customer update request.
> A) Does the initiating user have any customer update authority?
> i) No - send 'not you, buddy' notice and terminate transaction
> ii) Yes - CONTINUE.
>
> 2) Prepare to and accept user input to identify customer for update.
>
> 3) Validate input
> A) is input in valid format (all letters/numbers in the right places)?
> i) No - send 'bad format' message and GO TO 2)
> ii) Yes - see if customer exists in system
> a) No - send 'not here - re-enter or use A)dd function'
> and GO TO 2)
> b) Yes - does user have auth to update this class of customer?
> 1) No - send 'lowly peon' msg and GO TO 2
> 2) Yes - CONTINUE
>
> 4) Prepare to and accept user input to modify identified customer.
>
> 5) Validate input
> A) is input in valid format (codes entered are valid update types)?
> i) No - send bad code(s) msg and GO TO 4)
> ii) Yes - are codes valid for this kind of customer?
> a) No - send 'not for this one, you don't' msg and GO TO 4)
> b) Yes - send 'are you sure?' msg and get response
> 1) is response valid?
> A) No - send 'Y/N, please?' msg and GO TO 5.A.ii.b
> ... etc.
>
> Now... the question of 'the extraction of business rules' and 'the
> extraction of logic rules' is where it gets sticky. Take the example of
> an insurance-claims system. It seems logical and businesslike to allow
> for a claim to be made for the treatment of uterine infections... BUT NOT
> if the policy's group doesn't have a rider to cover such treatments...
>
> ... then it's OK... BUT NOT IF the claimant is a male...
>
> ... BUT IF the claimant is a male who has a female relative who is also
> covered by the policy then it's OK...
>
> ... BUT NOT IF the claimant is a male who has a female relative who is
> also covered who has had a hysterectomy...
>
> ... BUT IF the claimant is a male who has a female relative who is also
> covered who has had a hysterectomy AND the date of the hysterectomy is
> greater than the date of the uterine infection treatment (someone left the
> claim in a drawer for six months) then it's OK...
>
> ... BUT NOT IF the claimant is a male who has a female relative who is
> also covered who has had a hysterectomy AND the date of the hysterectomy
> is greater than the date of the uterine infection treatment (someone left
> the claim in a drawer for six months) AND the date of the uterine
> infection treatment precedes the effective date for policy's rider which
> covers such treatments...
>
> ... et and cetera. I think I'll stop now.
>
I 'm really sorry you did. That was brilliant! Some time ago I worked for a
major insurer where we encountered this kind of nonsense frequently. I used
to refer to these cases as the 'one legged black lesbian dwarves' (I was
young and irreverent; nowadays I would drop the 'black'... It is really OK
to insult disabled, gay, and especially, dwarves, in one sentence, but
coloured people have definitely had enough...I'm not one to put the boot in
when people are down... ) This is one of the best examples I have ever seen
of the kind of exceptions that test program development. Managers want
simple rules; the real world has the above.
Well done, Doc!
> (note to newbies - it might be helpful to keep situations like this in
> mind the next time you ask 'why would *anyone* code an IF statement that
> goes on for four-and-a-half pages of greenbar?')
>
No. It might be useful to keep in mind the basic tenets of Boolean
simplification and reduce it to a few lines of greenbar... Or think about
alternatives like EVALUATE...
> (addendum to note to newbies - if you need to then ask a Local Geezer
> 'What is 'greenbar'?')
Outside the US it is sometimes referred to as 'lineflo'.
Pete.
| |
|
| In article <3os7emF78ubjU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:dg9b7i$e0l$1@reader1.panix.com...
[snip]
>
>I 'm really sorry you did. That was brilliant!
Pfoo... you'se jes' easily impressed.
>Some time ago I worked for a
>major insurer where we encountered this kind of nonsense frequently.
'Nonsense'? That might be applied to 'true arcana', such as certain areas
of accounting designed for Special Interests (I recall, vaguely, certain
oil-revenue procedures that were valid only in the states of Oklahoma,
Arkansas and Texas (named OAT for that reason) but I chose those examples
because they'd make sense to Just About Anyone who has submitted an
insurance-claim.
>I used
>to refer to these cases as the 'one legged black lesbian dwarves' (I was
>young and irreverent; nowadays I would drop the 'black'... It is really OK
>to insult disabled, gay, and especially, dwarves, in one sentence, but
>coloured people have definitely had enough...I'm not one to put the boot in
>when people are down... )
Not even in your own mouth? (Sorry... cheap shot but I couldn't resist.)
>This is one of the best examples I have ever seen
>of the kind of exceptions that test program development. Managers want
>simple rules; the real world has the above.
Linking to the Management thread? I'd say 'No... Managers (and users) do
not want simple rules, they want complex rules implemented exactly as they
intended no matter how simplistically they were stated. (see 'DWIM
command (absence thereof)')
>
>Well done, Doc!
See above about 'easily impressed'... but thanks, anyhow.
>
>
>No. It might be useful to keep in mind the basic tenets of Boolean
>simplification and reduce it to a few lines of greenbar... Or think about
>alternatives like EVALUATE...
Eh? The code to deal with this was written, tested and has been running
since the shop upgraded to a System/370; it Ain't Broke... and besides,
whose budget is going to be used for it? (back to Management)
DD
| |
| Larry Kahm 2005-09-16, 6:55 pm |
| Interesting discourse you've got started here.
While having breakfast this morning, I read about a product called
BluePhoenix (www.bphx.com). Not only does it work with COBOL, but it works
several other "legacy" languages and processes as well.
Should an application live on the mainframe, or should it be distributed?
Hmmm. I'd rather see it on a z/OS platform - even if the box is partitioned
out to Linux. I have witnessed too many server farms grow as an
applications group's reach has exceed it's grasp [ Oh yes, of >course< we
need a new stand-alone QA environment - and the 16 boxes to support it.... ]
Larry Kahm
Heliotropic Systems, Inc.
"jce" <defaultuser@hotmail.com> wrote in message
news:sLPVe.68865$p_1.47526@tornado.tampabay.rr.com...
>
> I've been thinking about the modernization of COBOL applications running
> on a mainframe environment so I decided to work on a rambling set of
> questions.
>
> Seems to me that there is growing move to "enable" mainframe functions
> with the littlest effort possible. I've seen the obvious solutions that
> are move the application to a Unix flavor...or port some portion to .NET
> framework, however, I was thinking more of the case where the existing
> function is appropriate and what was needed was an extension out into the
> new world. I am looking at the old application branching out as well as
> how new requirements can be solutioned in an existing environment using
> new tooling/design patterns.
>
> For the existing case. If you can imagine - we have a module that updates
> a customer from some green screen. I would want to enable the update
> function as a callable service. All authorization and authentication
> issues aside - the desire would be to have a module that can be called by
> "either" the CICS transaction or via, say, a SOAP service request.
>
> I don't see immediately how the architecture of a typical COBOL
> application would manage to accomplish this easily. For existing
> function, it seems that there is a multi phase approach that is required -
> the extraction of business rules that define the operation (what is needed
> to update a customer), the extraction of the logic rules (who and how is
> this allowed) and the creation of the presentation of the rules. Finally,
> there is the communication of the request to the actual transaction. For
> the new functions, it would be a much easier as it would be a case of just
> designing the modules with those business rules truly externalized in the
> first place.
>
> Would it seem more appropriate that the a new calling module be "non CICS"
> and call the CICS module...and leaving the CICS green screen transactions
> as just with the function externalized...or does it make more sense to
> completely decouple the CICS from the act of updating the customer
> account? Can CICS call a non CICS program now that I think about it..?
> *It's been a while ;-) *
>
> In my mind, it makes more sense to remove the CICS subsystem from the
> equation - but then I'm left with what is the best option to implement the
> transaction based activities...should I have a daemon running unders USS
> on z/OS or some other method of application triggering....? CICS has been
> updated recently to be pretty flexible in terms of some web enablement but
> I just don't like the idea of it. Is that *dumb* of me?
>
> Should I look at migrating or using a z/Linux LPAR as the front door?
> Seems to bring into play a lot of uneccessary networking - I don't believe
> that there is a communication channel supported...
>
> I'm also looking at the same ideas for non CICS based items that are today
> Batch based but have some scope for function use. The same question
> exists here...is there a standard transaction processor to use ?
>
> Anyone have any good resources? Anything on creating mainframe web
> services framework - which, whilst not exactly what I'm looking at, would
> give me some good pointers. Is there a decent example of how to setup
> portals for new functions...so for example, creating a portal so that an
> operations team could look at the current system status, or help desk look
> at customer configurations..etc..or setting up LDAP for authorizations, or
> UDDI registry, etc etc?
>
> To reiterate - I am not looking to move to Unix/Windows flavor platform
> (except if it can be resident on a mainframe). If you believe the
> Windows/Unix is the only "real" method to do this type of work..I'd be
> interested to know why?
>
> I think ultimately, I'd be really interested in something that was like
> the http://www.droplets.com/ which seems to be a pretty neat deployment
> method for mainframe activity :-)
>
> My final question - if I may be so bold - is that reading online I see a
> lot of the function that is being enabled is simple presentation layer
> type items (so registering for a plane seat on the web versus on a green
> screen) or access to people's tax records.....does anyone know of a real
> example of a mainframe application being enabled to provide some function
> that could not be implemented using some Host-On-Demand, Java 3270
> emulator ? In other words, any true b2b type activity ?
>
> This last question I didn't actually do any research yet, so I will
> probably go find some of those white paper customer success stories...so
> unless it is off the top of your head don't worry too much :-)
>
> I will read this again tomorrow to see if it still makes sense...and make
> updates if necessary....
>
> MANY thanks in advance...
>
> JCE
>
>
>
>
>
| |
| Pete Dashwood 2005-09-16, 6:55 pm |
|
<docdwarf@panix.com> wrote in message news:dgbn4t$guv$1@reader1.panix.com...
> In article <3os7emF78ubjU1@individual.net>,
> Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
> [snip]
>
>
> Pfoo... you'se jes' easily impressed.
>
>
> 'Nonsense'? That might be applied to 'true arcana', such as certain areas
> of accounting designed for Special Interests (I recall, vaguely, certain
> oil-revenue procedures that were valid only in the states of Oklahoma,
> Arkansas and Texas (named OAT for that reason) but I chose those examples
> because they'd make sense to Just About Anyone who has submitted an
> insurance-claim.
>
I was using 'nonsense' in the non-literal sense (which is often employed in
the U.K.) to represent anything that is a tiresome exception to some
established rule. I agree that your examples are literally far from
nonsensical.
You really are too literal, Doc... :-)
>
> Not even in your own mouth? (Sorry... cheap shot but I couldn't resist.)
>
I would expect nothing less than a low blow from a dwarf...
>
> Linking to the Management thread? I'd say 'No... Managers (and users) do
> not want simple rules, they want complex rules implemented exactly as they
> intended no matter how simplistically they were stated. (see 'DWIM
> command (absence thereof)')
Then we have to disagree. My experience is that most people prefer
non-complexity and that is what often leads to oversimplification and
consequent failure in systems...
As for DWIM... I remember reading an internal tehnical paper many years ago
(around 30, actually) when I was working for CDC, which claimed that the
company's tech researchers had succeeded in fabricating memory from tachyon
particles. (Tachyons, for those without an affinity for Physical Science,
are rmarkable because they actually move backwards in time; popping into
existence when they are extremely old, gradually getting younger and
younger, until finally popping out again...) The tachyon memory, it was
claimed, would revolutionise the computer industry, because it meant that a
computer so equipped would know the answer to your question before you had
asked it...
>
>
> See above about 'easily impressed'... but thanks, anyhow.
>
>
> Eh? The code to deal with this was written, tested and has been running
> since the shop upgraded to a System/370; it Ain't Broke... and besides,
> whose budget is going to be used for it? (back to Management)
The same budget that has someone permanently on call because it keeps
failing in the said 'IF'... In the long run, surgery is cheaper than many
packets of band aids...
And besides, there is much more job satisfaction in reducing four pages to
15 lines or so, so people will find the time, whether it is budgeted or not.
(It's the sort of thing I would have once taken home at the w end to amuse
myself with instead of the Sunday crossword. In fact, I seem to remember
some years ago Eileen (Yukon Mama) posting such an example and I did
simplify it instead of doing a cryptic crossword...
http://groups.google.co.nz/group/co...bf2cc8f052c4ed3
Check entry 21 from 'anonymous' in the thread.
Pete.
| |
| James Johnson 2005-09-17, 3:58 am |
| On Sat, 17 Sep 2005 05:08:34 +1200, "Pete Dashwood" <dashwood@enternet.co.nz>
wrote:
>
>
><docdwarf@panix.com> wrote in message news:dgbn4t$guv$1@reader1.panix.com...
>I was using 'nonsense' in the non-literal sense (which is often employed in
>the U.K.) to represent anything that is a tiresome exception to some
>established rule. I agree that your examples are literally far from
>nonsensical.
>
>You really are too literal, Doc... :-)
>
>I would expect nothing less than a low blow from a dwarf...
>
>
>Then we have to disagree. My experience is that most people prefer
>non-complexity and that is what often leads to oversimplification and
>consequent failure in systems...
>
>As for DWIM... I remember reading an internal tehnical paper many years ago
>(around 30, actually) when I was working for CDC, which claimed that the
>company's tech researchers had succeeded in fabricating memory from tachyon
>particles. (Tachyons, for those without an affinity for Physical Science,
>are rmarkable because they actually move backwards in time; popping into
>existence when they are extremely old, gradually getting younger and
>younger, until finally popping out again...) The tachyon memory, it was
>claimed, would revolutionise the computer industry, because it meant that a
>computer so equipped would know the answer to your question before you had
>asked it...
>
>The same budget that has someone permanently on call because it keeps
>failing in the said 'IF'... In the long run, surgery is cheaper than many
>packets of band aids...
>
When I was a beginning programmer I was working on such a problem and came up
with a solution to fix the problem and incidentally reduce those 4 pages to 1/4
of a page of code. In the tech review meeting my work leader tore my head off
about my solution and directed me to just "bandaid" it. Embarrassed and hurt I
later found that she had been the original coder of that 4 page IF statement.
Man is not a rational animal. We just pretend to be sometimes.
JJ
>And besides, there is much more job satisfaction in reducing four pages to
>15 lines or so, so people will find the time, whether it is budgeted or not.
>(It's the sort of thing I would have once taken home at the wend to amuse
>myself with instead of the Sunday crossword. In fact, I seem to remember
>some years ago Eileen (Yukon Mama) posting such an example and I did
>simplify it instead of doing a cryptic crossword...
>
>http://groups.google.co.nz/group/co...bf2cc8f052c4ed3
>
>Check entry 21 from 'anonymous' in the thread.
>
>Pete.
>
>
James Johnson
remove the "dot" from after sail in email address to reply
| |
| Alistair 2005-09-17, 3:58 am |
|
Pete Dashwood wrote:
I'm not one to put the boot
> I would expect nothing less than a low blow from a dwarf...
>
That one was beneath you, Peter.
| |
|
| In article <7Nednex7Qcm5trHeRVn-2w@adelphia.com>,
John Culleton <john@wexfordpress.com> wrote:
>docdwarf@panix.com wrote:
[snip]
[snip]
[color=darkred]
>First you build the DLT, then you boil it down to its most economic size,
>and then you implement each rule with a complex IF such as
>IF A AND B AND C AND NOT D PERFORM X-SEQUENCE. This involves liberal use of
>condition names and switches of course. But all the logic fits on one or
>two lines.
Hmmmm... so the abovementioned situation might boil down to 'one or two
lines' like...
IF UTERINE-INFECTION-CLAIM AND POLICY-RIDER-EXISTS AND (POLICYHOLDER =
FEMALE OR PERSON-COVERED = FEMALE) AND (HYSTERECTOMY-NOT-PERFORMED OR
HYSTERECTOMY-DATE < UTERINE-INFECTION-TREATMENT-DATE) AND
(UTERINE-INFECTION-TREATMENT-DATE < POLICY-RIDER-EFFECTIVE-DATE)...
If I am correct then a difficulty might be found in directing the flow of
processing for 'sub-conditions', something you'd want to do if the first
two are true and the third false, the first three true and the fourth
false, etc... or am I missing something?
DD
| |
|
| In article <3p0cgsF7rmd4U1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
>
><docdwarf@panix.com> wrote in message news:dgbn4t$guv$1@reader1.panix.com...
>I was using 'nonsense' in the non-literal sense (which is often employed in
>the U.K.) to represent anything that is a tiresome exception to some
>established rule. I agree that your examples are literally far from
>nonsensical.
.... and in the case of insurance they were the established rules, as well.
>
>You really are too literal, Doc... :-)
I am not bigrammatic! Oh... not 'two literals', sorry.
[snip]
>
>Then we have to disagree. My experience is that most people prefer
>non-complexity and that is what often leads to oversimplification and
>consequent failure in systems...
It is a wonderful world which has such varied experiences in it, aye.
>
>As for DWIM... I remember reading an internal tehnical paper many years ago
>(around 30, actually) when I was working for CDC, which claimed that the
>company's tech researchers had succeeded in fabricating memory from tachyon
>particles. (Tachyons, for those without an affinity for Physical Science,
>are rmarkable because they actually move backwards in time; popping into
>existence when they are extremely old, gradually getting younger and
>younger, until finally popping out again...) The tachyon memory, it was
>claimed, would revolutionise the computer industry, because it meant that a
>computer so equipped would know the answer to your question before you had
>asked it...
This seems to be a variant of Asimov's 'thiotimoline', a compound so
soluble that it dissolves in water before the water is added.
[snip]
>
>The same budget that has someone permanently on call because it keeps
>failing in the said 'IF'... In the long run, surgery is cheaper than many
>packets of band aids...
I have never, Mr Dashwood, heard of a system so well-written that the
on-call positions were disbanded; management seems to have learned that
there's *always* something to go wrong, someplace, and if someone else
isn't on call then the manager gets called.
>
>And besides, there is much more job satisfaction in reducing four pages to
>15 lines or so, so people will find the time, whether it is budgeted or not.
Of course this is so... and I am the King of England, you may call me Your
Majesty. With all due respect, Mr Dashwood, if your assertion were true
then there would be no more four-and-a-half page IFs left over from the
System/370 coversion... and a few are still out there, I believe.
>(It's the sort of thing I would have once taken home at the wend to amuse
>myself with instead of the Sunday crossword. In fact, I seem to remember
>some years ago Eileen (Yukon Mama) posting such an example and I did
>simplify it instead of doing a cryptic crossword...
Using yourself as a comparative, Mr Dashwood? That way can lead to
disappointment.
DD
| |
|
| In article <1126899943.812325.14520@g49g2000cwa.googlegroups.com>,
Alistair <alistair@ld50macca.demon.co.uk> wrote:
>
>Pete Dashwood wrote:
>I'm not one to put the boot
>That one was beneath you, Peter.
Still... no need to get short with him over it.
(come to think of it... hard to get short with him *under* it, as well)
DD
| |
| John Culleton 2005-09-17, 9:55 pm |
| docdwarf@panix.com wrote:
> In article <sLPVe.68865$p_1.47526@tornado.tampabay.rr.com>,
> jce <defaultuser@hotmail.com> wrote:
>
> [snip]
>
>
> Where do the customer data 'live' (mainframe/elsewhere) and in what format
> (flat file/VSAM/database)?
>
>
> Let me sing this back to see if I'm learning the song.
>
> 1) Initiate customer update request.
> A) Does the initiating user have any customer update authority?
> i) No - send 'not you, buddy' notice and terminate transaction
> ii) Yes - CONTINUE.
>
> 2) Prepare to and accept user input to identify customer for update.
>
> 3) Validate input
> A) is input in valid format (all letters/numbers in the right places)?
> i) No - send 'bad format' message and GO TO 2)
> ii) Yes - see if customer exists in system
> a) No - send 'not here - re-enter or use A)dd function'
> and GO TO 2)
> b) Yes - does user have auth to update this class of customer?
> 1) No - send 'lowly peon' msg and GO TO 2
> 2) Yes - CONTINUE
>
> 4) Prepare to and accept user input to modify identified customer.
>
> 5) Validate input
> A) is input in valid format (codes entered are valid update types)?
> i) No - send bad code(s) msg and GO TO 4)
> ii) Yes - are codes valid for this kind of customer?
> a) No - send 'not for this one, you don't' msg and GO TO 4)
> b) Yes - send 'are you sure?' msg and get response
> 1) is response valid?
> A) No - send 'Y/N, please?' msg and GO TO 5.A.ii.b
> ... etc.
>
> Now... the question of 'the extraction of business rules' and 'the
> extraction of logic rules' is where it gets sticky. Take the example of
> an insurance-claims system. It seems logical and businesslike to allow
> for a claim to be made for the treatment of uterine infections... BUT NOT
> if the policy's group doesn't have a rider to cover such treatments...
>
> ... then it's OK... BUT NOT IF the claimant is a male...
>
> ... BUT IF the claimant is a male who has a female relative who is also
> covered by the policy then it's OK...
>
> ... BUT NOT IF the claimant is a male who has a female relative who is
> also covered who has had a hysterectomy...
>
> ... BUT IF the claimant is a male who has a female relative who is also
> covered who has had a hysterectomy AND the date of the hysterectomy is
> greater than the date of the uterine infection treatment (someone left the
> claim in a drawer for six months) then it's OK...
>
> ... BUT NOT IF the claimant is a male who has a female relative who is
> also covered who has had a hysterectomy AND the date of the hysterectomy
> is greater than the date of the uterine infection treatment (someone left
> the claim in a drawer for six months) AND the date of the uterine
> infection treatment precedes the effective date for policy's rider which
> covers such treatments...
>
> ... et and cetera. I think I'll stop now.
Let me throw in a few unpopular ideas.
1. The Murach/Noll combine in one of their books ( I forget which)
recommended against CICS decades ago. Among other things it isn't COBOL,
and it is slow to code. So the first few things to consider are separating
the user interface part of the app from the logic part and then working
toward a different user interface as a callable function. There are several
imperfect possibilities, such as html, Tcl/Tk and the somewhat dubious
screen section in (more or less) standard COBOL. But the interface should
be portable.
2. The EVALUATE verb is only slightly less obnoxious than its immediate
parent, the extraordinarily convoluted nested IF. I use neither. For one
thing both violate the COBOL principles that any action is terminated by a
period, and any action takes one or at most two lines of code. The simple
"test this field for a value and then proceed accordingly" situation is
best solved by a string of equally simple if statements. Since the field
can only hold one value at a time there is no need for complicated and
buggy ELSE IF nesting. And the professor types would have you indenting the
code clear off the page, all in the name of readability. Nonsense.
Now what about the dwarf minority lesbian or her cousin the red-haired
left-handed Eskimo shortstop? Well there are two approaches I might favor.
The first might be called the flowchart approach. You test for a condition
and then perform a lower level module that tests for another condition etc.
But I prefer the Decision Logic Table approach for this kind of complexity.
First you build the DLT, then you boil it down to its most economic size,
and then you implement each rule with a complex IF such as
IF A AND B AND C AND NOT D PERFORM X-SEQUENCE. This involves liberal use of
condition names and switches of course. But all the logic fits on one or
two lines. And the logic behind the logic is analyzed and tested beforehand
during the DLT analysis. This is not the swiftest way home, but it is clear
and understandable even six months after you wrote it. And you can show the
DLT to the consumer and ask the the Peggy Lee torch song question: "is that
all there is?" Chances are excellent that there are at least three other
special situations that said consumer forgot to mention.
Many decades ago, before Murach, before even Dykstra, the Navy Programming
Languages Division came up with a Decision Logic Table Translator, written
in COBOL of course, which would take a DLT embedded as comment statements
in a source program and translate it to executable code. There were tons of
GO TOs generated. I still have the code somewhere.
Those who have never heard of a DLT are banished to the minor league. Those
who never heard of the Navy Programming Languages Division are remanded to
Java-Script or Visual Basic or whatever.
Enough, I have to clean up the puppy pen and do some real work on the
computer. Sometimes it is difficult to distinguish between the two tasks.
--
John Culleton CDP, RBP
Retired Old Fart
| |
| John Culleton 2005-09-17, 9:55 pm |
| docdwarf@panix.com wrote:
> In article <7Nednex7Qcm5trHeRVn-2w@adelphia.com>,
> John Culleton <john@wexfordpress.com> wrote:
>
> [snip]
>
>
> [snip]
>
>
> Hmmmm... so the abovementioned situation might boil down to 'one or two
> lines' like...
>
> IF UTERINE-INFECTION-CLAIM AND POLICY-RIDER-EXISTS AND (POLICYHOLDER =
> FEMALE OR PERSON-COVERED = FEMALE) AND (HYSTERECTOMY-NOT-PERFORMED OR
> HYSTERECTOMY-DATE < UTERINE-INFECTION-TREATMENT-DATE) AND
> (UTERINE-INFECTION-TREATMENT-DATE < POLICY-RIDER-EFFECTIVE-DATE)...
>
> If I am correct then a difficulty might be found in directing the flow of
> processing for 'sub-conditions', something you'd want to do if the first
> two are true and the third false, the first three true and the fourth
> false, etc... or am I missing something?
>
> DD
Grr. Now I have to do some work, which I hate. I much prefer to BS my way
through life. I will put together the DLT as a graphic (it is impossible to
line up columns in an email) and post it somewhere.
As for subconditions, the action of a rule in a DLT can be to process
another DLT. But that gets us back into flowchart logic. The science of
DLT is explained in books. The art consists of knowing how complex a DLT do
you allow before breaking it off and creating another.
--
John Culleton
Able Indexers and Typesetters
| |
| John Culleton 2005-09-17, 9:55 pm |
| John Culleton wrote:
> docdwarf@panix.com wrote:
>
> Grr. Now I have to do some work, which I hate. I much prefer to BS my way
> through life. I will put together the DLT as a graphic (it is impossible
> to line up columns in an email) and post it somewhere.
>
> As for subconditions, the action of a rule in a DLT can be to process
> another DLT. But that gets us back into flowchart logic. The science of
> DLT is explained in books. The art consists of knowing how complex a DLT
> do you allow before breaking it off and creating another.
My solution posted here:
http://wexfordpress.com/tex/dlt.pdf
Criticisms/corrections accepted with my usual grumpiness.
--
John Culleton
Able Indexers and Typesetters
| |
| Richard 2005-09-17, 9:55 pm |
|
John Culleton wrote:
> But I prefer the Decision Logic Table approach for this kind of complexity.
> First you build the DLT, then you boil it down to its most economic size,
> and then you implement each rule with a complex IF ...
There were several decision table preprocessors available many years
ago, I still have a couple of books on the subject. They were a good
method of implementing a design by taking specs that were created as
decision tables and simply dropping these into the source code and
letting the preprocessor tell you what was wrong.
The EVALUATE was designed to emulate and replace decision tables but
got it 'sideways'. Also a proper preprocessor would evaluate all the
conditions specified and tell you what combinations were not included.
I don't know of any DT preprocessors that are available today.
| |
| Rick Smith 2005-09-17, 9:55 pm |
|
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1126984717.455391.125640@f14g2000cwb.googlegroups.com...
[snip]
> I don't know of any DT preprocessors that are available today.
Then let me inform you that though the full product may
not be available today; "A free preview release of
LogicGem 3.0 is available for download. Please note
that the preview will expire on October 1, 2005. "
< http://www.catalyst.com/products/logicgem/ >
"LogicGem is a Decision Table or Logic Table processor.
You populate a table with a set of conditions and
corresponding actions that can apply to those conditions
and LogicGem will complete the table for you by finding
any missing rules and automatically removing all of the
redundant rules. It is the only method whereby you are
assured of mathematical perfection for your logic. Once
the logic has been perfected, LogicGem will then translate
the completed table into source code for the language of
your choice, including English for documentation purposes."
However, "language of choice" does not include COBOL.
From < http://www.catalyst.com/products/logicgem/release.html >,
"Computer languages supported are BASIC, C, C++,
Fortran, FoxPro, Java, Pascal, PowerBuilder, SAS,
Visual Basic, Visual Basic.NET, Visual C#.NET, and
XBase.
I reviewed LogicGem 2.0 (a DOS product) about ten years
ago; but never used that product.
| |
|
| In article <7sidnZ0ir9EJx7HeRVn-jw@adelphia.com>,
John Culleton <john@wexfordpress.com> wrote:
>docdwarf@panix.com wrote:
>
[snip]
[color=darkred]
>Grr. Now I have to do some work, which I hate. I much prefer to BS my way
>through life.
Oh, I *cannot resist...
.... looking to move up to Management, eh?
>I will put together the DLT as a graphic (it is impossible to
>line up columns in an email) and post it somewhere.
That would be of interest, I'd say... and those 'all ya gotta do is'
solutions have a tendency, in my experience, to require others to do More
Work.
>
>As for subconditions, the action of a rule in a DLT can be to process
>another DLT. But that gets us back into flowchart logic.
Funny how those Hoary Ancient Practises keep rearing their ugly heads,
aye.
>The science of
>DLT is explained in books. The art consists of knowing how complex a DLT do
>you allow before breaking it off and creating another.
If my clients wanted artists they'd hire (insert name of
painter/sculptor/worker in other medium here). They want code so they
call for (echo chamber on) CAAAPPPPPTTTAAAIIIIINNNNNNN... COBOL... OBOl...
OBol... Obol.
DD
| |
| John Culleton 2005-09-17, 9:55 pm |
| docdwarf@panix.com wrote:
> In article <mL-dnSc-y4sR_rHeRVn-vA@adelphia.com>,
> John Culleton <john@wexfordpress.com> wrote:
>
> [snip]
>
>
> Looks like my guess was close... but as my first programming instructor
> used to say, 'Examples in books are not always compiled.'
>
> PERFORM PAY CLAIM?
>
> DD
(grump)
So you never forgot a hyphen?
(end grump)
Anyhow did you like/dislike the ultimate result (with error corrected)?
--
John Culleton
Able Indexers and Typesetters
| |
| William M. Klein 2005-09-17, 9:55 pm |
| Personally, I'll take a COBOL EVALUATE statement (or nested EVALUATEs if
needed) every time - when trying to implement a complex decision table.
However, I do accept this as a "style" issue and probably based on what COBOL
syntax (and semantics) one is already (most) familiar with.
--
Bill Klein
wmklein <at> ix.netcom.com
"John Culleton" <john@wexfordpress.com> wrote in message
news:XaudnZ3o9cJkPbHeRVn-pA@adelphia.com...
> docdwarf@panix.com wrote:
>
> (grump)
> So you never forgot a hyphen?
> (end grump)
> Anyhow did you like/dislike the ultimate result (with error corrected)?
> --
> John Culleton
> Able Indexers and Typesetters
| |
| Richard 2005-09-18, 6:55 pm |
| > http://wexfordpress.com/tex/dlt.pdf
This can be mechanistically converted to an EVALUATE:
<code>
IDENTIFICATION DIVISION.
PROGRAM-ID. dt.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 Claimant-Sex PIC X.
88 Claimant-Female VALUE "F".
01 Policy-Status PIC X.
88 Policy-Rider VALUE "Y".
01 Womb-Status PIC X.
88 Hysterectomy VALUE "Y".
01 Hys-Date PIC 9(8).
01 Inf-Date PIC 9(8).
01 Rider-Date PIC 9(8).
PROCEDURE DIVISION.
DTTest.
EVALUATE Claimant-Female
ALSO Policy-Rider
ALSO Inf-Date > Rider-Date
ALSO Hysterectomy
ALSO Hys-Date > Inf-Date
WHEN TRUE
ALSO TRUE
ALSO TRUE
ALSO TRUE
ALSO TRUE
PERFORM Pay-Claim
WHEN TRUE
ALSO TRUE
ALSO TRUE
ALSO FALSE
ALSO ANY
PERFORM Pay-Claim
WHEN OTHER
PERFORM Deny-Claim
END-EVALUATE
STOP RUN.
Pay-Claim.
Deny-Claim.
END PROGRAM dt.
</code>
| |
| Pete Dashwood 2005-09-18, 6:55 pm |
| Sorry, John, I didn't like it because of the duplication of code...
IF CLAIMANT-FEMALE AND POLICY-RIDER AND INFECTION-DATE >RIDER-DATE AND
HYSTERECTOMY AND HYS-DATE > INFECTION-DATE
PERFORM PAY CLAIM
ELSE
IF CLAIMANT-FEMALE AND POLICY-RIDER AND INFECTION-DATE > RIDER-DATE AND
NO-HYSTERECTOMY
PERFORM PAY CLAIM
ELSE
PERFORM DENY-CLAIM.
Applying Boolean simplification, becomes...
IF CLAIMANT-FEMALE AND POLICY-RIDER AND INFECTION-DATE > RIDER-DATE
IF (NOT HYSTERECTOMY OR HYS-DATE > INFECTION-DATE)
PERFORM PAY-CLAIM
ELSE
PERFORM DENY-CLAIM
END-IF
END-IF
I agree with Bill, it comes down to style.
Pete.
"John Culleton" <john@wexfordpress.com> wrote in message
news:XaudnZ3o9cJkPbHeRVn-pA@adelphia.com...
> docdwarf@panix.com wrote:
>
> (grump)
> So you never forgot a hyphen?
> (end grump)
> Anyhow did you like/dislike the ultimate result (with error corrected)?
> --
No, it doesn't get my vote. I believe the less code there is the less chance
for error there is, and it is easier to read and absorb small constructs
rather than long ones. Besides, knowing I did something twice when there was
really no need to, just makes me wake up sweating... :-)
Pete.
| |
| Binyamin Dissen 2005-09-18, 6:55 pm |
| On Sun, 18 Sep 2005 17:44:39 +1200 "Pete Dashwood" <dashwood@enternet.co.nz>
wrote:
:>Sorry, John, I didn't like it because of the duplication of code...
:>IF CLAIMANT-FEMALE AND POLICY-RIDER AND INFECTION-DATE >RIDER-DATE AND
:>HYSTERECTOMY AND HYS-DATE > INFECTION-DATE
:>PERFORM PAY CLAIM
:>ELSE
:>IF CLAIMANT-FEMALE AND POLICY-RIDER AND INFECTION-DATE > RIDER-DATE AND
:>NO-HYSTERECTOMY
:>PERFORM PAY CLAIM
:>ELSE
:>PERFORM DENY-CLAIM.
:>Applying Boolean simplification, becomes...
:>IF CLAIMANT-FEMALE AND POLICY-RIDER AND INFECTION-DATE > RIDER-DATE
:> IF (NOT HYSTERECTOMY OR HYS-DATE > INFECTION-DATE)
:> PERFORM PAY-CLAIM
:> ELSE
:> PERFORM DENY-CLAIM
:> END-IF
:>END-IF
Not identical.
What if CLAIMANT-FEMALE is false?
Be careful when "simplifying" logic.
--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
| |
| Arnold Trembley 2005-09-18, 6:55 pm |
|
Pete Dashwood wrote:
> (snip)
> Sorry, John, I didn't like it because of the duplication of code...
>
> IF CLAIMANT-FEMALE AND POLICY-RIDER AND INFECTION-DATE >RIDER-DATE AND
> HYSTERECTOMY AND HYS-DATE > INFECTION-DATE
> PERFORM PAY CLAIM
> ELSE
> IF CLAIMANT-FEMALE AND POLICY-RIDER AND INFECTION-DATE > RIDER-DATE AND
> NO-HYSTERECTOMY
> PERFORM PAY CLAIM
> ELSE
> PERFORM DENY-CLAIM.
>
> Applying Boolean simplification, becomes...
>
> IF CLAIMANT-FEMALE AND POLICY-RIDER AND INFECTION-DATE > RIDER-DATE
> IF (NOT HYSTERECTOMY OR HYS-DATE > INFECTION-DATE)
> PERFORM PAY-CLAIM
> ELSE
> PERFORM DENY-CLAIM
> END-IF
> END-IF
>
> I agree with Bill, it comes down to style.
>
> Pete.
Err...Shouldn't that be more like this:
PROCESS-UTERINE-INFECTION.
IF CLAIMANT-FEMALE AND POLICY-RIDER AND INFECTION-DATE > RIDER-DATE
IF NOT HYSTERECTOMY
OR HYS-DATE > INFECTION-DATE
PERFORM PAY-CLAIM
ELSE
PERFORM DENY-CLAIM
END-IF
ELSE
PERFORM DENY-CLAIM <== the missing path...
END-IF
Splitting up the OR is my stylistic preference (not a quibble with
your excellent simplification), but it seems to me that if this logic
is to be restricted to processing a claim for uterine infection then
an ELSE path was omitted.
Of course, I could be wrong about that.
On the other hand, I thought Richard's EVALUATE statement was fairly
easy to understand. Perhaps if there were a Decision Table translator
for COBOL it would generate COBOL code that looked like that. At
least I hope so.
I have to admit I am very weak on Decision Tables. I don't remember
them being covered at all where I learned programming. It seems to me
that the descriptions of LEX and YACC that I have read sound like a
form of decision table processing generated from some rule
specifications.
As a side note, I heard an anecdote about a very large mainframe
financial application written in COBOL with an extremely complex
decision table. The decision table was so large that the developers
built a MicroFocus COBOL program to pre-process the decision table
rules and generate an optimized COBOL decision table as a code
fragment, which was then copied into the mainframe COBOL programs. It
drove the project manager crazy when he found out his mainframe
programs were partially written by PC programs.
With kindest regards,
--
http://arnold.trembley.home.att.net/
| |
| Pete Dashwood 2005-09-18, 6:55 pm |
|
"Binyamin Dissen" <postingid@dissensoftware.com> wrote in message
news:8q2qi15mlfghnafvhinqp2fl4i4rt5ghb1@
4ax.com...
> On Sun, 18 Sep 2005 17:44:39 +1200 "Pete Dashwood"
> <dashwood@enternet.co.nz>
> wrote:
>
> :>Sorry, John, I didn't like it because of the duplication of code...
>
> :>IF CLAIMANT-FEMALE AND POLICY-RIDER AND INFECTION-DATE >RIDER-DATE AND
> :>HYSTERECTOMY AND HYS-DATE > INFECTION-DATE
> :>PERFORM PAY CLAIM
> :>ELSE
> :>IF CLAIMANT-FEMALE AND POLICY-RIDER AND INFECTION-DATE > RIDER-DATE AND
> :>NO-HYSTERECTOMY
> :>PERFORM PAY CLAIM
> :>ELSE
> :>PERFORM DENY-CLAIM.
>
> :>Applying Boolean simplification, becomes...
>
> :>IF CLAIMANT-FEMALE AND POLICY-RIDER AND INFECTION-DATE > RIDER-DATE
> :> IF (NOT HYSTERECTOMY OR HYS-DATE > INFECTION-DATE)
> :> PERFORM PAY-CLAIM
> :> ELSE
> :> PERFORM DENY-CLAIM
> :> END-IF
> :>END-IF
>
> Not identical.
>
> What if CLAIMANT-FEMALE is false?
The claim will not be paid. However, I didn't specifically deny it because
of a mistake I made when hurriedly 'translating' into symbolic notation...
>
> Be careful when "simplifying" logic.
Sound advice. I usually am, but slipped up on this occasion. Thanks for
spotting it.
I hasten to add that in a 'real' environent it would have failed the testing
and I would then have fixed it... (well, that's my story and I'm sticking to
it... :-))
Pete.
| |
|
| docdwarf@panix.com wrote:
> In article <4jkgi19m5eqpsa2b1plqtmth0ctrlro9m2@4ax.com>,
> Jeff Lanam <jeff-dot-lanam@hp-dot-com-not.net> wrote:
>
>
>
> Or maybe a drinking-establishment specialising in concoctions containing
> chartreuse.
So, basically any bar on St. Patty's Day, right?
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
|
| In article <9c36a$432f6b7e$45491c57$18163@KNOLOGY.NET>,
LX-i <lxi0007@netscape.net> wrote:
>docdwarf@panix.com wrote:
>
>So, basically any bar on St. Patty's Day, right?
Perhaps things have changed since I ceased frequenting such
establishments... but what the advertisers used to call 'The Day For the
Wearin' o' the Green' was not, as I recall it, one for sales of
http://www.chartreuse.fr/pa_green&yellow_uk.htm.
DD
| |
| Joe Zitzelberger 2005-09-20, 6:55 pm |
| In article <7Nednex7Qcm5trHeRVn-2w@adelphia.com>,
John Culleton <john@wexfordpress.com> wrote:
> Let me throw in a few unpopular ideas.
> 1. The Murach/Noll combine in one of their books ( I forget which)
> recommended against CICS decades ago. Among other things it isn't COBOL,
> and it is slow to code. So the first few things to consider are separating
> the user interface part of the app from the logic part and then working
> toward a different user interface as a callable function. There are several
> imperfect possibilities, such as html, Tcl/Tk and the somewhat dubious
> screen section in (more or less) standard COBOL. But the interface should
> be portable.
I'm not conversant with that text, but any opinion of CICS based on
decades old issues is going to miss many great features introduced in
the past two decades. IBM has introduced numerous features in the last
two decades that make CICS a great platform for supporting any
application.
I'm not sure what 'it isn't COBOL' means -- CICS has fully supported
Cobol for a very long time. It certainly can be Cobol. Especially if
one has no attached terminal to muck things up, it can be pure Cobol.
> 2. The EVALUATE verb is only slightly less obnoxious than its immediate
> parent, the extraordinarily convoluted nested IF. I use neither. For one
> thing both violate the COBOL principles that any action is terminated by a
> period, and any action takes one or at most two lines of code. The simple
> "test this field for a value and then proceed accordingly" situation is
> best solved by a string of equally simple if statements. Since the field
> can only hold one value at a time there is no need for complicated and
> buggy ELSE IF nesting. And the professor types would have you indenting the
> code clear off the page, all in the name of readability. Nonsense.
There is a Cobol principle that requires all actions be terminated by a
period? Isn't that what explicit scope terminators were supposed to fix
when they were introduced several decades ago.
And those professor types that would have you 'indent the code clear off
the page' have a sound scientific basis for doing so. Studies have
shown very clearly that indentation to match logic improves reader
comprehension.
The optimum was 2 to 4 bytes indentation, with 6 to 8 offering no
benefit. The 'block' style offering a negative effect on comprehension.
Some will try and claim that it is "what you are used to", but it isn't.
It is just a function of the human brain and visual recognition tend to
work.
In a slightly related note:
There is a cute email chain letter circulating that claims to be from
the Yale Psychology Department -- it has no vowels and some other
letters have been removed from the interior of the words, yet it is
surprisingly readable. If I can find it I'll post it. It gives some
interesting insight into how the mind 'reads'.
| |
| Oliver Wong 2005-09-20, 6:55 pm |
| "Arnold Trembley" <arnold.trembley@worldnet.att.net> wrote in message
news:tk8Xe.267908$5N3.245937@bgtnsc05-news.ops.worldnet.att.net...
> As a side note, I heard an anecdote about a very large mainframe financial
> application written in COBOL with an extremely complex decision table.
> The decision table was so large that the developers built a MicroFocus
> COBOL program to pre-process the decision table rules and generate an
> optimized COBOL decision table as a code fragment, which was then copied
> into the mainframe COBOL programs. It drove the project manager crazy
> when he found out his mainframe programs were partially written by PC
> programs.
And yet the manager was not upset when he found out that his programmers
were only describing the algorithms to perform in some high level language,
while all the "real" work of transforming this into code you could actually
run was being done by the compiler?
Had I discovered this thread earlier, I was actually going to suggest,
as an alternate solution, to write a tool (perhaps a plugin to an IDE) that
would let you draw state diagrams
(http://en.wikipedia.org/wiki/State_diagram), and which would automatically
generate the COBOL code for you. These state diagrams would then BE the
source code (for that particular module of the application anyway), and
COBOL would be a lower level representation to it, just as machine code is a
lower level representation of COBOL code.
Writing programs which write programs which write programs which write
programs (and so on ad nauseum) is actually considered typical in the shop
I'm working at. You have to force yourself to *FORGET* the big picture, and
only concentrate on the task at hand, less you start suffering from vertigo.
- Oliver
| |
|
| In article <mL-dnSc-y4sR_rHeRVn-vA@adelphia.com>,
John Culleton <john@wexfordpress.com> wrote:
[snip]
>My solution posted here:
>
>http://wexfordpress.com/tex/dlt.pdf
Looks like my guess was close... but as my first programming instructor
used to say, 'Examples in books are not always compiled.'
PERFORM PAY CLAIM?
DD
| |
|
| In article <XaudnZ3o9cJkPbHeRVn-pA@adelphia.com>,
John Culleton <john@wexfordpress.com> wrote:
>docdwarf@panix.com wrote:
>
>(grump)
>So you never forgot a hyphen?
>(end grump)
Compilers... the close-to-original spell-checkers.
>Anyhow did you like/dislike the ultimate result (with error corrected)?
It seems to have produced results close to my guess, Mr Culleton... but
I've not seen the tool applied to a project of any scope so more than that
I cannot say. One swallow, summer making, that sor of thing.
DD
| |
| Pete Dashwood 2005-09-21, 6:55 pm |
| Ouch! Please replace the code I posted as follows:
I would actually go further if I was serious about this.... The real code I
would use would be something like...
01 CLAIM-FLAG PIC X VALUE SPACE.
88 PAYING-CLAIM VALUE '1'.
88 DENYING-CLAIM VALUE ZERO.
....
PROCESS-UTERINE-INFECTION-CLAIM.
SET DENYING-CLAIM TO TRUE
IF CLAIMANT-FEMALE AND POLICY-RIDER AND INFECTION-DATE > RIDER-DATE
IF (NOT HYSTERECTOMY)
OR
(HYS-DATE > INFECTION-DATE)
SET PAYING-CLAIM TO TRUE
END-IF
END-IF
(Any other processing that might be common between the Paying and Denying
process, or any other processing connected with this type of claim that
might be added later, and could override whether it is paid or
denied...)...then...
IF PAYING-CLAIM
PERFORM PAY-CLAIM
ELSE
PERFORM DENY-CLAIM
END-IF
(sigh...)
Pete.
| |
| Pete Dashwood 2005-09-21, 6:55 pm |
|
"Arnold Trembley" <arnold.trembley@worldnet.att.net> wrote in message
news:tk8Xe.267908$5N3.245937@bgtnsc05-news.ops.worldnet.att.net...
>
>
> Pete Dashwood wrote:
>
> Err...Shouldn't that be more like this:
>
> PROCESS-UTERINE-INFECTION.
>
> IF CLAIMANT-FEMALE AND POLICY-RIDER AND INFECTION-DATE > RIDER-DATE
> IF NOT HYSTERECTOMY
> OR HYS-DATE > INFECTION-DATE
> PERFORM PAY-CLAIM
> ELSE
> PERFORM DENY-CLAIM
> END-IF
> ELSE
> PERFORM DENY-CLAIM <== the missing path...
> END-IF
>
Yes.
(Hangs head, shuffles feet, mumbles apology... and refers back to Benyamin's
spotting of the same error...)
> Splitting up the OR is my stylistic preference (not a quibble with your
> excellent simplification), but it seems to me that if this logic is to be
> restricted to processing a claim for uterine infection then an ELSE path
> was omitted.
>
Yes, I agree. I would also normally put the OR on a second line. On this
occasion I was cutting and pasting John's code.
> Of course, I could be wrong about that.
>
No, you and Benyamin both spotted it correctly. I checked the symbolic
translation I did and found it immediately... I did do it quickly, but it's
no excuse... guess I'm getting old... :-)
I would actually go further if I was serious about this.... The real code I
would use would be something like...
01 CLAIM-FLAG PIC X VALUE SPACE.
88 PAYING-CLAIM VALUE '1'.
88 DENYING-CLAIM VALUE ZERO.
....
PROCESS-UTERINE-INFECTION-CLAIM.
SET DENY-CLAIM TO TRUE
IF CLAIMANT-FEMALE AND POLICY-RIDER AND INFECTION-DATE > RIDER-DATE
IF (NOT HYSTERECTOMY)
OR
(HYS-DATE > INFECTION-DATE)
SET PAY-CLAIM TO TRUE
END-IF
END-IF
(Any other processing that might be common between the Paying and Denying
process, or any other processing connected with this type of claim that
might be added later, and could override whether it is paid or
denied...)...then...
IF PAYING-CLAIM
PERFORM PAY-CLAIM
ELSE
PERFORM DENY-CLAIM
END-IF
> On the other hand, I thought Richard's EVALUATE statement was fairly easy
> to understand.
Yes, I liked that too.
> Perhaps if there were a Decision Table translator for COBOL it would
> generate COBOL code that looked like that. At least I hope so.
>
> I have to admit I am very weak on Decision Tables. I don't remember them
> being covered at all where I learned programming. It seems to me that the
> descriptions of LEX and YACC that I have read sound like a form of
> decision table processing generated from some rule specifications.
>
> As a side note, I heard an anecdote about a very large mainframe financial
> application written in COBOL with an extremely complex decision table.
> The decision table was so large that the developers built a MicroFocus
> COBOL program to pre-process the decision table rules and generate an
> optimized COBOL decision table as a code fragment, which was then copied
> into the mainframe COBOL programs. It drove the project manager crazy
> when he found out his mainframe programs were partially written by PC
> programs.
>
"The best tools for the job..."
Pete.
| |
| Richard 2005-09-23, 7:55 am |
| > I don't know of any DT preprocessors that are available today.
Here's one that I prepared earlier today:
IDENTIFICATION DIVISION.
PROGRAM-ID. dtprocess.
* Copyright Azonic Associates 2005
* 23 September 2005
* released under the Gnu Public License (GPL)
* this code may be used and modified as long
* as this copyright notice is included.
*
* The source program being processed may contain a number
* of decision tables. Each table must be laid out as:
*
* *>header rulehead
* copy line
* *>conditions rules
* *>section separator
* *>actions actionqualifiers
* *>terminator line
*
* Each line between the header and the terminator inclusive,
* except the copy line, must have an '*' in column 7
* and a '>' or space in column 8.
*
* Header:
*
* The Header starts a Decision Table and, starting with
* the asterisk in column 7 is:
*
* *>DECISION-TABLE name 1 2 ... E
*
* The name is documentary only and must start in column
* 24 and not contain any spaces.
*
* The remainder of the line will contain the rule numbers
* which are one or two digits except the last which is
* the 'else' rule and must be numbered as E.
*
* There must be at least one space between each rule
* number.
*
* copy line:
*
* The copy line specifies the output file for the decision
* table code. It must not be a comment line as it will be
* used to read the source file into the program:
*
* Temporary rule: the name must not contain a '.'.
*
* COPY "dtsourcecob".
*
* Condition Lines:
*
* Must have '*' in col 7 a condition starting in col 9.
* In the column under the rule number in the header the
* condition value should be set to 'Y', 'N' or '-' where:
*
* Y indicates the condition is to be true
* N indicates the condition is not to be true
* - indicates the condition is not tested
*
* Separator line
*
* Must have '*' in col 7 and at least 6 hyphens starting
* in column 9:
*
* *>-----------------------------
*
* Action Lines:
*
* Must have '*' in col 7 an imperitive statement starting
* in col 9.
* In the column under the rule number in the header the
* action value should be set to '*', or space where:
*
* * indicates the action is to be performed
* space indicates the action is not to be performed
*
* Terminator line
*
* Must have '*' in col 7 and 'END-TABLE' starting
* in column 9, the name is optional:
*
* *>END-TABLE name
*
* Limits:
*
* Rules: 50
* Conditions: 50
* Actions: 50
*
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SPECIAL-NAMES.
ARGUMENT-NUMBER IS Argument-Number
ARGUMENT-VALUE IS Argument-Value
| |
| Richard 2005-09-23, 6:55 pm |
| > I don't know of any DT preprocessors that are available today.
Test program for dtprocess:
IDENTIFICATION DIVISION.
PROGRAM-ID. dttest.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 Example-Sex PIC X.
88 Example-Male VALUE "M".
88 Example-Female VALUE "F".
88 Example-Unsexed VALUE x"00" THRU "E"
"G" THRU "L"
"N" THRU x"FF".
01 Example-Age PIC 999.
01 Example-Funds PIC S9(8)V99.
PROCEDURE DIVISION.
Decision-Test.
DISPLAY "Female 15 0.00"
MOVE "F" TO Example-Sex
MOVE 15 TO Example-Age
MOVE ZERO TO Example-Funds
PERFORM Example-DT
DISPLAY "Female 17 0.00"
MOVE "F" TO Example-Sex
MOVE 17 TO Example-Age
MOVE ZERO TO Example-Funds
PERFORM Example-DT
DISPLAY "Male 19 0.00"
MOVE "M" TO Example-Sex
MOVE 19 TO Example-Age
MOVE ZERO TO Example-Funds
PERFORM Example-DT
DISPLAY "Male 19 150.00"
MOVE "M" TO Example-Sex
MOVE 19 TO Example-Age
MOVE 150.00 TO Example-Funds
PERFORM Example-DT
DISPLAY "Male 22 0.00"
MOVE "M" TO Example-Sex
MOVE 22 TO Example-Age
MOVE ZERO TO Example-Funds
PERFORM Example-DT
STOP RUN
| |
| Richard 2005-09-23, 9:55 pm |
| > dtprocess
What the program does not do, and would be very useful if it did, is
analyse the rules. It should check for duplicates, for masked out
unreachable rules, and preferably ensure completeness with every
possible combination given in a rule (ie with the else rule redundant).
Ideas on how that might be done would be useful. 2 ** 50 is a big
number.
The program could also check for duplicate adjacent action blocks and
merge them. Another enhancement would be to cater for the action flags
specifying the order. Instead of simple '*' indicating an action to be
done the column could be given as numbers that will be used to sort the
actions for this rule.
| |
| Ira Baxter 2005-09-24, 6:55 pm |
| "Richard" <riplin@Azonic.co.nz> wrote in message
news:1127503035.875866.107300@o13g2000cwo.googlegroups.com...
>
> What the program does not do, and would be very useful if it did, is
> analyse the rules. It should check for duplicates, for masked out
> unreachable rules, and preferably ensure completeness with every
> possible combination given in a rule (ie with the else rule redundant).
> Ideas on how that might be done would be useful. 2 ** 50 is a big
> number.
One can often write a straightforward code generator to generating
working code from correct input for a specification language
with the simplicity of a finite statemachine.
It gets a lot harder if the tool has to diagnose syntax and as many semantic
errors as possible, if the input language is sophisticated (imagine
what happens if you allow decision tables inside decision tables
as a an example) or the result must be reasonably optimized.
In this case, one needs a compiler-like infrastructure,
to ensure strong parsing (thus good syntax error checking),
strong semantic analysis, and optimization technology
like compilers have. COBOL isn't particularly suited
for this.
The DMS Software Reengineering Toolkit is.
See http://www.semanticdesigns.com/Prod...DMSToolkit.html
The way we would solve this problem is to define a decision
table language (we have a nested finite-state automata
language which is a superset), and define analysis
and "source-to-source" transformation rules that map
the input language to the output language. These
rules essentially are "algebra for programs", and
say essenttialy "if you see this code fragment
(in some langauge), it is the same as that code fragment
in (the same or another) langauge". In this
case the languages would be DecisionTables
and COBOL respectively.
You can see what transformation rules look like at
www.semdesigns.com/Products/DMS/Pro...formation.html.
With such machinery, checking for duplicates can be
reliably accomplished; a BIG engine for finding
duplicate code is discussed at our web site under the
name "clone detection", but it contains exactly the
duplicate checking logic needed for this task.
In effect, it compares compiler-like data structures
representing the code fragments to see if they
are identical or similar (e.g., it doesn't compare
text strings).
Completeness checking (I assume you mean by this
that every input combination is covered) can
be handled by forming a boolen algebra expression
for each table row, and taking the disjunction of
all table rows as a symbolic booelan formula.
If that disjunctive formulat can be simplified to
"true" by applying boolean logic rules, then
all input cases are covered; if not, the complement
of the simplifed formula is a case not handled.
Such logic rules can be code directly as
transformations, and we do this pretty often with
DMS because lots of people want to work with and simplify
boolean formulas.
You'd probably also want to check for subsumption:
does one condition imply another? If so, there are
circumstances when both trigger, and the actions
might be inconsistent. If the actions aren't inconsistent,
then the subsumed one is redundant.
> The program could also check for duplicate adjacent action blocks and
> merge them.
That's clone detection again.
> Another enhancement would be to cater for the action flags
> specifying the order. Instead of simple '*' indicating an action to be
> done the column could be given as numbers that will be used to sort the
> actions for this rule.
When you add ordering to the rules, the checking
gets more complex. Just means you need the supporting
machinery even more :-}
I'm not suggesting everybody run out and buy DMS;
just letting people know that there are sophisticated
engines to enable custom, high-quality code generation
with good checking capabilities.
If your organization does a lot of this kind of thing,
well, DMS might be worth considering.
If your present table generator works, that should
be OK for the moment.
It might amuse folks to know that DMS contains a
number of little languages of its own (syntax, transformation
rules, ...) which are generators, and that we use DMS to generate
and enhance itself, and that it is about a 5 million line
system at this point. DMS wouldn't be possible without
itself :-}
--
Ira D. Baxter, Ph.D., CTO 512-250-1018
Semantic Designs, Inc. www.semdesigns.com
| |
| Richard 2005-09-24, 6:55 pm |
| > (imagine what happens if you allow decision tables inside
> decision tables as a an example)
That is unlikely as it is only necessary to PERFORM another.
> When you add ordering to the rules,
The rules are not to be reordered, evaluation must be done in the order
presented. The ordering was potentially of the actions:
*> PERFORM Allow-Entry 1 2
*> PERFORM Require-Payment 2 1
> With such machinery, checking for duplicates can be
> reliably accomplished;
The problem is identifying that these are the same:
*> condition 1 Y Y
*> condition 2 - Y
*> condition 3 N -
The number of possible combinations is 2 ** no-of-conditions. Each rule
will cover 2 ** number-of '-'.
One simple way to test for masking and completeness is to set up a
table of flags of size 2**conditions. Each rule would then calculate
the postions in the table that caters for and would check and set the
flags. This may be OK for numbers up to 20 or 25, which may be a
realistic limit in any case.
|
|
|
|
|