Re: JAVA In Batch

[Timothy Sipples]

John McKown writes:
>As an offshoot from this, if it were my choice, then I'd likely keep my
>Java development stuff on a UNIX file server. This UNIX file server
>would NFS export the appropriate subdirectories. The z/OS system would
>NFS import them. All Java development would occur on PC desktops running
>Linux or Windows , which can access those NFS exported
>directories. I'd use either Netbeans or Eclipse on the desktop for Java
>development (I use Netbeans, myself). This would allow the programmers
>easy access to edit, compile, and test Java. Promotion would be from the
>NFS mounted subdirectories onto "production" UNIX files residing on the
>z/OS system. Again, this would be my first take on how to do it.
>Unfortunately, the interest in Java on z/OS here is approaching zero
>from beneath.

I'm afraid I would disagree with John here, which is rare.

The "official" way, if you want an Eclipse-based Java programming
environment, is WebSphere Developer for System z.  That's quite an elegant
way to do it, and you certainly don't need a separate UNIX box.  I should
also point out that it is possible you might have one or more WDz licenses
and don't know it yet.  At least some license rights to WDz come with CICS
3.1 or WebSphere Host Integration Solution (HATS), so check your
announcement letters for those products if you have them.  You might be
pleasantly surprised.

But failing all that, I don't see why you couldn't operate in UNIX System
Services unless and until you wanted to invoke Java programs with JCL.  It
has UNIX shell, UNIX file structures (zFS or the older HFS), access to the
JDK, etc. and you can get a terminal connection to it, transfer files, etc.
It is the UNIX(TM) box, and you already have it, so why not use it if you
think you need one?

Both of the above methods are much more likely to preserve regulatory
compliance around code development and promotion to production.

It's worth noting that there are a couple limitations to OS/390 for Java,
if you're looking for yet more reasons to move to z/OS.  One is that newer
Java releases are not likely to run on OS/390, so if a Java programmer is
looking for the newer APIs then that might be an impediment.  Another is
that none of the 64-bit Java releases will run on OS/390, and I see how
64-bit addressing could be useful in certain Java batch programming for
getting a very large chunk of memory that never garbage collects during the
entire batch run.  (Garbage collection requires CPU.)  Yet another is that
OS/390 doesn't support zAAP engines, and the zAAP technology has a radical,
beneficial impact on the economics of running Java on your mainframe.  If
you have any non-trivial Java workload then run, don't walk, and get one or
more zAAPs.

Sounds like an interesting effort, so I hope it goes well.

- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Specializing in Software Architectures Related to System z
Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
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: JAVA In Batch

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Robert Pelletier
> Sent: Thursday, March 08, 2007 7:45 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: JAVA In Batch
> 
> 
> Hi All. Once again I turn to the group for help. We are OS390 
> V2R10. Can
> we compile and run JAVA in a batch program? Would anyone have a sample
> of how to do this or point me to a manual? Thanks in advance. 
> 
> 
> Have a Nice Day !
>  
> Bob Pelletier

I don't know about OS/390 2.10, but the JZOS originally from Dovetail
and now acquired by IBM (JZOS, not Dovetail) runs Java in batch
wonderfully!

Java "stuff" exists only in UNIX files. You cannot store the source or
the .class/.jar files in a PDS. Well, you can store the source in a PDS.
But you cannot compile from the PDS, you'll need to copy it to an UNIX
file. And Java naming conventions are not very easy to squeeze into an 8
character, upper case only, PDS member name. I wouldn't even try.

As an offshoot from this, if it were my choice, then I'd likely keep my
Java development stuff on a UNIX file server. This UNIX file server
would NFS export the appropriate subdirectories. The z/OS system would
NFS import them. All Java development would occur on PC desktops running
Linux or Windows , which can access those NFS exported
directories. I'd use either Netbeans or Eclipse on the desktop for Java
development (I use Netbeans, myself). This would allow the programmers
easy access to edit, compile, and test Java. Promotion would be from the
NFS mounted subdirectories onto "production" UNIX files residing on the
z/OS system. Again, this would be my first take on how to do it.
Unfortunately, the interest in Java on z/OS here is approaching zero
from beneath.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it. 

--
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: JAVA In Batch

[Veilleux, Jon L]

Gil is correct. You may have to use DD's like this:

//STDOUT  DD  PATH='/tmp/test1.out',PATHOPTS=(OWRONLY,OCREAT)   
//STDERR  DD  PATH='/tmp/test2.out',PATHOPTS=(OWRONLY,OCREAT)



Jon L. Veilleux
[EMAIL PROTECTED]
(860) 636-2683 


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Paul Gilmartin
Sent: Thursday, March 08, 2007 8:55 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: JAVA In Batch

In a recent note, Veilleux, Jon L said:

> Date: Thu, 8 Mar 2007 08:50:32 -0500
> 
> //JESSTEP EXEC PGM=BPXBATCH,REGION=8M, // PARM='SH javac 
> full_path_to_java_source_file '
> //STDOUT  DD  SYSOUT=*
> //STDERR  DD  SYSOUT=*
> 
But be aware that only the most recent release(s) of z/OS will honor
those STDOUT and STDERR DD statements.

-- gil
--
StorageTek
INFORMATION made POWERFUL

--
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

-
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna

--
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: JAVA In Batch

[Paul Gilmartin]

In a recent note, Veilleux, Jon L said:

> Date: Thu, 8 Mar 2007 08:50:32 -0500
> 
> //JESSTEP EXEC PGM=BPXBATCH,REGION=8M,
> // PARM='SH javac full_path_to_java_source_file '
> //STDOUT  DD  SYSOUT=*
> //STDERR  DD  SYSOUT=*
> 
But be aware that only the most recent release(s) of z/OS
will honor those STDOUT and STDERR DD statements.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
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: JAVA In Batch

[Robert Pelletier]

Once again thanks Jon and all. I have no knowledge of JAVA and
Programming is inquiring about it. Does the source go into a PDS? 


Have a Nice Day !
 
Bob Pelletier
Connecticut Student Loan Foundation
Rocky Hill, Ct.

-Original Message-
From: Veilleux, Jon L [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 08, 2007 8:51 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: JAVA In Batch

You could use BPXBATCH JCL.

//JESSTEP EXEC PGM=BPXBATCH,REGION=8M,   
// PARM='SH javac full_path_to_java_source_file ' 
//STDOUT  DD  SYSOUT=*   
//STDERR  DD  SYSOUT=*   

//JESSTEP EXEC PGM=BPXBATCH,REGION=8M,   
// PARM='SH java  full_path_to_java_class_file ' 
//STDOUT  DD  SYSOUT=*   
//STDERR  DD  SYSOUT=*  

 
Jon L. Veilleux
[EMAIL PROTECTED]
(860) 636-2683 


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Robert Pelletier
Sent: Thursday, March 08, 2007 8:45 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: JAVA In Batch

Hi All. Once again I turn to the group for help. We are OS390 V2R10. Can
we compile and run JAVA in a batch program? Would anyone have a sample
of how to do this or point me to a manual? Thanks in advance. 


Have a Nice Day !
 
Bob Pelletier
Connecticut Student Loan Foundation
Rocky Hill, Ct.

--
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

-
This e-mail may contain confidential or privileged information. If you
think you have received this e-mail in error, please advise the sender
by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna

--
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: JAVA In Batch

[Veilleux, Jon L]

You could use BPXBATCH JCL.

//JESSTEP EXEC PGM=BPXBATCH,REGION=8M,   
// PARM='SH javac full_path_to_java_source_file ' 
//STDOUT  DD  SYSOUT=*   
//STDERR  DD  SYSOUT=*   

//JESSTEP EXEC PGM=BPXBATCH,REGION=8M,   
// PARM='SH java  full_path_to_java_class_file ' 
//STDOUT  DD  SYSOUT=*   
//STDERR  DD  SYSOUT=*  

 
Jon L. Veilleux
[EMAIL PROTECTED]
(860) 636-2683 


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Robert Pelletier
Sent: Thursday, March 08, 2007 8:45 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: JAVA In Batch

Hi All. Once again I turn to the group for help. We are OS390 V2R10. Can
we compile and run JAVA in a batch program? Would anyone have a sample
of how to do this or point me to a manual? Thanks in advance. 


Have a Nice Day !
 
Bob Pelletier
Connecticut Student Loan Foundation
Rocky Hill, Ct.

--
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

-
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna

--
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

JAVA In Batch

[Robert Pelletier]

Hi All. Once again I turn to the group for help. We are OS390 V2R10. Can
we compile and run JAVA in a batch program? Would anyone have a sample
of how to do this or point me to a manual? Thanks in advance. 


Have a Nice Day !
 
Bob Pelletier
Connecticut Student Loan Foundation
Rocky Hill, Ct.

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Chris Mason]

If Pat's reply is "jumping onto a cold thread", being only three days late,
how does this one rate?

I've been cleaning out my reader - sorry "inbox" - and I guess I kept this
one because of the insight Pat offered on the comparison - and
effectiveness - of TCP and SNA timers.

Reading through, I've a couple of extra comments:

I had a look at checking back to the original thread but it's rather large
and there's a strong possibility the characteristics of Ted's famous
application when being transported over IP will not be revealed.

Ted said his application worked reliably under SNA but unreliably under
TCP/IP. This may just be an illustration of why "TCP/IP" is a bad way to
describe the suite of functions/protocols which make up the "TCP/IP suite" -
and it looks like I've manoeuvred myself into being a "word policeman"
again - how tragic!

It may be that it has simply been assumed that Ted's application uses the
TCP protocol and hence should benefit from TCP reliability when it may be
that the UDP protocol is used and the writer of the application - converted
from SNA - hasn't written sufficient reliability into it.

It may have been assumed that the application uses TCP because Ted said in
all innocence that the application uses "TCP/IP". However he probably
intended to refer to, using the today's product names, the Communications
Server IP component rather than the Communications Server SNA component.
Thus he isn't necessarily claiming the application is using the TCP
protocol.

It was Pat's "but the app may not be willing or able to wait" that triggered
the idea that UDP may be being used.

-

I thought Pat, confused by jumping between TCP and SNA, had incorrectly used
the word "route" rather than "link" when he said that, in SNA, "data gets
through or the route is declared dead". In SNA data gets through or the
*link* is declared dead but, in addition, any route using the link - being
connection-oriented they know who they are - will also be declared dead[1] -
so Pat wasn't necessarily confused - and I hope that applies also to anyone
reading this. 

[1] Unless we are dealing with APPN/HPR, of course, where an alternative
path can be found, if one exists, and the logical connection (link) over a
number of nodes and real links remains active.

-

One answer to the question "What would an SNA name server do?" is the ANAME
application from the "APPC Application Suite" the manuals which greet us
first whenever we select the Communications Server bookshelf - and we skip
right over them.

Chris Mason

- Original Message ----- 
From: "Patrick O'Keefe" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: 
Sent: Thursday, 15 June, 2006 8:47 PM
Subject: Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)


> On Mon, 12 Jun 2006 00:00:00 GMT, Ted MacNEIL
> <[EMAIL PROTECTED]> wrote:
>
> >>TCP keeps track of it all, requesting a resend of dropped/lost/missing
> packets.
> >
> >NOT in this case!
> >The packets are dropped!
> >They are not re-sent and the app is blown off the air.
> >It works under SNA; it bellies up under TCP/IP.
> >Every time! Repeatable!
> >...
>
> I'm way behind on on IBM-Main so am probably jumping onto a cold thread,
> but want to add my belated 2 cents worth.  Ted is probably right about
> the behavior of the application and is spot-on with "Repeatable!", but
> is a bit off on his criticizm of TCP/IP.
>
> Yes, IP drops packets. But also, yes, TCP keeps track of it all and
> requests retransmissions.  The reason this works much better in SNA
> (IM not so HO) is that the error detection and correction in SNA
> happens at a much lower level than in TCP/IP - at what would be the
> IP level - at the level where timers can match "line" characteristics -
> very short timers.  There is guaranteed delivery at a very low level;
> data gets through or the route is declared dead.
>
> On the other hand, IP does not guarantee delivery.  It is left up to the
> higher (TCP) level to detect need for retransmission.  And since any 2
> packets can flow across different routes with very different speeds, it
> has to have very long timers or risk requesting unneeded retransmissions.
> If the retransmission timers are longer than timers in the application
> (something completely unneeded in an SNA app), the app may choke even
> though data is on the way. In other words, TCP guarrentees delivery of
> data, but the app may not be willing or able to wait.
>
> One aspect of this is that behavior of an SNA network is MUCH more
> predictable than a TCP/IP behavior.  Network management is self-
> contradictory in TCP/I

Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Patrick O'Keefe]

On Fri, 16 Jun 2006 00:00:00 GMT, Ted MacNEIL <[EMAIL PROTECTED]> 
wrote:

>...
>We have no guaranteed delivery! Period!
>And, the only change was SNA to TCP/IP.
>...

But that doesn't mean TCP/IP is at fault.  By the description elsewhere in
this thread, this could be an interaction between Delayed Acks and the  
Nagle algorithm - a configuration/tuning issue.  And in any case, the data
does eventually get delivered ... but probably not soon enough for your
application and/or Tn3270 client and server to cope with.
  
>>>If TCP/IP is so robust, why has it NEVER happened in 7 years under SNA 
(how long we've had the TN3270 client we use), and it always happens under 
TCP/IP.
>

TCP/IP and SNA had very different design criteria with very different 
definitions of "robust".  To TCP, "robust" means the packet will eventually
get from source to destination even if the packet has to be routed via
Mars and is routed from hop to hop for a week.

To SNA "robust" means that a frame is rapidly set from hop to hop along a 
predefined path, and if that cannot be guaranteed the session will be 
broken so it can be re-established across another predefined route.  
(APPN with HPR does a pretty good job of taking the best characteristics
of both SNA and TCP/IP.)

>From a perfomance standpoint, both will fail miserably if incorrectly 
defined, but the SNA failure is likely to hard and permanent until 
corrected.  When it is working it works consistantly within quite 
tight limits.  A TCP/IP network doesn't permanently fail, but may have
terrible performance characteristics.

Application written expecting SNA performance characteristics may very
well not work well in a TCP/IP environment.  This is NOT the fault of
TCP/IP. 

>
>>That sounds like a problem with the Tn3270 client, or some kind of 
incompatability between the Tn3270 client and server, or some such.
>
>I can reproduce the problem manually (with 5 minutes of effort).
>It has to do with the lack of think time.
>Just pound a PFKey until the host barfs.
>It happens with:
>RUMBA
>ATTACHMATE
>Hummingbird,
>and at least three different web-clients:
>2 in JAVA
>and on in ACTIVEx.
>

That doesn't eliminate the possibility of Delay Ack being specified at the 
server.

>...
>The packet drops (not always the same one), but with no think time the 
desktop is sending the data too fast.
>...
>The packets are one PFKey.
>

That definitely sonds like the Nagle / Delay Ack issue.  It's more likely
to happen with short packets.  But I suspect there are other possible 
configuration causes.  Or a bug in the server or TCP/IP stack. 

>
>>I happen to be an SNA bigot and have no love for TCP/IP, but don't like 
seeing bogus arguments against TCP/IP.
>
>It's not bogus. I explained the issue to a z/OS TCP/IP consultant, at CMG 
Canada in April.
>Even with my poor grasp of terminology, she knew what the issue was.
>Something about NAGLE (spelling?) and host settle-time.
>

And that is not a poor design in TCP/IP; it's a configuration issue.
You can cause probles for SNA with incorrect configurations - they just 
tend to create harder errors and get fixed sooner.

>
>>Crying "wolf" helps nobody.
>
>I am not crying wolf.
>Also, I was not asking for help here.
>I was just pointing out that TCP/IP sucks, is a weak protocol and is 
going to take over the market.
>

I contend that blaiming TCP/IP rather than the configuration is 
crying wolf.  (And my griping about running SNA-designed applications in
a TCP/IP environment is crying over spilled milk.  We're both guilty.)

And I contend that TCP/IP does not suck; that is is actually a pretty 
robust protocol.  But it is radically different than SNA, designed for 
a very different communication environment (dirty, slow lines), and 
designed for a completely different goal (delivery of military and 
governmental communications after nuclear war has disrupted the 
communication grid vs delivery of commercial data across a well 
maintained private communication network).

Pat O'Keefe  

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[R.S.]

Ted MacNEIL wrote:


I obviously can't comment on traces I haven't seen.  I can say that TCP 
provides guaranteed delivery ... if you (and your software) are willing to cope 
with some very ugly timings.



We have no guaranteed delivery! Period!
And, the only change was SNA to TCP/IP.



If TCP/IP is so robust, why has it NEVER happened in 7 years under SNA (how 
long we've had the TN3270 client we use), and it always happens under TCP/IP.




I don't understand that statement.  If you've been using Tn3270 for 7 years you've 
been using TCP/IP.  >By definition, Tn3270 is 3270 over TCP/IP.



Not being a network person, I may be tripping over terminology.
It's been the same desktop client for 7 years.



First, in my VERY unhumble opinion, anybody using screen scraping gets what he or she deserves.  (BOOM!)  That was as true under pure SNA as 


under TCP/IP.

All well and good!
It doesn't fly with the business or my mangement.
If I could get away with that, we would be TCP/IP on the mainframe, tomorrow.
And, we would have a whole lot of scrap 3745's and 3174's.




(If you went for 7 years without screen reformatting you lived in a very static 
world, indeed.



Never said that we did.
We have people who re-do the MACROS when the screens change.
(Just did it for Germany)





That sounds like a problem with the Tn3270 client, or some kind of 
incompatability between the Tn3270 client and server, or some such.



I can reproduce the problem manually (with 5 minutes of effort).
It has to do with the lack of think time.
Just pound a PFKey until the host barfs.
It happens with:
RUMBA
ATTACHMATE
Hummingbird,
and at least three different web-clients:
2 in JAVA
and on in ACTIVEx.


I could imagine this is a problem with the PC OS (presumably Windows).
Did you try to :
change OS on PC,
change OS on host (yes, there are errors in z/OS!)
change *whole* network connectivity, i.e. connect PC directly to the 
subnetwork, where OSA is connected, change networking cards, drivers, 
switches, firewalls, routers, rules on those devices, etc.





Next question:
"What was the result"?

Answer:
"No matter what client I used, if I typed 'too fast', my session got forcibly 
disconnected".


This indicates that script has nothing to do with the problem. The 
reason is rather speed of 'typing'. It was *never* an issue in 
environments I worked. Including some scripting on PC, even huge "batch 
script, which issued millions of CICS transaction using 3270 emulator.


--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[R.S.]

Ted MacNEIL wrote:
Yes, IP drops packets. But also, yes, TCP keeps track of it all and requests retransmissions. 



Not according to the traces.

If TCP/IP is so robust, why has it NEVER happened in 7 years under SNA (how 
long we've had the TN3270 client we use), and it always happens under TCP/IP.
We have MACROS (scripts) coded for call centres to screen scrape an old CICS 
application and answer customers' questions.
They have never failed under SNA.
The only change we make (and I know it's the only change because I am 
co-ordinating it and controlling it), is we make the TN3270 client talk to 
TCP/IP.
Invoke the MACRO and BOOM!.
Corrupted (incomplete) data sent to the host, the application session gets 
terminated and the user is blown to a blank sign-on screen.

Doesn't even have the logo and sign-on crap we display when the PC first 
connects to the mainframe.

Every time. Not intermittent. No re-transmission requests. No session. No data.


IMHO it is *not* a proof that TCP/IP is bad and SNA is good. The only 
thing it proves is you have a problem with some macro when switched from 
SAN to TCP/IP. It can happen because of error in the script, emulator, 
emulator settings, even network configuration (i.e. some packets could 
be filtered).
I'm far from claiming that TCP/IP is the best solution, however single 
case, especially not analyzed one is not a proof.


--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Ted MacNEIL]

>1122 S
Requirements for Internet hosts - communication layers, Braden R.,

Abbott & Costello:

Costello:
I can speak any language in the world, except Greek.

Abbott:
Say something in Spanish.

Costello:
That's Greek to me!


.
-teD

Marching to the beat of a different flute  

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Anne & Lynn Wheeler]

Tom Schmidt wrote:
> Read a little about John Nagle's observations on network performance here: 
>  
> http://www.port80software.com/200ok/archive/2005/01/31/317.aspx
>  
> That particular link hyperlinks to a Microsoft page that gives you a clue 
> how to change your registery settings to alter the PC's settle time.  
> Perhaps that will help you?
>  
> (If not, RFC896 is Mr. Nagle's original RFC on the subject.  Use 'RFC896' 
> as a search argument in your TCPIP terminal emulator documentation to see 
> if they offer help there.)  
>  

my ietf RFC index (frames mode)
http://www.garlic.com/~lynn/rfcietff.htm

normally RFC summaries load in the lower frame.

clicking on the ".txt=nnn" field in the summaries retrieves the actual RFC.

RFC 896
http://www.garlic.com/~lynn/rfcidx2.htm#896


896
Congestion control in IP/TCP internetworks, Nagle J., 1984/01/06
(9pp) (.txt=26782) (Ref'ed By 985, 1016, 1072, 1122, 1254, 1323, 1812,
2126, 2309, 2525, 2556, 2914, 3539, 3714, 4138, 4172, 4413)


however, see several implementation discussions in 1122 related to Nagle.
http://www.garlic.com/~lynn/rfcidx3.htm#1122


1122 S
Requirements for Internet hosts - communication layers, Braden R.,
1989/10/01 (116pp) (.txt=289148) (STD-3) (Updated by 4379) (See Also
1123) (Refs 768, 791, 792, 793, 813, 814, 815, 816, 817, 826, 879, 893,
894, 896, 922, 950, 963, 964, 980, 994, 995, 1009, 1010, 1011, 1016,
1042, 1071, 1072, 1108, 1112) (Ref'ed By 1127, 1180, 1190, 1191, 1207,
1219, 1254, 1256, 1329, 1349, 1370, 1379, 1385, 1403, 1433, 1455, 1517,
1531, 1533, 1541, 1561, 1577, 1620, 1626, 1644, 1716, 1745, 1755, 1770,
1812, 1819, 1885, 1933, 1937, 1970, 2001, 2131, 2132, 2176, 2225, 2309,
2331, 2353, 2360, 2391, 2414, 2461, 2463, 2474, 2481, 2488, 2498, 2521,
2525, 2581, 2663, 2678, 2694, 2757, 2760, 2784, 2822, 2834, 2835, 2893,
2914, 2923, 2988, 3021, 3022, 3081, 3135, 3154, 3155, 3168, 3175, 3259,
3260, 3360, 3366, 3390, 3435, 3449, 3465, 3481, 3490, 3522, 3684, 3720,
3821, 3884, 3948, 4035, 4172, 4302, 4367, 4379, 4391, 4413, 4443, 4459,
4460)

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Tom Schmidt]

On Fri, 16 Jun 2006 00:00:00 GMT, Ted MacNEIL wrote:
 
...snipped...
 
>>I happen to be an SNA bigot and have no love for TCP/IP, but don't like 
>>seeing bogus arguments against TCP/IP.
>
>It's not bogus. I explained the issue to a z/OS TCP/IP consultant, at CMG 
>Canada in April.  
>Even with my poor grasp of terminology, she knew what the issue was.
>Something about NAGLE (spelling?) and host settle-time.
 
 
Read a little about John Nagle's observations on network performance here: 
 
http://www.port80software.com/200ok/archive/2005/01/31/317.aspx
 
That particular link hyperlinks to a Microsoft page that gives you a clue 
how to change your registery settings to alter the PC's settle time.  
Perhaps that will help you?
 
(If not, RFC896 is Mr. Nagle's original RFC on the subject.  Use 'RFC896' 
as a search argument in your TCPIP terminal emulator documentation to see 
if they offer help there.)  
 
-- 
Tom Schmidt 
Madison, WI 
 

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Ted MacNEIL]

>I obviously can't comment on traces I haven't seen.  I can say that TCP 
>provides guaranteed delivery ... if you (and your software) are willing to 
>cope with some very ugly timings.

We have no guaranteed delivery! Period!
And, the only change was SNA to TCP/IP.

>>If TCP/IP is so robust, why has it NEVER happened in 7 years under SNA (how 
>>long we've had the TN3270 client we use), and it always happens under TCP/IP.

>I don't understand that statement.  If you've been using Tn3270 for 7 years 
>you've been using TCP/IP.  >By definition, Tn3270 is 3270 over TCP/IP.

Not being a network person, I may be tripping over terminology.
It's been the same desktop client for 7 years.


>First, in my VERY unhumble opinion, anybody using screen scraping gets what he 
>or she deserves.  (BOOM!)  That was as true under pure SNA as 
under TCP/IP.

All well and good!
It doesn't fly with the business or my mangement.
If I could get away with that, we would be TCP/IP on the mainframe, tomorrow.
And, we would have a whole lot of scrap 3745's and 3174's.


> (If you went for 7 years without screen reformatting you lived in a very 
> static world, indeed.

Never said that we did.
We have people who re-do the MACROS when the screens change.
(Just did it for Germany)



>That sounds like a problem with the Tn3270 client, or some kind of 
>incompatability between the Tn3270 client and server, or some such.

I can reproduce the problem manually (with 5 minutes of effort).
It has to do with the lack of think time.
Just pound a PFKey until the host barfs.
It happens with:
RUMBA
ATTACHMATE
Hummingbird,
and at least three different web-clients:
2 in JAVA
and on in ACTIVEx.



>If this is not an intermittant problem it is absurd to blame it on dropped IP 
>packets.  Dropped packets are not a repeatable issue ... unless you are 
>violating the protocol or have something misconfigured.

The packet drops (not always the same one), but with no think time the desktop 
is sending the data too fast.


>(Sending packets too large for a level-2 switch will be dropped every time.  
>And trying to set up an SNA connection between mismatched ends will fail,
too.  Remember NRZI vs non-NRZI?)

I don't know what you just said. And, no, I don't remember.
The packets are one PFKey.


>I happen to be an SNA bigot and have no love for TCP/IP, but don't like seeing 
>bogus arguments against TCP/IP.

It's not bogus. I explained the issue to a z/OS TCP/IP consultant, at CMG 
Canada in April.
Even with my poor grasp of terminology, she knew what the issue was.
Something about NAGLE (spelling?) and host settle-time.


>Crying "wolf" helps nobody.

I am not crying wolf.
Also, I was not asking for help here.
I was just pointing out that TCP/IP sucks, is a weak protocol and is going to 
take over the market.


>Find more specifics about your failure; there is something more specific than 
>just "TCP/IP" here.

If I knew what questions to ask, I would.

Standard Problem Determination question:

"What changed"?

Answer:
"I changed to protocol on the desktop to communicate through TCP/IP, rather 
than SNA".

Next question:
"What was the result"?

Answer:
"No matter what client I used, if I typed 'too fast', my session got forcibly 
disconnected".

Secondary Answer:
"When I used scripts, it happened immediately"!

IPSO FACTO! Q.E.D.


.
-teD

Marching to the beat of a different flute  

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Patrick O'Keefe]

On Thu, 15 Jun 2006 00:00:00 GMT, Ted MacNEIL <[EMAIL PROTECTED]> 
wrote:

>>Yes, IP drops packets. But also, yes, TCP keeps track of it all and 
requests retransmissions.
>
>Not according to the traces.

I obviously can't comment on traces I haven't seen.  I can say that 
TCP provides guaranteed delivery ... if you (and your software) are 
willing to cope with some very ugly timings.

>
>If TCP/IP is so robust, why has it NEVER happened in 7 years under SNA 
(how long we've had the TN3270 client we use), and it always happens under 
TCP/IP.

I don't understand that statement.  If you've been using Tn3270 for 7 years
you've been using TCP/IP.  By definition, Tn3270 is 3270 over TCP/IP.

>We have MACROS (scripts) coded for call centres to screen scrape an old 
CICS application and answer customers' questions.
>They have never failed under SNA.
>The only change we make (and I know it's the only change because I am co-
ordinating it and controlling it), is we make the TN3270 client talk to 
TCP/IP.
>Invoke the MACRO and BOOM!.

First, in my VERY unhumble opinion, anybody using screen scraping gets
what he or she deserves.  (BOOM!)  That was as true under pure SNA as 
under TCP/IP.  (If you went for 7 years without screen reformatting you
lived in a very static world, indeed.


>Corrupted (incomplete) data sent to the host, the application session 
gets terminated and the user is blown to a blank sign-on screen.
>
>Doesn't even have the logo and sign-on crap we display when the PC first 
connects to the mainframe.
>
>Every time. Not intermittent. No re-transmission requests. No session. No 
data.

That sounds like a problem with the Tn3270 client, or some kind of 
incompatability between the Tn3270 client and server, or some such.  If
this is not an intermittant problem it is absurd to blame it on dropped
IP packets.  Dropped packets are not a repeatable issue ... unless you 
are violating the protocol or have something misconfigured.  (Sending 
packets too large for a level-2 switch will be dropped every time.  And
trying to set up an SNA connection between mismatched ends will fail,
too.  Remember NRZI vs non-NRZI?)

I happen to be an SNA bigot and have no love for TCP/IP, but don't like
seeing bogus arguments against TCP/IP.  Crying "wolf" helps nobody.
Find more specifics about your failure; there is something more specific
than just "TCP/IP" here.

Pat O'Keefe 

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 06/15/2006
   at 02:47 PM, "Patrick O'Keefe" <[EMAIL PROTECTED]> said:

>What would an SNA name server do?

Map a tree structured name space into a two level name space, of
course.
 
-- 
 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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Ted MacNEIL]

> I'm going to ask a dumb question about the TN3270 client - is it somehow 
> using UDP instead of TCP? 

I don't even know what UDP is.
I'm not a network person.
I'm stuck on this project because I'm the only Mainframe Techie for our company.
The rest are outsourced.

The traces show some kind of stutter.
Then a 'terminate session' request is sent back to the client workstation.

The terminology is not from our service provider's staff, rather from a second 
(or third) hand explanation.

I mentioned our problem to a z/OS TCP/IP consultant I met at a CMG Canada 
seminar, two months ago.

She understood what the problem was (or so it seemed).
She mentioned something called a 'nagle' (spelling?).
She mentioned that we could engage her through IGS.

We have tried to engage IGS and they have been hesitant to take our money.
They suggested a PMR.
We've been that route with no success.

.
-teD

Marching to the beat of a different flute  

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Ted MacNEIL]

>Yes, IP drops packets. But also, yes, TCP keeps track of it all and requests 
>retransmissions. 

Not according to the traces.

If TCP/IP is so robust, why has it NEVER happened in 7 years under SNA (how 
long we've had the TN3270 client we use), and it always happens under TCP/IP.
We have MACROS (scripts) coded for call centres to screen scrape an old CICS 
application and answer customers' questions.
They have never failed under SNA.
The only change we make (and I know it's the only change because I am 
co-ordinating it and controlling it), is we make the TN3270 client talk to 
TCP/IP.
Invoke the MACRO and BOOM!.
Corrupted (incomplete) data sent to the host, the application session gets 
terminated and the user is blown to a blank sign-on screen.

Doesn't even have the logo and sign-on crap we display when the PC first 
connects to the mainframe.

Every time. Not intermittent. No re-transmission requests. No session. No data.

.
-teD

Marching to the beat of a different flute  

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Patrick O'Keefe]

On Mon, 12 Jun 2006 00:00:00 GMT, Ted MacNEIL 
<[EMAIL PROTECTED]> wrote:

>>TCP keeps track of it all, requesting a resend of dropped/lost/missing 
packets.
>
>NOT in this case!
>The packets are dropped!
>They are not re-sent and the app is blown off the air.
>It works under SNA; it bellies up under TCP/IP.
>Every time! Repeatable!
>...

I'm way behind on on IBM-Main so am probably jumping onto a cold thread,
but want to add my belated 2 cents worth.  Ted is probably right about 
the behavior of the application and is spot-on with "Repeatable!", but
is a bit off on his criticizm of TCP/IP.

Yes, IP drops packets. But also, yes, TCP keeps track of it all and 
requests retransmissions.  The reason this works much better in SNA  
(IM not so HO) is that the error detection and correction in SNA 
happens at a much lower level than in TCP/IP - at what would be the 
IP level - at the level where timers can match "line" characteristics - 
very short timers.  There is guaranteed delivery at a very low level;
data gets through or the route is declared dead.

On the other hand, IP does not guarantee delivery.  It is left up to the
higher (TCP) level to detect need for retransmission.  And since any 2
packets can flow across different routes with very different speeds, it
has to have very long timers or risk requesting unneeded retransmissions.
If the retransmission timers are longer than timers in the application
(something completely unneeded in an SNA app), the app may choke even 
though data is on the way. In other words, TCP guarrentees delivery of
data, but the app may not be willing or able to wait.

One aspect of this is that behavior of an SNA network is MUCH more
predictable than a TCP/IP behavior.  Network management is self-
contradictory in TCP/IP because behavior is too random.

And in regard to the DNS issues in this thread, that's sort of a red
herring.  IP addressing is based on numeric addresses.  SNA addressing
is based on . names (with numeric addresses used within
a domain, and to a lesser extent, between domains in SNI configurations).
What would an SNA name server do?  

A bigger issue is that a public network like the internet does not map
well to SNA's 2-level name structure.

Pat O'Keefe



  

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 06/12/2006
   at 07:21 AM, Anne & Lynn Wheeler <[EMAIL PROTECTED]> said:

>SNA isn't networking

Not originally, but that changed with MSNF and changed more with SNI.
 
-- 
 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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Anne & Lynn Wheeler]

Ted MacNEIL wrote:

NOT in this case!
The packets are dropped!
They are not re-sent and the app is blown off the air.
It works under SNA; it bellies up under TCP/IP.
Every time! Repeatable!


there were some amount of dirty tricks ... not all that can be repeated 
in polite company.


with respect to the previous post about running sna thru a real 
(peer-to-peer) infrastructure
http://www.garlic.com/~lynn/2006.html#50 Mainframe Linux Mythbusting 
(Was: Using Java in batch on z/OS?)


and eliminating the communication groups whole 37xx business  the 
obvious reaction was to get corporate to make sure all of my funding was 
cut.


the couldn't actually kill the project because it came out of another 
organization and most of the work was going to be subcontracted to the 
original (RBOC) implementers.


so showing a little ingenuity ... we went to one of the largest SNA 
customers. they had a huge annual budget devoted to operational and 
infrastructure things to compensate for SNA shortcomings. we showed that 
the fully funded costs for development, ship, and support of this other 
thing ... plus the hardware costs replacing all the 37xx boxes ... was 
less than their first year savings on all the add-on stuff that they 
could now eliminate (i.e. the customer would fund the total product 
development and product ship costs ... because they would easily recover 
that within the first year of operation).


getting that part stop required other measures.

so there was an early mainframe tcp/ip implementation. in the late 80s, 
it would get about 44kbyte/sec aggregate thruput and consume just about 
a whole 3090 processor. i added rfc 1044 support to the implementation 
and in some tuning tests at cray research between a 4341 (clone) and a 
cray machine was able to show sustained effective thruput of approx. 
1mbyte/sec using only a modest amount of the 4341 processor (limited to 
the controller hardware interface to the 4341 channel); i.e. about 25 
times the thruput for maybe 1/10th the pathlength.


was somehow  able to sneak out rfc 1044 support in the product when 
nobody was looking. misc. past posts mentioning rfc 1044 support:

http://www.garlic.com/~lynn/subnetwork.html#1044

the communication division finally came out and said that even tho sna 
and OSI were strategic (govs. and large institutions and organizations 
were all publicly claiming that all that internetworking stuff was going 
to be eliminated and replaced by osi)

http://www.garlic.com/~lynn/subnetwork.html#xtphsp

... that they were doing a tcp/ip implementation support in vtam. there 
was an organization in palo alto sq (corner of page mill and el camino) 
that was sometimes referred to as communication "west". they got the job 
of subcontracting the vtam implementation to a contractor.


the first/original (vtam) implementation had tcp/ip thruput 
significantly higher than lu6.2. it was then explained to the contractor 
that all protocol analysis have shown that lu6.2 has higher thruput than 
tcp/ip ... and therefor any tcp/ip implementation that benchmarked 
tcp/ip with substantially higher thruput than lu6.2 was incorrect ... 
and the company wasn't going to pay for an incorrect tcp/ip 
implementation. so what did the contractor do?


in that time-frame there was some analysis of NFS implementation running 
on top of typical tcp/ip ... common bsd tahoe/reno workstation 
implementation. there was a range of implementations from a low of 5k 
instruction pathlength (and five buffer copies) to something like 40k 
instruction pathlength ... to do a typical NFS operation.


in some detailed comparisons, it was claimed that somewhat equivalent 
mainframe function (not NFS, but the closest that SAA had to NFS 
capability) implemented on top of LU6.2 required 160k instructions and 
15 buffer copies. Also, at the time, one of the issues in doing an 
8kbyte buffer copy (involved in a NFS equivalent operation) was that 15 
8k buffer copies could add more processor cycles than executing the 160k 
instructions.


--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on

[Paul Gilmartin]

In a recent note, Ted MacNEIL said:

> Date: Mon, 12 Jun 2006 00:00:00 GMT
> 
> >o No DNS?
> 
> If you build it, they will come.
> 
So, then, IBM elected not to build it, and "they" stayed away.

And the Wheelers attribute grave architectural paralysis to
political infighting within IBM.  Pity.  If it were a usable
alternative to TCP/IP, and more reliable, it would be valuable.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Ted MacNEIL]

>TCP keeps track of it all, requesting a resend of dropped/lost/missing packets.

NOT in this case!
The packets are dropped!
They are not re-sent and the app is blown off the air.
It works under SNA; it bellies up under TCP/IP.
Every time! Repeatable!

-
-teD

300,000 Kilometres per Second
Not only is it a good idea!
It's the LAW!!!  

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Anne & Lynn Wheeler]

Ed Gould wrote:
I don't think SNA has anything like a DNS (warning my info is old). The 
last time I did a 3745 gen you had to hardcode a lot of subareas. 
Although I do think they have updated it since then (hope so anyway). 
There were some route tables that could get hairy. I had access to the 
RTG tool and it made a complicated map reasonably easy. IIRC, SNI was 
another mess that helped, but it was still complicated. JES2 could add 
complexity as he could start routing output via another node that you 
didn't expect if you weren't careful. To most (all?) nodes in my 200+ 
node JES2 network I turned off the JES2 routing as we were connected all 
over the place and I did not want the output to be done through a 3rd 
party node.


I suppose if the nodes were all one company it wouldn't make a 
difference. But financial information was too important to let others 
see it.


re:
http://www.garlic.com/~lynn/2006l.html#45 Mainframe Linux Mythbusting 
(Was: Using Java in batch on z/OS?)


a lot of the original hasp/jes2 networking code running originally on 
the internal network still carried the "TUCC" identifier on source code 
"cards".


HASP had a 255 entry table for psuedo devices. the hasp/jes2 support 
started out defining networking nodes using unused entries in the psuedo 
device table. that typically allowed JES2 to defined something like 
160-200 networking nodes. misc. past hasp &/or jes2 postings

http://www.garlic.com/~lynn/subtopic.html#hasp

by the time JES2 networking was announced as a product, the internal 
network had over 255 nodes

http://www.garlic.com/~lynn/subnetwork.html#internalnet

and by the time JES2 had support for 999 nodes, the internal network was 
over 1000 nodes, and by the time JES2 had support for 1999 nodes, the 
internal network was over 2000 nodes. JES2 would trash any network 
traffic that came thru the node, where JES2 didn't have the destination 
node in its local table. However, JES2 also would trash any network 
traffic where the originating node wasn't in its local table. This made 
JES2 almost unusable on the internal network except as carefully 
controlled end-node (not as any sort of intermediate store&forward node).


the other problem was that JES2 network architecture was notorious for 
getting networking mixed up with work load processing. relatively minor 
changes in header formats between releases could result in one JES2 
system crashing another JES2 (and associated MVS) system. there is an 
infamous case on the internal network where a JES2 system in San Jose 
was causing a MVS system in Hursley to crash.


since the primary mainstay of the internal network had implemented 
gateway-like capability ... it also implemented a large array of 
different interfaces/gateways to JES2 systems  allowing JES2 
networking some modicum of participation in the internal network. 
because of the problem with one jes2 system causing other jes2/mvs 
systems to crash (due to even minor from changes in version/releases) 
... there grew up compensating processes in the internal network jes2 
gateway interfaces. basically a canonical jes format representation. An 
internal network interface that talked directly to a real JES2 node ... 
would be specific to that version/release of jes2 ... and eventually had 
the code that converted from canonical JES2 format to the format needed 
by that specific JES2 system (as countermeasure preventing different 
JES2 systems causing each other to crash).




as an aside ... the corporate requirements for the internal network 
required all transmission leaving a corporate facility to be encrypted. 
at one point there was the claim that the internal network had over half 
of all the link encryptors in the world. one of the harder issues 
getting internal network connectivity in various parts of the world was 
the issue of encrypted links crossing national boundaries ... it was 
frequently a really tough sell to get two (or more) different government 
agencies to all agree that a link going from one corporate location (in 
one country) to another corporate location (in a different country) 
could be encrypted.


disclaimer ... during part of this period my wife served a stint in the 
g'burg jes group.


--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Ted MacNEIL
> 
> >I think it also was due (in part at least) to the late 
> 80's/early 90's 
> >Anything but IBM attitude,
> 
> Possibly, but I also see the same attitude with TCP/IP.
> This is the standard? Why?
> 
> Compared to SNA, it sucks!

Not even that good, yet.

Unrelated question:  Why do you preset the Reply-to: for offlist
replies?

-jc-

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Craddock, Chris]

> But, the biggest problem is data integrity, as far as I'm concerned.
> We have a problem where data is dropped under TCP/IP and it is not
under
> SNA.

Pardon? TCP and IP are not the same thing. TCP is a stateful protocol
that is implemented over the top of IP which isn't. It is perfectly ok
for IP to drop a packet or thirty. TCP keeps track of it all, requesting
a resend of dropped/lost/missing packets. 

In practical terms there isn't a lot of difference between an SNA
session and a TCP/IP session - except that the TCP/IP one is vastly
easier to set up and manage. I can't believe you guys are waxing lyrical
about SNA. Have you forgotten what a royal PITA it is to set up and
manage?

CC

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Anne & Lynn Wheeler]

Paul Gilmartin wrote:

Can you envision running the Internet on SNA?

o 8-character flat namespace?

o No DNS?

Or am I mistaking attributes of VTAM for SNA?  (But still, where's SNA's DNS?)


SNA isn't networking ... at least in the sense used by most of the rest 
of the world. SNA is quite good at managing large number of terminals 
... or things effectively emulating large number of terminals

http://www.garlic.com/~lynn/subnetwork.html#emulation

in heavily SNA centric environment, the term "peer-to-peer" networking 
was invented to describe standard networking (as understood by most of 
the rest of the world) differentiated from SNA communication 
infrastructures.


in the early SNA days, my wife had co-authored peer-to-peer networking 
architecture with Bert Moldow ... AWP39 (which never got announced as 
product, sna group possibly viewed it as competition). Later, when she 
was con'ed into going to POK to be in charge of loosely-coupled 
architecture ... she originated "peer-coupled shared data"

http://www.garlic.com/~lynn/subtopic.html#shareddata

which didn't see a lot of uptake ... except for the guys doing IMS 
hot-standby ... at least until parallel sysplex came along.


the closest thing to networking within any kind of SNA context was 
AWP169 ... which the SNA organization non-concurred with announcing. 
After some escalation, AWP169 announcement letter ... "APPN" was 
carefully crafted to not imply any relationship between AWP169/APPN and 
SNA.


I used to chide the person responsible for AWP169 that he was wasting 
his time trying to craft networking into SNA context ... they were never 
going to appreciate and/or accept him ... he would be much better off 
spending his time working within a real networking context like the 
internet.


note that the explosion in the internal corporate network in the 70s and 
early 80s ... wasn't an SNA implementation either  however it had a 
form of gateway capability implemented in every node. slight drift ... 
it was another product brought to you courtesy of the science center

http://www.garlic.com/~lynn/subtopic.html#545tech

as was virtual machines, the (smp) compare-and-swap instruction, the 
invention of GML (original ancestor of sgml, html, xml, etc), and 
numerous interactive technologies. i've also asserted that all the 
performance measurement, modeling, workload profiling, etc, etc ... 
evolved into what is now called capacity planning

http://www.garlic.com/~lynn/subtopic.html#benchmark

in any case (in part because of the gateway like function), the internal 
network

http://www.garlic.com/~lynn/subnetwork.html#internalnet

was larger than arpanet/internet from just about the beginning until 
possibly mid-85. the "arpanet" got its gateway capability with the great 
switchover to internetworking protocol on 1/1/83.

http://www.garlic.com/~lynn/subnetwork.html#internet

recent thread that discussed the size of the internal network vis-a-vis 
the size of the arpanet

http://www.garlic.com/~lynn/2006j.html#34 Arpa address
http://www.garlic.com/~lynn/2006j.html#45 Arpa address
http://www.garlic.com/~lynn/2006j.html#46 Arpa address
http://www.garlic.com/~lynn/2006j.html#49 Arpa address
http://www.garlic.com/~lynn/2006j.html#50 Arpa address
http://www.garlic.com/~lynn/2006j.html#53 Arpa address
http://www.garlic.com/~lynn/2006k.html#3 Arpa address
http://www.garlic.com/~lynn/2006k.html#8 Arpa address
http://www.garlic.com/~lynn/2006k.html#9 Arpa address
http://www.garlic.com/~lynn/2006k.html#10 Arpa address
http://www.garlic.com/~lynn/2006k.html#12 Arpa address
http://www.garlic.com/~lynn/2006k.html#40 Arpa address
http://www.garlic.com/~lynn/2006k.html#42 Arpa address
http://www.garlic.com/~lynn/2006k.html#43 Arpa address

misc. past posts mentioning awp39 and/or awp169 (appn):
http://www.garlic.com/~lynn/2004n.html#38 RS/6000 in Sysplex Environment
http://www.garlic.com/~lynn/2004p.html#31 IBM 3705 and UC.5
http://www.garlic.com/~lynn/2005p.html#8 EBCDIC to 6-bit and back
http://www.garlic.com/~lynn/2005p.html#15 DUMP Datasets and SMS
http://www.garlic.com/~lynn/2005p.html#17 DUMP Datasets and SMS
http://www.garlic.com/~lynn/2005q.html#27 What ever happened to Tandem 
and NonStop OS ?

http://www.garlic.com/~lynn/2005u.html#23 Channel Distances
http://www.garlic.com/~lynn/2006h.html#52 Need Help defining an AS400 
with an IP address to the mainframe

http://www.garlic.com/~lynn/2006j.html#31 virtual memory
http://www.garlic.com/~lynn/2006k.html#9 Arpa address
http://www.garlic.com/~lynn/2006k.html#21 Sending CONSOLE/SYSLOG To 
Off-Mainframe Server

http://www.garlic.com/~lynn/2006l.html#4 Google Architecture

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Ted MacNEIL]

>Can you envision running the Internet on SNA?
>o 8-character flat namespace?
>o No DNS?

If you build it, they will come.

But, the biggest problem is data integrity, as far as I'm concerned.

We have a problem where data is dropped under TCP/IP and it is not under SNA.
Same circumstances.
Fully repeatable.
The issue is caused by user written macros (scripts), that are needed for the 
business.
The data comes in so fast that TCP/IP cannot handle it and the users session is 
blown out of the water.
Under SNA it does not happen.

-
-teD

300,000 Kilometres per Second
Not only is it a good idea!
It's the LAW!!!  

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Ed Gould]

On Jun 11, 2006, at 10:55 PM, Paul Gilmartin wrote:


In a recent note <[EMAIL PROTECTED]> said:


Date: Sun, 11 Jun 2006 00:00:00 GMT

I think it also was due (in part at least) to the late 80's/early  
90's Anything but IBM attitude,


Possibly, but I also see the same attitude with TCP/IP.
This is the standard? Why?

Compared to SNA, it sucks!


Can you envision running the Internet on SNA?

o 8-character flat namespace?

o No DNS?

Or am I mistaking attributes of VTAM for SNA?  (But still, where's  
SNA's DNS?)


-- gil


Gil,

I don't think SNA has anything like a DNS (warning my info is old).  
The last time I did a 3745 gen you had to hardcode a lot of subareas.  
Although I do think they have updated it since then (hope so anyway).  
There were some route tables that could get hairy. I had access to  
the RTG tool and it made a complicated map reasonably easy. IIRC, SNI  
was another mess that helped, but it was still complicated. JES2  
could add complexity as he could start routing output via another  
node that you didn't expect if you weren't careful. To most (all?)  
nodes in my 200+ node JES2 network I turned off the JES2 routing as  
we were connected all over the place and I did not want the output to  
be done through a 3rd party node.


I suppose if the nodes were all one company it wouldn't make a  
difference. But financial information was too important to let others  
see it.


Ed


--
StorageTek
INFORMATION made POWERFUL

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Paul Gilmartin]

In a recent note <[EMAIL PROTECTED]> said: 

> Date: Sun, 11 Jun 2006 00:00:00 GMT
> 
> >I think it also was due (in part at least) to the late 80's/early 90's 
> >Anything but IBM attitude,
> 
> Possibly, but I also see the same attitude with TCP/IP.
> This is the standard? Why?
> 
> Compared to SNA, it sucks!
> 
Can you envision running the Internet on SNA?

o 8-character flat namespace?

o No DNS?

Or am I mistaking attributes of VTAM for SNA?  (But still, where's SNA's DNS?)

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Ted MacNEIL]

>I think it also was due (in part at least) to the late 80's/early 90's 
>Anything but IBM attitude,

Possibly, but I also see the same attitude with TCP/IP.
This is the standard? Why?

Compared to SNA, it sucks!

-
-teD

300,000 Kilometres per Second
Not only is it a good idea!
It's the LAW!!!  

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Wayne Driscoll]

I think it also was due (in part at least) to the late 80's/early 90's
Anything but IBM attitude, driven in part by the OS2/MCA debacle.
Wayne Driscoll
Product Developer
JME Software LLC
NOTE: All opinions are strictly my own.
  

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Edward Jaffe
Sent: Thursday, June 08, 2006 12:48 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

Froberg, David C wrote:
> I think another author who addressed very well the issue of "changes 
> in the paradigm" is Clayton Christensen in The Innovator's Dilemma in 
> which he made a compelling case that paradigm shifts occur when new 
> technologies become cheap enough to do a good enough job, become 
> increasingly adopted and adapted, and the established interests wait 
> to long to respond.
>   

I'm dealing _right now_ with network performance issues in a mixed-media
network and wondering _how on earth_ Ethernet managed to gain so much market
acceptance and prevail over Token-Ring. It certainly wasn't due to technical
superiority. (Far from it!) From what I can gather, it was price, price, and
... oh yeah ... price...

-- 
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.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

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Timothy Sipples]

John McKown wrote:
>
Yes, YOU will take Linux over Windows, as would I. Are you the decision
>maker? Unfortunately, in many cases, the decision makers have a herd
>mentality. I remember when it was "Nobody got fired for buying IBM.".
>Now it is "Nobody got fired for buying Microsoft."

Well, OK, but there's a mighty big (and still fast growing) Linux herd.
There's plenty of market research data on that from Gartner, IDC, etc.
Your particular company may be different -- maybe your herd got separated
from the bigger herd -- but there's no lack of big herd here.  Maybe three
to five years ago, maybe.

Actually if you do a quick Google search -- and if the results are
consistent :-) -- you'd see that, indeed, there are plenty of people who
got fired for buying Microsoft.  My Google says Cardsystems, National
Westminster Bank, Commonwealth Bank of Australia, and the unnamed CIO in
the story I posted not too long ago, among others.

You don't buy Linux, so it's impossible to get fired for buying Linux.  (Or
maybe you should always get fired for buying Linux because you don't have
to buy Linux. :-))  You buy (or don't buy) Linux support.

- - - - -
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Tom Marchant
> Sent: Friday, June 09, 2006 7:17 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Mainframe Linux Mythbusting (Was: Using Java in 
> batch on z/OS?)
> 
> 
> On Thu, 8 Jun 2006 11:16:06 -0400, Jon Brock <[EMAIL PROTECTED]> wrote:
> 
> >
> > This shows some of the good and some of the bad with using
> >open-source technologies.  You can do some very useful and exciting
> >stuff, but it is not as mature as what we are used to with z/OS.
> >
> Linux and Unix are nowhere near what MVS is, but I'll take Linux and
> other Open source software over Microsoft any day.
> 
> Tom Marchant

Yes, YOU will take Linux over Windows, as would I. Are you the decision
maker? Unfortunately, in many cases, the decision makers have a herd
mentality. I remember when it was "Nobody got fired for buying IBM.".
Now it is "Nobody got fired for buying Microsoft."

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited. 
 

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Daz]

But it's a totally diffrent paradigm, IMHumbleO.
In our shop, we have many unixen. But their CP is tied to memory.
Each unixen CP has to have xMB memory, and they come in fours.
You want more memory?  4 More CP + 4 * xMB. And so on. That's costly.
Mainframe is diffrent. Much Diffrent. And the people?
For twenty unix boxen, 1 sysprog/admin. Not Gartner, but close to real.
Big shops, two - three hundred unix boxen, some maybe 'super-domes', really
30 -35 per seat - tough job, really tough.
Close to mainframe? I think totally diffrent.

For Multi-Sysplex MainFrame Production system, how many sysprogs to change a
light bulb?

I love my job.


On 6/9/06, Bob Shannon <[EMAIL PROTECTED]> wrote:


>The same reason people are moving away from the mainframe.  Look at any

>mainframe shop and you'll see an explosive growth in computing power.
The
>mainframes are staying about the same while *ix and Microslop gain..

That may be true in your situation, but certainly not everywhere. Some
mainframe shops have stagnated. Others are seeing tremendous growth. Are
server MIPS growing faster than mainframe MIPS? Probably, but that
doesn't mean mainframes aren't growing.

Bob Shannon
Rocket Software

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Tom Marchant]

On Fri, 9 Jun 2006 08:28:57 -0400, Bob Shannon 
<[EMAIL PROTECTED]> wrote:

>>The same reason people are moving away from the mainframe.  Look at any
>
>>mainframe shop and you'll see an explosive growth in computing power.
>The
>>mainframes are staying about the same while *ix and Microslop gain..
>
>That may be true in your situation, but certainly not everywhere. Some
>mainframe shops have stagnated. Others are seeing tremendous growth. Are
>server MIPS growing faster than mainframe MIPS? Probably, but that
>doesn't mean mainframes aren't growing.
>
I'd like to see the shop where the mainframe is growing even half as
fast as the other platforms.  I'd also like to see the number of
mainframe shops increasing.

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Bob Shannon]

>The same reason people are moving away from the mainframe.  Look at any

>mainframe shop and you'll see an explosive growth in computing power.
The 
>mainframes are staying about the same while *ix and Microslop gain..

That may be true in your situation, but certainly not everywhere. Some
mainframe shops have stagnated. Others are seeing tremendous growth. Are
server MIPS growing faster than mainframe MIPS? Probably, but that
doesn't mean mainframes aren't growing. 

Bob Shannon
Rocket Software

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Tom Marchant]

On Thu, 8 Jun 2006 11:16:06 -0400, Jon Brock <[EMAIL PROTECTED]> wrote:

>
>   This shows some of the good and some of the bad with using
>open-source technologies.  You can do some very useful and exciting
>stuff, but it is not as mature as what we are used to with z/OS.
>
Linux and Unix are nowhere near what MVS is, but I'll take Linux and
other Open source software over Microsoft any day.

Tom Marchant

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Tom Marchant]

On Thu, 8 Jun 2006 10:48:04 -0700, Edward Jaffe 
<[EMAIL PROTECTED]> wrote:
>
>I'm dealing _right now_ with network performance issues in a mixed-media
>network and wondering _how on earth_ Ethernet managed to gain so much
>market acceptance and prevail over Token-Ring. It certainly wasn't due
>to technical superiority. (Far from it!) From what I can gather, it was
>price, price, and ... oh yeah ... price...
>
The same reason people are moving away from the mainframe.  Look at any 
mainframe shop and you'll see an explosive growth in computing power.  The 
mainframes are staying about the same while *ix and Microslop gain.

Not trying to open the debate about TCO...  The perception is that the 
mainframe is expensive.

It's really unfortunate that IBM isn't pricing software aggressively to 
stop the hemorrhage.

Tom Marchant

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Jon Brock]

Browsed that book this past Sunday but did not buy it.  Maybe I'll take another 
look.

Jon




Read "The Tipping Point" by Malcolm Gladwell for some interesting thoughts
on what brings about change.  Fascinating book.


--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Edward Jaffe
> 
> Froberg, David C wrote:
> > I think another author who addressed very well the issue of "changes

> > in the paradigm" is Clayton Christensen in The Innovator's Dilemma
in 
> > which he made a compelling case that paradigm shifts occur when new 
> > technologies become cheap enough to do a good enough job, become 
> > increasingly adopted and adapted, and the established interests wait

> > to long to respond.
> 
> I'm dealing _right now_ with network performance issues in a 
> mixed-media network and wondering _how on earth_ Ethernet 
> managed to gain so much market acceptance and prevail over 
> Token-Ring. It certainly wasn't due to technical superiority. 
> (Far from it!) From what I can gather, it was price, price, 
> and ... oh yeah ... price...

"Good enough" is.

So it was with VHS over BETA, TCPIP over SNA, Windows over OS/2, (E)ISA
over MicroChannel

Who's your "favorite" between HD-DVD and Blue-Ray?

-jc-

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Ed Finnell]

 
In a message dated 6/8/2006 12:48:33 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

to  technical superiority. (Far from it!) From what I can gather, it was  
price, price, and ... oh yeah ... price...




>>
And graphics

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Edward Jaffe]

Froberg, David C wrote:

I think another author who addressed very well the issue of "changes in
the paradigm" is Clayton Christensen in The Innovator's Dilemma in which
he made a compelling case that paradigm shifts occur when new
technologies become cheap enough to do a good enough job, become
increasingly adopted and adapted, and the established interests wait to
long to respond.
  


I'm dealing _right now_ with network performance issues in a mixed-media 
network and wondering _how on earth_ Ethernet managed to gain so much 
market acceptance and prevail over Token-Ring. It certainly wasn't due 
to technical superiority. (Far from it!) From what I can gather, it was 
price, price, and ... oh yeah ... price...


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Bill Seubert]

On Thu, 8 Jun 2006 09:13:10 -0400, Froberg, David C <[EMAIL PROTECTED]> wrote:

>I think another author who addressed very well the issue of "changes in
>the paradigm" is Clayton Christensen in The Innovator's Dilemma in which
>he made a compelling case that paradigm shifts occur when new
>technologies become cheap enough to do a good enough job, become
>increasingly adopted and adapted, and the established interests wait to
>long to respond.

Read "The Tipping Point" by Malcolm Gladwell for some interesting thoughts
on what brings about change.  Fascinating book.


Bill Seubert
zSeries Software I/T Architect
IBM Corp
[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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Jon Brock]

I have had some squirrely results with both NFS and Samba.  In the 
latest case, I was mounting a CD on a desktop Linux system and exporting the 
CD-RW drive.  I could never get the NFS file system mounted on my client 
platform (I need to go back and check on this at some point).  When I switched 
to Samba, I could mount it just fine, but using it to drive a WebSphere 
graphical install did not work.  I eventually used the SMB-mounted file system 
to copy the CD over to the target VM/Linux system and installed from there.  
Worked great.

This shows some of the good and some of the bad with using open-source 
technologies.  You can do some very useful and exciting stuff, but it is not as 
mature as what we are used to with z/OS. 

Jon




Oh to use Samba, SMB, or NFS to make the MF
a big fileserver to the client/server flock.  New applications on the
MF?  Would have loved too. 


--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Froberg, David C]

>Why are mainframe people so reluctant to change ?
Not all of us are reluctant.  I remember being in an SHARE session about
OpenEdition (gee, was it ESA 4.3 or 5.1, about 10 years ago).  It was in
a small hotel room where the speaker was talking about this new feature
called OpenEdition and the room was packed.  As soon as I got back to
work, I was scrambling to get OE on to our system.  Unix and Open
Standards clearly had a future on the mainframe.  In due time, I dug
into Linux and TCP/IP too.  Oh to use Samba, SMB, or NFS to make the MF
a big fileserver to the client/server flock.  New applications on the
MF?  Would have loved too. But, when you work at shops where management
has determined to leave the mainframe for whatever reason, there's only
so much you can do.

> very Boyd and ooda-loop oriented
> http://www.garlic.com/~lynn/subboyd.html#boyd
> http://www.garlic.com/~lynn/subboyd.html#boyd2
>

Thank you for the links about Boyd.  Your references to him are very
appropriate.  Boyd was brilliant and gutsy and not studied enough.

I think another author who addressed very well the issue of "changes in
the paradigm" is Clayton Christensen in The Innovator's Dilemma in which
he made a compelling case that paradigm shifts occur when new
technologies become cheap enough to do a good enough job, become
increasingly adopted and adapted, and the established interests wait to
long to respond.
 
Dave

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Gabe Goldberg]

I'm not disagreeing, just emphasizing your point: Other-platform folk happily proceed with projects whose problems they can't anticipate and (maybe) solve the problems later. Mainframers are better at seeing problems with proposed projects. And it's the mainframers who need their attitudes adjusted, not the other-platform folk who management thinks should do better project analysis. 


Sad but likely true. I've worked in no-bad-news settings where messengers 
bearing unhappy news had a poor survival rate.

Marian Gasparovic <[EMAIL PROTECTED]> said:

If you come with an idea of new application or solution, people from
other platform see no problem, mainframe people show what are
pitfalls. I don't say it is bad, I know it is because of their
responsibility and experience to see the problems way ahead, but
unfortunately today's market doesn't work this way. Everybody wants
everything as fast as possible, problems are solved later, during
production. Yes, it is totaly wrong, but it is reality.

--
Gabriel Goldberg, Computers and Publishing, Inc.  (703) 204-0433
3401 Silver Maple Place, Falls Church, VA 22042[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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Kirk Wolf]

John,

I can relate to your Endevor problems... I worked with client to get 
this set up, and it just doesn't support HFS file systems well enough to 
be usable for Java source control.   In the end, they decided to check 
in a distribution "tar" file into Endevor and then wrote JCL/scripts to 
allow Endevor to handle the deployment/promotions.   The source is 
maintained in either CVS or PVCS and builds of the tar distributions 
were done via a Ant script on a Unix system, which was kicked off by a 
MVS job.


As far as development tools, I would encourage you to look at using the 
Eclipse IDE for z/OS Java development.
We have put up some documentation and examples (from our SHARE 
presentations) on how to do this on our web sites:


http://jzos.com/docs/eclipseSetup.html
http://dovetail.com/downloads.html  (see the "Batch XML Sample" project 
download)


With Eclipse setup properly, you can code/compile your Java in a 
fantastic (and free) IDE, and then use ANT to one-click deploy the code 
to z/OS via FTP.


Regards,
Kirk

McKown, John wrote:



Thanks. I already have a web site on our z/OS system. I have even
written a web based application to do our "standard" RACF stuff such as
creating a new userid, deleteing an existing id, resume an id, revoke an
id, etc. It uses REXX CGI programs.

I am looking at Java (JZOS) right now. Not too bad, but could use a
zAAP. But even presenting it to my team gets a yawn. "What good is it?"
There is an entire 'nother thread on this. I can imagine some really
NICE things if we did some CICS/Java for our XML and "web based" stuff.
Just plain no interest. And, to be honest, we cannot integrate it into
our current Endevor change environment (as best as I can tell). I am
only one person, with very poor sales skills. And I have not been able
to present a "fool proof" plan of how to implement any of this so that
it would be usable "out of the box" and completely integrated into our
current development methodology. I.e. develop Java using ISPF (in PDS
libraries), then submit batch jobs to compile it into yet another PDS.
Remember, no liking around here for UNIX stuff. Just to be honest, the
programmers have a point. They are swamped (as are most) just trying to
keep the boat afloat. They don't usually have time to do fancy
scrollwork on the stair rails while the boat sinks.



---

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on
06/06/2006
   at 10:00 AM, Marian Gasparovic <[EMAIL PROTECTED]> said:

>Flame me,

I refuse!

I certainly have no objection to adding another platform to my
repertoire.
 
-- 
 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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on
06/05/2006
   at 04:05 PM, Anton Britz <[EMAIL PROTECTED]> said:

>a. "1700 installations"

Pay close attention. That number refers to Linux on zSeries, not to
the total Linux usage.

>d. Not in the USA

And you know that how? How do you account for the rise in browsers
claiming to be running under Linux?
 
-- 
 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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS ?)

[Nix, Robert P.]

We did a POC using zVM 4.4 and both RedHat and SuSE images, and ran that way on 
one IFL for close to a year (things move slowly here). We had just retired zVM 
and OfficeVision shortly after this started, so we had two zVM people with 
fairly extensive experience.

We currently have two LPARs in two separate CECs, with two IFLs in each, and 
10Gig of memory in each, running zVM 5.1 and about 50 Linux guests. All the 
significant guests are SuSE SLES. We run both version 8 and 9, depending on 
what the application dictates.

I've been rolled from the Mainframe support group into the Unix support group, 
and there are now two of us doing Linux support, both for the mainframe and for 
Intel and Blade servers. (The Linux person is learning zVM much faster than I'm 
learning Linux.) 

The two main projects we are working on in the mainframe Linux are Tivoli 
support, along with Tivoli's DB2 servers, and IBI I-Way servers. Our main 
objective was to remove usage from our zOS LPARs to extend the life of the 
system (I-Way accounted for 100 MIPS in zOS, and moving it to zLinux releases 
those resources).

For what we've been working in, Linux is Linux, and virtual hardware is much 
easier to come by than real hardware. Where an Intel or Blade project has a 
several week lead-time before the applications people even get to touch the 
box, a zLinux system can be built and handed over in about a day. And, we're 
working on cutting that time down, via cloning instead of full Linux installs.

Interesting bits and pieces: We're IPLing both LPARs from the same zVM sysres 
volume. We're working on converting everything to vSwitch, and the two 
vSwitches are attached to the same subnet and external switch, so we should be 
able to move a guest from one LPAR to the other just by bringing it down on one 
LPAR and then autologging it on the other (untested as yet). We're interested 
in Hipersockets to talk to the zOS DB2, but we haven't been able to sell our 
DB2 Connect support people on the idea as yet (They support DB2 Connect server 
on Windows, and aren't interested in supporting it on another platform.) We're 
looking at the cloning model described in the Virtualization Cookbook Redbook. 
And our Oracle people are interested in kicking the tires, so we may have an 
Oracle in a zLinux image shortly.

That's about all I can think of that might be of interest to anyone here.

If you don't have Linux in your shop... This probably isn't for you. Don't do 
it just for the sake of doing it. If you have a lot of Linux already, then this 
is something to think about, as it can cut down on your floor space and 
resource consumption. If you're just getting interested in Linux, do Intel 
first, and keep this in the back of your mind as an option for later on.

Just to apply scale, for comparison to your own shop: We run two z990's running 
zOS and zVM in two separate data centers. We also have about 300 Unix servers 
supporting various tasks, and about 1,400 Windows servers. We have somewhere 
around 28,000 Windows desktops here on this campus; I'm not sure of the numbers 
at the other two sites. Mayo here in Rochester employs about 31,000 people.

-- 
Robert P. Nix   Mayo Foundation
RO-OC-1-13  200 First Street SW
507-284-0844Rochester, MN 55905
-
"In theory, theory and practice are the same, but
 in practice, theory and practice are different."

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Alan 
C. Field
Sent: Tuesday, June 06, 2006 2:21 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

So, any others care to tell about their Linux on Z POCs or 
implementations?   Did your projects stay on schedule and run
smoothly?  Did you have to hire new people or were the existing
zOS or *nix people in your shop able to handle it?  How much help
did you need / get from IBM or other consultants? 

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Alan C. Field]

So, any others care to tell about their Linux on Z POCs or 
implementations?   Did your projects stay on schedule and run
smoothly?  Did you have to hire new people or were the existing
zOS or *nix people in your shop able to handle it?  How much help
did you need / get from IBM or other consultants? 

I'll tell:

We have 4 lpars running z/VM 5.1 and 5.2. on two footprints. Memory 
wise they are our largest LPARs (about 3 times as big as the z/OS ones).
Using shared IFLs. Two of the lpars are production, two are development/ 
test. 

Each LPAR has between 20 and 30 Linux servers running. 

We grew our own z/VM support (two people who worked with VM eons ago).

The Linux side of things is handled by the group that does the *IX 
support. 

No consultants that I am aware of but possibly IBM help.

I think there were some turf battles initially, but management is
solidly behind the zSeries and it is working well for us. 

Alan 

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Anne & Lynn Wheeler]

Marian Gasparovic wrote:

Why are mainframe people so reluctant to change ? I know cases where
mainframe people refused to implement new applications, so they were
implemented on different platform, old applications were removed as
well as mainframe. I witnessed this situation personaly at one
customer before I joined IBM. Now when I work for IBM in mainframe
market I know the fights we have to fight. Mainframe platform and
people are perceived as least flexible. I repeat - we are perceived as
least flexible.


very Boyd and ooda-loop oriented
http://www.garlic.com/~lynn/subboyd.html#boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2

I sponsored Boyd a number of times at internal corporate seminars in the 
early 80s (it started out being slightly less than full day, but as Boyd 
evolved some of his talks it began harder and harder to get it all 
crammed into a single day)  some number of people would go in 
thinking it would be a very non-civilian oriented talk and were 
surprised to find how applicable it was to all sorts of business 
endeavors (it has since become much more acceptable to reference boyd's 
ooda-loop concepts in business settings, especially where rapid 
adaptation and agility to deal with changing circumstances is required).


having projected in the late 80s that things were headed into the red 
and things would have to change ... in the early 90s, we would 
periodically visit places like somers for discussions on the subject.
nobody would really disagree that things were going to have to change 
... but you go back a couple months later and found nothing was changing.


one possible observation was that there were a large number of senior 
people with possibly 25-30 years experience and their perceived value 
was based experience in on a long standing, relatively consistent 
paradigm. any significant changes in the paradigm would significantly 
reduce the perceived value of these individuals' experience.


there appeared to be a large contingent of people that didn't disagree 
that things were going to have to change ... but they were doing 
everything possible to forestall it until at least after they, 
personally had retired (and then it would be somebody else's problem)


--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Tom Marchant]

I agree.  I began to learn Unix with UTS, and the experience made it
easier to pick up Unix System Services.  That, in turn made it easier
when I installed Linux on three of our computers at home.  Certainly,
Linux is a huge improvement over Windows.  Even my kids use it.

Linux, like Unix, is in a different league than z/OS, but that is no
reason to dismiss it outright.

On Tue, 6 Jun 2006 15:37:00 +0900, Timothy Sipples 
<[EMAIL PROTECTED]> wrote:

>Anton wrote:
>>Does this type of talk work for you in Japan these days because I
>>visited the University of Tokyo in 1985 and I was impressed with the way
>>they did their research and the way they understood the "technical" claims
>>from the American companies.
>
snip!
>
>Does anybody seriously dispute that Linux is popular?  That Linux is
>growing?  Including the mainframe?  What I am suggesting is the following:
>
>1. More people here should add Linux to their knowledge base -- ideally
>leading efforts in your shops to implement Linux for certain projects.
>Ostrich strategies do not work, IMHO.
>2. Many of you are already learning Linux (in effect) and just don't know
>it.  USS skills are quite transferable.  (And you need at least a little
>bit of USS knowledge to be a competent z/OS system programmer, in all
>candor.)
>3. Difficulty implementing Linux is exaggerated by many in this forum,
>truly.  It's not zero, but it's also not the Apollo Space Program nor the
>Manhattan Project.
>

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Mark Zelden]

This new thread started after I wrote that Timothy tends to oversimplify
things.   Based on my experience here with a zLinux project and some
(I admit now outdated) experience elsewhere, I am sticking to my 
guns on that.   

Without getting into too much detail.. there were two projects (POCs) 
going on. One was related to moving TSM off of z/OS to run on zLinux under
z/VM and the other was moving TAMe from AIX (I think.. it could have
been Wintel). I did not work on the projects myself, but one of my 
team members did pretty much exclusively for a year. BTW, there was 
a part time consultant with z/VM and Linux "expertise" that was thrown
in by whomever (IBM?) as part of the POC.  Although my team member 
was always telling me he didn't get much support from him. 

As others have suggested, z/VM installation & customization was probably 
not a big deal.  But I can see long term support being a little more
of an issue.  Things like applying / rolling out maintenance, backup /
recovery, etc.  

However, the TSM / Linux part was a big deal.  There were constant 
issues with driver levels vs. kernel levels, re-installs, trouble
obtaining the proper levels, and issues with some third party software
that was involved in interfacing to STK tape drives in a 9310 SILO.  This
of course was on top of the learning curve issues of an unfamiliar 
environment to the zOS sysprog working on the project (he was working 
with one of the VTAM sysprogs who had some VM and unix experience).
This project was eventually canned.   

The TAMe POC never really got off the ground to begin with.  

18 months after the start I'm not even sure where we are now.
z/VM and zLinux still aren't dead yet.  There is just nothing production
running on it at the moment.  I'm pretty sure they are still looking
at other opportunities and perhaps even testing WAS on zLinux as I
write.

I'm not saying that our experience is typical.  Part of the problem
was lack of solid commitment by management with these projects and
getting the resources needed.  All I am saying is what I said to 
begin with - I think Timothy  oversimplified how easy it is to get
an application running on Linux or Linux under z/VM.  Remember, 
these were only POCs, which to me is still quite a bit away
from an enterprise ready production application.

So, any others care to tell about their Linux on Z POCs or 
implementations?   Did your projects stay on schedule and run
smoothly?  Did you have to hire new people or were the existing
zOS or *nix people in your shop able to handle it?  How much help
did you need / get from IBM or other consultants?  

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group
mailto: [EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[R.S.]

Marian Gasparovic wrote:


Why are mainframe people so reluctant to change ? I know cases where
mainframe people refused to implement new applications, so they were
implemented on different platform, old applications were removed as
well as mainframe. I witnessed this situation personaly at one
customer before I joined IBM. Now when I work for IBM in mainframe
market I know the fights we have to fight. Mainframe platform and
people are perceived as least flexible. I repeat - we are perceived as
least flexible.

[...]
Fully agreed. Mainframe specialists I met are most conservative folks I 
know. How many of us never used USS shell, how many still prefer IOCP 
coding over HCD, how many still use NOEGN, haven't migrated to SMS, etc.
From the other hand: IBM pushes customers to use Linux on z/Series, no 
doubt. Otherwise IFL would cost the same as general CP.
It's even funny to observe IBM conferences in Poland: most speaker talk 
about Linux, zIIP, etc. while majority of customers listening it use 
'the most legacy' applications on z/OS (or OS/390), CICS, VSAM, Adabas, 
sometimes DB2.



--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Steve Comstock
> Sent: Tuesday, June 06, 2006 8:30 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Mainframe Linux Mythbusting (Was: Using Java in 
> batch on z/OS?)



> 
> Well, I know you're not going to offer one of our
> classes, but perhaps they would be intrigued by my
> paper on hosting a web site on z/OS, just as a
> teaser to get them hooked.
> 
> Look at:
> http://www.trainersfriend.com/General_content/Book_site.htm
> 
> and scroll down to the next-to-last entry in the first table.
> 
> Kind regards,
> 
> -Steve Comstock

Thanks. I already have a web site on our z/OS system. I have even
written a web based application to do our "standard" RACF stuff such as
creating a new userid, deleteing an existing id, resume an id, revoke an
id, etc. It uses REXX CGI programs.

I am looking at Java (JZOS) right now. Not too bad, but could use a
zAAP. But even presenting it to my team gets a yawn. "What good is it?"
There is an entire 'nother thread on this. I can imagine some really
NICE things if we did some CICS/Java for our XML and "web based" stuff.
Just plain no interest. And, to be honest, we cannot integrate it into
our current Endevor change environment (as best as I can tell). I am
only one person, with very poor sales skills. And I have not been able
to present a "fool proof" plan of how to implement any of this so that
it would be usable "out of the box" and completely integrated into our
current development methodology. I.e. develop Java using ISPF (in PDS
libraries), then submit batch jobs to compile it into yet another PDS.
Remember, no liking around here for UNIX stuff. Just to be honest, the
programmers have a point. They are swamped (as are most) just trying to
keep the boat afloat. They don't usually have time to do fancy
scrollwork on the stair rails while the boat sinks.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited. 
 

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Steve Comstock]

McKown, John wrote:





Does anybody seriously dispute that Linux is popular?  That Linux is
growing?  Including the mainframe?  What I am suggesting is 
the following:


1. More people here should add Linux to their knowledge base 
-- ideally

leading efforts in your shops to implement Linux for certain projects.
Ostrich strategies do not work, IMHO.



I've been trying here, but the Windows people (at least in the past)
have been "driving the boat". The new CIO is more platform agnostic, but
as "a voice crying in the wilderness", I'm fairly ineffective in getting
anyone interested.


2. Many of you are already learning Linux (in effect) and 
just don't know
it.  USS skills are quite transferable.  (And you need at 
least a little

bit of USS knowledge to be a competent z/OS system programmer, in all
candor.)



My was the reverse. I have been using Linux/Intel at home for quite a
while (finally 99.9% off of Windows!). z/OS UNIX was very easy to pick
up. The other z/OS sysprogs here basically don't like UNIX. I may need
to suggest a minor class on UNIX concepts for them (even invite
interested programmers - what a concept!)


Well, I know you're not going to offer one of our
classes, but perhaps they would be intrigued by my
paper on hosting a web site on z/OS, just as a
teaser to get them hooked.

Look at:
http://www.trainersfriend.com/General_content/Book_site.htm

and scroll down to the next-to-last entry in the first table.

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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Timothy Sipples
> Sent: Tuesday, June 06, 2006 1:37 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Mainframe Linux Mythbusting (Was: Using Java in 
> batch on z/OS?)
> 
> 



> 
> Does anybody seriously dispute that Linux is popular?  That Linux is
> growing?  Including the mainframe?  What I am suggesting is 
> the following:
> 
> 1. More people here should add Linux to their knowledge base 
> -- ideally
> leading efforts in your shops to implement Linux for certain projects.
> Ostrich strategies do not work, IMHO.

I've been trying here, but the Windows people (at least in the past)
have been "driving the boat". The new CIO is more platform agnostic, but
as "a voice crying in the wilderness", I'm fairly ineffective in getting
anyone interested.

> 2. Many of you are already learning Linux (in effect) and 
> just don't know
> it.  USS skills are quite transferable.  (And you need at 
> least a little
> bit of USS knowledge to be a competent z/OS system programmer, in all
> candor.)

My was the reverse. I have been using Linux/Intel at home for quite a
while (finally 99.9% off of Windows!). z/OS UNIX was very easy to pick
up. The other z/OS sysprogs here basically don't like UNIX. I may need
to suggest a minor class on UNIX concepts for them (even invite
interested programmers - what a concept!)

> 3. Difficulty implementing Linux is exaggerated by many in this forum,
> truly.  It's not zero, but it's also not the Apollo Space 
> Program nor the
> Manhattan Project.

Unfortunately, I don't have a zSeries Linux to play with. I could do it
on Hercules/390 at home (I run MVS 3.8j at home! Makes me love the
enhancements in z/OS.) Installing Fedora Core 5 on an old Pentium III
was so simple as to be boring. On my AMD64, I run SuSE 9.3. SuSE 10.0 is
running on my laptop. Installing there were not difficult. YaST makes it
fairly simple. I even have a version of DB2 on my Linux/AMD64. Wish I
knew how to use it .

> 
> [ Speaking for myself, if that wasn't obvious. :-) ]
> 
> - - - - -
> Timothy F. Sipples



--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited. 
 

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Richards.Bob]

With the dumbing down of the MVS Sysprog, I welcome anything that still
requires "some" technical competence to implement. Otherwisewell you
know the rest.

Bob 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ted MacNEIL
Sent: Monday, June 05, 2006 8:00 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Mainframe Linux Mythbusting (Was: Using Java in batch on
z/OS?)

>Difficulty implementing Linux is exaggerated by many in this forum,
truly.  It's not zero, but it's also not the Apollo Space Program nor
the Manhattan Project.

I think, after talking to a few, that the exaggeration is coming from
IBM.

It's not just the implementation. It's also the care and feeding.
AND, the (hidden) costs of z/VM.
And, its care and feeding.

-
-teD

300,000 Kilometres per Second
Not only is it a good idea!
It's the LAW!!! 
  
  
  
LEGAL DISCLAIMER 
The information transmitted is intended solely for the individual or entity to 
which it is addressed and may contain confidential and/or privileged material. 
Any review, retransmission, dissemination or other use of or taking action in 
reliance upon this information by persons or entities other than the intended 
recipient is prohibited. If you have received this email in error please 
contact the sender and delete the material from any computer. 
  
Seeing Beyond Money is a service mark of SunTrust Banks, Inc. 
[ST:XCL] 
 
 
 
 

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Marian Gasparovic]

Why are mainframe people so reluctant to change ? I know cases where
mainframe people refused to implement new applications, so they were
implemented on different platform, old applications were removed as
well as mainframe. I witnessed this situation personaly at one
customer before I joined IBM. Now when I work for IBM in mainframe
market I know the fights we have to fight. Mainframe platform and
people are perceived as least flexible. I repeat - we are perceived as
least flexible.

If you come with an idea of new application or solution, people from
other platform see no problem, mainframe people show what are
pitfalls. I don't say it is bad, I know it is because of their
responsibility and experience to see the problems way ahead, but
unfortunately today's market doesn't work this way. Everybody wants
everything as fast as possible, problems are solved later, during
production. Yes, it is totaly wrong, but it is reality.

Linux is growing, it is a fact. Mainframe won several awards for being
the best hw platform for Linux. Why do we see so many posts about 'our
mainframe will be removed' ? I don't say all, but part of them is just
because new applications were developed elsewhere. Here we remove one
small 'unimportant' application and give it to unix, after two years
it is one of core applications, needing new machines etc. Why not to
develop it under Linux on mainframe ?

And of course well known problem - new managers are taught UNIX and
Linux, not JCL.

Yes, even z/VM has a learning curve. But here you pinpoint it as a
hidden cost, on different platforms (mainly windows) they are not
counted as costs ? Everybody knows other OS out of the box ?

Yes, Timothy is right, installing z/VM *is* easy. Also basic config is
easy. And yes, production config and maintenance needs more knowledge,
as others mention. It is a difference to install something and to tune
it. As everywhere. Unfortunately, people from other platforms don't
care, defaults are too often 'good enough'. But refusing everything
only because it is different, is wrong.

Don't take Linux on mainframe as competition, it is not meant so. z/OS
(z/VSE etc) is 'main' OS on mainframe, but if you can run application
server on Linux on z or on unix, why not to choose Linux on z ? DB2 on
z/OS, WAS on Linux on z is a great combination. Less footprint, less
cables etc(insert all marketing stuff, but part of it is true, even
more true if you grow images). z/VM is not needed for 1-2 LPARs, but
it helps a lot with monitoring, managing, backup etc. You can look at
IBM pages for references.

Flame me, you have full right to do so, compared to most of you I am
still freshmen in wonderful mainframe world.

Marian Gasparovic
IBM Slovakia
(speaking for myself of course, disclaimers, legal notices etc are all
applicable)

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Ted MacNEIL]

>Difficulty implementing Linux is exaggerated by many in this forum, truly.  
>It's not zero, but it's also not the Apollo Space Program nor the Manhattan 
>Project.

I think, after talking to a few, that the exaggeration is coming from IBM.

It's not just the implementation. It's also the care and feeding.
AND, the (hidden) costs of z/VM.
And, its care and feeding.

-
-teD

300,000 Kilometres per Second
Not only is it a good idea!
It's the LAW!!!  

--
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: Using Java in batch on z/OS?

[Hunkeler Peter (KIUB 34)]

Bob, I completely agree with you. I sure know that this is well
received by the finance people. And I know it may help the mainframe
to survive. Yet,... I'm a technical person and I hate to see how
z/OS is being deformed for just that purpose.
 
Peter Hunkeler
CREDIT SUISSE

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Timothy Sipples]

Anton wrote:
>Does this type of talk work for you in Japan these days because I
>visited the University of Tokyo in 1985 and I was impressed with the way
>they did their research and the way they understood the "technical" claims
>from the American companies.

Japan is one of the most successful markets for mainframe Linux.  The
largest mainframe Linux installation in the world (to my knowledge) happens
to be in Japan.  If Japanese research impresses you, perhaps mainframe
Linux should as well.

Re: The system programmer job loss fears, with all due respect, what?!?!
Where have I said that system programmers are not required?  I'd much
rather have more mainframe people employed, quite honestly.  Maybe my hint
wasn't big enough.

Does anybody seriously dispute that Linux is popular?  That Linux is
growing?  Including the mainframe?  What I am suggesting is the following:

1. More people here should add Linux to their knowledge base -- ideally
leading efforts in your shops to implement Linux for certain projects.
Ostrich strategies do not work, IMHO.
2. Many of you are already learning Linux (in effect) and just don't know
it.  USS skills are quite transferable.  (And you need at least a little
bit of USS knowledge to be a competent z/OS system programmer, in all
candor.)
3. Difficulty implementing Linux is exaggerated by many in this forum,
truly.  It's not zero, but it's also not the Apollo Space Program nor the
Manhattan Project.

[ Speaking for myself, if that wasn't obvious. :-) ]

- - - - -
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Anton Britz]

"Linux is extremely popular at universities and colleges worldwide." ?



a. "1700 installations"

b. "Gartner" says... Have you read all the "BS" that Gartner publishes ?
Please come back "James Martin"

c. Extremely popular ? Where .. in the libraries or in the "Game Club"

d. Not in the USA



Does this type of talk work for you in Japan these days because I
visited the University of Tokyo in 1985 and I was impressed with the way
they did their research and the way they understood the "technical" claims
from the American companies.



Anton

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Anne & Lynn Wheeler]

Ed Gould wrote:

Timothy:

I profess I have never installed VM (unless you count once 30 years 
ago). That being said, its never the d/l'ing that is the difficult part 
.. its always the "post" downloading that gets to be a PITA and always 
requires some (some say quite a bit) expertise. The VM system I helped 
set up was on a 4331 (w/3310's IIRC) was not a breeze by any stretch. 
IIRC it was a IPO (but I could be remembering incorrectly). But to get 
back to MVS the same thing can be said with a SERVPAC. I won't talk too 
much about servpac's as I have already indicated my dislike for them on 
here in the past. The d/l is almost never hard the customization is 
always the gotcha IMO. So please don't say the install is easy as it is 
only about a 1/3 (1/4?) of the job. You are making a broad statement, 
IMO, and putting a broad brush on the effort and thereby making it seem 
like any idiot can do so. This seems to be an effort by IBM (starting in 
the 1990's) that sysprogs are no longer needed. IBM (even in the SERVPAC 
classes) discussed that they are no longer needed that any joe blow can 
do a servpac.


I am not picking on LE but if you take the defaults that LE put out, a 
lot of your batch programs will not work correctly. The same can be said 
for other "optional" customization items that need careful monitoring at 
customization times. Most likely an untrained sysprog would take all the 
defaults. I was training a sysprog at the time of the servpac and I gave 
him the chore to determine which customization jobs were needed and he 
didn't have a clue. Like I said I don't wish to pick on ONE component 
but LE is a good target (sigh).


IBM (and you) seems to be sending out signals that we sysprogs are no 
longer needed. I am lucky to be in retirement and not have to put up 
with this BS from IBM anymore.


we did a lot of work for vm originally on 138/148  besides ecps
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist

there was a lot of investigation trying to make it almost as 
transparently part of the machine as current day LPAR. ... basically 
pre-installed with lots of useability stuff on every machine that went 
out the door


however this was back in the days when corporate still thot they had a 
chance to kill vm ... and while they allowed endicott to ship ecps 
support, the idea that every machine that went out the door had it 
pre-installed was blocked (along with the lots of the usability stuff)


POK had the vm development group in burlington mall shutdown and all the 
people were told they had to move to POK to work on the (internal only) 
VMTOOL supporting mvs/xa development (justification was that mvs/xa 
development couldn't meet schedule unless they had all the vm developers 
working on it also) ... and there would be no more vm products for 
customers. endicott managed to pickup some of the vm370 mission and 
rescue some of the people from having to move to POK (although quite a 
few stayed in the boston area and went to places like DEC to work on 
what was to became VMS).


however, this (138/148) was the leading edge of some companies starting 
to order the boxes in large numbers. this really accelerated in the 
4331/4341 time-frame where it wasn't unusual to have customers ordering 
the boxes in a couple hundred at a time. old reference to one such situation

http://www.garlic.com/~lynn/2001m.html#15 departmental servers

the issue started becoming if the number of machines increase by two 
orders of magnitude (100 times) ... where does the two orders of 
magnitude increase in the number of support people come from?


this period also saw a big explosion in the number of vm/4341s on the 
internal network

http://www.garlic.com/~lynn/subnetwork.html#internal

which was nearly almost all vm machines already. at the time the arpanet 
cutover to internetworking protocol on 1/1/83, there was possibly 100 
arpanet nodes with somewhere between 100 and 255 connected system hosts

http://www.garlic.com/~lynn/subnetwork.html#internet

however the internal network was almost 1000 nodes by that time ... 
almost all vm (and non-sna) machines. a recent thread

http://www.garlic.com/~lynn/2006k.html#40 Arpa address
http://www.garlic.com/~lynn/2006k.html#42 Arpa address
http://www.garlic.com/~lynn/2006k.html#43 Arpa address

vax was also selling into that same mid-range market (as 4331 and 4341).
there was some study that 4341 was better price/performance and a claim 
that something like 11,000 vax sales should have been 4341s ... recent 
post mentioning the subject:

http://www.garlic.com/~lynn/2006l.html#17 virtual memory

however, in that period there was a SHARE study/report that found that a 
lot of customers were buying vax (instead of vm/4341s) because of much 
less resources/skills were needed to install, support and maintain the 
systems (although overall 4331/4341 did still sell more total than vax, 
in part because of large customers ordering them a couple hund

Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Ted MacNEIL]

>So please don't say the  install is easy as it is only about a 1/3 (1/4?) of 
>the job. You are making a broad statement

And, doing the whole thing a disservice.

If IBM keeps claiming complex tasks are simple, when they are not, then how's 
it going to look when the customer finds out the truth?

So, please tell us the real story (and costs) up front, so that we (and you) 
don't like idiots when it fails to meet expectations.

If it is truly so simple, show us how. But, not with high consultation fees 
(another disservice)!


-
-teD

300,000 Kilometres per Second
Not only is it a good idea!
It's the LAW!!!  

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Ed Gould]

On Jun 5, 2006, at 3:14 AM, Timothy Sipples wrote:

Y'all know z/VM installs from DVD, right?  That started about when  
the z800
came out.  It's pretty easy, too.  The second link below has the  
steps, and

there aren't many.  Don't know how the rumor started that z/VM is
difficult.  Quite simply it ain't.  Maybe mainframers are always  
supposed

to say it's difficult then over-deliver? :-)

http://www.vm.ibm.com/install/
http://www.redbooks.ibm.com/abstracts/sg246311.html

To reiterate, about 1,700 mainframe shops have already done this  
(installed

Linux, almost all under z/VM). That's very fast adoption for something
that's about 6 years old.



Timothy:

I profess I have never installed VM (unless you count once 30 years  
ago). That being said, its never the d/l'ing that is the difficult  
part .. its always the "post" downloading that gets to be a PITA and  
always requires some (some say quite a bit) expertise. The VM system  
I helped set up was on a 4331 (w/3310's IIRC) was not a breeze by any  
stretch. IIRC it was a IPO (but I could be remembering incorrectly).  
But to get back to MVS the same thing can be said with a SERVPAC. I  
won't talk too much about servpac's as I have already indicated my  
dislike for them on here in the past. The d/l is almost never hard  
the customization is always the gotcha IMO. So please don't say the  
install is easy as it is only about a 1/3 (1/4?) of the job. You are  
making a broad statement, IMO, and putting a broad brush on the  
effort and thereby making it seem like any idiot can do so. This  
seems to be an effort by IBM (starting in the 1990's) that sysprogs  
are no longer needed. IBM (even in the SERVPAC classes) discussed  
that they are no longer needed that any joe blow can do a servpac.


I am not picking on LE but if you take the defaults that LE put out,  
a lot of your batch programs will not work correctly. The same can be  
said for other "optional" customization items that need careful  
monitoring at customization times. Most likely an untrained sysprog  
would take all the defaults. I was training a sysprog at the time of  
the servpac and I gave him the chore to determine which customization  
jobs were needed and he didn't have a clue. Like I said I don't wish  
to pick on ONE component but LE is a good target (sigh).


IBM (and you) seems to be sending out signals that we sysprogs are no  
longer needed. I am lucky to be in retirement and not have to put up  
with this BS from IBM anymore.


Ed




 


--
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: the "why" of tiered pricing (Was RE: Using Java in batch on z/OS?)

[R.S.]

Charles Mills wrote:


It's true. Also furniture stores don't have to put up with customers who
call and say "Aunt Sally fell off the couch yesterday" and expecting them to
come up with a solution. 


IMHO they care about it. If it is couch failure. The same apply for the 
software. Unless you have such license agreement like MS has. No 
responsibility for anything. Every error is FIN (Fixed If Next release).

Any better maintenance costs some annual fee, doesn't it ?


BTW: In Lodz, the fee for CableTV connection depends on house you live.
For flat (apartment) it much less than for house. It absolutely does not 
depend on the costs of connection. Simply, the bigger house, the more 
rich customer.


--
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: the "why" of tiered pricing (Was RE: Using Java in batch on z/OS?)

[Tom Marchant]

IMHO, the problem is not with tiered pricing, but the fact that mainframes 
are getting more powerful.  At any given time the top of the line mainframe 
is about twice as powerful as the ones available just a couple of years 
ago, so the cost of the software doubles.

z/OS.e costs about a tenth of z/OS, but if you look at the cost of running 
z/OS.e on today's largest processor, it's about as much as it costs to run 
z/OS on the largest processor that was available when z/OS.e was introduced.

The upward creep of software prices is the real problem, and I believe that 
IBM needs to take drastic steps to reduce software costs.  The small steps 
that they have made in adjusting the MSU ratings of the newer processors 
are inadequate.

Tom Marchant

On Sun, 4 Jun 2006 09:30:39 -0300, Shmuel Metz (Seymour J.)  wrote:

>In <[EMAIL PROTECTED]>, on 06/04/2006
>   at 02:18 PM, "R.S." <[EMAIL PROTECTED]> said:
>
>>So, I see you joined the party because of incomes, not because it is
>>more fair model, or other reason. Just - bigger isntallation means
>>more  money to spend. Using this idea bigger datacenters should pay
>>more for  electricity or tape carts (blank).
>
>So should he price the small shops out of the market by setting the
>price too high lose money on development by setting the price too low
>or simply not develop the product so that both the big and the small
>shops lose? Those are his choices.
>
>>Why not ?
>
>They should pay more, but in practice they pay less because of bulk
>discounts. Is that fair?
>
>>I don't want to judge it.
>
>Then stop judging it.
>
>>Sometimes you invest, work hard, but you have no
>>incomes.
>
>And when he finally does get an income you whine about it. He's not
>exerting monopoly powers to extort money like some software vendors;
>in fact, he's not big enough to do so. He's simply trying to set a
>pricing model that allows him to make a reasonable profit on the time
>and money he's invested.
>

--
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: the "why" of tiered pricing (Was RE: Using Java in batch on z/OS?)

[Charles Mills]

It's true. Also furniture stores don't have to put up with customers who
call and say "Aunt Sally fell off the couch yesterday" and expecting them to
come up with a solution. 

Charles



-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Eric N. Bielefeld
Sent: Sunday, June 04, 2006 5:51 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: the "why" of tiered pricing (Was RE: Using Java in batch on
z/OS?)


I think I've used the same argument, but there is a difference between 
software and couches.  Most software companies come out with new releases 
and fixes for problems.  I don't recall a furniture vendor coming out with a

new release of their couch, and then giving it to you.

--
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: Training pricing (was: Re: the "why" of tiered pricing (Was RE: Using Java in batch on z/OS?))

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Steve Comstock
> [snip]
> 
> 
> We have the same problem in pricing training. In fact, just 
> about any non-monopoy business has difficulty setting the 
> "right" price for their products or services.
> 
> We are fanatic about keeping our courses current and in 
> developing new materials as fast as our resources allow. Our 
> competitors don't do that, generally speaking. Instead, they 
> compete on price. And in a market mentality that price is 
> everything, we will lose even if we have the better, more 
> appropriate offering.
> 
> For years we have only offered discount prices in very 
> special circumstances, feeling our prices are fair and 
> competitive. But we find, as one poster in this thread 
> pointed out, management loves to get a "discount" - real or 
> perceived. So we are considering re-structuring our prices 
> then offering discounts, so that the net is about the same 
> but the training coordinator can boast about the discount 
> they got! It's a bit of a sham, but perception is reality 
> today. [Any comments on this strategy?]

The automobile industry has been doing that for years with their
"rebates", which is just a more palatable term than "bribes".  But it
seems to be an acceptable (and accepted) business model, so "go for it."

-jc-

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Timothy Sipples]

Y'all know z/VM installs from DVD, right?  That started about when the z800
came out.  It's pretty easy, too.  The second link below has the steps, and
there aren't many.  Don't know how the rumor started that z/VM is
difficult.  Quite simply it ain't.  Maybe mainframers are always supposed
to say it's difficult then over-deliver? :-)

http://www.vm.ibm.com/install/
http://www.redbooks.ibm.com/abstracts/sg246311.html

To reiterate, about 1,700 mainframe shops have already done this (installed
Linux, almost all under z/VM). That's very fast adoption for something
that's about 6 years old.

Re: Hacking a driver and recompiling the kernel, my response was to the
implication that I didn't know what I was talking about.  On this occasion
anyway, I do. :-)  Those tasks are not required to run Linux, especially
Linux on z.  But someone challenged my geekness, so, you know... :-)

Of course I recognize that there are companies that "don't run Linux."
Allegedly -- there are plenty of companies that do, but the CIO doesn't
know about it.  That's perfectly legal.  Linux is free open source.
However, the number of companies that truly don't run Linux is diminishing
rapidly as Linux's marketshare increases.  IDC pegs Linux server unit
marketshare at 28.3% in 2004 (latest year I could find), and their forecast
is 37.6% for 2008.  The share of companies running one or more Linux
servers is probably higher than these numbers.  Gartner published a survey
earlier this year which suggested that Linux -- including mainframe Linux
-- is the most popular destination OS for database migrations.  (z/OS is
also a popular destination.)

Those marketshare statistics have to be coming from somewhere. To think
Linux isn't popular (and getting moreso) just doesn't make sense.

My general observation is that the Linux market is bifurcated, but that's
changing quickly.  Originally it was very small installations, then it hit
big business.  Now it's spreading into the medium-sized businesses, filling
in the middle.  The U.S. may be slightly behind the rest of the world in
Linux adoption if I had to guess -- but only slightly.

Linux is extremely popular at universities and colleges worldwide.

- - - - -
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: the "why" of tiered pricing (Was RE: Using Java in batch on z/OS?)

[Eric N. Bielefeld]

I think I've used the same argument, but there is a difference between 
software and couches.  Most software companies come out with new releases 
and fixes for problems.  I don't recall a furniture vendor coming out with a 
new release of their couch, and then giving it to you.


Eric Bielefeld
Sr. z/OS Systems Programmer
Milwaukee Wisconsin
414-475-7434

- Original Message - 
From: "Charles Mills" <[EMAIL PROTECTED]>


The MIPS pricing model is terrible - it's just the best model we had. I 
used

to give the example that you buy a couch for $500. Several years later you
add a new bedroom onto your house - and the furniture store calls you up 
and

says that now that your house has more square feet, you owe them another
$100 for the couch.

Charles 


--
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: Training pricing (was: Re: the "why" of tiered pricing (Was RE: Using Java in batch on z/OS?))

[Charles Mills]

> Any comments on this strategy?

Marketing is all about giving customers what they want. Take a walk around
the mall. Customers obviously LOVE "x% off." Ignore all the engineers saying
"no we don't" (they actually do; they just are very good self-psychologists)
and "x% off of what?" (off the bad old no discount price, of course ).

Charles



-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Steve Comstock
Sent: Sunday, June 04, 2006 9:55 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Training pricing (was: Re: the "why" of tiered pricing (Was RE:
Using Java in batch on z/OS?))

For years we have only offered discount prices in very special
circumstances, feeling our prices are fair and competitive. But
we find, as one poster in this thread pointed out, management
loves to get a "discount" - real or perceived. So we are
considering re-structuring our prices then offering discounts,
so that the net is about the same but the training coordinator
can boast about the discount they got! It's a bit of a sham, but
perception is reality today. [Any comments on this strategy?]

--
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: the "why" of tiered pricing (Was RE: Using Java in batch on z/OS?)

[Dave Salt]

Charles Mills wrote:

whereas the first time a big shop, upon being quoted the price said "is
that one-time or per-month?" I realized I was leaving a heck of a lot of
money on the table with the big shops.

So I quickly joined the party and went to tiered (or as it was called 
then, "group") pricing.


"R.S." <[EMAIL PROTECTED] wrote:


So, I see you joined the party because of incomes, not because it is more 
fair model, or other reason. Just - bigger isntallation means more money to 
spend. Using this idea bigger datacenters should pay more for electricity 
or tape carts (blank). Why not ?


Bigger datacenters DO pay more for electricity, don't they? Bigger machines 
usually require more electricity, which costs more to run them. There is no 
electricity company I know of that charges a flat fee for a 'datacenter', 
regardless of size. Instead, they say "you use this much KWH, we charge you 
this much. You use this much KWH, we charge you this much", and so on.


On a PC, software is frequently licensed by number of users. If a company 
wants 1 copy of the MicroFocus workbench, it costs this much; if they want 
10 copies, it costs this much. Why should mainframe software cost a single 
flat fee, regardless of how many people use it?


Having said that, I don't practice what I preach. As an ISV, I sell a 
mainframe software product to North American customers at a single flat fee 
of 5K per year. This amount is charged regardless of the size, speed, or 
number of users on the customers mainframe. However, I struggle with whether 
this is fair. If a small company has 10 programmers, their 5K investment 
should net them an annual saving of somewhere between 50K to 100K (i.e. 
roughly the cost of hiring an additional programmer). If they have 100 
programmers, their 5K investment should net them a saving of anywhere from 
half a million to one million dollars a year. Does this seem fair?


Several years ago I heard a competing product was being licensed to a large 
company for 200K per year. While 200K might seem like a lot of money, the 
company had well over 1,000 programmers. If the competing product generates 
similar productivity savings to the ones I've just mentioned, this means the 
200K investment would save the company anywhere from 5 to 10 million dollars 
a year. This seems like a tremendous return on investment, but smaller 
companies can't afford to pay 200K per year. So, does this mean smaller 
companies wouldn't be able to license the software? Of course not; thanks to 
tiered pricing, smaller companies would be charged a lot less money. In this 
sense, tiered pricing seems to make things more fair, not less fair.


For me, I'm still struggling with the whole pricing issue. The current flat 
rate of 5K per year doesn't generate enough revenue, so should I increase 
the flat rate for everyone, or should I keep it low for smaller customers 
and increase it for bigger customers? If bigger customers are charged more 
money, what would the increase be based on; MSUs? Seats? Concurrent usage? 
(Note: The idea of locking people out of software just because 'x' number of 
people are already using it doesn't seem very appealing to me).


It would be nice to have a pricing structure that everyone agrees is fair, 
but I honestly don't know what the answer is. And when I see messages posted 
on IBM-MAIN about the unfairness of tiered pricing, it just makes the entire 
decision that much more difficult.


If anyone has opinions or suggestions on this subject and would like the 
opportunity to influence an ISV, here's your chance. Please feel free to 
contact me off-list if you prefer.


Regards,

Dave Salt
SimpList(tm) - The easiest, most powerful way to surf a mainframe!
http://www.mackinney.com/products/SIM/simplist.htm

--
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: the "why" of tiered pricing (Was RE: Using Java in batch on z/OS?)

[R.S.]

Charles Mills wrote:

bigger datacenters should pay more for electricity 



Well, yes, they probably do. Not more per kwh, but more in total. Less per
kwh, but more in total. And that's how most MIPS charging works also, I
believe.

As I more-or-less said in my last para., no one thinks anyone should pay
more, but most think some should pay less. Unfortunately, some paying more
is a necessary corollary of some paying less.



you joined the party because of incomes, not because it is more fair model



You bet! And yes, I thought I was quite frank in my first post about how
yes, we were "looking for more efficient ways of extracting money from
customers." It sounds like a bad thing when you phrase it that way, but we
were in that business, we had significant expenses, and were not - if you
look at the month-to-month picture - consistently profitable or consistently
cash flow positive. We needed money from customers to survive, and I think
greater efficiency is generally a good thing.


Charles,
I explicitly noted: I dont't judge it. I just wanted to say that tiered 
pricing is a way to get more money from customers. Dot. I never said 
it's bad. Last but not least: your software is *your own*. You decide 
how to sell it. You can make the price higher for fat guys if you want. 
Oh, in political correct world you can make discounts for thins. 

Or you can make the prices higher for european customers (IBM do).
Your product, your business, your choice.

However, on the other side, customers sometimes don't see any 
relationship between the price and the prodduct. In most cases it affect 
MSU-based pricing, where the product itself have very little to do with 
the number of MIPS. Some sysprog facilities would be well-justified when 
related to number of concurrent users (good old pricing model of Novell).
Sometimes I simply don't know what pricing model would be good, and even 
software venedors do not know (or, at leat, they change their mind).


Regards
--
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: the "why" of tiered pricing (Was RE: Using Java in batch on z/OS?)

[Ed Gould]

On Jun 4, 2006, at 11:24 AM, Charles Mills wrote:


he bigger you are the more JCL errors you have?


Probably, generally speaking, I would think so, yes.

Charles



I cannot prove this but I have observed that this is not the case.  
The bigger the company the fewer JCL errors. The smaller companies  
tend to hire (IMO) less experienced  personnel. I have taught JCL  
courses at small companies and they tend to have less than lets say  
talented people, IMO.


Ed

--
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: the "why" of tiered pricing (Was RE: Using Java in batch on z/OS?)

[Jeffrey D. Smith]

=
-Original Message-
From: "Charles Mills" <[EMAIL PROTECTED]>
Sent: 6/4/2006 10:35 AM
To: "IBM-MAIN@BAMA.UA.EDU" 
Subject: Re: the "why" of tiered pricing (Was RE: Using Java in batch on z/OS?)

> bigger datacenters should pay more for electricity 

Well, yes, they probably do. Not more per kwh, but more in total. Less per
kwh, but more in total. And that's how most MIPS charging works also, I
believe.

As I more-or-less said in my last para., no one thinks anyone should pay
more, but most think some should pay less. Unfortunately, some paying more
is a necessary corollary of some paying less.

> you joined the party because of incomes, not because it is more fair model

You bet! And yes, I thought I was quite frank in my first post about how
yes, we were "looking for more efficient ways of extracting money from
customers." It sounds like a bad thing when you phrase it that way, but we
were in that business, we had significant expenses, and were not - if you
look at the month-to-month picture - consistently profitable or consistently
cash flow positive. We needed money from customers to survive, and I think
greater efficiency is generally a good thing.

While we're on the topic, the "right" way to charge more IMHO is to charge
for something that parallels the business benefit. We were a file transfer
product. I would have liked to have charged by the megabyte, not by the MSU,
but we had no rigorous and enforceable way of doing so - plus we would have
been a small company fighting the industry "standard" which is seldom a good
thing. The sales guys say "when you explain, you lose."

The MIPS pricing model is terrible - it's just the best model we had. I used
to give the example that you buy a couch for $500. Several years later you
add a new bedroom onto your house - and the furniture store calls you up and
says that now that your house has more square feet, you owe them another
$100 for the couch.

Charles
=
Greetings,

1.  Charge by machine size: The implication is that a bigger machine
means that your product is used more. Thus, the business benefit
somehow correlates to the machine size. This is a dinosaur, but
still widely used because it's simple accounting, but not fair.

Downside: Someone, either the software vendor or the customer, is
benefitting at the expense of the other, because there is no accurate
measurement of benefit or actual usage. It's just a guess that there is
some correlation of machine size with usage/benefit.

2.  Charge by transaction. More transactions means more business
benefit, thus your customer pays for higher usage that correlates
to the benefit.

Downside: How to account for the transactions in a non-intrusive,
yet accurate manner? Monthly SMF reports or custom reports sent
to the vendor? Tedious and error prone. Automatic TCP/IP transfer
of accounting from customer to vendor? Some sites may have security
concerns with this approach. Also, a "spike" in usage may cause an
unpleasant invoice to appear without warning.

May use a "governor server" that limits the number of transactions
per second/minute/day/whatever. When the limit is reached, subsequent
transactions are delayed to limit the throughput. The governor must
be aware of "hot" and "cold" times for transactions (multiple service
limits through-out the day, week, month, etc.), instead of using "one
size fits all" transaction limit. A phone call to the vendor (or an
on-line web page) to order a higher transaction limit can increase
capacity in just a few minutes. The governor may even be configured
to increase capacity, within pre-defined guidelines, by automatically
contacting the vendor website to avoid service delays.

3.  Charge per seat: For human-interactive products, like a debugger,
more concurrent users means more business benefit. Like renting
a delivery truck to send stuff to Phoenix. If you also want to send
stuff to Portland, you must wait for the truck to return from Phoenix,
or rent another truck and concurrently send stuff to both places (and
pay for two trucks instead of one).

Concurrency can be measured through various means, including global
enqueues or TCP/IP-connected servers that manage floating licenses.
When the limit is reached, no new sessions can start until some
sessions end. A quick call to the vendor (or an on-line web page) to
order more seats can increase capacity in just a few minutes. The
floating license manager could be configured to increase capacity
by automatically contacting the vendor website.

Downside: Applicable to human-interactive products and difficult
to extend to "behind the scenes" products (like automatic compression
or encryption services -- see item [2]).


All of the abo

Re: Training pricing (was: Re: the "why" of tiered pricing (Was RE: Using Java in batch on z/OS?))

[Marian Gasparovic]

There are companies, where people responsible for purchasing are
measured(!) by discounts they get. So if you want to sell them
something for $1,000, you say the list price is $5,000 and give them
80% discount. I saw several such situations at my previous job.

Marian Gasparovic

On 6/4/06, Steve Comstock <[EMAIL PROTECTED]> wrote:

R.S. wrote:
[snip]

> What pricing model is fair ?
> I don't know. However I know, what is reality: it is necessary to fing
> competitive vendor, get their offer, including migration assistance, and
> re-negotiate the original agreement. Result: 1/3 of original price. In
> fact, I don't care what pricing model they prefer, how many programmers
> they hire, especially how many sales specialists have income from my
> account. Competition gives me reasonable prices, because I have an
> alternative.
>

But then you get into today's mentality: everything is price,
nothing is quality.

We have the same problem in pricing training. In fact, just
about any non-monopoy business has difficulty setting the
"right" price for their products or services.

We are fanatic about keeping our courses current and in developing
new materials as fast as our resources allow. Our competitors don't
do that, generally speaking. Instead, they compete on price. And
in a market mentality that price is everything, we will lose even
if we have the better, more appropriate offering.

For years we have only offered discount prices in very special
circumstances, feeling our prices are fair and competitive. But
we find, as one poster in this thread pointed out, management
loves to get a "discount" - real or perceived. So we are
considering re-structuring our prices then offering discounts,
so that the net is about the same but the training coordinator
can boast about the discount they got! It's a bit of a sham, but
perception is reality today. [Any comments on this strategy?]

Actually, playing mental games with it is kind of fun. Suppose
we set our daily rate at x_dollars, then how many different
discounts can we offer so that the net is y_dollars? What do
you base discounts for training on? New client rates, first
time a course is taught rates, bulk training rates, preferred
client rates, small class size rates, large class size rates,
???

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: the "why" of tiered pricing (Was RE: Using Java in batch on z/OS?)

[Edward Jaffe]

Charles Mills wrote:

The MIPS pricing model is terrible - it's just the best model we had. I used
to give the example that you buy a couch for $500. Several years later you
add a new bedroom onto your house - and the furniture store calls you up and
says that now that your house has more square feet, you owe them another
$100 for the couch.
  


Not quite. Mainframes are highly scalable, so the number of footprints 
doesn't tell the proper story.


Imagine a company with 50 employees that has 50 desktop PCs and a 100 
MIPS mainframe. They have 50 copies of Windows and associated software 
and one copy of z/OS and associated software. Being successful, they 
increase their business and their IT staff by 50%. They now have 75 
desktop PCs and a 150 MIPS mainframe. They now have 75 copies of Windows 
and associated software and still only one copy of z/OS and associated 
software. Does anyone reading this actually believe there be no upgrade 
fee for the mainframe software?


By paying more for z/OS and associated software on the 150 MIPS machine, 
they keep the mainframe software business as profitable as the PC 
software business. Without _some_ sort of tiered pricing structure, IBM 
and everyone else in the software business would have abandoned the 
mainframe platform long ago...


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.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

Training pricing (was: Re: the "why" of tiered pricing (Was RE: Using Java in batch on z/OS?))

[Steve Comstock]

R.S. wrote:
[snip]


What pricing model is fair ?
I don't know. However I know, what is reality: it is necessary to fing 
competitive vendor, get their offer, including migration assistance, and 
re-negotiate the original agreement. Result: 1/3 of original price. In 
fact, I don't care what pricing model they prefer, how many programmers 
they hire, especially how many sales specialists have income from my 
account. Competition gives me reasonable prices, because I have an 
alternative.




But then you get into today's mentality: everything is price,
nothing is quality.

We have the same problem in pricing training. In fact, just
about any non-monopoy business has difficulty setting the
"right" price for their products or services.

We are fanatic about keeping our courses current and in developing
new materials as fast as our resources allow. Our competitors don't
do that, generally speaking. Instead, they compete on price. And
in a market mentality that price is everything, we will lose even
if we have the better, more appropriate offering.

For years we have only offered discount prices in very special
circumstances, feeling our prices are fair and competitive. But
we find, as one poster in this thread pointed out, management
loves to get a "discount" - real or perceived. So we are
considering re-structuring our prices then offering discounts,
so that the net is about the same but the training coordinator
can boast about the discount they got! It's a bit of a sham, but
perception is reality today. [Any comments on this strategy?]

Actually, playing mental games with it is kind of fun. Suppose
we set our daily rate at x_dollars, then how many different
discounts can we offer so that the net is y_dollars? What do
you base discounts for training on? New client rates, first
time a course is taught rates, bulk training rates, preferred
client rates, small class size rates, large class size rates,
???

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: the "why" of tiered pricing (Was RE: Using Java in batch on z/OS?)

[Charles Mills]

> bigger datacenters should pay more for electricity 

Well, yes, they probably do. Not more per kwh, but more in total. Less per
kwh, but more in total. And that's how most MIPS charging works also, I
believe.

As I more-or-less said in my last para., no one thinks anyone should pay
more, but most think some should pay less. Unfortunately, some paying more
is a necessary corollary of some paying less.

> you joined the party because of incomes, not because it is more fair model

You bet! And yes, I thought I was quite frank in my first post about how
yes, we were "looking for more efficient ways of extracting money from
customers." It sounds like a bad thing when you phrase it that way, but we
were in that business, we had significant expenses, and were not - if you
look at the month-to-month picture - consistently profitable or consistently
cash flow positive. We needed money from customers to survive, and I think
greater efficiency is generally a good thing.

While we're on the topic, the "right" way to charge more IMHO is to charge
for something that parallels the business benefit. We were a file transfer
product. I would have liked to have charged by the megabyte, not by the MSU,
but we had no rigorous and enforceable way of doing so - plus we would have
been a small company fighting the industry "standard" which is seldom a good
thing. The sales guys say "when you explain, you lose."

The MIPS pricing model is terrible - it's just the best model we had. I used
to give the example that you buy a couch for $500. Several years later you
add a new bedroom onto your house - and the furniture store calls you up and
says that now that your house has more square feet, you owe them another
$100 for the couch.

Charles



-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of R.S.
Sent: Sunday, June 04, 2006 5:18 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: the "why" of tiered pricing (Was RE: Using Java in batch on
z/OS?)


Charles Mills wrote:
[...]
> whereas the first time a big shop, upon being quoted the price, said "is
> that one-time or per-month?" I realized I was leaving a heck of a lot of
> money on the table with the big shops.
> 
> So I quickly joined the party and went to tiered (or as it was called
then,
> "group") pricing.

So, I see you joined the party because of incomes, not because it is 
more fair model, or other reason. Just - bigger isntallation means more 
money to spend. Using this idea bigger datacenters should pay more for 
electricity or tape carts (blank). Why not ?
IBM delivers 8-CP machine, but the CPs are disabled, unless you pay for it.
Disclaimer: I don't want to judge it. I just observe.

--
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: the "why" of tiered pricing (Was RE: Using Java in batch on z/OS?)

[Charles Mills]

> he bigger you are the more JCL errors you have? 

Probably, generally speaking, I would think so, yes.

Charles



-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Ed Gould
Sent: Sunday, June 04, 2006 7:13 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: the "why" of tiered pricing (Was RE: Using Java in batch on
z/OS?)


On Jun 4, 2006, at 7:18 AM, R.S. wrote:

> -SNIP---
> It wasn't my question, however I think you didn't answered why  
> bigger installation should pay more. In my opinion MSU-based fee is  
> sometimes justified, while sometimes is not.
> Examples:
> (justified) DB2, CICS - you make more transactions, more workload,  
> you pay more. But you *USE* the software more.
> (not justified IMHO). Debugger. Assumed you use it on development  
> LPAR, but you have to pay for total MSU. You production grows up,  
> while development not. Your fees grows up, but not the usage. In  
> fact VWLC changed the scenario significantly.
>
So,. The bigger you are the more JCL errors you have? ... h I  
don't think so.

--
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: the "why" of tiered pricing (Was RE: Using Java in batch on z/OS?)

[R.S.]

Edward Jaffe wrote:


Ed Gould wrote:

So,. The bigger you are the more JCL errors you have? ... h I 
don't think so.



It's likely that a bigger company, with a bigger IT staff, will submit 
more jobs and experience more JCL errors.


I don't see correspondence between JCL errors and pricing model, but my 
example - debugger on one LPAR (no growth) and growing production is 
real one. There are more examples like that, i.e. some company tries to 
charge job scheduler per job being scheduled. As an alternative they 
purpose per MIPS price. I know company which grew up from 100 MIPS to 
1800 MIPS, but the number of jobs grew up by less than 50 %.

What pricing model is fair ?
I don't know. However I know, what is reality: it is necessary to fing 
competitive vendor, get their offer, including migration assistance, and 
re-negotiate the original agreement. Result: 1/3 of original price. In 
fact, I don't care what pricing model they prefer, how many programmers 
they hire, especially how many sales specialists have income from my 
account. Competition gives me reasonable prices, because I have an 
alternative.


Todays' PC industry charges "per seat" or "per computer" for most 
things. If Windows XP runs on every desktop in an organization, the 
number of copies purchased by a large company will generate 
proportionally more revenue for Microsoft than the number of copies 
purchased by a small company.


I think, MS pricing model is quite unique. Vast majority of Win licenses 
sold are OEM licenses. So in fact they charge PC vendor per number of 
PCs sold, doesn't matter what will be used on that PC - Linux, OS/2 or 
anything else. You pay the bucks for the sticker on enclosure.

However majority of PC software is charged per installation (per PC).
It is also worth to mention Oracle pricing model: per processor. It is 
quite silly IMHO, since they AFAIK count each processor equally: it can 
be z9 IFL, or PowerPC, or Alpha AXP, or PA-RISC, or SPARC. The problem 
is to get similar computing (and DB) power different numbers of 
processors are required. As a result, some platforms are favoured over 
others. Definitely not a goal of Oracle.


Last but not least: Software expenses are growing part of IT budget, 
while hardware partis shrinking.



--
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: the "why" of tiered pricing (Was RE: Using Java in batch on z/OS?)

[Edward Jaffe]

Ed Gould wrote:
So,. The bigger you are the more JCL errors you have? ... h I 
don't think so.


It's likely that a bigger company, with a bigger IT staff, will submit 
more jobs and experience more JCL errors.


Todays' PC industry charges "per seat" or "per computer" for most 
things. If Windows XP runs on every desktop in an organization, the 
number of copies purchased by a large company will generate 
proportionally more revenue for Microsoft than the number of copies 
purchased by a small company.


IBM tried to come up with something similar for mainframes by assuming 
that larger companies had larger mainframe computing needs. For the 
most-part, their assumption was correct. The graduated discounts allowed 
companies of all sizes to run their businesses on a mainframe. It seemed 
to make sense at the time. In many ways, it still does.


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.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: the "why" of tiered pricing (Was RE: Using Java in batch on z/OS?)

[Ed Gould]

On Jun 4, 2006, at 7:18 AM, R.S. wrote:


-SNIP---
It wasn't my question, however I think you didn't answered why  
bigger installation should pay more. In my opinion MSU-based fee is  
sometimes justified, while sometimes is not.

Examples:
(justified) DB2, CICS - you make more transactions, more workload,  
you pay more. But you *USE* the software more.
(not justified IMHO). Debugger. Assumed you use it on development  
LPAR, but you have to pay for total MSU. You production grows up,  
while development not. Your fees grows up, but not the usage. In  
fact VWLC changed the scenario significantly.


So,. The bigger you are the more JCL errors you have? ... h I  
don't think so.



Ed

--
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: the "why" of tiered pricing (Was RE: Using Java in batch on z/OS?)

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 06/04/2006
   at 02:18 PM, "R.S." <[EMAIL PROTECTED]> said:

>So, I see you joined the party because of incomes, not because it is 
>more fair model, or other reason. Just - bigger isntallation means
>more  money to spend. Using this idea bigger datacenters should pay
>more for  electricity or tape carts (blank).

So should he price the small shops out of the market by setting the
price too high lose money on development by setting the price too low
or simply not develop the product so that both the big and the small
shops lose? Those are his choices.

>Why not ?

They should pay more, but in practice they pay less because of bulk
discounts. Is that fair?

>I don't want to judge it.

Then stop judging it.

>Sometimes you invest, work hard, but you have no 
>incomes.

And when he finally does get an income you whine about it. He's not
exerting monopoly powers to extort money like some software vendors;
in fact, he's not big enough to do so. He's simply trying to set a
pricing model that allows him to make a reasonable profit on the time
and money he's invested.

-- 
 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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 06/04/2006
   at 02:35 PM, james smith <[EMAIL PROTECTED]> said:

>One client even mentioned running z/OS under z/VM until 'the penny
>dropped' and he realized a) he had no z/VM expertise on-site and b)
>that no reasonable level of z/VM support was available in-country. 

What country?
 
-- 
 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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[R.S.]

Timothy Sipples wrote:

[...]

FWIW, I'm typing this e-mail from my Linux PC. I installed it. I even
hacked some driver source code, recompiled it, and recompiled my kernel to
get a special wireless card working. 


That's why Linux is not as popular as Windows on home&office computers. 
My secretary is not able to hack some driver source code and compile it. 
However she wants to send & receive mails, print Word documents etc.
Even IT folks prefer Windows here. I mean all the helpdesk stuff and 
'one man band IT dept' in small companies.
Of course there are exceptions, sometimes single Linux specialist can 
set up small company IT environment on Linux and everybody will be happy 
of that. But it is uncommon in my observation.


--
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: the "why" of tiered pricing (Was RE: Using Java in batch on z/OS?)

[R.S.]

Charles Mills wrote:
[...]

whereas the first time a big shop, upon being quoted the price, said "is
that one-time or per-month?" I realized I was leaving a heck of a lot of
money on the table with the big shops.

So I quickly joined the party and went to tiered (or as it was called then,
"group") pricing.


So, I see you joined the party because of incomes, not because it is 
more fair model, or other reason. Just - bigger isntallation means more 
money to spend. Using this idea bigger datacenters should pay more for 
electricity or tape carts (blank). Why not ?

IBM delivers 8-CP machine, but the CPs are disabled, unless you pay for it.
Disclaimer: I don't want to judge it. I just observe.

[...]

There were months I worked
12 hours a day six days a week and was $50,000 poorer at the end of the
month than I was at the beginning. I don't care how crappy your job is, I'll
bet it's a better deal than that. 


It is definitely *not* software company specificity! It is specificity 
of business at all. Sometimes you invest, work hard, but you have no 
incomes.


[...]

Does this answer your question? The answer really is in the first paragraph;
the rest of it is just a long digression on the software business.


It wasn't my question, however I think you didn't answered why bigger 
installation should pay more. In my opinion MSU-based fee is sometimes 
justified, while sometimes is not.

Examples:
(justified) DB2, CICS - you make more transactions, more workload, you 
pay more. But you *USE* the software more.
(not justified IMHO). Debugger. Assumed you use it on development LPAR, 
but you have to pay for total MSU. You production grows up, while 
development not. Your fees grows up, but not the usage. In fact VWLC 
changed the scenario significantly.


--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[james smith]

I saw some clients up here demonstrate an initial interest after the first
'sales pitch'.  Once it dawned on them that installing z/VM to host linux
wasn't quite the same as installing windoze the interest waned  

One client even mentioned running z/OS under z/VM until 'the penny dropped'
and he realized a) he had no z/VM expertise on-site and b) that no
reasonable level of z/VM support was available in-country.  

Jim S

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Shane
Sent: 03 June 2006 18:39
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

On Sat, 2006-06-03 at 07:23 +0900, Timothy Sipples wrote:

> Mark Zelden writes:
> >No brainer?   How about the staff, time, learning curve, etc.
> >to support an operating system and environment that is
> >new to the shop?
> 
> Three points:
> ...
> Three more points:

I'm with Mark.
My customers say z/Linux isn't on the horizon. In fact most of them say
mainframe is not in their future.
Those that are (planning) getting off the mainframe are talking M$oft -
*NOT* linux; on any platform.
They *will not* consider a conversion to Linux. No training, no wasted
investment, no interest.
Period.

Having techos (me included) dicking around with Linux on PCs counts for
zero.

Shane ...

--
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: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Shane]

On Sat, 2006-06-03 at 07:23 +0900, Timothy Sipples wrote:

> Mark Zelden writes:
> >No brainer?   How about the staff, time, learning curve, etc.
> >to support an operating system and environment that is
> >new to the shop?
> 
> Three points:
> ...
> Three more points:

I'm with Mark.
My customers say z/Linux isn't on the horizon. In fact most of them say
mainframe is not in their future.
Those that are (planning) getting off the mainframe are talking M$oft -
*NOT* linux; on any platform.
They *will not* consider a conversion to Linux. No training, no wasted
investment, no interest.
Period.

Having techos (me included) dicking around with Linux on PCs counts for
zero.

Shane ...

--
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

Pricing model (Was: Using Java in batch on z/OS?)

[Wade Curry]

R.S.([EMAIL PROTECTED])@Fri, Jun 02, 2006 at 10:25:01PM +0200:
> 
> IMHO the truth is in the middle. It is wise to encourage people
> to *start using mainframe* - that's why the price for the special
> engines is low. It is also wise to keep current incomes from
> legacy users unaffected - that's why regualr CP's are still
> expensive and subject to software fees (MSU base).  The idea is
> clear: if you want to run Linux, then you have a choice, you are
> not doomed to mainframe. So, IBM want to make z/Platform more
> attractive. Effect: IFL.  Similar idea for JAVA workload, since
> JAVA is (more or less) platform independent.  Similar approach
> for DB2 "modern" workload. Can be done on unix or windows.
> COMPETITION.  Obviously old fat stinking IMS/CICS/COBOL/VSAM
> users pay the bucks at regular prices, because they have no
> choice. Migration is hard, expensive and failure-prone. They pay
> for regular CPs and MSU-based MLC.

I don't know what MLC and MSU stand for, but I assume they refer to
the hardware pricing scheme.  You have included the issue of
software fees, though, which I know even less about.

I'm surprised by the "fat old stinking" label.  At my shop we have
IMS, CICS, COBOL, and VSAM.  I was under the impression that the
vast majority of mainframe installations use either IMS or CICS,
and probably both COBOL and VSAM.  There's no question that they
are old, and ubiquity doesn't necessarily prove they don't
stink.  I've just never heard a mainframer describe them in that
fashion, so I'm hoping you'll elaborate.

At the very least, I find it difficult to describe what an
installation with a modern workload would look like.  I guess an
installation that exclusively used VM and Linux might qualify as at
least non-traditional.  Is that configuration common at all?  What
other options are there for z/OS shop, though? - even a newer one?
I can imagine an installation leaving out COBOL in favor of C/C++.
I would guess, though, that it is not incredibly popular or cheap
to buy an installation without either IMS or CICS.  Writing
entirely new online transaction/data connection frameworks for new
applications seems like more expense and work than most companies
would want to take on when there are already two well-known
products available.

> However, these 'traditional' users also think how to reduce the
> costs.  One of the ideas is to move some workload to special
> engines.  IMHO JAVA is not the best choice for batch processing.
> For sure, it is technically senseless to migrate from existing
> (*working*), usually COBOL-based batch to JAVA.  It is a signal
> to IBM: something goes wrong, maybe we should tune the pricing
> model.
> 

Wade Curry

--
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

Tiered Pricing (Was: Using Java in batch on z/OS?)

[Edward Jaffe]

Wade Curry wrote:

if you (John) or anyone else really does understand the "why" of
tiered pricing (beyond just having an efficient way to extract
money) I'd really like to hear it.  That sounded sufficiently
sarcastic that I probably need to say that this is a serious
question.  Did/does IBM perceive a benefit to the *customer* as a
result of tiered pricing... past or present?  I've been in the
mainframe world for 4 years, and that lack of exposure/experience
is showing, I'm afraid.
  


Tiered pricing was a way to introduce graduated discounts to small 
companies that didn't have the big budgets found in big companies. The 
idea was simple: the smaller your computing environment, the lower your 
software bill. This provided attractive entry-level pricing for small 
companies and, as they grew their businesses and presumably the size of 
their computing environments, their discounts would slowly erode until 
they were paying the same "full" price paid by the other large 
mega-companies.


In a sense, this mechanism still works today. Two companies, one small; 
one big, running the identical software stack, will be paying radically 
different prices -- with the smaller company paying the lower price in 
every case.


The real mistake was in adopting a fixed price/MIPS schedule, rather 
than one that was indexed to annual "MIPS inflation". The machines we 
ran back then were much, much, _much_ slower than today's machines. Many 
had MIPS ratings in the single digits. (Heck, I remember some that were 
rated using _fractional_ MIPS amounts!) Fast-forward to 2006 where the 
z9EC uniprocessor grinds out around 580 MIPS! The price curve went 
through the roof and they've been trying to come up with various clever 
(and not so clever) ways to fix it ever since...



Frankly, pricing per MIPS sounds fundamentally unethical to me.
But since I've never been involved in purchasing a mainframe, I
can't say I see the big picture.  I still see it as the purchase of
a large asset, like a house.  No one would charge you $10,000 less
if you promise to brick-off the door to the second or third
bedroom. And actually, I'm assuming the price/MIPS is a recurring
fee.  Perhaps it's just an up-front pricing scheme to induce a
company to upgrade with at least a "partial" CP?
  


Outside the mainframe environment, you will something similar. Often, 
software is priced by the number of processors on the machine. One 
processor: one price; two processors: another price; etc. That's a 
better model because it keeps up with speed improvements in the 
hardware, but it's still based on capacity, size, and need.


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.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

the "why" of tiered pricing (Was RE: Using Java in batch on z/OS?)

[Charles Mills]

> if you (John) or anyone else really does understand the "why" of tiered
pricing

I'll be happy to. In 1988 I wrote a mainframe product and brought it to
market. In my naïveté, I decided to price it at $24,000 – one size fits all.
I quickly found that it was priced way out of the market for small firms –
whereas the first time a big shop, upon being quoted the price, said "is
that one-time or per-month?" I realized I was leaving a heck of a lot of
money on the table with the big shops.

So I quickly joined the party and went to tiered (or as it was called then,
"group") pricing.

It's easy to say "beyond just having an efficient way to extract money" like
it was a bad thing but yeah, that's the business we were in, we supply
software and the customer sends us money. I had a programmer who used to
give me an occasional lecture on how software should be free. I told him
that as soon as he was willing to start working for free, I would consider
making our software free. Oh, and he also had to convince the landlord and
the electric company of the joys of doing it for free.

Being in the software business is not to be able to take money to the bank
by the wheelbarrow load. If it were, there would be more mainframe software
companies, wouldn't there? More software companies in general, for that
matter. Software is a funny business. I used to say we were in the business
of selling $8 tapes for $24,000. Of course, I was paying a lot of guys and
gals $50K to $100K per year whether I sold any software or not. I was
running expensive adds in ESJ that I had to pay for whether I sold any
software or not. The easiest business to be in is one in which you buy
widgets for $5 and sell them for $10. It's a lot harder to be in a business
in which you pay programmers $100K to turn $8 tapes into software that you
might or might not be able to sell for $24,000. There were months I worked
12 hours a day six days a week and was $50,000 poorer at the end of the
month than I was at the beginning. I don't care how crappy your job is, I'll
bet it's a better deal than that. There were two points where things were so
bleak I seriously considered just locking the door and walking away. So yes,
we welcomed more efficient ways of extracting money from the customer.

By the way, shortly before I sold the company (and don't get me wrong –
everything worked out very well for me in the long run – I have no
complaints) I came up with an idea that I don't know why more software
companies don't take up. Everyone likes to pay less; no one likes to pay
more. So instead of saying our product is $10,000 for a Group 20, and $5,000
more for a Group 30, and so forth, we said "the product is $100,000. Oh, you
have a Group 50? Then you qualify for a 50% discount. You have a Group 40?
You qualify for a 65% discount. And so forth." The customers seemed to love
it. "Hey boss, I bought it for 65% off!"

Does this answer your question? The answer really is in the first paragraph;
the rest of it is just a long digression on the software business.

Charles

--
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

Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

[Timothy Sipples]

Mark Zelden writes:

>No brainer?   How about the staff, time, learning curve, etc.
>to support an operating system and environment that is
>new to the shop?

Three points:

1. If you aren't running Linux now...well, check your TiVo and your Linksys
router. :-) Seriously, Linux is not exactly uncommon and getting more
common.

2. Usually paid for. (Does z/OS work more or less hard when requests arrive
via HiperSocket v. network? What might the response time be like for each
scenario? How about security, reliability, availability, etc?)

3. That support has got to go somewhere today, even if it is familiar. Is
it easier or harder to support lots of little servers? Lots of smart people
think it's harder. There's also DB2 support to consider. How many calls
start with "the database is slow -- it's the mainframe's fault" or "I can't
connect -- it's the mainframe's fault"? :-)

>While there may be *nix people that could
>support Linux or help support it, it's probably not just Linux
>that would be new, it's also z/VM.

Three more points:

1. z/VM is not required to run Linux. It's awfully nice but not required.
For a "couple or three" Linux instances, you could go without.

2. Getting sufficient z/VM knowledge to run Linux is really not a big deal.
IBM thought it was about 6 years ago and released a Linux-only virtual
machine product, but it flopped. Nobody could tell the difference in
learning curve. IBM thinks there are about 1,700 mainframe customers
actually running Linux in production. That's some evidence this stuff isn't
like building a fusion reactor.

3. To know z/OS these days you have to know USS. That's a skill set that
works well for Linux, too.

>I'm not saying using Linux on z is a bad idea, but you really tend
>to over simplify things and look at things like a salesman, not a
>technician.

I wish! Sadly I don't get commissions.

FWIW, I'm typing this e-mail from my Linux PC. I installed it. I even
hacked some driver source code, recompiled it, and recompiled my kernel to
get a special wireless card working. I've also installed and IPLed Linux
under z/VM, and installed and configured software products on Linux under
z/VM -- for a major bank, as it happens. Yeah, it's easy. Why, even a
salesman can do it. :-)

Generally good choices to run on mainframe Linux (z/OS also of course great
for many of these as well):

- DB2 Connect
- "Utility" servers (DHCP, DNS, NTPD, LDAP, etc.)
- SAP and other data-intensive LOB applications (that can enjoy
HiperSockets to DB2 z/OS, CICS, IMS, etc.)
- File servers (Samba, NFS)
- Certain security services (e.g. Tivoli Access Manager for e-business)
- Monitoring-related software (e.g. Tivoli Enterprise Console)
- Lotus Domino (and other e-mail servers)
- Rational ClearCase/ClearQuest, CVS, etc.
- other servers to support application development and testing
- WebSphere Commerce
- most integration software
- simplification of lots of little databases (distributed DB2, Oracle,
Informix, etc.)
- reporting tools (e.g. IBI WebFocus)

[ Speaking for myself...because I can't afford to pay someone else to speak
for me. :-) ]

- - - - -
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: Using Java in batch on z/OS?

[Wade Curry]

McKown, John : Fri, Jun 02, 2006 at 01:28:50PM -0500:
> > [mailto:[EMAIL PROTECTED] On Behalf Of Hunkeler Peter
> > >They are not useless. Real shops are saving real dollars! Just
> > >ask any shop that has zAAPs and runs WebSphere or SAP on z/OS.
> > 
> > IMHO, it's just plain stupid marketing driven nonsense. z/OS
> > MVS has proven to be superior in managing very diverse
> > workloads with a single pool of processors. As of now it has to
> > manage three processor pools, three work queues,... I wonder
> > what the next "speciality" engine (what a terribly misleaging
> > term) will be.
> > 
> > Wrong approach, IBM. 
> 
> I must respectfully disagree. It is not "stupid" marketting by
> IBM. It is "smart" marketting by IBM. Why? Because although IBM
> started the "tiered pricing" it is now endemic in the market. IBM
> is trying to allow companies to legally upgrade their CPU power
> without getting hit for software upgrade fees by other companies.
> 


> 
> However, I do agree that the entire "tiered pricing" is a
> millstone on the zSeries. I understand the why of it. But
> something better is required so that a company can run cost
> effective software while the software vendors make a reasonable
> profit. Unfortunately, I don't like anything that I've seen as a
> proposed replacement. 

if you (John) or anyone else really does understand the "why" of
tiered pricing (beyond just having an efficient way to extract
money) I'd really like to hear it.  That sounded sufficiently
sarcastic that I probably need to say that this is a serious
question.  Did/does IBM perceive a benefit to the *customer* as a
result of tiered pricing... past or present?  I've been in the
mainframe world for 4 years, and that lack of exposure/experience
is showing, I'm afraid.

Frankly, pricing per MIPS sounds fundamentally unethical to me.
But since I've never been involved in purchasing a mainframe, I
can't say I see the big picture.  I still see it as the purchase of
a large asset, like a house.  No one would charge you $10,000 less
if you promise to brick-off the door to the second or third
bedroom. And actually, I'm assuming the price/MIPS is a recurring
fee.  Perhaps it's just an up-front pricing scheme to induce a
company to upgrade with at least a "partial" CP?

Wade Curry
Sr. Implementation Mgr
AT&T Services, Inc.
San Diego, CA

--
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: Using Java in batch on z/OS?

[R.S.]

McKown, John wrote:

-Original Message-
From: IBM Mainframe Discussion List 
[mailto:[EMAIL PROTECTED] On Behalf Of Hunkeler Peter (KIUB 34)

Sent: Friday, June 02, 2006 1:40 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Using Java in batch on z/OS?



They are not useless. Real shops are saving real dollars! Just 
ask any shop that has zAAPs and runs WebSphere or SAP on z/OS.


IMHO, it's just plain stupid marketing driven nonsense. z/OS MVS
has proven to be superior in managing very diverse workloads with
a single pool of processors. As of now it has to manage three 
processor pools, three work queues,... I wonder what the next 
"speciality" engine (what a terribly misleaging term) will be.


Wrong approach, IBM. 


Peter Hunkeler
CREDIT SUISSE



I must respectfully disagree. It is not "stupid" marketting by IBM. It
is "smart" marketting by IBM. Why? Because although IBM started the
"tiered pricing" it is now endemic in the market. IBM is trying to allow
companies to legally upgrade their CPU power without getting hit for
software upgrade fees by other companies.

[...]

IMHO the truth is in the middle. It is wise to encourage people to 
*start using mainframe* - that's why the price for the special engines 
is low. It is also wise to keep current incomes from legacy users 
unaffected - that's why regualr CP's are still expensive and subject to 
software fees (MSU base).
The idea is clear: if you want to run Linux, then you have a choice, you 
are not doomed to mainframe. So, IBM want to make z/Platform more 
attractive. Effect: IFL.
Similar idea for JAVA workload, since JAVA is (more or less) platform 
independent.

Similar approach for DB2 "modern" workload. Can be done on unix or windows.
COMPETITION.
Obviously old fat stinking IMS/CICS/COBOL/VSAM users pay the bucks at 
regular prices, because they have no choice. Migration is hard, 
expensive and failure-prone. They pay for regular CPs and MSU-based MLC.


However, these 'traditional' users also think how to reduce the costs. 
One of the ideas is to move some workload to special engines.
IMHO JAVA is not the best choice for batch processing. For sure, it is 
technically senseless to migrate from existing (*working*), usually 
COBOL-based batch to JAVA.
It is a signal to IBM: something goes wrong, maybe we should tune the 
pricing model.


My $0.02

--
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