Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Register Log in
  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

A "better" COBOL. 7

Status
Not open for further replies.
tgreer

tgreer

Programmer
Oct 4, 2002
1,781
US
I've been asked to research finding a "better COBOL" for my company. I know that's subjective, so bear with me. We currently use CA-Realia Workbench 3.1.

We're in a Windows NT/2000/XP PC environment.

A short list of what "better" might mean:

- faster

- better file i/o (more on this later)

- COM/Automation/ActiveX

- .NET integration (maybe... we don't particularly care for .NET's huge installation footprint, nor Microsoft's tendency to change everything once other players get involved. And that's from a C#/ASP.NET developer, folks.)

Which Windows/PC COBOL vendor did YOU choose? Why? What were YOUR criteria?

One of the problems, I'm told, is file i/o. We work with huge customer-provided text and binary files. We have to "do stuff" to them. These may be PostScript files, PCL files, or data files. Many times the developers must code multiple passes through the file. Once to find specific records or strings, a second time to insert code, a third to move chunks of data around. I'm told this is because COBOL doesn't support random file i/o.

Is this true? Is it true under certain conditions, but not in others? Is it true of certain compilers? I ask because I see references to "RANDOM" and "DYNAMIC" access modes. (I'm not, yet, a COBOL programmer, so forgive the ignorance.)

Would another language entirely be a "better COBOL"? Perl? I used to program in PL/B, which is an ANSI standard language, with excellent file i/o, string manipulation, character- based AND GUI/event-driven programming, plus COM/ActiveX. Perhaps switching from COBOL to PL/B would be the right choice:
I'm looking for a good discussion / debate / education on the pros and cons of the various COBOL vendors, plus thoughts on migrating to other languages.

Thanks in advance for your thoughtful responses.



Thomas D. Greer

Providing PostScript & PDF
Training, Development & Consulting
 
Sort by date Sort by votes
Hum.. Don't know PL/B so can't comment on that.

GO on parts.

.NET
Only Microfocus and Fujitsu COBOL

COM/Automation/ActiveX
Fully compliant
Microfocus
Fujitsu
Acucobol
Partial support
RM/COBOL

Faster
This is relative. Processing wyse on a Windows machine I would say that Microfocus, Fujitsu and Acucobol will be faster in most things, but in File I/O CA-Realia used to be the fastest.

Better File IO.
In terms of file processing speed see above.
In terms of capabilities, CA-Realia lacked some multiuser functionality that the others have. Not sure if still true.
As you seem to be dealing with sequential files only (eventually relative files), then whatever you do you will be stuck with the same type of processing.

As far as I' aware there is no product, COBOL or other, that is able to add a "record" to the middle of a sequential file without first creating a brand new file, even it this is done on memory.
So in order to speed up this processing the only option may be to create some low-level functions (in C/Assembler) that do this outside COBOL.

---
RANDOM and DYNAMIC in cobol are part of Relative/Indexed file processing. Are not used on sequential files which you are using.



Regards

Frederico Fonseca
SysSoft Integrated Ltd
 
Upvote 0 Downvote
Thanks, I appreciate your reply. Let me clarify the specific file i/o situation that is causing us grief:

1) 1st Pass. Read through the entire file, sequentially, looking for specific strings OR characters. Assume that this is an ASCII file, for now, though we frequently must process files which contain binary data.

Record the record locations or byte offsets of our target strings into a table or another file.

2) 2nd Pass. Jump to specific byte offsets (found in step 1), reading in the data and writing it back out to a NEW file.

My point is, we don't need to insert data, randomly, into the file we're reading. We do need to be able to position the file pointer backwards or forwards, either to specific locations or as an OFFSET FROM a specific location.

In terms of a print stream file, we might need to go get Pages 12-15, write them out to the new file, and then go get Pages 1-11, and write them out, then jump down to Page 16. You get the idea. Will any COBOL implementation support this kind of file i/o?

I'd like to add "XML support" to my wish list of features, recognizing that this too, is a relative term.

Thomas D. Greer

Providing PostScript & PDF
Training, Development & Consulting
 
Upvote 0 Downvote
Micro Focus COBOL has "byte-stream" procesing functions, which will enable you do do the 1st and 2nd pass you specified. You can read the file, note the byte-offset of the data you are interested in, and skip back to those byte positions. As for printing pages out of order, I have a program written using byte-stream processing which I use to print a text file in "booklet" format, where the first and last page are printed on the sheet, then the second and next-to-last pages printed on the back half of the same sheet; other pages are printed simularly.

I don't use the current version of Micro Focus COBOL, but I understand it has XML support.
 
Upvote 0 Downvote
As I said not natively.
MF byte-stream is an external function and as such you yourself could build your own and use this with your COBOL vendor of choice.

As for XML I think all current vendors have some kind of support for it, even if it is through a third-party OCX.

Also if you are dealing with files less than 10 MB in size (maybe even more) then it is perfectly feasible to load the whole file into memory and work it there before writting the final output file. Very small file IO involved.

Regards

Frederico Fonseca
SysSoft Integrated Ltd
 
Upvote 0 Downvote
It sounds to me as if you will (probably) end up deciding between Fujitsu and Micro Focus (Both AcuCOBOL and RM have lots of "good things" - especially portability across Unix/Linux systems - but the do NOT sound like the best matches at this time).

PROs and CONs with MF and Fujitsu

PRO:
Fujitsu - no run-time licensing issues
currently available "native" (managed) .NET code
no run-time licensing fees

Micro Focus - (better - from what I hear) support
Currently available XML support

CON:
Fujitsu - seems (to me) to have less "ongoing" development (e.g. XML)
Micro Focus - run-time licensing fees.

***

HISTORICALLY, CA-Realia was known for its "IBM <mainframe> compatible" syntax support. Micro Focus has kept current with this, while Fujitsu has not done much in this area since IBM's VS COBOL II syntax. It sounds to me as if this isn't a "big issue" for you - but it might be.

Also, I don't think it would be a real issue, but MF's OO support matches (as an option to match) the ISO 2002 COBOL Standard, while Fujitsu's is NOT compliant. Again, I doubt that this would be an issue for someone coming from CA-Realia.

Bill Klein
 
Upvote 0 Downvote
For one, I fail to understand the exact problem here: I guess you're wanting something that will record-pointer seek a file? (say "I want to go back and read the 32,000th byte?")

Any kind of I/O is going to be slow, especially if you are running multiple passes over a file.

Even if your COBOL doesn't support random access on a sequential file, could a file driver be written in another language and then provided as a DLL?

Might have to look into this one a little bit more at least for the COBOL side of the solution. The DLL solution would be slam-dunk assuming you know how/if the COBOL you have can call a DLL.
 
Upvote 0 Downvote
We do have an IBM Mainframe and will continue to write code for it. However, I think we realize we'll be causing a development rift.

In terms of .NET, I hope we can still write non .NET code, something that does NOT require the .NET Framework.

I would expect the IDE to let me choose between .NET and "standard" projects.




Thomas D. Greer

Providing PostScript & PDF
Training, Development & Consulting
 
Upvote 0 Downvote
I know that Fujitsu sells TWO different compilers - one for .NET and one for "non-.NET environments" (on Windows).

I *believe* but am not certain, that Micro Focus sells a signle compiler that supports both environments (but again not currently for "Managed" code.)

Bill Klein
 
Upvote 0 Downvote
Glenn9999 -

Yes, I need to be able to jump to specific spots in an open file. Forward or Backward. I may be at byte 100,000, but need to go to byte 32 and read in 2K. Then jump to byte 100,101 and read in 4K. We want to eliminate making "multiple passes" through a file.

You may say "then store that 2K at byte 32 the first pass through the file", however, we don't necessarily KNOW where all the significant "chunks" are until we've processed the entire file.

We only want one language. Writing a DLL to solve the problem isn't really solving the problem. If LanguageX will fix things via a DLL, why not just switch to LanguageX?



Thomas D. Greer

Providing PostScript & PDF
Training, Development & Consulting
 
Upvote 0 Downvote
We only want one language. Writing a DLL to solve the problem isn't really solving the problem. If LanguageX will fix things via a DLL, why not just switch to LanguageX?"

My typical observation of different languages is that they were each designed to do different jobs. So you will get something like a Fortran which is great for math jobs but is nightmarish to do much else besides that. Or COBOL which is great for data processing, but is terrible for utility processing.

The "one language for all jobs in the shop" philosophy caused me numerous headaches - I've written a couple of programs in COBOL once that would be an easy 30 minute job with other languages. The COBOL programs took months, consequently, to get working completely right. Basically to go back to the tool analogy, I was trying to drive a nail with a hand-saw. The one language for all philosophy is really foolish on the face of it - how many builders will use one tool and only one tool to build an entire house? That hammer doesn't really make a great level and it really doesn't remove screws all that well...

Will LanguageX do all your jobs better than what you have? Likely not. COBOL is going to be very hard to beat for data processing and it would be very hard for me to want to jettison it entirely for LanguageX because 1% of my total code involves doing something that COBOL is terrible at (or can't do) and LanguageX is good at. So why not just write the 1% of the trouble code in LanguageX and make a DLL that I can call from my language that doesn't give me any trouble 99% of the time? Of course this logic flies in the face of the "one language for all jobs in the shop" mentality...
 
Upvote 0 Downvote
Because language X won't be able to do other things you can do with COBOL.
You don't switch to Fortan just because it is better at maths so you can do a few calculations.

You don't switch from VB to VC++ just because VC++ can deal with pointers while VB can't.

If you look at the current languages ALL of them will interface with external components to perform operations not nativelly available on their own "environment".

So yes writting a DLL may be your best option as I mentioned on both my previous posts.

By your idea of "only one language" you will be excluding your self from almost everything there is on the GUI market.

Only thing remaining will be C based, and even then you need to avoid, by your own idea, controls written in other languages.


Going back to the processing of those files.

Unless you are dealing with really BIG files you can just load then into memory and do all within the program.

A C/assembler based program will probably be faster than a COBOL one, and depending on how parameterized your processing is it will be your best option.
If you need to create a COBOL program for each processing you do then stick with COBOL only, loading the file in memory.




Regards

Frederico Fonseca
SysSoft Integrated Ltd
 
Upvote 0 Downvote
Ok, Ok, point taken. The external control argument is precisely why we want a language that supports COM. That said, I don't think we want to start writing our own DLLs.

We are indeed dealing with VERY BIG FILES, and, frequently, very MANY files. File sizes will often be in the hundreds of megabytes, and even into the GB ranges. Also, we may on some jobs be dealing with hundreds of thousands of files.

So we're looking for a development environment/language that will allow us a lot of NATIVE file i/o and string manipulation power, augmented by COM interop. I've mentioned PL/B already a couple of times, and that was my recommendation to the group.

However, as part of due diligence, I want to thoroughly research the COBOL situation. If we can stay with COBOL, I think we should. It would be best for the group as a whole, regardless of my own preferences.



Thomas D. Greer

Providing PostScript & PDF
Training, Development & Consulting
 
Upvote 0 Downvote
Thomas,

Some comments...

Regarding 'byte stream files' one must consider that, while compiler vendors offer processing for such things within the language, such files are typically not treated in a data transparent fashion, and would therefore be inappropriate for your application. My guess is that most vendors offer a solution that would be usable (I know we do) but it is via a subroutine call rather than in the language itself.

Megabyte/gigabyte files? Part of the everyday work.

One thing you didn't mention, but which I inferred, was regular expression support. We have had that in the language for a few releases. I see that AcuCorp has added support through a subroutine call.

I didn't see (though might have missed) a specific reason for 'COM interop'. Could you describe further what leads to this need?

XML support varies quite a bit. We provide a very robust XML document manipulation capability, which also serves as a building block for our Business Information Server products. Which leads me to another question...

Notably absent from your list was any kind of web access or web enablement. Is there no web-based component in this set of requirements?

Tom Morrison
 
Upvote 0 Downvote
COM interop: we frequently need to interface with programs for one reason or another. Perhaps the client has provided an Excel spreadsheet as their "database", so it'd be nice to automate excel for some formatting and data export features. Or, we need to manipulate a PDF file, so would automate Acrobat or activePDF Server or activePDF Toolkit.

XML support: an increasing number of clients are providing XML data. So there's a corresponding need for XML DOM support, or the ability to apply an XSLT transform.

Web: we have a separate internet services division. I'm a web developer, and code in ASP.NET, ASP, and PHP, as well as the client-side fundamentals, HTML, CSS, and JavaScript. However, for the particular projects under discussion, there is rarely a web component.



Thomas D. Greer

Providing PostScript & PDF
Training, Development & Consulting
 
Upvote 0 Downvote
Hi Thomas,

I choose Realia a long time ago because it was the fastest. Even the fastest code is not fast if you don't use the right techniqes and if you don't study the manual.

For example, if you assign to 'AFILE' when using binary, the assign to 'AFILE[B:63]' in Realia will be about 4 times faster.

I have updated MF applications to Realia and changed the performance from 48 hours running time in MF into 4 minutes running time in Realia. Several people can confirm this.

Also an encryption program written in Realia was in the beginning using good techniques about 64 times slower than the last version which was completely tuned, also using nothing else than Realia.

I don't see things in your original question that other compilers will do faster. Find COBVSC on the web and compare Realia with C. Realia is faster.

You can always mail me directly if you need programming tips because most of the time, this depends on your programmers, not on this Realia compiler.

Regards,

Crox

 
Upvote 0 Downvote
I'd say Micro Focus or ACU. Both still active and developing new products. Both offering a nice IDE to develop and both offer a runtime environment from the most modest PC to the biggest 64bit unix animal.

XML is part of the 2002 standard so that's not really an issue.
 
Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

C
  • Question
IBM AS400 COBOL Conditionally have a record blink
Replies
0
Views
117
chuckw0325
C
A
  • Locked
  • Question
New COBOL Programming Course!
Replies
1
Views
337
SaltyTheFrog
SaltyTheFrog
foxmuldr3
  • Locked
  • Question
RM/COBOL data extraction
Replies
15
Views
739
foxmuldr3
foxmuldr3
RichL32
  • Locked
  • Question
Microfocus Cobol Compiler for personal use
Replies
3
Views
618
mikrom
mikrom
jlcca
  • Locked
  • Question
CobolScript and shm1.cbl
Replies
3
Views
252
jlcca
jlcca

Part and Inventory Search

Sponsor

Back
Top