CICS JCL procedure to compile and link the SIT containing updated CICS parameters - jcl

Does CICS have supplied procedure for assembling a SIT? I'm currently checking from https://www.ibm.com/docs/en/cics-ts/5.3?topic=library-cics-supplied-procedures but I can't find anything that uses EXEC PGM=DFHSIP. I'm not in that level yet to write a JCL myself so I'm really trying to find sample of how I can assemble my updated DFHSIT macro.

It usually isn't necessary to assemble a new SIT table. You can pass SIT parameters as overrides when starting your CICS region. I find that the majority of CICS systems are started with one of the supplied SIT load modules (DFHSIT or DFHSIT6$) and provide customized SIT overrides via SYSIN. See https://www.ibm.com/docs/en/cics-ts/5.3?topic=regions-specifying-system-initialization-parameters-before-startup
Note that the primary reason why people don't assemble a new SIT table is that the SIT load module must reside in an APF authorized data set. In most enterprises, write access to an APF authorized data set is rarely allowed and is severely scrutinized when an update is absolutely necessary.

DFHSIP is the main CICS program and isn't used for assembling the SIT tables. Probably best to have a look at the proc DFHEITAL that is provided with CICS. This is a good example of how to translate, compile and linkedit assembler programs.
However SIT tables should not be translated or linkedited with the CICS stub program. Below is an example of what I've used before to compile CICS tables:
//ASM EXEC PGM=ASMA90,REGION=0M,
// PARM='DECK,NOOBJECT,LIST’
//SYSLIB DD DSN=<cicshlq>.SDFHMAC,DISP=SHR
// DD DSN=<cicshlq>.SDFHSAMP,DISP=SHR
// DD DSN=SYS1.MACLIB,DISP=SHR
//SYSUT1 DD UNIT=SYSDA,SPACE=(1700,(400,400))
//SYSUT2 DD UNIT=SYSDA,SPACE=(1700,(400,400))
//SYSUT3 DD UNIT=SYSDA,SPACE=(1700,(400,400))
//SYSPUNCH DD DSN=&&LOADSET,
// UNIT=SYSDA,DISP=(,PASS),
// SPACE=(400,(100,100))
//SYSPRINT DD SYSOUT=A
//SYSIN DD DATA,DLM='<>'
<source>
<>
//LKED EXEC PGM=IEWL,REGION=0M,
// PARM='LIST,XREF',COND=(7,LT,ASM)
//SYSLIB DD DSN=<cicshlq>.SDFHLOAD,DISP=SHR
//SYSLMOD DD DSN=<output>,DISP=SHR
//SYSUT1 DD UNIT=SYSDA,DCB=BLKSIZE=1024,
// SPACE=(1024,(200,20))
//SYSPRINT DD SYSOUT=A
//SYSLIN DD DSN=&&LOADSET,DISP=(OLD,DELETE)
// DD DDNAME=SYSIN
//SYSIN DD *
NAME <name>(R)
/*

Related

AFL hello world example

I'm trying to figure out how to use AFL, but I can't seem to make a simple example running.
Here is my C program:
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <assert.h>
char *remove_white_space(char *s)
{
while (s && *s++)
if (*s == ' ')
return "moish";
return s;
}
int main(int argc, char **argv)
{
char buffer[256]={0};
FILE *fl = fopen(argv[1],"rt");
if (fl == NULL) return 0;
assert(fscanf(fl,"%s",buffer) > 0);
char *res = remove_white_space(buffer);
if (strcmp(res,"a b c d") == 0)
{
assert(0);
}
fclose(fl);
return 0;
}
My input seed is a text file with a single line abhgsd.
Here is what I did:
$ afl-gcc main.c -o main
afl-cc 2.56b by <lcamtuf#google.com>
afl-as 2.56b by <lcamtuf#google.com>
[+] Instrumented 62 locations (64-bit, non-hardened mode, ratio 100%).
$ afl-fuzz -i INPUTS/ -o OUTPUTS ./main ##
And I got this red CAPITAL CRASH message:
afl-fuzz 2.56b by <lcamtuf#google.com>
[+] You have 8 CPU cores and 1 runnable tasks (utilization: 12%).
[+] Try parallel jobs - see /usr/local/share/doc/afl/parallel_fuzzing.txt.
[*] Checking CPU core loadout...
[+] Found a free CPU core, binding to #0.
[*] Checking core_pattern...
[-] Hmm, your system is configured to send core dump notifications to an
external utility. This will cause issues: there will be an extended delay
between stumbling upon a crash and having this information relayed to the
fuzzer via the standard waitpid() API.
To avoid having crashes misinterpreted as timeouts, please log in as root
and temporarily modify /proc/sys/kernel/core_pattern, like so:
echo core >/proc/sys/kernel/core_pattern
[-] PROGRAM ABORT : Pipe at the beginning of 'core_pattern'
Location : check_crash_handling(), afl-fuzz.c:7316
I'm a bit reluctant to change something unless I'm sure what I'm doing.
What's going on here? Should I listen to what AFL is saying?
You should probably change your core pattern, but you can change it back later. Many linux distros have a crash reporting service like apport, which relies on having core dumps from crashing processes piped to it via a core pattern like |/usr/share/apport/apport %p %s %c %d %P (see man 5 core) When the core pattern is set up this way, every time a program crashes, apport is run and the core is fed to it as standard input. So if you change the core pattern to just core, do your fuzzing, and then change the core pattern back to whatever it is currently, your distro's crash reporter should resume its normal operation.
AFL may have an environment variable to disable this check, as I know there exist environment variables to disable other pre-fuzzing checks (like AFL_SKIP_CRASHES allowing crashing input in the initial seeds), but this one is pretty low-cost to toggle.
The answer is right there in front of you.
log in as root and echo core >/proc/sys/kernel/core_pattern

JCL expected continuation not received

When starting a job it fails with JCL not run
173 IEFC621| EXPECTED CONTINUATION NOT RECIEVED
174 IEFC605| UNIDENTIFIED OPERATIONAL FIELD
The code
173 //STEP1 EXEC SASDUP,WORKU=SYSDU,WORK='100,25'
OPTIONS='MACRO SORTDEV=SYSDU FS X
174 // SYSPARM=''''2016040120160430'''''
//STEP1 EXEC SASDUP,
// WORKU=SYSDU,
// WORK='100,25',
// OPTIONS='MACRO SORTDEV=SYSDU FS SYSPARM=''''2016040120160430'''''
This is just freehand, I haven't tested it.
As #BillWoodger indicates, continuation can be quite tricky.
So first, there's missing a coma after you "WORK='100,25'" parameter. Second, make sure your continuity of statement never starts after position(cols) 16. It may also be over or under 16 though, depending on your emulator (look were a wrote here below). Third, the issue could be into your SASDUP application. Fourth, clean up your OPTION and SORTDEV parameters? I don't think it can work like that.
OPTIONS='MACRO SORTDEV=SYSDU FS X
?
Take a look at SASDUP, it may help you found which parameters it needs. And so, parameters for SASDUP must be separated with comas and, if on the next line, must begin at a specific position.
Try something like that.
//STEP1 EXEC SASDUP,WORKU=SYSDU,WORK='100,25',
*here* OPTIONS='MACRO',SORTDEV='SYSDUFSX'
//*here* SYSPARM='2016040120160430'
I'm far from a expert, but I hope it'll help you.

IMS init empty DB

i've got a problem, that i can't resolve.
I want to try to work with IMS. so i make dbdlib, psblib, and now write jcl to init my db.
1://RELOAD EXEC PGM=DFSRRC00,PARM='ULU,DFSURGL0,LIBDBD,,,,,,,,,,,N'
2://STEPLIB DD DISP=SHR,DSN=DFSD10.SDFSRESL
3://DFSRESLB DD DISP=SHR,DSN=DFSD10.SDFSRESL
4://IMS DD DISP=SHR,DSN=USER19.DBDLIB
5://DFSUINPT DD DUMMY
6://DFSVSAMP DD DISP=SHR,DSN=DFSD10.PROCLIB(VSAMP01)
7://SYSPRINT DD SYSOUT=*
8://DATABASE DD DISP=OLD,DSN=USER19.LIBIMS
This is my jcl. I've got rc 16 and such msgs in sysprint:
DFS386A A PREMATURE EOF WAS ENCOUNTERED ON DDNAME DFSUINPT
DFS339I FUNCTION DR HAS COMPLETED ABNORMALLY RC=16
I think, he want me putting some data in my db, but i only want to init EMPTY db
I don't think that you should be using DFSURGL0 as that's reload/unload utility as per
The HD Reorganization Reload utility (DFSURGL0) reloads databases and HALDB partitions by using the output data sets that are created by the HD Reorganization Unload utility (DFSURGU0).
I'd suggest haveing a look at the IBM Knowledge centre. This could be a good starting point as it's the initialisation utilities. Definition and initialization utilities
I can't be of much more help as it's been around 30 years or since I last used IMS Utilities and only have access to search the web in this respect.
In brief terms what you've encountered is the utility saying it expects some data in the ddname DFSUINPT and DD DUMMY results in END of DATA (EOF) immediately the DDNAME is accessed/read. So DFSURGL0 is complaining, hence CC=16. Another way of looking at this is that you told it, perhaps by default, to load the database, so it's saying what with.

SB37 JCL error to small a size?

The following space allocation is giving me an sB37 JCL error. The cobol size of the output file is 100 bytes and the lrecl size is 100 bytes. What do you think is causing this error? I have tried increase the size to 500,100 and still get the same error.
Code:
//OUTPUT1 DD DSN=A.B.C,DISP=(NEW,CATLG,DELETE),
// DCB=(LRECL=100,BLKSIZE=,RECFM=FBM),
// SPACE=(CYL,(10,5),RLSE)
Try to increase not only the space, but the volume as well.
Include VOL=(,,,#) in your DD. # is the numbers of values you want to allocate
Ex: SPACE=(CYL,(10,5),RLSE),VOL=(,,,3) - includes 3 volumes.
Additionally, you can increase the size, but try to stay within reasonable limits :)
The documentation for B37 says the application programmer should respond as indicated for message IEC030I. The documentation for IEC030I says, in part...
Probable user error. For all cases, allocate as many units as volumes
required.
...as noted in another answer. However, be advised that the documentation for the VOL parameter of the DD statement says...
If you omit the volume count or if you specify 1 through 5, the system
allows up to five volumes; if you specify 6 through 20, the system
allows 20 volumes; if you specify a count greater than 20, the system
allows 5 plus a multiple of 15 volumes. You can override the maximum
volume count in data class by using the volume-count subparameter. The
maximum volume count for an SMS-managed mountable tape data set or a
Non-managed tape data set is 255.
...so for DASD allocations you are best served specifying a volume count greater than 5 (at least).
//OUTPUT1 DD DSN=A.B.C,DISP=(NEW,CATLG,DELETE),
// DCB=(LRECL=100,BLKSIZE=,RECFM=FBM),
// SPACE=(CYL,(10,5),RLSE)
Try this instead. Notice that the secondary will take advantage of a large dataset whereas without that parameter the largest secondary that makes any sense is < 300. Oh, and if indeed it is from a COBOL program make sure that the FD says "BLOCK 0"!!!!! If it isn't "BLOCK 0" then you might not even need to change your JCL because it wasn't fixed block machine. It was merely fixed and unblocked so the space would almost never be enough. And finally you may wish to revisit why you have the M in the RECFM to begin with. Notice also that I took out the LRECL, the BLKSIZE and the RECFM. That is because the FD in the COBOL program is all you need and putting it in the JCL is not only redundant but dangerous because any change will have to be now done in multiple places.
//OUTPUT1 DD DSN=A.B.C,DISP=(NEW,CATLG,DELETE),
// DSNTYPE=LARGE,UNIT=(SYSALLDA,59),
// SPACE=(CYL,(10,1000),RLSE)
There is a limit of 65,535 tracks per one volume. So if you will specify a SPACE that exceeds that limit - system will simply ignore it.
You can increase this limit to 16,777,215 tracks by adding DSNTYPE=LARGE paramter.
Or you can specify that your dataset is a multi volume by adding VOL=(,,,3)
You can also use DATACLAS=xxxx paramter here, however first of all you need to find it. Easy way is to contact your local Storage Team and ask for one. Or If you are familiar with ISPF navigation, you can enter ISMF;4 command to open a panel
use bellow paramters before hitting enter.
CDS Name . . . . . . 'ACTIVE'
Data Class Name . . *
It should produce a list of all available data classes. Find the one that suits you ( has enougth amount of volume count, does not limit primary and secondary space

PARM value not interpreted as expected

Working in z/os mainframe, I have the following situation
1) That's my JCL, which I've submited:
//PAYMENT JOB MSGCLASS=H
//******************************************************************
//*
//* This job can be used to run an MQ application that
//* communicates with a transaction running in a CICS region.
//* The CICS transaction records a credit card payment in DB2.
//* The payment description has a maximum length of 35 characters.
//* It is enclosed within quotes below so that you may include
//* spaces to separate words.
//* The monetary values allowed by this tool must be within the
//* range 0.01 - 9999.99.
//*
//******************************************************************
//PAYMENT EXEC PGM=PAYMENT,REGION=1024K,
// PARM='CSQ1,CARD.PAYMENTS,CCD3050.REPLY,CCD3050,
// 400.05,"MY PAYMENT"'
//STEPLIB DD DSN=CCD3050.PART2.LOAD,DISP=SHR
// DD DSN=WMQ.V6R0.SCSQLOAD,DISP=SHR
// DD DSN=WMQ.V6R0.SCSQANLE,DISP=SHR
// DD DSN=WMQ.V6R0.SCSQAUTH,DISP=SHR
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
2) Looking at the job output in SDSF I see:
IRR010I USERID CCD3050 IS ASSIGNED TO THIS JOB.
$HASP373 PAYMENT STARTED - INIT 1 - CLASS A - SYS MVST
IEF403I PAYMENT - STARTED - TIME=12.06.31
- --TIMINGS (MINS.)-
-JOBNAME STEPNAME PROCSTEP RC EXCP CPU SRB CLOCK SERV PG PAGE SWAP VIO SWAPS STEPNO
-PAYMENT PAYMENT 01 39 .00 .00 .00 122 0 0 0 0 0 1
IEF404I PAYMENT - ENDED - TIME=12.06.31
-PAYMENT ENDED. NAME- TOTAL CPU TIME= .00 TOTAL ELAPSED TIME= .00
$HASP395 PAYMENT ENDED
0------ JES2 JOB STATISTICS ------
- 01 FEB 2014 JOB EXECUTION DATE
- 55 CARDS READ
- 111 SYSOUT PRINT RECORDS
- 0 SYSOUT PUNCH RECORDS
- 6 SYSOUT SPOOL KBYTES
- 0.00 MINUTES EXECUTION TIME
1 //PAYMENT JOB MSGCLASS=H
//******************************************************************
//*
//* This job can be used to run an MQ application that
//* communicates with a transaction running in a CICS region.
//* The CICS transaction records a credit card payment in DB2.
//* The payment description has a maximum length of 35 characters.
//* It is enclosed within quotes below so that you may include
//* spaces to separate words.
//* The monetary values allowed by this tool must be within the
//* range 0.01 - 9999.99.
//*
//******************************************************************
2 //PAYMENT EXEC PGM=PAYMENT,REGION=1024K,
// PARM='CSQ1,CARD.PAYMENTS,CCD3050.REPLY,CCD3050,
// 400.05,"MY PAYMENT"'
3 //STEPLIB DD DSN=CCD3050.PART2.LOAD,DISP=SHR
4 // DD DSN=WMQ.V6R0.SCSQLOAD,DISP=SHR
5 // DD DSN=WMQ.V6R0.SCSQANLE,DISP=SHR
6 // DD DSN=WMQ.V6R0.SCSQAUTH,DISP=SHR
7 //STDOUT DD SYSOUT=*
8 //STDERR DD SYSOUT=*
9 //SYSPRINT DD SYSOUT=*
ICH70001I CCD3050 LAST ACCESS AT 15:55:39 ON WEDNESDAY, JANUARY 29, 2014
IEF236I ALLOC. FOR PAYMENT PAYMENT
IGD103I SMS ALLOCATED TO DDNAME STEPLIB
IGD103I SMS ALLOCATED TO DDNAME
IGD103I SMS ALLOCATED TO DDNAME
IGD103I SMS ALLOCATED TO DDNAME
IEF237I JES2 ALLOCATED TO STDOUT
IEF237I JES2 ALLOCATED TO STDERR
IEF237I JES2 ALLOCATED TO SYSPRINT
IEF142I PAYMENT PAYMENT - STEP WAS EXECUTED - COND CODE 0001
IGD104I CCD3050.PART2.LOAD RETAINED, DDNAME=STEPLIB
IGD104I WMQ.V6R0.SCSQLOAD RETAINED, DDNAME=
IGD104I WMQ.V6R0.SCSQANLE RETAINED, DDNAME=
IGD104I WMQ.V6R0.SCSQAUTH RETAINED, DDNAME=
IEF285I CCD3050.PAYMENT.JOB03520.D0000101.? SYSOUT
IEF285I CCD3050.PAYMENT.JOB03520.D0000102.? SYSOUT
IEF285I CCD3050.PAYMENT.JOB03520.D0000103.? SYSOUT
IEF373I STEP/PAYMENT /START 2014036.1206
IEF374I STEP/PAYMENT /STOP 2014036.1206 CPU 0MIN 00.00SEC SRB 0MIN 00.00SEC VIRT 16K SYS 320K EXT 280K SYS 11012K
IEF375I JOB/PAYMENT /START 2014036.1206
IEF376I JOB/PAYMENT /STOP 2014036.1206 CPU 0MIN 00.00SEC SRB 0MIN 00.00SEC
3) And then I see these messages:
********************************************************
Credit card payment unit test tool
********************************************************
Incorrect usage!
Program Usage
-------------
PAYMENT <queue manager> <cics request queue> <reply queue> <userid> <payment value> <payment description>
The payment description has a maximum length of 35 characters.
The monetary value must be within the range 0.01 - 9999.99.
What am I doing wrong?
The program you are using is doing you no favours. It is good practice for all programs which receive a PARM to show the value that has been passed to them.
Compile and execute this program, with the PARM exactly as you have specified it:
ID DIVISION.
PROGRAM-ID. PROGNAME.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 W-WHEN-COMPILED PIC X(8)BX(8).
LINKAGE SECTION.
01 THE-PARM-FROM-THE-JCL.
05 TPFTJ-LENGTH BINARY PIC 9(4).
05 TPFTJ-VALUE.
10 FILLER OCCURS 0 TO 100 TIMES
DEPENDING ON TPFTJ-LENGTH.
15 FILLER PIC X.
PROCEDURE DIVISION USING
THE-PARM-FROM-THE-JCL
.
MOVE WHEN-COMPILED TO W-WHEN-COMPILED
DISPLAY "PROGNAME " W-WHEN-COMPILED
DISPLAY
">"
TPFTJ-VALUE
"<"
GOBACK
.
You should see this as your output:
PROGNAME followed by date-and-time-of-compile
>CSQ1,CARD.PAYMENTS,CCD3050.REPLY,CCD3050, 400.05,"MY PAYMENT"<
You will see that chunk of blanks in the middle. That is your problem.
I don't know if you actually want the double-quotes around MY PAYMENT.
Assuming not, this would be one way to code your PARM:
// PARM=('CSQ1,CARD.PAYMENTS,CCD3050.REPLY,CCD3050',
// '400.05,MY PAYMENT')
The above program will show you this value:
>CSQ1,CARD.PAYMENTS,CCD3050.REPLY,CCD3050,400.05,MY PAYMENT<
If you look at this, you'll see the problem and some resolutions described: http://publib.boulder.ibm.com/infocenter/zvm/v5r4/index.jsp?topic=/com.ibm.zos.r9.ieab100/jclexs.htm. This example is for the binder (IEWL). You should also consult the JCL Reference manual for your particular release of z/OS (although any one should do, I don't think PARM processing has changed under z/OS).
Continuations of PARM are tricky, because there are certain characters which have meanings to JCL. One way of continuing is to use up to column 71 and then continue in column 16. This is not very flexible. Enclosing the PARM value in parenthesis is more flexible. You also have several full-stops/periods, and those values need to be protected by single-quote pairs. The JCL Reference will detail all, and then you experiment with the above program to achieve full clarity.