AcuCobol DLLs??

[dilettante]

We use a 3rd party application that includes a peridically updated database and a suite of programs and libraries to perform some sophisticated data cleansing and related operations.

This was once built in MicroFocus, but the latest release is in AcuCobol.

Our primary use of this has involved calling the standard DLLs of this package from our own (non-Cobol) Windows applications. We make little use of the included batch-processing EXEs in the package.

Upon installing the binary Setup for the new version we found something a bit frightening: no DLLs, no real EXEs at all! Instead AcuCobol looks like some sandboxed interpreted system akin to the old UCSD P-system or the old DOS QBasic. Libraries appear to be includeable p-code modules now instead of Win32 binaries.


At this point we feel totally screwed. The info at Acucorp's site is anything but encouraging. It suggests that the only real models of interaction with the outside world is through batch processed disk files, OLE Automation (like controlling an instance of Word from a script), or possibly some sort of .NETtish Web Service.

As far as I can tell any of these would require the source code to the 3rd party application and a license for (perhaps a fancy edition of) AcuCobol.

The only alternative I see is to rewrite all of our Windows code in Acucobol and "include" the application's "libraries" as required. This isn't viable because our existing code (supporting the older releases of the 3rd party product) serves as a bridge between another platform and the Windows machine, to get at the product's services through a specialized RPC mechanism. Our code wraps the third-party libraries as a COM+ Application.


Is the situation as grim as it feels from here right now? Can anyone confirm/deny that AcuCobol is truly this sort of closed universe?

 

[k5tm]

dilettante,

Do you have any licensing terms with the application vendor that would cover your use (which I presume is 'out of the mainstream' for that application) that might be construed as a contract to continue to provide suitable interface?

Since you were getting to the product via an RPC layer, perhaps you can write a wrapper using England Technical Services COBOL-RPC for AcuCOBOL. This might be straightforward if the RPC layer was merely mimicking an internal API that hasn't changed in the AcuCOBOL reimplementation. You might find ETS a good resource for ideas, even if COBOL-RPC won't help. They have a lot of experience in this type of interface issue.

on another note:

looks like some sandboxed interpreted system akin to the old UCSD P-system or the old DOS QBasic.

This seems rather pejorative. Why not say, "... akin to the well-known, state-of-the-art Java Virtual Machine?"

Good luck!

Tom Morrison

http://www.liant.com

 

[dilettante]

Thank you Tom,

You've offered some useful suggestions, ones we'll be sure to explore.

The funky RPC we use (piggybacked on COM+) is only used to support a highly important platform the vendor no longer supports directly. As it is (in the MicroFocus releases) we have to write a COM wrapper anyway.

So Cobol-RPC looks interesting. It may be something we'll have to bring up with our vendor. Perhaps they'll be willing to provide compiled software enabled in such a way as a "server." We ourselves don't have a source license for their product nor are we an AcuCobol licensee. The concealed pricing of AcuCobol isn't encouraging in itself, but we don't have much interest at this point in doing the vendor's job anyway. This is not some microISV product and we pay substantial licensing and support fees for it.

I have not investigated the license terms of the 3rd party product itself yet. I suspect you may be right in that most customers may just run the provided batch programs against an input file to create a cleaned output file and reports.

In addition to batch processing on the order of 100M records a year through this product we also interactively "clean" something like 16M transactions a year through it. My preference would be to do the batch cleaning as the vendor intended. Unfortunately this (a.) isn't my call, and (b.) still doesn't address the transaction processing need.

The provided customer documentation does explicitly give information on calling the routines formerly implemented as Windows standard DLLs however. Sadly, the new release's documentation only describes use of these routines from customer AcuCobol programs, mentioning other-language use almost literally as an excercise for the reader - something on the order of "consult the documentation for your language development tools."

The good news is that the API has not changed in terms of calls, their parameters, or returned results. The only substantive change seems to be the runtime implementation which is no longer platform-native.

We did get a seemingly panicked reaction from the 3rd party vendor's support desk. Perhaps we are simply the first to call in with this issue. It'll be interesting to see what the resolution is from their end.

I'm not sure my analogy is quite as pejorative as it may appear. While most Java implementations support JNI or other alternatives for interoperation with platform-native software it appears as if AcuCobol does not. Acucorp's decision to encumber access to product documentation does make this difficult to determine with accuracy however. My grumpiness at having had this suddenly dumped in my lap is no excuse for a poor attitude here though.


In the meantime we're trying to decide how big a panic this is for us. My only real question probably comes down to: "Can Win32 AcuCobol's 'library' routines be compiled to permit their being called by native Win32 applications as either standard or COM DLLs?"

Performance is already a concern with the old product. We don't have any interest in something as slow and cumbersome as a "Web Service" interface. We haven't even had a chance to see what the AcuCobol runtime performance characteristics are going to do to us.

 

[3gm]

dilettante -

I understand your frustration. I originally was disdainful of the AcuCorp approach to cross-system compatiblity, but I've come to appreciate that it does have its advantages.

AcuCORP has been rather protective of its documentation which does make it hard for folks who don't hold full development licenses to learn about the product. Even the full documentation doesn't adequately address interoperability. See faq209-6283 for more information about how to call AcuCOBOL from C.

I've use that method for one of my clients with great success. Performance is very good on AIX.

Glenn

 

[dilettante]

Thanks Glenn,

Tom made an excellent point as well with his Java analogy. Microsoft's .Net takes a similar approach. Other vendors of Cobol development tools have gone this way as well. There are some very good reasons for doing so and it can provide value for customers in a number of ways.

I have to admit to some shock when I encountered this. I haven't been dealing with Cobol rehosting tools at all until just now and assumed native-code compilers were de rigeur.

I wouldn't have been concerned about the matter or perhaps not even aware of it had this 3rd party package's API not changed suddenly. Some type of "native interop" feature would go a long way toward easing our pain. AcuCobol's "world" seems very closed right now.

Maybe something like Cobol-RPC will make a difference here.

I'm glad you're seeing good performance on AIX. That's encouraging. From where I sit AcuCobol is a black box in so many ways. Perhaps Acucorp will act on our request for information via their web site form in a few more days.


The difficult part for us is that this product we're using consists of both programs and a proprietary database. The database requires regular updates to be of much use. We don't have the option of running the earlier version software with new database versions. The database has changed to a new form as well as the code, i.e. the new data doesn't work with the old code.

Even the in-house "champion" of this product is chuckling nervously and suggesting we look at competitors' products. This may be no small undertaking. There are only a handful of players in the market after a series of mergers and acquisitions. Even a suitable product may use a radically different API, resulting in further costs for us to change existing applications.

A year of warning might have been nice. I was brought in on this late so I don't yet know whether we had the warning though and simply ignored it ourselves.


The good news is that the new release is only about 3 weeks old. We can drag our feet as many as four more months if we have to before updating the production and standby (cold spare) servers. But four months can go by quickly waiting for news and then possibly needing to rush major changes through.


In the meantime I'm hoping to get answers to my handful of technical issues. AcuCobol users may not be plentiful here at Tek-Tips, and I know from supporting Cobol developers for the first 20 years of my own career that most Cobol programmers are more focused on source-level issues. My answers may have to come from the vendors involved in my current situation.

I've been surprised at the dearth of technical product analyses and comparisons in this sector of the tools market. Aside from Cobol vendor sites, a few supporting-tools vendor sites, and a few contract services sites... all I've really seen is the occasional plea for help on forums and some product announcements.

This may reflect the size of the market for Cobol rehosting tools more than anything else. That in itself may be changing as old platforms fade away and the need to port legacy line of business software grows. For now my fairly exhaustive Google searches have been disappointing.


I find it interesting that the need for legacy support is driving the market to more and more virtualization. On the one hand we have things like Java, .Net, and these Cobol products. On the other we have platforms like NT 4.0 and even the mainframe we use going to a VM on (later) Windows, Linux, etc. model of support.

It looks like Cobol will be around for a long time to come. Most shops are just not willing or able to port applications to either new platforms or new languages. A lot of the "new" development seems to add new functionality, often in a surprisingly peripheral way.

Short term perhaps the virtualization market will prove a growth business, I don't know. At some point though we're going to see a serious Cobol programmer shortage. The need just isn't going away for everyone and even legacy software needs care and feeding.

 

[Truusvlugindewind]

Part of the "problem" here you went from Micro Focus to ACU. When you want to call those COM/DCOM windows stuff, you do not want to call, you want to evoke a method in a class. Suddernly where on O-O terrain. Strange and spooky for us cobol programmers.

Micro Focus implemented the O-O consept 15 years ago. ACU waits for customers to ask for it.... nodbody asked so never implemented.

There are triks to call/evoke methods in a class.... don't ask how. Some criptic copybook has to be compiles or assembeled and that copybook is includen in the special-names paragraph. Then using the "modify handle" syntax you can "call" your method.... In dutch we say "draaien als een drol in een pispot". But, you can get it to work.

 

[3gm]

Truusvlugindewind -

The poster indicated that he needed to call AcuCORP (COBOL) from another language, not create COM objects and invoke their methods. He also indicated this was NOT a choice he made, but one that was forced upon him when his vendor changed COBOLs.

AcuCORP does appear to be slow to fully incorporate support for COM objects into their product. For instance, they don't support late-binding or passing all SAFEARRAY types.

I would also disagree that it's tricky. It is difficult primarily because it IS poorly documented (the documentation is spread around in many places in the manuals and too few good examples exist). There are better examples available online, but you have to work to find them.

As for cryptic copybooks, the copybook is normally generated with their AXDEFGEN tool (pick a type library, give it a file name, and press OK) and quite easy to read (creating one by hand is another matter). It clearly mirrors the IDL found in the typelib. You don't have to understand the copybook to use the associated objects. Sometimes, it helps clarify how to use the object and can be especially helpful identifying enums to use among other things. Of course, the better understanding you have of COM, the better you'll understand the copybook.

Regards,

Glenn

 

[dilettante]

At this point all we need is a way to call the library routines provided (and documented) by the vendor from Win32 or COM code in another language. If this AcuCobol programming tool could create the libraries as COM objects usable as COM+ Applications the "other language" requirement disappears as well.

This vendor is mulling the matter over, and we'll have to await their determination before we can decide how to proceed. Even if AcuCobol (with or without additional "helper" tools) can do what we need the vendor will have to decide to implement the necessary changes.

Until they make a move we'll just have to sit back rather than pepper them with options.