CICS Explorer 1.1.1 - Connections
JoeWinchester 110000DQA0 Comment (1) Visits (3732)
We've just released our latest modification update to the CICS Explorer which is available either on our download site, or if you have a copy of the CICS Explorer 1.1.0 you can upgrade it to the 1.1.1 release by using the menu option Help -> Check for Updates. What the Check for updates does is contact our support team's update site which we include whenever we ship a CICS Explorer - see that there's a newer version - and then automagically turns your CICS Explorer 1.1.0 into a CICS Explorer 1.1.1.
Our homepage has details of what's in the release - as well as John Knutson's announcement post to our developerworks forums.
I won't go over what's in the relase notes or John's post - instead what I'll do over the next week or two is deep dive each significant new feature and try to cover everything we've done and why we've done it. Today's episode is called "Connections Makeover" What I'll cover in this blog is the a new user interface we're creatd to simplify and really improve how you work with connections, as well as some nice new function to allow you to share groups of connections between users - how to pre-load the CICS Explorer with a set of default connections - how to assign userIDs and passwords to groups of connections. Oh, and before you ask, if you are already a CICS Explorer user and have a workspace with existing connections, you won't lose any data about your connections going from CICS Explorer 1.1.0 to CICS Explorer 1.1.1 - this is what in IBM we like to call not breaking forward compatability, or alternatively called keeping your existing users happ
To net it al out - what worked four years ago for a user interface to manage connections - needed a redesign.
Prior to the 1.1.1 release the way you managed your connection was to use a preference page to manage details of hosts/ports and any other details specific to how that connection needed to be made, and a separate preference page to manage your user ID and password combinations - and another preference page to export and import connection information between workspaces. These preference pages do still exist in case you go there looking for the old user interface, but they announce proudly that stuff has been moved to a single new view. They even have a hyperlink that opens the view for you. We did think about just removing the pages, however folks told us that they had internal docs in their organizations telling their users to open the preferences so we left the helpful "This function has been moved - go here instead" dialog in its page.
We did think about putting the view as being open by default on the perspectives, however we decided against it (for now), but we did add a menu item Manage Connections to the Window pulldown menu which will appear on every perspective (including any custom one you may have created), so you always get to the view with a couple of mouse clicks.
You might be asking yourself "What's so special about this view you keep telling me about", in which case ask no longer. A picture speaks a thousand words, so here's a picture of it to keep you reading this blog entry.
Still here ! Excellent - thank you for being patient - now we can begin the main act.
The view uses a new way to add and edit connections with improved validation and usability. When you press the Add... button if you have selected a connection type in the view's tree it will assume you are adding for that type, otherwise a pop-up menu will ask you which type. In the dialog the focus will initially be on the Host name: text field. This is the most significant piece of information - it's like a web browser - the most important thing is the name of the site you want to reach. (Before in the preference page the initial focus was on the name of the connection and I've lost count of the number of folks I've seen type the host in the name field - then realize their mistake - get frustrated - by which time I've usualy left the room before they can growl at me). Anyway - no more - what we do now is try to generate the Name: for you. The algorithm we use is to take the first segment of the host name, append a colon character, and then the port. This is done as you type so whenver you update the host or port the name is updated. If you don't like our auto-generated name and want to call it something cool like "Vader" or "Bilbo" instead - then you can overtype the name and we won't splat your cute name with our autogenerated name.
On the dialog we have three buttons you can choose from - Save and connect saves details, shuts the dialog, and then attempts to connect. Save and close saves the details and shuts the dialog. Close will shut the dialog without updating your changes, and if the only enabled button if there are any errors (we do keystroke by keystroke validation of things like port numbers being numeric with cute redXs and yellow backgrounds). If the connection has any additional details such as DB2 server name or FTP multibyte characterset, then these will be beneath the main connection details in the UI.
Locally added connections are cool - you can use them to connect to servers - but what's even cooler is connection shar
Good news - we've put in some pretty neat stuff to make this whole experience stuff just a lot simpler and hopefully more enjoyable.
You can export all of the connections you have locally defined into a file and give it a meaningful name, e.g. All My Production systems. To launch the export dialog use the toolbar button in the Host connections view that has a picture of a computer with a blue arrow coming out of it. From another workspace you can import this file in one of two ways - one is what I call a copy and paste import - the details are read into the new workspace and they can then diverge - changes in one set aren't auto
In Hursley - where I work and develop the CICS Explorer with a bunch of the smartest folks I've had the pleasure of knowing - we have a list of systems that we connect to. These are at different CICS levels - some are production - some have test data - and we all need to know what these are. What I've done is define a bunch of these in my workspace using the Add.. dialog and then exported these to a file I've called hurs
The dialog that appears lets you enter the location of the file you want to import from (with a Browse... button that works if it's on a mapped drive rather than reachable through http:// which you have to type into the text field) and radio button choices for whether you want a dynamic import or a static one. What I want to do is let all my colleagues in Hursley point to the file I created, and then when I'm aware of a new system that they might want to connect to, or that a port or host details on a system have changed, or a system is no longer applicable I can update the file and they all get the changed details. For this option the user who is consuming the file containing exported preferences should choose the Load radio button, which we've helpfully made the default, and we've also put what we thought was some useful blurb to try to explain this on the dialog.
Press OK - the file contents are retrieved - and turned into connections. What this means is that whoever is responsible for updating the hurs
Connections which have been dynamically loaded, i.e. are imports of the real details which come from another file, are displayed differently to those that have been entered in the workbench using the Add... button. Earlier we created the CICS Management Interface connection cicsexp1:27062 - and then we imported twenty more. These are displayed slightly differently in the tree with a NE pointing arrow in the bottom left corner of the icon which shows the connections on/off status. In the screen shot below none of the connections are active, and the top connection has a regular red square X to show this, while the other connections (part of the imported set from the file hurs
If you open one of the connections that has been dynamically imported, then the dialog will have all of the data fields greyed out. The rationale for this, is because you're not meant to edit them. Whoever owns the master file, which could also be you, should edit the file you're pointing to. When you exit and re-start the explorer the fresh details will be retrieved - so even if you did manage to edit them locally they'd be spaltted next time your explorer refreshed the details from the remote file. If you do want to edit the details - then you should have taken the Import radio button, rather than Load on the dialog where you entered the remote file name. Import reads from the remote file and then divorces itself from all knowledge that the connection details came from the remote file - as far as the workbench is concerned it's as though you typed Add... and entered them all by hand.
The toolbar button to the left of the import export ones - whose hover help is Show Links will toggle whether or not the top node of the Connections tree should be the source or not.
When the button is toggled on you get icons which show where the connections come from. There is always one called My Connections which shows the ones which are local to your workbench and were created using the Add... button. For every file that you've done a dynamic load from - there'll be an icon that shows the source of the file. Beneath each icon showing the source of the connection the tree then shows the kinds of connections coming from that source, and you can expand further to see the actual connections themselves.
If for any reason there is a problem reaching the file where connections have been dynamically imported from, you'll see a redX next to the file and some help as to what went wrong. This is most likely to be that maybe you can no longer reach the network where the shared file or http:// address is, or that the file that's there isn't able to be read - maybe a permission issue - or that when the CICS Explorer tried to parse the file it came across something it didn't like. When the remote file can't be read - the CICS Explorer doesn't clear out the connections it read from the file the last time it was successful - it leaves them there as this is the last known good set of connections.
There is no limit to the number of files containing connections which you can dynamically load. Each one will appear as a top level tree node if you have Show links toggled on. When I say no limit to the number of remote files - there probably is a number in the housands where if you create enough something in the JVM would pop, wobble and fizz. Yikes ! That sounds like a breakfast cereal - let's move on switfy to preset connections and what they're all about.
When the CICS Explorer starts it always looks for a file called connections.pref in the same folder as the cicsexplorer.exe. This is a good way to distribute a set of connections if you're using a shared network drive to launch a copy of the CICS Explorer across your user community without having to install it locally on their workbench, and also can be combind with the Java Web Start solution that my colleagues Dave Nice, Steve Bolton and Nick Bishop recently described in their recent developerworks article Deploy CICS Explorer using Java Web Start. I'll cover the various ways to distribute CICS Explorer copies in a future blog, for now I'll stay track on connection distribution.
So .... what I did was create a file called connections.pref that looks like this
I only have one connection in here - an FTP one to connect on port 1234 to an imaginary server. The confID is a unique key which is autogenerated each time a connection is added to the CICS Explorer - however if you are doing copy and paste of lines in a file to hand crank connections - then just be sure to make the configID unique. This is what the explorer uses to match connections from remote files between refreshes to distinguish adds from updates, and only one connection can exist in a CICS Explorer workbench with the same unique key irrespective of how it got there.
Then I put the connections.pref file into the folder where I launch my CICS Explorer from.
Then when I start the CICS Explorer I will get a special folder called Preset Connections which represents the connections that come from the special file connections.pref in the .exe location. Similar to connections dynamically loaded, they have the graphic in the bottom left corner indicating that they come from outsdide the workbench and their entry fields are read only in the Open... dialog.
Note that you don't need to use the connections.pref file - nor do you need to create remote files with lists of connections. You can carry on using connections as before where each CICS Explorer user had their own set and enjoy the improved user interface - the sharing of connections via mapped drives or http:// servers, or files in the same folder as the cics
Connecting to a connection
You might be thinking that this blog has so far only talked loads and loads about the new conection user interface to manually create new connections, export them, and then share that file either with a network drive or http:// address or by putting the connection file in the same folder as the cicxexplorer.exe. You're right - and you're forgiven for wondering when this blog would actually get around to how to use the connection(s). Once you've got all these wonderful hosts and ports - the real fun of course only starts when you use them to log onto a system - fill up a view with data - and start exploring !
To use a connection to get into a z/OS port it's pretty much a certianty that the port is going to be authenticated on z/OS with a security manager such as RACF, and that you'll need to provide a user ID and password combination. The CICS Explorer calls these combinations credentials. Previously - in CICS Explorer 1.1.0 - you had to create credentials and assign them, one by one, with connections as they were created. It was fiddly, and folks didn't usually give that many stars in feedback forms for what they felt about the whole process. So ... we made it better.
First - you can have connections without credentials in your workbench. In fact - we've got this far without creating any credentials - just to prove this point. We have 1 preset connection - 1 local user defined connection - and 23 dynamically loaded connection and not a credential in sight ! (If we had used CICS Explorer 1.1.1 with a 1.1.0 workspace that had connections previously defined we would see them in the Credentials view - more of the forwards compatability thingy in action there folks!). Credentials are asked for when they are needed, which is when you try to connect, although they can be created beforehand and associated with connections. There are four possible states the CICS Explorer can find itself in when using a connection and its associated credential.
1) There is not a credential anywhere to be found - in which case one needs to be created
2) There are credentials in the workspace, however this is the first time you've used a particular connection the CICS Explorer needs to know whether you're going to use an existing credential, or create a new one
3) There is a credential associated with the connection - however you've not used it before for this particular CICS Explorer session. The CICS Explorer needs to prompt you with the user ID and password to let you confirm nothing has changed
4) There is a crednetial associated with the connection and you've managed to successfully log on to another connection using it already in the same CICS Explorer session. In this case the CICS Explorer knows that it's valid.
1) No credential anywhere to be found
The first time you attempt to make a connection if there are no credentials the CICS Explorer realizes you need to create one, so it does to at the same time it collects the user ID and password. The dialog is a bit like the one when you create a connection in that it defaults the name as you type. In the screen shot below I was connecting to a CICS system whose host IP address is cics
After pressing OK the connection in the title of the dialog - cics
2) There are credentials in the workspace, but this is the first time you've used a particualr connection
We've connected cicsexp1host:27062, however there are many other connections in the Host Connections view. Let's select another one - this time the CICSEXP1 (SingleServer). This is a dynamically imported connection so it has the bottom left corner NE facing arrow so we can't change its host and port details which come from the remote master copy file, however can assign it credentials which are always held locally in the workspace.
When you use a connection which has no assigned credential the sign-on dialog gives you the chance to create a new credential, however it recognizes that are existing credentials that you might want to re-use. There are a couple of radio buttons asking you what you'd like to do - re-use or create. The re-use radio has a combo box of all konwn credentials, and the create radio button will enabled the UI controls to let you create a new credential, similar to the dialog used when no credential existed in the worksapce.
Once you've signed on with this connection it is now shown in green in the host connections view. It also has the credential associated with it in its text.
You don't have to wait to actually connect to associate a connection with a credential - you can use the Add... button on the Credentials table on the right hand side of the view to bring up a dialog that lets you just create ad-hoc credentials. This might be useful if you have a user ID for production and another for test - or different ones for different LPARs.
If you want to you can use the pop-up menu against a connection, or connections (multi-select is supported), and you can assigned a whole set at once. To show this I've created a second credential called WINCHJ@LPAR2, and selected a number of connections and opened the pop-up menu.
The pop-upe menu Set Credentials> has menu itmes for each credential - and you can choose it and assign a bunch of connections to use a credential at once. You can re-assign a connection which has an existing credential, but one thing you can't currently do is change the credential for a connection which is active. We did actually code this, but ran into too many problems with whether this means you should disconnect and re-connect, what if the user did it by accident and we lost their data, etc..., so we took the decision that only disconnected connections can have their credentials assigned through the pop-up menu.
3) If there is a credential assigned with a connection, and you've not used it so far in this CICS Explorer session,
Even if you took the option to save the password, we always take the decision to re-prompt you to sign on. In the screen shot above the credentail WINCH@LPAR2 doesn't have the green arrow next to it, which indicates that it hasn't been used yet to connect. At one point we did just flow the saved password down the wire and attempt to connect, however the problem was if the password had expired or been changed and we used one which was now bad, we ran into the possibility that we'd use up one of the user's three lives to get it right. To play safe, we therefore always will re challenge the first time we're using a user ID and password combination.
4) There is a credential assigned and it's already been used to successfully signon in that CICS Explorer session
This is the simplest of all scenarios - we know which user ID and password to use - we know it's good. What we do here is just connect without any pop-ups. It's silent - all you know as a user is that your empty views get data in them.
Quickly creating or switching connection
In the bottom right corner of perspectives in the CICS Explorer is what we call the trim widget. This is quite a poor name and it's because we couldn't think of a better name, but it is a widget, and it's in the trim area of the workbench shell, so until we can think of a better name I'll refer to it as the trim widget.
The trim widget has always been in the CICS Explorer and allowed you to switch connections and open the preference page (now replaced by the Host Connections view) to add new connections or change conn
If you select the trim widget itself the behaviour used to be to open the preference page for the currently acitve connection - what we've done is leave this behaviour there but instead we open the edit connection dialog which allows you to modify the host/port, etc... You can also use the trim widget - as before - to select other connections to switch to - rather like switching channels on your TV remote.
The Full Monty
Rewriting connections was something we've been wanting to do for a while, not only because it was one of the first parts of the CICS Explorer built and needed a make-over, but because it is the shared component that all tools plugging into the CICS Explorer need for their user to operate. Share componentry is good for IBM because it means we only have to write it once - fix and test one component - and it's good for you good folks out there - because you only have to learn a single way to connect. Single sign-on - not having to challenge you for user IDs and passwords over and over is something that people did complain about, so now hopefully you can connect more easily and find other scenarios where our CICS Explorer family of tools can be improved in terms of how it can help you do your day job better.
One of the reasons we re-wrote the connections user interface for our CICS Explorer 1.1.1 release, is because this componentry is used by the IBM problem determiniation tools to connect, as well as the existing CICS tools. The screen show below shows a CICS Explorer which has a number of tools plugins. Application Performance Analyzer, CICS Deploment Assistant, CICS Configuration Manager, Debug Tool, CICS Interdependency Analyzer, CICS Performance Analyzer, Fault Analyzer, File Manager, CICS Transaction Gateway, and Workload Simulator. All of these tools use the connection framework in the CICS Explorer.