Re: Workbench


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:
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
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,

Ian C


Join genevaers-discussion@lists.openmainframeproject.org to automatically receive all group messages.