2

I am responsible for converting an old UNIX based COBOL batch application that was developed by a consultant back in the 1990s to a Windows environment but still in COBOL using Microfocus (Eclipse, etc).

This is a pretty straight-forward task except for one little glitch.

The old application never did any explicit file handling within the COBOL. That is there are no FDs, OPENs, READs, WRITEs or CLOSE commands in the COBOL programs. Instead they wrote a C program that would do one of those different functions based on parameters passed to it (including, but not limited to file name, rec length, and the function desired.)

I would like to rewrite that subroutine in COBOL, which would require very little modifications to the COBOL main programs being converted. That is, it would still call that subroutine, but it would now be in COBOL instead of C.

But the challenge is how to write that subroutine so that it is able to act on most any file. I would think I have to go the route of variable length records because they could literally be any length up to to-be-determined maximum size, but seems like it would be vulnerable to error (as it tries to open different types of files).

Does anybody have any experience on this or ideas on a task like this? If not,l I may have to go the blunt force route of replacing each call statement to that subroutine with the specific COBOL command (Open, Read, etc) that needs to be performed and obviously FD and SELECT for every file would need to be added to the main program.

Thanks in advance.

DaveL
  • 101
  • 1
  • 7
  • Have you got the source of the C sub-program that you can include in the question? – Bill Woodger Apr 15 '16 at 19:26
  • Not sure how much I can include here, but this is the function that opens a file:/************************************************************************** ** Edit: It was too large. I may have to wait till Monday. Can I attach a file here? – DaveL Apr 15 '16 at 20:15
  • There's an edit link under your question. If you use that, there's 30,000 characters to play with, which I'd hope is enough. – Bill Woodger Apr 15 '16 at 20:19
  • You would have to read up on the FILE STORAGE SECTION. *However*, it might be worth asking why the consultant used C instead of COBOL.I vaguely remember that Microfocus COBOL, when I used it in the '80s, had some pretty severe limitations due to its 8 bit internal storage (255 fields per record, chars in a varchar etc). You might want to check that it can now handle the formats you want to use. – Mike Apr 15 '16 at 20:24
  • You don't want to dump 100's of lines of C into your question. So if that's what you have, you might want to find an external place to put it and link to it. To your question: have you considered the option of porting the C and interfacing to it from Microfocus COBOL, just as the original program did? I'm not familiar with whether Microfocus has that facility, or what C compiler objects they might link with, but I'm just tossing it out there as an alternative. – lurker Apr 18 '16 at 16:58

1 Answers1

0

You might be able to

CALL "subprogram" USING fd-name

where fd-name is

FD fd-name.
...

So, yes? maybe?, you might be able to pull off a subprogram that can take generic COBOL files. But, then you get into matching record layouts and other fun things, so, be wary. This might not work COBOL to COBOL, but it does work COBOL to C and back, as you end up passing a reference to the file control block.

You'll likely be better off looking into stock system libraries. Things like CBL_OPEN_FILE and CBL_READ_FILE if they are available. This will give you a much closer match to streaming IO that will be assumed in the current C subprogram.

Or, as Bill is suggesting in the comments, try and figure out why C was used and if you don't want the foreign functions, just dig in and write new COBOL procedures, as that will likely read better in the end.

Brian Tiffin
  • 3,978
  • 1
  • 24
  • 34
  • Thanks to everybody for the comments. After reviewing with our other programmer and weighing the responses and our options (which included those mentioned here - rewriting explicitly in COBOL and porting the C subroutine), we have decided that the volume of the new code is not exorbitant and it is worth simplifying the process by keeping it in the mains. – DaveL Apr 20 '16 at 00:32