I'm not sure about MicroFocus Cobol (which is a PC Cobol, as I recall) but I recall that on the mainframes (IBM 360/370 range) Cobol did NOT provide its own database layer.
It is probably something like VSAM or ISAM, or possibly SQL. A web search yielded: http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q103/2/26.asp&NoWebContent=1 Apparently there is also a Microsoft Cobol. There is also mention at http://www-306.ibm.com/software/data/u2/middleware/ Cobol Direct Connect COBOL Direct Connect (CDC) supports quick and safe redeployment of COBOL-indexed files into SQL-compliant RDBMS tables without data structure modification, source code changes, "dynamic SQL" or other migration efforts. CDC utilizes legacy applications including underlying file systems, access to GUI interfaces, and desktop DSS/4GL interoperability. In addition, new applications can be developed using Java and other modern languages that can access the COBOL data. COBOL Direct Connect provides: * Direct redeployment of ISAM (or other) data structures into UniData's nested RDBMS which provides applications with SQL data access and permits the usage of more modern tools for reporting and BI/OLAP analysis. * Preservation of your existing COBOL applications and data structures so you maintain just one set of source code. * Expanded functionality with a low cost of ownership. COBOL Direct Connect maps COBOL ISAM files into the IBM UniData extended relational database. It works with most versions of AcuCobol (from AcuCorp) and MicroFocus COBOL (from Merant/MicroFocus). > > OK, OK, I know this is a M list. But hear me out. > > The December our Mysis contract will expire, which is our old EMR.=20 > The company says that it will be $5,000+ to get the old progress notes > exported. Recently our group voted not to do that, and to just go > forward with our paper printouts of that data (which are already in > our paper charts). > > But I can't help but wonder if I could get the data out myself. I > know that I can do it through printing to a disk instead of printer, > then running it all through a conversion program. But it is certainly > lacking. > > The underlying code is written in cobol -- either RM COBOL or > MicroFocus Cobol (or both). I don't know Cobol, but I gues I could go > learn it... > > So my question, does anyone know enough about cobol to tell me to give > it up now, its too hard. Or that it's just sitting there for easy > picking. Would the cobol be acting as the database itself (as M > does), or would it likely be using some other method of storing. This > technology is circa 1990. > > Thanks > Kevin > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Hardhats-members mailing list > Hardhats-members@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hardhats-members > ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
