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)
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 Jenkins 2.46.2 version. I have installed Parameterized Scheduler plugin to trigger the build periodically with different parameter.
But it fails to trigger the build at scheduled time.
You have a problem with the ";" on parameters.
you have to insert space after each parameter, for example:
H/2 * * * * % EndMarket=can ;GitBranch=DevelopmantBranch
try without spaces between params, like:
0 8 * * * % base_url=https://www.example.com;suite_type=Regression
I installed the plugin on Jenkins 2.67, and it works. I had the same problem with builds failing to trigger with earlier version of Jenkins.
in my case, my parameter is Choice Parameter, so if I set the scheduler below and 'valueabc' is not in the list of choice, it will fail to start
H/15 * * * * %name=valueabc
NSLog() uses timestamps with millisecond resolution, but is a blunt instrument because all its log messages are at the Warning level.
Apple System Log is a much more fine-grained system, with 8 different levels. BUT... its timestamps have only 1-second resolution. I read the man page about time formats, but they all seem to be to the second only.
Clearly this information is available, at least to NSLog. A lot can go on in a second; is there a way to get better resolution with ASL?
You can append ".#" to the time format in ASL (and syslog) to specify the precision. Thus "utc.3" would format in UTC format with milliseconds. You can add this to both the msg_fmt or time_fmt arguments.
Time format precision appears to only be documented in syslogd(1). I am not sure why it didn't make it to asl(3).
For example, using asl_add_output_file and specifying in the time_fmt might look like this:
// setup, do once!
aslclient log = asl_open(NULL, NULL, 0);
asl_add_output_file(log, STDERR_FILENO,
"$Time $((Level)(str)) - $Message", // $Time here uses time_fmt arg on next line
ASL_TIME_FMT_UTC ".3", // time_fmt: append ".3" for milliseconds here
ASL_FILTER_MASK_UPTO(ASL_LEVEL_DEBUG), ASL_ENCODE_SAFE);
// example log
asl_log(log, NULL, ASL_LEVEL_INFO, "Hello");
// Note in the above ASL_TIME_FMT_UTC is #defined to "utc", so the we're
// using compile-time string concatenation of "utc" ".3" to "utc.3".
// Alternately you can just specify "utc.3" directly.
and output:
2016-02-01 19:16:39.561Z Info - Hello
Specifying in msg_fmt argument of asl_add_output_file might look like this:
// setup, do once!
aslclient log = asl_open(NULL, NULL, 0);
asl_add_output_file(log, STDERR_FILENO,
// in msg_fmt below, use ISO8601 + ".6" for microseconds
"$((Time)(ISO8601.6)) $((Level)(str)) - $Message",
ASL_TIME_FMT_UTC,
ASL_FILTER_MASK_UPTO(ASL_LEVEL_DEBUG), ASL_ENCODE_SAFE);
// example log
asl_log(log, NULL, ASL_LEVEL_INFO, "Hello");
and output:
2016-02-01T14:16:39.562030-05 Info - Hello
(I would caution that the above snippets of code are only meant to demonstrate specifying the time format precision in ASL. Actual usage should likely involve a dispatch_once for setup, use a serial dispatch queue for logging.)
Use ts shell command to add milliseconds to any log.
idevicesyslog | ts '[%Y-%m-%d %H:%M:%.S]'
How can I determine the compile options used to compile an IBM Enterprise COBOL program by looking at the load module? When a dump is issued they are listed as follows:
Compile Options for PROGXX:
ADV, ARITH(COMPAT), AWO, NOCICS, CODEPAGE(01140), DATA(31), NODATEPROC,
NODBCS, NODLL, NODYNAM, NOEXPORTALL, NOFASTSRT, INTDATE(LILIAN),
NUMPROC(NOPFD), NOOPTIMIZE, OUTDD(SYSOUT), PGMNAME(COMPAT), RENT, RMODE(AN
NOSQL, SQLCCSID, SSRANGE, NOTEST, NOTHREAD, TRUNC(OPT), XMLPARSE(XMLSS),
YEARWINDOW(1900), ZWB
so I presume they must be tucked away somewhere in the load module.
I want to scan a load library checking that each load was compiled with some specific options to ensure compliance to shop standard (eg. SSRANGE).
Any ideas would be appreciated.
Update
I have since written an LE Cobol load module scanning program which does this job and a bit more besides. If you are interested check out: http://www3.sympatico.ca/bredam/LoadInfo.html
Perhaps this is a start. From the CBT Tape:
//* * FILE 551
//***FILE 552 is from Marc Manuel, and contains a COBOL 2 and * FILE 552
//* COBOL/MVS analysis program. This program will list * FILE 552
//* the compile options of COBOL load modules. * FILE 552
//* * FILE 552
//* email: "MANUMAN" <manuman#club-internet.fr> * FILE 552
Something in there may be useful ...
Roland Schiradin's COBANAL is free, or there's the commercial product Edge Portfolio Analyzer
There is quick mainframes tutorials and compiler options at link
http://techpalli.blogspot.com/p/mainframes.html