IBM Mainframe Forum

I need to create a Rexx program that accepts a filename and the copybook name from the user. It then calls a COBOL program and sends this filename and copybook name to it so that the COBOL program can read the file with its copybook layout. How exactly can this be done?

I searched the WEB and found that LINKPGM can be used to call COBOL from REXX and pass relevant parameters. But will COBOL program identify the filename and copybook name variables so passed? i.e. if we recieve the copybook name in variable 'WS-COPY" in COBOL code and wite COPY 'WS-COPY' to include this copybook in the program, will COBOL accept this? Same goes for Filname to be used in the SELECT and FD clauses of the Code.

Currently I do not have access to mainframes so can't code and test the same. Please throw some light on how exactly I can accompalish this requirement.

Rather than search the web for snippets of information why not go to the mother of all rexx informationm - the rexx manuals? There are examples there of calling "other language" programs.

if we recieve the copybook name in variable 'WS-COPY" in COBOL code and wite COPY 'WS-COPY' to include this copybook in the program, will COBOL accept this?

It really depends upon what you are wanting to do. If you expect a COBOL program to be passed a copy layout and be able to use that layout while executing to read the file -- this cannot be done, period. COBOL is a compiled language and all copy layouts, file layouts, and data records MUST be known at compile time. An executing program cannot be recompiled "on-the-fly" to use a different copy book.

If you are wanting to write your application such that the COBOL program gets the copy book, then the COBOL program is compiled with the source changes, and then that program is executed as a different step of the job or a new job, then yes that can be done. It is not necessarily easy, but it can be done.

If you are not clear on the difference between the compile and the execution, you MUST first understand this before you go any further. Source changes of any sort cannot be done at execution time -- only at compile time. Hence, for example, the file record length (maximum length for a variable length file) is REQUIRED to be known at compile time -- you cannot read a file of arbitrary length since the compile sets the length (or maximum length), not the execution of the program.

Use skeletons to build your COBOL program. I've done something similar with PL/I and IDMS in the past,

Thanks all for your kind input.

If you are wanting to write your application such that the COBOL program gets the copy book, then the COBOL program is compiled with the source changes, and then that program is executed as a different step of the job or a new job, then yes that can be done. It is not necessarily easy, but it can be done.

Robert,
Is this possible for REXX to just provide copybook to the COBOL program without actually executing it? Can REXX compile and execute the COBOL program seperately?

Also, I have the flexibility to use any other language to do the processing that is currently being done by the COBOL program.So can I fulfill my initial requirement of sending copybook and filenames from REXX to a program written in some language other than COBOL, lets say, Easytrieve etc?

I am asking this as my basic requirement is to interactively recieve 2 filenames and copybook names from the user and then compare them.Please note that some data in files are in different formats i.e. ACC-AMT field in both the files can contain binary data in 1 file and packed data in another.So I need to manually convert them to some common format (zoned decimal) before comparison can be done.

Use skeletons to build your COBOL program. I've done something similar with PL/I and IDMS in the past,

Prino,
I don't have any idea about PL/I and IDMS.Can you throw some light on it to let me start things using the same?

I am asking this as my basic requirement is to interactively recieve 2 filenames and copybook names from the user and then compare them.Please note that some data in files are in different formats i.e. ACC-AMT field in both the files can contain binary data in 1 file and packed data in another.So I need to manually convert them to some common format (zoned decimal) before comparison can be done.

If your expectation is that you can pass an arbitrary file name and copy book (fixed OR variable, of any length) to the COBOL program and have the comparison done -- the only way to do this would be to recompile and link the program for the different file information. COBOL does not support any form of dynamic (changeable at run time) file definition. What you want to do could be done with Assembler, but this is not easy code to write. If the files were always the same format (fixed 80-byte records, for example) then you could write a program to pass copy book names and data set names to a COBOL program that dynamically allocates the files and uses the copy books to compare the fields. The general case, where the file length is not known in advance, is MUCH harder since the program would have to be compiled and linked by the calling program (or Assembler could be used).

meddy_2725 wrote:Thanks all for your kind input.

Use skeletons to build your COBOL program. I've done something similar with PL/I and IDMS in the past,

Prino,
I don't have any idea about PL/I and IDMS.Can you throw some light on it to let me start things using the same?

Way back in the early 1990'ies I wrote a bit of REXX to parse PL/I %include members (they are the PL/I equivalent of COBOL copybooks). At some stage my users wanted the tool to also be able to use the record layouts from IDMS INCLUDES, but as these were only held in the IDMS data dictionary, I added an ISPF skeleton to the application that would generate a PL/I program pulling in the IDMS INCLUDE, compile the program, only as far as generating a listing, and then an edit macro would cut the resulting PL/I code out of the listing and pass it back to the original application that would just parse it.

As for your variable length records, your REXX should determine the LRECL of the files and use the determined values in the ISPF skeleton to set up everything.

What you want to do could be done with Assembler, but this is not easy code to write. If the files were always the same format (fixed 80-byte records, for example) then you could write a program to pass copy book names and data set names to a COBOL program that dynamically allocates the files and uses the copy books to compare the fields.

Robert,

Can you explain how this could be done with the help of Assemblers? I have access to Assemblers and I would really appreciate if you can provide some input for me to get started.

Also, 1 confusion - Is the program that passes copybook and dataset names to COBOL program is an Assembler program ? How dynamic allocation can be done for files in this case?

I meant that Assembler allows you to defer until execution time specifying some details about files (unlike COBOL where you have to specify these details at compile time). However, even using Assembler you will NOT be using the copy book to read the file -- the only way to do that would be to compile the program as you have been told. You would be using the copy book to provide starting locations and lengths of variables and would actually be processing the data via reference modification -- NOT THE VARIABLE NAMES IN THE COPY BOOK. Dynamic allocation works in Assembler or COBOL equally well, so that is not a concern.

And there is no reason to provide much detail since (1) this is a beginners and students forum and the code that would be needed to accomplish what appears to be your goal is CONSIDERABLY beyond anything a beginner or student could write, and (2) however it is done the code is involved (and depending upon the copy books could be quite complicated -- OCCURS DEPENDING ON, RENAMES, REDEFINES for example all require a lot of thought before ever writing a single line of code).

Hello,

I have access to Assemblers and I would really appreciate if you can provide some input for me to get started.

Having access to assembler is the easiest part of the implementation.

What code to write and how to write it will be your hurdles. If you'd like something to "get you going", think about what the COBOL compiler has to do to process only the data division of some code. You will need to use many of the same processes.

Of all of the thousands of people who visit our forums, there is only a small handful who would be able to do this. Those of us who might feel comfortable have previously worked on compilers, or assemblers, or parsers (i.e.DDL), etc.

This is definitely the first task one should attempt with Assembler.