Re: COBOL File Specs to DDS or SQL

[Jerry Draper <midrangel@xxxxxxxxxxxxx>]

I recently did this manually.  It would great to have a pgm to read 
through the COBOL /copy statements and create DDS.

Jerry

On 8/16/2012 11:29 AM, DrFranken wrote:
> The tables are coming from mainframe.  All we have is COBOL Source for
> the specs.
>
>       - L
>
> On 8/16/2012 11:05 AM, Jim Oberholtzer wrote:
> > Larry,
> >
> > If the tables exist on the system, why not just use Navigator to
> > retrieve the SQL to recreate the table?
> >
> > Jim Oberholtzer
> > Chief Technical Architect
> > Agile Technology Architects
> >
> >
> > On 8/16/2012 8:53 AM, DrFranken wrote:
> > > Found out there are 'more files' likely following this one thus making
> > > the program approach even more desirable.
> > >
> > > I Personally don't have the specs but they are generic COBOL. And being
> > > COBOL they are not in columns and are indented seemingly randomly. Since
> > > the subfields have 'redefine' those can easily be ignored I think.
> > >
> > > Was hoping someone maybe had a program they've done this with.:-)
> > >
> > >             - Larry
> > >
> > > On 8/16/2012 9:49 AM, John Yeung wrote:
> > > > >    It's absolutely doable, and I agree that a programmatic approach is
> > > > >    the way to go.  I don't know COBOL, though.  Maybe if you could give a
> > > > >    sample of the specs you're talking about?
> > > > >
> > > > >    Rob's suggestion of just letting COBOL handle it certainly would be
> > > > >    the first and most obvious choice.  If that doesn't work, I strongly
> > > > >    suspect it would be rather easy to parse the specs in any high-level
> > > > >    language (doesn't even have to be on the i) and generate the desired
> > > > >    DDS or SQL.
> > > > >
> > > > >    John
> > > --