0

Could somebody please explain what cob32api does?

I have the task of migrating a batch cobol system from 32 bit Windows to 64 bit Linux. A large number of programs call 'cob32api' which belongs to Net Express. The Linux equivalent to Net Express is Server Express, but I'm not at all clear on what this particular call actually does. There don't appear to be any parameters required. Sadly, there are also no comments explaining what it's for.

Naturally I get an error when I try to build:

Load error : file 'cob32api' 
error code: 173, pc=0, call=1, seg=0 173 
Called program file not found in drive/directory

Can anybody help me out here?

Thanks in advance.

Achim Schmitz
  • 498
  • 1
  • 7
  • 18
  • 1
    It's a shared library used (I guess?) for interfacing with the system? Runtime library? Not really enough info to go on here. – Joe Nov 20 '13 at 18:47
  • It seems to be setting up an "environment" and then using various calls which that environment supports. If you get no answers of use here, contact Micro Focus support. I'm sure they'll be happy to tell you what is needed. – Bill Woodger Nov 20 '13 at 20:41

1 Answers1

2

OK, I tracked down a colleague who has worked on this stuff and knew what it meant. The call to cob32api is required so that the cobol program in question, as well as any sub-modules, can call Windows APIs. This explains why the corresponding library (cob32api.dll) has no Linux equivalent.

The simple solution to my problem: Remove the call altogether.

I hope this helps anybody who runs into a similar problem.

Thanks for the comments.

Additional information: The removal of the "cob32api" call had consequences for the sub-modules I mentioned. Ther were a number of calls of the form

CALL WINAPI "windows-function-name" ...

These resulted in later compile errors and therefore needed to be replaced.

Achim Schmitz
  • 498
  • 1
  • 7
  • 18
  • You could have also added an "on exception continue" clause or use CBL_GET_OS_INFO to determine at runtime you are executing on a Unix platform. – Stephen Gennard Nov 27 '13 at 09:50
  • Unfortunately it hadn't even got to runtime... my problem was building the system in the first place. Besides, I'm a bit old fashioned and prefer to handle exceptions rather than skip over them. But that's just a personal preference ;-) – Achim Schmitz Nov 27 '13 at 14:57
  • I agree but in this case the use of CALL "cob32api" just ensures that symbols found in user32, gdi32, kernel32 and the C runtime are visible to the COBOL program. As the Unix COBOL runtime does not have this routine or have access to these "Windows DLL", all that would happen on Unix, is that the actual CALL to the Windows API itself would fail giving you a better understanding of the issue. – Stephen Gennard Nov 27 '13 at 15:56