topic Re: C question in Operating System - OpenVMS

C question

Mulder_1 — Wed, 12 Aug 2009 14:23:33 GMT

Why don't I get any output for lib$put_output but works fine with printf ?

Thanks

Re: C question

Jess Goodman — Wed, 12 Aug 2009 14:56:45 GMT

If you want us to debug your code, it would help if you would include the code so we could look for the bug.

But I'll make a wild guess anyway. You might be passing a string by reference to lib$put_output:

lib$put_output("this won't write out");

which is not the correct argument for this routine, as you would see if you did:
$ HELP RTL LIB$ LIB$PUT_OUTPUT argument

You must set up a string descriptor and pass that instead. String descriptors are structures that contain the address and length of the string, so no assumption about zero-byte termination is necessary.

#include
auto $DESCRIPTOR(string_descrip,"This will write out.");
lib$put_output(&string_descrip);

Re: C question

Jess Goodman — Wed, 12 Aug 2009 15:07:20 GMT

Sorry, your attachment did not show up the first time I viewed the page.

LIB$PUT_OUTPUT only takes one argument. If your want to use C style output formats you must first use sprintf() to write to a string in memory, fill in a descriptor with the address of the string and the resulting strlen() of it, and then pass the descriptor to lib$put_output.

Re: C question

Steven Schweda — Wed, 12 Aug 2009 16:19:38 GMT

> LIB$PUT_OUTPUT only takes one argument.
> [...]

For a more timely complaint about such a
usage problem, defining __NEW_STARLET seems
to be effective:

alp $ cxx /define = (__NEW_STARLET=1) 336875.TXT

lib$put_output("Value \n ",&str_dsc);
...........................^
%CXX-E-MANYARGUMENTS, too many arguments in function call
at line number 21 in file ALP$DKA0:[SMS.ITRC]336875.TXT;1

lib$put_output("Value \n ",&a);
...........................^
%CXX-E-MANYARGUMENTS, too many arguments in function call
at line number 22 in file ALP$DKA0:[SMS.ITRC]336875.TXT;1

%CXX-I-MESSAGE, 2 errors detected in the compilation of "ALP$DKA0:[SMS.ITRC]336875.TXT;1".

Inspection of lib$routines.h shows why.

Also, as
HELP RTL_ROUTINES LIB$ LIB$PUT_OUTPUT
says,

The Put Line to SYS$OUTPUT routine
writes a record to the current
controlling output device, specified by
SYS$OUTPUT using the OpenVMS RMS $PUT
service.

I'd guess that you don't really want one
message split across multiple records.

And you're using lib$put_output() why,
exactly?

You said "C question", but around here,

alp $ cc 336875.TXT

#include
.^
%CC-F-NOINCLFILEF, Cannot find file specified in #include directive.
at line number 2 in file ALP$DKA0:[SMS.ITRC]336875.TXT;1

CXX worked better for me.

Re: C question

Hein van den Heuvel — Wed, 12 Aug 2009 17:06:05 GMT

You may also want to check out SYS$FAO to format a message string and feed it variables before to be assembled into an output descriptor, before using that descriptor for LIB$PUT_OUTPUT.

sprintf is fine as well. If you use that, then use its Return_Values to set the length into the descriptor. "The number of characters placed in the output string, not including the final null character."

Hein

Re: C question

Hoff — Wed, 12 Aug 2009 17:32:51 GMT

OpenVMS native APIs are different from C native APIs; this is an area that causes confusion for C programmers new to OpenVMS.

Details on creating, managing and correctly allocating and deallocating string descriptors are posted around the network. Start with reading through the OpenVMS Programming Concepts Manual (in the OpenVMS manual shelf), and the C guide in the C documentation shelf. That investment will save you time, and it'll also help improve your coding prowess. These two shelves are reachable via the URL:

http://www.hp.com/go/openvms/doc

As for the C compilation:

$ CC /WARN=ENABLE=QUESTCODE

can tend to help spot various C coding errors, and unstable code. Yes, it makes the C compiler get rather fussy about syntax and structure and such.

And here (and as a general comment), always specify and always verify the return status (condition) values from calls such as the lib$put_output routines used here. Production code is most stable when errors are consistently checked, uniformly processed, and appropriately reported. That can help identify the specific trigger for these sorts of error cases more quickly.