Invalid Job Spool Display

[jellypuno]

Describe the bug

The user executed a JCL with a Job card that started with:

//SET1 SET PN=EXER3
//&PN JOB

This resulted to a JCL Error and Zowe Explorer displayed it like this:

To Reproduce

Steps to reproduce the behavior:

1. Run a JCL with a Job Card similar to the one above
2. Submit it
3. Retrieve the result in Zowe Explorer
4. See error

Expected behavior

A better error handling

Screenshots

Error Message:

From Zowe CLI:

Desktop (please complete the following information):

• OS: Windows 10
• Zowe Explorer Version: 1.6.0
• (Optional) Zowe CLI Version: 6.13.0
• (Optional) Are you using Secure Credential Store? No

Additional context

Follow the conversation: https://openmainframeproject.slack.com/archives/C011NE32Z1T/p1591632786034100

[zdmullen]

Possible solution here:
We should only show the name of the JCL and "JCL error" next to it, without any entries for JES (since there not any produced). This would keep things clean and prevent users from selecting something that provides large error messages.

[zdmullen]

This is dependent on type of security being used, RACF vs ACF2 etc., because they may offer more in the DD.

[jellypuno]

This is still happening for v1.18.1

[roman-kupriyanov]

Hi, I am taking this one into work 😃

[roman-kupriyanov]

After some investigation, I found a weird behavior of z/OSMF service, which in our case of JCL ERROR returns a list of Job documents, instead of Job file documents. This is undocumented by IBM, since docs state that if response is successful, an empty list or a list of Job file documents is expected.

For ZE it means that the list of undefined items for a job depends on a count of jobs in the list, since API call returns the list of available jobs instead. And because JSON structure for Jobs is not the same as for Job files obviously, the fields we expect are not there.

For Zowe/CLI it seems the same, but it filters out for specific JSON fields in response, so we can see only an array of empty objects:

❯ zowe jobs ls sfbj job00392 --zosmf-profile cobolprg --rft string
[{},{}]

❯ zowe jobs ls sfbj job07993 --zosmf-profile cobolprg --rft string
[{},{},{},{},{}]

[roman-kupriyanov]

@phaumer While preparing a post with the results from REST client, I was struck by a realisation.

The reason is not in JCL ERROR status, but in the name of a job itself, in our case: ?PN. Seems like & to ? substitution breaks the URI of the required resource:

https://server:443/zosmf/restjobs/jobs/?PN%2FJOB00239%2Ffiles

Since ? is a query delimiter, containing in the job name, it basically makes the URI equal to just https://server:443/zosmf/restjobs/jobs/, which returns that unexpected list of the jobs, instead of job files.

The & -> ? substitution happens on the z/OSMF side though:

  {
    "owner": "Z88254",
    "phase": 20,
    "subsystem": "JES2",
    "phase-name": "Job is on the hard copy queue",
    "job-correlator": "J0000392SVSCJES2DA9F8C8F.......:",
    "type": "JOB",
    "url": "https:\/\/zowe:443\/zosmf\/restjobs\/jobs\/J0000392SVSCJES2DA9F8C8F.......%3A",
    "jobid": "JOB00392",
    "class": "A",
    "files-url": "https:\/\/zowe:443\/zosmf\/restjobs\/jobs\/J0000392SVSCJES2DA9F8C8F.......%3A\/files",
    "jobname": "?PN",
    "status": "OUTPUT",
    "retcode": "JCL ERROR"
  },

Considering that, I guess there is no issue with z/OSMF service itself from this point of view. It just does what being asked.

On the other hand, it might return job names that cannot be used to retrieve any spool files, at least by using job name. There is another URL form - using correlator or taking URL from files-url field of the job, which works as expected even for unreliable job names:

[
  {
    "recfm": "UA",
    "records-url": "https:\/\/1zowe:443\/zosmf\/restjobs\/jobs\/J0000392SVSCJES2DA9F8C8F.......%3A\/files\/2\/records",
    "stepname": "JES2",
    "subsystem": "JES2",
    "job-correlator": "J0000392SVSCJES2DA9F8C8F.......:",
    "byte-count": 316,
    "lrecl": 133,
    "jobid": "JOB00392",
    "ddname": "JESMSGLG",
    "id": 2,
    "record-count": 11,
    "class": "A",
    "jobname": "?PN",
    "procstep": null
  },
  {
    "recfm": "V",
    "records-url": "https:\/\/zowe:443\/zosmf\/restjobs\/jobs\/J0000392SVSCJES2DA9F8C8F.......%3A\/files\/3\/records",
    "stepname": "JES2",
    "subsystem": "JES2",
    "job-correlator": "J0000392SVSCJES2DA9F8C8F.......:",
    "byte-count": 110,
    "lrecl": 136,
    "jobid": "JOB00392",
    "ddname": "JESJCL",
    "id": 3,
    "record-count": 1,
    "class": "A",
    "jobname": "?PN",
    "procstep": null
  },
  {
    "recfm": "VA",
    "records-url": "https:\/\/zowe:443\/zosmf\/restjobs\/jobs\/J0000392SVSCJES2DA9F8C8F.......%3A\/files\/4\/records",
    "stepname": "JES2",
    "subsystem": "JES2",
    "job-correlator": "J0000392SVSCJES2DA9F8C8F.......:",
    "byte-count": 130,
    "lrecl": 137,
    "jobid": "JOB00392",
    "ddname": "JESYSMSG",
    "id": 4,
    "record-count": 3,
    "class": "A",
    "jobname": "?PN",
    "procstep": null
  }
]

[roman-kupriyanov]

After a discussion with @jellypuno, a solution for now should be to prevent displaying undefined:undefined(undefined) items all together, when API returns non-Job File Documents for any reason.