I have been tasked  with the replacement of some Assembler programs by Enterprise COBOL programs, using some of the new features available

in Enterprise COBOL and for the most part I have already been successful. However I have the following issues that I cannot find a solution for:

1. In a COBOL called program is there away to know how many parameters were passed?

2. Is there a way to dump specific areas within the program, for example certain areas in the Working Storage area, by giving the start,end address, similar to what

    the SNAP macro can do in Assembler.

3. I need to load a program into storage similar to the LOAD macro in Assembler, so I use the following statements

         05   WS-PROGA           PIC X(8) VALUE 'PROGA'.
         05   WS-PROGA-POINTER PROCEDURE-POINTER.

         SET WS-PROGA-POINTER TO ENTRY WS-PROGA

    The problem is that if the program PROGA does not exist , an S806 abend occurs. I would like a way to know within the COBOL program

     that the loaded program does not exist.
 

1. To my knowledge there is no way to find out how many parameters are passed in a call except maybe:
   1. Have the caller specify unused parameters by using the word OMITTED and have the sub-module test for valid addresses (Address Of) or
   2. Specifying specific entry-points for each possible different number  of parameter(s) or
   3. adding an (assembler) "entry-module" that does some intricate conversion between the actual and the maximum number of parameters
   • All of the above means that the callers need to be more or less amended
2. Display?
   1. We currently use the Snap function of Fault Analyzer to "dump" interesting data for analysis or
   2. Create a (assembler) sub module to do the processing
3. Why not use standard dynamic Call with the "On Exception" option. This will catch the S806 error I think.

Regards Lars

1. There are a large numbers of calling programs, so modifying them is not an option.

   Since I am asked to move away from assembler, a stub  would not be an option.

2. The DISPLAY would not work as I have two addresses to work with, in the replacement COBOL program. The  assembler program I am replacing receives two addresss and SNAPs the area within the two addresses.

     1. Fault Analyzer IDISNAP is not an options as some of these Applications will move away from the mainframe to Microfocus.

     2. Since we are moving away from Assembler, and assembler stub is not an option   

3.    The way the system works is that it   sets the program addresses within a table, to be called later. . So I do not want to actually call the modules , but just get their entry-points to save in the table for later.

Hi Ron,

1. Determining the number of parameters passed purely in COBOL is difficult at best. Current COBOL versions copy the addresses in the declared parameter list to BLL cells while removing the high order bit (HOB), so you effectively can't tell where the parameter list ends. This needs an assembler stub I'm afraid, though it can be a simple LE conforming stub that points R1 to an address that points to the original parameter list. The COBOL program then gets just one parameter pointing to a list of pointers that can be tested in the COBOL program for an HOB. An even lighter weight approach is an assembler program that just returns R13 (LR 15,13; B 14) after which the COBOL program can find the R1 in the COBOL program's caller's save area.
2. There's nothing holding you back from writing a COBOL dump routine. COBOL pointers and linkage section items can be used to address arbitrary memory locations. You can even use a CEEHDLR registered condition handler in your dump routine to let it recover from 0C4's (CEE3204Ss) should it get a bad address.
3. A dynamic linkage SET {function-pointer} TO ENTRY {variable} will always attempt to load the module, and short of a condition handler will terminate the program with a serious error if the module is not found. You could wrap your entry table in a module with a condition handler and have it return a function-pointer (possibly null if the module's not found) given a name.  (The table would primarily let you track which modules don't exist, to avoid driving all the machinery it takes to discover the module's not there.)

And yah, a lot of this will be system programmer flavored COBOL, there's no getting away from that.

Bernie (COBOL support)

Hi Bernie,

1. Unfortunately  for Assembler, I am the last man standing at my site, so I have been asked to stay away from it, so I guess, determining the number of parms is out of the question, at the moment,  unless future versions of COBOL have this feature.

2. Yes, I already figured that out and I am in the process of writing a COBOL dump routine that mimics the Assembler SNAP macro.

     Your suggestion of a CEEHDLR might be the solution to this issue, so I will go for that

3. Your suggestion of a CEEHDLR  is exactly what I needed for this.

Thanks for your tips, they gave me some direction.

Ron

Hi,

Regarding the control of parameters passed to a subprogram, Enterprise Cobol does not comply with the ISO standard which specifies for description of the CALL statement:

If an OMITTED phrase is specified or a trailing argument is omitted, the omitted-argument condition for that parameter evaluates to true in the called program.

According to the tests I have done, the end parameters that are absents at the time of the CALL do not receive a NULL memory address (OMITTED), but receive an undefined value: the IF ADDRESS OF parm-n = NULL test does not work .

Still according to the ISO standard, the control to perform to test the absence of a parameter is:

IF data-name IS [NOT] OMITTED

I suggest that an RFE be opened for Enterprise Cobol to comply with the ISO standard.

Alternatively, one solution might be to develop an assembler subroutine that would traverse the SAVEAREA chain to trace back to the calling Cobol program, retrieve the value of register 1 in SAVEAREA from the caller to this Cobol program, and explore the list of parameters to count them (stop at parameter having bit 31 to 1).Going up the chain SAVEAREA seems quite simple (as long as the programs are standard LE), but I do not know how to identify the SAVEAREA that corresponds to the program Cobol (it would be necessary to recover the name of the program associated with the SAVEAREA, can be by recovery of the PPA1 structure associated with the program, the entry point of which is determined by the value of the register 15 saved in SAVEAREA.

It should request the provision of an intrinsic function "FUNCTION ARGCOUNT" to retrieve the number of parameters received.