|
Q:
|
Would be great to have a native plug-in for Visual Studio Code which just works without a lot of hassle for users. And requires licensing Zowe? Would be a great native feature perhaps, just a suggestion
|
|
A:
|
Users can customize their own z/OSMF desktop. If there are any plugins that they are not interested with, they can remove them from their desktop and won't impact other users' z/OSMF UI. In terms of Visual Studio Code, we have a built-in editor window which provides VSC similar experience for editing data sets and USS files
|
|
Q:
|
Can the download/upload function be disabled if a site wanted to restrict extraction of data to workstation? Are these transfers logged, SMF?
|
|
A:
|
There is no direct SAF resource to restrict z/OSMF download/upload function. However, the Desktop data set and file functions are driving z/OSMF data set and file REST APIs undercover. It relies on the security control of data set and file REST APIs. The access to Data set and file REST API requires read access to resource “<SAF prefix>.IzuManagementFacilityRestFiles.izuUsers” class(EJBROLE). If user doesn’t have such access, they can not access z/OSMF Data set and file REST APIs and they will also experience error when they use Desktop functions, although the error today is not so user friendly. Another aspect I’d like to clarify is that both desktop functions and data set REST APIs don’t change the fact that user needs to have access to the data set or uss file itself. If user doesn’t have such access, the actions will also be failed in Desktop UI.
The Download/Upload function itself doesn’t write SMF log today.
|
|
Q:
|
This upload/download could replace WINscp or any other vendor tool.. but I know it has a size limit of 100 MB for uploading files from our workstation. How can we request limit size to be changed
|
|
A:
|
Please open a requirement on aha. You can add a new RFE idea here: https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/?category=7060446884669803837
|
|
Q:
|
How do you enable this new feature?
|
|
A:
|
This link is about how to enable Parmlib plugin: https://www.ibm.com/docs/en/zos/3.1.0?topic=services-configure-parmlib-management-service. This link is about how to use REST API to validate parmlib syntax https://www.ibm.com/docs/en/zos/3.1.0?topic=services-parmlib-management
|
|
Q:
|
Is this new API/ plugin also available on z/OS 2.5 ?
|
|
A:
|
No, this new function is currently only available on z/OS 3.2
|
|
Q1:
|
Is the plugin also able to validate the member suffixes existence or non existence ? i.E IEASYS00 has OMV= (xx,yy,zz,,00)?
So the plugin would validate that all BPXPRMxx members needed would be available in the PARMLIB concatenation, and be also syntax validated...
|
|
A1:
|
OMV= (xx,yy,zz,,00) the api could validate all those four members. Yes the api supports to search active suffix and find them in parmlib data sets and validate them
|
|
Q2:
|
Does plugin perform symbolic substitution as per LOADxx and post filtering IEASYMxx used?
|
|
A2:
|
Yes, such as in IEASYS, OMVS=&&sym1, the api read sym1 value and continue to validate it
|
|
Q3:
|
I meant if BPXPRMxx contained &MYSYM.
|
|
A3:
|
We support symbols in some parmlib member.
|
|
Q4:
|
What I meant is if you were checking a specific BPXPRMxx that contains system symbols, and you had not specified a LOADxx in the REST call, does it just assume that any symbols in BPXPRMxx are valid, or does it default to using the active LOADxx member?
|
|
A4:
|
If the place of symbol is a specific value, e.g., YES|NO, we will get the symbol's value and the do the syntax check.
|
|
Q5:
|
If, for example, we have MOUNTPOINT('/&MYSYS./mydir/mountpoint') and only check the BPXPRMxx member without a LOAD stated, does it assume MYSYS is valid or does it get the active &MYSYS from the running system and substitute
|
|
A5:
|
We don’t validate the value today. Since &MYSYS. in the examples is shown in a value, we don’t resolve it. But if &MYSYS. is included in IEASYS member, we will resolve value of &MYSYS. in order to get suffix of other parmlib. In this case, the active value of &MYSYS. will be used.
|
|
Q:
|
Can you start the validation from a rexx under TSO?
|
|
A:
|
The function today is only provided through REST API. But REST API can be called from many languages. You can drive it from a python script in USS, you can also drive rest api with z/OS Web Enablement Toolkitwhich does provide REXX interface to drive REST API.
|
|
Q:
|
Can you validate PARMLIB members before they become active members?
|
|
A:
|
Yes, you could indicate any LOAD (even though the LOAD is not active) . Meanwhile, you could validate any parmlib members even though they are inactive
|
|
Q:
|
Thinking that this is going to be an API which could be used in an Application/Function that validates Parmlib for changes & IPL validation etc. Is there a plan for this or are we a long way away from this at this time?
|
|
A:
|
I like your thinking! I can see a benefit for this API in our IBM z/OS Change Tracker function :). Finding errors before the members go active, not just after, is one of the most important use cases I see for this.
|
|
Q:
|
Does this API use a 'template' that gives it the expected syntax, then we could also bring in our own or other vendor syntax and maybe our own to limit things in Parmlib which we don't want or allow (e.g. security etc)...need to think more about this?
|
|
A:
|
Good idea about "template". We have provided default syntax files for each of the 38 PRMLIB types. You can customize those files to bring in additional limitations to the syntax.
|
|
Q:
|
Does it go beyond syntax checking? For example: validate that a specified dsn exists (and, if specified, on the volser provided)?
|
|
A:
|
We do not check whether dsn exists.
|
|
Q:
|
So is this where it would validate before the member saves and you are updating parmlib or is it only check prior to IPL and you have to take the action to scan
|
|
A:
|
We have to take the action to scan the parmlib content.
|
|
Q:
|
Does it require the record numbers on cols 72-80, or can we just skip them?
|
|
A:
|
Record numbers in the parmlib member are not required.
|
|
Q:
|
Is there any reason why we have the Response in that format using brackets { }, etc ..
|
|
A:
|
The response is in JSON format.
|
|
Q
|
zOSMF PARMLIB validation will now require us to activate zOSMF on environments that does not have it active in any other //SYSPLEX
|
|
A:
|
I am not sure if this is a question. To validate Parmlib syntax of a sysplex, you need to have a z/OSMF running in remote sysplex. That’s just common requirement like almost all other z/OSMF plugins. If you don’t need parmlib validation capability in any sysplex, then you don’t need to activate z/OSMF in that sysplex.
|
|
Comment:
|
This is not a question. It's a comment. I suppose that this capability might be helpful to those who do not use Image Focus. I find a RESTful interface a strange choice. Syntax check repairs require a human and REST is targeted to a digital audience. It seems to me that executing a simple utility that spits out a report is easier
|
|
Comment
|
I would also like to be able to tell the validator the content I expect in the parmlib members and have the tool tell me if they match or not.
|
|
Q:
|
If for example we have MOUNTPOINT('/&MYSYS./mydir/mountpoint') and only check the BPXPRMxx member without a LOAD stated, does it assume MYSYS is valid or does it get the active &MYSYS from the running system and substitute
|
|
A
|
We don’t validate the value today. Since &MYSYS. in the examples is shown in a value, we don’t resolve it. But if &MYSYS. is included in IEASYS member, we will resolve value of &MYSYS. in order to get suffix of other parmlib. In this case, the active value of &MYSYS. will be used.
|