Problem solve Get help with specific problems with your technologies, process and projects.

Need help opening a file using C on OS/390 CICS

 I am a 390 novice and am having problems opening a file.
Here is the command we are using in C code on OS/390 CICS:

EXEC CICS STARTBR FILE( file_name ) RIDFLD( rba_value ) RBA RESP(resp)
RESP2( resp2 );

file_name is a usual C string.
My question is should we prepend NULL byte to this string or somehow else
change it to be able to read the file?

I'm going to start by owning up to a phobia about running C programs within CICS. It's the way C does things that is suited to a workstation/unix environment and not the mainframe way of doing things that I don't like - but that's me!

That being said, I think you have encountered one of these little differences that requires a different C coding technique for C in CICS as against C on a workstation. The CICS API/SPI has evolved over the years for a COBOL/PL1/Assembler mode of operation, and C was a later addon (and the continuing evolution into the Java world introduces another operational mode to boot!). Consequently, the mode of operation for the API/SPI accessed from C has to fit that for access from COBOL/PL1/Assembler.

This means that C Strings are not what the CICS API/SPI expects (or understands). This comes down to the fact that C null-terminated strings are not processed by CICS in the API/SPI commands. Where something like a CL8 name is required, CICS will expect 8 bytes of data with spaces padding on the RHS. It will not like, say 4 bytes of data with the 5th byte as the null terminator.

If you want to use a String as input to the API/SPI, then ensure its 1byte longer and left justified: So if you want to supply a CL8 file name, use a char[9] with info in bytes 1-8 left justified (spaces on the rhs) and byte 9 the X'00' terminator (ie: strlen will always return 8).

The same idea applies to API/SPI commands that return characters: if you want to process them as a string (as opposed to a byte array), then create a variable one byte bigger than CICS requires and force the rightmost byte to X'00' after the command has executed.

If you look in the C Chapter of the CICS Programming Guide, there is a list of restrictions and data types : and a comment about C Strings and how CICS does not recognize null terminators.

Dig Deeper on IBM system z and mainframe systems

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.