The following is the e-mail I wrote to 'rthelen(at)de.ibm.com' with
my comments about Msys for Setup. Please tell me what you think about
this jewel.
Hello. I am a System Programmer which is about to finish to setup
z/OS 1.3.
Sorry for my poor english, it's not my native language.
This are my <<personal>> comments about msys for Setup. This is my
<<personal>> opinion and not necessarly the opinion of the company
I'm working for.
First of all, being a relatively experienced System Programmer and
this one not being the first MVS that I customize I must say that the
idea of a tool that does the things for me when I first read about
msys for setup was both appealing and frightening.
I started by customizing the old traditional way and this is the
first thing that I disliked about the tool: you need to setup most of
the OS, setup USS, then setup TCPIP, setup LDAP, setup DB2, install
Java, just to start to connect to the tool that says that performs
the customizations for you. I did not find this much encoraging...
I then started to play with the tool (1.3 version) which was full of
bugs and I could not even finish a single refresh task (many, many
hours of wasted time)
So I tried to check for updates and I finished downloading the 1.4
version from the Web.
With the new version I was able to almost do all the customisation
tasks just to see that the parmlib that where modified where almost
identical to what they already were (some days of wasted time)
On the performance point of view, the use of Java as a programming
language might have been a good choice for the msys for setup
programmers as a sandbox for future project. In this case this was
the worse choice as an environment. First of all you might expect
customers preparing a new version of an OS to work on a mini
partition with only a few MIPS available and only little Central
Storage. Java is both memory hungry and CPU Intensive. Also LDAP as a
database for storing the information is a bad choice because it needs
too much setup and is both memory hungry and CPU intensive too AND
the combination of the two things make the whole system very slow and
very boring to use.
From the functionality point of view I judge the Parallel Sysplex
Dialogs somehow useful for people trying to setup parallel sysplex
for the first time. But that's it. For customers that have Parallel
Sysplex already setup it does not add any value.
Other tools like ISPF, TCPIP and LE dialogs could have been useful,
but are useless because they don't gather the data from the currently
running system or from another system that is already cusomized. I
was not sure of which parameter were changed by some values entered
in the graphically appealing but otherwise useless dialogs, therefore
I preferred not to use the tool at all.
Also the tool does not provide any guidance (as far as I could see)
for cloning or propagating a new version of the OS in production, so
no added value there also.
The cherry on the cake is that I could not manage to use the TCPIP
customization (some errors always occur while simulating a prepare
update). So I decided to stop using the tool !
To summarize:
The idea of a set of tools that help system programmers in their
setup job is good. Msys for Setup does not answer to this idea at
all. It is just a useless piece of software that burn disk, memory,
cpu and network resources.
If you really want to do something useful STOP developing msys for
setup the way it is now and START with a tool that: needs only
TSO/ISPF/JES2 to be setup (which is usually done as the first step in
a new system) Use ISPF panels as an interface to the dialogs that
1) ask you about some initial data
2) build jobs using skeletons to gather system data using MVS base
supplied tools
Then let the System Programmer modify the job and submit it. After
the jobs are run use another ISPF panels based dialog that:
1) parses the output of the jobs
2) puts the parsed data in either sequential or VSAM datasets or even
ISPF table and/or variables BUT NOT DB2 or LDAP (in a new system they
are not already setup).
3) shows some new panels to allow the customer to change the data and
build jobs or sample parmlib members and instructs the customer on
how to change the system.
This would be a way a system programmer would like to be helped !
Another valuable tools would be something that lets you handle
catalogs, dasd and smp to clone part or the whole OS and to port a
newly customized OS in production.
Maybe I am the only system programmer that thinks what I wrote. Ask
some other system programmers and see. I don't believe that I am the
only one.