My COBDATA problem
in [Cobol]
|
Prev: "Climategate" code
Next: IS NUMERIC check for SPACES
From: Graham Hobbs on 29 Nov 2009 20:43 Pete, Here is an extract from my COBDATA download. To me it looks like it shouldn't compile.. .. data division . file section . fd input-file . 01 input-record pic x(256) . 01 input-card. . 05 columns-1-6 pic x(06) . 05 columns-7-72 . etc ... because the '01 input-card.' stmt is followed on the next line by another period (full stop) in col 2. Does such compile under Fujitsu or Microfocus (F/MF hereafter)? In my cosmetizing of COBDATA to get to the 'old-fashioned' IBM format I dropped such a second period (several times). EXIT PERFORM only appears once in COBDATA. Your EXIT PERFORM replacement code failed because there is no 'line-in' field, changing it to line-byte then gave a subscript error - so I noted your comments about likely later usage of the value in 'n' and reprogrammed as follows (091130 are added lines) .. 091130 COMPUTE SAVE-N = ZERO MOVE ZERO TO LINE-LENGTH PERFORM VARYING N FROM 1 BY 1 UNTIL N GREATER THAN LINE-LIMIT IF LINE-BYTE (N) EQUAL TO '*' AND N LESS THAN LINE-LENGTH AND LINE-BYTE (N + 1) EQUAL TO '>' * EXIT PERFORM 091130 COMPUTE SAVE-N = N + 1 091130 COMPUTE N = LINE-LIMIT + 1 END-IF 091130 IF SAVE-N = ZERO IF LINE-BYTE (N) NOT EQUAL TO SPACE MOVE N TO LINE-LENGTH END-IF 091130 END-IF END-PERFORM 091130 COMPUTE N = SAVE-N - 1 ... is logically the same as the original code but it still didn't work, same non results. Could I suggest with your approval ... I send to you my IBM rendition of COBDATA with the code change described above - it compiles with IBM's RDz compiler. If you compile it and test with F/MF and if it worked you'd have COBDATA that works for F/MF and IBM - future changes would then consider all three compilers. If it doesnt work somebody would have to look at the IBM version and figure out whats going on:-(. Possible that none of the 121 downloaders are IBM'ers. Graham PS. About the filename - what I changed was.. from select input-file assign to 'c:\cobdata.in' to select input-file assign to cobdatai so I can use different copybooks in a CMD file without recompiling the program. PPs. Since it compiles am assuming nested pgms are supported. --- --- On Sun, 29 Nov 2009 22:45:06 +1300, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: >Sorry about blank response, finger trouble. > >Some qick coments below... > >Graham Hobbs wrote: >> Hello, >> >> Today I downloaded the COBDATA COBOL source code and compiled it on my >> Windows XP machine using the IBM compiler that is part of Rational >> Developer for System z. I had to make many cosmetic changes, split the >> text of several lines, do one logic change because of EXIT PERFORM, >> and changed the input file to cobdatai. > >I'm not familair with this version of COBOL but am interested to know why a >file name needed to be changed...? > >> >> It ran to conclusion but didn't seem to work too well:-(. >> >> ----------------------- >> My input CMD file was: >> ----------------------- >> set cobdatai=c:\copylibg\w06403.cbl >> cobdata >> >> ---------------------- >> Where the copybook w06403 contains: >> --------------------- >> 01 WS-F06403-REC. >> 05 WS-CSTMR-NBR PIC X(8). >> 05 WS-CSTMR-MOP14-INFO. >> 10 WS-CSTMR-NAME PIC X(30). >> 10 WS-CSTMR-ADR1 PIC X(32). >> etc >> > >That looks OK... > >> ---------------------- >> and the output was: >> ---------------------- >> LVL NAME POS LEN TYP OC >> 1 01 - 1 >> 2 05 - 1 >> 3 05 - 1 >> 4 10 - 1 >> 5 10 - 1 >> etc > >That certainly doesn't... :-) >> >> ------------------------- >> and the logic change (091128's) I made was: >> ------------------------- >> PERFORM VARYING N FROM 1 BY 1 UNTIL N GREATER THAN >> LINE-LIMIT >> IF LINE-BYTE (N) EQUAL TO '*' AND >> N LESS THAN LINE-LENGTH AND >> LINE-BYTE (N + 1) EQUAL TO '>' >> 091128* EXIT PERFORM >> 091128 COMPUTE N = LINE-LIMIT + 1 > >I think you need to save the value of N before you increment it to cause the >exit perform. > >It's a long time since I looked at the code but I'm pretty sure it will use >the value of N later on. > > > >> END-IF >> 091128 IF N NOT > LINE-LIMIT >> IF LINE-BYTE (N) NOT EQUAL TO SPACE >> MOVE N TO LINE-LENGTH >> END-IF >> 091128 END-IF >> END-PERFORM >> ------------------------------ >> >> Is there something obvious I've missed or must I do a complete desk >> check of all the cometic changes I made (not because I enjoyed it, but >> because I got so many errors with my compiler that it seemed like the >> thing to do). > >Without seeing the kind of errors it threw and whether they are knock-ons or >serious, it is hard to advise. > >Obviously, you have needed to chage the code to make it run on your >platform. Somewhere along the way, errors have been introduced. > >So it would seem that a check on the changes made might be in order... > >Faced with converting it to run on your platform here's what I would do: > >1. Check that nested programs are supported in your environment. >2. Compile it and try and establish exactly WHICH constructs it uses which >are problematic. For example, you know that EXIT PERFORM is not supported so >you chose to get the same effect by incrementing the control variable beyond >the limit. Fair enough, but if that variable is used and expected to contain >something important (like the length of the string being processed) then >this will be disastrous. Find all the EXIT PERFORMS and make sure that in >each case, you save the controlling variable before you increment it to >cause exit. However even this does not duplicate the action of an EXIT >PERFORM because control is transferred to the action following the PERFORM >and nothing within the range of the PERFORM is executed. Your "equivalent >code" needs to check the condition again before it can exit. > >So, if it were me, I'd be looking for a way of coding an EXACT equivalent to >the unsupported verb, and I'd TRY to use that consistently throughout the >program (especially if I wasn't absolutely sure of what the code was trying >to do...) > >In the case above I believe the code is trying to establish the length of >the input line, discarding *> and what follows that, as it is not interested >in comments. (It may be that your compiler does not support *> as an >embedded comment for COBOL and that would cause a large number of compile >errors if the COBDATA code uses this...) > >There is a function in Fujitsu COBOL that will return the effective length >of a string, but I think that Robert was either not aware of this or >deliberately didn't use it, to try and keep some compatibility. Anyway, what >you need to do is to set N to the length of the effective string terminated >by *> or all blanks > >Here's something that SHOULD give you what you need and you could replace >the whole complex PERFORM and its range with these lines... > >MOVE ZERO TO N >INSPECT LINE-IN > TALLYING N > FOR ALL "*>" >IF N = ZERO > INSPECT LINE-IN > TALLYING N > FOR ALL CHARACTERS BEFORE ALL SPACE >ELSE > MOVE ZERO TO N > INSPECT LINE-IN > TALLYING N > FOR ALL CHARACTERS BEFORE "*>" >END-IF > >... then carry on with the statement which currently follows the >END-PERFORM. > > >> Is there anybody else who has changed COBDATA to run with an IBM >> compiler? > >121 people have downloaded the COBDATA Tool. I don't know how many are using >it on IBM sites. > >I know some of them have integrated the source into their own tools and use >it in ways neither Robert nor myself imagined when we undertook to publish >it. (One imaginative use I know of is using it to drive access to >"undefined" COBOL data on a RDB, providing offsets and lengths of fields in >COBOL records for languages like VB...) > >There have been 4 errors reported in it and these have been fixed. The last >error was reported several months ago. > >I have also had some requests for the code as a COM .DLL (which I have >gladly acceded to) so it can be called from a Web Page. > >If you are unable to get it working, Graham, lease let me know. > >If you DO get it working please send me the source code so I can post it for >anyone else who may be using the same platform. > >Cheers, > >Pete.
From: Pete Dashwood on 29 Nov 2009 22:24 Graham Hobbs wrote: > Pete, > > Here is an extract from my COBDATA download. To me it looks like it > shouldn't compile.. > > . data division > . file section > . fd input-file > . 01 input-record pic x(256) > . 01 input-card. > . 05 columns-1-6 pic x(06) > . 05 columns-7-72 > . > etc > .. because the '01 input-card.' stmt is followed on the next line by > another period (full stop) in col 2. When I first saw the code it surprised me (I didn't write it, Robert Wagner did, although both of us have made amendments to it since, in co-operation) because it looked "strange"... However, this is just Robert's style. He is used to coding database procedures and the SQL style has carried into his COBOL. There's actually nothing wrong with it and it will compile OK on any COBOL platform because it is compliant with the standard. In places where you get a second full stop (as you queried) most compilers will ignore it. It is likely that I may have put the (unnecessary) full stop after "input-card" just from force of habit. Removing it (or the one following it...) should not affect anythng. > Does such compile under Fujitsu > or Microfocus (F/MF hereafter)? Yes, it does. >In my cosmetizing of COBDATA to get to > the 'old-fashioned' IBM format I dropped such a second period (several > times). My apologies. I wouldn't mind betting those were from amendments I made, rather than from Robert's original code. BTW, the "old-fashioned" code you refer to is simply fixed format COBOL. Robert chose to use free-format for COBDATA and he also ensured that definitions processed by it can be free or fixed format. > > EXIT PERFORM only appears once in COBDATA. Your EXIT PERFORM > replacement code failed because there is no 'line-in' field, I didn't go and check the actual code because it is on another machine than the one I am writing these posts from. I guessed at the name because the code was intended to show an approach... I knew the name might be wrong but was hoping you would fix it... :-) It is a pretty simple matter to change it to the group level of what is being read...see below. > changing > it to line-byte then gave a subscript error - so I noted your comments > about likely later usage of the value in 'n' and reprogrammed as > follows (091130 are added lines) .. > > 091130 COMPUTE SAVE-N = ZERO > MOVE ZERO TO LINE-LENGTH > PERFORM VARYING N FROM 1 BY 1 UNTIL N GREATER THAN > LINE-LIMIT > IF LINE-BYTE (N) EQUAL TO '*' AND > N LESS THAN LINE-LENGTH AND > LINE-BYTE (N + 1) EQUAL TO '>' > * EXIT PERFORM > 091130 COMPUTE SAVE-N = N + 1 > 091130 COMPUTE N = LINE-LIMIT + 1 > END-IF > 091130 IF SAVE-N = ZERO > IF LINE-BYTE (N) NOT EQUAL TO SPACE > MOVE N TO LINE-LENGTH > END-IF > 091130 END-IF > END-PERFORM > 091130 COMPUTE N = SAVE-N - 1 > > .. is logically the same as the original code but it still didn't > work, same non results. It's not "logically the same"... :-) (I'm not going to correct it here; look at it again...better still, just replace it :-)) I looked up the field that was incorrectly named. Try this: MOVE ZERO TO N INSPECT LINE-TEXT TALLYING N FOR ALL "*>" IF N = ZERO INSPECT LINE-TEXT TALLYING N FOR ALL CHARACTERS BEFORE ALL SPACE ELSE MOVE ZERO TO N INSPECT LINE-TEXT TALLYING N FOR ALL CHARACTERS BEFORE "*>" END-IF MOVE N TO LINE-LENGTH I would stress you must reproduce it EXACTLY as above... Unfortunately, even if you get this compiled it will still contain the errors that have since been fixed. You are working on the ORIGINAL code from Robert. I converted this to OO code (which was really the point of the exercise) and it was the OO code that was fixed. I did not retro fit the fixes back to the original Procedural COBOL code. Nevertheless, replacing the PERFORM with the above should get you a result. > > Could I suggest with your approval ... > I send to you my IBM rendition of COBDATA with the code change > described above - it compiles with IBM's RDz compiler. I'd be interested to have it with the new code above, if it works. > If you compile > it and test with F/MF and if it worked you'd have COBDATA that works > for F/MF and IBM - future changes would then consider all three > compilers. No they won't. I am only maintaining the OO version. If your RDz compiler supports OO I'd be very interested in getting it to compile the latest OO version. If it doesn't, then I'm sorry, it is of little interest to me. If you apply the changes above and it compiles and runs with a better result than you have been obtaining, I will gladly help you with the other fixes that need to be done, so you can have a bug free copy of Robert's original procedural code, but I simply don't have the time or inclination to get a procedural version running on a platform which no-one has ever expressed interest in before you. (And it kind of grinds my gears to be perpetuating a procedural solution... :-)) > If it doesnt work somebody would have to look at the IBM > version and figure out whats going on:-(. Yes, they would... I understand there are professionals around who get paid for doing that... :-) > > Possible that none of the 121 downloaders are IBM'ers. Indeed. I haven't polled them. Of course, there is nothing to stop an IBMer or ANYONE who has a compiler that can call COM objects, from calling the .DLL. I'll provide this .DLL to anyone who asks for it, if they are unable to compile their own from the OO version of the code. > > Graham > > PS. > About the filename - what I changed was.. > from select input-file assign to 'c:\cobdata.in' > to select input-file assign to cobdatai > so I can use different copybooks in a CMD file without recompiling > the program. Ah, I see... Thanks. > PPs. > Since it compiles am assuming nested pgms are supported. > --- Sounds fair...:-) <snipped previous > Graham, I have every sympathy and appreciate your interest in the tool. If I had nothing else to do, I'd gladly help you with this. But I really can't do much without having your platform available, and I honestly have much more pressing matters to attend to at the moment. (People paying for my time have to get priority; I'm sure you understand.) If there are other IBM RDz users here perhaps they can help. I will gladly assist where and when I can. The object of the exercise was to show that standard procedural COBOL can be fairly easily converted to OO COBOL and wrapped as a component. This component can then be used with C# or any other modern language so that useful COBOL functionality doesn't need to be discarded. The Tool executable is written in C# and provides the user interface and the ability to run the tool against data stored on the system clipboard (I find this very useful). It was never really about the COBDATA code. (In fact, the OO version renames it as COBSTRUCT). If the above suggested code replacement fails to work, let me know. Cheers, Pete. -- "I used to write COBOL...now I can do anything."
From: William M. Klein on 30 Nov 2009 00:39 Pete, IBM (on Windows or MVS) does NOT support "free style" format at all - and does sitll worry about A-/B-margin. It does NOT support inline comments at all. For an "easy" online reference (this is to the MVS version, but the RDz is similar), see: http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/Shelves/igy3sh50 FYI, It does support nested pgorams but minial OO (not Like MF or Fujitsu). BASICALLY, it is an '85 Standard compiler (with most IBM extensions). Try compiling your program with either MF or FuJitsu "ANSI'85" flagging on, and you will see what SHOULD work with RDz. (It does support Intrinsic Funcitons as well). Graham, If you shift everything over 7 columns, you will get further - but still have lots to worry about. Any time that you see, "*>" followed by text, put a "line break" before the "*" and move the "*" to column 7. "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message news:7ngs6tF3m16tgU1(a)mid.individual.net... > Graham Hobbs wrote: >> Pete, >> >> Here is an extract from my COBDATA download. To me it looks like it >> shouldn't compile.. >> >> . data division >> . file section >> . fd input-file >> . 01 input-record pic x(256) >> . 01 input-card. >> . 05 columns-1-6 pic x(06) >> . 05 columns-7-72 >> . >> etc >> .. because the '01 input-card.' stmt is followed on the next line by >> another period (full stop) in col 2. > > When I first saw the code it surprised me (I didn't write it, Robert > Wagner did, although both of us have made amendments to it since, in > co-operation) because it looked "strange"... > > However, this is just Robert's style. He is used to coding database > procedures and the SQL style has carried into his COBOL. There's actually > nothing wrong with it and it will compile OK on any COBOL platform because > it is compliant with the standard. > In places where you get a second full stop (as you queried) most compilers > will ignore it. > > It is likely that I may have put the (unnecessary) full stop after > "input-card" just from force of habit. Removing it (or the one following > it...) should not affect anythng. > > > >> Does such compile under Fujitsu >> or Microfocus (F/MF hereafter)? > > Yes, it does. > > >>In my cosmetizing of COBDATA to get to >> the 'old-fashioned' IBM format I dropped such a second period (several >> times). > > My apologies. I wouldn't mind betting those were from amendments I made, > rather than from Robert's original code. > > BTW, the "old-fashioned" code you refer to is simply fixed format COBOL. > Robert chose to use free-format for COBDATA and he also ensured that > definitions processed by it can be free or fixed format. > >> >> EXIT PERFORM only appears once in COBDATA. Your EXIT PERFORM >> replacement code failed because there is no 'line-in' field, > > I didn't go and check the actual code because it is on another machine > than the one I am writing these posts from. I guessed at the name because > the code was intended to show an approach... I knew the name might be > wrong but was hoping you would fix it... :-) It is a pretty simple matter > to change it to the group level of what is being read...see below. > > >> changing >> it to line-byte then gave a subscript error - so I noted your comments >> about likely later usage of the value in 'n' and reprogrammed as >> follows (091130 are added lines) .. >> >> 091130 COMPUTE SAVE-N = ZERO >> MOVE ZERO TO LINE-LENGTH >> PERFORM VARYING N FROM 1 BY 1 UNTIL N GREATER THAN >> LINE-LIMIT >> IF LINE-BYTE (N) EQUAL TO '*' AND >> N LESS THAN LINE-LENGTH AND >> LINE-BYTE (N + 1) EQUAL TO '>' >> * EXIT PERFORM >> 091130 COMPUTE SAVE-N = N + 1 >> 091130 COMPUTE N = LINE-LIMIT + 1 >> END-IF >> 091130 IF SAVE-N = ZERO >> IF LINE-BYTE (N) NOT EQUAL TO SPACE >> MOVE N TO LINE-LENGTH >> END-IF >> 091130 END-IF >> END-PERFORM >> 091130 COMPUTE N = SAVE-N - 1 >> >> .. is logically the same as the original code but it still didn't >> work, same non results. > > It's not "logically the same"... :-) (I'm not going to correct it here; > look at it again...better still, just replace it :-)) > > I looked up the field that was incorrectly named. Try this: > > MOVE ZERO TO N > INSPECT LINE-TEXT > TALLYING N > FOR ALL "*>" > IF N = ZERO > INSPECT LINE-TEXT > TALLYING N > FOR ALL CHARACTERS BEFORE ALL SPACE > ELSE > MOVE ZERO TO N > INSPECT LINE-TEXT > TALLYING N > FOR ALL CHARACTERS BEFORE "*>" > END-IF > MOVE N TO LINE-LENGTH > > I would stress you must reproduce it EXACTLY as above... > > Unfortunately, even if you get this compiled it will still contain the > errors that have since been fixed. You are working on the ORIGINAL code > from Robert. I converted this to OO code (which was really the point of > the exercise) and it was the OO code that was fixed. I did not retro fit > the fixes back to the original Procedural COBOL code. > > Nevertheless, replacing the PERFORM with the above should get you a > result. > >> >> Could I suggest with your approval ... >> I send to you my IBM rendition of COBDATA with the code change >> described above - it compiles with IBM's RDz compiler. > > I'd be interested to have it with the new code above, if it works. > > > >> If you compile >> it and test with F/MF and if it worked you'd have COBDATA that works >> for F/MF and IBM - future changes would then consider all three >> compilers. > > No they won't. I am only maintaining the OO version. If your RDz compiler > supports OO I'd be very interested in getting it to compile the latest OO > version. If it doesn't, then I'm sorry, it is of little interest to me. > > If you apply the changes above and it compiles and runs with a better > result than you have been obtaining, I will gladly help you with the other > fixes that need to be done, so you can have a bug free copy of Robert's > original procedural code, but I simply don't have the time or inclination > to get a procedural version running on a platform which no-one has ever > expressed interest in before you. > > (And it kind of grinds my gears to be perpetuating a procedural > solution... :-)) > >> If it doesnt work somebody would have to look at the IBM >> version and figure out whats going on:-(. > > Yes, they would... I understand there are professionals around who get > paid for doing that... :-) >> >> Possible that none of the 121 downloaders are IBM'ers. > > Indeed. I haven't polled them. > > Of course, there is nothing to stop an IBMer or ANYONE who has a compiler > that can call COM objects, from calling the .DLL. I'll provide this .DLL > to anyone who asks for it, if they are unable to compile their own from > the OO version of the code. > >> >> Graham >> >> PS. >> About the filename - what I changed was.. >> from select input-file assign to 'c:\cobdata.in' >> to select input-file assign to cobdatai >> so I can use different copybooks in a CMD file without recompiling >> the program. > > Ah, I see... Thanks. > >> PPs. >> Since it compiles am assuming nested pgms are supported. >> --- > > Sounds fair...:-) > > <snipped previous > > > Graham, I have every sympathy and appreciate your interest in the tool. If > I had nothing else to do, I'd gladly help you with this. But I really > can't do much without having your platform available, and I honestly have > much more pressing matters to attend to at the moment. (People paying for > my time have to get priority; I'm sure you understand.) > > If there are other IBM RDz users here perhaps they can help. I will gladly > assist where and when I can. > > The object of the exercise was to show that standard procedural COBOL can > be fairly easily converted to OO COBOL and wrapped as a component. This > component can then be used with C# or any other modern language so that > useful COBOL functionality doesn't need to be discarded. The Tool > executable is written in C# and provides the user interface and the > ability to run the tool against data stored on the system clipboard (I > find this very useful). It was never really about the COBDATA code. (In > fact, the OO version renames it as COBSTRUCT). > > If the above suggested code replacement fails to work, let me know. > > Cheers, > > Pete. > -- > "I used to write COBOL...now I can do anything." >
From: Pete Dashwood on 30 Nov 2009 06:20 William M. Klein wrote: > Pete, > IBM (on Windows or MVS) does NOT support "free style" format at all > - and does sitll worry about A-/B-margin. It does NOT support inline > comments at all. Thanks Bill. I understood that it did. My bad. > > For an "easy" online reference (this is to the MVS version, but the > RDz is similar), see: > http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/Shelves/igy3sh50 OK, thanks again. > > FYI, > It does support nested pgorams but minial OO (not Like MF or > Fujitsu). BASICALLY, it is an '85 Standard compiler (with most IBM > extensions). Try compiling your program with either MF or FuJitsu > "ANSI'85" flagging on, and you will see what SHOULD work with RDz. (It > does support Intrinsic Funcitons as well). Well, I understood that Fujitsu defaulted to COBOL '85 and so I thought that what worked must be COBOL '85. I realise now they produced extensions to COBOL '85 which they call COBOL '97. I simply got it wrong. Thanks for the assistance. > > Graham, > If you shift everything over 7 columns, you will get further - but > still have lots to worry about. Any time that you see, > "*>" followed by text, put a "line break" before the "*" and move > the "*" to column 7. I made some changes to Robert's code because it wasn't handling line numbers properly. I'm not sure that moving things to the right won't cause more problems than it will fix, but I'm unable to devote time to it at the moment. Pete. -- "I used to write COBOL...now I can do anything."
From: Graham Hobbs on 2 Dec 2009 16:58
Pete, Your 'emphatic' mods didn't compile and when I jerked them around, didn't work. I would post what happened but is all getting a bit heavy. I will look at the program, pity its not documented. Might there be a cobdata executable somewhere that runs on a Windows XP box I could try? 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. If it's of any interest I planned to include it as part of my product when it goes to market. Graham --- On Mon, 30 Nov 2009 16:24:18 +1300, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: >Graham Hobbs wrote: >> Pete, >> >> Here is an extract from my COBDATA download. To me it looks like it >> shouldn't compile.. >> >> . data division >> . file section >> . fd input-file >> . 01 input-record pic x(256) >> . 01 input-card. >> . 05 columns-1-6 pic x(06) >> . 05 columns-7-72 >> . >> etc >> .. because the '01 input-card.' stmt is followed on the next line by >> another period (full stop) in col 2. > >When I first saw the code it surprised me (I didn't write it, Robert Wagner >did, although both of us have made amendments to it since, in co-operation) >because it looked "strange"... > >However, this is just Robert's style. He is used to coding database >procedures and the SQL style has carried into his COBOL. There's actually >nothing wrong with it and it will compile OK on any COBOL platform because >it is compliant with the standard. >In places where you get a second full stop (as you queried) most compilers >will ignore it. > >It is likely that I may have put the (unnecessary) full stop after >"input-card" just from force of habit. Removing it (or the one following >it...) should not affect anythng. > > > >> Does such compile under Fujitsu >> or Microfocus (F/MF hereafter)? > >Yes, it does. > > >>In my cosmetizing of COBDATA to get to >> the 'old-fashioned' IBM format I dropped such a second period (several >> times). > >My apologies. I wouldn't mind betting those were from amendments I made, >rather than from Robert's original code. > >BTW, the "old-fashioned" code you refer to is simply fixed format COBOL. >Robert chose to use free-format for COBDATA and he also ensured that >definitions processed by it can be free or fixed format. > >> >> EXIT PERFORM only appears once in COBDATA. Your EXIT PERFORM >> replacement code failed because there is no 'line-in' field, > >I didn't go and check the actual code because it is on another machine than >the one I am writing these posts from. I guessed at the name because the >code was intended to show an approach... I knew the name might be wrong but >was hoping you would fix it... :-) It is a pretty simple matter to change it >to the group level of what is being read...see below. > > >> changing >> it to line-byte then gave a subscript error - so I noted your comments >> about likely later usage of the value in 'n' and reprogrammed as >> follows (091130 are added lines) .. >> >> 091130 COMPUTE SAVE-N = ZERO >> MOVE ZERO TO LINE-LENGTH >> PERFORM VARYING N FROM 1 BY 1 UNTIL N GREATER THAN >> LINE-LIMIT >> IF LINE-BYTE (N) EQUAL TO '*' AND >> N LESS THAN LINE-LENGTH AND >> LINE-BYTE (N + 1) EQUAL TO '>' >> * EXIT PERFORM >> 091130 COMPUTE SAVE-N = N + 1 >> 091130 COMPUTE N = LINE-LIMIT + 1 >> END-IF >> 091130 IF SAVE-N = ZERO >> IF LINE-BYTE (N) NOT EQUAL TO SPACE >> MOVE N TO LINE-LENGTH >> END-IF >> 091130 END-IF >> END-PERFORM >> 091130 COMPUTE N = SAVE-N - 1 >> >> .. is logically the same as the original code but it still didn't >> work, same non results. > >It's not "logically the same"... :-) (I'm not going to correct it here; look >at it again...better still, just replace it :-)) > >I looked up the field that was incorrectly named. Try this: > >MOVE ZERO TO N >INSPECT LINE-TEXT > TALLYING N > FOR ALL "*>" >IF N = ZERO > INSPECT LINE-TEXT > TALLYING N > FOR ALL CHARACTERS BEFORE ALL SPACE >ELSE > MOVE ZERO TO N > INSPECT LINE-TEXT > TALLYING N > FOR ALL CHARACTERS BEFORE "*>" >END-IF >MOVE N TO LINE-LENGTH > >I would stress you must reproduce it EXACTLY as above... > >Unfortunately, even if you get this compiled it will still contain the >errors that have since been fixed. You are working on the ORIGINAL code from >Robert. I converted this to OO code (which was really the point of the >exercise) and it was the OO code that was fixed. I did not retro fit the >fixes back to the original Procedural COBOL code. > >Nevertheless, replacing the PERFORM with the above should get you a result. > >> >> Could I suggest with your approval ... >> I send to you my IBM rendition of COBDATA with the code change >> described above - it compiles with IBM's RDz compiler. > >I'd be interested to have it with the new code above, if it works. > > > >> If you compile >> it and test with F/MF and if it worked you'd have COBDATA that works >> for F/MF and IBM - future changes would then consider all three >> compilers. > >No they won't. I am only maintaining the OO version. If your RDz compiler >supports OO I'd be very interested in getting it to compile the latest OO >version. If it doesn't, then I'm sorry, it is of little interest to me. > >If you apply the changes above and it compiles and runs with a better result >than you have been obtaining, I will gladly help you with the other fixes >that need to be done, so you can have a bug free copy of Robert's original >procedural code, but I simply don't have the time or inclination to get a >procedural version running on a platform which no-one has ever expressed >interest in before you. > >(And it kind of grinds my gears to be perpetuating a procedural solution... >:-)) > >> If it doesnt work somebody would have to look at the IBM >> version and figure out whats going on:-(. > >Yes, they would... I understand there are professionals around who get paid >for doing that... :-) >> >> Possible that none of the 121 downloaders are IBM'ers. > >Indeed. I haven't polled them. > >Of course, there is nothing to stop an IBMer or ANYONE who has a compiler >that can call COM objects, from calling the .DLL. I'll provide this .DLL to >anyone who asks for it, if they are unable to compile their own from the OO >version of the code. > >> >> Graham >> >> PS. >> About the filename - what I changed was.. >> from select input-file assign to 'c:\cobdata.in' >> to select input-file assign to cobdatai >> so I can use different copybooks in a CMD file without recompiling >> the program. > >Ah, I see... Thanks. > >> PPs. >> Since it compiles am assuming nested pgms are supported. >> --- > >Sounds fair...:-) > ><snipped previous > > >Graham, I have every sympathy and appreciate your interest in the tool. If I >had nothing else to do, I'd gladly help you with this. But I really can't do >much without having your platform available, and I honestly have much more >pressing matters to attend to at the moment. (People paying for my time have >to get priority; I'm sure you understand.) > >If there are other IBM RDz users here perhaps they can help. I will gladly >assist where and when I can. > >The object of the exercise was to show that standard procedural COBOL can be >fairly easily converted to OO COBOL and wrapped as a component. This >component can then be used with C# or any other modern language so that >useful COBOL functionality doesn't need to be discarded. The Tool executable >is written in C# and provides the user interface and the ability to run the >tool against data stored on the system clipboard (I find this very useful). >It was never really about the COBDATA code. (In fact, the OO version renames >it as COBSTRUCT). > >If the above suggested code replacement fails to work, let me know. > >Cheers, > >Pete. |