Bringing the fun back to z/OS - new course

[Steve Comstock]

To further the revitalization of the mainframe
market, I believe we need to make it more interesting
and relevant to work on the mainframe these days
(not necessarily simpler, ('though that can't be bad),
just interesting).

What seems to be most relevant, fun, and interesting
these days is all the technologies / capabilities of
the Internet and the Web. By a stroke of luck, the
z/OS folks have been working to allow this by setting
up z/OS UNIX (current name, after several iterations)
and providing a free HTTP server. A little tweaking
of parameters, a little modification of the system
start-up process and, lo and behold, you have a
capable, easy to use, and _free_ web server running
right there on your mainframe.

Now, the ability to run UNIX on the mainframe melds a
lot of strengths: flexibility (run classic mainframe
apps and UNIX apps on the same box), scalability,
reduced footprint, economies of scale to the UNIX
side of the house, access to batch, TSO, ISPF, CICS,
and a UNIX shell all at the same time, on the same
box. Utilize the legendary strengths of the mainframe
with the rich capabalities of UNIX, and you have a
hard-to-beat combination of economic power, business
strength, and appeal to new / young employees (not to
mention re-energizing current staff because they can
learn how to use the new facilities and leverage their
knowledge of the business).

Many of you know my feelings that IBM has done a terrible
job of telling the mainframe story. I'm still waiting for
the tales of shops switching to z/OS from UNIX, Linux,
or Windows server machines. I'm still waiting for my
colleagues to say they would encourage their kids to go
for a career in mainframes. I'm still waiting for prospects
we call on to stop saying either "We're getting off the
mainframe" or "We don't have a mainframe" [when we know
they do]. When those things start happening I'll know
that IBM has started to get the mainframe story right.

Doing our part, we are pleased to announce the availability
of our latest course, "You and z/OS and the World Wide Web".

This five-day course is designed to provide a rich, deep,
hands-on introduction to creating and maintaining a
corporate website hosted on your z/OS mainframe using
only the _free_ IBM supplied HTTP server!

The basic topics are:
  Introduction to the Web
  Introduction to markup languages
(SGML, HTML, XHTML)
  Markup elements supported by both the
HTML 4.01 and XHTML 1.0 standards
  Links and anchors
  Style and stylesheets (CSS - Cascading
Style Sheets)
  Lists
  Images and maps
  Client-side maps
  Embedding Objects (Applets, multimedia)
  Introduction to client-side scripting
  DOM - the Document Object Model
  Forms and controls
  Cookies
  Tables
  Framesets

More detail at:
http://www.trainersfriend.com/UNIX_and_Web_courses/u518descr.htm



The course includes 20 challenging hands-on labs, designed
to be solved using your z/OS server for coding and serving
and your workstation browser for testing and checking.

This extends our curriculum aimed at teaching how to build
and sustain Internet work running from the mainframe.



The student should have some background in z/OS UNIX before
taking this course, such as might be gained from our
three-day course "Introduction to z/OS UNIX"
(see http://www.trainersfriend.com/UNIX_and_Web_courses/u510descr.htm )


Although not absolutely necessary, it would be beneficial
for the student to have also taken our three-day course
"Shell Script Programming in z/OS UNIX"
(see http://www.trainersfriend.com/UNIX_and_Web_courses/u515descr.htm )



Now that's fun!


Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.
800-993-8716
303-393-8716
http://www.trainersfriend.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Bringing the fun back to z/OS - new course

[Barbara Nitz]

Steve's post prompts me to relate our MVS Unix/Linux experience - this is in
no way meant to disparage Steve's efforts for courses...

>Now, the ability to run UNIX on the mainframe melds a lot of strengths:
>flexibility (run classic mainframe apps and UNIX apps on the same box), 

You'd better not. We are running a clustered Lotus Domino Server on our
boxes and have to run several unix apps (ADSM - whatever that's called these
days, WBIFN - gateway to the SWIFT net and Websphere Application Server). We
found out very fast that these beasties tend to take over more than their
share of processing power, so all of these UNIX apps quickly got their own
lpar where traditional workload did not have to compete with these cpu hogs.

>scalability, reduced footprint, 

reduced footprint?!?
Even confined to their own lpars, the Dominoes take everything in terms of
assigned processors and lpar weight, to the detriment of other lpars. And if
these Unix dominated lpars don't get what they want, they stop working
altogether. 

We are in the process of moving the UNIX apps to Linux under VM, where they
can use the other type of processors and save us a lot of software costs
(BMC is killing us, followed by CA.) Did I mention that we now run almost as
many Linuxes as we run MVS lpars? Reduced foortprint?!?

>Utilize the legendary strengths of the mainframe

One of which was first failure data capture (and it worked, too, given the
right knowledge in looking at a dump). All of these UNIX apps have never
even heard the term first failure data capture, much less are familiar with
the concept. With the exception of maybe one (stupid) user error on our
part, IBM has proved incapable time and again to look at dumps (even those
written by the product itself) and find a problem. Unless you can reproduce
the problem, provided you have an inkling how, you get a lot of crap which
always involves restarting a high availability application.

And without a complaint on top a sev1/prio1 IBM doesn't even look at the
problem, much less solve it. Even with a complaint, all we get is what we
call in German 'holding hands' - meaning they commiserate with us but only
attempt to calm us thus infuriating us more.

I'd better stop here

Regards, Barbara Nitz 

-- 
Echte DSL-Flatrate dauerhaft für 0,- Euro*!
"Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Bringing the fun back to z/OS - new course

[Steve Comstock]

Barbara Nitz wrote:

Steve's post prompts me to relate our MVS Unix/Linux experience - this is in
no way meant to disparage Steve's efforts for courses...



Now, the ability to run UNIX on the mainframe melds a lot of strengths:
flexibility (run classic mainframe apps and UNIX apps on the same box), 



You'd better not. We are running a clustered Lotus Domino Server on our
boxes and have to run several unix apps (ADSM - whatever that's called these
days, WBIFN - gateway to the SWIFT net and Websphere Application Server). We
found out very fast that these beasties tend to take over more than their
share of processing power, so all of these UNIX apps quickly got their own
lpar where traditional workload did not have to compete with these cpu hogs.


scalability, reduced footprint, 



reduced footprint?!?
Even confined to their own lpars, the Dominoes take everything in terms of
assigned processors and lpar weight, to the detriment of other lpars. And if
these Unix dominated lpars don't get what they want, they stop working
altogether. 


We are in the process of moving the UNIX apps to Linux under VM, where they
can use the other type of processors and save us a lot of software costs
(BMC is killing us, followed by CA.) Did I mention that we now run almost as
many Linuxes as we run MVS lpars? Reduced foortprint?!?



Utilize the legendary strengths of the mainframe



One of which was first failure data capture (and it worked, too, given the
right knowledge in looking at a dump). All of these UNIX apps have never
even heard the term first failure data capture, much less are familiar with
the concept. With the exception of maybe one (stupid) user error on our
part, IBM has proved incapable time and again to look at dumps (even those
written by the product itself) and find a problem. Unless you can reproduce
the problem, provided you have an inkling how, you get a lot of crap which
always involves restarting a high availability application.

And without a complaint on top a sev1/prio1 IBM doesn't even look at the
problem, much less solve it. Even with a complaint, all we get is what we
call in German 'holding hands' - meaning they commiserate with us but only
attempt to calm us thus infuriating us more.

I'd better stop here

Regards, Barbara Nitz 



Wow!. Thanks, Barbara. I mean that. It helps me get a
little more real, and perhaps can help to wake up IBM
a little more to see this perspective and experience
shared in public. We need to push in order to improve
the product.

Kind regards,

-Steve Comstock

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Bringing the fun back to z/OS - new course

[Jack Kelly]

amen to Barbara's comments. glad to see that domino's support and appetite 
 hasn't changed. i haven't dealt with them for two years but i still can't 
even stand the thought of a domino pizza

Jack Kelly
LA Systems @ US Courts
x 202-502-2390

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Bringing the fun back to z/OS - new course

[Patrick . Falcone]

I would agree with Barbara on this. We run a mix of traditional work along 
with a Domino Change Management System with about 400 registered Users and 
WAS V4 in lightweight mode with about the same amount. Both applications 
can kill performance to our traditional workloads on our small 2 way. The 
WAS always sits at the top of the CPU usage monitor, again this is 
lightweight mode not full blown WAS, with the IDMS right behind it. The 
Domino application server task, at times, can dominate CPU as well. 

Since we  have been in a holding pattern while the bean counters basically 
decide our eventual fate I have been trying to hold the line as the 
production WAS environment adds Users who then navigate up through our 
traditional environment into our CA/IDMS. It has been a very delicate 
balancing act to see that the Production Users get service while I *try* 
to get cycles to the developers on this LPAR, no we don't have a test 
LPAR. If I had my druthers I would attempt to run the Unix workloads on 
their own LPAR where possible to eliminate the performance anomalies to 
the traditional mainframe workloads. If not possible I would load the LPAR 
with zAAP's as necessary to defray the impact.

We recently also had a problem while running a batch job against a zFS 
which supports our Tech's Website and PDF files. The WAS in which the 
PDF's were connected to suddenly went haywire using significant CPU, 
operations then cancelled and eventually had to force the WAS, then zFS 
abended - all in all an ugly incident. While there is an open APAR that 
matches to some degree IBM asked us to try to recreate it as the WAS dump 
was not helpful. Please see OA15422 with APAR description: "LOOP IN USER 
CACHE, LOOKS LIKE A HANG IN ZFS"

And as Barbara said not to disparage Steve but we have had our share of 
problems with running the new workloads with the traditional ones. Of 
course you can also see my rants in the archives about my WAS experiences 
if this wasn't enough. I do like the new workloads as they keep me 
employed at this point but they just don't seem to play well with the 
traditional ones.





Barbara Nitz <[EMAIL PROTECTED]> 
Sent by: IBM Mainframe Discussion List 
03/28/2006 12:53 AM
Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@BAMA.UA.EDU
cc

Subject
Re: Bringing the fun back to z/OS - new course






Steve's post prompts me to relate our MVS Unix/Linux experience - this is 
in
no way meant to disparage Steve's efforts for courses...

>Now, the ability to run UNIX on the mainframe melds a lot of strengths:
>flexibility (run classic mainframe apps and UNIX apps on the same box), 

You'd better not. We are running a clustered Lotus Domino Server on our
boxes and have to run several unix apps (ADSM - whatever that's called 
these
days, WBIFN - gateway to the SWIFT net and Websphere Application Server). 
We
found out very fast that these beasties tend to take over more than their
share of processing power, so all of these UNIX apps quickly got their own
lpar where traditional workload did not have to compete with these cpu 
hogs.

>scalability, reduced footprint, 

reduced footprint?!?
Even confined to their own lpars, the Dominoes take everything in terms of
assigned processors and lpar weight, to the detriment of other lpars. And 
if
these Unix dominated lpars don't get what they want, they stop working
altogether. 

We are in the process of moving the UNIX apps to Linux under VM, where 
they
can use the other type of processors and save us a lot of software costs
(BMC is killing us, followed by CA.) Did I mention that we now run almost 
as
many Linuxes as we run MVS lpars? Reduced foortprint?!?

>Utilize the legendary strengths of the mainframe

One of which was first failure data capture (and it worked, too, given the
right knowledge in looking at a dump). All of these UNIX apps have never
even heard the term first failure data capture, much less are familiar 
with
the concept. With the exception of maybe one (stupid) user error on our
part, IBM has proved incapable time and again to look at dumps (even those
written by the product itself) and find a problem. Unless you can 
reproduce
the problem, provided you have an inkling how, you get a lot of crap which
always involves restarting a high availability application.

And without a complaint on top a sev1/prio1 IBM doesn't even look at the
problem, much less solve it. Even with a complaint, all we get is what we
call in German 'holding hands' - meaning they commiserate with us but only
attempt to calm us thus infuriating us more.

I'd better stop here

Regards, Barbara Nitz 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Bringing the fun back to z/OS - new course

[Steve Comstock]

[EMAIL PROTECTED] wrote:
I would agree with Barbara on this. We run a mix of traditional work along 
with a Domino Change Management System with about 400 registered Users and 
WAS V4 in lightweight mode with about the same amount. Both applications 
can kill performance to our traditional workloads on our small 2 way. The 
WAS always sits at the top of the CPU usage monitor, again this is 
lightweight mode not full blown WAS, with the IDMS right behind it. The 
Domino application server task, at times, can dominate CPU as well. 

Since we  have been in a holding pattern while the bean counters basically 
decide our eventual fate I have been trying to hold the line as the 
production WAS environment adds Users who then navigate up through our 
traditional environment into our CA/IDMS. It has been a very delicate 
balancing act to see that the Production Users get service while I *try* 
to get cycles to the developers on this LPAR, no we don't have a test 
LPAR. If I had my druthers I would attempt to run the Unix workloads on 
their own LPAR where possible to eliminate the performance anomalies to 
the traditional mainframe workloads. If not possible I would load the LPAR 
with zAAP's as necessary to defray the impact.


We recently also had a problem while running a batch job against a zFS 
which supports our Tech's Website and PDF files. The WAS in which the 
PDF's were connected to suddenly went haywire using significant CPU, 
operations then cancelled and eventually had to force the WAS, then zFS 
abended - all in all an ugly incident. While there is an open APAR that 
matches to some degree IBM asked us to try to recreate it as the WAS dump 
was not helpful. Please see OA15422 with APAR description: "LOOP IN USER 
CACHE, LOOKS LIKE A HANG IN ZFS"


And as Barbara said not to disparage Steve but we have had our share of 
problems with running the new workloads with the traditional ones. Of 
course you can also see my rants in the archives about my WAS experiences 
if this wasn't enough. I do like the new workloads as they keep me 
employed at this point but they just don't seem to play well with the 
traditional ones.




Patrick,

Help me learn more, here. I'm talking about hosting
a website on z/OS without WAS. It would seem that
would be even lighter weight, although I honestly
have no idea how it scales to commercial levels of
activity.

Anyone else have some experience doing this who would
share your observations?

I'm thinking: get 'em in cheap (and light) using HTTP
server; then, when needed, bring in WAS (and more hardware,
it sounds like).

Kind regards,

-Steve Comstock

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Bringing the fun back to z/OS - new course

[Patrick . Falcone]

I'm sorry. Our WAS environment is running WAS V4 (in 3.5 compatibility 
mode or lightweight mode) which is single server or single task. This 
environment uses much less resources than a full blown WAS heavyweight 
environment where a cell group in support of an application(s) can consist 
of 7 tasks or more. I was basically making the observation that I have had 
some performance challenges tuning this mixed environment on a small 2-way 
CMOS box. When we tried to move to WAS V5 heavyweight in 31 bit it became 
next to impossible to support overall performance when starting some of 
the tasks within the cell group for a particular application not to 
mention the resource consumption, storage and CPU, that was required once 
the application (one of many slated at that time) was initialized. Of 
course, 64 bit and  hardware w/zAAP(s) ($) would provide additional 
balance to limit these anomalies to the traditional workloads.

I would certainly think you would limit the potential of performance 
anomalies with just HTTP on z/OS with traditional workloads. Of course the 
size  hardware and operating system make all the difference in the world, 
a luxury I do not have at this time.




Steve Comstock <[EMAIL PROTECTED]> 
Sent by: IBM Mainframe Discussion List 
03/28/2006 11:23 AM
Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@BAMA.UA.EDU
cc

Subject
Re: Bringing the fun back to z/OS - new course




Patrick,

Help me learn more, here. I'm talking about hosting
a website on z/OS without WAS. It would seem that
would be even lighter weight, although I honestly
have no idea how it scales to commercial levels of
activity.

Anyone else have some experience doing this who would
share your observations?

I'm thinking: get 'em in cheap (and light) using HTTP
server; then, when needed, bring in WAS (and more hardware,
it sounds like).

Kind regards,

-Steve Comstock

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Bringing the fun back to z/OS - new course

[Barbara Nitz]

>i haven't dealt with them for two years but i still can't 
>even stand the thought of a domino pizza

While the level2 guy in Boston is real nice, he isn't doing the dump
reading, and we had more than one occasion where he was begging the dump
readers to help him. (And he is doing the customer contact for both z/OS and
Linux, so he gets all the heat.)

We had/have 4 sev1's open at the same time, plus the complaint specifically
about IBM not doing analysis properly. It was evident very fast that their
developers only deal with tracebacks/save area stacks (and have no idea how
to extract them if they're not given by a core dump from their task) and on
top of that can only 'analyze' a problem if provided a logging trace
(similar to a component trace) that of course can only be turned on via a
restart of the product. (And this is true for basically all unix based
products).

As the sev1's were mainly Linux, we have reached the point where we
routinely take Linux standalone dumps for every problem including the swap
files, just so IBM cannot tell us that the 'right data are not in the dump'.
(They can't read these standalone dumps, either, but that's their problem -
we've removed their excuse.)

I have been warned by IBM not to take them to task anymore for not doing
their analysis job. I have also been told that IBMs reaction then would be
'Alright, then we don't analyze your problems anymore'. (As Shane always
says: IBM must hate me.)

>Help me learn more, here. I'm talking about hosting a website on z/OS
>without WAS. It would seem that would be even lighter weight, although I
>honestly have no idea how it scales to commercial levels of activity.

>I'm thinking: get 'em in cheap (and light) using HTTP server; then, when
>needed, bring in WAS (and more hardware, it sounds like).

Steve, as long as you're aware that you're completely on your own if you
venture there in terms of problems, you can of course install a 'light'
website. But I seem to remember that WAS recommends against using HTTP
servers (my WAS V4 memory). I stopped attempting to get IBM to fix their WAS
problems a looong time ago (too frustrating), but we regularly have dumps
because of timeouts (and that on a production lpar) that is not the most
favoured by lpar controls.

In our experience, all you're being told is to install the latest ptf (never
mind that it's gone PE with a big problem) and then reproduce the problem.
And IBM was quite useless if we had setup questions particular to our
environment (including some problems due to some missing file system
permissions). It will be a trial and error effort on your part.

Regards, Barbara

ps. Am I glad that I am not the only one having had these frustrations!

-- 
Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer!
Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Bringing the fun back to z/OS - new course

[Timothy Sipples]

A couple thoughts here, since I think Steve was talking about letting IBM 
know of these issues. First a point Barbara made:

>We are in the process of moving the UNIX apps to Linux under VM, where 
they
>can use the other type of processors and save us a lot of software costs
>(BMC is killing us, followed by CA.)

IBM made a strategic decision several years ago to enter into direct, 
professional competition with BMC and CA.  I would advise any customer to 
weigh their options now that there is heightened, healthy competition. 
That's not particularly vendor specific, actually.  If you're an IBM 
tools/utilities customer then I would advise you to periodically compare 
with other vendors.  In other words, it works both ways.

One thing we've discovered is that terms and conditions often matter most, 
including license restrictions, capacity upgrade charges (tier levels, 
"MIPS on the floor" rules), etc.  We've tried very hard to introduce more 
rationality into mainframe software pricing and terms.  (Which is 
interesting, because the other platforms seem to be getting less rational 
with each passing day. :-))

With respect to Patrick's comments, WebSphere Application Server/Java is 
certainly not IDMS/ADO (for example) from a resource utilization point of 
view.  A "modest" two-way CP-only 31-bit-only system is simply not going 
to be delivering very high WebSphere volumes, I'm afraid.  Unless your 
WebSphere Application Server workload is trivial, please do one of two 
things: (1) get a zAAP (for WAS z/OS); (2) get an IFL (for WAS Linux). 
It's frankly bad *finance* to run (much) WAS without either of these two 
options.  Spend money to save a lot more money.

With either one of these two approaches mainframe WAS becomes not just 
affordable but, in numerous situations, the *most* cost-effective J2EE 
platform. My personal favorite is zAAP, but please choose at least one of 
these two avenues.

Yes, WAS loves storage.  But we're now in the era when even z800s come 
with minimum 8 GB, so the times they are a-changin'.  (IBM saw these "new 
workloads" coming years ago and declared that everybody would have some 
generous storage even in the base configuration. I think it was one of the 
smarter things we've done.)  "Wasteful"?  Maybe.  But IBM just cut the 
memory price (again, with the System z9), and we're now in the era when 
programmers aren't counting bytes (or even kilobytes) like they used to.

Steve asks in reply about the IBM HTTP Server for z/OS -- is that 
"lighter"?  Answer: absolutely.  It's mostly I/O work, and allegedly 
mainframes handle that. :-)  I'm generally not concerned about workload 
impact of HTTP serving, even on modest systems.  If you're looking to get 
your "feet wet" with HTTP serving, a good match is WebSphere Host 
On-Demand hosted on z/OS.  It's very quick and easy to set up, it's very 
light workload, it's frankly the best place to host Host On-Demand, and I 
guess you could say it's step zero on the road to WAS.  There are other 
candidates for z/OS HTTP serving, but that's one of my favorites.

Do note that the first Web server in the world outside Switzerland was 
installed on a Stanford mainframe -- a long time before any still extant 
operating system got a Web server.  So HTTP serving on mainframes isn't 
exactly new, and you'll have lots of company if (when, I hope) you decide 
to join the club.

Lastly, I think there's an implication that workloads in USS cannot fit 
into WLM service classing, goals, etc. in order to manage together with 
batch and other classic workloads.  I hope nobody is saying that, because 
it's certainly not true.  z/OS and WLM will manage all work, including 
USS-based work, as you tell it.  If your system is too small to meet or 
exceed all goals at peak, that'll still be true regardless of the *type* 
of work you throw onto the system.  WebSphere z/OS is spectacularly 
plugged into WLM -- it works really, really well, at least for the past 
three versions that I'm more familiar with (5.0+).  But if I'm trying to 
suck an elephant through a straw and want the elephant to more or less 
retain its shape, well... :-)

Kudos on this effort, Steve. It sounds really interesting.

- - - - -
Timothy F. Sipples
Consulting Enterprise Software Architect, z9/zSeries
IBM Japan, Ltd.
E-Mail: [EMAIL PROTECTED]

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Bringing the fun back to z/OS - new course

[Anne & Lynn Wheeler]

there is also the folklore of the contractor hired to do the original
tcp/ip implementation in vtam. the initial try had tcp benchmark
w/thruput much higher than lu6.2. it was explained to him that
everybody KNEW that a CORRECT tcp/ip implementation would have thruput
much lower than lu6.2 ... and they were only willing to accept a
CORRECT protocol implementation. the contract was handled by a group
that was sometimes called cpd-west located in palo alto sq (corner of
el camino and page mill).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Bringing the fun back to z/OS - new course

[Patrick . Falcone]

<>




Timothy Sipples <[EMAIL PROTECTED]> 
Sent by: IBM Mainframe Discussion List 
03/29/2006 07:21 AM
Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@BAMA.UA.EDU
cc

Subject
Re: Bringing the fun back to z/OS - new course




With respect to Patrick's comments, WebSphere Application Server/Java is 
certainly not IDMS/ADO (for example) from a resource utilization point of 
view.  A "modest" two-way CP-only 31-bit-only system is simply not going 
to be delivering very high WebSphere volumes, I'm afraid.  Unless your 
WebSphere Application Server workload is trivial, please do one of two 
things: (1) get a zAAP (for WAS z/OS); (2) get an IFL (for WAS Linux). 
It's frankly bad *finance* to run (much) WAS without either of these two 
options.  Spend money to save a lot more money.

<>

With either one of these two approaches mainframe WAS becomes not just 
affordable but, in numerous situations, the *most* cost-effective J2EE 
platform. My personal favorite is zAAP, but please choose at least one of 
these two avenues.

<>

Lastly, I think there's an implication that workloads in USS cannot fit 
into WLM service classing, goals, etc. in order to manage together with 
batch and other classic workloads.  I hope nobody is saying that, because 
it's certainly not true.  z/OS and WLM will manage all work, including 
USS-based work, as you tell it.  If your system is too small to meet or 
exceed all goals at peak, that'll still be true regardless of the *type* 
of work you throw onto the system.  WebSphere z/OS is spectacularly 
plugged into WLM -- it works really, really well, at least for the past 
three versions that I'm more familiar with (5.0+).  But if I'm trying to 
suck an elephant through a straw and want the elephant to more or less 
retain its shape, well... :-)

<>

- - - - -
Timothy F. Sipples
Consulting Enterprise Software Architect, z9/zSeries
IBM Japan, Ltd.
E-Mail: [EMAIL PROTECTED]

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Alternative to mvsqr, was: Bringing the fun back to z/OS - new course

[Arthur Fichtl]

Hi colleagues,

We are in the process of moving the UNIX apps to Linux under VM, where
>they can use the other type of processors and save us a lot of software
>costs (BMC is killing us, followed by CA.)


I was asked to find out whether there exist z/OS based products from IBM
or 3rd parties that provide similar content & functionality.

Any idea?

TIA,
Arthur

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Alternative to mvsqr, was: Bringing the fun back to z/OS - new course

[Rich Smrcina]

Arthur,

Similar functionality to which products?

Arthur Fichtl wrote:

Hi colleagues,


We are in the process of moving the UNIX apps to Linux under VM, where
they can use the other type of processors and save us a lot of software
costs (BMC is killing us, followed by CA.)



I was asked to find out whether there exist z/OS based products from IBM
or 3rd parties that provide similar content & functionality.

Any idea?

TIA,
Arthur

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



--
Rich Smrcina
VM Assist, Inc.
Main: (262)392-2026
Cell: (414)491-6001
Ans Service:  (360)715-2467
rich.smrcina at vmassist.com

Catch the WAVV!  http://www.wavv.org
WAVV 2006 - Chattanooga, TN - April 7-11, 2006

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Alternative to mvsqr, was: Bringing the fun back to z/OS - new course

[R.S.]

Arthur Fichtl wrote:


Hi colleagues,


We are in the process of moving the UNIX apps to Linux under VM, where
they can use the other type of processors and save us a lot of software
costs (BMC is killing us, followed by CA.)




I was asked to find out whether there exist z/OS based products from IBM
or 3rd parties that provide similar content & functionality.

Any idea?


Yes, reasonable priced. Tell us what products do you want to replace.
BTW: From my experience it is often enough to find an alternative 
product and tell about it to your current supplier. The prices can 
shrink dramatically.


--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Alternative to mvsqr, was: Bringing the fun back to z/OS - new course

[Timothy Sipples]

>>I was asked to find out whether there exist z/OS based products from IBM
>>or 3rd parties that provide similar content & functionality.
>Yes, reasonable priced. Tell us what products do you want to replace.
>BTW: From my experience it is often enough to find an alternative 
>product and tell about it to your current supplier. The prices can 
>shrink dramatically.

I respectfully disagree that telling a current supplier is often enough. 
It might be on one occasion (might), but it's not a strategy likely to 
work the next time around. And some suppliers are very good at making you 
think you've got a "dramatically" lower price -- because their original 
quoted price is dramatically ridiculous. Also, the terms and conditions, 
most particularly the price attached to growth, are critical. There's a 
growing trend -- just look at the airline industry -- to obfuscate price 
through bewildering terms and conditions.

Receiving a fair price on any product requires a *credible* market 
alternative in *your* particular situation. Things that bring credibility 
to the discussion:

- a project actually underway to switch from one vendor to another
- past, recent defection to another vendor
- respect for functional innovation (i.e. that you care about value, not 
just price)
- knowledge about the product, the vendor's business, your business 
requirements, etc.
- seriousness (e.g. a long term commitment, growth)
- timeliness

Timeliness means you should be having this discussion about 12 to 16 
months before your contract renewal.

Here's where you can start within the halls of IBM:
http://www.ibm.com/software/solutions/softwaremigration/sps.html

But the above advice applies regardless of vendor.

- - - - -
Timothy F. Sipples
Consulting Enterprise Software Architect, z9/zSeries
IBM Japan, Ltd.
E-Mail: [EMAIL PROTECTED]

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Alternative to mvsqr, was: Bringing the fun back to z/OS - new course

[Ed Gould]

On Apr 2, 2006, at 9:50 PM, Timothy Sipples wrote:

I was asked to find out whether there exist z/OS based products  
from IBM

or 3rd parties that provide similar content & functionality.

Yes, reasonable priced. Tell us what products do you want to replace.
BTW: From my experience it is often enough to find an alternative
product and tell about it to your current supplier. The prices can
shrink dramatically.


I respectfully disagree that telling a current supplier is often  
enough.

It might be on one occasion (might), but it's not a strategy likely to
work the next time around. And some suppliers are very good at  
making you
think you've got a "dramatically" lower price -- because their  
original
quoted price is dramatically ridiculous. Also, the terms and  
conditions,
most particularly the price attached to growth, are critical.  
There's a
growing trend -- just look at the airline industry -- to obfuscate  
price

through bewildering terms and conditions.

Receiving a fair price on any product requires a *credible* market
alternative in *your* particular situation. Things that bring  
credibility

to the discussion:


Timothy:

This was(is?) true of a current big name vendor .. at least a few  
time the company was offered a product at extremely bargain basement  
prices. Ahh.. where is the catch.. if you do any upgrades of Hardware  
you get socked MAJOR $$ (another nail in the coffin for MF's).


This has been discussed on here before about the bait and switch  
tactics of sales types.




- a project actually underway to switch from one vendor to another
- past, recent defection to another vendor
- respect for functional innovation (i.e. that you care about  
value, not

just price)
- knowledge about the product, the vendor's business, your business
requirements, etc.
- seriousness (e.g. a long term commitment, growth)
- timeliness

Timeliness means you should be having this discussion about 12 to 16
months before your contract renewal.

Here's where you can start within the halls of IBM:
http://www.ibm.com/software/solutions/softwaremigration/sps.html

But the above advice applies regardless of vendor.

- - - - -
Timothy F. Sipples
Consulting Enterprise Software Architect, z9/zSeries
IBM Japan, Ltd.
E-Mail: [EMAIL PROTECTED]

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Alternative to mvsqr, was: Bringing the fun back to z/OS - new course

[Shmuel Metz (Seymour J.)]

In
<[EMAIL PROTECTED]>,
on 04/02/2006
   at 08:50 PM, Timothy Sipples <[EMAIL PROTECTED]> said:

>Receiving a fair price on any product requires a *credible* market 
>alternative in *your* particular situation. Things that bring
>credibility  to the discussion:

>- a project actually underway to switch from one vendor to
>another

I would consider it a strategic error to stick with a vendor that has
forced you to that extreme. If the project is already underway then,
IMHO, you are better of proceeding to switch.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Alternative to mvsqr, was: Bringing the fun back to z/OS - new course

[Timothy Sipples]

>>Receiving a fair price on any product requires a *credible* market 
>>alternative in *your* particular situation. Things that bring
>>credibility  to the discussion:
>>- a project actually underway to switch from one vendor to
>>another
>I would consider it a strategic error to stick with a vendor that has
>forced you to that extreme. If the project is already underway then,
>IMHO, you are better of proceeding to switch.

That's the likely outcome, yes. But I didn't phrase that bullet in 
sufficient detail.

Let's suppose there are three vendors: Vendor A, Vendor B, and Vendor C. 
Your company has products from Vendors A and B installed but, currently, 
no products from Vendor C. Your company is 12+ months from contract 
expiration with Vendor A. If you have a project underway to switch one 
product from Vendor B to Vendor C, that might put the "fear of God" into 
Vendor A and thus demonstrate that you are perfectly capable of switching, 
especially if Vendor C is the likely beneficiary.

Otherwise a vendor may not view a switching threat as credible.

- - - - -
Timothy F. Sipples
Consulting Enterprise Software Architect, z9/zSeries
IBM Japan, Ltd.
E-Mail: [EMAIL PROTECTED]

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html