I'm just starting COBOL, and ran into this with JCL... How do I compile a basic cobol program from my PDS, I know through instream it would just be
//SYSIN DD *
code code code
/*
I tried something like
//SYSIN DD DSN=the.pds.location(file),DISP=SHR
but all that shot back was garbage and a return code of 12 I think.
If anyone could help, I would be grateful.
Based on the information you have posted, your JCL
should work. Maybe you are missing something else.
The following JCL provides the full job step to do
a COBOL compile:
... your job card goes here...
//COB EXEC PGM=IGYCRCTL
//STEPLIB DD DISP=SHR,DSN=SYSP.IGY.V3R4M1.SIGYCOMP
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSUT2 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSUT3 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSUT4 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSUT5 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSUT6 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSUT7 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSLIN DD DSN=objectmodule,UNIT=SYSDA,
// DISP=(MOD,PASS),SPACE=(TRK,(3,3))
//SYSIN DD DSN=the.pds.location(file),DISP=SHR
//SYSPRINT DD SYSOUT=*
... your link step using object from SYSLIN above...
Note: You might have to change the STEPLIB to match the
version of COBOL running at your site.
If your JCL looks pretty close to the above, the next thing to
check out is your COBOL program. Go into the ISPF editor (I presume
you have access to it) and type PROFILE on the command line. You
should see something like:
=PROF> ....GEN (FIXED - 80)....RECOVERY OFF WARN....NUMBER OFF.................
=PROF> ....CAPS ON....HEX OFF....NULLS ON STD....TABS OFF......................
=PROF> ....AUTOSAVE ON....AUTONUM OFF....AUTOLIST OFF....STATS ON..............
=PROF> ....PROFILE UNLOCK....IMACRO NONE....PACK OFF....NOTE ON................
=PROF> ....HILITE OFF CURSOR FIND..............................................
=BNDS> <
=COLS> ----+----1----+----2----+----3----+----4----+----5----+----6----+----7--
Now have a look for PACK ON (note the above shows PACK OFF). If you find
PACK ON this is your problem. You need to issue the PACK OFF command
and save your dataset. Try the compile again.
BTW... you get rid of the profile display by typing RESET on the command
line.
If neither one of these fix your problem you need to provide a more information
as to what the exact nature of the problem is.
Related
I have business logic in CICS, we want to replace maps/ mapsets with distributed systems, so we want our CICS programs to provide service and have distributed system (to replace maps/ mapsets) that sends request and receive response from CICS are processing. This is for Legacy payment application and is non-SSP environment.
As first step, I am trying to submit JCL that creates WSDL and WSBIND files using CICS webservice assistant tool (DHFLS2DS) but I am not sure about the parameters to be passed, that executes BPXBATCH.
//JAVAPRG1 EXEC PGM=BPXBATCH,REGION=400M,
// PARM=('SH &PATHPREF/usr/lpp/cicsts/&USSDIR/lib/wsdl/DFHLS2WS ', X
// '&JAVADIR &USSDIR &TMPDIR./&TMPFILE. &SERVICE &PATHPREF')
Can someone please help with required parameters to be passed to execute CICS webservice assistant tool?
Not answering your parameter question, but commenting on the JCL.
//JAVAPRG1 EXEC PGM=BPXBATCH,REGION=400M,
//*.+....1....+....2....+....3....+....4....+....5....+....6....+....7..
// PARM=('SH &PATHPREF/usr/lpp/cicsts/&USSDIR/lib/wsdl/DFHLS2WS ', X
// '&JAVADIR &USSDIR &TMPDIR./&TMPFILE. &SERVICE &PATHPREF')
Note that the maximum length of the PARM= data is 100 characters. This is a JCL limit. Your PARM will probably exceed 100 characters after symbolic parameter resolution.
BPXPATCH has implemented the //STDPARM DD statement as an alternative way to pass parameters. There is a limit of 65536 characters on //STDPARM. See here for details: Running shell scripts or executable files under MVS environments - Topic BPXBATCH.
The modified JCL for the step would look smoething like this:
//JAVAPRG1 EXEC PGM=BPXBATCH,REGION=400M
//... put any other DD statements for BPXBATCH phere
//...
//STDPARM DD *
SH
&PATHPREF/usr/lpp/cicsts/&USSDIR/lib/wsdl/DFHLS2WS
&JAVADIR &USSDIR
&TMPDIR./&TMPFILE. &SERVICE &PATHPREF
/*
But there is the problem of resolving the JCL symbolic parameters within SYSIN data, which is not done by default. You need to enable symbolic parameter resolution by changing the DD statement to look like this:
//STDPARM DD *,SYMBOLS=(JCLONLY)
Additionally, you need tell which parameters you want to be eligible for resolution in SYSIN data. This is done with the following statement before your EXEC statement, and before any symbolic parameter that you might SET. Best place is immediately following the JOB statement.
// EXPORT SYMLIST=*
Note that your systems programmer must have allowed this for the job class your job will run in. The job class must have been set to SYSSYM=ALLOW.
The final JCL looks like this:
//jobname JOB ....
//... any job level parameters you need go here
//*
// EXPORT SYMLIST=*
//*
//... any additional symbolic parameters are set here
//*
//JAVAPRG1 EXEC PGM=BPXBATCH,REGION=400M
//... put any other DD statements, BPXBATCH requires here
//...
//STDPARM DD *,SYMBOLS=(JCLONLY)
SH
&PATHPREF/usr/lpp/cicsts/&USSDIR/lib/wsdl/DFHLS2WS
&JAVADIR &USSDIR
&TMPDIR./&TMPFILE. &SERVICE &PATHPREF
/*
Warning: I have not actually run that JCL, since I do not know what all the symbolic parameters are set to in your environment.
Final note: Enabling Symbolic parameter resolution in SYSIN data doesn't look like a straight forward process, does it?. IBM had to implement this in a way that guaranteed not to break any existing job (JCL). Once you get used to it, it is nevertheless a very useful thing, IMHO.
The JOB Symbolic parameters and SYSIN parameters are explained in this official IBM document
Mainly, we need to check the location of DFHLS2WS program present in the Z/OS Unix file path and pass in the symbolic parameter - JAVADIR and we can use the default parameters for the remaining symbolic parameters unless you have a requirement to change it.
Note : all parameters are not required.
Please pass the SYSIN parameters as per your application and requirement. The significance of all the parameters are explained in the above document.
After submitting this job I am unable to find SYSOUT in spool.
The JCL follows:
//IBMUSERP JOB NOTIFY=&SYSUID
//STEP2 EXEC PGM=PERFORM1
//STEPLIB DD DSN=IBMUSER.RKSH.LOAD,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSIN DD *
/*
//
I'm going to provide some general guidance as your question is going to get an "it depends" answer.
It looks like your most likely on a ZD&T system since you are using IBMUSER as your dataset prefix.
I used an IDCAMS utility to do my tests as I know it produces output. I would try this first to verify your system is working correctly.
//DEFCAT1 JOB (ACCT),NOTIFY=&SYSUID.,REGION=0M
//STEP1 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
LISTC ENT(IBMUSER)
/*
If the above works and you can find the output your program PERFORM1 may not be working correctly and is not generating any output. Perhaps you can provide a minimum working sample to ensure that your program is working correctly.
Submitting a similar job but using a JOB card with a MSGCLASS=H (which is the default I've been using) worked fine and the output appears in SDSF. Make sure you have your prefix set correctly and use a wildcard. Something like PRE IBMUSER* for your example.
Where the output goes depends on how JES is setup on your system. Your JOB card does not have a MSGCLASS but uses SYSOUT=* which indicates to use the job's default MSGCLASS. That is defined in your JESPARM statements
Check your system log to make sure your output is not being 'printed' to a device.
Use the following commands:
LOG to view the system log
ST to see the job status
H to find held output that doesn't have a destination
O to find output that is ready to print but is waiting for a device.
If you are using TSO-ISPF then go to ISPF main menu and open SDSF. Enter st(job status) to open spool. find the job by 's userid' or 's job name'. select the job and you can check Sysout, Sysprint.
I just recognized you don't have JOB statement parameters, except from NOTIFY=. Your environment probably requires you to at least add the CLASS= parameter to tell the system in what jobclass to run your job. Maybe other parameters are requested too.
Usually, jobs are killed before execution if the minimum required JOB parameters are not specified.
I suggest you submit again, then go to SDSF and have a look at the system log or operlog by typing log in SDSF's command line, then search for messages related to you jobname.
Alternatively, supply at least the CLASS= parameter, and see if the job is run then.
I'm using lua script to run redis commands and use {{redis.log()}} in it. It prints the format as mentioned below. But I wanted to change to time format in the log. i.e dd-MM-yyyy HH:mm:ss.SSS instead of default format (dd MMM hh:MM:ss.SSS which I assume)
Format:
[pid] date loglevel message
For instance:
[4018] 14 Nov 07:01:22.119 * Background saving terminated with success
How can I do this?
Regrettably, no, there are no "user serviceable" knobs for this. The output to the log is always preceded by a timestamp in the hardcoded format that's specified in server.c:
off = strftime(buf,sizeof(buf),"%d %b %H:%M:%S.",localtime(&tv.tv_sec));
My COBOL program reads a VSAM file that may or may not be empty. When the file is empty i get a status code 35 while opening in INPUT/I-O mode. I do not want to handle it in program but in a JCL. Is there any way by which VSAM file can be checked if it is empty or not...if it is not possible through a JCL then can we handle it in program without having to check status code 35?
Add OPTIONAL to the SELECT clause in the FILE-CONTROL paragraph.
SELECT OPTIONAL fdname
ASSIGN TO ddname
...
When you get a starus "35" exit the program with a
MOVE 8 TO RETURN-CODE.
GOBACK.
[example here][1]
http://ibmmainframes.com/about60344.html
You can then test for a non-zero return code in your JCL with a COND=8 on the next step which will only execute when your program detected an empty file.
I seem to recall that you could use IDCAMS to repo the file into a dummy dataset and you would get an RC=4 if it was empty.
That is from memory a few years ago, but then you could put that check in your job stream before running your program and control execution of the next step using the IDCAMS return code.
I am learning mainframe programming now. I got a tso id with Dezhi and I am using PASSPORT terminal emulator.My user is CATIA81
I uploaded a few jobs and a cobol program to test. I tried to submit a job through the ISPF COMMAND SHELL:
SUBMIT CATIA81.KSDCRTJ1.JCL
AND I GET THE FOLLOWING ERROR:
SUBMIT cancelled, JOBNAME must start with CATIA81
This is what I have
//CATIA81KDEL1 JOB CSBL81,CLASS=1,MSGCLASS=0,NOTIFY=CSIP1
//* *******************************************************************
//* This program is provided by: SimoTime Enterprises *
//* (C) Copyright 1987-2012 All Rights Reserved *
//* Web Site URL: http://www.simotime.com *
//* e-mail: helpdesk#simotime.com *
//* *******************************************************************
//* Subject: JCL to delete a VSAM Data Set using the IDCAMS Utility *
//* Author: SimoTime Enterprises *
//* Date: January 1, 1998 *
//*-------------------------------------------------------------------*
//* The following example is more than what is usually required to *
//* delete a VSAM Data Set. However, the purpose is to illustrate the *
//* functions of the IDCAMS utility. *
//*********************************************************************
//*
// EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DELETE CATIA81.DATA.VKSD0080 -
FILE (VKSD0080) -
PURGE -
ERASE -
CLUSTER
SET MAXCC = 0
/*
//
The orginal JOBNAME was KSDDELJ1, which I altered to CATIA81KDEL1.
What was(were) my mistake(s)?
Job names can be no longer than 8 characters, change the job name from CATIA81KDEL1 to CATIA81K
Besides the job name cannot be longer than 8 characters, you also want to enclose your data set name in quotes unless you don't want it to be explicitly fully-qualified. Otherwise, TSO adds your user prefix to the front of the name.
The prefix normally matches the user ID but can be set differently using the TSO PROFILE command. To see what is defined in your environment, you can run this little REXX-script:
/* REXX */
say 'sysvar(syspref):' sysvar(syspref)
say 'sysvar(sysuid): ' sysvar(sysuid)