× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Ok, let me put it this way...

Can anyone guide me to a starting point for parsing/evaluating an expression?

For example, I think I may have rules defined something like: 
*THISB=@VALUE("ADDRDF",1,8,10,*B) which means the boolean value of the field 
being tested must equal the boolean value of the value in positions 8-10 of the 
1st ADDRDF parm card. The expression evaluates true if both are blank or both 
have a value.

But I have no clue where to start on building code to perform the evaluation 
and I don't want to get too far into defining this "language" before I can see 
how difficult it's going to be to parse. Anyone?

-----Original Message-----
From: Metz, Zak
Sent: Wednesday, October 30, 2002 12:17 PM
To: midrange-l@midrange.com
Subject: Describing parm card dependencies in a database


I don't know that this is the best place for this question, so please feel free 
to redirect me...

I have an idea that I'm trying to wrap my brain around.

Here's the situation. Our company creates software in COBOL that is 
cross-platform, and happens to run on the iSeries. The software is driven by 
"parm cards," 80-byte records, each with a distinct 6-byte name, with various 
uses for the remaining columns. Here are some actual parm cards:

Z5 OUT     163 C
Z4 OUT     168 C
CR OUT     172
CS OUT     141 20       161
SA OUT     071 70                                                      X
AP OUT                       X 071 35 X 106 35

I would like to find a way to describe the dependencies between various parm 
card positions (such as, if you have an X here on this card, you must have a 
value on this card in this position) in a database. The idea is that if all 
that information could be in a database, as well as descriptions of the parm 
card positions and the possible values, it would be possible to write a simple 
front end in any language. The biggest challenge I see is somehow describing 
the dependencies in a manner that is easy for any language to interpret.

My initial thought was to use Net.Data which I believe can resolve variable 
names and such after reading it from a table, so if all the information were 
present, it would just be a matter of "resolving" the code snippet stored in 
the database for the particular parm card being validated. But this isn't the 
ideal solution since other languages can't generally resolve such a thing 
unlike interpreted Net.Data, and the type of things I would need to do don't 
really come naturally to any existing language.

I don't know if anything exists that can help with this. I'm ready to dive into 
writing my own little language to define the dependencies, but was hoping 
someone could give what I'm trying to do a name and perhaps save me from 
reinventing the wheel. At this point I have not chosen a language for this, but 
am leaning toward server-side Java, but the important part to me is getting 
this information into a database where any language could be used to convert my 
psuedocode for interpretation of the dependency logic (which doesn't yet exist, 
of course).
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.