Help me identify a Cobol database
in [Cobol]
|
From: SomeGuy on 3 Feb 2010 10:50 On Feb 3, 9:07 am, docdw...(a)panix.com () wrote: > In article <9a930fb6-22fb-4a4f-8fa0-4b73fc711...(a)a13g2000vbf.googlegroups..com>, > > > > SomeGuy <jimgr...(a)nc.rr.com> wrote: > >On Feb 2, 9:00?am, docdw...(a)panix.com () wrote: > >> In article > ><c35879ad-0e56-4cf9-8fc1-088fad613...(a)h33g2000vbr.googlegroups.com>, > > >> SomeGuy ?<jimgr...(a)nc.rr.com> wrote: > >> >Thanks for the very helpful reply! > > >> >[Aside - I don't think it's uncommon or out-of-line for a NG post to > >> >appear that requires a "need more information" response" (and people > >> >generally don't suggest you're trying to ruin someone else's > >> >livelihood by asking :-)] > > >> Not 'ruin their livelihood'... just get them to do for free what they do > >> for a salary. ?'Hey, Sam, you got a free day to drive this tractor-trailer > >> rig a couple-five hundred miles for me? ?I've put some effort into the > >> project... see, I know how to buckle my safety-belt!' > > >Hmmm, let's review this thread, shall we? > > >Jim: How would I identify the format of a data file used by a PC COBOL > >program? > > A: Familiarising which of a variety of PC COBOL environments produce what > kinds of files under different conditions is part of the skill-set used by > a professional programmer to earn a living. > > >Answer: it contains records defined by COBOL source, which you'll need > >to have to read it. > > Conclusion: you get what you pay for... sometimes even double. > > > > >Apparently, the above exchange is equivalent to asking someone to > >drive a tractor-trailer rig. For hundreds of miles. For free. > > >It's all so clear now. > > Requesting that a person provide information and skills which said person > uses in order to earn a living without offering recompense for said > information and skills is equivalent to requesting a person provide > information and skills which said person uses in order to earn a living > without offering recompense for said information and skills... by Neddie > Dingo, programming starts with Logic, you may just have taken the first > step! > > DD Ok, dude, whatever.
From: SomeGuy on 3 Feb 2010 11:13 On Feb 2, 8:37 pm, "James J. Gavan" <jgavandeletet...(a)shaw.ca> wrote: > SomeGuy wrote: > > On Feb 2, 7:18 am, Alistair <alist...(a)ld50macca.demon.co.uk> wrote: > > >>Am I the only person who remembers dBase files which (IIRC) were > >>suffixed .DB? > >>Since the .DB files are unlikely to contain cobol specific data items > >>then importing the flat files in to MS Access would be an option. It > >>would require some understanding of data formats and intelligent > >>guessing of layouts. Not too difficult, even I have done that in the > >>past. > > > How would one go about guessing the layout of a COBOL-generated file > > for which you know next to nothing about the layout? Note that, > > unlike DBase files, I can discern no field descriptors (name, type, > > start, length, etc...) in the file. > > > Thanks. > > Well sort of - you've basically got to get at the DB Engine where you > INITIALLY CREATE a Table specifying for each column, what type, length > etc., it has. Granted the format and Data are in the same file, and to > some extent the M/F COBOL file headers have 'some' information, but it > doesn't take you all the way. So without Alistair the Alligator's > guessing game, to be ABSOLUTELY proof positive you need two things from > the COBOL application, and the first I forgot to mention, concentrating > on the Record Layout. Here's some template stuff I have for files > using OO classes :- > > *>------------------------------------------------------------ > OBJECT. > *>------------------------------------------------------------ > $*> set datacompress "1" - use as necessary > > FILE-CONTROL. > > Select Data-File > assign Data-filename > organization indexed > access dynamic > record key Data-PrimeKey *> +++ CHANGE **** (1) > alternate key Data-AltKey1 *> +++ CHANGE **** (1 & 2) > file status ws-FileStatus. > *> lock mode .............. *> +++ CHANGE **** (3) > > *>---------------------------------------------------------------- > > *> (1) PRIME and ALTERNATE KEYS : > > *> Both PrimeKeys and Alternate Keys can be SLIT KEYS :- > *> > *> 01 Data-Record. > *> 03 FirstName pic X(10). > *> 03 Personnel-no pic X(4). > *> 03 LastName pic X(15). > > *> the syntax: record key is Fullname = LastName, FirstName > > *> would cause the COBOL system to treat Fullname as though it > *> were an explicitly defined group item consisting of : > > *> 03 LastNamee pic X(15). > *> 03 FirstName pic x(10). > > *> (2) ALTERNATE KEYS > > *> Either delete or specify 'with or without duplicates'. > *> If present ensure you add methods to handle alternates > > *> (3) LOCK MODE : > > *> lock mode } automatic} with (1) lock On (Multiple) Record(s) > *> } manual } " " " " " " > *> " (2) Rollback > *> } exclusive > > *>--------------------------------------------------------------- > > FILE SECTION. > > FD Data-File. > > 01 Data-record. *> +++ CHANGE **** > 05 Data-PrimeKey pic x(20). *> by substituting your > 05 Data-Info-1 pic x(70). *> copy record > 05 Data-AltKey1 pic x(30). *> > 05 Data-info-2 pic x(140). *> > > *> Replace this dummy info with a copyfile containing your record. > *> So that the copyfile can be used elsewhere in other programs/ > *> classes, prefix each field with (tag), so that you can have an > *> entry :- > *> > *> 01 Data-Record. > *> copy 'myrecord.cpy' replacing ==(tag)== by ==Data==. > > *>--------------------------------------------------------------- > > It's possible, that in some instances the developers *may* have used > Alternate Keys for some of their ISAM files. If their application is > multi-user, they may have used the LOCK MODE feature. > > Using that DFE (Data File Editor) I mentioned - I tried it on a simple > file. As I indicated it takes the binary values and translates them to > what is referred to in COBOL as Usage Display, (printable numbers), i.e. :- > > pic 9(04)v9(02) comp-3 (contains 012345) shows as '0123.45' in the > display dialog. BUT it doesn't give you a column-header description, nor > when you look at the size does it indicate whether or not the field was > specified as :- > > - pic 9(04).9(02), pic 9(04)v9(02) or pic 9(04)v9(02) comp-3, and > depending upon the compiler, other variations on the 'comp-3', such as > comp-1, comp-5. > > The only thing it specifically does, in the case of ISAM, is define the > positioning of the PrimeKey and any Alternate Keys, such as :- > > - PrimeKey (1:20) Alt-Key-1 (30:40) Alt-Key-2 (78:20) > > I drafted something, but I don't think I sent it. Either the end-user > has got to show you what they have, from reports, (which will still > entail you doing a lot of messing about to extract the data), or bite > the bullet, and for an acceptable fee get the file formats from the > original developers - *IF* they will sell them to you ! > > Did you google on COBOL data conversions, or look at the COBOL FAQ for > help ? > > Jimmy, Calgary AB > > PS: Alistair once told us spell checkers want to change his name to > 'Alligator' ;-) To be honest, never having used COBOL, I didn't really follow everything you posted. I looked at the Net Express website but couldn't find information about the DFE. I did try the Siber Systems Data Viewer. It manages to report a lot of columns, many of them with legitimate-looking values. But the rest have basically gibberish and all have only generated names (like "GUESSED-535-1"). Another thought: is there a tool that will scan COBOL source and produce a report (copybook? FDD?) with the layout? If so, perhaps I can give the tool to the client to run for me (assuming they have source). I really appreciate the effort you've put in. Above and beyond. Jim
From: SomeGuy on 3 Feb 2010 11:16 On Feb 3, 7:01 am, Alistair <alist...(a)ld50macca.demon.co.uk> wrote: > On Feb 2, 9:11 pm, SomeGuy <jimgr...(a)nc.rr.com> wrote: > > > > > On Feb 2, 7:18 am, Alistair <alist...(a)ld50macca.demon.co.uk> wrote: > > > > On Feb 1, 9:43 pm, Richard <rip...(a)Azonic.co.nz> wrote: > > > > > On Feb 2, 6:11 am, SomeGuy <jimgr...(a)nc.rr.com> wrote: > > > > > > Need to identify some database files used by a PC COBOL program > > > > > written in the mid-90's. The extensions are .DB and .IDX. Given the > > > > > date, language and OS, are there any candidates you can think of? I > > > > > can send a sample of the files if that would help. > > > > > > Thanks, > > > > > Jim > > > > > The .DB is probably a user choice. The .IDX is most likely an index > > > > file for the .DB. If the first two bytes of the .IDX is 0xFE53 then it > > > > is probable that these are MicroFocus LevelII/CISAM format indexed > > > > files. > > > > > The first block of the .IDX should have further information giving > > > > record length and key information (size and start position). > > > > > If the files are LevelII/CISAM then the data records in the .DB will > > > > be fixed length with CR/LF record terminators. Other formats may have > > > > variable length records with record headers and/or may have compressed > > > > data. > > > > > Without an FD entry you are unlikely to be able to know what the data > > > > fields are or even where they start/end within the record. > > > > Am I the only person who remembers dBase files which (IIRC) were > > > suffixed .DB? > > > Since the .DB files are unlikely to contain cobol specific data items > > > then importing the flat files in to MS Access would be an option. It > > > would require some understanding of data formats and intelligent > > > guessing of layouts. Not too difficult, even I have done that in the > > > past. > > > How would one go about guessing the layout of a COBOL-generated file > > for which you know next to nothing about the layout? Note that, > > unlike DBase files, I can discern no field descriptors (name, type, > > start, length, etc...) in the file. > > > Thanks.- Hide quoted text - > > > - Show quoted text - > > The same way that I went about guessing the contents of a VDF (Visual > Data Flex) file: look at the reports or screens produced/used and tie > their contents to the data in the file. It takes a bit of brain > processing and is not guaranteed to be 100% foolproof especially if > you don't know the data formats available to the database. > > If you don't have the file layouts and probably you don't have report > or screen shots then you probably won't be able to resolve the issue. We do have screen shots and output, but I can't imagine that approach would be economical for this project. Jim
From: Alistair on 3 Feb 2010 12:44 On Feb 3, 1:37 am, "James J. Gavan" <jgavandeletet...(a)shaw.ca> wrote: > SomeGuy wrote: > > On Feb 2, 7:18 am, Alistair <alist...(a)ld50macca.demon.co.uk> wrote: > Jimmy, Calgary AB > > PS: Alistair once told us spell checkers want to change his name to > 'Alligator' ;-)- Hide quoted text - > Seeing as another thread has brought up soundex, shoulsd the spell checkers come up with Aligator or LGTR ?
From: Alistair on 3 Feb 2010 12:52
On Feb 3, 4:13 pm, SomeGuy <jimgr...(a)nc.rr.com> wrote: > On Feb 2, 8:37 pm, "James J. Gavan" <jgavandeletet...(a)shaw.ca> wrote: > > > > > > > SomeGuy wrote: > > > On Feb 2, 7:18 am, Alistair <alist...(a)ld50macca.demon.co.uk> wrote: > > > >>Am I the only person who remembers dBase files which (IIRC) were > > >>suffixed .DB? > > >>Since the .DB files are unlikely to contain cobol specific data items > > >>then importing the flat files in to MS Access would be an option. It > > >>would require some understanding of data formats and intelligent > > >>guessing of layouts. Not too difficult, even I have done that in the > > >>past. > > > > How would one go about guessing the layout of a COBOL-generated file > > > for which you know next to nothing about the layout? Note that, > > > unlike DBase files, I can discern no field descriptors (name, type, > > > start, length, etc...) in the file. > > > > Thanks. > > > Well sort of - you've basically got to get at the DB Engine where you > > INITIALLY CREATE a Table specifying for each column, what type, length > > etc., it has. Granted the format and Data are in the same file, and to > > some extent the M/F COBOL file headers have 'some' information, but it > > doesn't take you all the way. So without Alistair the Alligator's > > guessing game, to be ABSOLUTELY proof positive you need two things from > > the COBOL application, and the first I forgot to mention, concentrating > > on the Record Layout. Here's some template stuff I have for files > > using OO classes :- > > > *>------------------------------------------------------------ > > OBJECT. > > *>------------------------------------------------------------ > > $*> set datacompress "1" - use as necessary > > > FILE-CONTROL. > > > Select Data-File > > assign Data-filename > > organization indexed > > access dynamic > > record key Data-PrimeKey *> +++ CHANGE **** (1) > > alternate key Data-AltKey1 *> +++ CHANGE **** (1 & 2) > > file status ws-FileStatus. > > *> lock mode .............. *> +++ CHANGE **** (3) > > > *>---------------------------------------------------------------- > > > *> (1) PRIME and ALTERNATE KEYS : > > > *> Both PrimeKeys and Alternate Keys can be SLIT KEYS :- > > *> > > *> 01 Data-Record. > > *> 03 FirstName pic X(10). > > *> 03 Personnel-no pic X(4). > > *> 03 LastName pic X(15). > > > *> the syntax: record key is Fullname = LastName, FirstName > > > *> would cause the COBOL system to treat Fullname as though it > > *> were an explicitly defined group item consisting of : > > > *> 03 LastNamee pic X(15). > > *> 03 FirstName pic x(10). > > > *> (2) ALTERNATE KEYS > > > *> Either delete or specify 'with or without duplicates'. > > *> If present ensure you add methods to handle alternates > > > *> (3) LOCK MODE : > > > *> lock mode } automatic} with (1) lock On (Multiple) Record(s) > > *> } manual } " " " " " " > > *> " (2) Rollback > > *> } exclusive > > > *>--------------------------------------------------------------- > > > FILE SECTION. > > > FD Data-File. > > > 01 Data-record. *> +++ CHANGE **** > > 05 Data-PrimeKey pic x(20). *> by substituting your > > 05 Data-Info-1 pic x(70). *> copy record > > 05 Data-AltKey1 pic x(30). *> > > 05 Data-info-2 pic x(140). *> > > > *> Replace this dummy info with a copyfile containing your record. > > *> So that the copyfile can be used elsewhere in other programs/ > > *> classes, prefix each field with (tag), so that you can have an > > *> entry :- > > *> > > *> 01 Data-Record. > > *> copy 'myrecord.cpy' replacing ==(tag)== by ==Data==. > > > *>--------------------------------------------------------------- > > > It's possible, that in some instances the developers *may* have used > > Alternate Keys for some of their ISAM files. If their application is > > multi-user, they may have used the LOCK MODE feature. > > > Using that DFE (Data File Editor) I mentioned - I tried it on a simple > > file. As I indicated it takes the binary values and translates them to > > what is referred to in COBOL as Usage Display, (printable numbers), i.e.. :- > > > pic 9(04)v9(02) comp-3 (contains 012345) shows as '0123.45' in the > > display dialog. BUT it doesn't give you a column-header description, nor > > when you look at the size does it indicate whether or not the field was > > specified as :- > > > - pic 9(04).9(02), pic 9(04)v9(02) or pic 9(04)v9(02) comp-3, and > > depending upon the compiler, other variations on the 'comp-3', such as > > comp-1, comp-5. > > > The only thing it specifically does, in the case of ISAM, is define the > > positioning of the PrimeKey and any Alternate Keys, such as :- > > > - PrimeKey (1:20) Alt-Key-1 (30:40) Alt-Key-2 (78:20) > > > I drafted something, but I don't think I sent it. Either the end-user > > has got to show you what they have, from reports, (which will still > > entail you doing a lot of messing about to extract the data), or bite > > the bullet, and for an acceptable fee get the file formats from the > > original developers - *IF* they will sell them to you ! > > > Did you google on COBOL data conversions, or look at the COBOL FAQ for > > help ? > > > Jimmy, Calgary AB > > > PS: Alistair once told us spell checkers want to change his name to > > 'Alligator' ;-) > > To be honest, never having used COBOL, I didn't really follow > everything you posted. I looked at the Net Express website but > couldn't find information about the DFE. I did try the Siber Systems > Data Viewer. It manages to report a lot of columns, many of them with > legitimate-looking values. But the rest have basically gibberish and > all have only generated names (like "GUESSED-535-1"). > > Another thought: is there a tool that will scan COBOL source and > produce a report (copybook? FDD?) with the layout? If so, perhaps I > can give the tool to the client to run for me (assuming they have > source). > The COPYBOOKS (some of the files suffixed .cbl) should be part of the project environment available to your clients. If the copybooks are not there they are unlikely to be in the program code. Copybooks contain record layouts (in cobol-speak) which may contain the FD (file description) but don't have to contain the FD. The copybooks, if they exist, should be readable using notepad and will contain stuff like: 01 record-layout. 03 text-data-item pic x(255). < text, length 255 characters. 03 numeric-item pic 9(9) comp-3. < a packed field 03 another-number pic s9(4) comp. < a binary number. How this appears in the data depends upon whether the hardware is big-endian or little-endian. |