Sanity test on CLI console may fail randomly

[jackjia-ibm]

Describe the bug

We added CLI console test on D IPLINFO and D T. But the test on D IPLINFO may fail randomly. Currently chance of failure is around 3 out of 20. When it fails, this error message shows in the log:

expected 'Command Error:\nz/OSMF REST API Error:\nRest API failure with HTTP(S) status 500\nreason:      The TSO/E address space for this console can not be found\nreturn-code: 3\nreason-code: 12\n\n\nError Details:\nHTTP(S) error status "500" received.\nReview request details (resource, base path, credentials, payload) and ensure correctness.\n\nHost:      tvt6019.svl.ibm.com\nPort:      443\nBase Path: \nResource:  /zosmf/restconsoles/consoles/defcn\nRequest:   PUT\nHeaders:   [{"Content-Type":"application/json"},{"X-CSRF-ZOSMF-HEADER":true}]\nPayload:   { cmd: \'D IPLINFO\', async: \'N\' }\n' to be empty

In z/OSMF log /var/zosmf/data/logs/IZUG0.log, we may see exceptions logged like this: zosmf-IZUG0.log

To Reproduce

Steps to reproduce the behavior:

1. Run sanity test of CLI console tests/sanity/test/cli/test-05-console.js on target server.

Expected behavior

The test should pass without random failures.

Additional context

From Alfonso Rios 5 hours ago: Hi Jack, yes I do remember that test failing randomly but very frequently, It seems like running that command for the very first time after zowe is installed tend to fail with that error. What I did in our test project is to call it twice in a row, It seems like second time always is okay. I am pretty sure the same behavior will happen if you try to issue the command D T if this is the first console command executed. In smoke tests, the D T test will never fail as D IPLINFO test is executed first. try { result = await exec(command, options); } catch(error) { console.error(error); } result = await exec(command, options);

[jackjia-ibm]

From Joey, z/OSMF team regarding this issue:

My first thought is in what environment you are running z/OSMF? For some small machine, you might experience timeout issue occasionally. WLM tuning to set a higher QoS goal for z/OSMF address space might be helpful for this occasional time out issue.

[jackjia-ibm]

Jing Hua Jiang 7 hours ago Hi Jack, can't get too much info in the log, could you please help to issue 'D OMVS,O', check the value of IPCMSGQBYTES, the default value should be 2G, which is 2147483647, if the value is not 2G, you could set it by 'SETOMVS IPCMSGQBYTES=2147483647', and try the scenario again.

Also recommended by Joey: zosmf v2r4 resource requirement.pdf