|
View previous topic :: View next topic
|
| Author |
Message |
j_rymbei
New User
.jpg)
Joined: 22 Aug 2006
Posts: 17
Location: India Kolkata
|
|
|
|
I have a file which has field names. I want a COBOL program, which should read the File and get the field name, and use that field name in MOVE statement.
FileA -
001 WS-A
002 WS-B
Cobol program
Read FileA.
Move xyz to WS-A.
Note: WS-A is to be received from the FileA and not included in working storage or any copybook.
I know it may not be possible to do so in COBOL, but is there any alternate solution. |
|
| Back to top |
|
 |
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| Some clue as to what you are actually trying to do, and why, would be useful. |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3051
Location: NYC,USA
|
|
|
|
| Quote: |
| I know it may not be possible to do so in COBOL, but is there any alternate solution. |
Unless you state the problem clearly, it is impossible to find the solution.
However, I can understand that,
1) WS-A is a variable in your file,
2) WS-A - you don't want to declare in Working Storage section
3) Now, you want the MOVE 'xyz' to WS-A should work
4) And then what do you do next with WS-A, is it used anywhere further?
Why would you get any variables/field name in a file instead of actual data, something is wrong? |
|
| Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada
|
|
|
|
| This would be easy to do if, instead of variable names the input file contains the start position and length of each field you wanted to copy data to. |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3051
Location: NYC,USA
|
|
|
|
| Don , I may be wrong but it looks like TS wants to use the variables written in the file as it is in COBOL program without any of them declared in WS section. |
|
| Back to top |
|
|
j_rymbei
New User
Joined: 22 Aug 2006
Posts: 17
Location: India Kolkata
|
|
|
|
Thanks to all. Let me rephrase it.
1. There will be a data map file. It would contain a source field name and
target field name.
2. The program should be able to read the data map file, an I/P file and
write into a VSAM file.
In the I/P file it will have the source field data and it will be mapped to
a copybook. The copybook will have the same field name as it is
mentioned in the data map file. Same for the O/P VSAM file.
3. The program should be able to
a. match the i/p copybook field name with the source field name from
data map file
b. match the o/p copybook field name with the target field name from
the data map file
c. the matching is needed as I need to follow the mapping mentioned
in the mapping file.
d. write in the vsam file based on the mapping
4. Reason for the mapping - I need a configurable mapping file which should be used as an input to load the data in VSAM, so that if any new fields arrive in the I/P file, we don't need to change the programs. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
So if there is a new field on the file (and that must be happening like, what, about 13 times a day?) instead of adding a MOVE statement and recompiling the program, you want to do all this?
Have a think about what Don said. If you had 17,10,31,10 in your input, you'd have no messing with names. So do the messing outside, and create a file that the COBOL program can use (without messing).
The thing is, when you need to do any "conversion" of data, like on output it should be packed-decimal but it is zoned-decimal on the input. So you do some stuff for that. Then you end up with a limited and buggy version of SORT/FileManager/FileAid/Whatever. |
|
| Back to top |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006
Posts: 1353
Location: Israel
|
|
|
|
| j_rymbei wrote: |
| so that if any new fields arrive in the I/P file, we don't need to change the programs. |
Wait, no need to change the file(s) record length in your cobol program ? |
|
| Back to top |
|
|
j_rymbei
New User
Joined: 22 Aug 2006
Posts: 17
Location: India Kolkata
|
|
|
|
| Bill Woodger wrote: |
So if there is a new field on the file (and that must be happening like, what, about 13 times a day?) instead of adding a MOVE statement and recompiling the program, you want to do all this?
Have a think about what Don said. If you had 17,10,31,10 in your input, you'd have no messing with names. So do the messing outside, and create a file that the COBOL program can use (without messing).
The thing is, when you need to do any "conversion" of data, like on output it should be packed-decimal but it is zoned-decimal on the input. So you do some stuff for that. Then you end up with a limited and buggy version of SORT/FileManager/FileAid/Whatever. |
I agree, by using the position we may resolve the issue. However, as you also rightly identified, I may need to convert the data acording to the target field.
There can be cases where the data arrived as e.g.
(a) in I/P I recieved 1234567890 but I need to store it in a s9(9) USAGE COMP field
(b) in I/P I received -2637980.87 but I need to store it in S9(7)v99 USAGE COMP-3 field |
|
| Back to top |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006
Posts: 1353
Location: Israel
|
|
|
|
In cobol, here is how it could be done:
Define in WORKING-STORAGE:
| Code: |
01 TB-METADESC.
03 FILLER OCCURS 500.
05 TB-FLDNAME PIC X(48).
05 TB-INP-LEN PIC S9(4) COMP.
05 TB-INP-OFS PIC S9(4) COMP.
05 TB-INP-USA PIC X(1).
05 TB-OUT-LEN PIC S9(4) COMP.
05 TB-OUT-OFS PIC S9(4) COMP.
05 TB-OUT-USA PIC X(1). |
and in PROCEDURE DIVISION:
Load metadata from i/p copybook into this table (consist of reading one cobol statement, analyzing it to get the field name, its usage and picture, and to store this info in the table).
Then update the same metadata using o/p copybook (consist of reading one cobol statement, analyzing it to get the field name, its usage and picture, and to insert this info in the field of same name in the table).
Once you have that, you can start processing the data: read one input record, scan the metadata and move data from input to output (if they have same usage just 'move', if they have different usage then 'convert') then write the result.
I think you need "above average" skills in cobol to do this. |
|
| Back to top |
|
|
jasorn
Warnings : 1
Active User
Joined: 12 Jul 2006
Posts: 191
Location: USA
|
|
|
|
| I created some programs that do just this. I can't describe how useful it's been over the years. Easily my most useful work. |
|
| Back to top |
|
|
jasorn
Warnings : 1
Active User
Joined: 12 Jul 2006
Posts: 191
Location: USA
|
|
|
|
I should add that I'm in the process of converting these programs to use symnames metadata format instead of the custom metadata format I created for this. At the time I created this, around 1995-6, I hadn't even heard the term metadata and symnames didn't exist. I often wonder if someone got wind of my process and passed the idea on to dfsort! Maybe I'm due royalties 
| jasorn wrote: |
| I created some programs that do just this. I can't describe how useful it's been over the years. Easily my most useful work. |
|
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Well, I've got a different way to do it :-)
Easytrieve Plus had "symnames" for its SORT activities, many years before DFSORT. |
|
| Back to top |
|
|
|
|
