 OpenCOBOL Forum Index OpenCOBOL
Easter rabbit. | Register To Post |
| Threaded | Newest First | Previous Topic | Next Topic | Bottom |
| Poster | Thread |
|---|---|
| marcellom | Posted on: 2012/3/29 18:52 |
Quite a regular   Joined: 2006/1/4 From: Italy Posts: 62 |
Easter rabbit. Hi,
Santa Claus brought nothing. Easter Rabbit has empty hands. Shall we conclude that 1.1 is not the latest but the last version? Marcellom |
| jcurrey | Posted on: 2012/3/30 12:15 |
Home away from home  Joined: 2009/3/19 From: Texas Posts: 181 |
Re: Easter rabbit. Marcello,
What is it that you need OpenCOBOL to do that it does not do now? Is your concern about longevity? Are there features that you need to make your programming less time consuming? jimc |
| mrcool | Posted on: 2012/3/30 18:45 |
Quite a regular Joined: 2009/1/28 From: Posts: 44 |
Re: Easter rabbit. I'm satisfied that OpenCobol 1.1 handles all of ANSI Cobol-85 very well. I've run extensive tests. Then I did a file compare of over 100,000 output lines with previous tests run in MF and AcuCobol. I was surprised that they were all identical except for the few tests that had a date and time stamp within the data. Thanks for that. I'm impressed.
I don't know about Marcello, but for me I can't use 1.1 because there is a defect in the Accept statement using absolute cursor positioning (Accept ws-txt line x position y). For one, it prompts with spaces when no prompting is specified. It erases my screen when it should not. If I just press return, it should accept whatever was displayed there with the previous Display statement. For another, the function keys F1 through F5 work ok, but the rest go haywire. I can't use OC until these issues are fixed. Sure, I could fix them myself. But then I'd be working on a fork of 1.1. When 2.0 comes out, all of my work would be wasted. Please release 2.0. If I have to fix it, I want to work on something that will not fork out of existence. |
| jcurrey | Posted on: 2012/3/30 20:33 |
Home away from home Joined: 2009/3/19 From: Texas Posts: 181 |
Re: Easter rabbit. @Mrcool
Yes, We never did use the SCREEN SECTION or fancy ACCEPTS and DISPLAYS (COBOL68 did not support them). We did write a routine that simulates an HP2645 terminal (block mode). Did accepts one character at a time with the help of a very small c program. I doubt that it would help but you are welcome to it. jimc |
| marcellom | Posted on: 2012/4/2 10:33 |
Quite a regular Joined: 2006/1/4 From: Italy Posts: 62 |
Re: Easter rabbit. Hi Jim.
Please see "Santa Claus". 1) split-keys missing. A work-around is proposed but not really working. As you can see, you cannot avoid using real split-keys. You cannot even use mysql as OC 1.1 does not allow handling so many fields. 2) MF support is asserted to work but, as an esample, "invalid key" still gives compiling error. 3) We were promised a full current ANSI support (see NIST matter). 4) Nested copy does not work. 5) Someone spoke as Roger's voice ( some months ago) and said work was in progress. No further new! From time to time someone comes and asks if OC is totally working in real environment and someone answers with usual Nagasaki prefecture. They probably try converting a few programs and then disappear. I spent months with OC but I still have not what I need, no matter what I try. OC 1.1 does a lot, but a "quid" is still missing and that quid is critical. Cheers, Marcellom |
| jgt | Posted on: 2012/4/2 14:06 |
Just can't stay away  Joined: 2010/1/18 From: 44.21.48N 80.50.15W Posts: 76 |
Re: Easter rabbit. Quote:
As you can see, you cannot avoid using real split-keys. Why not just duplicate the split key fields at the end of the record in the correct order so that it is no longer split. |
| human | Posted on: 2012/4/3 7:07 |
Home away from home Joined: 2007/5/15 From: GERMANY Posts: 1416 |
Re: Easter rabbit. Quote:
That's the way all OC users I know of that work with ISAM solved this issue. OK, it's definitely not a solve but a workaround. Real split keys would be nice (and I thought someone was working on a patch for OC 1.1 to implement them), but as it is working that way... human |
| marcellom | Posted on: 2012/4/3 9:44 |
Quite a regular Joined: 2006/1/4 From: Italy Posts: 62 |
Re: Easter rabbit. Hi,
just because the same field is present in more than one duplicated key and cobol does not allow duplicated field-names inside a record. I know someone is working on it (the news is several months old) but so far ..... And so is for all other topics I high-lighted, but, so far 1.1 is still pre-release and it has been so for years. Marcellom |
| federico | Posted on: 2012/4/3 17:16 |
Home away from home Joined: 2010/2/7 From: Posts: 220 |
Re: Easter rabbit. I also think that (actual) solution could be code the split key adding them at the end of the record and managing them using the reference group name.
And compiling way a pre-processor to add the changed cobol into the cobol.. looking at move and write and rewrite statements with inline code. These changes could be made also using a macro with strong editor.. But I think you could solve this..of course as human told not a really solution.. but more a workaround.. Federico |
| jcurrey | Posted on: 2012/4/3 20:59 |
Home away from home Joined: 2009/3/19 From: Texas Posts: 181 |
Re: Easter rabbit. @marcellom
I understand and respect your position. Some things need to be clarified however. "You cannot even use mysql as OC 1.1 does not allow handling so many fields." "From time to time someone comes and asks if OC is totally working in real environment and someone answers with usual Nagasaki prefecture. They probably try converting a few programs and then disappear." I wrote my first Cobol program in 1969. I have never had a compiler that implemented everything that I wanted. OpenCOBOL is no exception. |
| (1) 2 3 » | |
| Threaded | Newest First | Previous Topic | Next Topic | Top |
| Register To Post | |
