Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

How to use string value as data name????

Status
Not open for further replies.

Guest_imported

New member
Jan 1, 1970
0
Given...

05 FLD-A pic x(32) value 'FIELD-NAME-123'.

and...

FIELD-NAME-123 exists as a data element on a database.

How do I use the value of FLD-A to reference FIELD-NAME-123 on the database?
 
Hi Fly,

What's your environment, database, etc.?

Jack
 
To be more specific, I do not want to use 88 levels. Bottom line is there should be no direct reference to the data-name in the code. I just want to use the value of a field which contains the data name as a alphanumeric string as a data name in a move statement.
Is this possible? Any help appreciated.
 
I know that you can reference program names (like for a CALL statement) through a variable (i.e. during run time) because the compiler doesn't care about this; a called program name will be dynamically linked to your resulting executable (or object file).

But with field names, they have to be valid at compile time, so for example if one of your field names is the contents of another field that gets updated during runtime, the compiler would go crazy.

In essence, I don't think this is prossible. I would love, however, to be proven wrong. This would be a very neat thing to do! Good luck!
 
In SQL you would select a table where <table element> = &quot; &quot;.

You can also use Like.

You have to know how to use SQL in a COBOL program for that.

Maybe someone in here knows how to do that. If you do not like my post feel free to point out your opinion or my errors.
 
Thanks for the info everybody.

Slade, I'm running on mainframe and the database is DB2. I'm trying to keep future modifications to the code to a minimum (as new fields are needed). What we're doing is creating an XML datastream using a table of user defined field requirements. If I could put those requirements in a table, instead of imbedding them in code it would be easier to maintain.
 
Hi Fly,

You could probably use Dynamic SQL to reference the DB2 data name in an SQL statement. If you're not familiar w/Dynamic SQL it allows you to &quot;build&quot; SQL statements &quot;on the fly&quot;; that means you can use COBOL data names to build them.

The problem w/it is that the SQL stmts are interpreted & bound at exec time and this can cause performance probs. You'll also get to wrangle w/your tech guys, which is always fun.

In any event this is the only way you can do it w/mainframe COBOL/DB2. I think the PTB will tell you to pay the $2.

Regards, Jack.
 
Hi,
How about writing a cobol program that creates and compiles a new cobol program based on the table of data names you wish to access?
 
You're using DB2 on a mainframe environment.

I can suggest creating a cursor and then, in your Procedure Division, fetch all the values in your database for that particular field. As each record comes up on your cursor, load it into a COBOL working storage table. When you get done with the fetch, search the table for the value you want.

Or if you don't want this sort of tabling (but I think I read that you do), then when you want to select the value of FLD-A when it equals FIELD-NAME-123, then write in EXEC SQL and then your SQL 'Select FLD-A into :FLD-A when FLD-A = '[whatever actual value is currently in your variable 'FIELD-NAME-123]'.

Hope this helps, Nina Too
 
We haven't heard from flyboy in a while, but I think what he wants to do is execute an SQL stmt like: select fd-a into :ws-hold-fld from x where fld-a = ws-srch-arg, at one point in time, then months or yrs later change the EXEC PARM or a file to get the same pgm (w/o recompiling) to execute this SQL stmt:

select fd-b into :ws-hold-fld from x where fld-b = ws-srch-arg

With Dynamic SQL you can change the content of the same SQL stmt to look either way, that's what makes it dynamic. Personally, from what he stated of his intent, I don't think it's worth the effort or the performance hit.

Jack
 
Well, he said that he wanted to put the records (of user requirements) into a table. The best way to do this in DB2 is for, each time the program is run, create a cursor which gathers up all of the specific records that he wants.

After you create the cursor (in the data division), in the procedure division, you open the cursor and start fetching the records, one by one. As you fetch each record, you load it into a working storage table. This way, you get the most current records every time you run the program.

After you get to the end of the cursor, you close the cursor and then work with the records you have just fetched and loaded into your table.

As for maintenance, all you have to check are the parameters of the cursor you have created (and your WS table fields which you will load, if necessary); these can be easily changed if necessary before runnng it.

Nina Too
 
Hi,

It can be very interesting reading the following link:


It is a discussion about a kind of self-made SPUFI. There is source there that is interpreted by DB2. You can generate youw own DB2 spufi command and let it be executed.

Regards,

Crox
 
Hi Nina,

Acheology isn't my strong suit, but I'll try to interpret the fragments of the problem we've unearthed here.

He says he wants a table of DATANAMES. I capitalize to differentiate that from data values. It sounds to me like he wants to vary the data COLUMNS he retrieves from exec to exec by using the table of datanames.

The only way I know of for doing that is to use Dynamic SQL.

Someone (MrR ?) suggested recompiling on the fly. That would work if the tekkies let you get away with it.

Regards, Jack.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top