CICS Explorer runs on your PC, and when you start it up apart from
looking fabulous, doesn't become that useful until it connects to some
kind of server on another computer. In our very first release of the
CICS Explorer back in 2008 there was only one kind of connection you
could make which was to a CPSM Web User Interface server and all you had
to do was know the host and port, together with your user ID and
password. One of the driving forces behind the CICS Explorer is to
provide an integration platform for tools which add value to a CICS user
- whether they're a system programmer or a developer - and these tools
typically have their own servers which provide data useful to the
particular CICS Explorer views that their plugin extends the workbench
with. Even without any tools the CICS Explorer has two different
primary sources of data - CICS regions - or z/OS - and each of those has
two different ways of connecting.
To net it al out - what worked four years ago for a user interface to manage connections - needed a redesign.
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.
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
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 patience - now we can begin the main act.
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.
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 sharing.
you create using the Add.. dialog are local to your workspace. This
seems a bit of a shame, because if you have any other CICS Explorer
users in your company, chances are they're going to want to connect to
the same systems, and folks told us that having every CICS Explorer user
in an organization seprately add hosts and port details was bad for a
number of reasons, the most important being that the details are
volatile - they can change as systems are added, ports changed, host
address modified, and so forth. Second, is that to use the CICS
Explorer requires a connection to a host and if the user experience
doing this is less than perfect then they're by the time they get to
unleash the power of a CICS Explorer connected to CICS or z/OS they're
already less then pleased. This is what folks sometimes call an "out of the box experience".
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 automatically propogated to the other workspace without a manual re-import. The second way - which is new in CICS Explorer 1.1.1 is what I call a dynamic import.
The second workspace retains memmory to the location of the file
containing the connection details and treats this as a master copy.
Each time the CICS Explorer starts it will look for the master copy and
then get the most current list of connections from there. If there is a
new connection it will be added - if details such as
name/host/port have been changed then they will be update - and if a
previously dynamicaly imported connection is no longer in the master
copy it will be deleted. This check for updates will
not affect any connections in the workspace which have been manually
added - and you can have multiple dynmically linked connection master
copy files. Connection files can be imported - both statically and
dynmically - from either a mapped drive address, e.g. z:\explorer_connections\production_systems.pref or from an http address, e.g. http:\\my_web_server\explorer_connections\production_systems.pref.
tried a couple of times to rewrite that last paragraph to make
it easier to follow and I've failed both times, so I'll try to do a sort
of demo with screen shots.
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
hursley_cics_systems.pref. At IBM we each
have a little bit of storage on an http server where we can share stuff
with colleagues and I copied the file to a location that everyone can
reach, which is
my colleagues need to do in their CICS Explorer workspace
is dynamically import this file, using the import dialog which is
launched from the toolbar button in the Host connections view that has
the picture of a green arrow entering a computer. The arrow entering
the computer is for import - the arrow leaving the computer is for
export. Long live sensible icons.
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.
OK - the file contents are retrieved - and turned into connections.
What this means is that whoever is responsible for updating the hursley_cics_systems.pref
file (me for the purpose of this blog entry) has just managed to share
details for twenty different CICS systems' connection details. as well
as three z/OS systems that have FTP ports open on them.
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 hursley_cics_systems.pref have the little link arrow in the corner.
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.
is no limit (within reason - I'm sure if you used millions something
would probably go pop or fizz in the JVM) to the number of files that
you can dynamically load connections from. 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.
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.
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
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
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 cicsexplorer.exe, is new stuff designed to help CICS Explorer users where these scenarios make sense.
Connecting to a connection
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 !
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.
- 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
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
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
1) No credential anywhere to be found
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 cicsexp1host.hursley.ibm.com. I typed in WINCHJ as my user ID and the name of the credentials automagically chose WINCH@cicsexp1host. This
is a concatentation of the user ID and the first segment of the IP
addres, and is useful to distinghish the credential in case I'm going to
use more than one. I could change it to something else, e.g. WINCHJ@LPAR1"
After pressing OK the connection in the title of the dialog - cicsexp1host.hurslehy.ibm.com:27026
will be contacted using the user ID and password entered. If there's
any kind of error a redX wil be shown against the connection and hover
help will display the problem. The screen shot below shows that all
went well for cicsexp1host. In addition, the credential which was
created during the sign-on process has been created and appears in the
right hand side of the Host Connections view. The green ticky shows
that that credentials is being used. Also, as well as the
cicsexp1host:27062 connection having a green connected icon, it has the
credential name on the right side of its description. in a rather
fetching brown colour.
2) There are credentials in the workspace, but this is the first time you've used a particualr connection
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
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
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