Help me identify a Cobol database
in [Cobol]
|
From: SomeGuy on 2 Feb 2010 16:11 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.
From: SomeGuy on 2 Feb 2010 16:37 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!' > > DD 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? Answer: it contains records defined by COBOL source, which you'll need to have to read it. 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.
From: James J. Gavan on 2 Feb 2010 20:37 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' ;-)
From: Alistair on 3 Feb 2010 07:01 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.
From: Anonymous on 3 Feb 2010 09:07
In article <9a930fb6-22fb-4a4f-8fa0-4b73fc71118f(a)a13g2000vbf.googlegroups.com>, SomeGuy <jimgreen(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 |