z/VSE to z/OS comparision

[Avihu Gershoni]

Hi,

 

I was asked by management to write (or to find) a short document about z/OS advantages compared to z/VSE.

Using Google I found VSE to OS/390 Migration Workbook, a rather old (1998)  stuff, in which the first chapter is labeled "Why Customers Migrate"  and has several reasons, most of them irrelevant to z/VSE of today, of why would someone want to pay the price of conversion, education of users, enlarged system programing staff, and 4 to 5 more system software cost.

 

Are there a better and more up to date resources on the internet?

 

Avihu Gershoni

Manager, systems programming

Hilan Ltd, Israel, 8  Meitav Street Tel Aviv

e-mail:  av...@hilan.co.il

 

[Tony Thigpen]

A few reasons that customers migrate:
1) They need WebSphere.
2) They need a better DB2. (Although this can be handled with z/VSE and
z/Linux.)
3) Their company was acquired by a company that has z/OS and it's a
consolidation migration.
4) An application needs some of the CICS web capabilities that are not
found in the z/VSE version of CICS/TS. (Martin can expand on these.)
5) They were sold a line of $#@% by an IBM BP.
6) Management making decisions without regard to the technical points.
(Usually, an upper level manager is hired that had z/OS in a previous
shop and feels that z/VSE is not up to his vision of what is right and
proper.)

The first 4 are actually reasonable, but should be countered with ROI
figures. Unfortunately, the last two are what are normally the real reasons.

Tony Thigpen

-----Original Message -----
From: Avihu Gershoni
Sent: 08/11/2013 08:34 AM
> Hi,
>
> I was asked by management to write (or to find) a short document about
> z/OS advantages compared to z/VSE.
>
> Using Google I found VSE to OS/390 Migration Workbook

> <http://www.redbooks.ibm.com/redbooks/pdfs/sg242043.pdf>, a rather old

> (1998) stuff, in which the first chapter is labeled "Why Customers
> Migrate" and has several reasons, most of them irrelevant to z/VSE of
> today, of why would someone want to pay the price of conversion,
> education of users, enlarged system programing staff, and 4 to 5 more
> system software cost.
>
> Are there a better and more up to date resources on the internet?
>
> Avihu Gershoni
>
> Manager, systems programming
>
> Hilan Ltd, Israel, 8 Meitav Street Tel Aviv
>
> e-mail: av...@hilan.co.il
>
>
>

> _______________________________________________
> VSE-L mailing list
> VS...@lists.lehigh.edu
> https://lists.lehigh.edu/mailman/listinfo/vse-l
>

_______________________________________________
VSE-L mailing list
VS...@lists.lehigh.edu
https://lists.lehigh.edu/mailman/listinfo/vse-l

[Avihu Gershoni]

Hello Tony,

 

I am afraid your reply is a little bit too simple. I am not a z/OS system programmer but I can think of few other reasons:

1)      Productivity –

a.      z/OS manage resources (CPU, I/O) much better then z/VSE, and if you have an installation with large number of batch jobs (like we do), you can get more from the same machine with z/OS.

b.      z/OS checks for JCL errors on submit, while z/VSE checks for JCL while the job is running. If you run large number of batch jobs on the night shift unattended (like we do), in z/VSE you will discover the errors on the morning, meaning you lose time, while on z/OS you will discover them on submit.

c.      CPU time limitation is inherent in z/OS, but does not exist at all with z/VSE. Again, if one of the night shift jobs enters a CPU loop it will affect all your other jobs while in z/OS the job will abend with S322.

2)      Better CICS –  Apart from the web stuff you mentioned

a.      Under z/OS version an application cannot overlay another application storage

b.      As far as I know there is support of using more than one CPU in the same CICS region.

3)     Better software development and debugging options

a.      A much better PL/I (yes, that’s the language we use)

b.      Support for modern languages like C++ and JAVA 

c.      Support for development and debug on a windows workstation using z/PDT

4)      Information Security – RACF and the z/OS version of TOP SECRET are much better than anything on the VSE platform and are more integrated with other information security products.

5)      Personal – z/VSE system programmers are a dying breed.

 

Probably there are other reasons. I do not deny that all those advantages come with a price and that there are cases where z/VSE is better than z/OS (for example support for virtual tapes). Everything should be taken into consideration and that is why I asked for a good resource on the web.

[Allan Peterson]

Personal – z/VSE system programmers are a dying breed

 

You need to rephrase this , as equally  z/OS sysprogs are a dying breed

[Martin Truebner]

Avihu,

Althru Tony mentioned me, I did not find much I would have added- but
your arguments do appear a little tinted (by a z/OS bigot)

>> a. z/OS manage resources (CPU, I/O) much better then z/VSE, and
>> if you have an installation with large number of batch jobs (like we
>> do), you can get more from the same machine with z/OS.

Yes, the engine-management of a Porsche is superior to what
Buick does- If you look at what is usable to the end-user (the
batch job) with given input (on a given engine + fuel) - it will be
less.

>> b. z/OS checks for JCL errors on submit, while z/VSE checks for
>> JCL while the job is running. If you run large number of batch jobs
>> on the night shift unattended (like we do), in z/VSE you will
>> discover the errors on the morning, meaning you lose time, while on
>> z/OS you will discover them on submit.

not true- It can not do that, but there are extensions that can
help to eliminate most of the problems (just like in z/VSE).

>> c. CPU time limitation is inherent in z/OS, but does not exist
>> at all with z/VSE. Again, if one of the night shift jobs enters a
>> CPU loop it will affect all your other jobs while in z/OS the job
>> will abend with S322.

Yes- but i.e. my PICAPCPU can(and does) totally eliminate this problem.

>> 2) Better CICS - Apart from the web stuff you mentioned

yea- VSE has not seen an update for the VSE part in 15 years

>> a. Under z/OS version an application cannot overlay another application storage

Storage protection via key (9 vs local) is implemented in VSE as in
z/OS.

Storage isolation is not implemented. This feature does require way too
many modification to functionality (of the page management) that does
not even exist on z/VSE. The performance penalty for this is heavy as
opposed to storage protection (which comes for FREE). There are
restrictions to it and if you can not use storage protection in z/VSE
today, you will never be able to explore this in z/OS (*1).

>> b. As far as I know there is support of using more than one CPU
>> in the same CICS region.

As long as an installation does not move and explores only
functionality as it was available with CICS/VS (as is the case in most
VSE shops) you will NOT be able to use any noticeable
amount of an extra CPU.

>>3) Better software development and debugging options

YES

>> a.A much better PL/I (yes, that's the language we use)

Don't know- but same is true for COBOL

>> b. Support for modern languages like C++ and JAVA

YES

>> c. Support for development and debug on a windows workstation
>> using z/PDT

Yea- and it really makes you wonder why Z/PDT is not available for VSE
shops

>>4) Information Security - RACF and the z/OS version of TOP SECRET are

>> much better than anything on the VSE platform and are more integrated
>> with other information security products.

YES

>> 5) Personal - z/VSE system programmers are a dying breed.

what? the other side is always greener. Allan is right - System
personal (with op-sys background) is....

But some op-sys background (while not as vital) would be nice for programmers too.
They do not need (or want) exposition to the underlying op-sys.

and if you look at it the other way:

In Europe there are only limited number of programmers with knowledge of languages like COBOL, PLI or HLASM (the
stuff that runs on mainframes)....whereas knowledge of Pearl, Python,
Java, C++ et al is there in abundance.

Did I mention that I am biased towards mainframes (everything that runs
on z-boxes)?

(*1) storage isolation does require storage protection to be on. This
is not a functional requirement. It would work for key 8 (or any local
key in z/VSE). But apparently it was decided to build that intothe
implementation of storage isolation in CICS (and I like to add: good job
Hursley).

--
Martin

Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de

[mick poil]

CICS TS z/OS is not restricted to one TCB under CICS providing that the programs conform to CICS Threadsafe conventions and you enable Open TCB support for them so that they can run as (almost) fully-asynchronous processes. There is now a lot more of the CICS API that is also Threadsafe as switching TCBs during the task is expensive. True multiprocessing with a z/OS Region has been there for years.

There has been a lot of development in CICS TS z/OS over the years to enable sophisticated web-based processing and the use of Java within CICS. The latest JVMServer under CICS looks just like the WAS implementation where just one JVM has many threads/Java programs running in parallel (CICS used to use many JVMs). It now has some Mobile Apps support. There is also CICS Event processing support to trigger actions when something happens in CICS or a program. IPIC for IP connectivity where ISC was used before. It also has full 64-bit support for CICS itself, the Java JVM and application programs.

As I see it, z/OS has the ability to run large workloads due to its ability to use many cpus (not just 2 or 3) with Parallel Sysplex (and CICSPlex System Manager) technology. The Workload Manager uses Goal-based definitions to dynamically prioritize the workload, and products like CICS actively work with the WLM to assist its decision making. It can exploit Hiperdispatch to improve cpu affinity and hence better performance through better cache exploitation. Customers do not run a few CICS partitions, they run 10's or 100's. Most products are more sophisticated in z/OS compared to VSE, e.g. MQ and DB2, and that includes OEM, and they can scale to meet the workload growth.

There is SMS for automating dasd management volume selection, dasd tuning, automatic unused primary space release, advanced secondary space allocation (e.g. VSAM does not need a primary allocation on a new volume),

data archiving etc. etc. VSAM has System Managed Buffering that automates buffer tuning without needing OEM software, and ICF catalogs that are much simpler (VSAM extent information is with the volume's VTOC not in the catalog) and are easier to recover when  there is a problem (forward recovery of catalog information is possible). VSAM RLS allows record-level (not CI-level) sharing across regions by using a VSAM data management subsystem.

It has very sophisticated security and can usually fully exploit the latest hardware encryption. CICS exploits multiple fully-parallel SSL subtasks instead of one non-parallel subtask.

z/OS does not need a Linux sidecar as it has had a fully-functional Unix environment within itself for a long time.

There is a Redbook series - the ABCs of z/OS Systems Programming SG24-6981 etc. that may give you more of a feel, although even that is getting out-of-date now

Those of you that know me are aware that I really like VSE, but there are customers out there that would just not be able to do the work that they do with VSE, hence they use z/OS and can justify the cost of the software and the extra personnel to handle the complexity. Some of this would have been historical as they started with OS instead of DOS, but that was probably because they needed a bigger 360 (and could afford it) to start with.

Mike

[Frank M. Ramaekers]

The main reason they don't:

$$$$$

Frank M. Ramaekers Jr.

> -----Original Message-----
> From: vse-l-bounces+framaekers=ailif...@lists.lehigh.edu
[mailto:vse-l-
> bounces+framaekers=ailif...@lists.lehigh.edu] On Behalf Of Tony
Thigpen
> Sent: Sunday, August 11, 2013 8:21 AM
> To: VSE Discussion List
> Subject: Re: z/VSE to z/OS comparision
>

[Tom Huegel]

Frank has it there, $$$$. If z/OS and z/VSE were about the same cost how many z/VSE shops would there be?

Back when IBM was killing off VSE wasn't there some stripped down MVS entry-level offering?

 

[Edward M. Martin]

Reason number 6 here with 3 being what the Remote Hosted site had.

Ed Martin
Aultman Health Foundation
330-363-9666
Ext 39666

-----Original Message-----
From: vse-l-bounces+emartin=aultm...@lists.lehigh.edu [mailto:vse-l-bounces+emartin=aultm...@lists.lehigh.edu] On Behalf Of Tony Thigpen
Sent: Sunday, August 11, 2013 9:21 AM
To: VSE Discussion List
Subject: Re: z/VSE to z/OS comparision

[Andy Engels]

Under #6 - I knew a place that went MVS to show their largest partner organization that "they could play with the big boys."

Yeah, they were bought out by another outfit - that converted them back to VSE. That was a couple years after all the expenditures on the conversion, CPU upgrade, all the software upgrade. They still only ran the place with 2 systems programmers. At least they hired people who knew what they were doing...

__________________________________
Andy Engels
IS Team Leader - Technical Services
Illinois Municipal Retirement Fund
Oak Brook, IL
630-368-5346

-----Original Message-----
From: vse-l-bounces+aengels=imrf...@lists.lehigh.edu [mailto:vse-l-bounces+aengels=imrf...@lists.lehigh.edu] On Behalf Of Tony Thigpen
Sent: Sunday, August 11, 2013 8:21 AM
To: VSE Discussion List
Subject: Re: z/VSE to z/OS comparision

[Richard Verville]

Allan +1