03-20-2009 01:19 PM
There are cases where it makes more readable code to use a function syntax than it does for calling other programs (i.e., CALL 'MYPROG' USING...).
john dot farmer at genworth dot com
03-20-2009 02:49 PM
I would stick with what you know, CALL.
It seems debatable whether functions are more readable for your simple COMPUTE.
Of course in C, C++ or etc., using functions in expressions is nice.
03-20-2009 04:14 PM
So you are stuck with the CALL USING ... GIVING
Now those called subroutines can be coded in any language, not just Cobol itself. That's the beauty of OpenVMS! Feel free to write your subroutines in C or MACRO or Fortran.
Cobol is happy to call out, passing by descriptor, reference or value. Cobol itself is NOT happy to be called by anything but a memory reference, but there are tricks around that.
The biggest common (expectation) problem using multiple languages is that each have their own native file io methods. You can not mix BASIC channels with Fortran LUNs or C file handles. But otherwise... just about anything goes.
Hope this helps,
03-22-2009 03:16 PM
As Hein says, you can mix languages on OpenVMS very easily, BUT COBOL can have a peculiar problem calling routines in other languages. Since COBOL has far more data types than most other languages, you have to work a bit harder to make sure your arguments are correct. There are many data types in COBOL that the likes of C and C++ will not recognise.
THE biggest issue when calling any routine is making sure arguments agree in position, data type and passing mechanism. You'll need to consult the table Table 13-4 COBOL Implementation of the OpenVMS Data Types (OpenVMS) in the Cobol Users Manual to make sure you've declared the arguments correctly.
03-22-2009 04:27 PM
03-22-2009 04:56 PM
A very worthwhile question, and one that I have wondered about since intrinsic functions appeared. Iguess the answer has to be in the evolving COBOL language standards and the whether (how soon) John Reagan can incorporate adherence to those standards into HP/COBOL. Sadly, I see huge obstacles on the horizon :-(
Already, there are many COBOL features common elsewhere that are not supported in VAX/HP/COBOL "Set Reference of ws-var TO ws-pointer" (or something like it) being one that I wish for.
As far as "creating" cobol functions goes, there is nothing to stop you. You can then call them as a function from something like SQL with no problems. (Just not "as a funtion" from COBOL)
Cheers Richard Maher
PS. If you wish to return something other than a [big]integer as a function result from COBOL then just specify it as the first parameter in your sub-program (ie: you don't use the GIVING phrase for a String function result)
03-22-2009 07:15 PM
That's pretty much what I do when the going gets tough. Can't argue with bits & bytes. They are what there are.
Richard>> whether (how soon) John Reagan can incorporate adherence to those standards into HP/COBOL. Sadly, I see huge obstacles on the horizon :-(
I suspect you are right. Ain't gonna happen. What you see is what you get.
Richard> VAX/HP/COBOL "Set Reference of ws-var TO ws-pointer" (or something like it) being one that I wish for.
Amen. Something, anything, to de-refence.
I resort to silly stuff like:
01 fab_pt POINTER.
01 gbc_pointer POINTER.
CALL "DCOB$RMS_CURRENT_FAB" GIVING FAB_PT
ADD 72 TO FAB_PT GIVING GBC_POINTER.
CALL "OTS$MOVE3" USING BY VALUE 2, BY REFERENCE GBC, BY VALUE GBC_POINTER.
Richard>> S. If you wish to return something other than a [big]integer as a function result from COBOL then just specify it as the first parameter in your sub-program
Right. Thanks for reminding us / pointing that out!
03-23-2009 02:05 PM
- CALL ws-identifier
- (VMS') lib$callg
- Nested sub-programs
- IS COMMON
- variables with GLOBAL scope
This functionality/flexibility can also help with COBOL program design.
Cheers Richard Maher