This form controls Jazz Processing and Job Submission. It appears when the [Process] button is right-clicked, or if the [Process] button is clicked and the checkbox “Show this form on left click” is checked.
It looks like this, when used for direct z/OS testing: -
When you are using an IDE (Visual Studio or Eclipse) for testing your programs the IDE tab appears, the Manual FTP section at the bottom disappears, and some of the buttons change. However its function remains essentially the same: -
If we click [Test], or we click [Process] on the Workbench and the checkbox “Show this form on left click” is not checked, then Jazz goes through the following steps: -
Direct z/OS testing: -
1. The program is checked. Errors may be reported, keywords will be highlighted, and the code will be indented.
1. Provided that no errors exceeding the maximum severity level (set by [Configure])have been detected, COBOL will be generated
2. Provided that no further errors exceeding the maximum severity level have been detected, JCL is generated, and then
3. The job is submitted to the z/OS system. Temporary objects (COBOL and JCL, and other jobs) are deleted unless the relevant Save Locally option is checked, and the Process form is closed.
4. On return to the Jazz Workbench various messages are produced as the program waits for the job results.
5. When the job has been run the results are returned, and the button [Job Results] is highlighted. Clicking this allows the job output to be displayed.
1. The program is checked. Errors may be reported, keywords will be highlighted, and the code will be indented.
2. Provided that no errors exceeding the maximum severity level (set by [Configure])have been detected, COBOL will be generated
3. If this is a batch program, JCL will be generated
4. Clicking the [Test] button closes the Process form, and highlights the “Job Results” button, which will have the name or your IDE project as its caption.
5. Clicking this [project] button will start an IDE session on your associated COBOL project, where you can test your COBOL program.
6. [Test] will also add your newly-created COBOL [and JCL] objects into the project, ensure that the Microfocus Enterprise Server is running, build the project, and (if a batch program) submit the JCL for a test, and then open the output. (If I can figure out how to do this J)
Normal processing goes through stages Check Jazz, Generate COBOL, Generate JCL, Submit compile and retrieve job output. You can run this sequence up to an earlier step, and you can restart the process.
Click one of the buttons [Check], [Generate], or [JCL] to process the program only up to this stage. The program will be processed up to this step (unless there are errors in a preceding step), and the checkbox after the last successful step will be checked. In the example below we have just clicked [JCL] and processing has been normal up to this point, so the “Submit” checkbox is checked. Now if we click [Submit] or any of the other buttons below this checkbox Jazz starts with the job submission, without re-running the earlier steps.
If you click [Generate] then you can click [Review COBOL] to view the COBOL program in Notepad, and edit it if you wish, then continue with the edited COBOL. Similarly after clicking [JCL] you can click [Review JCL to edit the generated JCL before continuing.
When you open the [Process] form initially you’ll see buttons [Find COBOL] and [Find JCL] instead of [Review COBOL] and [Review JCL]. When COBOL has been generated the first button will change from [Find COBOL] to [Review COBOL], and when JCL has been generated the second button changes from [Find JCL] to [Review JCL]. While the buttons say “Find” instead of “Review” you can click them to open a Windows Explorer dialog and search for a file. You can edit this file, and submit it for later-stage processing.
Note that if you submit your own COBOL program then probably you should also submit your own JCL unless you are simply making minor changes to the COBOL that was generated from the Jazz program. The automatically-generated JCL will be based on templates and the original program, and may have the wrong DD statements in the RUN step. Thus if you start with a Jazz BATCH program that does not use SQL, and then locate a different type of COBOL program (for example, a CICS program the does use SQL), the Jazz-generated JCL will be appropriate for compiling and running your original batch non-SQL program, not the CICS SQL program.
If you click [Find COBOL] then you can browse for existing COBOL (xxx.CBL) and continue with that. This gives you a way of using this submission facility for your own COBOL programs and subprograms. The name will be taken from the located object name. For example, if you start your session with Jazz program
but use [Find COBOL] to locate
then the session name will be changed from Prog1 to Prog2, and the COBOL will be uploaded your mainframe source library as member Prog2.
If you click [Find COBOL] then Jazz will check COBOL in the Save Locally section of the Process form. Otherwise the local version of your COBOL program would be deleted when the job is returned, and you’d have to recover it from the mainframe. Uncheck this if you want it deleted as normal.
You may need to be a a bit careful with the JCL. Jazz determines the type of JCL to use from the characteristics of the Jazz program. If Prog1.Jzz had started
PROGRAM CICS1 CICS …
then Jazz will generate appropriate JCL to compile a CICS program. If you now use [Find COBOL] to locate Prog2 and continue with this it will use CICS JCL, not batch JCL, even if Prog2 is a batch program. Similarly if Prog1 had been a batch program but Prog2 is CICS it will compile Prog2 with the wrong JCL. If you have any doubts stop the process after [Generate JCL] and before [Submit] to check.
As with COBOL, you can use [Find JCL] to find and then run your own JCL. This is particularly useful for utility jobs like IDCAMS to create a VSAM file. [Find JCL] looks for .JCL and .JZL files: you can select one and Jazz will submit this job. As for COBOL, if you click [Find JCL] then Jazz will check JCL in the Save Locally section of the Process form so that your JCL is not deleted when the job is returned.
JZL is like standard z/OS JCL except that it may contain parameters like @Username that are substituted by Jazz before the job is sent to z/OS.
Neither JCL nor JZL should contain a JOB statement: if the first line is a JOB statement then the line will be dropped. Note that JOB statements that take more than one line when conforming to z/OS JCL rules should be written as a single line for Jazz. Jazz will split JCL statements at valid continuation points when they are written to z/OS. If you write a multi-line JOB statement and submit it through this facility then only the first line of the JOB statement will be dropped, and the resulting JCL will not be valid.
The three buttons
are alternatives. The default is [Submit], which will submit a job to z/OS that will compile the COBOL program and, if it is a batch job, attempt to run it.
[Compile] does exactly the same as Submit for a CICS job. For batch jobs however it omits the run step.
[Run Only] runs only the GO step of a batch compile and run job. Use this if you want to re-run a report, perhaps after changing the JCL.
You can choose between z/OS and IDE. Which IDE? (Visual Studio or Eclipse) is set in Configuration.
These values are from the COBOL tab of Configuration.
· Max Jazz Error Level. Jazz messages may be
o Information. Something that we thought you might like to know, not an error.
o Warning. Perhaps an error, but almost certainly not.
o Error. Probably an error, but Jazz has made some changes/assumptions and the program may be OK.
o Severe Error. Definitely an error, and Jazz hasn’t been able to fix it up. However Jazz is able to continue with the following statements and generate a program, but the program is unlikely to be correct.
o Terminal Error. This error is very serious, probably caused by a program fault within Jazz, and Jazz cannot continue.
Thus if you select a max error level of Severe Error, then Jazz will generate COBOL even if there are S-level messages.
These values are from the z/OS tab of Configuration, and must be correct for your z/OS system. If the FTP port (21 in this example) is correctly configured then Jazz will detect that FTPS (Secure FTP) is available and use this automatically instead of basic File Transfer Protocol.
The project is from the Workbench tab of Configuration.
With direct z/OS testing, if nothing is checked then Jazz will generate COBOL, generate JCL, and submit the job. After the COBOL has been successfully uploaded to the z/OS system the local copy is deleted, and after the job has been submitted the JCL and all previous jobs are deleted. This is to keep your local files as clean as possible: you don’t normally need the COBOL or JCL, and if jobs are not deleted your job output folder will get pretty cluttered. However you can check any of these to have the object retained locally.
With IDE testing these are irrelevant and don’t appear.
At the bottom of the form are a series of controls to enable you to explicitly FTP objects to/from the mainframe.
This provides the ability to have jobs that were submitted through TSO/ISPF returned to your Windows environment in the same way as jobs that were submitted from the Jazz workbench. For example, this job was submitted from ISPF: -
and it was sitting on the held-output queue as JES job JOB04710: -
We enter JOB04710 and click [Get Job]: -
The job is downloaded from JES to our PC, and removed from the Class H output queue. When this is completed we are returned to the Jazz workbench, where the Job Results button will be highlighted and clicking it will display the job output with Notepad.
Local identifies the source file for [Upload], the destination file for [Download]. z/OS identifies the file on the mainframe that is the target for upload, or the source for download. Either file may be identified using @ parameters: these are substituted in the same way as described for JCL.
The default value is set to the object currently in the Jazz workbench. The local reference is given as a full path: -
For upload the file may alternatively be identified as an HTTP//: or HTTPS:// reference to a WSDL web page. See Uploading WSDL below for more details
For upload the file (or WSDL web page) must exist. For download its path must exist, but the object need not. If it does exist, it will be overwritten if the FTP is successful
This identifies the mainframe file that is the destination for [Upload], the source for [Download]. This may identify a file in the z/OS file system, including a member of a PDS, or file in the HFS. If a file in the HFS it’s name should start with /u/, and if you use @ parameters as part of the name then note that directory (and object) names are case sensitive, and you might need to remember to use the appropriate parameter, such as @lcProject rather than @Project.
Check this if you want the file uploaded/downloaded without any conversion. If unchecked then FTP will convert between ASCII in the Windows environment and EBCDIC in the mainframe environment. You will probably leave this unchecked except when you are uploading WSDL, or transferring non-character data – images, binary data, etc.
Special facilities are provided to upload WSDL, which you might use if you want to explicitly manage DFHWS2LS jobs. Give the local file as HTTP://URI, where URI is the web identifier of the service. It must either end in “.WSDL” or “?WSDL”, and the z/OS file must be within the HFS and end with “.wsdl”.
You may want to check As Binary if you are using this option. Even though the WSDL is character data, it will internally identify its character encoding and errors may be reported if the IBM Web Services Assistant program DFHWS2LS finds an inconsistency.