zwe start -c /path/to/custom.zowe.yaml ignore custom.zowe.yaml

[cumarav]

Describe the bug

I've installed zowe.
I want to be able to start zowe with customized set of APIML services so I've created copy of zowe.yaml - custom.zowe.yaml
in which I've enabled a additional service.

I've stopped running zowe and trying to start it with: bin/zwe start -c custom.zowe.yaml

I the job log I see -

2024-06-04 10:52:37.016 <ZWELNCH:16777405> ZWESVUSR INFO ZWEL0023I Zowe YAML config file is 'FILE(/etc/zowe2/zowe.yaml)'       
2024-06-04 10:52:37.016 <ZWELNCH:16777405> ZWESVUSR INFO ZWEL0024I HA_INSTANCE_ID is 'de63'                                    
2024-06-04 10:52:37.024 <ZWELNCH:16777405> ZWESVUSR INFO ZWEL0017I ROOT_DIR is '/etc/zowe2'                                    
2024-06-04 10:52:37.031 <ZWELNCH:16777405> ZWESVUSR INFO ZWEL0069I Configuration is valid                                      

I cannot find any reference to custom.zowe.yaml at all. -c parameter just ignored.

Expected behavior
As -c path/to/zowe.yaml parameter is MANDATORY - zowe should use it
custom.zowe.yaml should be applied with the higher precedence that default config or instead of default config.

Additional context
zowe 2.16

[balhar-jakub]

When you were looking into the actual jobs, the additional service wasn't started, just to validate?

If that is the case @Martin-Zeithaml @jp669844 this seems like a relevant bug.

[Martin-Zeithaml]

zwe start uses the config custom.zowe.yaml to find, what is the started task name and will start that STC.
You probably did not changed that or the default value was used.
And your launcher STC is coded with:

//STDENV   DD  *                             
_CEE_ENVFILE_CONTINUATION=\                  
_CEE_RUNOPTS=HEAPPOOLS(OFF),HEAPPOOLS64(OFF) 
_EDC_UMASK_DFLT=0002                         
CONFIG=/etc/zowe2/zowe.yaml
/*                                           

zwe start is not modifying STC before the execution.

[JoeNemo]

It is probably better to run this under SDSF or EJES or Sysview, I don't know how well these cases are documented.

[Martin-Zeithaml]

SDSF or SYSVIEW will not help, the config path is coded inside the JCL.

zwe start is only a way how to start STC from unix. Inside the start command there is basically only /S ZWESLSTC.

If you make additional changes to config or rename config, it is up to user to take corresponding actions:

• Config renamed - STC must be updated
• Component is disabled/enabled - nothing is required
• Change in zowe.setup - zwe install or zwe init could be required
• Possibly some changes in components might also require zwe init

The last 2 bullets are the reason, why zwe start is so simple (and stupid). It is not checking config in STC and command. Which could lead to the situation you described: config1 is used to start zowe which will use config2.

[cumarav]

When you were looking into the actual jobs, the additional service wasn't started, just to validate?

If that is the case @Martin-Zeithaml @jp669844 this seems like a relevant bug.

Yes, expected service was down after restart. (other changes has not been applied as well)
Looks like bin/zwe read only STC name from YAML to start but it contains path to zowe.yaml which it should start. It does not make those 2 files interpolation

[JoeNemo]

We continue to desire other 3rd-party products to be supported in addtion to SDSF. @Martin-Zeithaml is looking at Sysview.

[MarkAckert]

I agree with Martin that we should keep the zwe start command behavior as-is, and we should further clarify the behavior of the start command in the help text. It should be front and center that the zowe.yaml config is only being used to identify an already-configured instance of Zowe, and any changes to the zowe.yaml config require re-running related zwe commands before issuing zwe start.