Thoughts on MF COBOL, Unix, and RDBMS
in [Cobol]
|
Prev: COBOL Compiler for Windows
Next: compiler directive
From: Robert on 4 May 2008 15:01 On Sun, 04 May 2008 11:01:51 +0100, Frederico Fonseca <real-email-in-msg-spam(a)email.com> wrote: >On Sat, 03 May 2008 01:05:28 -0500, Robert <no(a)e.mail> wrote: > >>On Sat, 3 May 2008 12:51:38 +1200, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> >>wrote: >> >>>I have some programs written in Fujitsu COBOL (generated by a tool) that run >>>in a Windows environment, read ISAM and write a RDB using embedded SQL and >>>ODBC. >>> >>>I would like to have these programs run in a Unix environment. There is a >>>COBOL compiler (MicroFocus) available but it doesn't support SQL, and the >>>ISAM is C-ISAM. :-) >> >>It does support SQL, either through the MF-supported OpenESQL precompiler or the Oracle >>buggy and no longer supported PRO*COBOL. You can talk through ODBC or OCI (Oracle Call >>Interface). >Robert, > >Can you please supply us with the link from Oracle that states that >PRO*COBOL is no longer supported? When I called for support, no one could figure out why PRO*COBOL was crashing, or knew anything about it. The answer was that text beyond column 80 makes it crash. Oracle documentation doesn't say that, either.
From: Frederico Fonseca on 4 May 2008 17:33 On Sun, 04 May 2008 14:01:25 -0500, Robert <no(a)e.mail> wrote: >On Sun, 04 May 2008 11:01:51 +0100, Frederico Fonseca <real-email-in-msg-spam(a)email.com> >wrote: > >>On Sat, 03 May 2008 01:05:28 -0500, Robert <no(a)e.mail> wrote: >> >>>On Sat, 3 May 2008 12:51:38 +1200, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> >>>wrote: >>> >>>>I have some programs written in Fujitsu COBOL (generated by a tool) that run >>>>in a Windows environment, read ISAM and write a RDB using embedded SQL and >>>>ODBC. >>>> >>>>I would like to have these programs run in a Unix environment. There is a >>>>COBOL compiler (MicroFocus) available but it doesn't support SQL, and the >>>>ISAM is C-ISAM. :-) >>> >>>It does support SQL, either through the MF-supported OpenESQL precompiler or the Oracle >>>buggy and no longer supported PRO*COBOL. You can talk through ODBC or OCI (Oracle Call >>>Interface). >>Robert, >> >>Can you please supply us with the link from Oracle that states that >>PRO*COBOL is no longer supported? > >When I called for support, no one could figure out why PRO*COBOL was crashing, or knew >anything about it. The answer was that text beyond column 80 makes it crash. Oracle >documentation doesn't say that, either. The fact that you got someone unable to answer one of your problems does not mean it is no longer supported. So once again I ask for a link to a Oracle webpage that states that Oracle no longer supports PRO*COBOL. Frederico Fonseca ema il: frederico_fonseca at syssoft-int.com
From: Pete Dashwood on 4 May 2008 18:40 "Robert" <no(a)e.mail> wrote in message news:rrtp14tp3u0l9ni93d1gb44i56cfk3pjm6(a)4ax.com... > On Sat, 3 May 2008 19:31:47 +1200, "Pete Dashwood" > <dashwood(a)removethis.enternet.co.nz> > wrote: > >> >> >>"Robert" <no(a)e.mail> wrote in message >>news:dstn14pta7o7oou3h872mfmkkeasb5pq8f(a)4ax.com... >>> On Sat, 3 May 2008 12:51:38 +1200, "Pete Dashwood" >>> <dashwood(a)removethis.enternet.co.nz> >>> wrote: >>> >>>>I have some programs written in Fujitsu COBOL (generated by a tool) that >>>>run >>>>in a Windows environment, read ISAM and write a RDB using embedded SQL >>>>and >>>>ODBC. >>>> >>>>I would like to have these programs run in a Unix environment. There is >>>>a >>>>COBOL compiler (MicroFocus) available but it doesn't support SQL, and >>>>the >>>>ISAM is C-ISAM. :-) >>> >>> It does support SQL, either through the MF-supported OpenESQL >>> precompiler >>> or the Oracle >>> buggy and no longer supported PRO*COBOL. You can talk through ODBC or >>> OCI >>> (Oracle Call >>> Interface). >>> >>> Embedded SQL on Unix is what I do every day. >> >>I think it is an old compiler, Robert. It might even be the same one that >>was rebadged and sold as "MicroSoft COBOL"... I have been assured that it >>doesn't support SQL, but there may be a lack of understanding. Can >>OpenESQL >>work with old MF stuff? Would we need to buy Open ESQL or is it free? > > OpenESQL is not free. It is sold packaged with Cobol compilers, not as a > separate product. I am assured it is not packaged with the compiler available in this case. > > Precompilers translate EXEC SQL statements into CALLS and MOVES that can > be compiled by > any Cobol compiler. The problem comes at execution time. Old MF compilers > produce GNTs > that run under a COBRUN. They cannot call ELF-format libraries. The > library code has to be > linked into a custom COBRUN. Building one is a pain. > >>>>So maybe the generated code should simply write the data out as strings >>>>that >>>>can be INSERTED with a script, as another step in the process. >>> >>> A kludge. > > On second thought, since volume is low, I'd have the Cobol program write > SQL INSERT > statements: > INSERT INTO table VALUES ("string", 123, 456, ...); Yes, I see this as equivalent to generating XML, or a CSV file. Again, as I don't know the Unix environment, I'm not aware of the utilities that this could be piped to. > > You could pipe the file into a tool like isql or sqsh. I've never heard of either of these, but I'll do some homework and see whether this is viable or not for the people concerned. Thanks for the pointer. > >>Yes, we are not using Oracle in this case. The target is SQL Server (user >>request; I have no preference personally...). > >>>>Given my unfamilairity with Unix environments I may have missed >>>>something >>>>that is normal in that environment. >>> >>> It's not about Unix, it's about databases. >> >>Yes, but for all I know there may be packages, tools and utilities in the >>Unix environment, that I'm simply not aware of and that could suggest a >>completely different approach... Just trying to cover the bases. > > SQL Server doesn't run on Unix. They assure me it does in their environment and specifically requested SQL Server. I'll check with them on this. The actual database doesn't really matter, as I'm sure you know. >Why are we talking about Unix? I'd do the file conversion > on Windows, using MF or Fujitsu Cobol. There are many Windows tools to > load a database. > MSQUERY is one that everyone has because it comes free with Excel. I have certainly considered doing just that and it isn't off the table. For me the C-ISAM was an unknown in the Windows environment, but as both you and Richard have assured me it is a simple flat file format, this might be one of the best options. > >>Is there a Unix environment utility that will read ISAM and write SQL >>Server? That would certainly be another option. The code I have will do so >>in a Windows environment using Fujitsu ISAM. I need it for a Unix >>environment using C-ISAM. > > C-ISAM is super easy. The data is in a flat file with fixed length > records. I'd FTP it to > Windows and do the conversion there. Better yet, read the file through a > SAMBA connection. > Thanks again for your comments, Robert. Pete. -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 4 May 2008 18:48 "Rene_Surop" <infodynamics_ph(a)yahoo.com> wrote in message news:8b983d33-43f2-455a-8cb3-7301adde6bae(a)1g2000prg.googlegroups.com... >> SQL Server doesn't run on Unix. Why are we talking about Unix? I'd do the >> file conversion >> on Windows, using MF or Fujitsu Cobol. There are many Windows tools to >> load a database. >> MSQUERY is one that everyone has because it comes free with Excel. >> > > I guess Pete is converting (or processing) a UNIX-based Cobol platform > using a C-ISAM file or maybe a MySQL data into a Windows-based Fujitsu > Cobol (using MS/SQL server). No, not quite, but for commercial reasons I can't go into details here. Certainly, we are looking at moving a fairly large C-ISAM based application running in a Unix environment, onto a relational Database. I have tools I wrote that can do this, but they are intended for the Windows environment. I'm trying to assess how much mdification the tools will need, or whether I can do this without modifying them, maybe by using a different strategy than I have in the past. > > This is sometimes done if you have VMWare running on UNIX emulating a > Windows-based platform.... once converted in Windows, then it can be > 'totally' be used in Windows OS. > > This is quite a very good example of rightsizing. Nice thoughts here. Certainly there have been some nice thoughts from Richard and Robert and I appreciate their contributions. Thanks also for your positive comments, Rene. Pete. -- "I used to write COBOL...now I can do anything."
From: William M. Klein on 4 May 2008 23:22
Some comments on Micro Focus compilers, SQL, Unix, et al At the time that Micro Focus had 3 products for DOS-OS/2 - Compiler - Toolset - Workbench Micro Focus sold 2 products for Unix - Compiler - Toolbox Micro Focus sold (for Windows-OS/2) a SEPARATE "XDB" product which was their first "SQL" product (and was definitely a DB2 emulator). Later products included "built-in" SQL preprocessors (including PRO*COBOL at one stage - as an option). For as long as I can remember (since at least late 80's), Micro Focus has supported the "preprocessor" directive on all platforms. For each of the platforms that I remember, there were "add-on" SQL products. "Integrated" SQL support (that was not an add-on product) was a "medium-late" addition from Micro Focus (late '90s, I would guess). As far as "rebadged" products go, "COBOL/2" (compiler only, and ASCII not EBCDIC support) was a product available from either IBM or Micro Focus. (It was "crippled" to NOT have EBCDIC support - or even '85 Standard support when you bought the IBM version.). This was during the days when Microsoft and IBM were still cooperating on OS/2. This product had support for an "MS" dialect that did emulate a much earlier Microsoft developed/sold COBOL product. The actual Microsoft "rebadged" COBOL product - that worked with the Microsoft pwd (???) was "mostly" equivalent to COBOL 3.x from Micro Focus - but was (again) a crippled product that didn't do every thing that the IBM or Micro Focus products did, but WAS integrated into the Microsoft product line. * * * Bottom-Line (related to the ORIGINAL issues), I know of NO version of a Micro Focus product (from the late '80s on) that did not "work with" SQL, but up thru Server Express,(when talking about Unix) I would expect that you would need to purchase the correct "add-on" SQL product and use the Micro Focus "preprocessor" directive to get it to work on Unix. Also, related to the original question, whether C-ISAM was used or not was ALWAYS a "directive" question. For the Unix products, the "file-handler" was always provided in a manner that could be changed by the user. Although it is for a MUCH later Unix product, if you want to know about selecting C-ISAM vs other file systems, check out: http://supportline.microfocus.com/Documentation/books/sx50ws03/sx50indx.htm then look at "compiler directives" and look for "FILETYPE " where value "1" is C-ISAM, but many other types are available. -- Bill Klein wmklein <at> ix.netcom.com |