CALLEXIT for checking Call Parameter Usage

This would require a completely separate tool to get this working; which is not feasible. As a result, we will have to reject this RFE.

This would be nice to have it in PL/I too, but it may be a bit more complex:

We (in AXA Winterthur) have a Standard-Parameterlist and the DATAs are only referenced by pointers in this list (a header, pointer for Inputdata, pointer for outputdata and an pointer for our standard errorhandling).

So, how do you want handle the pointer parameters ?

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Programming Languages
Product - COBOL Compilers

For recording keeping, the previous attributes were:
Brand - Rational
Product family - Design & development
Product - COBOL Compilers

Programs used in CICS:
Some sub-Programs runs in CICS, but have no DFHCOMMAREA (and DFHEIB) in Linkage Section. They are dynamically called by normal COBOL-Routines, not by EXEC CICS LINK). Of course these programs have to be defined to CICS (or auto-installed).
If a "main"-Program calls such a sub-program with normal CICS-methods, the parameter positions are shifted, the sub-program will fail.
With this Exit i can check easily the compile option for CICS-coprocessor.
You can compile with or without CICS coprocessor, if you have no EXEC CICS statements in your program. But your Using-parameters are with or without dfhcommarea....
And with the preprocessor you could easily check the "procedure division using" statement in the called program.
But the exit can do it automatically.

Best regards

Guenter

Hello and a happy new year.
I have written my comment a few minutes ago, klicking on Submit button, website changed, now i have tested a minute later, no comment of me here.
So i try to do this again (and i hope to remember to copy my text before clicking).

I am not sure if ADATA would be enough.
Normally SYSADATA is a sequential file i have to process later.
When using ADEXIT for getting all information at now, i have to save most of the informations in Memory, because if i get a row with CALL token (0004) i have to recognize the used fields (row by row and token by token), then i have to search the whole information i've got before for the related informations about variable type and length.
And After doing this complex table working i can do the original job: checking against a repository (db2 table).
And as ADEXIT i found no chance to interrupt the compiling, giving the warning message for different call parameters between caller (this program) and called subprogram.
Or i misinterpreted the SYSADATA records.
So i am still wishing the Call-Exit.

Hi, thanks for your feedback. Can SYSADATA be used instead for this purpose?

Hello,
i am sure i added a comment last friday.
So i try to do it again:
The Use of Function Prototyping has two restrictions:
1) I have to change every Program to add the prototype for my sub-program (a copy book would be fine, but also this copy statement has to be added.
2) If i don't compile a calling progam, the prototype wouldn't be accessed and i get no compile error. I must be sure to compile every caller of my changed subroutine.
With a CallExit we have much more flexibility.
- I don't need to create prototype statements (in copybooks).
- if i forget to compile a calling program, i can find it with easy sql query
- i don't need to change every program for implementing the prototype copybooks.
- i only need to create a dictionary table, adjust and compile/link the callexit sample program to my needs and USE IT.
- Much less work for all, works also with code from external sources
- i can easily adjust some extraordinary program callings (mismatching length of areas) to my internal rules

The proper way to achieve the functionality requested via this RFE should be by using function prototyping. It is our intention to implement function prototyping in a future compiler version.

Attachment (Description): More specific details for CallExit