topic Re: Creating functions for use in HP COBOL on OpenVMS in Operating System - OpenVMS

Creating functions for use in HP COBOL on OpenVMS

John T. Farmer — Fri, 20 Mar 2009 20:19:32 GMT

Is it possible to write fuctions for use in HP COBOL, VMS 8.3 like the intrinsic functions supplied with HP COBOL? For instance, COMPUTE MYVALUE = FUNCTION MYFUNCTION(WRK-MYPARAM). If so, can these be coded with any Language like COBOL (the only one I know...). Thanks for pointing me to any references on the subject, and/or for your recommendations.

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...).

Thanks,

John
john dot farmer at genworth dot com

Re: Creating functions for use in HP COBOL on OpenVMS

Dennis Handly — Fri, 20 Mar 2009 21:49:40 GMT

>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...).

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.

Re: Creating functions for use in HP COBOL on OpenVMS

Hein van den Heuvel — Fri, 20 Mar 2009 23:14:21 GMT

I don't think so. Just a those 50 odd, fixed intrinsic functions. No named, or linker resolved , functions like the 'call'.
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,
Hein.

Re: Creating functions for use in HP COBOL on OpenVMS

John Gillings — Sun, 22 Mar 2009 22:16:38 GMT

John,

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.

Re: Creating functions for use in HP COBOL on OpenVMS

Hoff — Sun, 22 Mar 2009 23:27:42 GMT

John provided the textbook answer. I usually coded up an examine program and an example target (both using the same language), then stepped into the call sequence using the debugger, and looked around. From the descriptor codes and the header files, I could work backwards into the descriptor-related documentation in the calling standard manual. Brute-force and hugely ugly and hopefully an absurd way to go after this case, but I also found more than a few cases where a compiler used an unexpected (to me) descriptor.

Re: Creating functions for use in HP COBOL on OpenVMS

Richard J Maher — Sun, 22 Mar 2009 23:56:08 GMT

Hi John,

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)

Re: Creating functions for use in HP COBOL on OpenVMS

Hein van den Heuvel — Mon, 23 Mar 2009 02:15:33 GMT

Hoff,
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.
:
Yuck!

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!

Hein.

Re: Creating functions for use in HP COBOL on OpenVMS

John T. Farmer — Mon, 23 Mar 2009 13:24:40 GMT

Thanks for all the replies. Was worth a shot. Will continue CALLing routines in COBOL to get the job done.

Thanks,

John F.

Re: Creating functions for use in HP COBOL on OpenVMS

Richard J Maher — Mon, 23 Mar 2009 21:05:35 GMT

For anyone else that comes across this thread don't forget COBOL's: -

- 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