zowe / zss Goto Github PK

Zowe System Services Server for enabling low-level microservices

License: Eclipse Public License 2.0

C 92.59% Shell 4.92% Python 1.52% JavaScript 0.31% Java 0.67%

zss's Introduction

This program and the accompanying materials are made available under the terms of the Eclipse Public License v2.0 which accompanies this distribution, and is available at https://www.eclipse.org/legal/epl-v20.html

SPDX-License-Identifier: EPL-2.0

ZSS - Zowe System Services Server for enabling low-level microservices for z/OS

(Quick start) How to build ZSS and the cross-memory server

git clone [email protected]:zowe/zss.git
cd zss
git submodule update --init
./build/build.sh

Note: zssServer will be placed in the bin directory, the cross-memory server's load module will be placed in the user-id.DEV.LOADLIB dataset.

(Quick run) How to start ZSS

Zowe core schemas are needed to run, so the quickest way to get them as a developer is to clone the repo they come from.

git clone [email protected]:zowe/zowe-install-packaging.git

Then, tell ZSS where to find the schemas and the configs and then start it up, like so:

cd /path/to/zss/bin
export ZWES_COMPONENT_HOME=/path/to/zss
export ZWE_zowe_runtimeDirectory=/path/to/zowe-install-packaging
ZWE_CLI_PARAMETER_CONFIG="FILE(/my/zowe.yaml)" ./zssServer.sh

Note: ZSS defaults are in defaults.yaml so you only need to provide customizations in your own zowe.yaml.

How to submit a pull request

The zowe-common-c library is a dependency of ZSS. If a ZSS pull request implies some changes of zowe-common-c, the changes should be merged first, and the reference to the correspondent zowe-common-c commit should be included.

For example:

cd deps/zowe-common-c
git checkout <ZOWE_COMMON_C_GIT_REFERENCE>
cd ../..
git add deps/zowe-common-c/

Troubleshooting

When using ZSS as the agent to host files and folders, for example: for the Zowe Editor Desktop app by the App server, may lead to '401 Impersonator Error' Fix: Make sure the program-controlled bit is set for your ZSS binary extattr +p zssServer

ZSS in V2 takes advantage of V2 by using schemas and the Zowe configuration YAML. If you're running zssServer accidentally, instead of zssServer.sh or your zssServer.sh is out of date, you may see an error on start like ZSS 2.x requires schemas and config

When starting ZSS, you may encounter a schema validation issue i.e. Configuration has validity exceptions: Schema at '' invalid [...]. Fix: To read these errors, consult: https://docs.zowe.org/stable/user-guide/configmgr-using/#validation-error-reporting Note: ZSS has a default schema in $ZWES_COMPONENT_HOME/schemas and default configuration YAML in $ZWES_COMPONENT_HOME/defaults.yaml

Mock server

If you don't have access to z/OS, or want to help expand the Mock server, find it at: https://github.com/zowe/zss/tree/v2.x/staging/mock

SPDX-License-Identifier: EPL-2.0

zss's People

Contributors

Stargazers

Watchers

zss's Issues

Disable setting zss

Unix file directory list initiates download instead of JSON display

Possibly due to content-type header or disposition header, we see application/x.directory for directories instead of application/json

Zowe cross memory server parmlib reader supporting in-stream

It would be good, at least for developing and testing to have possibility to use in stream parameters, e.g.:

//ZWESIS01...
...
//PARMLIB  DD   DSNAME=ZOWE.COMMON.PARMLIB,DISP=SHR 
//         DD   *                                   
  ZOWE.UNDOCUMENTED.FEATURE=YES                     
/*

Can't Copy jcl file to PROCLIB

The cp command on Line 24 of zowe-xmem-deploy-sh fails to write to USER.Z23B.PROCLIB on a zD&T system.

Reason for failure:
There is a restriction is USS which means you can't write to a z/OS dataset if any process has it allocated, even if only for READ. USER.Z23B.PROCLIB is in use by another user. The other user of USER.Z23B.PROCLIB is anyone who logs on with the TSO PROC called ISPFPROC, which allocates USER.Z23B.PROCLIB to your TSO userid.

So the following datasets used in ISPFPROC will fail as a PROCLIB candidate:

USER.Z23B.PROCLIB
FEU.Z23B.PROCLIB
ADCD.Z23B.PROCLIB

on our zD&T systems. Any other system that does this will have the same problem.

A solution is to avoid using USS to make the copy. The main zowe install does this using a REXX EXEC, so the failing line 24 could be replaced by a call to the shell script which uses that REXX.

if ${ZSS}/../scripts/zowe-copy-proc.sh ${ZSS}/SAMPLIB/${jclfile} $proclib $member

ZSS API Versioning

ZSS- UnixFile GET metadata API request gives - 404- File not found

open the API Catalog and try to use the ZSS Unixfile API to get the metadata of any file/directory

you will get 404 for all requests for the following FAILING SCENARIOS

FAILING CASE:

when we have '/' in the directory path
directory -> u/adarsh
filename -> testing
=> curl -X GET "https://TVT5xxx.svl.xxx.com:7554/zss/api/v1/unixfile/metadata/u%2Fadarsh/testing" -H "accept: application/json"
when we have one or more spaces in the directory path or file name
directory -> u
filename -> a b c d
=> curl -X GET "https://TVTxxx.svl.xxx.com:7554/zss/api/v1/unixfile/metadata/u/a%20b%20c%20d-H "accept: application/json"

PASSING CASE:
directory -> u
filename -> adarsh
=> curl -X GET "https://TVTxxx.svl.xxx.com:7554/zss/api/v1/unixfile/metadata/u/adarsh" -H "accept: application/json"

It seems like ZSS does not handle %2F and %20b in the request URL

ZIS status - Permission denied (name='ZWESIS_STD ', zisRC=8, cmsRC=33, srvcRC=0, clientVersion=2)

I was not able to login to Zowe Desktop.

ZOWESVRV STC contained an error message

ZIS status - Permission denied (name='ZWESIS_STD      ', zisRC=8, cmsRC=33, srvcRC=0, clientVersion=2)

Solution:
In my case STC user assigned to ZOWESVR did not have ZWES.IS.

bring SAMPLIB in line with CUPIDS epic

With the CUPIDS epic we're reworking the install, configuration, and runtime experience for Zowe, for example by providing an SMP/E-managed install scenario.
Part of this epic is reworking configuration so all variables are defined together and all config work has the same look and feel to show Zowe as a single product instead of cobblepot, and to simplify customization scripts.
To have ZSS fit in this, we propose some updates to the files shipped in zss.pax SAMPLIB. Note that this has a ripple effect into ZSS documentation.

If you give me the permit I can push the following, which is also attached to this issue:

/c/zowe-git/zss/samplib/zis (samplib)
$ git status
On branch samplib
Changes to be committed:
(use "git reset HEAD ..." to unstage)

    renamed:    ZWESISMS -> ../ZWESISMS

** ZWESISMS is just a copyright header and should not be shipped to customers.
-> move it away from the shipped files

    renamed:    ZWESAUX -> ZWESASTC.jcl

** To avoid complications with SMP/E managed installs we do not allow duplicate file names.
-> loadmod keeps its name, STC changes name

    renamed:    ZWESIS01 -> ZWESISTC.jcl

** To avoid complications with SMP/E managed installs we do not allow duplicate file names.
-> loadmod keeps its name, STC changes name

Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)

    modified:   ZWESASTC.jcl

->reworked to provide additional info, create uniform look & feel for all JCL and use common variable names to simplify customization scripts

    modified:   ZWESISCH

-> fixed faulty comment characters, create uniform look & feel for all PARMLIB members

    modified:   ZWESISTC.jcl

->reworked to provide additional info, create uniform look & feel for all JCL and use common variable names to simplify customization scripts

Untracked files:
(use "git add ..." to include in what will be committed)

    ZWESIPRG

** New: sample PROGxx member

samplib.zip

Dynamic (runtime) compression of REST API data (ZSS)

Primarily when dealing with the unixfile or datasetcontents REST APIs (though maybe others), read the accepts header to see if the client wants and supports compression types such as gzip, and if so, send the file/dataset content in a compressed form by doing compression of the response.
gzip compression may be a hardware feature, so leveraging that would be best versus trying to do some software stuff.

Build failed, DATA SET CSF.SCSFMOD0 NOT IN CATALOG

My build on my local system failed with this message:

IKJ56228I DATA SET CSF.SCSFMOD0 NOT IN CATALOG OR CATALOG CAN NOT BE ACCESSED   
FSUM3052 The data definition name <SYSLIB> cannot be resolved. The data set was not found. Ensure that data set name CSF.SCSFMOD0 is specified correctly.
Build failed

This is because CSF.SCSFMOD0 is not stored under that DSN on my system.

Suggestion: Make DSNs of this kind into parameters in some build.conf file. Default values for these DSNs will be the current values.

ICFS error message is not printed

The error message https://github.com/zowe/zowe-common-c/blob/master/c/httpserver.c#L1359 is controlled by the http server's log component which is initialized after the ICFS check. Because of that, the error message is never printed. The ZSS code needs to initialize the log level prior to the error message.

Installing Zowe's ZIS datasets can freeze CLI if done via CLI

In this ticket zowe/zowe-cli#1012 it is described that any use of tsocmd should be ended with < /dev/null to make certain that the command finishes instead of hanging. The lack of this does not hang all callers, but some such as the CLI do hang, so we should add this to all invocations of tsocmd to be safe & certain.

Print build time of the ZSS Cross-Memory Server

@DmitryNikolaev pointed out that it'd be helpful to know the build time of the ZWESIS01 module so that automation could verify that the expected version got loaded.

The following message:

2019/03/29-09:12:53.84 ZWESIS01 00FB9B80(0068) 008F8588  ZWES0001I ZSS Cross-Memory Server starting, version is 1.0.3

could be changed to include the build date/time:

2019/03/29-09:12:53.84 ZWESIS01 00FB9B80(0068) 008F8588  ZWES0001I ZSS Cross-Memory starting, version is 1.0.3 (2019-04-01 08:25:43.933964)

Provide option to register ZSS into APIML

If APIML exists, it would be good to register ZSS into it. It could provide https "for free", without the need of AT-TLS.
static definition seems like a good first step since it should be easy, but there is a condition we must be careful of:
if AT-TLS is enabled or not will determine if the definition should state https or not

I think those who worked on the Explorers could provide some tips on how to get this right in the packaging & configuration, but https://docs.zowe.org/stable/extend/extend-apiml/onboard-overview.html#guides-for-static-onboarding-and-direct-call-onboarding is also a good source of information.

zssServer failed with new zos version

Hi,

I'm running into issue where zssServer failed to start. In log file I saw following info. I know zOS 2.4 is not released yet. But could you please still take a look? Thanks!

168:/Z2/var/zowert/1.1.0/zlux-app-server/log $ cat zssServer-2019-05-01-14-17.log
CEE5207E The signal SIGABRT was received.
error: z/OS version = 0x01020400, max supported version = 0x01020300 - CAA fields require verification

Validate environment during ZSS and ZIS start up

ZSS needs to check:

ICSF:
- RNG, optional if SSO is being used
- PKCS11, only if SSO is being used
BPX:
- Check state of BPX.DAEMON, BPX.SERVER

ZIS needs to check:

The user has an OMVS segment

ZSS message improvements:

ZIS status codes are light or missing descriptions:
- Add a mapping of status codes to human readable description

ZSS API allows enqueued dataset to be updated by another user

I used the WEBUI Editor to edit a dataset, which takes an exclusive SPFEDIT ENQ, visible in z/OS as

SDSF ENQ DISPLAY  MV3B     MV3B      MAJ SPFEDIT       LINE 6-6 (6)           
COMMAND INPUT ===>                                            SCROLL ===> CSR 
NP   MINOR                                                Major    Req JobName
     USER.PARMLIB                                TESTMEM  SPFEDIT  EXC SZ1

Then another user used Insomnia to POST an updated body to that same member, and this succeeded. This should not be permitted.

Enhance ZSS build pipeline to add end user test ZSS Rest API

Add ZSS End User API Testing to its Jenkins pipeline.
Start coverage with edit datasets API.
Testing is critical to functionality as its involves locking resources.

Goal: Keep testbed effective by adding more automated tests for ZSS APIs since recent API additions & enhancements have some harder to test issues like testing against timing & contention

ZSS is not able to read SO token on ACF2

This feature properly works for TSS and RACF but on ACF2(marist-2) we get an error message ZWES1030W Server startup problem: Could not load the JWT key 'ZWETOKEN' from token 'jwtsecret': rc '12', p11rc '0', p11Rsn '0' .
More info in https://wash.zowe.org:8443/job/zowe-install-test/view/change-requests/job/PR-2053/18/consoleFull
PR zowe/zowe-install-packaging#2053

API URL does not work when DSN contains #

If you use RESTClient to send a URL like this
https://localhost:8544/datasetEnqueue/USER.TEST.RECFM#V
then the request fails because only USER.TEST.RECFM is included on the DSN.

The file Editor does not have this problem, because it sends
https://localhost:8544/datasetEnqueue/USER.TEST.RECFM%23V

Support z/OS 2.4 in ZSS

Currently there is an explicit check that prevents ZSS from starting on z/OS > 2.3. This check needs to be changed to include 2.4.

Migrate dataset REST api out of zowe-common-c and into zss

zowe-common-c is a repo for libraries, not REST APIs which would depend upon/make use of those libraries.
Yet, we have our dataset REST API logic for zss within zowe-common-c. This is technical debt and should be solved by moving datasetjson.c and possibly other related files out of zowe-common-c and into the zss repo.

Need to run ZWESAUX for zACS

According to this image, it seems, that ZWESAUX is managing PC calls:

So I need to have ZWESAUX running to be able to perform PC (program call) scan, which I need for IBM Authorized Code Scanner (zACS).

I read the documentation and search in these issues and I understand, that this module is not intended to be executed by user otherwise it will fail. The execution is controlled by the cross memory server (ZWESIS01).

Is there some way how to run ZWESAUX?

I will appreciate any idea or hint, thanks.

Add http no-cache headers to i/o apis

/unixfile, /datasetcontents, /datasetmetadata and /vsamdatasetcontents serve potentially sensitive information, and therefore shouldn't be cached by the browser.
To fix, we'd need to add the headers "Cache-control: no-store" and "Pragma: no-cache" to these services in order to secure them.

ZSS - Editor Open dataset causing Json: conversion error

Open a dataset with Record Format FBS / Lrecl 4160 / Blocksize 24960 in Editor causing infinite messages:
JSON: conversion error, rc 16, reason 4
jsonConvertAndWriteBuffer() error: newLen = -1

ZWE1SZ1 starts looping/spiking.

ZSS address space - S0C4 RSN=00000011

I'm not sure if this is the right place to report this but I am currently trying to get ZOWE running but right after the startup of the ZSS address space starts I see these messages and then it crashes:

MSGID     MSGTEXT
ZWES0001I ZSS Cross-Memory Server starting, version is 1.0.5
ZWES0002I Input parameters at 0x6FE6:
ZWES0101I 00000000  0016D5C1 D4C57EE9 E6C5E2C9 E26DE2E3 |..NAME=ZWESIS_ST|

The dump is a SYSTEM COMPLETION CODE=0C4 REASON CODE=00000011

Plug-in system for the ZSS Cross-Memory server

Currently the cross-memory server doesn't have a mechanism to extend its functionality via 3rd party components and it is obvious that vendors may want to add new services without having to provide their own version of the server.

To solve this issue, the cross-memory server needs be able to extend its set of services via external load libraries.

Main new features:

New services can be added by providing a load library and the corresponding entry in the PARMLIB member
Services can now be called by name (more specifically by server name and service path which consists of the plug-in and service names). That's been achieved by introducing a global map which is used to locate services.
Ability to provide your own init, term and modify command callback functions for plug-ins
Ability to provide your own init and term callback functions for services
Every plug-in and service is provided by a common storage area to store plug-in and service specific data
More robust modify command handler - all commands are processed in their own TCBs and with their recovery

Things which are included:

Per service SAF checks (this should be discussed, would we want to leave it to plug-in developers to perform appropriate checks, or do we want to provide ways to pass SAF classes and profiles that need to be checked by the framework before calling the service?)

Pull-requests have been created:
zowe/zowe-common-c#16
#14

You can find examples of plug-ins in the following directory:
https://github.com/ifakhrutdinov/zss/tree/feature/zis-plugins-dev/plugins/zis

Below are some diagrams to help understand the old vs new architecture. The new parts are shown in green.

Current server architecture

New server architecture

Current cross-memory service call

New cross-memory service call (the old way of calling services will still work)

zis-plugin-install.sh fails to propagate return code to caller

If you give an invalid folder for the parmlib, error messages are printed, and obviously values are not entered into the zowe parmlib, and a zero return code is returned to the caller (so the caller thinks that all was well).

zis-plugin-install.sh extended-install myplugin/zisServer/loadlib nonexistantfolder

info: updating RSQA.IZP.IZPS011.PARMLIB(ZWESIP00) with the values from nonexistantfolder/*
update_parmlib 4294967101: zis-parmlib-update.sh 269: FSUM7343 cannot open "nonexistantfolder/*" for input: EDC5135I Not a directory.
error: script failed, RC = 1

Yet the return value to the original caller is zero despite this printout.

It looks like the culprit might be zis-parmlib-update.sh; I added some print statements to try to track this down but did not come to a conclusion about where the real bug is.

zowe server log message mentions 27.0.0.1 for localhost

Describe the bug
The Zowe server log in JES has this message

*** In production, please use 27.0.0.1 or localhost. Server is using '0.0.0.0' ***

To Reproduce
Steps to reproduce the behavior:

Go to host running zowe
Click on SDSF zowe jobs
Scroll down to the message
See error

Expected behavior
The Zowe server log in JES has this message

*** In production, please use 127.0.0.1 or localhost. Server is using '0.0.0.0' ***

Screenshots

zssServer.sh removing /u/x/zowe/instance/logs/zssServer-2020-11-11-17-58.log                               
ZSS_LOG_FILE=/u/x/zowe/instance/logs/zssServer-2021-01-27-10-13.log                                        
ZWES1013I ZSS Server has started. Version '1.19.0+20210106'                                                       
ZWES1033I Using server config file '/u/x/zowe/instance/workspace/app-server/serverConfig/server.json'      
ZWES1015W *** Server has not implemented HTTPS! ***                                                               
*** In production, please use 27.0.0.1 or localhost. Server is using '0.0.0.0' ***                                
ZWES1035I ZSS Server settings: Address='0.0.0.0', port='8542'                                                     
ZWES1025I Will not accept JWTs: Disabled in the configuration.

Clean up comments in config member ZWESIP00

The comments in samplib/zis/ZWESIP00 are incomplete and do not line up with what is in the online documentation, so somebody who knows what the configuration options are should review this file and clean it up, together with the matching online documentation.
Once all the data is in, I can help with tweaking the look and feel to make it fit in with the rest of Zowe sample members.

document how to write a comment, you currently use 2 different methods
all uppercase is not pleasant to read
document that keywords are strung together with a period
document valid and default values for keywords
not all PLUGIN keywords are documented
online docs say ZSS uses SAF class FACILITY, here you insinuate that a new class, ZOWE, is used (not a fan of this, as now we must also provide sample commands to create a class in RACF/ACF2/TSS).

Implement RBAC in ZSS

Currently, when RBAC is enabled, the App server checks whether or not a URL is requested by first asking if the RBAC request will succeed. Currently, ZSS can't be accessed directly (accessed via App server) therefore ZSS URL's are also protected by this code. However, if we make ZSS directly accessible, which is required for Docker + HA, when RBAC is turned on, you can circumvent RBAC by contacting ZSS directly instead of using the App server.
Therefore, to solve the issue:
ZSS needs to do its own RBAC checks

Today, RBAC checks happen due to 2 codebases: In sso-auth/zss-auth, there will be some authorize code that transforms a URL into a SAF-resource pattern. With that, it contacts the REST API on ZSS w/ the username and resource pattern and asks true/false "can the user access this pattern?" We need all of that code to also exist in the form of callable ZSS functions w/o a REST API & internal to the server, therefore when ZSS gets the request itself, it can check the request internally to see true/false can the user access this?

Some thoughts: httpserver.c has authentication code, but no authorization code. This auth code may be too Zowe-specific, therefore it seems more correct to not put it inside here, instead httpserver.c could take a pointer a function that if exists, calls it to get a true/false authorization answer & that would allow us to put authorization code into the zss repo instead of zowe-common-c

We should ask Irek if that idea sounds good or if he has another suggestion

Trust APIML SSO without PKCS11 storage

PKCS11 storage is currently used in SSO to hold token trust info that ZSS needs to read in order to verify an APIML SSO token. However, APIML generates tokens using a keystore or keyring instead of PKCS11.

We have encountered several issues with PKCS11 such as

More setup needed. Yet another place to store info, and needs extra ESM permissions to use.
RACD commands do not have enough parameters to work properly for our needs across all environments, some environments have issues with it.
Not using RACD could be development intensive to contact ICSF directly for storage operations.

It was determined that if ZSS can contact APIML on startup to learn the info needed to later trust an apiml token, then ZSS will no longer need the PKCS11 storage, which will simplify installation and reduce issues.

Tasks to complete include

Implement code to contact APIML on startup to get trust info
Implement code to verify apiml token given the trust info
Remove pkcs11 info from documentation, as it is no longer needed
pkcs11 scripting/code can be kept, for backward compatibility of anyone who has been automating installs, but it need not be used in new installations with this epic completed.

POST to datasetContents writes only the last record of the body

I sent POST to URL

https://9.20.205.110:8544/datasetContents/TSTRADM.TEST.JCL(MEM1)

with body

{
  "records": ["Fred","Flintstone"]
}

to a new dataset TSTRADM.TEST.JCL containing one empty member MEM1
and the result was

 BROWSE    TSTRADM.TEST.JCL(MEM1)                   
 Command ===>                                       
********************************* Top of Data ******
Flintstone                                          
Flintstone                                          
******************************** Bottom of Data ****

S0C4 on Zowe 1.19.1 with ZWED_agent_http_ipAddresses=0.0.0.0

If I add
ZWED_agent_http_ipAddresses=0.0.0.0
to my Zowe instance.env then zssServer dies with:

2021-03-11 13:48:02 <ZWELS:83952031> DOESTC INFO (start-component.sh:74) starting component zss ...                      
zssServer.sh removing /proj/ndx/var/zowe/inst1/logs/zssServer-2021-02-19-03-08.log                                       
ZSS_LOG_FILE=/proj/ndx/var/zowe/inst1/logs/zssServer-2021-03-11-08-48.log                                                
CEE3204S The system detected a protection exception (System Completion Code=0C4).                                        
         From entry point reportSLHFailure at statement 1447 at compile unit offset +000000BC at entry offset +000000BC  
         at address 209BA924.                                                                                            
ZWES1013I ZSS Server has started. Version '1.19.0+20210106'                                                              
ZWES1033I Using server config file '/proj/ndx/var/zowe/inst1/workspace/app-server/serverConfig/server.json'              
could not get any memory for SLH extension, extension size was 0x10

As soon as I remove ZWED_agent_http_ipAddresses then zssServer starts fine

Add the option to continue the execution of ZSS on an unsupporetd z/OS

ZSS should read a parameter that will allow it continue the execution if it's been started on a z/OS version that's not supported
Print a warning message ZSS has been started on an unsupported z/OS

Document zss error codes

Put each message of https://github.com/zowe/zss/blob/staging/h/zssLogging.h into zowe doc site with explanations and suggested user actions for each message.

MALLOC Issue?

I'm seeing about 5 of these messages for different plugins within zowe. Not sure what they mean. Any help would be great!

ZWESIS01 Status check should not use a simulated login

On my system I receive the following message:

ICH408I USER(D U MM Y) GROUP( ) NAME(??? ) 411
LOGON/JOB INITIATION - USER AT TERMINAL NOT RACF-DEFINED

It appears that on line 670 of c/zss.c a faux logon is attempted using a defunct userID called "D U MM Y". This generates a log message and a RACF audit of a filed logon attempt.

To avoid that issue, I suggest that we pass a ZWEIST67 (perhaps this is configurable) and when we see that logon in zowe-common-c we do not actually execute the FASTAUTH and simply return. This should achieve the goal of authorization without creating false audit records.

CLI plugin for ZSS APIs

The ZSS server provides some builtin REST APIs, some of which are similar to other APIs that the zowe CLI uses, and others which are to my knowledge unique in that no CLI plugin exists with capabilities such as password reset, terminal discovery, etc.

At minimum, there should be a CLI plugin for ZSS which allows the CLI to make use of ZSS core APIs. This may include

Dataset access
File access
Password reset
Terminal discovery
ESM queries
OMVS queries

But beyond this, ZSS is a pluggable server. It's unclear whether that means each ZSS plugin that has a useful REST API should have its own CLI plugin (most likely) or if a singular ZSS plugin to the CLI has dynamic behavior by querying which ZSS plugins are installed (sounds confusing)

zss v2

This ticket tracks tasks necessary to do for zss by the zowe v2 deadline.

in progress:

zss 64 bit #703 ~95% done
trust apiml sso without pkcs#11 #365

not started:

update all var names to be ZWE_ and ZWED and ZWES consistently

Switch /unixfile mixed-tag encoding behavior to binary

Currently /unixfile/contents tries to convert encoding of files with mixed tag. But this action can loose binary part of these files. From chtag manual page:

-m
Indicates that the file contains mixed text and binary data. The data
is not uniformly encoded, but to identify the encoding of portions of
the file that are text, this option allows the specifications of a code
set with the -c option. This option sets txtflag = OFF. When used
without -c, the existing coded character set that is associated with
the file is retained.

       Automatic conversion is disabled with this option. However, user
       applications can independently convert any text data that resides in
       the file by knowing the code set associated with it.

Automated test of zss api for contention checks

Create automated test for DS locking/writing

We can start at this level. These are actions people would try to do in general, so we could incorporate them into tests:

user A sees contents when not locked
A establishes a lock
user B sees whether contents can be read while lock is held
user B tries to establish a lock and fails
user A writes an update to the dataset
user A can see the update
user B can see the update if they could see the contents when lock was held
user A releases lock
user B can perform actions like user A now that lock is released
And some user or developer error cases

user tries to write without establishing lock, when no lock exists
user tries to write without establishing lock, when a lock from another user exists

And all of these cases could be attempted with different kinds of datasets:

pds
pdse
basic datasets (fb80, vb256)
vsam (currently doesn't work in Editor, so probably don't need this)
archived

Avoid using AUX communication PC for termination

Problem description

The AUX address space can run with REUSASID=NO. When it does, it will leak the ASID every time it's terminated because it uses a system LX for its communication PC. Using a non-system LX is not an option because once the parent (ZIS) issues ETCON, the AUX address space will be converted to non-reusable, again, leading to leaking the ASID.

Proposed solution

Since the communication PC isn't used much, we should introduce an option to disable it to avoid leaking ASIDs. Disabling the PC will disrupt modify command, work and termination signals sent from ZIS to AUX. The termination signal is all we care at the moment so we need to add an additional communication path for the termination signal. This new path is an ECB on which AUX will wait in a dedicated thread. Once ZIS is terminated, it will post on that ECB instead of calling the now disabled PC routine.

A message about data service installation failure

There used to be a message about a failure of data service installation in zss.
https://github.com/zowe/zowe-common-c/blob/master/c/dataservice.c#L118-L120

We find the message useful as we can spot the failure immediately in the log without switching to debug mode.

Could it be set at least to WARN level? Similarly, the same for other messages that indicate a failure:
https://github.com/zowe/zowe-common-c/blob/e82f4c634827d8fffe0853fcb5d524658ea3c65f/c/dataservice.c#L128
https://github.com/zowe/zowe-common-c/blob/e82f4c634827d8fffe0853fcb5d524658ea3c65f/c/dataservice.c#L133
https://github.com/zowe/zowe-common-c/blob/e82f4c634827d8fffe0853fcb5d524658ea3c65f/c/dataservice.c#L137

This issue is a duplicate of the zowe/zowe-common-c#210 issue

Handling of bad volumes in dataset services

The dataset services should handle offline/bad volumes better.

File Editor 500 errors with zss log error CEE0802C - 1.10 rc2 testing

Testing 1.10 RC2.
Open File Editor and drive it for a few minutes, expanding directories, creating directory and creating file, switching to Data Sets, back to USS. After a period it throws 500 errors and ceases to function.

This is the error in the zssServer.log file

about to start RLE Task from main at 0x154c5030 wkElement=0x1524acd0 pendingService=0x1524a4e0
httpTaskMain element=0x1524acd0 elt->convo=0x153afe40
about to start RLE Task from main at 0x154c5030 wkElement=0x1524acd0 pendingService=0x153ab8b8
CEE0802C Heap storage control information was damaged.
         From entry point malloc31 at statement 334 at compile unit offset +0000008E at entry offset +0000008E at
         address 1490A46E.
httpTaskMain element=0x1524acd0 elt->convo=0x153afec8
l1=name
csi query for WINCHJ.*                                            ����
¢Å�
¢Å�
¢Å�

ZSS Cross-Memory Server Starting, version 1.0.5

Hello! When starting the Cross Memory Server I run into this issue:

I already saw a post that was fairly similar to this one (#122). I tried uploading the recommended .pax file and replacing the LOADLIB member with the member from the unpaxed file, but that did not change anything. Not sure what to do... any help would be awesome!

Thank you,

James

A handler performing the SAF_AUTH check: checks if the user has the
specified access to the specified entity in the specified class

 URL format:
   GET .../saf-auth/<USERID>/<CLASS>/<ENTITY>/<READ|UPDATE|ALTER|CONTROL>
 Example: /saf-auth/PDUSR/FACILITY/CQM.CAE.ADMINISTRATOR/READ

but this fails with "Unexpected access level".

This format works:

GET .../saf-auth/<ENTITY>/<READ|UPDATE|ALTER|CONTROL>

Is it intentional? Is it possible to use a different resource class than ZOWE?

What are the possible ways how to authenticate? Basic auth works, is it possible to use the Zowe JWT token?