Workbench
|
Ian C <ian@...>
Hi All, reviewing an issue re management of passwords led me to think about the workbench in a more general sense. We currently do not manage our passwords in a way that will comply with the CII best practices. We keep that passwords locally in a less than acceptable encrypted form. I partially understand how to fix the issue. But let's stand back and think about what the workbench is and where we want to go with it. It is a temporary beast. We want to move to a language based approach. As a step towards that I propose we think of the workbench as an editor. Nothing more. An editor that produces say WB XML files. That can then be processed on the mainframe to generate the run control files and run the performance engine. As such I think we should remove any password storage from the workbench system. The database behind the workbench should be thought of as nothing more than a clever scratch pad. It remembers stuff. Similarly the business of logging into the workbench is not really needed. The whole user account and management of internal permissions is pretty pointless. Simple connect to the database and a given environment. Do what you want and export the xml. It can then be stored in source control and re imported at a later date. Share an environment with others. But treat the workbench just as an editor. Agree how you are going to work together. Do not rely on the tool to sort it for you. Or maybe just use a local database.... that is then much more like an editor? This will greatly simplify it and the need for management of accounts etc, All we need is to provide a login screen that makes a connection to the database and takes you to the desired environment. What about someone accidently deleting things? Yep, a valid concern. Open to suggestions on that one. If whatever is stored in a source control system then it can be restored. Reply to the group with comments etc. And we can maybe discuss in our coming meetings. Though I think things like this should be sorted outside of a meeting and merely confirmed in the meeting. Looking forward to hearing from you. We need to figure out what we are going to do pretty soon. Cheers, Ian C |
|
|
|
speresie1@...
All,
My brain dump on this topic.
In the new world, we need to fully understand where the source code management is to be expected. The reason you lock down Geneva is to ensure the source is not changed accidentally. For someone to go in and change an lr would be highly detrimental to the rest of the team. I think there are two mode review and develop – sometimes you need to see how it was coded without being and xml genius. Hence view only. Is it possible to have view based on userid without password? Userid’s to certain environments? Is that overkill? The beauty of the wb is that you don’t have to know xml. It helps when debugging but is not mandatory. I struggle with this one – a mainframe programmer uses the point and click because very likely they have no server skillset. Is the overall object to make the mainframe like a server in outward appearance or train a server person to be a mainframer. Are we taking a step back by eliminating the gui front end? I guess it is silly to restrict people if you don’t have a password to ensure they are the people meant to have that access. So if we remove the authentication – what is the point of having different access rights? Good question. Protection for the individual that doesn’t want to harm something. Maybe it is more like browse with view only and browse with edit in the mainframe. Agreed if you are taking that all away and considering it is only an editor – you will leave the authentication of changes in the hand of other software such as github commit authority or acf2 / racf authorization on the mainframe. I think the answer to this question is the source code management – what is the proposal for that? Will the build / compile of a view or views take the source out of github? Then we have an answer. Commit is the way not to shoot everyone in the foot by mistake. What I am unclear of is where are the lr’s stored once we leave the workbench – are they stored in something like a copybook and pulled into the view at compile time? Is that the plan with the new wb replacement.
Sandy
From: genevaers-discussion@... <genevaers-discussion@...> On Behalf Of Ian C
Sent: Friday, February 19, 2021 3:38 AM To: genevaers-discussion@... Subject: [GeneraERS] Workbench
Hi All,
reviewing an issue re management of passwords led me to think about the workbench in a more general sense.
We currently do not manage our passwords in a way that will comply with the CII best practices. We keep that passwords locally in a less than acceptable encrypted form.
I partially understand how to fix the issue.
But let's stand back and think about what the workbench is and where we want to go with it. It is a temporary beast. We want to move to a language based approach.
As a step towards that I propose we think of the workbench as an editor. Nothing more. An editor that produces say WB XML files. That can then be processed on the mainframe to generate the run control files and run the performance engine.
As such I think we should remove any password storage from the workbench system. The database behind the workbench should be thought of as nothing more than a clever scratch pad. It remembers stuff.
Similarly the business of logging into the workbench is not really needed. The whole user account and management of internal permissions is pretty pointless. Simple connect to the database and a given environment. Do what you want and export the xml. It can then be stored in source control and re imported at a later date.
Share an environment with others. But treat the workbench just as an editor. Agree how you are going to work together. Do not rely on the tool to sort it for you.
Or maybe just use a local database.... that is then much more like an editor?
This will greatly simplify it and the need for management of accounts etc, All we need is to provide a login screen that makes a connection to the database and takes you to the desired environment.
What about someone accidently deleting things? Yep, a valid concern. Open to suggestions on that one. If whatever is stored in a source control system then it can be restored.
Reply to the group with comments etc. And we can maybe discuss in our coming meetings. Though I think things like this should be sorted outside of a meeting and merely confirmed in the meeting.
Looking forward to hearing from you. We need to figure out what we are going to do pretty soon.
Cheers, |
|
|
|
Kip Twitchell
Should be a good discussion on Tuesday. Many good thoughts moving us forward. Thanks for giving us time on these topics.
toggle quoted message
Show quoted text
On Feb 19, 2021, at 8:14 AM, speresie1 via lists.openmainframeproject.org <speresie1=yahoo.com@...> wrote:
|
|
|
|
Ian
Thanks for the comments Sandy.
This really just highlights that we do not have a concrete plan for the workbench. Or the rest for that matter. Just a notion of where we are going. My thoughts are re the workbench. We have some options. 1. Release the code pretty much as is. Warts and all. And there are many warts. Not least of which is the topic mentioned - our unacceptable method of managing passwords. Then plan future iterations. Downside here is that it is pretty limited at the moment and will be of little use. 2. Come up with an initial target set of functionality. Not far from what is there now. Remove the password and account dependency. Get the basic views working. Then plan future iterations. At the moment Jeff and I are working to address the issues we can see. 3. Wait until it is all working as we desire before releasing. RE the idea of thinking of the workbench as an editor. I was not proposing it as a direct XML editor. Merely that we think of it as an editor. It will still, at least in the short term, be a point and click GUI through which you make the existing grids to generate views. Then generate/export a workbench XML file or files. As a process to generate Run Control Files I do however propose that the workbench be used to generate WB XML to be consumed by MR91. Then the rest of the performance engine can run. And MR91 then does not have to connect to the workbench database at all. Which is good because to does not connect to Postgres at the moment. A user should never have to look inside the WB XML. Just think of it as a binary file not unlike the existing VDPs. They are essentially the same. Just that the content is more easily viewed. And it is those WB XML file(s) that will be managed in some external github like environment. And that will act as a backup to accidental changes/deletions. And in the fullness of time, (think UK TV program Yes Minister) at the appropriate juncture, we will switch the XML to some sort of language like file. Which may still be able to generate via the workbench GUI? Or we hopefully will be able to edit views etc in your favourite text editor. |
|
|
|
a orth <pwht@...>
I think Ian's perspective advances our desired future state. Sandy is correct about SCM, which is likely to be git based.
Just from a efficiency perspective, if Sandy has already defined a LR and the XML is placed in git, I can download and import it into my workspace, create my view and be on my merry way.
As for changing a LR, the process would follow normal git practices.
As for where compilation occurs, I think a proposed solution is in the architectural PowerPoint. But I'm going off memory.
To see the latest version on the PowerPoint head to GenevaERS. It's the most recent post
From: genevaers-discussion@... <genevaers-discussion@...> on behalf of speresie1 via lists.openmainframeproject.org <speresie1=yahoo.com@...>
Sent: Friday, February 19, 2021, 09:14 To: 'Ian C'; genevaers-discussion@... Subject: Re: [GeneraERS] Workbench All,
My brain dump on this topic.
In the new world, we need to fully understand where the source code management is to be expected. The reason you lock down Geneva is to ensure the source is not changed accidentally. For someone to go in and change an lr would be highly detrimental to the rest of the team. I think there are two mode review and develop – sometimes you need to see how it was coded without being and xml genius. Hence view only. Is it possible to have view based on userid without password? Userid’s to certain environments? Is that overkill? The beauty of the wb is that you don’t have to know xml. It helps when debugging but is not mandatory. I struggle with this one – a mainframe programmer uses the point and click because very likely they have no server skillset. Is the overall object to make the mainframe like a server in outward appearance or train a server person to be a mainframer. Are we taking a step back by eliminating the gui front end? I guess it is silly to restrict people if you don’t have a password to ensure they are the people meant to have that access. So if we remove the authentication – what is the point of having different access rights? Good question. Protection for the individual that doesn’t want to harm something. Maybe it is more like browse with view only and browse with edit in the mainframe. Agreed if you are taking that all away and considering it is only an editor – you will leave the authentication of changes in the hand of other software such as github commit authority or acf2 / racf authorization on the mainframe. I think the answer to this question is the source code management – what is the proposal for that? Will the build / compile of a view or views take the source out of github? Then we have an answer. Commit is the way not to shoot everyone in the foot by mistake. What I am unclear of is where are the lr’s stored once we leave the workbench – are they stored in something like a copybook and pulled into the view at compile time? Is that the plan with the new wb replacement.
Sandy
From: genevaers-discussion@... <genevaers-discussion@...>
On Behalf Of Ian C
Hi All,
reviewing an issue re management of passwords led me to think about the workbench in a more general sense.
We currently do not manage our passwords in a way that will comply with the CII best practices. We keep that passwords locally in a less than acceptable encrypted form.
I partially understand how to fix the issue.
But let's stand back and think about what the workbench is and where we want to go with it. It is a temporary beast. We want to move to a language based approach.
As a step towards that I propose we think of the workbench as an editor. Nothing more. An editor that produces say WB XML files. That can then be processed on the mainframe to generate the run control files and run the performance engine.
As such I think we should remove any password storage from the workbench system. The database behind the workbench should be thought of as nothing more than a clever scratch pad. It remembers stuff.
Similarly the business of logging into the workbench is not really needed. The whole user account and management of internal permissions is pretty pointless. Simple connect to the database and a given environment. Do what you want and export the xml. It can then be stored in source control and re imported at a later date.
Share an environment with others. But treat the workbench just as an editor. Agree how you are going to work together. Do not rely on the tool to sort it for you.
Or maybe just use a local database.... that is then much more like an editor?
This will greatly simplify it and the need for management of accounts etc, All we need is to provide a login screen that makes a connection to the database and takes you to the desired environment.
What about someone accidently deleting things? Yep, a valid concern. Open to suggestions on that one. If whatever is stored in a source control system then it can be restored.
Reply to the group with comments etc. And we can maybe discuss in our coming meetings. Though I think things like this should be sorted outside of a meeting and merely confirmed in the meeting.
Looking forward to hearing from you. We need to figure out what we are going to do pretty soon.
Cheers, |
|
|
|
a orth <pwht@...>
Exactly, and agile will help us get there.
From: Ian C <ian@...>
Sent: Saturday, February 20, 2021 12:58 AM To: a orth <pwht@...> Subject: Re: [GeneraERS] Workbench
Hi Andrea, Looks like email came to just me.
And re agile, or any process for that matter, will not work unless we have a clear idea/definition of where we are headed.
Cheers,
On Sat, Feb 20, 2021 at 2:49 PM a orth <pwht@...> wrote:
|
|
|
|
Ian C <ian@...>
Just to clarify. Currently the workbench XML contains all of the components needed for a given view. That is all the LRs, Lookup Paths etc. You can also group many views into a workbench XML. There is an concern regarding making sure we have consistent LRs etc. The proposed method for doing this at the moment is the use of the CREATEDTIMESTAMP value. When a set of WB XMLS are generated from the workbench (say for a set of views) they will all have the same timestamp. To indicate that they are the compatible set. And when importing back into the workbench so they can be edited then the timestamps will be checked. Cheers, Ian C On Sat, Feb 20, 2021 at 1:58 AM a orth <pwht@...> wrote:
|
|
|
|
speresie1@...
Sorry is there a picture of this process? Where is the timestamp stored? Is it on the database? Is there a method of exporting all the metadata to be stored in git without a view wrapped around it?
What happens on the import – if I have an lr there already – does it overlay that LR or does it just store it as a different timestamp? We need to process out how this will work both when we have the wb and when it is gone with the addition of code source lockdown management if there will be no user security.
If I remember correctly, if we wanted to change a view, we used to create a new env, import everything in the component, change the view, do testing but only migrate the vdp that had changed – then get rid of the environment.
We only migrated the one vdp so that we didn’t have to retest all the vdps. How would that work if we were trying to import the entire set of vdps. I would think they would eventually have different timestamps depending on when they were exported/migrated.
I think we need a working group on this.
When is a good time to have a meeting?
Sandy
From: genevaers-discussion@... <genevaers-discussion@...> On Behalf Of Ian C
Sent: Sunday, February 21, 2021 8:18 PM To: a orth <pwht@...> Cc: speresie1@...; Ian C <ian@...>; genevaers-discussion@... Subject: Re: [GeneraERS] Workbench
Just to clarify. Currently the workbench XML contains all of the components needed for a given view. That is all the LRs, Lookup Paths etc.
You can also group many views into a workbench XML.
There is an concern regarding making sure we have consistent LRs etc. The proposed method for doing this at the moment is the use of the CREATEDTIMESTAMP value.
When a set of WB XMLS are generated from the workbench (say for a set of views) they will all have the same timestamp. To indicate that they are the compatible set. And when importing back into the workbench so they can be edited then the timestamps will be checked.
Cheers,
On Sat, Feb 20, 2021 at 1:58 AM a orth <pwht@...> wrote:
|
|
|