z/VM Graphical User Interface Program Project

I've completed the porting of the file editor code. its now all pretty, Javadoced and conforms to the new style and all coding conventions. I've also completed overhauling the exception handling code so that all (well, most) exceptions inherit from a base exception to allow catching all exceptions you care about and handling the rest with a single generic exception handling routine.

I think we would be better off, instead of coming up with a single monster monolithic design, developing a series of rapid prototype projects that we can continue to improve on. Throughout doing this we will be able to pinpoint sticking points and take care of troublesome details that we could never think of in a design meeting. All of the prototypes could then be combined and/or refactored to conform to any new standards and/or coding practices that we come up with along the way. This new system will also have the added benefit that some of our tools will be able to be created quickly and people will be able to start using them. We will benefit from us being able to actually test them and from the community being able to test/try them. We may even make a small name for ourselves :) This new system needs to be designed as soon as possible and we should hit the ground running next semester. We already have a few of the tools in development as proof of concept projects. There is the CMS File Editor, then DASD Copier/Formatter, and the z/VM Network Manager.

- Jason J. Herne (hernejj@clarkson.edu)

Planning continues for both the CMS file editor and the DASD coppier/formatter, but in more exciting news, code has been written for the new file editor :) A cmsFileEditor module has been created and the first of its functions (boolean cmsFileExists()) has been written and tested. A test framework is being put into place that will be able to be used to test the entire code base.

As soon as IBM gives us the go-ahead, we'll be making the code publicly available be way of a cvs/svn/arch server.

- Jason J. Herne (hernejj@clarkson.edu)

A lot of us vm gui guys have been busy with another project lately, but now that we're starting to get ahead, we should have a little more time to put into this project. With that said, IBM is gearing up to officially release my code from this summer as open source, this should be happening in 2 days. When that happens the DASD formatter guys are ready to start writing code :) Also, plans and code will be written for the new and cool VM file editor. See the bug server for more details.

- Jason J. Herne (hernejj@clarkson.edu)

We're still working :) The DASD project planning is well underway and close to being done and the code cleanup is still in progress.... hey its a lot of work :) Hopefully we'll have more interesting things to report after the next meeting.

- Jason J. Herne (hernejj@clarkson.edu)

We had yet another meeting this week. We talked about coding standards, old assignments, and the new DASD formatter project. People have been great at getting things done :) We've closed bugs related to language settings, functionality document changes, CMS User Monitor bugs, and documentation. Nothing overly exciting to report, but we've been busy chipping away at the little things.

- Jason J. Herne (hernejj@clarkson.edu)

Things have been progressing slow as of recent, but I suspect that out progress will speed up rather rapidly now that we're five weeks in :) Everyone's been experiencing a bit of pain as this semester is proving to be a little more work than we though.

The bug server is finaly clean and up to date. Team members have had formal assignments for about 2 weeks now, so progress should be comming soon. I'm cleaning up our code base and writting some documentation that newcommers will be able to use to get started on the team. As part of that initiative, I've created a coding standards guideline that all code contributed to this project should adhere to. Look for the link at the end of this posting.

We're starting the planning for a proof of concept style program that will allow a user to graphically manage formatting and coppying of DASD packs. This should be interesting when it's all done. We'll be sure to make plently of announcements as this sub-project progresses.
Coding Standards: [Open Office] [PDF]

- Jason J. Herne (hernejj@clarkson.edu)

Hey now! Welcome back :-D !! Its been a whole summer since the last update to this page. This may lead you to believe that nothing has happened. Well, on the contrary, lots of things have been going on that directly affect this project. I actually got to work on it as part of a summer internship at IBM! The result of which is a semi functional z/VM virtual network management tool. After we get clearance from IBM we can merge the code in with our code and release as open source. Until then, we'll just have to continue working with what we have.

In other news we had our first real meeting yesterday! We got a lot of review done and are ready to forge on into the depths of the z/VM Gui project! We made a little bit of actual progress towards a few of the bugs in our bug server. As it turns out, saving half of our meeting times for actual hands on work is a very effective way to get things done!

So now that we're rolling again, expect regular updates at least once a week.

- Jason J. Herne (hernejj@clarkson.edu)

It's been almost a month, finals are over and the summer is about to begin! Some of us will be working, others doing research, and some of us won't really be doing much at all. What this means is that there may be a group of people willing to work on the project over the summer. I myself might be in a position to put a very large chunk of my time towards the project. Stay tuned as I'll post updates when I know more. :)

- Jason J. Herne (hernejj@clarkson.edu)

We had our last meeting of the semester today. Fear not! Some (most) of us have decided that we want to work on this prokject over the sumer. So check back here from time to time and expect updates :).

We made a couple of changes to the modules diagram. We removed the UserDirectoryLine and UserDirectory Entry because they are no longer needed thanks to our decision to use SMAPI to handle the USER DIRECTORY. We also removed the VNic_Address module. This seems pointless as there is never any management that needs to be done on a single virtual network card address.

We started documenting the VLan, VLanManager, and VNic modules. This marks the beginning of our expedition into the horror that is the Network Manager!

Everyone looked at and agreed on our choice of license and our license notification comment that will be placed at the top of all of our code files. All that is left to do is clear the license with the Cosi advisor and we'll be able to post code! YYAAAAYY!! Sorry for the wait.

Thanks to Andrew for his work with a REXX script that will allow us to constantly feed output from a guest to a telnet connection! This is wonderful functionality that we will surely be able to use. :)

Thanks to newcomer James Kraetz for redesigning the GUI for the CMS File Editor. It looks much better now!

- Jason J. Herne (hernejj@clarkson.edu)

Wow! :) We're officially 10 meetings old now! Sorry this update is so late, this has been a very busy week for me. Last meeting we continued work on the modules diagram. We discussed and documented the JobQueue, Job, and DASDFormatJob modules. These modules are complete (well, as complete as the others ;) ) and can be used in the next proof of concept project. We will not be having a meeting this upcoming Sunday due to easter. That means that there are only two more meetings left before the end of the semester.

I know, I owe everyone an apology for not having the CMS File Editor done on time. It seems like every time I'm ready to do a release, a bug pops up. This time, I believe I have tracked down the last of the bugs. I am hoping to have the code and binaries posted this weekend.

We've complete the VMGUIOP installation and evaluation. We've determined that at this point we will need to understand how the product works before we decide to use its methodology. As a service to Sine Nomine, we have prepared a product evaluation for them. We'll be sending that off to them today.

- Jason J. Herne (hernejj@clarkson.edu)

Updated the modules diagram to indicate what we have documented and what we have coded. a D indicates a module that we have documented and a C indicates a module that we've coded.

DASDManager and sub modules have been updated again. We decided that the proper place to put a format method for DASD is in the DASD module as format is an operation that applies to a single DASD pack. We decided that the DASDManager would handle copying a DASD to another DASD because it would have instant access to both DASD packs as it knows about all of the DASD on the system. The MDISK object should handle formatting itself for reasons similar to the DASD argument. And MDISKManager will handle the copying of MDISKs because it is the closest abstraction we can use and still be dealing with MDISKS. An MDISKManager only contains MDISKs that reside on a single DASD pack. We could end up copying an MDISK to a destination MDISK that is on a different pack. This is Ok and although it is a little obscure, there is simply no better way (that we can think of) to do it.

We also thought of a possible solution to our z/VM Telnet line mode "half duplex" problem. Our idea is to use a REXX script to execute a command (like Dirm commands) and then wait until DIRM returns a message, collect that message in its entirety and the return it by spitting it to the console and returning. This should cause z/VM to halt and not immediately return control back to the client AND allow us to easily receive DIRM messages from the zVMCommandLineController.

We were also very lucky to get a quick demo of Kevin's "CMS User Monitor" program today! On startup it gives the user a list of guests on the system and allows any of them to be forced offline. It also has the capability to XAUTOLOG a guest name entered by the user. Kevin neatly sidestepped our "half-duplex" problem by sending an "enter" keystroke to z/VM every once in a while and parsing the login/logout messages that have come in since the last poll. Actions take by the user update the list immediately and for the impatient, there is even a refresh button. As soon as the code is polished, tested , cleaned and licensed we'll be posting it for your viewing and executing pleasure.... right along with the CMS File Editor.

On a lighter note, we enjoyed a tasty pizza party today! :) The votes are in and its unanimous, Little Italy's pizza and garlic knots RULE! Thanks to Jeanna Matthews and the Clarkson Computing Lab fund for helping with the bill for this event. Also, special thanks to the COSI Soda Fund and the COSI H2O Collection Agency ;).

- Jason J. Herne (hernejj@clarkson.edu)

Many thanks to Andrew for doing some research on PROP. PROP is a tool one can use to "route" z/VM messages to different guests based on their content. You can also cause a script to be executed to perform an action based on the message. This is cool stuff and it may come in handy in the future.

PROP Writeup: [Open Office] [PDF]

- Jason J. Herne (hernejj@clarkson.edu)

Well well, 13 days without a post. Thats our longest span yet. Blame spring break! Meeting number eight went very well. We discussed and spec'ed the MDISK, MDISKManager, and DASD modules. It was decided that we will have the MDISKManager perform certain tasks on its MDISKs including copying it to a new DASD pack, moving it to a new DASD pack, changing the MDISKs owner, and changing it's virtual address. All of these functions can be used to implement the ability to have an end user be able to move, delete, copy and add minidisks in an explorer style (drag and drop / context menus) fashion. All of this is sort of a departure from our original thoughts on the involved modules. We feel that the added functionality is worth the tiny bit of confusion we'll have to endure ;). On a related note, we also decided that the actual "work" involved in copying the DASD packs and doing the ownership and/or address changing will be outsourced to the Guest/GuestManager module (because it deals with directory entry stuff) and the DASDCopyJob module. So no "meat and potatoes" code will reside in these functions. They will simply be tiny functions that use other modules to get the job done while looking for errors and reporting status and progress as much as possible.

Status note on VMGUIOP: It is installed on z/VM and I've installed the z/VM GUIPACK module client on a windows machine. We're hung up on a configuration file issue and an outdated version of the CMS PIPELINES module. VMGUIOP is our *top* priority right now as a successful evaluation is needed to help us decide which tools we will utilize when we sit down to code the GUI Program.

Java CMS File Editor Status: A rather nasty bug has been found in the zVMCommandLineController module and is being resolved. We've started looking at licenses but have yet to choose one. And the error handling is comming along nicely. Sorry about the delays on this.

Java CMS User Monitor: Kevin has been getting quite a bit done on this. Recently our z/VM TCPIP stack has been "out to lunch" more often than its been allowing connections so he, along with the rest of us, has had a little trouble getting work done. Stay tuned!

- Jason J. Herne (hernejj@clarkson.edu)

It's practically complete. I have fixed the special characters bug (for all the special characters I could find) and updated the poc-editfile documentation to show how this is done. Just as soon as I add error handling (easy) and we choose an appropriate open source license, I'll be posting the code. This should happen within a week.

- Jason J. Herne (hernejj@clarkson.edu)

Today we discussed the conference call that we had with David Boyes and Dave Jones from Sine Nomine Associates. David basically proposed that we abandon attempting to write a telnet and/or SMAPI interface module and instead adopt a CMS based server component written in Rexx. Sine Nomine has been experimenting with the idea of writing a z/VM GUI management program for some time now and has some significant experience to bring to the table. As a group we decided that we need to get more information regarding their CMS Server component and what each parties role in a collaborative project would be before we make any final decisions, although we are quite excited to evaluate their first verion of VMGUIOP and see exactly what advantages it could offer.

in our discussion regarding the conference call we added a few things to the bug tracker. We determined that someone needs to evaluate VMGUIOP. We need to find a way to deal with multiple languages and the fact that users of our program may have z/VM set to output information in another language. We also need to research SRPI and IUCV. I also ran across some information about a GUI toolkit built into z/VM known as the Graphical User Interface Facility. This is something else that needs looking into as it may provide some tools that could be helpful.

We also questioned how we will deal with error handling in terms of z/VM command execution. Does it make sense to have a separate class for each command that knows all about that command including syntax and how to parse the output and detect errors and error codes? Or is it better to have a method for each command in the zCMCommandLineController class that handles execution, error code checking and returning output. We left this undecided for now. We will come back to this after we've all had a little while to thing about it.

The second half of the meeting was spent working on the module design documentation. We discussed the CPU, DASD, MDISK and MDISKManager modules. it was decided that an MDISKManager object should be passed a copy of the z/VM User Directory for the purposes of learning which MDISK's belong to the DASD it resides in. The DASDManager will be passed the output of the Q DASD command which will be parsed to learn about all of the DASD devices on the system .

- Jason J. Herne (hernejj@clarkson.edu)

After a long two weeks of midterms and projects, The CMS File Editor program has been completed...well, for the most part. The TelnetController, zVMCommandLineController, and CMSFileEditor modules have been implemented and a basic GUI has been put together to allow a user to edit files. I'm currently plagued by some special character printing bugs, but nothing that can't be fixed. As soon as they are fixed I'll be posting the code here for all to see and experiment with. Many thanks to Kevin for researching a solution to my special character problem!

- Jason J. Herne (hernejj@clarkson.edu)

Thanks to Kevin and Andrew for doing some very useful research and creating documentation for everyone! Kevin's document deals with getting information about CPU's and dedicating them to guests. It's currently available from the bug server but Open Office and PDF versions are on the way. Andrew's document explains how to use the SET OBSERVER command to cause all of one users console I/O to appear on another users console.

Console Monitoring: [Open Office] [PDF]

- Jason J. Herne (hernejj@clarkson.edu)

Today we talked a lot about the whole Dirmaint/SMAPI/Do everything ourselves issue. We concluded that we need more information so we are going to wait for more of a response from the marist S390 list before making a decision. Until then we'll plow forward with our design :). We filled in even more of our Module Description document only we decided to create several documents instead of maintaining a large monolithic one. A link to these will follow. We also defined a few more tasks that need to be accomplished. Please check the bug server for more information on these. We also made very minor changes to the modules diagram, mostly name changes but you may want to grab it again to keep up to date.

Module Description Documents

- Jason J. Herne (hernejj@clarkson.edu)

We now have our very own project in the Cosi bug server. Everyone will be reporting bugs and tasks to be completed here. Team members can also find out if they have any outstanding tasks as well.

- Jason J. Herne (hernejj@clarkson.edu)

We're back from break and hopefully well rested ;). We all agreed that we have a good modules diagram and that we should start discussing the description, properties and methods of our modules (thanks to Kevin for looking this over during break). This is yet another design document that we will work out slowly. We actually got started on this today and even though there really isn't a whole lot in the document I thought I would post it for those that are interested.

We also came up with a list of outstanding tasks/questions that need to be addressed:

• To DIRM or not to DIRM? - Should we use Dirmaint for managing the user Directory or not? If we do, then we get a large chunk of functionality without lifting a finger. However, use of Dirmaint requires that the user have Dirmaint and SMapi installed and functioning. Also, we may lose the ability to control certain things if we do not like the way Dirmaint handles a particular situation. If we do not use Dirmaint then we must write all of our own code to manage the user directory AND deal with the fact that the user COULD be using either a monolithic or a microlithic directory structure. But we get full control of how tasks are handled. We posted a message to the Marist S390 mailing list asking people what they thought about Dirmaint. We are hoping that their responses will help us with this decision.
• Do we need a NetworkManager object? Is this object simply a ghost container that will contain no functionality or will it serve a purpose? Time will tell.
• CMS File Editor needs to be completed (in progress).
• Module task definition (in progress).
• Think about and possibly start planning a GUI design (later)
• Research good Java GUI development tools
• Research possibility of getting more info about real OSA cards. Would be nice if we could get the same info as we can with virtual NICs.
• Research the Performance ToolKit. What can it tell us? How can we interact with it through VM and/or its web interface.
• Learn more about how to get CPU info from z/VM (in progress).

We are kind of behind schedule at this point. We are only about a third of the way through the Specification phase (still have module descriptions and index card testing) and we are supposed to be done this week. This obviously will not happen. Its okay though, the schedule was tentative and as it turns out it is way too demanding. Next week we should come up with a more realistic schedule so we will know where we will be at the end of the semester.

Module Description Document: [Open Office] [PDF]

- Jason J. Herne (hernejj@clarkson.edu)

I've updated the modules-v2 diagram as well as the functionality documentation and the CMS command line editing proof of concept document. The modules diagram was updated to include a broader view of the TelnetController. The functionality doc changes were all spelling error corrections. The CMS command line editing poc doc was overhauled to include more information. While working on the CMS file editor I ran into a few problems interacting with CMS which were all related to the use of the command line to write to a file. I found solutions for all of these problems and documented them on the command line poc doc.

- Jason J. Herne (hernejj@clarkson.edu)

After a four day break and many hours of coding and packet sniffing (my nose is kinda numb :( ), I have managed to write a very basic Java GUI file editor for CMS. It connects and establishes a telnet session with a z/VM instance, logs in as the user of your choice and retrieves the contents of a specified file and displays it on the screen. File saving capabilities have not been implemented but should be coming soon. I'm learning a lot about using Telnet to interact with z/VM and devising a good object oriented design solution in the process.

- Jason J. Herne (hernejj@clarkson.edu)

Today I captured (using Ethereal) a telnet communication between me and z/VM for the purposes of learning the underlying protocols that will allow the COSI z/VM GUI team to write software to communicate with z/VM via a telnet session. The experiment was quite successful :) Here are my notes.

z/VM Telnet Interaction Study: [Open Office] [PDF]

- Jason J. Herne (hernejj@clarkson.edu)

After quite a few hours of debate and discussion we ended up significantly changing some design decisions with respect to our module diagram. So be sure to see the version 2 diagram that that is at the end of the section.

Everyone was in favor of the initially proposed virtual networking infrastructure. We also decided that the "Pool" concept(a collection of objects of same type) seen in the previous chart can be removed from the diagrams and will be implied from now on. Instead of creating a separate Pool object everywhere we will use some form of a List in Java to handle this. Manager objects were added to contain anything that needed them. A Manager object is responsible for actions to be performed on objects it contains. For example, the Guest manager will be responsible for adding, removing and modifying guests. The concept of an abstract class was introduced. Job is an abstract object that can represent a Copy_Job or a Format_Job. Each job type can be added to the Job_Queue for execution. We also created the Alert_Manager and Alert objects.

Module Diagram V.2: [Dia] [JPG] [PNG]

- Jason J. Herne (hernejj@clarkson.edu)

Today we discussed licensing and the possibility of getting a SourceForge.Net page for our project. This may or may not be necessary anymore as we now have this web space and Cosi may set up a CVS server. however a SourceForge page would make our software much more accessible and provide a 24/7 backed up hosting and storage solution with no hassle to us.

For the last two hours of the meeting, we worked on breaking the program up into modules. We made decent progress and I'll post a follow up Dia diagram for clarification. We had quite a bit of trouble coming up with a method to accurately and concisely describe the networking structure that we would have to work with. We ended up coming up with a myriad of ideas that I sorted through and put the most logical sounding one in the diagram. in the process of discussion, we talked about how VLans and VSwitches work. I also made up a Dia diagram to explain this.

Early Module Diagram: [Dia] [JPG] [PNG]
VLan and VSwitch explanation: [Dia] [JPG] [PNG]

- Jason J. Herne (hernejj@clarkson.edu)

Yesterday Ryan and I met to work on the functionality document and today I put the finishing touches on it. The doc might still need a little bit of work but nothing major.

Functionality Document: [Open Office] [PDF]

- Jason J. Herne (hernejj@clarkson.edu)

Today's meeting was very productive. :) We made some progress on the functionality document and even set next Sunday as an estimated date of completion for it. We also made up a tentative schedule for the rest of the semester. The schedule is quite demanding and may turn out to be too much to keep up with but we all feel strongly about trying to release code at the end of the semester so we will try. To aid us in keeping pace we're going to start meeting for 3 hours a week instead of 2. Kevin and Jay volunteered to research the possibility of supporting a plugin architecture and Kevin took on the task of doing a Proof of Concept on file editing from the CMS command line. This type of functionality would be really useful in managing the SYSTEM CONFIG.

Tentative semester schedule
Editing file from CMS command line: [Open Office] [PDF]

- Jason J. Herne (hernejj@clarkson.edu)

I participated in a conference call with IBM today. It turns out that are *very* interested in our project and want to try to work out a method in which we could work with them collaboratively on a z/VM GUI project. There are no details to this yet but I'll make them available as soon as possible.

- Jason J. Herne (hernejj@clarkson.edu)

We had our first meeting of the semester. We reviewed what we did last semester and went over the incomplete functionality documentation that we had started. This semester we'll be concentrating on finishing the functionality doc, specification documentation, and detailed design. If there is time it would be cool to be able to get an alpha/beta version written.

- Jason J. Herne (hernejj@clarkson.edu)