MVSFORUMS.com

[ravi.alpha]

I want to parse the below SQL code using Cobol program.

I have below SQL in a flat file and I want read the below SQL and put each column name into an array declared in COBOL similarly I want to put all host variable (: H: H) into another array declared in Cobol.

Once I populate these column names into array I want to compare each with respective host variable if it is

[dbzTHEdinosauer]

what is your goal?
since you have :H, I assume you are trying to parse DBRM's.
again, what is your goal?
having a null indicator is dependent upon either
the results of columnar/scalar functions and sub selects
or if the column is defined as nullable in the table/view declaration.

since the number of SELECT/INTO objects can vary, I would suggest using indexing or reference modification to extract your objects.
_________________
Dick Brenholtz
American living in Varel, Germany

[ravi.alpha]

The goal is to find out all the columns which are not using Null indicators.

I have list of columns which can allow nulls from Sysibm.syscolumns. I want to filter all the DBRMS to find out which all application are impacted.

I have all the DBRMS downloaded into one files and now I want to parse each select statement and put column name in one array and host variable in another array.

I am also thinking of using Index but not sure of the exact logic. If you know the best way pls suggest me and provide me the logic

[dbzTHEdinosauer]

The reason i suggested indexing/reference modification is that I wrote a COBOL DBRM parser using UNSTRING. Not knowing how many objects to allow for (each select has x number of INTO's), required a continual loop in the UNSTRING logic. was not a fast as indexing/ref mod.

I was reading all DBRM's which meant I had a mix of SELECTs/INSERTs/DECLARE Tables, CURSORS/DELETEs, FETCHs, .....

Instead of investing time writing something that will work, I would suggest:

you can identify the modules that need to 'fixed' by

1. ripping thru TABLE DECLAREs - searchfor NULL
2. x all the NOT NULL
3. use the IDX parm on the search to have the copybook/or module name on everyline
4. that will give you a list of TABLES
5. search the DBRMs for 'DECLARE TABLE <tablename> searchfor in batch allows you more than 1000 search items

That will be your module list. Then you can go back to the original SQL (module) and on a one by one basis modify the SQL. You will have to add logic in your module to handle null indictors anyway.

not an elegant solution but it is easier and faster to debug you searchfor logic than to write/debug a program that rips thru the DBRMs and compare to columns in syscolumns - which you will need to qualify each column with the table name.
_________________
Dick Brenholtz
American living in Varel, Germany

[ravi.alpha]

ripping thru TABLE DECLAREs - searchfor NULL
x all the NOT NULL
use the IDX parm on the search to have the copybook/or module name on everyline
that will give you a list of TABLES
search the DBRMs for 'DECLARE TABLE <tablename> searchfor in batch allows you more than 1000 search items

I am not very much clear on this approch, could you please explain me bit more.

[dbzTHEdinosauer]

use the facilities of Search for, ispf option 3.1?.
_________________
Dick Brenholtz
American living in Varel, Germany

[ravi.alpha]

Thanks Dick Brenholtz.

After all the try... I have decided to move on to REXX.