I have a few programs that may help, written mostly for my own selfish 
needs. Can't giveup the source code cuz I have partners, but I do have 
the NMPRG's available.

The first program finds all your Image databases, interrogates them 
using dbinfo, setvars to the  total count of all db,items, sets, and 
fields on the systems.
The second program simply looks at those variables above and creates a 
repository image database (MIGDB.PUB.J3K) to store all your image meta 
data (structure), not the actual data in them ;-)
Third program, almost like the first, only instead of counting, it 
actually DBPUT's all the dbinfo data into the MIGDB database.

Now if you compile the programs in question, and direct the coblist to a 
disc file, you can then write a simple program that reads the coblist, 
and then DBFINDs in MIGDB which has the image structure logically linked.


Michael Anderson,
J3k Solutions
Sr.Systems Programmer/Analyst
832.515.3868



Roy Brown wrote:
> In message <[log in to unmask]>, Jim Chance 
> <[log in to unmask]> writing at 14:20:54 in his/her local time opines:-
>> Is anyone aware of a tool that would create a cross reference list 
>> from a COBOL copylib to its matching IMAGE data item?
>
>> We have the need to spec out several COBOL programs and during this 
>> reverse engineering step we've natrually encounterd a time consuming 
>> requirement of creating a cross reference list of used copylib field 
>> names within each program against its matching - and usually 
>> different named datset "item" name.
>
> When the actual new databases are created in another system, perhaps 
> SQL, the database and dataset/table names will be the same and in 
> order for the non COBOL developer in the desitnation system to 
> understand formulas he/she needs to see the dataset/item - AKA 
> table/column name - they have no knowledge of copylib field names.
>
> For instance IMAGE says...
>    LOCATION-MSTR,MANUAL
>       ITEMS:
>          ACCOUNT-SIGNON,       X8            <<KEY ITEM>>
>          LOCATION,             X2
>          GROUP,                X2
>          NAME-LOC-SHORT,       X16
>          NAME-LOCATION,        X30
>          ADDRESS-LINE1,        X30
>          ADDRESS-LINE2,        X30
>          CITY,                 X16
> However in the COBOL application we refer to CITY as LOCM-CITY 
> (copylib name).
> While creating the new spec we must refer to CITY as the field to use; 
> not LOCM-CITY.
>
> It might be reaching.....but thought I'd ask if anyone knows how to 
> reduce this pain.
>
> Thank you very much for your time.
>
>
> I'm looking at a spreadsheet that does just this, and which I 
> painstakingly constructed for a client a few years ago.
>
> I can remember that I did it, but not how :-(
>
> As they had DOC/3000, and there's no sign that was used to generate 
> it, then either DOC/3000 doesn't do it, or I missed a trick big-time :-)
>
> I can see that the database details were all extracted with Query into 
> column H of a spreadsheet, and the contents of the copy library into 
> column I on a second sheet, and I recall that I tied them together 
> with a dataset name/copylib entry name cross-reference (VLOOKUP), so 
> that the copylib entries could be replicated into column I of the 
> first sheet so they roughly lined up with the corresponding dataset 
> details.
>
> But then I had to copy/paste that column as Values, so I could refine 
> the matching manually.
>
> Not a big job, but we had:
>
> CopyLib entries that were subdefinitions of dataset fields
> - with and without an overarching 1 to 1 definition of the database field
> - that may or may not have had the PIC you'd expect
> - at the same or a deeper level (05, 10, etc.)
> - Redefines
> - Entries defined as Occurs when the dataset fields weren't arrays, 
> but all individual
>
> so I had to put extra cells (Shift Down) into the H column to give the 
> correct alignment;
>
> and
>
> CopyLib entries encompassing two or more contiguous dataset fields
>
> so I had to put extra cells (Shift Down) into the I column to give the 
> correct alignment.
>
> In short, some of everything you can think of that would make a 
> dataset description and its corresponding copylib entry go out of 
> alignment while still describing the same number of bytes
> (plus a few that turned out to be describing a slightly different 
> number of bytes in places, though thankfully mostly at the end)
>
>
> I'm sure a tool could exist to do this, by doing byte-for-byte 
> matching down the dataset description, if it had the smarts to know 
> about Image and about COBOL copylibs, but nobody offered me one :-(

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *