My COBDATA problem
in [Cobol]
|
Prev: "Climategate" code
Next: IS NUMERIC check for SPACES
From: Graham Hobbs on 4 Dec 2009 20:19 Bill, I do hope your wish list is 'very very short':-). a) and b) below are what would suit my needs perfectly. I would RDz compile your source and have a working .exe - right, or download your ..exe? Same for the mainframe? .. so my ideal world ist: a) in a Windows CMD file .. set cobfilei=c:\conrad\f023mf.cbl set cobfileo=c:\conrad\f023mf.lst cobdata b) in an OS/JCL stream (if I remember my JCL) .. //step01 exec pgm=cobdata //cobfilei dd dsn=prodcopy.sitea(f023mf),disp=shr //cobfileo dd dsn=ghobbs.proj1.f023mf,disp=(new,catlg,del), etc // When I wrote my own 'cobdata' (mycobpgm, very frustrating and never adequately working), to check output validity I did this: with copybook abc.cbl as input I ran mycobpgm. Then I did 'copy abc.cbl' into a small pgm and the RDz compiler gave me 'length(displacement)' in its .lst file. Then used a REXX to compare the results - pretty infallible so long as you believe IBM:-). When the time comes I have dozens of complex assorted copybooks built especially to test mycobpgm if you're interested. A couple of other points I might mention. I would be interested in seeing additional info on each line produced e.g. is the item group/elementary, part of an occurs, part of a redefines, both - just part of my Christmas wish list:-). Incidentally it only took me 30 minutes or so to IBM'ize the source. You can have mine if you want. Graham --- On Thu, 3 Dec 2009 23:21:35 -0600, "William M. Klein" <wmklein(a)nospam.netcom.com> 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'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 5 Dec 2009 01:08 Graham Hobbs wrote: > Bill, > > I do hope your wish list is 'very very short':-). > > a) and b) below are what would suit my needs perfectly. I would RDz > compile your source and have a working .exe - right, or download your > .exe? Same for the mainframe? .. so my ideal world ist: > > a) in a Windows CMD file .. > > set cobfilei=c:\conrad\f023mf.cbl > set cobfileo=c:\conrad\f023mf.lst > cobdata > > b) in an OS/JCL stream (if I remember my JCL) .. > > //step01 exec pgm=cobdata > //cobfilei dd dsn=prodcopy.sitea(f023mf),disp=shr > //cobfileo dd dsn=ghobbs.proj1.f023mf,disp=(new,catlg,del), etc > // > > When I wrote my own 'cobdata' (mycobpgm, very frustrating and never > adequately working), to check output validity I did this: with > copybook abc.cbl as input I ran mycobpgm. Then I did 'copy abc.cbl' > into a small pgm and the RDz compiler gave me 'length(displacement)' > in its .lst file. Then used a REXX to compare the results - pretty > infallible so long as you believe IBM:-). When the time comes I have > dozens of complex assorted copybooks built especially to test mycobpgm > if you're interested. > > A couple of other points I might mention. I would be interested in > seeing additional info on each line produced e.g. is the item > group/elementary, part of an occurs, part of a redefines, both - just > part of my Christmas wish list:-). Those are provided in the current output of COBDATA. > > Incidentally it only took me 30 minutes or so to IBM'ize the source. > You can have mine if you want. Except that that is the "wrong" code...and it doesn't work :-) That code is intended purely for illustrative purposes. I already said it has bugs in it and it hasn't been maintained. (See the previous stuff below...) The OO version has. It is the OO version that should be "IBMized". This is a simple matter of taking the methods and either making them nested source programs, or PERFORMING them as SECTIONS of COBOL code from a standard control section or paragraph. At the same time the Data Divisions for the methods can be merged into one single Data Division. Hardly rocket science. The advantage of Bill doing it is that he has comprehensive knowledge of what is standard and what isn't, and he doesn't "jerk things around" when they don't work, preferring instead to understand what caused the problem and fix it... :-) > > Graham > --- > On Thu, 3 Dec 2009 23:21:35 -0600, "William M. Klein" > <wmklein(a)nospam.netcom.com> 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'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." Pete. -- "I used to write COBOL...now I can do anything."
From: Howard Brazee on 7 Dec 2009 10:28
On Sat, 5 Dec 2009 12:37:29 +1300, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: >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, Only one step is necessary - taken by their employers. -- "In no part of the constitution is more wisdom to be found, than in the clause which confides the question of war or peace to the legislature, and not to the executive department." - James Madison |