Start and browse file resoure definition sample

EXEC CICS INQUIRE FILE START END-EXEC.         
PERFORM UNTIL RESPCODE = DFHRESP(END)           
    EXEC CICS INQUIRE FILE(FILENAME) NEXT       
        OPENSTATUS(OPENSTAT)                   
        RECOVSTAT(RCVRSTAT)                     
        FWDRECSTATUS(FWDSTAT)                   
        RESP(RESPCODE) END-EXEC                 
    IF RESPCODE = DFHRESP(NORMAL)               
        IF OPENSTAT = DFHVALUE(OPEN)           
            CALL RCVY-RTN USING RCVRSTAT FWDSTAT
        END-IF                                 
    ELSE CALL ERROR-RTN END-IF                 
END-PERFORM.                                   
EXEC CICS INQUIRE FILE END END-EXEC.

How to get RACF information in CICS region

CICS doesn’t supply much access directly to RACF info via the API. But there is a supported way to obtain a lot of RACF information about the current user. And it can be done in plain ol’ COBOL.

EXEC CICS ADDRESS ACEE will provide access to the RACF ACEE control block. (ACEE stands for Access Control Environment Element. Maybe it will come up in a trivia question some day. Probably not. The important thing to know is that it is a block of storage containing RACF information which can be addressed from application programs.) From there, it is possible to easily obtain the user’s primary RACF group and the user’s name (as it is recorded in RACF).

The layout of the ACEE control block is documented in SYS1.MACLIB(IHAACEE). Unfortunately, there is not a COBOL copybook provided, so to access this information in a COBOL program, we have to code our own storage definitions. The following are based on SYS1.MACLIB(IHAACEE):

Define these in Linkage area
01 ACEE.
05 FILLER PIC X(021).
05 ACEEUSRI PIC X(008).
05 FILLER PIC X(001).
05 ACEEGRPN PIC X(008).
05 FILLER PIC X(062).
05 ACEEUNAM-POINTER USAGE IS POINTER.
01 ACEE-USER-NAME.
05 FILLER PIC X(001).
05 ACEEUNAM PIC X(020).

And we need a piece of miscellaneous working storage to hold a pointer:

77 WS-ACEE-ADDR-POINTER USAGE IS POINTER.
Now, if we execute the following, we’ll have the address of the ACEE control block in that pointer:

EXEC CICS
ADDRESS ACEE (WS-ACEE-ADDR-POINTER)
END-EXEC.
And then the following commands will make the RACF information addressable by our storage definitions:

SET ADDRESS OF ACEE TO WS-ACEE-ADDR-POINTER.
SET ADDRESS OF ACEE-USER-NAME TO ACEEUNAM-POINTER.
Now we have the user’s RACF id in ACEEUSRI, the user’s primary RACF group in ACEEGRPN, and the user’s name in ACEEUNAM. Very simple – just a matter of knowing how to address the information.

In a future post, we’ll continue this and see how we can obtain all of the RACF groups to which the user’s RACF id is connected.

How to Link COBOL & C Together on z/OS

(1) Link your C program to call your COBOL program by declaring your C and COBOL functions as follows:

 Declare a function in C that passes an integer value (i) to COBOL:
 void CBLRTN(int );
 CBLRTN(i);

 Use the value “I” from the C program in your COBOL program:
 01 I PIC S9(9) BINARY.
 PROCEDURE DIVISION USING BY VALUE I.

(2) Link your COBOL program to your C program by having the COBOL program call a C function and pass it a value, as follows:

Call the C subroutine “CFUNC” from COBOL, passing the value “I”:
01 I PIC S9(9) BINARY.
CALL "CFUNC" USING BY VALUE I.

Declare the function in C:
void CFUNC(int i) {
  return i;
}

(3) Declare a “pragma_linkage” at the top of your C program to explicitly declare a linkage to COBOL, which is required by some compilers. The syntax for the pragma linkage is:
“#pragma linkage(function, COBOL)”.

You declare the pragma linkage and create a C function to pass a value to COBOL as follows:

#pragma linkage(CBLRTN,COBOL)
void CBLRTN(int i);
CBLRTN(i);

You then use the passed variable in your COBOL program as follows:

01 I PIC S9(9) USAGE IS BINARY
PROCEDURE DIVISION USING I.

(4) Declare a “pragma linkage” at the top of your C program to explicitly link the COBOL program to C. This is
required by some compilers. The pragma linkage is always done in the C program, even when the COBOL program is
passing the value to the C program.

You declare the variable in the COBOL program and call the C function as follows:

01 I PIC S9(9) USAGE IS BINARY
CALL 'CFUNC' USING BY CONTENT I.

You then declare the pragma linkage to COBOL and define the function in C as follows:

#pragma linkage(CFUNC,COBOL)
void CFUNC(int p1) {

Migrating data from HFS/zFS to zFS

Suppose you have an HFS file system mounted at /etc/dfs. You want to copy this into an empty zFS file system mounted at /etc/dce/testzfs1. You issue the following commands from z/OS UNIX:

(1) Move to the source (HFS) file system mounted at /etc/dfs
cd /etc/dfs

(2) Create a z/OS UNIX archive file called /tmp/zfs1.pax that contains the HFS file system mounted at /etc/dfs
pax -wvf /tmp/zfs1.pax .

(3) Move to the target (zFS) file system mounted at /etc/dce/testzfs1
cd /etc/dce/testzfs1

(4) Read the archive file into the zFS file system mounted at /etc/dce/testzfs1
pax -rv -p e -f /tmp/zfs1.pax

CICS without security in an ACF2

F ENF,MODE(CICS,NONE) and set SEC=NO in SIT or override, the region(s) will come up without ACF2

C - replace substring

char *replace_str(char *str, char *orig, char *rep)
{
  static char buffer[4096];
  char *p;

  if(!(p = strstr(str, orig)))  // Is 'orig' even in 'str'?
    return str;

  strncpy(buffer, str, p-str); // Copy characters from 'str' start to 'orig' st$
  buffer[p-str] = '\0';

 sprintf(buffer+(p-str), "%s%s", rep, p+strlen(orig));

 return buffer;
}

Example:
replace_str("Hello, world!", "world", "Miami@ #")

C - string padding

char *StringPadRight(char *string, int padded_len, char *pad) {
    int len = (int) strlen(string);
    if (len >= padded_len) {
        return string;
    }
    int i;
    for (i = 0; i < padded_len - len; i++) {
        strcat(string, pad);
    }
    return string;
}

that's supposed to do StringPadRight("Hello", 10, "0") -> "Hello00000".