My COBDATA problem
in [Cobol]
|
Prev: "Climategate" code
Next: IS NUMERIC check for SPACES
From: Pete Dashwood on 2 Dec 2009 23:41 Graham Hobbs wrote: > Pete, > > Your 'emphatic' mods didn't compile and when I jerked them around, > didn't work. Well, I asked you to let me know and you did... :-) I'm sorry. Without knowing the precise nature of the jerking, or what your compiler said about it, I can't help further. > I would post what happened but is all getting a bit > heavy. I will look at the program, pity its not documented. It is written in procedural COBOL. Some people argue that is "self-documenting"...:-) I managed to maintain it without real difficulty (once I got my head around the style). > > Might there be a cobdata executable somewhere that runs on a Windows > XP box I could try? Yes, there is. I said as much. There are two executables: 1. The application wrapped in C#, as downloadable from cobol21. This is a complete, standalone application. You can present your record definition on the system clipboard or from a local sequential file, and the output is written to a sequential file in the local directory. Have you tried this? (You will need a .NET platform installed, in order to run it. The install will get it for you if it doesn't find it.) 2. A COM .dll which can be called from any language which supports the Component Object Model. So far people have used it from Fujitsu COBOL, VB.Net and C++, all running on the XP platform. This has no user interface and expects the input to be in a local sequential file. You must instantiate the COBSTRUCT object and invoke the COBDATA Method of it. As your COBOL apparently doesn't support OO this may be difficult for you. (It's not impossible but you have to go "round the houses...") If you can't get the code to compile on your platform why not simply rebuild it in your own environment? It is only COBOL...and you have the source. If you extract the separate methods in the OO version you could put them together, either as nested programs, or even as PERFORMED routines under a main control loop. This way you can compile it step by step and get something that runs native on your platform. I'm suggesting you use the OO version for re-construction because it has had amendments and enhancements applied to it. (For example, I extended Robert's code to support up to 1000 datanames instead of 250...) > > Am doing tjhis because it's critical for the software package I'm > working on and my own version of same is/was giving me so much trouble > with OCCURS and REDEFINES that I decided to try cobdata. I understand. Parsing (correctly) and dealing with COBOL record definitions is not easy, largely because of REDEFINES and OCCURS, but sometimes group fields can be problematic also. COBDATA correctly does this, even on very complex definitions, and every time I have thought I had a case where it got it wrong, it was actually correct, PROVIDED the COBOL was correct... obviously, invalid REDEFINEs and OCCURS will not guarantee a correct result from COBDATA. Since it was released I have come to trust this program and it is used in some of my applications every day. Yesterday I used the standalone version of it it on a COBOL definition with 500 datanames in it and 24 REDEFINES. It worked correctly. I believe the code is good and Robert did a good job with a difficult task. > If it's of > any interest I planned to include it as part of my product when it > goes to market. That's fine and doesn't violate the Licence. Good luck with your project. Pete. <unreferenced previous snipped> -- "I used to write COBOL...now I can do anything."
From: William M. Klein on 4 Dec 2009 00:21 Pete, Graham, et al, In my spare time, I might try and convert the existing code to an ANSI'85 conforming source prgoram. I don't think it uses anything that couldn't be done that way. I'll put this on my "wish list" of things to do. Having such source should make the source even MORE portable. "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message news:7notr2F3mph8kU1(a)mid.individual.net... > Graham Hobbs wrote: >> Pete, >> >> Your 'emphatic' mods didn't compile and when I jerked them around, >> didn't work. > > Well, I asked you to let me know and you did... :-) > > I'm sorry. > > Without knowing the precise nature of the jerking, or what your compiler > said about it, I can't help further. > >> I would post what happened but is all getting a bit >> heavy. I will look at the program, pity its not documented. > > It is written in procedural COBOL. Some people argue that is > "self-documenting"...:-) > > I managed to maintain it without real difficulty (once I got my head > around the style). > >> >> Might there be a cobdata executable somewhere that runs on a Windows >> XP box I could try? > > Yes, there is. I said as much. > > There are two executables: > > 1. The application wrapped in C#, as downloadable from cobol21. This is a > complete, standalone application. You can present your record definition > on the system clipboard or from a local sequential file, and the output is > written to a sequential file in the local directory. > > Have you tried this? (You will need a .NET platform installed, in order to > run it. The install will get it for you if it doesn't find it.) > > 2. A COM .dll which can be called from any language which supports the > Component Object Model. So far people have used it from Fujitsu COBOL, > VB.Net and C++, all running on the XP platform. This has no user interface > and expects the input to be in a local sequential file. You must > instantiate the COBSTRUCT object and invoke the COBDATA Method of it. As > your COBOL apparently doesn't support OO this may be difficult for you. > (It's not impossible but you have to go "round the houses...") > > If you can't get the code to compile on your platform why not simply > rebuild it in your own environment? It is only COBOL...and you have the > source. If you extract the separate methods in the OO version you could > put them together, either as nested programs, or even as PERFORMED > routines under a main control loop. This way you can compile it step by > step and get something that runs native on your platform. I'm suggesting > you use the OO version for re-construction because it has had amendments > and enhancements applied to it. (For example, I extended Robert's code to > support up to 1000 datanames instead of 250...) > >> >> Am doing tjhis because it's critical for the software package I'm >> working on and my own version of same is/was giving me so much trouble >> with OCCURS and REDEFINES that I decided to try cobdata. > > I understand. Parsing (correctly) and dealing with COBOL record > definitions is not easy, largely because of REDEFINES and OCCURS, but > sometimes group fields can be problematic also. COBDATA correctly does > this, even on very complex definitions, and every time I have thought I > had a case where it got it wrong, it was actually correct, PROVIDED the > COBOL was correct... obviously, invalid REDEFINEs and OCCURS will not > guarantee a correct result from COBDATA. > > Since it was released I have come to trust this program and it is used in > some of my applications every day. Yesterday I used the standalone version > of it it on a COBOL definition with 500 datanames in it and 24 REDEFINES. > It worked correctly. > > I believe the code is good and Robert did a good job with a difficult > task. > > >> If it's of >> any interest I planned to include it as part of my product when it >> goes to market. > > That's fine and doesn't violate the Licence. > > Good luck with your project. > > Pete. > > <unreferenced previous snipped> > > -- > "I used to write COBOL...now I can do anything." >
From: Pete Dashwood on 4 Dec 2009 06:48 William M. Klein wrote: > Pete, Graham, et al, > In my spare time, I might try and convert the existing code to an > ANSI'85 conforming source prgoram. I don't think it uses anything > that couldn't be done that way. > I'm quite sure it doesn't. I'd do it myself but Idon't have the time or, really, the inclination. I was hoping to get another "freebie" up on cobol21, which a couple of people have requested through private mail, but I haven't had time to do that either. Enhancements and extensions to the PRIMA Migration Toolset are taking all my time at the moment. Coincidentally, I added internal use of COBDATA to the Toolset yesterday. (It was needed to establish the size of certain records and the offset and length of their primary key fields, for a process called "bagging" which is needed when a very large COBOL definition would result in creation of a RDB table which exceeds the limit for the RDBMS being used.) I can confirm that the COBOL COM .DLL works perfectly from C#. It is an added reference to a C# project and 2 lines of code (excluding comments) as follows: // create an instance of the COBDATA COM component... COBSTRUCT.COBSTRUCTClass objCobstruct = new COBSTRUCT.COBSTRUCTClass(); objCobstruct.COBDATA(); // invoke the COBDATA method of the COM Class The equivalent action in (Fujitsu) OO COBOL would be as follows: REPOSITORY. *COM as COM. *> Sets up the Fujitsu COM interface Class WORKING-STORAGE. 01 COM-prog-ID pic x(21) value "COBSTRUCT.COBSTRUCT.1". 01 objCobstruct OBJECT REFERENCE COM. PROCEDURE DIVISION. *> create an instance of the COBDATA COM component... invoke COM "CREATE-OBJECT" USING COM-prog-ID RETURNING objCobstruct end-invoke *> invoke the COBDATA method... invoke objCobstruct "COBDATA" end-invoke (10 lines of code excluding comments and headers, scattered all over the program, and with no IntelliSense guidance from the Fujitsu IDE...) You can start to understand why people don't write OO COBOL. (Once you understand what is going on it is much quicker and cleaner to write in a modern language. Like I said before, you CAN do it in COBOL , but why would you...?) In both cases, I have not shown error trapping and exception processing, which I would certainly add to the real thing. In the real code I have wrapped it in a TRY... CATCH block in case there is a problem with instantiating it, but it has performed well in test, instantiating and running the published COBOL code under .NET InterOP Services without any problem at all. Using objects in C# is REALLY simple and easy and IntelliSense in Visual Studio shows all the methods and properties available in the Class, automatically. I see this as a very good example for NOT discarding or rewriting COBOL. It works fine... why rewrite it? Just refactor it and continue using it. > I'll put this on my "wish list" of things to do. Having such source > should make the source even MORE portable. That would be great, Bill. If you manage to get around to doing this, please let me have the final source and I'll add it to the download package on cobol21. Will make sure you are appropriately acknowledged. Cheers, Pete. -- "I used to write COBOL...now I can do anything."
From: Richard on 4 Dec 2009 13:15 On Dec 5, 12:48 am, "Pete Dashwood" <dashw...(a)removethis.enternet.co.nz> wrote: > William M. Klein wrote: > > Pete, Graham, et al, > > In my spare time, I might try and convert the existing code to an > > ANSI'85 conforming source prgoram. I don't think it uses anything > > that couldn't be done that way. > > I'm quite sure it doesn't. I'd do it myself but Idon't have the time or, > really, the inclination. > > I was hoping to get another "freebie" up on cobol21, which a couple of > people have requested through private mail, but I haven't had time to do > that either. Enhancements and extensions to the PRIMA Migration Toolset are > taking all my time at the moment. Coincidentally, I added internal use of > COBDATA to the Toolset yesterday. (It was needed to establish the size of > certain records and the offset and length of their primary key fields, for a > process called "bagging" which is needed when a very large COBOL definition > would result in creation of a RDB table which exceeds the limit for the > RDBMS being used.) I can confirm that the COBOL COM .DLL works perfectly > from C#. > > It is an added reference to a C# project and 2 lines of code (excluding > comments) as follows: > > // create an instance of the COBDATA COM component... > COBSTRUCT.COBSTRUCTClass objCobstruct = new COBSTRUCT.COBSTRUCTClass(); > objCobstruct.COBDATA(); // invoke the COBDATA method of the COM Class > > The equivalent action in (Fujitsu) OO COBOL would be as follows: > > REPOSITORY. > > *COM as COM. *> Sets up the Fujitsu COM interface Class > > WORKING-STORAGE. > 01 COM-prog-ID pic x(21) value "COBSTRUCT.COBSTRUCT.1". > 01 objCobstruct OBJECT REFERENCE COM. > > PROCEDURE DIVISION. > > *> create an instance of the COBDATA COM component... > invoke COM "CREATE-OBJECT" > USING COM-prog-ID > RETURNING objCobstruct > end-invoke > *> invoke the COBDATA method... > invoke objCobstruct "COBDATA" > end-invoke > > (10 lines of code excluding comments and headers, scattered all over the > program, and with no IntelliSense guidance from the Fujitsu IDE...) > You are being entirely disengenuous. The lines are not 'scattered all over', they are in clearly defined places. The Repository is equivalent to the 'include' or 'using' lines in C# which would normally be counted. The end-invokes are only required when the invoke is a conditional statement, such as having an 'on exception'. As you say you had a TRY and CATCH but didn't count those though you did count the 'catch' terminator in Cobol. The C# would also have to be in a public class foo { > You can start to understand why people don't write OO COBOL. (Once you > understand what is going on it is much quicker and cleaner to write in a > modern language. Like I said before, you CAN do it in COBOL , but why would > you...?) > > In both cases, I have not shown error trapping and exception processing, > which I would certainly add to the real thing. > > In the real code I have wrapped it in a TRY... CATCH block in case there is > a problem with instantiating it, but it has performed well in test, > instantiating and running the published COBOL code under .NET InterOP > Services without any problem at all. > > Using objects in C# is REALLY simple and easy and IntelliSense in Visual > Studio shows all the methods and properties available in the Class, > automatically. > > I see this as a very good example for NOT discarding or rewriting COBOL. It > works fine... why rewrite it? Just refactor it and continue using it. > > > I'll put this on my "wish list" of things to do. Having such source > > should make the source even MORE portable. > > That would be great, Bill. If you manage to get around to doing this, please > let me have the final source and I'll add it to the download package on > cobol21. Will make sure you are appropriately acknowledged. > > Cheers, > > Pete. > -- > "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 4 Dec 2009 18:37
Richard wrote: > On Dec 5, 12:48 am, "Pete Dashwood" > <dashw...(a)removethis.enternet.co.nz> wrote: >> William M. Klein wrote: >>> Pete, Graham, et al, >>> In my spare time, I might try and convert the existing code to an >>> ANSI'85 conforming source prgoram. I don't think it uses anything >>> that couldn't be done that way. >> >> I'm quite sure it doesn't. I'd do it myself but Idon't have the time >> or, really, the inclination. >> >> I was hoping to get another "freebie" up on cobol21, which a couple >> of people have requested through private mail, but I haven't had >> time to do that either. Enhancements and extensions to the PRIMA >> Migration Toolset are taking all my time at the moment. >> Coincidentally, I added internal use of COBDATA to the Toolset >> yesterday. (It was needed to establish the size of certain records >> and the offset and length of their primary key fields, for a process >> called "bagging" which is needed when a very large COBOL definition >> would result in creation of a RDB table which exceeds the limit for >> the RDBMS being used.) I can confirm that the COBOL COM .DLL works >> perfectly from C#. >> >> It is an added reference to a C# project and 2 lines of code >> (excluding comments) as follows: >> >> // create an instance of the COBDATA COM component... >> COBSTRUCT.COBSTRUCTClass objCobstruct = new >> COBSTRUCT.COBSTRUCTClass(); objCobstruct.COBDATA(); // invoke the >> COBDATA method of the COM Class >> >> The equivalent action in (Fujitsu) OO COBOL would be as follows: >> >> REPOSITORY. >> >> *COM as COM. *> Sets up the Fujitsu COM interface Class >> >> WORKING-STORAGE. >> 01 COM-prog-ID pic x(21) value "COBSTRUCT.COBSTRUCT.1". >> 01 objCobstruct OBJECT REFERENCE COM. >> >> PROCEDURE DIVISION. >> >> *> create an instance of the COBDATA COM component... >> invoke COM "CREATE-OBJECT" >> USING COM-prog-ID >> RETURNING objCobstruct >> end-invoke >> *> invoke the COBDATA method... >> invoke objCobstruct "COBDATA" >> end-invoke >> >> (10 lines of code excluding comments and headers, scattered all over >> the program, and with no IntelliSense guidance from the Fujitsu >> IDE...) >> > > You are being entirely disengenuous. > > The lines are not 'scattered all over', they are in clearly defined > places. They require switching backwards and forwards to reference and check them. Particularly as the IDE won't check spelling or references. There is no such requirement with the C# code. >The Repository is equivalent to the 'include' or 'using' lines > in C# which would normally be counted. No, it isn't. And I stated there was a reference line excluded from the count. The reference line generates the using so it doesn't need to be counted twice. > > The end-invokes are only required when the invoke is a conditional > statement, such as having an 'on exception'. As you say you had a TRY > and CATCH but didn't count those though you did count the 'catch' > terminator in Cobol. There was no ON EXCEPTION clause shown in the code (although there would be in the real thing). I use scope delimiters as a matter of good programming practice (so do many experienced COBOL programmers) whether they are "required" or not. My point was that it is much easier to write the functionality in C# than it is in COBOL, notwithstanding the number of lines. There is nothing disingenuous or misleading in my examples. > > The C# would also have to be in a > > public class foo > { > And the COBOL has to be in a program or Class with a PROGRAM-ID. I believe that must be taken as read and cancels out. > > >> You can start to understand why people don't write OO COBOL. (Once >> you understand what is going on it is much quicker and cleaner to >> write in a modern language. Like I said before, you CAN do it in >> COBOL , but why would you...?) >> >> In both cases, I have not shown error trapping and exception >> processing, which I would certainly add to the real thing. >> >> In the real code I have wrapped it in a TRY... CATCH block in case >> there is a problem with instantiating it, but it has performed well >> in test, instantiating and running the published COBOL code under >> .NET InterOP Services without any problem at all. >> >> Using objects in C# is REALLY simple and easy and IntelliSense in >> Visual Studio shows all the methods and properties available in the >> Class, automatically. The para above sums up my argument; it isn't really about lines of code (although no matter how you write it, COBOL loses on that count, too). It really comes down to what people are used to and comfortable with. (You should be the last person I need to remind of that...) Once the "familiarity" barrier is broken and people understand the use of objects and layers and how they are implemented in modern languages, it is really a no brainer. I wrote OO COBOL for over a decade and thought it was fine. Now I realize that C# is simply better. (So is Java, and even VB.NET is quicker to write than COBOL.) It isn't necessarily a contest... some people will never want to take the steps they would need to in order to break away from COBOL, and some people will be happy to continue using COBOL as long as it serves their needs. I don't think they are "wrong". All I'm doing here is showing my own experience and encouraging people who might be contemplating a move... Pete. -- "I used to write COBOL...now I can do anything." |