21st centry [was: no subject]

[i***@winwholesale.com]

"VSE-L" <vse-l-bounces+industrynews=***@lists.lehigh.edu>
wrote on 07/12/2016 09:59:47 AM:
> Now why would a company "in the 21st century" be running VSE?
Thinkabout it.

I object to the implication that z/VSE is not a 21st century
operating system. I think IBM has done very well in modernizing z/VSE
just enough while still keeping costs down. 3rd-party vendors supply the
other bells and whistles a company might need for additional
modernization. z/VSE is hands-down the best bang for your mainframe buck.

Sincerely,

Dave Clark
--
Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio 45439 USA
[phone]




*********************************************************************************************
This email message and any attachments is for use only by the named
addressee(s) and may contain confidential, privileged and/or proprietary
information. If you have received this message in error, please
immediately notify the sender and delete and destroy the message and all
copies. All unauthorized direct or indirect use or disclosure of this
message is strictly prohibited. No right to confidentiality or privilege
is waived or lost by any error in transmission.
*********************************************************************************************

[i***@winwholesale.com]

"VSE-L" <vse-l-bounces+industrynews=***@lists.lehigh.edu>
wrote on 07/12/2016 12:09:12 PM:
> IBM has done very well in modernizing VSE? Really??

...while keeping costs down, yes. DOS/VSE was a 24-bit operating
system. Then, VSE/ESA was a 31-bit operating system. Now, in the 21st
century, z/VSE is a 64-bit operating system. IBM has done very well while
still keeping costs down. Would you rather the cost of z/VSE double or
triple? Hey, if you don't like z/VSE then get off of it. Go install
z/OS. If you are already on z/OS, then get off this list.

Sincerely,

Dave Clark
--
Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio 45439 USA
[phone]




*********************************************************************************************
This email message and any attachments is for use only by the named
addressee(s) and may contain confidential, privileged and/or proprietary
information. If you have received this message in error, please
immediately notify the sender and delete and destroy the message and all
copies. All unauthorized direct or indirect use or disclosure of this
message is strictly prohibited. No right to confidentiality or privilege
is waived or lost by any error in transmission.
*********************************************************************************************

[Ken and Mary Meyer]

Hey, let's keep this discussion cordial. We need both
advocates and dissenters on this list to be able to
keep progressing! People can complain and still be
very active using the z/VSE operating system. We need
representatives from very large and very small
companies as well to keep perspective. Let's not make
this discussion list become what so many others have
turned into.

Ken


On Tue, Jul 12, 2016 at 11:23 AM, <***@winwholesale.com> wrote:

​snip..
​

[i***@winwholesale.com]

"VSE-L" <vse-l-bounces+industrynews=***@lists.lehigh.edu>
wrote on 07/12/2016 02:26:07 PM:
> Hey, let's keep this discussion cordial.

For the most part I agree with you and in the 15 years I have been
on this list you should have noticed that I try to keep it that way. I
don't have a problem with complainers because, face it, we are all human
and will complain from time to time. That said, in the 36 years I have
worked with VSE I still see the future of z/VSE as being in a balancing
act. Two years of that I even worked with both VSE and MVS during a
transition. So, I really appreciate what IBM is doing for us VSE folk. I
don't want anyone giving IBM the idea that their efforts are not
appreciated -- because they could just stop sharing their toys with us.
So, those who outright bash what IBM is doing garner no pulled punches
from me.

Sincerely,

Dave Clark
--
Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio 45439 USA
[phone]




*********************************************************************************************
This email message and any attachments is for use only by the named
addressee(s) and may contain confidential, privileged and/or proprietary
information. If you have received this message in error, please
immediately notify the sender and delete and destroy the message and all
copies. All unauthorized direct or indirect use or disclosure of this
message is strictly prohibited. No right to confidentiality or privilege
is waived or lost by any error in transmission.
*********************************************************************************************

[Mick Poil]

A lot of the new VSE code is not in the Supervisor.

[Tom Huegel]

What's wrong with 'old code' as long as it works and efficiently
performs what is necessary. Hey I've had the same phone number for over 30
years - it still works, but it is 20th century.

On Tue, Jul 12, 2016 at 9:55 AM, Mick Poil <***@gmail.com>
wrote:

> A lot of the new VSE code is not in the Supervisor.
>
> _______________________________________________
> VSE-L mailing list
> VSE-***@lists.lehigh.edu
> https://lists.lehigh.edu/mailman/listinfo/vse-l
>
>

[Mick Poil]

Re comments on relative capacities, z/OS sites can run 100's of CICS
regions concurrently and still return very fast response times. CICS
transactions can take full advantage of multiple CPs and CICS z/OS has
other performance benefits due to the use of the available z/OS facilities
and CICS design changes.

Under the covers, CICS is extremely OS aware.

z/OS is very expensive, although I can't be sure of the multiplier of the
equivalent VSE price.

[Tom Huegel]

No Dave I recently replaced my old black dial phone with one of these new
fangled pushbutton gadgets. The only problem with the phone is it is
limited by the length of the cord. (A hardware restriction).

On Tue, Jul 12, 2016 at 10:29 AM, Stuart, David <***@ventura.org>
wrote:

> Same phone?
>
>
>
>
>
> Dave
>
>
>
>
>
> *From:* VSE-L [mailto:vse-l-bounces+david.stuart=
> ***@lists.lehigh.edu] *On Behalf Of *Tom Huegel
> *Sent:* Tuesday, July 12, 2016 10:19 AM
> *To:* VSE Discussion List <vse-***@lists.lehigh.edu>
> *Subject:* Re: 21st centry [was: no subject]
>
>
>
> What's wrong with 'old code' as long as it works and efficiently
> performs what is necessary. Hey I've had the same phone number for over 30
> years - it still works, but it is 20th century.
>
>
>
> On Tue, Jul 12, 2016 at 9:55 AM, Mick Poil <***@gmail.com>
> wrote:
>
> A lot of the new VSE code is not in the Supervisor.
>
>
> _______________________________________________
> VSE-L mailing list
> VSE-***@lists.lehigh.edu
> https://lists.lehigh.edu/mailman/listinfo/vse-l
>
>
>
> _______________________________________________
> VSE-L mailing list
> VSE-***@lists.lehigh.edu
> https://lists.lehigh.edu/mailman/listinfo/vse-l
>
>

[Ken and Mary Meyer]

No partition in z/VSE can use more than one CP at a
time. One of many reasons why multiple CPUs in the
z/VSE environment need to have multiple partitions
that can exploit these CPUs, plus you have to reduce
the NP (non-parallel) processing.

Ken


On Tue, Jul 12, 2016 at 2:23 PM, Stuart, David <***@ventura.org> wrote:
snip..

[Eugene S Hudders CTREK Corp. via VSE-L]

Hi Andy:

A large number of z/OS shops today run many CICS production, test and
certification systems running on multiprocessing systems. The shop I am
currently working with has 40+ production regions handling DB2 and VSAM. To
accomplish multitasking application work in CICS requires that both the operating
system as well as CICS have dispatchable units of work that can be
assigned to available processors and a lock mechanism that can protect the work
when it is executing. Both CICS and z/OS have a complex lock structure to
allow multiprocessing of work from one region. The unit of work used by z/OS is
called a Task Control Block or TCB. Within CICS the equivalent control
block is called a Kernel Task Control Block or KTCB which has an assigned z/OS
TCB to coordinate with z/OS.

Internally CICS has a Domain called the Lock Manager that is used to
protect resources during execution. z/OS also has its own lock structure to
protect resources. The lock structure within z/VSE would have to be
significantly altered to support multitasking within the same partition. You can see
this by the limitation of the z/VSE Non-Parallel processing partially
because of the lack of a sophisticated lock structure in z/VSE (please, not
insult meant). In z/OS you could have the operating system executing the same
code on two or more processors at the same time and there is no NP limitation
per se.

With regards to VSAM in z/OS, CICS TS has a separate TCB called the
Concurrent TCB (CO) to handle VSAM requests, specifically, write requests that
can be dispatched TCB and separate processor while other work running on
second processor running on the Quasi-Reentrant TCB (QR). Most of your
application code runs on the QR TCB unless you code your programs using the
threadsafe technique (I will discuss this concept at the end). The CO TCB used
for VSAM sub-tasking is not available in z/VSE (generated by the SIT
parameter SUBTSKS=1). However, I have never seen this TCB being used more than 2 to
5% of the total CICS CPU time. So, even though there is some overlap, it
was not very high. Also, there is a Resource Owning TCB (RO) that is used to
load programs, open system files and communicate with RACF. This TCB is
also a low CPU user. To improve this condition, Hursley implemented a whole
new series of TCBs depending on the work being performed by CICS to multitask
work on different types of TCBs.

To name a few TCBs:

1) L8/L9 -- used by DB2 and exits
2) SL/SO/S8/SP -- used by socket support
3) FO -- used to open application files
4) SZ -- support for Front End Processing Interface (FEPI)
5) T8/T9 -- Java Virtual Machine (JVM) support
6) X8/X9 -- C++
7) EP -- Event Processing

If there were sufficient processors (CPU) available, one CICS system could
have dispatched multiple of these TCBs on different processors. I have
seen one CICS system dispatch work on 6 processors at a time. However, using
some of these TCBs to dispatch work requires that programs be coded as
threadsafe. This simply means that not only does a program have to be fully
reentrant (versus quasi-reentrant) but that it also has to protect the use of
shared resources such as the CWA and shared storage GETMAINs. The protection
of shared resources can be done by ENQ/DEQ EXEC CICS commands for high
level languages or the equivalent assembler instructions. Originally defined
for DB2 work on L8 TCBs, it has now also been expanded to VSAM.

CICS TS is not the old CICS in structure. It is completely changed from the
old CICS VSE especially in the way tasks are dispatched. I hope this
provides some useful information to this discussion.

Regards,
Gene

[Andy Engels]

Sounds like another internals class might be in order....

Sent from my iPhone5
in Chicago, where the sky was first scraped.....

On Jul 12, 2016, at 22:24, Eugene S Hudders CTREK Corp. via VSE-L <vse-***@lists.lehigh.edu<mailto:vse-***@lists.lehigh.edu>> wrote:

Hi Andy:

A large number of z/OS shops today run many CICS production, test and certification systems running on multiprocessing systems. The shop I am currently working with has 40+ production regions handling DB2 and VSAM. To accomplish multitasking application work in CICS requires that both the operating system as well as CICS have dispatchable units of work that can be assigned to available processors and a lock mechanism that can protect the work when it is executing. Both CICS and z/OS have a complex lock structure to allow multiprocessing of work from one region. The unit of work used by z/OS is called a Task Control Block or TCB. Within CICS the equivalent control block is called a Kernel Task Control Block or KTCB which has an assigned z/OS TCB to coordinate with z/OS.

Internally CICS has a Domain called the Lock Manager that is used to protect resources during execution. z/OS also has its own lock structure to protect resources. The lock structure within z/VSE would have to be significantly altered to support multitasking within the same partition. You can see this by the limitation of the z/VSE Non-Parallel processing partially because of the lack of a sophisticated lock structure in z/VSE (please, not insult meant). In z/OS you could have the operating system executing the same code on two or more processors at the same time and there is no NP limitation per se.

With regards to VSAM in z/OS, CICS TS has a separate TCB called the Concurrent TCB (CO) to handle VSAM requests, specifically, write requests that can be dispatched TCB and separate processor while other work running on second processor running on the Quasi-Reentrant TCB (QR). Most of your application code runs on the QR TCB unless you code your programs using the threadsafe technique (I will discuss this concept at the end). The CO TCB used for VSAM sub-tasking is not available in z/VSE (generated by the SIT parameter SUBTSKS=1). However, I have never seen this TCB being used more than 2 to 5% of the total CICS CPU time. So, even though there is some overlap, it was not very high. Also, there is a Resource Owning TCB (RO) that is used to load programs, open system files and communicate with RACF. This TCB is also a low CPU user. To improve this condition, Hursley implemented a whole new series of TCBs depending on the work being performed by CICS to multitask work on different types of TCBs.

To name a few TCBs:

1) L8/L9 -- used by DB2 and exits
2) SL/SO/S8/SP -- used by socket support
3) FO -- used to open application files
4) SZ -- support for Front End Processing Interface (FEPI)
5) T8/T9 -- Java Virtual Machine (JVM) support
6) X8/X9 -- C++
7) EP -- Event Processing

If there were sufficient processors (CPU) available, one CICS system could have dispatched multiple of these TCBs on different processors. I have seen one CICS system dispatch work on 6 processors at a time. However, using some of these TCBs to dispatch work requires that programs be coded as threadsafe. This simply means that not only does a program have to be fully reentrant (versus quasi-reentrant) but that it also has to protect the use of shared resources such as the CWA and shared storage GETMAINs. The protection of shared resources can be done by ENQ/DEQ EXEC CICS commands for high level languages or the equivalent assembler instructions. Originally defined for DB2 work on L8 TCBs, it has now also been expanded to VSAM.

CICS TS is not the old CICS in structure. It is completely changed from the old CICS VSE especially in the way tasks are dispatched. I hope this provides some useful information to this discussion.

Regards,
Gene

[Lou Winston]

Interestingly, the lock manager routines within the VSE supervisor seem to date back to 1979 - that my explain why VSE is so woefully inadequate in that area.


L.W.


________________________________
From: VSE-L <vse-l-bounces+lewinston=***@lists.lehigh.edu> on behalf of Andy Engels <***@imrf.org>
Sent: Wednesday, July 13, 2016 10:50 AM
To: ***@aol.com; VSE Discussion List
Subject: Re: 21st centry [was: no subject]

Sounds like another internals class might be in order....

Sent from my iPhone5
in Chicago, where the sky was first scraped.....

On Jul 12, 2016, at 22:24, Eugene S Hudders CTREK Corp. via VSE-L <vse-***@lists.lehigh.edu<mailto:vse-***@lists.lehigh.edu>> wrote:

Hi Andy:

A large number of z/OS shops today run many CICS production, test and certification systems running on multiprocessing systems. The shop I am currently working with has 40+ production regions handling DB2 and VSAM. To accomplish multitasking application work in CICS requires that both the operating system as well as CICS have dispatchable units of work that can be assigned to available processors and a lock mechanism that can protect the work when it is executing. Both CICS and z/OS have a complex lock structure to allow multiprocessing of work from one region. The unit of work used by z/OS is called a Task Control Block or TCB. Within CICS the equivalent control block is called a Kernel Task Control Block or KTCB which has an assigned z/OS TCB to coordinate with z/OS.

Internally CICS has a Domain called the Lock Manager that is used to protect resources during execution. z/OS also has its own lock structure to protect resources. The lock structure within z/VSE would have to be significantly altered to support multitasking within the same partition. You can see this by the limitation of the z/VSE Non-Parallel processing partially because of the lack of a sophisticated lock structure in z/VSE (please, not insult meant). In z/OS you could have the operating system executing the same code on two or more processors at the same time and there is no NP limitation per se.

With regards to VSAM in z/OS, CICS TS has a separate TCB called the Concurrent TCB (CO) to handle VSAM requests, specifically, write requests that can be dispatched TCB and separate processor while other work running on second processor running on the Quasi-Reentrant TCB (QR). Most of your application code runs on the QR TCB unless you code your programs using the threadsafe technique (I will discuss this concept at the end). The CO TCB used for VSAM sub-tasking is not available in z/VSE (generated by the SIT parameter SUBTSKS=1). However, I have never seen this TCB being used more than 2 to 5% of the total CICS CPU time. So, even though there is some overlap, it was not very high. Also, there is a Resource Owning TCB (RO) that is used to load programs, open system files and communicate with RACF. This TCB is also a low CPU user. To improve this condition, Hursley implemented a whole new series of TCBs depending on the work being performed by CICS to multitask work on different types of TCBs.

To name a few TCBs:

1) L8/L9 -- used by DB2 and exits
2) SL/SO/S8/SP -- used by socket support
3) FO -- used to open application files
4) SZ -- support for Front End Processing Interface (FEPI)
5) T8/T9 -- Java Virtual Machine (JVM) support
6) X8/X9 -- C++
7) EP -- Event Processing

If there were sufficient processors (CPU) available, one CICS system could have dispatched multiple of these TCBs on different processors. I have seen one CICS system dispatch work on 6 processors at a time. However, using some of these TCBs to dispatch work requires that programs be coded as threadsafe. This simply means that not only does a program have to be fully reentrant (versus quasi-reentrant) but that it also has to protect the use of shared resources such as the CWA and shared storage GETMAINs. The protection of shared resources can be done by ENQ/DEQ EXEC CICS commands for high level languages or the equivalent assembler instructions. Originally defined for DB2 work on L8 TCBs, it has now also been expanded to VSAM.

CICS TS is not the old CICS in structure. It is completely changed from the old CICS VSE especially in the way tasks are dispatched. I hope this provides some useful information to this discussion.

Regards,
Gene

[Jeffrey Barnard]

Lou,

The original copyrights may go back that far, but there have been a lot of
updates, fixes, what not to lock manager over the years. To all of VSE's
code as a matter of fact. I have found the lock manager facilities very
useful over the years.

If you have a need for a new facility, in the lock manager or else where,
submit a request to IBM. It is sometimes surprising to see some of the
requests that were originally turned down (often several times) suddenly
come into existence.

If you want something new, submit a request for it and provide a business
case for your request. What do you need, why do you need it (be specific)
and why would it also benefit other VSE customers.

Regards,
Jeff

[Lou Winston]

I was specifically looking at the code for the lock manager - not the rest of the supervisor and it was dated 1979. Sorry - that's what it says.

as far as IBM implementing new features, they are well aware of the deficiencies - they were brought up in conjunction with CICS/TS and the fact that the VSE implementation of CICS/TS cannot exploit multiple engines because of the inadequate lock manager.


Personally, CICS/TS is one of the very bright spots for VSE. I am well satisfied with the way it functions in our environment.


L.W.




________________________________
From: VSE-L <vse-l-bounces+lewinston=***@lists.lehigh.edu> on behalf of Jeffrey Barnard <***@bsiopti.com>
Sent: Wednesday, July 13, 2016 2:22 PM
To: VSE Discussion List
Subject: Re: 21st centry [was: no subject]

Lou,

The original copyrights may go back that far, but there have been a lot of
updates, fixes, what not to lock manager over the years. To all of VSE's
code as a matter of fact. I have found the lock manager facilities very
useful over the years.

If you have a need for a new facility, in the lock manager or else where,
submit a request to IBM. It is sometimes surprising to see some of the
requests that were originally turned down (often several times) suddenly
come into existence.

If you want something new, submit a request for it and provide a business
case for your request. What do you need, why do you need it (be specific)
and why would it also benefit other VSE customers.

Regards,
Jeff

_______________________________________________
VSE-L mailing list
VSE-***@lists.lehigh.edu
https://lists.lehigh.edu/mailman/listinfo/vse-l
VSE-L -- VSE Discussion List - lists.lehigh.edu<https://lists.lehigh.edu/mailman/listinfo/vse-l>
lists.lehigh.edu
Welcome to VSE-L, discussion land and resources for the VSE / ESA mainframe operating system! For more information about vse-l see vse-l web pages.

[Jeffrey Barnard]

Ah.

I suspect what you are really asking for is better SETLOCK OBTAIN/RELEASE
support within z/VSE.

CICS TS requires a z/OS emulation layer to run. One of the things that must
be emulated is the z/OS SETLOCK functionality. E.g., SETLOCK OBTAIN,LOCAL
to acquire the local lock. Only those functions that are required by CICS
TS are emulated. Obtaining the local lock is one function that would be
required.

The z/VSE LOCK function works well but it is not designed to handle
serialization at the level required by multi-CPU, multi-tasking systems.
This is why z/OS has a SETLOCK facility.

Of course, even if we had this support, IBM would have to change a lot of
programs to use it too.

Regards,
Jeff

[Mick Poil]

That CICS TS VSE cannot exploit multiple cpus is a function of the CICS
dispatcher design for CICS/ESA 4.1 upon which CICS TS VSE was based.

Even if it did, it would be pointless, because VSE wouldn't allow more than
one CICS TCB (subtask) to be dispatched at a time no matter how many cpus
are available. I have only seen 3 (out of the 10 maximum) used by a VSE
customer anyway, but
I have seen some z/OS customers running 32 or more cpus per LPAR.

Mike

[Ken and Mary Meyer]

For z/VSE, multiple CPUs are useful for two partitions to be able to run at
the same time in parallel. This ability could help two CICS, two batch, or
one of each to run better, provided the requirement for non-parallel processing
is minimized and the two partitions use resources that are minimally shared
between the partitions. In the case where three CPUs are active, it is rare for
all three to be utilized effectively without diminishing returns.

For z/VSE to run multiple CPUs for a single partition, it would take a
monumental
amount of work to support by IBM and vendors, both of which must keep their
costs to a minimum to allow the platform to continue. Over the years I made
several changes to products that would allow them to run in multiple partitions
and reduce non-parallel requirements, allowing multiple CPUs to be used more
effectively. Such strategies are more useful for z/VSE exploitation of multiple
CPUs than attempting to allow multiple tasks to run simultaneously in a single
partition, plus it does not require changes to the operating system, itself.

Although old, the z/VSE locking mechanism is still very powerful. If
you are using
locking within a single LPAR, it is very fast and still easy to use.
You can create
a lock of an imaginary resource if you wish. If you take a look at
what IBM uses
it for, you will see some really neat stuff. :)

Ken


On Thu, Jul 14, 2016 at 2:13 PM, Mick Poil <***@gmail.com>
snip..

[Jeffrey Barnard]

Well said, Ken.

When the Turbo-Dispatcher was created the speed of a single processor was
much lower than it is now. Multiple CPU's could be used to increase overall
system performance/throughput.

As time passed, the speed of a single processor increased dramatically and
less VSE/ESA and z/VSE customers used multi-processor z/VSE images.

However, the time of big increases in CPU speed with each new z generation
is over and a shift to multiple CPU and even multi-threading is occurring.

That said, z/VSE is able to handle these new CPU's and a multi-CPU
environment easily. Applications like CICS TS (and running multiple CICS TS
partitions) in z/VSE will work very well in this environment. In the end,
applications that try to do everything in a single partition are at a
disadvantage. The future of z/VSE applications is in multi-partition
designs that can take maximum advantage of the availability of multiple CPUs.

Jeff

[Tony Thigpen]

Additionally,

When using a database where all database IO is via one partition (like
CA-Datacom/DB Multi-User Facility [MUF]), a second CPU is very helpful.
In a previous job, going from a singe to dual CPU really helped our
VSEs. No longer could a heavy sequential batch job (against Datacom)
cause CICS to have to wait for data from the MUF. When we went back to a
singe CPU (MP3000-H50), we again saw the same problem, but by jumping up
to more MIPS, we whitewashed the problem.

Tony Thigpen

Jeffrey Barnard wrote on 07/15/2016 09:56 AM:
> Well said, Ken.
>
> When the Turbo-Dispatcher was created the speed of a single processor
> was much lower than it is now. Multiple CPU's could be used to increase
> overall system performance/throughput.
>
> As time passed, the speed of a single processor increased dramatically
> and less VSE/ESA and z/VSE customers used multi-processor z/VSE images.
>
> However, the time of big increases in CPU speed with each new z
> generation is over and a shift to multiple CPU and even multi-threading
> is occurring.
>
> That said, z/VSE is able to handle these new CPU's and a multi-CPU
> environment easily. Applications like CICS TS (and running multiple CICS
> TS partitions) in z/VSE will work very well in this environment. In the
> end, applications that try to do everything in a single partition are at
> a disadvantage. The future of z/VSE applications is in multi-partition
> designs that can take maximum advantage of the availability of multiple
> CPUs.
>
> Jeff
>
> _______________________________________________
> VSE-L mailing list
> VSE-***@lists.lehigh.edu
> https://lists.lehigh.edu/mailman/listinfo/vse-l
>
>

[Lou Winston]

Reference the blog entry By Gene Hudders:

Note the use of the term "lack of a sophisticated lock structure"


"Internally CICS has a Domain called the Lock Manager that is used to protect resources during execution. z/OS also has its own lock structure to protect resources. The lock structure within z/VSE would have to be significantly altered to support multitasking within the same partition. You can see this by the limitation of the z/VSE Non-Parallel processing partially because of the lack of a sophisticated lock structure in z/VSE (please, not insult meant). In z/OS you could have the operating system executing the same code on two or more processors at the same time and there is no NP limitation per se. "




L.W.


________________________________
From: VSE-L <vse-l-bounces+lewinston=***@lists.lehigh.edu> on behalf of Ken and Mary Meyer <***@gmail.com>
Sent: Thursday, July 14, 2016 4:44 PM
To: VSE Discussion List
Subject: Re: 21st centry [was: no subject]

For z/VSE, multiple CPUs are useful for two partitions to be able to run at
the same time in parallel. This ability could help two CICS, two batch, or
one of each to run better, provided the requirement for non-parallel processing
is minimized and the two partitions use resources that are minimally shared
between the partitions. In the case where three CPUs are active, it is rare for
all three to be utilized effectively without diminishing returns.

For z/VSE to run multiple CPUs for a single partition, it would take a
monumental
amount of work to support by IBM and vendors, both of which must keep their
costs to a minimum to allow the platform to continue. Over the years I made
several changes to products that would allow them to run in multiple partitions
and reduce non-parallel requirements, allowing multiple CPUs to be used more
effectively. Such strategies are more useful for z/VSE exploitation of multiple
CPUs than attempting to allow multiple tasks to run simultaneously in a single
partition, plus it does not require changes to the operating system, itself.

Although old, the z/VSE locking mechanism is still very powerful. If
you are using
locking within a single LPAR, it is very fast and still easy to use.
You can create
a lock of an imaginary resource if you wish. If you take a look at
what IBM uses
it for, you will see some really neat stuff. :)

Ken


On Thu, Jul 14, 2016 at 2:13 PM, Mick Poil <***@gmail.com>
snip..

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

VSE-L -- VSE Discussion List - lists.lehigh.edu<https://lists.lehigh.edu/mailman/listinfo/vse-l>
lists.lehigh.edu
Welcome to VSE-L, discussion land and resources for the VSE / ESA mainframe operating system! For more information about vse-l see vse-l web pages.

[Lou Winston]

Sounds good to me.


L.W.


________________________________
From: VSE-L <vse-l-bounces+lewinston=***@lists.lehigh.edu> on behalf of Andy Engels <***@imrf.org>
Sent: Wednesday, July 13, 2016 10:50 AM
To: ***@aol.com; VSE Discussion List
Subject: Re: 21st centry [was: no subject]

Sounds like another internals class might be in order....

Sent from my iPhone5
in Chicago, where the sky was first scraped.....

On Jul 12, 2016, at 22:24, Eugene S Hudders CTREK Corp. via VSE-L <vse-***@lists.lehigh.edu<mailto:vse-***@lists.lehigh.edu>> wrote:

Hi Andy:

A large number of z/OS shops today run many CICS production, test and certification systems running on multiprocessing systems. The shop I am currently working with has 40+ production regions handling DB2 and VSAM. To accomplish multitasking application work in CICS requires that both the operating system as well as CICS have dispatchable units of work that can be assigned to available processors and a lock mechanism that can protect the work when it is executing. Both CICS and z/OS have a complex lock structure to allow multiprocessing of work from one region. The unit of work used by z/OS is called a Task Control Block or TCB. Within CICS the equivalent control block is called a Kernel Task Control Block or KTCB which has an assigned z/OS TCB to coordinate with z/OS.

Internally CICS has a Domain called the Lock Manager that is used to protect resources during execution. z/OS also has its own lock structure to protect resources. The lock structure within z/VSE would have to be significantly altered to support multitasking within the same partition. You can see this by the limitation of the z/VSE Non-Parallel processing partially because of the lack of a sophisticated lock structure in z/VSE (please, not insult meant). In z/OS you could have the operating system executing the same code on two or more processors at the same time and there is no NP limitation per se.

With regards to VSAM in z/OS, CICS TS has a separate TCB called the Concurrent TCB (CO) to handle VSAM requests, specifically, write requests that can be dispatched TCB and separate processor while other work running on second processor running on the Quasi-Reentrant TCB (QR). Most of your application code runs on the QR TCB unless you code your programs using the threadsafe technique (I will discuss this concept at the end). The CO TCB used for VSAM sub-tasking is not available in z/VSE (generated by the SIT parameter SUBTSKS=1). However, I have never seen this TCB being used more than 2 to 5% of the total CICS CPU time. So, even though there is some overlap, it was not very high. Also, there is a Resource Owning TCB (RO) that is used to load programs, open system files and communicate with RACF. This TCB is also a low CPU user. To improve this condition, Hursley implemented a whole new series of TCBs depending on the work being performed by CICS to multitask work on different types of TCBs.

To name a few TCBs:

1) L8/L9 -- used by DB2 and exits
2) SL/SO/S8/SP -- used by socket support
3) FO -- used to open application files
4) SZ -- support for Front End Processing Interface (FEPI)
5) T8/T9 -- Java Virtual Machine (JVM) support
6) X8/X9 -- C++
7) EP -- Event Processing

If there were sufficient processors (CPU) available, one CICS system could have dispatched multiple of these TCBs on different processors. I have seen one CICS system dispatch work on 6 processors at a time. However, using some of these TCBs to dispatch work requires that programs be coded as threadsafe. This simply means that not only does a program have to be fully reentrant (versus quasi-reentrant) but that it also has to protect the use of shared resources such as the CWA and shared storage GETMAINs. The protection of shared resources can be done by ENQ/DEQ EXEC CICS commands for high level languages or the equivalent assembler instructions. Originally defined for DB2 work on L8 TCBs, it has now also been expanded to VSAM.

CICS TS is not the old CICS in structure. It is completely changed from the old CICS VSE especially in the way tasks are dispatched. I hope this provides some useful information to this discussion.

Regards,
Gene

[Mick Poil]

My post was just to say that CICS z/OS is more powerful and scalable by
design
. But is MUCH more expensive.

Some parts of CICS TS VSE are not very efficient, and it won't support more
than 1 cpu for 99% of the task activity.

The amount of multi cpu NP activity can impact CICS in unusual cases.

Those of you that know me will be aware of how much I like VSE. But just
because I drive a Ford doesn't mean I can't appreciate something like a big
Mercedes ;-)

And some customers really do need that number of regions for the massive
workloads that they have.

[Tom Huegel]

For organizations requiring massive transaction processing there is TPF...

On Tue, Jul 12, 2016 at 11:54 PM, Mick Poil <***@gmail.com>
wrote:

> My post was just to say that CICS z/OS is more powerful and scalable by
> design
> . But is MUCH more expensive.
>
> Some parts of CICS TS VSE are not very efficient, and it won't support
> more than 1 cpu for 99% of the task activity.
>
> The amount of multi cpu NP activity can impact CICS in unusual cases.
>
> Those of you that know me will be aware of how much I like VSE. But just
> because I drive a Ford doesn't mean I can't appreciate something like a big
> Mercedes ;-)
>
> And some customers really do need that number of regions for the massive
> workloads that they have.
>
> _______________________________________________
> VSE-L mailing list
> VSE-***@lists.lehigh.edu
> https://lists.lehigh.edu/mailman/listinfo/vse-l
>
>

[Tom Huegel]

The loudest thing I heard was a 2311 disk drive exploding. These were
hydraulic actuators the explosion send oil flying all over the place...
Sooo much fun.. the year was 1969 I believe.

On Wed, Jul 13, 2016 at 11:59 AM, August Carideo/RYE/US <
***@avon.com> wrote:

> Was nothing louder than the 2019 check sorters , or were they 3890’s was
> at bank I started at in 1978
>
> By time required to use ear protectors was too late for some
>
>
>
> *From:* VSE-L [mailto:vse-l-bounces+august.carideo=
> ***@lists.lehigh.edu] *On Behalf Of *Mike Moore
> *Sent:* Wednesday, July 13, 2016 1:02 PM
>
> *To:* VSE Discussion List <vse-***@lists.lehigh.edu>
> *Subject:* RE: 21st centry [was: no subject]
>
>
>
> Yep, between the 1403 and the 2 3211s we could drown out just about any
> noise we wanted to!
>
> Had an operator that loved to stick listings on the tops of the 3211s
> while he was doing other things. Forms would run out, cover would lift and
> the 3211 turned into a dump truck.
>
>
>
>
>
>
>
>
>
> Mike Moore
>
> IT Manager
>
> Alabama Judicial Datacenter
>
> 300 Dexter Avenue
>
> Montgomery, Alabama 36104
>
> 334-954-5025
>
>
>
> “This is the final test of a gentleman: his respect for those who can be
> of no possible service to him.” – William Lyon Phelps
>
>
>
> *From:* VSE-L [
> mailto:vse-l-bounces+mike.moore=***@lists.lehigh.edu
> <vse-l-bounces+mike.moore=***@lists.lehigh.edu>] *On Behalf Of *
> ***@courts.state.va.us
> *Sent:* Wednesday, July 13, 2016 11:10 AM
> *To:* VSE Discussion List <vse-***@lists.lehigh.edu>
> *Subject:* RE: 21st centry [was: no subject]
>
>
>
> We countered the noise by running the 1403 printer with the cover up
> (tape covering the interlock)
>
> [image: Inactive hide details for Mike Moore ---07/13/2016 11:37:22
> AM---Running a 1419 was just about like running a steam engine! Lot]Mike
> Moore ---07/13/2016 11:37:22 AM---Running a 1419 was just about like
> running a steam engine! Lots of air and noise! Mike Moore
>
> From: Mike Moore <***@alacourt.gov>
> To: VSE Discussion List <vse-***@lists.lehigh.edu>
> Date: 07/13/2016 11:37 AM
> Subject: RE: 21st centry [was: no subject]
> Sent by: "VSE-L" <vse-l-bounces+mriggs=***@lists.lehigh.edu
> >
> ------------------------------
>
>
>
>
> Running a 1419 was just about like running a steam engine! Lots of air and
> noise!
>
>
>
>
> Mike Moore
> IT Manager
> Alabama Judicial Datacenter
> 300 Dexter Avenue
> Montgomery, Alabama 36104
> 334-954-5025
>
> “This is the final test of a gentleman: his respect for those who can be
> of no possible service to him.” – William Lyon Phelps
>
> *From:* VSE-L [
> mailto:vse-l-bounces+mike.moore=***@lists.lehigh.edu
> <vse-l-bounces+mike.moore=***@lists.lehigh.edu>] *On Behalf Of *
> ***@courts.state.va.us
> * Sent:* Wednesday, July 13, 2016 10:23 AM
> * To:* VSE Discussion List <vse-***@lists.lehigh.edu>
> * Subject:* RE: 21st centry [was: no subject]
>
>
> Ahhh the days of the Oscilloscope... talk about sharing knowledge... the
> IBM CE taught me how to use one...
>
> Third shift, 1419 Check reader/sorter....3340 dasd... fun
>
> "...those were the days.........."
>
> Mike
>
> [image: Inactive hide details for "Stuart, David" ---07/13/2016 11:14:51
> AM---It didn't make the hardware support guys (me) all that ha]"Stuart,
> David" ---07/13/2016 11:14:51 AM---It didn't make the hardware support guys
> (me) all that happy, either. Dave
>
> From: "Stuart, David" <***@ventura.org>
> To: VSE Discussion List <vse-***@lists.lehigh.edu>
> Date: 07/13/2016 11:14 AM
> Subject: RE: 21st centry [was: no subject]
> Sent by: "VSE-L" <vse-l-bounces+mriggs=***@lists.lehigh.edu
> >
> ------------------------------
>
>
>
>
>
> It didn’t make the hardware support guys (me) all that happy, either.
>
>
> Dave
>
>
>
> * From:* VSE-L [
> mailto:vse-l-bounces+david.stuart=***@lists.lehigh.edu
> <vse-l-bounces+david.stuart=***@lists.lehigh.edu>] *On Behalf Of *Mike
> Moore
> * Sent:* Wednesday, July 13, 2016 8:13 AM
> * To:* VSE Discussion List <vse-***@lists.lehigh.edu>
> * Subject:* RE: 21st centry [was: no subject]
>
> 
and if you have never experienced removable disks, you have never
> experienced the joy of finding out an operator moved a disk with a
> headcrash to 3 other drives thinking they would work!!!
> Nothing like losing 4 disk drives from one problem. That always set the
> tone for the next few days in the datacenter!!!
>
>
>
>
> Mike Moore
> IT Manager
> Alabama Judicial Datacenter
> 300 Dexter Avenue
> Montgomery, Alabama 36104
> 334-954-5025
>
> “This is the final test of a gentleman: his respect for those who can be
> of no possible service to him.” – William Lyon Phelps
>
> * From:* VSE-L [
> mailto:vse-l-bounces+mike.moore=***@lists.lehigh.edu
> <vse-l-bounces+mike.moore=***@lists.lehigh.edu>] *On Behalf Of *Edward
> M. Martin
> * Sent:* Wednesday, July 13, 2016 10:01 AM
> * To:* VSE Discussion List <vse-***@lists.lehigh.edu>
> * Subject:* RE: 21st centry [was: no subject]
>
> Hello Andy,
>
> Wow, then you never had the experience of the removable 3330 drives?
>
> Edward M. Martin
> Aultman Health Foundation
> HealthQuest
> 330-363-9666
> Internal EXT 39666
> [image: cid:***@selectbs.com]
>
> * From:* VSE-L [
> mailto:vse-l-bounces+edward.martin=***@lists.lehigh.edu
> <vse-l-bounces+edward.martin=***@lists.lehigh.edu>] *On Behalf Of
> *Andy Engels
> * Sent:* Wednesday, July 13, 2016 10:46 AM
> * To:* VSE Discussion List
> * Subject:* Re: 21st centry [was: no subject]
>
> 3350 is before my time on IBM systems..
>
> Sent from my iPhone5
> in Chicago, where the sky was first scraped.....
>
> On Jul 12, 2016, at 18:10, Stuart, David <***@ventura.org>
> wrote:
>
> Andy,
>
> 3420 Mod6 and Mod8 running 2400 foot reels.
>
> The largest disks they had at the time were 3350. They started getting in
> some 3380’s just after I left that site.
>
>
> Dave
>
>
> * From:* VSE-L [
> mailto:vse-l-bounces+david.stuart=***@lists.lehigh.edu
> <vse-l-bounces+david.stuart=***@lists.lehigh.edu>] *On Behalf Of *Andy
> Engels
> * Sent:* Tuesday, July 12, 2016 4:02 PM
> * To:* VSE Discussion List <vse-***@lists.lehigh.edu>
> * Subject:* RE: 21st centry [was: no subject]
>
> Tape drives for journals? Wow. I saw that at a place for the data base
> protection logs. I would have thought that alternating disk files would
> have been a lot cheaper.
>
> A holdover from when disk was much smaller?
>
> ____________________________________
> Andy Engels
> IS Team Leader – Technology Infrastructure
> IMRF
> Oak Brook, IL
> 630-368-5346
>
> * From:* VSE-L [mailto:vse-l-bounces+aengels=***@lists.lehigh.edu
> <vse-l-bounces+aengels=***@lists.lehigh.edu>] *On Behalf Of *Stuart,
> David
> * Sent:* Tuesday, July 12, 2016 2:25 PM
> * To:* VSE Discussion List
> * Subject:* RE: 21st centry [was: no subject]
>
> One place I worked, back in the early 80’s, had 6 CICS regions, I think it
> was. We had a pool of 16 tape drives dedicated to CICS journals. 6 Primary,
> 6 alternate, and 4 ‘hot’ spare. One of the ‘Ma Bell kids’.
>
>
> Dave
>
>
> * From:* VSE-L [
> mailto:vse-l-bounces+david.stuart=***@lists.lehigh.edu
> <vse-l-bounces+david.stuart=***@lists.lehigh.edu>] *On Behalf Of *Andy
> Engels
> * Sent:* Tuesday, July 12, 2016 11:17 AM
> * To:* VSE Discussion List <vse-***@lists.lehigh.edu>
> * Subject:* RE: 21st centry [was: no subject]
>
> How many shops really need hundreds of CICS regions? I can see it for
> large airlines or some huge department store chain but I suspect, for most
> places, one is just fine.
>
> CICS is still CICS and taking advantage of multiple cpus, I’d like to hear
> more on that. Unless IBM has totally rewritten the guts from the ground up
> – which has not been my impression. Although I haven’t kept up at that
> level. I haven’t seen anyone really take advantage of that and I’ve been
> in quite a few VSE shops. Most are still on single processors so the
> multi-CPU thing is kind of mute.
>
>
> ____________________________________
> Andy Engels
> IS Team Leader – Technology Infrastructure
> IMRF
> Oak Brook, IL
> 630-368-5346
>
> * From:* VSE-L [mailto:vse-l-bounces+aengels=***@lists.lehigh.edu
> <vse-l-bounces+aengels=***@lists.lehigh.edu>] *On Behalf Of *Mick
> Poil
> * Sent:* Tuesday, July 12, 2016 12:21 PM
> * To:* VSE Discussion List
> * Subject:* RE: 21st centry [was: no subject]
>
>
> Re comments on relative capacities, z/OS sites can run 100's of CICS
> regions concurrently and still return very fast response times. CICS
> transactions can take full advantage of multiple CPs and CICS z/OS has
> other performance benefits due to the use of the available z/OS facilities
> and CICS design changes.
>
> Under the covers, CICS is extremely OS aware.
>
> z/OS is very expensive, although I can't be sure of the multiplier of the
> equivalent VSE price.
> _______________________________________________
> VSE-L mailing list
> VSE-***@lists.lehigh.edu
> https://lists.lehigh.edu/mailman/listinfo/vse-l
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2flists.lehigh.edu%2fmailman%2flistinfo%2fvse-l&data=01%7c01%7cEdward.Martin%40aultman.com%7c2f2f62a4fcd7422eb2d408d3ab2c7ce9%7cb91830d1006447288b5657e8943c3565%7c0&sdata=rokT%2ff5kYh9Oi5hNlq2OFzkCuAFm0hSxniADZWBp8RA%3d>
>
>
> * CONFIDENTIALITY NOTICE:* This e-mail (including the information it
> contains and attachments) is a business communication intended for the
> authorized use by the person who requested it, or for the authorized use by
> the intended recipient to perform an employment duty or business function.
> This e-mail may contain confidential, privileged, or proprietary
> information, including (but not limited to) Protected Health Information
> covered by the Health Insurance Portability and Accountability Act (HIPAA).
> It also may be protected by the Electronic Communications Act. If you
> received this e-mail by mistake, either directly or inadvertently as a
> recipient on a copied or forwarded e-mail, promptly notify us by return
> e-mail. Destroy this e-mail, the information, and attachments you received
> by mistake. You must not print, use, forward, or disclose to any third
> party by electronic, written or oral means any information you received by
> mistake. We do not waive any privilege. We may take legal steps or other
> appropriate action, as needed, to protect the confidentiality and privilege
> of any information inadvertently disclosed.
> _______________________________________________
> VSE-L mailing list
> VSE-***@lists.lehigh.edu
> https://lists.lehigh.edu/mailman/listinfo/vse-l
> _______________________________________________
> VSE-L mailing list
> VSE-***@lists.lehigh.edu
> https://lists.lehigh.edu/mailman/listinfo/vse-l
>
> _______________________________________________
> VSE-L mailing list
> VSE-***@lists.lehigh.edu
> https://lists.lehigh.edu/mailman/listinfo/vse-l
>
>

[Steve Huggins]

We called them Reader/sorters at the Bank I worked at...

Huggy

On Wed, Jul 13, 2016 at 4:47 PM, August Carideo/RYE/US <
***@avon.com> wrote:

> That’s it , had crs, but should have known it was just up from 1403
>
>
>
> *From:* VSE-L [mailto:vse-l-bounces+august.carideo=
> ***@lists.lehigh.edu] *On Behalf Of *Chuck Arney
> *Sent:* Wednesday, July 13, 2016 3:42 PM
> *To:* VSE Discussion List <vse-***@lists.lehigh.edu>
> *Subject:* Re: 21st centry [was: no subject]
>
>
>
> That was a 1419.
>
> Chuck Arney
>
>
> On Jul 13, 2016, at 1:59 PM, August Carideo/RYE/US <
> ***@avon.com> wrote:
>
> Was nothing louder than the 2019 check sorters , or were they 3890’s was
> at bank I started at in 1978
>
> By time required to use ear protectors was too late for some
>
>
>
> *From:* VSE-L [
> mailto:vse-l-bounces+august.carideo=***@lists.lehigh.edu
> <vse-l-bounces+august.carideo=***@lists.lehigh.edu>] *On Behalf Of *Mike
> Moore
> *Sent:* Wednesday, July 13, 2016 1:02 PM
> *To:* VSE Discussion List <vse-***@lists.lehigh.edu>
> *Subject:* RE: 21st centry [was: no subject]
>
>
>
> Yep, between the 1403 and the 2 3211s we could drown out just about any
> noise we wanted to!
>
> Had an operator that loved to stick listings on the tops of the 3211s
> while he was doing other things. Forms would run out, cover would lift and
> the 3211 turned into a dump truck.
>
>
>
>
>
>
>
>
>
> Mike Moore
>
> IT Manager
>
> Alabama Judicial Datacenter
>
> 300 Dexter Avenue
>
> Montgomery, Alabama 36104
>
> 334-954-5025
>
>
>
> “This is the final test of a gentleman: his respect for those who can be
> of no possible service to him.” – William Lyon Phelps
>
>
>
> *From:* VSE-L [
> mailto:vse-l-bounces+mike.moore=***@lists.lehigh.edu
> <vse-l-bounces+mike.moore=***@lists.lehigh.edu>] *On Behalf Of *
> ***@courts.state.va.us
> *Sent:* Wednesday, July 13, 2016 11:10 AM
> *To:* VSE Discussion List <vse-***@lists.lehigh.edu>
> *Subject:* RE: 21st centry [was: no subject]
>
>
>
> We countered the noise by running the 1403 printer with the cover up
> (tape covering the interlock)
>
> <image001.gif>Mike Moore ---07/13/2016 11:37:22 AM---Running a 1419 was
> just about like running a steam engine! Lots of air and noise! Mike Moore
>
> From: Mike Moore <***@alacourt.gov>
> To: VSE Discussion List <vse-***@lists.lehigh.edu>
> Date: 07/13/2016 11:37 AM
> Subject: RE: 21st centry [was: no subject]
> Sent by: "VSE-L" <vse-l-bounces+mriggs=***@lists.lehigh.edu
> >
> ------------------------------
>
>
>
>
> Running a 1419 was just about like running a steam engine! Lots of air and
> noise!
>
>
>
>
> Mike Moore
> IT Manager
> Alabama Judicial Datacenter
> 300 Dexter Avenue
> Montgomery, Alabama 36104
> 334-954-5025
>
> “This is the final test of a gentleman: his respect for those who can be
> of no possible service to him.” – William Lyon Phelps
>
> *From:* VSE-L [
> mailto:vse-l-bounces+mike.moore=***@lists.lehigh.edu
> <vse-l-bounces+mike.moore=***@lists.lehigh.edu>] *On Behalf Of *
> ***@courts.state.va.us
> * Sent:* Wednesday, July 13, 2016 10:23 AM
> * To:* VSE Discussion List <vse-***@lists.lehigh.edu>
> * Subject:* RE: 21st centry [was: no subject]
>
>
> Ahhh the days of the Oscilloscope... talk about sharing knowledge... the
> IBM CE taught me how to use one...
>
> Third shift, 1419 Check reader/sorter....3340 dasd... fun
>
> "...those were the days.........."
>
> Mike
>
> <image001.gif>"Stuart, David" ---07/13/2016 11:14:51 AM---It didn't make
> the hardware support guys (me) all that happy, either. Dave
>
> From: "Stuart, David" <***@ventura.org>
> To: VSE Discussion List <vse-***@lists.lehigh.edu>
> Date: 07/13/2016 11:14 AM
> Subject: RE: 21st centry [was: no subject]
> Sent by: "VSE-L" <vse-l-bounces+mriggs=***@lists.lehigh.edu
> >
> ------------------------------
>
>
>
>
>
> It didn’t make the hardware support guys (me) all that happy, either.
>
>
> Dave
>
>
>
> * From:* VSE-L [
> mailto:vse-l-bounces+david.stuart=***@lists.lehigh.edu
> <vse-l-bounces+david.stuart=***@lists.lehigh.edu>] *On Behalf Of *Mike
> Moore
> * Sent:* Wednesday, July 13, 2016 8:13 AM
> * To:* VSE Discussion List <vse-***@lists.lehigh.edu>
> * Subject:* RE: 21st centry [was: no subject]
>
> 
and if you have never experienced removable disks, you have never
> experienced the joy of finding out an operator moved a disk with a
> headcrash to 3 other drives thinking they would work!!!
> Nothing like losing 4 disk drives from one problem. That always set the
> tone for the next few days in the datacenter!!!
>
>
>
>
> Mike Moore
> IT Manager
> Alabama Judicial Datacenter
> 300 Dexter Avenue
> Montgomery, Alabama 36104
> 334-954-5025
>
> “This is the final test of a gentleman: his respect for those who can be
> of no possible service to him.” – William Lyon Phelps
>
> * From:* VSE-L [
> mailto:vse-l-bounces+mike.moore=***@lists.lehigh.edu
> <vse-l-bounces+mike.moore=***@lists.lehigh.edu>] *On Behalf Of *Edward
> M. Martin
> * Sent:* Wednesday, July 13, 2016 10:01 AM
> * To:* VSE Discussion List <vse-***@lists.lehigh.edu>
> * Subject:* RE: 21st centry [was: no subject]
>
> Hello Andy,
>
> Wow, then you never had the experience of the removable 3330 drives?
>
> Edward M. Martin
> Aultman Health Foundation
> HealthQuest
> 330-363-9666
> Internal EXT 39666
> <image002.png>
>
> * From:* VSE-L [
> mailto:vse-l-bounces+edward.martin=***@lists.lehigh.edu
> <vse-l-bounces+edward.martin=***@lists.lehigh.edu>] *On Behalf Of
> *Andy Engels
> * Sent:* Wednesday, July 13, 2016 10:46 AM
> * To:* VSE Discussion List
> * Subject:* Re: 21st centry [was: no subject]
>
> 3350 is before my time on IBM systems..
>
> Sent from my iPhone5
> in Chicago, where the sky was first scraped.....
>
> On Jul 12, 2016, at 18:10, Stuart, David <***@ventura.org>
> wrote:
>
> Andy,
>
> 3420 Mod6 and Mod8 running 2400 foot reels.
>
> The largest disks they had at the time were 3350. They started getting in
> some 3380’s just after I left that site.
>
>
> Dave
>
>
> * From:* VSE-L [
> mailto:vse-l-bounces+david.stuart=***@lists.lehigh.edu
> <vse-l-bounces+david.stuart=***@lists.lehigh.edu>] *On Behalf Of *Andy
> Engels
> * Sent:* Tuesday, July 12, 2016 4:02 PM
> * To:* VSE Discussion List <vse-***@lists.lehigh.edu>
> * Subject:* RE: 21st centry [was: no subject]
>
> Tape drives for journals? Wow. I saw that at a place for the data base
> protection logs. I would have thought that alternating disk files would
> have been a lot cheaper.
>
> A holdover from when disk was much smaller?
>
> ____________________________________
> Andy Engels
> IS Team Leader – Technology Infrastructure
> IMRF
> Oak Brook, IL
> 630-368-5346
>
> * From:* VSE-L [mailto:vse-l-bounces+aengels=***@lists.lehigh.edu
> <vse-l-bounces+aengels=***@lists.lehigh.edu>] *On Behalf Of *Stuart,
> David
> * Sent:* Tuesday, July 12, 2016 2:25 PM
> * To:* VSE Discussion List
> * Subject:* RE: 21st centry [was: no subject]
>
> One place I worked, back in the early 80’s, had 6 CICS regions, I think it
> was. We had a pool of 16 tape drives dedicated to CICS journals. 6 Primary,
> 6 alternate, and 4 ‘hot’ spare. One of the ‘Ma Bell kids’.
>
>
> Dave
>
>
> * From:* VSE-L [
> mailto:vse-l-bounces+david.stuart=***@lists.lehigh.edu
> <vse-l-bounces+david.stuart=***@lists.lehigh.edu>] *On Behalf Of *Andy
> Engels
> * Sent:* Tuesday, July 12, 2016 11:17 AM
> * To:* VSE Discussion List <vse-***@lists.lehigh.edu>
> * Subject:* RE: 21st centry [was: no subject]
>
> How many shops really need hundreds of CICS regions? I can see it for
> large airlines or some huge department store chain but I suspect, for most
> places, one is just fine.
>
> CICS is still CICS and taking advantage of multiple cpus, I’d like to hear
> more on that. Unless IBM has totally rewritten the guts from the ground up
> – which has not been my impression. Although I haven’t kept up at that
> level. I haven’t seen anyone really take advantage of that and I’ve been
> in quite a few VSE shops. Most are still on single processors so the
> multi-CPU thing is kind of mute.
>
>
> ____________________________________
> Andy Engels
> IS Team Leader – Technology Infrastructure
> IMRF
> Oak Brook, IL
> 630-368-5346
>
> * From:* VSE-L [mailto:vse-l-bounces+aengels=***@lists.lehigh.edu
> <vse-l-bounces+aengels=***@lists.lehigh.edu>] *On Behalf Of *Mick
> Poil
> * Sent:* Tuesday, July 12, 2016 12:21 PM
> * To:* VSE Discussion List
> * Subject:* RE: 21st centry [was: no subject]
>
>
> Re comments on relative capacities, z/OS sites can run 100's of CICS
> regions concurrently and still return very fast response times. CICS
> transactions can take full advantage of multiple CPs and CICS z/OS has
> other performance benefits due to the use of the available z/OS facilities
> and CICS design changes.
>
> Under the covers, CICS is extremely OS aware.
>
> z/OS is very expensive, although I can't be sure of the multiplier of the
> equivalent VSE price.
> _______________________________________________
> VSE-L mailing list
> VSE-***@lists.lehigh.edu
> https://lists.lehigh.edu/mailman/listinfo/vse-l
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2flists.lehigh.edu%2fmailman%2flistinfo%2fvse-l&data=01%7c01%7cEdward.Martin%40aultman.com%7c2f2f62a4fcd7422eb2d408d3ab2c7ce9%7cb91830d1006447288b5657e8943c3565%7c0&sdata=rokT%2ff5kYh9Oi5hNlq2OFzkCuAFm0hSxniADZWBp8RA%3d>
>
>
> * CONFIDENTIALITY NOTICE:* This e-mail (including the information it
> contains and attachments) is a business communication intended for the
> authorized use by the person who requested it, or for the authorized use by
> the intended recipient to perform an employment duty or business function.
> This e-mail may contain confidential, privileged, or proprietary
> information, including (but not limited to) Protected Health Information
> covered by the Health Insurance Portability and Accountability Act (HIPAA).
> It also may be protected by the Electronic Communications Act. If you
> received this e-mail by mistake, either directly or inadvertently as a
> recipient on a copied or forwarded e-mail, promptly notify us by return
> e-mail. Destroy this e-mail, the information, and attachments you received
> by mistake. You must not print, use, forward, or disclose to any third
> party by electronic, written or oral means any information you received by
> mistake. We do not waive any privilege. We may take legal steps or other
> appropriate action, as needed, to protect the confidentiality and privilege
> of any information inadvertently disclosed.
> _______________________________________________
> VSE-L mailing list
> VSE-***@lists.lehigh.edu
> https://lists.lehigh.edu/mailman/listinfo/vse-l
> _______________________________________________
> VSE-L mailing list
> VSE-***@lists.lehigh.edu
> https://lists.lehigh.edu/mailman/listinfo/vse-l
>
> _______________________________________________
> VSE-L mailing list
> VSE-***@lists.lehigh.edu
> https://lists.lehigh.edu/mailman/listinfo/vse-l
>
> _______________________________________________
> VSE-L mailing list
> VSE-***@lists.lehigh.edu
> https://lists.lehigh.edu/mailman/listinfo/vse-l
>
>
> _______________________________________________
> VSE-L mailing list
> VSE-***@lists.lehigh.edu
> https://lists.lehigh.edu/mailman/listinfo/vse-l
>
>

[a***@isbco.com]

Yes, I remember the CRAM JAM, not a nice thing to see with all of the strips wadded up.

Aubrey Hayes

[Shawn Legrand]

When I calculate the P/NP ratio using 3 CP running capped at 200 MIPS it is showing we require 3 CP. No matter how much work we have pushed through, it always seems to indicate that it will use 3 CP.

This appears to substantiate that 3 CP is the limit for parallel work on a zVSE.

Note:
We are running 5 CICS in dynamic partitions and run most of our batch in 4 fixed partitions. I have configured each partition in its own address space.

Shawn Legrand
ICW Group




________________________________________
From: VSE-L [vse-l-bounces+slegrand=***@lists.lehigh.edu] on behalf of Ken and Mary Meyer [***@gmail.com]
Sent: Thursday, July 14, 2016 1:44 PM
To: VSE Discussion List
Subject: Re: 21st centry [was: no subject]

For z/VSE, multiple CPUs are useful for two partitions to be able to run at
the same time in parallel. This ability could help two CICS, two batch, or
one of each to run better, provided the requirement for non-parallel processing
is minimized and the two partitions use resources that are minimally shared
between the partitions. In the case where three CPUs are active, it is rare for
all three to be utilized effectively without diminishing returns.

For z/VSE to run multiple CPUs for a single partition, it would take a
monumental
amount of work to support by IBM and vendors, both of which must keep their
costs to a minimum to allow the platform to continue. Over the years I made
several changes to products that would allow them to run in multiple partitions
and reduce non-parallel requirements, allowing multiple CPUs to be used more
effectively. Such strategies are more useful for z/VSE exploitation of multiple
CPUs than attempting to allow multiple tasks to run simultaneously in a single
partition, plus it does not require changes to the operating system, itself.

Although old, the z/VSE locking mechanism is still very powerful. If
you are using
locking within a single LPAR, it is very fast and still easy to use.
You can create
a lock of an imaginary resource if you wish. If you take a look at
what IBM uses
it for, you will see some really neat stuff. :)

Ken


On Thu, Jul 14, 2016 at 2:13 PM, Mick Poil <***@gmail.com>
snip..

[i***@winwholesale.com]

"VSE-L" <vse-l-bounces+industrynews=***@lists.lehigh.edu>
wrote on 07/15/2016 11:53:27 AM:
> That being said, sure recognize their efforts and thank them; but
> where it is to the long term benefit of the person who signs our
> paychecks to point out IBM's failures - do it.

The point is that IBM has *not* failed. You have.

> In the end, I owe my allegiance to my employer, not to IBM.

You owe yourself (and your employer) some allegiance to using your
brain properly. It is not IBM's failure that you need more than z/VSE
offers. You want more? Install z/OS. z/VSE has its niche, z/VM has its
niche, z/Linux has its niche, etc., and z/OS has the rest. IBM is a
business -- not your genie. There is no business reason for IBM to offer
two operating systems that compete in the same arena.

This started because you said z/VSE is not a 21st century
operating system and, in that, you are dead wrong. Does z/VSE have
anything close to the bells and whistles z/OS has? No, and it shouldn't.
You don't want to wait for IBM to add more bells and whistles to z/VSE as
IBM makes its own determination for a business case for them? Fine,
install z/OS instead.

But, z/VSE *is* a 21st century operating system in its own niche.
Period.

Sincerely,

Dave Clark
--
Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio 45439 USA
[phone]




*********************************************************************************************
This email message and any attachments is for use only by the named
addressee(s) and may contain confidential, privileged and/or proprietary
information. If you have received this message in error, please
immediately notify the sender and delete and destroy the message and all
copies. All unauthorized direct or indirect use or disclosure of this
message is strictly prohibited. No right to confidentiality or privilege
is waived or lost by any error in transmission.
*********************************************************************************************

[Mick Poil]

Going back to Shawn's update. I saw one native VSE system close to its
limit where the NP ratio of the workload meant that it would probably have
run on just 2 of the 3 cpus and performed much the same.

NP can be an issue. For those who attended my WAVV CICS performance
presentations where I mentioned the simple MONPTN program that shows
dispatchable % versus cpu % to highlight a cpu constraint, I had to adapt
it to add approximate % spent in an NP state in order to explain to a
customer why CICS response was bad when cpu availability was not an issue
but CICS cpu usage was going down and response was going up.

Mike.

[i***@winwholesale.com]

"VSE-L" <vse-l-bounces+industrynews=***@lists.lehigh.edu>
wrote on 07/15/2016 01:05:45 PM:
> Why are you such a cheerleader for VSE? Take a look at the facts,
> people vote with their feet... there is a slow but steady movement from
VSE.

And you are welcome to do the same. All that vote means is that
something (not necessarily VSE) is not fulfilling those particular
company's needs. That vote doesn't mean that VSE is not a 21st century
operating system. IBM has succeeded in bringing z/VSE into the 21st
century. It's not about being a cheerleader for VSE. It is about being
fair, reasonable, and honest.

My company has no complaints about VSE at all. It offers
everything we need -- and we are a 2+ billion dollar company spread all
across the United States. Are we in the process of moving away from VSE?
Yes, but not because either VSE or IBM has failed to meet our needs. We
just happen to have 2 IBM platforms and have chosen the other platform on
which to consolidate. Also note that platform was not chosen based on
hardware or operating system. It was chosen based on where most of our
in-house-developed software portfolio resides.

Sincerely,

Dave Clark
--
Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio 45439 USA
[phone]




*********************************************************************************************
This email message and any attachments is for use only by the named
addressee(s) and may contain confidential, privileged and/or proprietary
information. If you have received this message in error, please
immediately notify the sender and delete and destroy the message and all
copies. All unauthorized direct or indirect use or disclosure of this
message is strictly prohibited. No right to confidentiality or privilege
is waived or lost by any error in transmission.
*********************************************************************************************

[Mick Poil]

I am sorry, but I can't see how pursuing this kind of discussion is going
to change anything in VSE one iota.

On Fri, Jul 15, 2016 at 6:05 PM, Lou Winston <***@live.com> wrote:

> Why are you such a cheerleader for VSE? Take a look at the facts, people
> vote with their feet... there is a slow but steady movement from VSE.
>
> It would be better for everyone if any operating system is evaluated
> without bias.
>
>
> You say, that it makes no sense for IBM to offer two operating systems
> that compete in the same arena... Does it make sense for General Motors or
> Ford to offer multiple competing automobile lines? You bet it does. Been
> to a supermarket lately? how many laundry detergents does P&G offer?
>
>
> You are defeated by your own logic... you state that it doesn't make sense
> for IBM to offer two operating systems that compete.... so where exactly
> does VSE fit into that situation?
>
>
>
>
>
> ------------------------------
> *From:* VSE-L <vse-l-bounces+lewinston=***@lists.lehigh.edu> on
> behalf of ***@winwholesale.com <***@winwholesale.com>
> *Sent:* Friday, July 15, 2016 12:24 PM
> *To:* VSE Discussion List
> *Subject:* Re: 21st centry [was: no subject]
>
> "VSE-L" <vse-l-bounces+industrynews=***@lists.lehigh.edu>
> wrote on 07/15/2016 11:53:27 AM:
> > That being said, sure recognize their efforts and thank them; but
> > where it is to the long term benefit of the person who signs our
> > paychecks to point out IBM's failures - do it.
>
> The point is that IBM has *not* failed. You have.
>
> > In the end, I owe my allegiance to my employer, not to IBM.
>
> You owe yourself (and your employer) some allegiance to using your
> brain properly. It is not IBM's failure that you need more than z/VSE
> offers. You want more? Install z/OS. z/VSE has its niche, z/VM has its
> niche, z/Linux has its niche, etc., and z/OS has the rest. IBM is a
> business -- not your genie. There is no business reason for IBM to offer
> two operating systems that compete in the same arena.
>
> This started because you said z/VSE is not a 21st century
> operating system and, in that, you are dead wrong. Does z/VSE have
> anything close to the bells and whistles z/OS has? No, and it shouldn't.
> You don't want to wait for IBM to add more bells and whistles to z/VSE as
> IBM makes its own determination for a business case for them? Fine,
> install z/OS instead.
>
> But, z/VSE *is* a 21st century operating system in its own niche.
> Period.
>
> Sincerely,
>
> Dave Clark
> --
> Winsupply Group Services
> 3110 Kettering Boulevard
> Dayton, Ohio 45439 USA
> [phone]
>
>
>
>
>
> *********************************************************************************************
> This email message and any attachments is for use only by the named
> addressee(s) and may contain confidential, privileged and/or proprietary
> information. If you have received this message in error, please immediately
> notify the sender and delete and destroy the message and all copies. All
> unauthorized direct or indirect use or disclosure of this message is
> strictly prohibited. No right to confidentiality or privilege is waived or
> lost by any error in transmission.
>
> *********************************************************************************************
>
> _______________________________________________
> VSE-L mailing list
> VSE-***@lists.lehigh.edu
> https://lists.lehigh.edu/mailman/listinfo/vse-l
>
>

[Tom Huegel]

Whether you drive a Bentley a Ford Focus or a Dodge Hellcat they all get
you from point A to point B and each has it's advantages over the others.
Fifty years the Ford is what I could afford, 25 years ago the Dodge would
have lit my fire, but today I'd rather be in the Bentley.

z/VSE, z/OS, z/VM, LINUX, WINDOWS they all have there place (ok maybe not
windows) and as times change our OS of choice may change too.

On Fri, Jul 15, 2016 at 10:37 AM, Jeffrey Barnard <***@bsiopti.com>
wrote:

> Lou,
>
> Don't confuse the CICS TS Lock Manager Domain and its internal CICS TS
> resource serialization with the z/VSE LOCK Macro. They are different things
> with different uses. The z/OS SETLOCK used within CICS TS is supported
> within z/VSE as is the native z/VSE LOCK facility.
>
> Truly, if you need something this badly, submit a request to IBM. Provide
> a strong business case and include why it would useful to other z/VSE
> customers. That is what makes things happen.
>
> To be honest, when it comes to money and resource allocation in the z/VSE
> lab there are other things I would suggest they work on adding to z/VSE.
> Multiple CPU support within a single partition would be pretty low on my
> priority list (if it made the list at all).
>
> A modern C runtime environment, for example, would be far more useful.
> With it, massive amounts of software could be ported to z/VSE easily and
> quickly.
>
> Folks complain that z/VSE does not have the new applications it needs for
> growth. A modern C runtime when be the foundation here.
>
> Jeff
>
>
> _______________________________________________
> VSE-L mailing list
> VSE-***@lists.lehigh.edu
> https://lists.lehigh.edu/mailman/listinfo/vse-l
>

[Mick Poil]

Erm . . . . VSE is not 51 years old yet ;-)

On Fri, Jul 15, 2016 at 8:56 PM, Andy Engels <***@imrf.org> wrote:

> VSE has been dying for 50 years – like when everyone would move to the
> “real” OS.
>
>
>
> ____________________________________
>
> Andy Engels
> IS Team Leader – Technology Infrastructure
> IMRF
> Oak Brook, IL
> 630-368-5346
>
>
>
> *From:* VSE-L [mailto:vse-l-bounces+aengels=***@lists.lehigh.edu] *On
> Behalf Of *Lou Winston
> *Sent:* Friday, July 15, 2016 12:06 PM
>
> *To:* VSE Discussion List
> *Subject:* Re: 21st centry [was: no subject]
>
>
>
> Why are you such a cheerleader for VSE? Take a look at the facts, people
> vote with their feet... there is a slow but steady movement from VSE.
>
> It would be better for everyone if any operating system is evaluated
> without bias.
>
>
>
> You say, that it makes no sense for IBM to offer two operating systems
> that compete in the same arena... Does it make sense for General Motors or
> Ford to offer multiple competing automobile lines? You bet it does. Been
> to a supermarket lately? how many laundry detergents does P&G offer?
>
>
>
> You are defeated by your own logic... you state that it doesn't make sense
> for IBM to offer two operating systems that compete.... so where exactly
> does VSE fit into that situation?
>
>
>
>
>
>
> ------------------------------
>
> *From:* VSE-L <vse-l-bounces+lewinston=***@lists.lehigh.edu> on
> behalf of ***@winwholesale.com <***@winwholesale.com>
> *Sent:* Friday, July 15, 2016 12:24 PM
> *To:* VSE Discussion List
> *Subject:* Re: 21st centry [was: no subject]
>
>
>
> "VSE-L" <vse-l-bounces+industrynews=***@lists.lehigh.edu>
> wrote on 07/15/2016 11:53:27 AM:
> > That being said, sure recognize their efforts and thank them; but
> > where it is to the long term benefit of the person who signs our
> > paychecks to point out IBM's failures - do it.
>
> The point is that IBM has *not* failed. You have.
>
> > In the end, I owe my allegiance to my employer, not to IBM.
>
> You owe yourself (and your employer) some allegiance to using your
> brain properly. It is not IBM's failure that you need more than z/VSE
> offers. You want more? Install z/OS. z/VSE has its niche, z/VM has its
> niche, z/Linux has its niche, etc., and z/OS has the rest. IBM is a
> business -- not your genie. There is no business reason for IBM to offer
> two operating systems that compete in the same arena.
>
> This started because you said z/VSE is not a 21st century
> operating system and, in that, you are dead wrong. Does z/VSE have
> anything close to the bells and whistles z/OS has? No, and it shouldn't.
> You don't want to wait for IBM to add more bells and whistles to z/VSE as
> IBM makes its own determination for a business case for them? Fine,
> install z/OS instead.
>
> But, z/VSE *is* a 21st century operating system in its own niche.
> Period.
>
> Sincerely,
>
> Dave Clark
> --
> Winsupply Group Services
> 3110 Kettering Boulevard
> Dayton, Ohio 45439 USA
> [phone]
>
>
>
>
>
> *********************************************************************************************
> This email message and any attachments is for use only by the named
> addressee(s) and may contain confidential, privileged and/or proprietary
> information. If you have received this message in error, please immediately
> notify the sender and delete and destroy the message and all copies. All
> unauthorized direct or indirect use or disclosure of this message is
> strictly prohibited. No right to confidentiality or privilege is waived or
> lost by any error in transmission.
>
> *********************************************************************************************
>
> _______________________________________________
> VSE-L mailing list
> VSE-***@lists.lehigh.edu
> https://lists.lehigh.edu/mailman/listinfo/vse-l
>
>

[Martin Truebner]

Mick,

>> Erm . . . . VSE is not 51 years old yet ;-)

Oups- are you saying that the party a year ago (and the botton saying
"z/VSE 50") was all wrong? ;-)

Martin

40 and 50 - I was there and have the buttons to prove it.

[Mick Poil]

No, I was commenting on VSE dying for 50 years.

[Ken and Mary Meyer]

VSE got its second wind when IBM decided it made sense to work with
vendors instead of against, long ago.. :)

Ken


On Sun, Jul 17, 2016 at 2:13 PM, Mick Poil <***@gmail.com> wrote:
> No, I was commenting on VSE dying for 50 years.
>
>
> _______________________________________________
> VSE-L mailing list
> VSE-***@lists.lehigh.edu
> https://lists.lehigh.edu/mailman/listinfo/vse-l
>

[Mick Poil]

There is "Locking", and then there is "Locking".

VSE LOCK/UNLOCK is equivalent to an "ENQ/DEQ" for named resources with
owner/waiter queues, and is not designed to do what SETLOCK does, which is
to single-thread certain (CICS TS z/OS) activities within and across
Address Spaces. CICS TS VSE already does some of that using the traditional
CDS locks.

CICS Open TCB support is a whole different ball game. It would never have
been an option for VSE even had the code been there at the time CICS/ESA
4.1 was migrated.

Mike

[Tom Huegel]

Everyone knows this but a big reason mainframes are losing popularity is
the scarcity of talent. A company places an add for a z/VSE sysprog and
they are lucky to get one or two responses from a bored retiree. Place the
same add for a windows admin and the response will be overwhelming.
The 'z' systems just isn't taught in many schools anymore. Young people
have no way to learn about 'x'.

I would like to see some form of z/VSE that could be run on someone's home
PC (under Hercules would be OK). This would allow curious young people to
get involved and learn the systems.
I'm not sure how this would work since we wouldn't want to hurt IBM's
revenue, but in the long run it would be good for them.

On Mon, Jul 18, 2016 at 10:06 AM, Lou Winston <***@live.com> wrote:

> Probably not. What, in your estimation can improve the fate of VSE?
>
>
> L.W.
>
>
> ------------------------------
> *From:* VSE-L <vse-l-bounces+lewinston=***@lists.lehigh.edu> on
> behalf of Mick Poil <***@gmail.com>
> *Sent:* Friday, July 15, 2016 1:42 PM
>
> *To:* VSE Discussion List
> *Subject:* Re: 21st centry [was: no subject]
>
> I am sorry, but I can't see how pursuing this kind of discussion is going
> to change anything in VSE one iota.
>
> On Fri, Jul 15, 2016 at 6:05 PM, Lou Winston <***@live.com> wrote:
>
>> Why are you such a cheerleader for VSE? Take a look at the facts, people
>> vote with their feet... there is a slow but steady movement from VSE.
>>
>> It would be better for everyone if any operating system is evaluated
>> without bias.
>>
>>
>> You say, that it makes no sense for IBM to offer two operating systems
>> that compete in the same arena... Does it make sense for General Motors or
>> Ford to offer multiple competing automobile lines? You bet it does. Been
>> to a supermarket lately? how many laundry detergents does P&G offer?
>>
>>
>> You are defeated by your own logic... you state that it doesn't make
>> sense for IBM to offer two operating systems that compete.... so where
>> exactly does VSE fit into that situation?
>>
>>
>>
>>
>>
>> ------------------------------
>> *From:* VSE-L <vse-l-bounces+lewinston=***@lists.lehigh.edu> on
>> behalf of ***@winwholesale.com <***@winwholesale.com>
>> *Sent:* Friday, July 15, 2016 12:24 PM
>> *To:* VSE Discussion List
>> *Subject:* Re: 21st centry [was: no subject]
>>
>> "VSE-L" <vse-l-bounces+industrynews=***@lists.lehigh.edu>
>> wrote on 07/15/2016 11:53:27 AM:
>> > That being said, sure recognize their efforts and thank them; but
>> > where it is to the long term benefit of the person who signs our
>> > paychecks to point out IBM's failures - do it.
>>
>> The point is that IBM has *not* failed. You have.
>>
>> > In the end, I owe my allegiance to my employer, not to IBM.
>>
>> You owe yourself (and your employer) some allegiance to using
>> your brain properly. It is not IBM's failure that you need more than z/VSE
>> offers. You want more? Install z/OS. z/VSE has its niche, z/VM has its
>> niche, z/Linux has its niche, etc., and z/OS has the rest. IBM is a
>> business -- not your genie. There is no business reason for IBM to offer
>> two operating systems that compete in the same arena.
>>
>> This started because you said z/VSE is not a 21st century
>> operating system and, in that, you are dead wrong. Does z/VSE have
>> anything close to the bells and whistles z/OS has? No, and it shouldn't.
>> You don't want to wait for IBM to add more bells and whistles to z/VSE as
>> IBM makes its own determination for a business case for them? Fine,
>> install z/OS instead.
>>
>> But, z/VSE *is* a 21st century operating system in its own
>> niche. Period.
>>
>> Sincerely,
>>
>> Dave Clark
>> --
>> Winsupply Group Services
>> 3110 Kettering Boulevard
>> Dayton, Ohio 45439 USA
>> [phone]
>>
>>
>>
>>
>>
>> *********************************************************************************************
>> This email message and any attachments is for use only by the named
>> addressee(s) and may contain confidential, privileged and/or proprietary
>> information. If you have received this message in error, please immediately
>> notify the sender and delete and destroy the message and all copies. All
>> unauthorized direct or indirect use or disclosure of this message is
>> strictly prohibited. No right to confidentiality or privilege is waived or
>> lost by any error in transmission.
>>
>> *********************************************************************************************
>>
>> _______________________________________________
>> VSE-L mailing list
>> VSE-***@lists.lehigh.edu
>> https://lists.lehigh.edu/mailman/listinfo/vse-l
>>
>>
>
> _______________________________________________
> VSE-L mailing list
> VSE-***@lists.lehigh.edu
> https://lists.lehigh.edu/mailman/listinfo/vse-l
>
>

[i***@winwholesale.com]

"VSE-L" <vse-l-bounces+industrynews=***@lists.lehigh.edu>
wrote on 07/19/2016 08:04:12 PM:
> Is an AS400 or ISeries considered a mainframe , its call an AS400

Referring to an IBMi series machine as an AS/400 is like referring
to a z10 as an S/360.

Sincerely,

Dave Clark
--
Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio 45439 USA
[phone]




*********************************************************************************************
This email message and any attachments is for use only by the named
addressee(s) and may contain confidential, privileged and/or proprietary
information. If you have received this message in error, please
immediately notify the sender and delete and destroy the message and all
copies. All unauthorized direct or indirect use or disclosure of this
message is strictly prohibited. No right to confidentiality or privilege
is waived or lost by any error in transmission.
*********************************************************************************************

[g***@rzd.co.at]

Hello,

we are now on a BC/12 with z/VM 6.3 and z/VSE 5.2 - ;we will no more update
the system because our firm was bought and the buyer has a aix-solution
where he wants to include our business.

My first job was at the end of 1983 a native VSE/IPOE on a actual IBM 4312
with 3340-disks.
POWER was started reading a card-job and had as addon POQUE - not only one
time when the power-cards were read that they flyed through the room. But
they were numbered so they could be sorted again.

with best regards
Gerhard




Von: Lou Winston <***@live.com>
An: VSE Discussion List <vse-***@lists.lehigh.edu>
Datum: 12.07.2016 15:59
Betreff: Re:
Gesendet von: "VSE-L" <vse-l-bounces
+gerhard.tatschl=***@lists.lehigh.edu>



Now why would a company "in the 21st century" be running VSE? Think about
it.
L.W.





From: VSE-L <vse-l-bounces+lewinston=***@lists.lehigh.edu> on behalf
of Farmer, Mike <***@commauto.com>
Sent: Friday, July 8, 2016 2:30 PM
To: VSE Discussion List
Subject: RE:

I guess I'll keep dreaming for a company that is in the 21st century in
thinking.

Michael Farmer
Systems Programmer
Phone | 617.880.2361
Email | ***@commauto.com | www.commauto.com
--------------------------------------------------------------------------------------------------------------------------------------
Commonwealth Automobile Reinsurers
www.commauto.com
Private Passenger Residual Market Rates Placed on File Rate Pages are now available on the MAIP Company and Producer pages of CAR’s
website, under Manuals.
--------------------------------------------------------------------------------------------------------------------------------------







Commonwealth Automobile Reinsurers
225 Franklin Street Boston, MA 02110
________________________________________________________________________
Confidentiality Notice: This e-mail message, including any attachments, is
for the sole use of the intended
recipient(s) and may contain confidential and/or privileged information.
Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender
by reply e-mail and destroy all copies of the original message.


-----Original Message-----
From: VSE-L [mailto:vse-l-bounces+mfarmer=***@lists.lehigh.edu] On
Behalf Of Shawn Legrand
Sent: Friday, July 08, 2016 1:34 PM
To: VSE Discussion List
Subject: RE:

I do everything remotely -- our z12BC is in a colo in Irvine and our DR
z12BC CBU is in one in Dallas. I haven't seen or touched our frames for
about 3 years now. Also running the DR tests remotely.

Currently I am testing zVM 6.3 in a separate LPAR, so we had the 'hands on'
folks slide the DVD into the HMC for us. :)

-----Original Message-----
From: VSE-L [mailto:vse-l-bounces+slegrand=***@lists.lehigh.edu]
On Behalf Of Stuart, David
Sent: Friday, July 08, 2016 7:34 AM
To: VSE Discussion List
Subject: RE:

I ran my complete DR test from my family room at home, last year. The
'recovery' System was a good 1,000+ miles away.


Dave


Dave Stuart
Principal Information Systems Support Analyst Information Technology
Services County of Ventura, CA
805-662-6731
***@ventura.org


-----Original Message-----
From: VSE-L [mailto:vse-l-bounces+david.stuart=***@lists.lehigh.edu
] On Behalf Of Kevin Corkery
Sent: Thursday, July 07, 2016 7:25 PM
To: 'VSE Discussion List' <vse-***@lists.lehigh.edu>
Subject: RE:

I have configured the IOCP remotely. Hey, during the northeast blackout a
few years ago I was actually the only one on the staff that had access to
the system since I was "below" the grid failure. As I said, interesting
what you can do from a remote location.

-----Original Message-----
From: VSE-L [mailto:vse-l-bounces+kcorkery=***@lists.lehigh.edu] On
Behalf Of Farmer, Mike
Sent: Thursday, July 07, 2016 7:45 PM
To: VSE Discussion List
Subject: RE:

I've.ipld z/VM from my house in Florida 1500 miles away but they still want
someone onsite.


Sent from my Verizon Wireless 4G LTE smartphone


-------- Original message --------
From: Kevin Corkery
Date:07/07/2016 7:28 PM (GMT-05:00)
To: 'VSE Discussion List'
Subject: RE:

Gee, with modern communications there's very little you can't do from a
remote. I only go onsite when I physically need to attach/detach something
to/from the system. When I'm there I use the same remote connection to my
resource that I use from my basement office over 500 miles away. Just
sayin' ;-)

-----Original Message-----
From: VSE-L [mailto:vse-l-bounces+kcorkery=***@lists.lehigh.edu] On
Behalf Of Farmer, Mike
Sent: Thursday, July 07, 2016 5:25 PM
To: william janulin; VSE Discussion List
Subject: RE:

Do you live near Mass?


Sent from my Verizon Wireless 4G LTE smartphone


-------- Original message --------
From: william janulin via VSE-L
Date:07/07/2016 5:20 PM (GMT-05:00)
To: VSE Discussion List
Subject: Re:

Nice to see that, especially from a 'seasoned' professional :). There is
hope for me to land something.


On Thursday, July 7, 2016 3:58 PM, "Farmer, Mike" <***@commauto.com>
wrote:


I'm 72 and still supporting VSE
I migrated to 6.1 but may be finally retiring in Oct. My company has no
plans to move off VSE.


Sent from my Verizon Wireless 4G LTE smartphone
_______________________________________________
VSE-L mailing list
VSE-***@lists.lehigh.edu<mailto:VSE-***@lists.lehigh.edu>
https://lists.lehigh.edu/mailman/listinfo/vse-l


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

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

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

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

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

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

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

*** Forti ***