date:20100305

No, I wouldn't call it popular, but I wouldn't call it rare either. I have
worked on VM off and on throughout my career.

Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net 3/5/2010 6:05 AM

In
999072802-1267753158-cardhu_decombobulator_blackberry.rim.net-10413382...@bda026.bisx.prod.on.blackberry,
on 03/05/2010
at 01:39 AM, Ted MacNEIL eamacn...@yahoo.ca said:

VM MVS skills are rare to find in the same individual(s).

Not all that rare.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see http://patriot.net/~shmuel/resume/brief.html
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains
confidential and privileged information intended only for the addressee. If
you are not the intended recipient, please be advised that you have received
this material in error and that any forwarding, copying, printing,
distribution, use or disclosure of the material is strictly prohibited. If you
have received this material in error, please (i) do not read it, (ii) reply to
the sender that you received the message in error, and (iii) erase or destroy
the material. Emails are not secure and can be intercepted, amended, lost or
destroyed, or contain viruses. You are deemed to have accepted these risks if
you communicate with us by email. Thank you.

Re: LPARs: More or Less?

Thank you all for your constructive comments and critiques.

But from this little brainstorming exercise, I believe if I have learned
anything at all, I have learned that PR/SM is anything but free.

Would IBM really give away anything for free?

Here's nothing, grab it well  (Old Hungarian proverb)

The easiest path, the path of least resistance, is not always optimum.

There is a very hidden, subtle, but quite exorbitant price paid for PR/SM:

   -  Memory for each instance of z/OS replicated,
   -  Performance:  wasted CPU cycles especially for handshaking between
   LPARs doing shared I/O,
   - Software licensing fees
   -  Inflexibility of fitting workloads into fixed partitions,
   - complexity:  After splitting everything up we bring it all back
   together again with Parallel Sysplex, CDSes, CFRM policies:  List, Cache,
   and Lock structures, all kinds of plexes:  JESPLEX, VTAMPLEX, IMSPLEX, VSAM
   RLS, CICSPLEX, SHARED DB2, all designed to circumvent the artificial
   barriers we never needed to erect in the first place.

despite:


   -  all efforts of IBM to encourage this with sub-capacity pricing
   - the diminishing need to carve up memory now that paging, Expanded
   Storage, are history with 64 bit memory.

 True, there is a place for PR/SM for things like CFCC, AIX, LINUX.  But
just needlessly replicating z/OS because it is free and easy to do is not
the answer.

One of the oldest marketing devices is:

   - to first lower the hemline, then raise it;
   - first bring out double knit men's suits, then banish them,
   - first tell everyone to go distributive, then force them to centralize,
   - and above all:


   - software sells hardware, so encourage the inefficient use, needless
   replication, of software so we can sell more hardware.


On Fri, Mar 5, 2010 at 8:00 AM, Chase, John jch...@ussco.com wrote:


  -Original Message-
  From: IBM Mainframe Discussion List On Behalf Of George Henke
 
  I think I may have finally come upon a valid justification for a
 separate
  UAT, QA LPAR; maybe the only justification.
 
  You can only have one instance of Security, RACF, ACF2, TSS, in an
 LPAR,
  z/OS Domain, at any one time.


 OK so far

   Since, for QA testing, the need is to mirror PROD Security so that the
  security rules for a change being made are tested *before* moving the
 change
  to PROD, then there would need to be a separate LPAR to hold a
 separate
  Security DB that mirrored the PROD DB.


 We use installation-defined classes for much of that separation, which
 works well here because the vast majority of resources for which we
 might need to test new security rules are amenable to separate cloned
 classes (mostly CICS and FACILITY-like stuff).

   Since the DEV LPAR already has a DEV Security DB and there can be only
 one
  instance of a Security DB per LPAR, this would preclude the mirroring
 of the
  PROD Security DB in a DEV LPAR, and is sufficient reason for creating
 a
  separate LPAR for QA, UAT, testing.


 Actually, we share a RACF database between PROD and DEV/QA.  Only the
 sandbox has a separate RACF database.

   Of all the justifications, presented thus far, for creating a separate
 LPAR
  for QA, UAT testing, this appears to be the only one that cannot be
 refuted.


 If any exception to the rule counts as refutation, this is refuted.

   However, it still begs the question, why have LPARs at all, because
  separate Security DBs *can* be configured in separate Virtual Machines
  running separate instances of z/OS under z/VM without LPARs at all.


 OTOH, if all you run is a relatively stable set of z/OS images, why use
 z/VM when PR/SM is free (indeed, you can't get a current CPC without
 it)?  I'll admit that I've not worked with any flavor of VM in over a
 decade, but I don't recall any flavor of MVS IPLing any faster under VM
 than in an LPAR.

-jc-

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




-- 
George Henke
(C) 845 401 5614

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

Re: RMM Multi-Volume volume list

2010-03-05 Thread Dennis Trojak

Enter VL on the volume display for RMM and it will list the volume
chain. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of MONTERO ROMERO, ENRIQUE ELOI
Sent: Friday, March 05, 2010 6:45 AM
To: IBM-MAIN@bama.ua.edu
Subject: RMM Multi-Volume volume list

Hi team,

Here i am once again...

   In the DFSMSrmm Volume Details - xx panel, there is a
Multi-Volume message in the up-right corner. That means this volume
belongs to a multi-volume chain. It can be verified thru the fields :
   Previous volume  . : xx
   Next volume  . . . : xx

   At this moment to check which volumes are in a multi-volume, I have
to display each volume using the Previous/next volume fields values. It
is easy when there are 2 or 5 volumes in such chain. But... What about
in a 10 or more multivolume chain?

Here comes the question:

Is there some way thru command or batch or panels, to generate the list
of the volumes in a multi-volume chain?.

In CA-1, in the volume display panel, you can enter V command, and it
shows all the volumes in a multivolume chain. What about RMM?

Best regards, and happy week end.

Enrique Montero

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

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

Re: LPARs: More or Less?

Wow, I just don't know where to start.  The comments about PR/SM being free 
were made in the context of comparing it to using VM, and in that sense it is 
free since using VM not only has a license cost, but would further increase all 
the other costs you outline.
You seem to be implying that companies use PR/SM on a whim to multiply their 
z/OS images for no good reason, which I think is preposterous.
 
You say that all the points made have been refuted, yet you quietly fail to 
even acknowledge many very strong arguments.
 
It has not been terribly clear from the start what your position really is.  
Are you arguing that there is no point in having more that one z/OS image on 
any CEC, or are you arguing that PR/SM is a waste, and everyone should be using 
VM?  You seem to have argued both points at various times.

 George Henke gahe...@gmail.com 3/5/2010 9:38 AM 
Thank you all for your constructive comments and critiques.

But from this little brainstorming exercise, I believe if I have learned
anything at all, I have learned that PR/SM is anything but free.

Would IBM really give away anything for free?

Here's nothing, grab it well  (Old Hungarian proverb)

The easiest path, the path of least resistance, is not always optimum.

There is a very hidden, subtle, but quite exorbitant price paid for PR/SM:

   -  Memory for each instance of z/OS replicated,
   -  Performance:  wasted CPU cycles especially for handshaking between
   LPARs doing shared I/O,
   - Software licensing fees
   -  Inflexibility of fitting workloads into fixed partitions,
   - complexity:  After splitting everything up we bring it all back
   together again with Parallel Sysplex, CDSes, CFRM policies:  List, Cache,
   and Lock structures, all kinds of plexes:  JESPLEX, VTAMPLEX, IMSPLEX, VSAM
   RLS, CICSPLEX, SHARED DB2, all designed to circumvent the artificial
   barriers we never needed to erect in the first place.

despite:


   -  all efforts of IBM to encourage this with sub-capacity pricing
   - the diminishing need to carve up memory now that paging, Expanded
   Storage, are history with 64 bit memory.

True, there is a place for PR/SM for things like CFCC, AIX, LINUX.  But
just needlessly replicating z/OS because it is free and easy to do is not
the answer.

One of the oldest marketing devices is:

   - to first lower the hemline, then raise it;
   - first bring out double knit men's suits, then banish them,
   - first tell everyone to go distributive, then force them to centralize,
   - and above all:


   - software sells hardware, so encourage the inefficient use, needless
   replication, of software so we can sell more hardware.


On Fri, Mar 5, 2010 at 8:00 AM, Chase, John jch...@ussco.com wrote:


  -Original Message-
  From: IBM Mainframe Discussion List On Behalf Of George Henke
 
  I think I may have finally come upon a valid justification for a
 separate
  UAT, QA LPAR; maybe the only justification.
 
  You can only have one instance of Security, RACF, ACF2, TSS, in an
 LPAR,
  z/OS Domain, at any one time.


 OK so far

   Since, for QA testing, the need is to mirror PROD Security so that the
  security rules for a change being made are tested *before* moving the
 change
  to PROD, then there would need to be a separate LPAR to hold a
 separate
  Security DB that mirrored the PROD DB.


 We use installation-defined classes for much of that separation, which
 works well here because the vast majority of resources for which we
 might need to test new security rules are amenable to separate cloned
 classes (mostly CICS and FACILITY-like stuff).

   Since the DEV LPAR already has a DEV Security DB and there can be only
 one
  instance of a Security DB per LPAR, this would preclude the mirroring
 of the
  PROD Security DB in a DEV LPAR, and is sufficient reason for creating
 a
  separate LPAR for QA, UAT, testing.


 Actually, we share a RACF database between PROD and DEV/QA.  Only the
 sandbox has a separate RACF database.

   Of all the justifications, presented thus far, for creating a separate
 LPAR
  for QA, UAT testing, this appears to be the only one that cannot be
 refuted.


 If any exception to the rule counts as refutation, this is refuted.

   However, it still begs the question, why have LPARs at all, because
  separate Security DBs *can* be configured in separate Virtual Machines
  running separate instances of z/OS under z/VM without LPARs at all.


 OTOH, if all you run is a relatively stable set of z/OS images, why use
 z/VM when PR/SM is free (indeed, you can't get a current CPC without
 it)?  I'll admit that I've not worked with any flavor of VM in over a
 decade, but I don't recall any flavor of MVS IPLing any faster under VM
 than in an LPAR.

-jc-

   --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
 Search the archives

PDSE (again)

2010-03-05 Thread ITURIEL DO NASCIMENTO NETO

Hi all,

I'm doing some research about PDS and PDSE performance and did find APAR
OA15322 and
OA15473. These APARs have the following comments :

The system will be enhanced so that when LLA discovers a module 
which it would like to cache which is not eligible for LLA VLF cache 
will cause the module to be cached in the PDSE hiperspace if it is 
active in the SMSPDSE address space. 
This support will be activated if the IGWSMSxx parameter
PDSE_HSP_SIZE(nnn) is non-zero. 

As we can see it refers to SMSPDSE and PDSE_HSP_SIZE, and i could not
find out any 
other related APAR referencing SMSPDSE1 or PDSE1_HSP_SIZE.

Do they really mean SMSPDSE or we can assume SMSPDSE1 as well ?


Atenciosamente / Regards / Saludos 
Ituriel do Nascimento Neto 
BANCO BRADESCO S.A. 
4254 / DPCD Engenharia de Software 
Sistemas Operacionais Mainframes 
Tel: +55 11 4197-2021 R: 22021   Fax: +55 11 4197-2814 




HTMLfont face=Tahoma size=1HRAVISO LEGAL brEsta mensagem Ã© 
destinada exclusivamente para a(s) pessoa(s) a quem Ã© dirigida, podendo conter 
informaÃ§Ã£o confidencial e/ou legalmente privilegiada. Se vocÃª nÃ£o for 
destinatÃ¡rio desta mensagem, desde jÃ¡ fica notificado de abster-se a 
divulgar, copiar, distribuir, examinar ou, de qualquer forma, utilizar a 
informaÃ§Ã£o contida nesta mensagem, por ser ilegal. Caso vocÃª tenha recebido 
esta mensagem por engano, pedimos que nos retorne este E-Mail, promovendo, 
desde logo, a eliminaÃ§Ã£o do seu conteÃºdo em sua base de dados, registros ou 
sistema de controle. Fica desprovida de eficÃ¡cia e validade a mensagem que 
contiver vÃnculos obrigacionais, expedida por quem nÃ£o detenha poderes de 
representaÃ§Ã£o. 

HTMLfont face=Tahoma size=1HRLEGAL ADVICE brThis message is 
exclusively destined for the people to whom it is directed, and it can bear 
private and/or legally exceptional information. If you are not addressee of 
this message, since now you are advised to not release, copy, distribute, check 
or, otherwise, use the information contained in this message, because it is 
illegal. If you received this message by mistake, we ask you to return this 
email, making possible, as soon as possible, the elimination of its contents of 
your database, registrations or controls system. The message that bears any 
mandatory links, issued by someone who has no representation powers, shall be 
null or void.

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

Re: LPARs: More or Less?

2010-03-05 Thread Staller, Allan

At the end of the day, this discussion comes down to business
requirements. Many institutions, due to audit, regulatory, or industry
standards need to separate SANDBOX/DEV/TEST/QA/PROD. This can be done at
the administrative level (1 big LPAR with all information(os testing
excluded)), or the image level(separate LPARS for each), z/VM guests, or
anything in between. 

The trick in the single image environment is proving that the
non-production user CANNOT access production data, which will be a
concern for even the most incompetent of auditors. Yes this can be
accomplished, but how many auditors will understand the nuances of
RACF/ACF2/TS enough to even test the premise. Not to mention the
administrative overhead required to establish, document, and maintain
the separation of the environments within a single image. 

A separate LPAR(or guest) can be easily defended (with backup doc from
IBM and others) by saying This LPAR cannot access that LPAR's data
unless explicitly allowed. Most auditors can understand and test that
premise, even if they are not security experts.

In other words, whatever works best for your business is the method you
should use.

Just my 0.02 USD worth,

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

Re: z9 / z10 instruction speed(s)

This is simply incredible, to think that IBM would deliberately run BCT
loops to throttle, slowdown, CPs.

It is one thing to cut back the CPU cache.  It is quite another to
deliberate slow things down.

When will they ever learn that quality sells more than anything else and
that making anything less than the best possible product just hurts
themselves.

Detroit is in shambles because of built-in obsolescence.

My 1997 Honda Civic with the original radiator, air conditioner, heater
coil, starter, fuel pump, gas tank, etc has 374,000 miles on it and about
the only thing I have ever had to replace, aside from regular wear and tear
like tires, muffler, brakes, battery etc, is the ignition coil.

Sakichi Toyoda, (1867-1930) the greatest inventor and industrialist of
Japan, built his company in the early 1900's which later spawned the current
Toyota auto company, currently the world's largest automobile company,
despite recent problems.

BTW: the name Toyoda was changed to Toyota for PR reasons; the former has
bad connotations in Japanese.

Sakichi Toyoda, built is company and success on what is know as the 5 Whys.

When doing PD he required his people to ask a minimum of 5 Whys to get at
the root cause of the problem:

My car will not start. (the problem)

   1. *Why?* - The battery is dead. (first why)
   2. *Why?* - The alternator is not functioning. (second why)
   3. *Why?* - The alternator belt has broken. (third why)
   4. *Why?* - The alternator belt was well beyond its useful service life
   and has never been replaced. (fourth why)
   5. *Why?* - I have not been maintaining my car according to the
   recommended service schedule. (fifth why, a root cause)

The current trend towards CMMI and the Six Sigma standard of quality, 6
standard deviations (3.4 defects in a million) instead of the typical 3
standards deviations (1 defect in 370) points to the demand for quality,
excellence,  and perfection in everything.

No one will settle for less.

It is only a question of time before IBM goes the way of Detroit, if they do
not wake up.

On Wed, Mar 3, 2010 at 4:03 AM, Edward Jaffe edja...@phoenixsoftware.comwrote:

 McKown, John wrote:

 There are multiple z9 models. Each model has its own MSU rating, which
 is basically related to the number of CPs enabled and their speed. Now, I
 know that all the CPs on all z9 run same hardware speed. So, I'm wondering
 how they are knee capped? Now, I know that the knee capping is done by
 loading in a specific MCL. So, I'm thinking that this somehow does something
 like inserts a wait state during instruction processing. That is, the XYZ
 instruction on all z9s run in the same amount of time. But there is
 something extra done at the end of the XYZ instruction which causes a
 wait before the next instruction is actually executed. Am I on the right
 track? Or is it done is some other strange manner?



 There is a hardware timer pop (think STIMER REAL) that occurs every 'n'
 milliseconds on every CP that passes control to a millicode routine that
 does important housekeeping tasks for the CP, such as noticing and
 responding to SIGP requests. Before exiting this routine, they load a
 model-dependent integer value into a millicode register (Rx) and execute BCT
 Rx,* which chews up the prescribed amount of processor cycles.

 --
 Edward E Jaffe
 Phoenix Software International, Inc
 831 Parkview Drive North
 El Segundo, CA 90245
 310-338-0400 x318
 edja...@phoenixsoftware.com
 http://www.phoenixsoftware.com/


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




-- 
George Henke
(C) 845 401 5614

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

Dispatcher vs. CPU (was LPARs: More or Less?)

2010-03-05 Thread Thompson, Steve

Some years ago, there was a chart shown, that showed knees for the
number of CPUs that MVS, VM,  VSE could handle.

Some time later, after certain updates and changes, a new chart was
produced showing a new set of knees.

Prior to this, Amdahl had put out the Multiple Domain Facility, after
finding that there were more CPU cycles available than a single MVS
could handle/manage.

Is this still the case? With a Domain (LPAR to you IBM types) being able
to have more than 2GB of C-Store, which reduces paging, but increases
locality of reference delays, does one get max performance without 2 or
more Domains running z/OS?

This is strictly a CPU utilization via dispatcher question (engineering
type of thing) and not a billing for software, and so forth.

Regards,
Steve Thompson

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

Re: z9 / z10 instruction speed(s)

2010-03-05 Thread zMan

On Fri, Mar 5, 2010 at 11:02 AM, George Henke gahe...@gmail.com wrote:

 This is simply incredible, to think that IBM would deliberately run BCT
 loops to throttle, slowdown, CPs.

 It is one thing to cut back the CPU cache.  It is quite another to
 deliberate slow things down.


I thought this debate ended with the 486SX chips.

Using your logic, they should offer CPUs in groups of 4, since they're
shipping them anyway.

Using short words: YOU PAY LESS, YOU GET LESS. What's tricky about that?

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

Re: z9 / z10 instruction speed(s)

2010-03-05 Thread Anne Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.


gahe...@gmail.com (George Henke) writes:
 The current trend towards CMMI and the Six Sigma standard of quality, 6
 standard deviations (3.4 defects in a million) instead of the typical 3
 standards deviations (1 defect in 370) points to the demand for quality,
 excellence,  and perfection in everything.

Toyota doing Lean manufacturing
http://en.wikipedia.org/wiki/Lean_manufacturing

some of this has cross-over with Boyd's OODA-loops
... I had sponsored Boyd's briefings at IBM
http://en.wikipedia.org/wiki/OODA_loop

Toyota Production System
http://en.wikipedia.org/wiki/Toyota_Production_System

In the early 90s, one of the big-3 had C4 task force that was
looking at improving their competitive position ... and invented in some
number of technology vendors to participate. They went thru majority of
the issues with respect to their current state and foreign
competitors. One of the big issues was major foreign competitor had
reduced elapsed cycle to produce a (totally new) product (from idea to
rolling off the line) from 7-8 years to 2-3 years (and looking at
dropping below 2 years). Big part of C4 was leveraging technology as
part of drastically reducing elapsed product cycle.

I chided some of the mainframe brethern attending the meetings about
being there to offer advice on reducing product cycle from 7-8yrs to
2-3yrs (when they were still on long product cycle).

Within the domesitic auto industry ... although they could very clearly
articulate all the important issues ... the status quo was so entrenched
that they found it difficult to change.

recent thread in greater ibm blog mentioning Boyd
http://www.garlic.com/~lynn/2010e.html#39 Agile Workforce
http://www.garlic.com/~lynn/20103.html#43 Boyd's Briefings

misc. past posts mentioning Boyd /or OODA-loops
http://www.garlic.com/~lynn/subboyd.html

-- 
42yrs virtualization experience (since Jan68), online at home since Mar1970

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

Re: LPARs: More or Less?

2010-03-05 Thread Chase, John

 -Original Message-
 From: IBM Mainframe Discussion List On Behalf Of George Henke
 
 Thank you all for your constructive comments and critiques.
 
 But from this little brainstorming exercise, I believe if I have
learned
 anything at all, I have learned that PR/SM is anything but free.
 
 Would IBM really give away anything for free?

The price of PR/SM is built-in to the price of the hardware, so it
appears free.  You get it regardless whether you ever use it; very
much like the free air bags and seat belts you get in a car nowadays.

 Here's nothing, grab it well  (Old Hungarian proverb)
 
 The easiest path, the path of least resistance, is not always optimum.

Which tacitly acknowledges that on occasion it is.

 There is a very hidden, subtle, but quite exorbitant price paid for
PR/SM:
 
-  Memory for each instance of z/OS replicated,
-  Performance:  wasted CPU cycles especially for handshaking
between
LPARs doing shared I/O,
- Software licensing fees
-  Inflexibility of fitting workloads into fixed partitions,
- complexity:  After splitting everything up we bring it all back
together again with Parallel Sysplex, CDSes, CFRM policies:  List,
Cache,
and Lock structures, all kinds of plexes:  JESPLEX, VTAMPLEX,
IMSPLEX, VSAM
RLS, CICSPLEX, SHARED DB2, all designed to circumvent the
artificial
barriers we never needed to erect in the first place.

It was my understanding that all those various plexes were designed to
reduce or eliminate single points of failure, thus providing the
capability for near-continuous operation.

 despite:
 
 
-  all efforts of IBM to encourage this with sub-capacity pricing
- the diminishing need to carve up memory now that paging, Expanded
Storage, are history with 64 bit memory.

Paging is alive and well despite 64-bit storage.

  True, there is a place for PR/SM for things like CFCC, AIX, LINUX.
But
 just needlessly replicating z/OS because it is free and easy to do
is not
 the answer.

Some might argue that z/VM makes needlessly replicating z/OS even
easier.  I think the key word here is needlessly:  How many
installations needlessly replicate z/OS?

 One of the oldest marketing devices is:
 
- to first lower the hemline, then raise it;
- first bring out double knit men's suits, then banish them,
- first tell everyone to go distributive, then force them to
centralize,
- and above all:
 
 
- software sells hardware, so encourage the inefficient use,
needless
replication, of software so we can sell more hardware.

Bigger, faster cars that consumed lots of fuel were once the rage.  Then
the fuel providers decided they could raise their prices, so they raised
them until smaller, more fuel-efficient cars became the new rage.  But
drivers sorely missed bigger and faster, so they demanded they be
reinstated.  Green side out, now brown side out, now green side
out again.  That's the way things work.  Enjoy the ride, for in the end
we shall all be dead.

-jc-

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

Re: LPARs: More or Less?

You seem to be implying that companies use PR/SM on a whim to multiply
their z/OS images for no good reason, which I think is preposterous.

You're right it is preposterous.

The only thing the PR/SM LPAR paradigm lacks is a nice Escher painting to
hang over it.



On Fri, Mar 5, 2010 at 11:04 AM, George Henke gahe...@gmail.com wrote:

 Auditors don't like anything they can't stub their toe on.

 I have the scares to prove it.

   On Fri, Mar 5, 2010 at 10:52 AM, Staller, Allan 
 allan.stal...@kbm1.comwrote:

 At the end of the day, this discussion comes down to business
 requirements. Many institutions, due to audit, regulatory, or industry
 standards need to separate SANDBOX/DEV/TEST/QA/PROD. This can be done at
 the administrative level (1 big LPAR with all information(os testing
 excluded)), or the image level(separate LPARS for each), z/VM guests, or
 anything in between.

 The trick in the single image environment is proving that the
 non-production user CANNOT access production data, which will be a
 concern for even the most incompetent of auditors. Yes this can be
 accomplished, but how many auditors will understand the nuances of
 RACF/ACF2/TS enough to even test the premise. Not to mention the
 administrative overhead required to establish, document, and maintain
 the separation of the environments within a single image.

 A separate LPAR(or guest) can be easily defended (with backup doc from
 IBM and others) by saying This LPAR cannot access that LPAR's data
 unless explicitly allowed. Most auditors can understand and test that
 premise, even if they are not security experts.

 In other words, whatever works best for your business is the method you
 should use.

 Just my 0.02 USD worth,

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




  --
 George Henke
 (C) 845 401 5614




-- 
George Henke
(C) 845 401 5614

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

Re: LPARs: More or Less?

Many disagreements (interspersed):

There is a very hidden, subtle, but quite exorbitant price paid for PR/SM:

Define exhorbitant.

-  Memory for each instance of z/OS replicated,
  
Memory is relatively cheap compared to the total cost of the processor.

-  Performance:  wasted CPU cycles especially for handshaking between LPARs 
doing shared I/O,

I've been involved in MDF  PR/SM since the mid-1980's.
Back then, MDF was expensive -- 5% of the processor per domain.
PR/SM -- 3090-base -- 7%
 -- 3090-E -- 5-6%
 -- 3090-S -- 5ish%
 -- 3090-J  -- 4-5%
 -- ES/9000-- 4-5%
 -- 9672-- 3-4%
 -- z/Box   -- 2-3%
These are from memory following IBM guidelines on the number of logical vs 
physical ratios.
I was responsible for the measurements, and they were done by me, for many 
different environments that I managed.

I only suffered twice from I/O elongation, and both were on the older 
(non-CMOS) technology.

TPI  EMIF addressed a lot of the I/O issues. DCM  (HIPER)PAV addressed a lot 
more. With sub-5ms response, it's almost impossible to discern any effects due 
to PR/SM.

- Software licensing fees
  -  Inflexibility of fitting workloads into fixed partitions,

Again, define inflexibility.
 With variable weights, CPUs, and other dynamism in the picture, surely there 
is great flexibility.
Would you want to go back to the old monoliths with the (implied) wasted 
capacity.

Also, by isolating specific workloads to smaller partitions, I have helped many 
companies save licensing costs.

  - complexity:  After splitting everything up we bring it all back together 
 again with Parallel Sysplex, CDSes, CFRM policies:  List, Cache, and Lock 
 structures, all kinds of plexes:  JESPLEX, VTAMPLEX, IMSPLEX, VSAMRLS, 
 CICSPLEX, SHARED DB2, all designed to circumvent the artificial barriers we 
 never needed to erect in the first place.

That has nothing to do with PR/SM. SYSPLEX complexity is for redundancy in case 
of failure of hardware, systems, or sub-systems.
The first SYSPLEX, I was involved in, was four monolithic (ie: non-partitioned) 
processors.
We went to PR/SM, on one new box, to replace two boxes, about a year later.
The reasons for PR/SM, in that case were:
1. Less power.
2. Less cooling.
3. Flexibility. The two images peaked at different times, so we could get away 
with less capacity than that required by two footprints.
4. Of course, software costs. One less MVS licence.


despite:
-  all efforts of IBM to encourage this with sub-capacity pricing

Sub-Capacity Licences DO save money.


- the diminishing need to carve up memory now that paging, Expanded Storage, 
are history with 64 bit memory.

One agreement.

True, there is a place for PR/SM for things like CFCC, AIX, LINUX.
But just needlessly replicating z/OS because it is free and easy to do is 
not the answer.

Why not? There is more to it than your simple dismissal.

There are isolation issues.
And, even in the 21st century, virtual storage issues, still.
That is to name just two.

-
Too busy driving to stop for gas!

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

Re: LPARs: More or Less?

No, I'm saying that it's preposterous for you to say such a thing, because I do 
not believe it is prevalent.  I have never seen such a situation in any shop 
where I have worked, nor have I heard any reliable source explain that such a 
situation exists elsewhere.  I recently was involved in situation where 
management was desiring to do such a thing, through their own ignorance of the 
technology, but I was able to defeat it.

 George Henke gahe...@gmail.com 3/5/2010 11:50 AM 
You seem to be implying that companies use PR/SM on a whim to multiply
their z/OS images for no good reason, which I think is preposterous.

You're right it is preposterous.

The only thing the PR/SM LPAR paradigm lacks is a nice Escher painting to
hang over it.



On Fri, Mar 5, 2010 at 11:04 AM, George Henke gahe...@gmail.com wrote:

 Auditors don't like anything they can't stub their toe on.

 I have the scares to prove it.

   On Fri, Mar 5, 2010 at 10:52 AM, Staller, Allan 
 allan.stal...@kbm1.comwrote:

 At the end of the day, this discussion comes down to business
 requirements. Many institutions, due to audit, regulatory, or industry
 standards need to separate SANDBOX/DEV/TEST/QA/PROD. This can be done at
 the administrative level (1 big LPAR with all information(os testing
 excluded)), or the image level(separate LPARS for each), z/VM guests, or
 anything in between.

 The trick in the single image environment is proving that the
 non-production user CANNOT access production data, which will be a
 concern for even the most incompetent of auditors. Yes this can be
 accomplished, but how many auditors will understand the nuances of
 RACF/ACF2/TS enough to even test the premise. Not to mention the
 administrative overhead required to establish, document, and maintain
 the separation of the environments within a single image.

 A separate LPAR(or guest) can be easily defended (with backup doc from
 IBM and others) by saying This LPAR cannot access that LPAR's data
 unless explicitly allowed. Most auditors can understand and test that
 premise, even if they are not security experts.

 In other words, whatever works best for your business is the method you
 should use.

 Just my 0.02 USD worth,

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




  --
 George Henke
 (C) 845 401 5614




-- 
George Henke
(C) 845 401 5614

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



CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.


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

Re: z9 / z10 instruction speed(s)

This is simply incredible, to think that IBM would deliberately run BCT loops 
to throttle, slowdown, CPs.

Why? This kind of thing has been around nearly as long as commercial computing.
I remember when upgrades consisted of removing circuitry that slowed the 
processor down.

The AMD470 had built-in decelerators.


It is one thing to cut back the CPU cache.  It is quite another to deliberate 
slow things down.

Why? If you don't need the capacity, what's the issue?
Would you rather pay full hardware  software costs for capacity you don't need.

Also, this way, IBM has to build just one processor chip.
-
Too busy driving to stop for gas!

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

Re: z9 / z10 instruction speed(s)

2010-03-05 Thread Mark Zelden

On Fri, 5 Mar 2010 11:18:08 -0500, zMan zedgarhoo...@gmail.com wrote:

On Fri, Mar 5, 2010 at 11:02 AM, George Henke gahe...@gmail.com wrote:

 This is simply incredible, to think that IBM would deliberately run BCT
 loops to throttle, slowdown, CPs.

 It is one thing to cut back the CPU cache.  It is quite another to
 deliberate slow things down.


I thought this debate ended with the 486SX chips.

Using your logic, they should offer CPUs in groups of 4, since they're
shipping them anyway.

Using short words: YOU PAY LESS, YOU GET LESS. What's tricky about that?


Exactly.  Didn't we have this discussion a couple of weeks ago?

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:mzel...@flash.net  
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

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

Re: LPARs: More or Less?

2010-03-05 Thread Mark Zelden

On Fri, 5 Mar 2010 16:24:51 +, Ted MacNEIL eamacn...@yahoo.ca wrote:

No, I wouldn't call it popular, but I wouldn't call it rare either.
I have worked on VM off and on throughout my career.

Outside of IBM, I've only met two people with VM and MVS skills.
This is in the Greater Toronto Area, over the last 30 years.
To me, that's rare.

That is your experience, which is what you are writing about.   I will
say it is much more rare these days than it was 20 years ago.  At least
in the Chicago area.  There used to be a lot of shops running VM along
with MVS (and hence many sysprogs with experience in both) but many
of them got rid of VM.  The last full time VM I supported was VM/XA but
I also worked with VM/ESA and VM/HPO not long after that but there
was a full time VM sysprog that really supported those environments when I 
worked on them. 

It wasn't until zLinux popped up that I started working with VM again, which
I think is getting more and more common, so the dual skill set is making
a come back.

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:mzel...@flash.net  
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

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

Re: LPARs: More or Less?

No, I'm saying that it's preposterous for you to say such a thing, because
I do not believe it is prevalent. . . .  I recently was involved in
situation where management was desiring to do such a thing, through their
own ignorance of the technology, but I was able to defeat it.
IBM owes you money.

On Fri, Mar 5, 2010 at 11:59 AM, Scott Rowe scott.r...@joann.com wrote:

 No, I'm saying that it's preposterous for you to say such a thing, because
 I do not believe it is prevalent.  I have never seen such a situation in any
 shop where I have worked, nor have I heard any reliable source explain that
 such a situation exists elsewhere.  I recently was involved in situation
 where management was desiring to do such a thing, through their own
 ignorance of the technology, but I was able to defeat it.

  George Henke gahe...@gmail.com 3/5/2010 11:50 AM 
  You seem to be implying that companies use PR/SM on a whim to multiply
 their z/OS images for no good reason, which I think is preposterous.

 You're right it is preposterous.

 The only thing the PR/SM LPAR paradigm lacks is a nice Escher painting to
 hang over it.



 On Fri, Mar 5, 2010 at 11:04 AM, George Henke gahe...@gmail.com wrote:

  Auditors don't like anything they can't stub their toe on.
 
  I have the scares to prove it.
 
On Fri, Mar 5, 2010 at 10:52 AM, Staller, Allan 
 allan.stal...@kbm1.comwrote:
 
  At the end of the day, this discussion comes down to business
  requirements. Many institutions, due to audit, regulatory, or industry
  standards need to separate SANDBOX/DEV/TEST/QA/PROD. This can be done at
  the administrative level (1 big LPAR with all information(os testing
  excluded)), or the image level(separate LPARS for each), z/VM guests, or
  anything in between.
 
  The trick in the single image environment is proving that the
  non-production user CANNOT access production data, which will be a
  concern for even the most incompetent of auditors. Yes this can be
  accomplished, but how many auditors will understand the nuances of
  RACF/ACF2/TS enough to even test the premise. Not to mention the
  administrative overhead required to establish, document, and maintain
  the separation of the environments within a single image.
 
  A separate LPAR(or guest) can be easily defended (with backup doc from
  IBM and others) by saying This LPAR cannot access that LPAR's data
  unless explicitly allowed. Most auditors can understand and test that
  premise, even if they are not security experts.
 
  In other words, whatever works best for your business is the method you
  should use.
 
  Just my 0.02 USD worth,
 
  --
  For IBM-MAIN subscribe / signoff / archive access instructions,
  send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
  Search the archives at http://bama.ua.edu/archives/ibm-main.html
 
 
 
 
   --
  George Henke
  (C) 845 401 5614
 



 --
 George Henke
 (C) 845 401 5614

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



 CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains
 confidential and privileged information intended only for the addressee.  If
 you are not the intended recipient, please be advised that you have received
 this material in error and that any forwarding, copying, printing,
 distribution, use or disclosure of the material is strictly prohibited.  If
 you have received this material in error, please (i) do not read it, (ii)
 reply to the sender that you received the message in error, and (iii) erase
 or destroy the material. Emails are not secure and can be intercepted,
 amended, lost or destroyed, or contain viruses. You are deemed to have
 accepted these risks if you communicate with us by email. Thank you.


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




-- 
George Henke
(C) 845 401 5614

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

Re: LPARs: More or Less?

It wasn't until zLinux popped up that I started working with VM again,
which
I think is getting more and more common, so the dual skill set is making
a come back.

You're absolutely right, Mark.  I know a very large financial company who is
doing just that after the project was languishing for 6 years.

Also, it should be noted, that IBM offers z/VM virtually for free to
hospitals and universities as long as they use it for research.

So you will find z/VM and z/OS living happily together at such institutions
which is where I installed z/VM 5.4 last November.

On Fri, Mar 5, 2010 at 12:13 PM, Mark Zelden mzel...@flash.net wrote:

 On Fri, 5 Mar 2010 16:24:51 +, Ted MacNEIL eamacn...@yahoo.ca wrote:

 No, I wouldn't call it popular, but I wouldn't call it rare either.
 I have worked on VM off and on throughout my career.
 
 Outside of IBM, I've only met two people with VM and MVS skills.
 This is in the Greater Toronto Area, over the last 30 years.
 To me, that's rare.

 That is your experience, which is what you are writing about.   I will
 say it is much more rare these days than it was 20 years ago.  At least
 in the Chicago area.  There used to be a lot of shops running VM along
 with MVS (and hence many sysprogs with experience in both) but many
 of them got rid of VM.  The last full time VM I supported was VM/XA but
 I also worked with VM/ESA and VM/HPO not long after that but there
 was a full time VM sysprog that really supported those environments when I
 worked on them.

 It wasn't until zLinux popped up that I started working with VM again,
 which
 I think is getting more and more common, so the dual skill set is making
 a come back.

 Mark
 --
 Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
 mailto:mzel...@flash.net
 Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
 Systems Programming expert at http://expertanswercenter.techtarget.com/

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




-- 
George Henke
(C) 845 401 5614

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

Re: z9 / z10 instruction speed(s)

2010-03-05 Thread Tom Marchant

On Fri, 5 Mar 2010 11:02:22 -0500, George Henke wrote:

This is simply incredible, to think that IBM would deliberately run BCT
loops to throttle, slowdown, CPs.

Check the archives for discussions of kneecapped processors.
This has been covered many times.

It is one thing to cut back the CPU cache.  It is quite another to
deliberate slow things down.

That's absurd.  Reducing CPU cache will certainly cause a system 
to slow down, but not in a very predictable way.  And why is it more 
reasonable to use only part of the available cache than it is to run 
the CPU at a slower speed?

-- 
Tom Marchant

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

Re: z9 / z10 instruction speed(s)

2010-03-05 Thread Anne Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.


eamacn...@yahoo.ca (Ted MacNEIL) writes:
 Why? If you don't need the capacity, what's the issue?
 Would you rather pay full hardware  software costs for capacity you don't 
 need.

 Also, this way, IBM has to build just one processor chip.

i.e. aggregate computing cost (for everybody) is actually less with
single part number ... than if there were large number of different
parts.

in early 80s, major analysis of vm/4341s going into every nook  cranny
versus big iron in the datacenter, was the enormously greater big
iron expense involved in adding capacity. this can somewhat also be
seen with returning to the old timesharing days with cloud computing.

having extra capacity already available at the customer site ... is
analogous to having on-site spare part depot /or on-site CE.

recent reference to 3033N ... slower than 168/3032 ... but able to be
field upgraded to full speed 3033:
http://www.garlic.com/~lynn/2010e.html#27 SHAREWARE at Its Finest

-- 
42yrs virtualization experience (since Jan68), online at home since Mar1970

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

Re: Defrag

2010-03-05 Thread Rick Fochtman


--snip--
AFAIK, you are limited to 16 extents on a volume (NON-VSAM, PDS, DAM, 
etc.). If you are allowed (or can) do multi-volume, then yes, you get 16 
[max] per volume for 59 volumes.


Reclaiming space in the VTOC: If I can get all my space consolidated to 
just the DSCB #1, then all the other DSCBs (model 3s) become available, 
giving space for more allocations in the VTOC. If I remember correctly, 
there can be up to 4 Model 3 DSCBs to get you to 16 extents (for a data 
set) -- (non-VSAM, PDS, DAM, PS, etc.). Otherwise, once you have used up 
all the DSCBs in the VTOC, you can't allocate anything more, or even get 
a secondary extent on that volume. So defragging does recover space for 
a VTOC.

unsnip--
I can't speak for Extended Format, but for non-Extended Format datasets, 
you can only have one FORMAT-3 DSCB per dataset (Except for the special 
case of ISAM, now long dead.)


Rick

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

Re: Defrag

2010-03-05 Thread Thompson, Steve

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Rick Fochtman
Sent: Friday, March 05, 2010 12:33 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Defrag

--snip
--
AFAIK, you are limited to 16 extents on a volume (NON-VSAM, PDS, DAM, 
etc.). If you are allowed (or can) do multi-volume, then yes, you get 16

[max] per volume for 59 volumes.

Reclaiming space in the VTOC: If I can get all my space consolidated to 
just the DSCB #1, then all the other DSCBs (model 3s) become available, 
giving space for more allocations in the VTOC. If I remember correctly, 
there can be up to 4 Model 3 DSCBs to get you to 16 extents (for a data 
set) -- (non-VSAM, PDS, DAM, PS, etc.). Otherwise, once you have used up

all the DSCBs in the VTOC, you can't allocate anything more, or even get

a secondary extent on that volume. So defragging does recover space for 
a VTOC.
unsnip
--
I can't speak for Extended Format, but for non-Extended Format datasets,

you can only have one FORMAT-3 DSCB per dataset (Except for the special 
case of ISAM, now long dead.)

Rick
SNIP

Based on the doc, if an F1DSCB can only have 3 extents, and an F4DSCB
can only have 4 extents, but a simple PS data set is limited to 16
Extents on a volume, then we have a problem.

It has been 14+ years since I've had to do DSCB handling (OBS/ACS WYLBUR
would try to get a PDS to a single extent...). So I don't recall the
actual layouts and only went by what IBM's doc says. And I could very
well have misread or misinterpreted DFP/DFSMS's verbiage.

But the point was recovering space in a VTOC...

Regards,
Steve Thompson

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

Re: z9 / z10 instruction speed(s)

2010-03-05 Thread Edward Jaffe


George Henke wrote:

This is simply incredible, to think that IBM would deliberately run BCT
loops to throttle, slowdown, CPs.

It is one thing to cut back the CPU cache.  It is quite another to
deliberate slow things down.
  


IBM's current knee-capping approach is far superior to the old 
adjusted-clocking approach. It has given rise to the most granular 
sizing and flexible upgrade paths of any hardware platform on the planet.


Today's mainframe dynamic provisioning capabilities are truly 
leading-edge, and improving with each new generation.


We can dynamically grow any DASD volume--on the fly--up to 226GB in 
size. We can download and dynamically apply a patch that makes our CPUs 
run faster, adds new CPUs, or both. Expect to see even more such 
capabilities in the future...


People with PC-only experience are always astonished when I tell them 
about modern mainframe provisioning capabilities. They always assume 
when your hard drive fills up you need a new one or when your CPU is too 
slow you need a new one. What we do seems like magic to them.


Any sufficiently advanced technology is indistinguishable from magic. 
--  Arthur C. Clarke, Profiles of The Future, 1961


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

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

Re: LPARs: More or Less?

That's your reply?  IBM owes me money?  Why?  Because I did my job?
 
Now you will probably go on to say that nobody has refuted your position, right?
 
Are you really interested in having an intelligent discussion here? You seem to 
just be posting long diatribes and ignoring or dismissing all the well thought 
out responses you receive.
 
I'm still kind of curious what exactly you mean by: 
-  Performance:  wasted CPU cycles especially for handshaking between
   LPARs doing shared I/O
I have thoughts on what you mean by these kinds of things, but I am reserving 
judgement.

 George Henke gahe...@gmail.com 3/5/2010 12:15 PM 
No, I'm saying that it's preposterous for you to say such a thing, because
I do not believe it is prevalent. . . .  I recently was involved in
situation where management was desiring to do such a thing, through their
own ignorance of the technology, but I was able to defeat it.
IBM owes you money.


CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.


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

Re: LPARs: More or Less?

I'm still kind of curious what exactly you mean by: 
-  Performance:  wasted CPU cycles especially for handshaking between
   LPARs doing shared I/O

So am I.
I haven't seen these issues since the early days of MDF and PR/SM in the 1980's.

I have thoughts on what you mean by these kinds of things, but I am reserving 
judgement.

I'm not.
This sounds like a diatribe against something that has matured in the last 25 
years.

Rather than say it's bad because I say it's bad, present some evidence.

-
Too busy driving to stop for gas!

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

Re: z9 / z10 instruction speed(s)

2010-03-05 Thread zMan

On Fri, Mar 5, 2010 at 2:01 PM, Edward Jaffe edja...@phoenixsoftware.comwrote:

 Today's mainframe dynamic provisioning capabilities are truly leading-edge,
 and improving with each new generation.

 We can dynamically grow any DASD volume--on the fly--up to 226GB in size.
 We can download and dynamically apply a patch that makes our CPUs run
 faster, adds new CPUs, or both. Expect to see even more such capabilities in
 the future...

 People with PC-only experience are always astonished when I tell them about
 modern mainframe provisioning capabilities. They always assume when your
 hard drive fills up you need a new one or when your CPU is too slow you need
 a new one. What we do seems like magic to them.


You know *I* don't disagree with your position here, but there is a
disconnect -- distributed folks don't understand issues like small volumes
(226GB being smaller than the hard drive in my laptop), much less JCL. So
many/most of them *still* see the mainframe as slow, old, difficult,
crippled. That's something that needs to be rectified, but I'm ed if I
know how to do it.

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

Re: z9 / z10 instruction speed(s)

2010-03-05 Thread Blaicher, Chris

But, can you connect 10,000 dasd up to your PC?

Now, as for getting them to understand where a PC or a mainframe makes sense, 
that is harder.  PC people think in terms of 10's of transactions.  
Mainframer's think in terms of 10's of thousands of transactions.  I know of a 
company that has a table that is coming up on crossing the 2 trillion rows in 
it mark.

I know another company that does over 100 million inserts a day.

As far as hobbling a CPU, if you want it to run flat out then pay for it.  I'm 
sure IBM would rather that all boxes run full speed with all the processors 
turned on. $

Chris Blaicher
Phone: 512-340-6154
Mobile: 512-627-3803


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
zMan
Sent: Friday, March 05, 2010 1:46 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z9 / z10 instruction speed(s)


distributed folks don't understand issues like small volumes
(226GB being smaller than the hard drive in my laptop)

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

Re: LPARs: More or Less? (OT, somewhat)

2010-03-05 Thread John Baxter

Ah, the good old GTA; come visit Edmonton, Ted. There are a number of
ambidextrous sysprogs in our area. (Not to put T.O. down - I lived there
during the 60's  70's and loved it.) 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ted MacNEIL
Sent: Friday, March 05, 2010 9:25 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: LPARs: More or Less?

No, I wouldn't call it popular, but I wouldn't call it rare either.
I have worked on VM off and on throughout my career.

Outside of IBM, I've only met two people with VM and MVS skills.
This is in the Greater Toronto Area, over the last 30 years.
To me, that's rare.
-
Too busy driving to stop for gas!

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

The information transmitted is intended only for the addressee and may contain 
confidential, proprietary and/or privileged material. Any unauthorized review, 
distribution or other use of or the taking of any action in reliance upon this 
information is prohibited. If you receive this in error, please contact the 
sender and delete or destroy this message and any copies.

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

Re: z9 / z10 instruction speed(s)

2010-03-05 Thread Edward Jaffe


zMan wrote:

... distributed folks don't understand issues like small volumes
(226GB being smaller than the hard drive in my laptop)...


It has already been said by IBM, but obviously bears repeating... The 
226GB per volume EAV limit is nowhere near the *architectural* limit of 
EAV--which is over 220TB per volume. IBM artificially limited the 
initial per volume EAV size to 226GB to ensure any production 
performance bottlenecks can be addressed before raising the limit to 
higher values.


IBM is very aware of the airline magazine mentality that prevails 
today. They realize it's difficult to be on the defensive all the time  
trying to explain capacity and throughput issues to ignorant people. 
It's better to be the ones' putting the others on the defensive.


That's why we have 64-bit processors (and not 63-bit) and a 4.4Ghz chip 
in the z10 (and not the 2+Ghz value we should have had if we had 
continued down the z9 path). I would not be surprised to see a 1TB or 
even 2TB EAV in the not-too-distant future.


My prediction is that IBM will continually raise the per volume EAV size 
to a value at or above the prevailing off-platform volume size for 
exactly the reasons stated...


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

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

Re: Defrag

2010-03-05 Thread Ron Hawkins

Steve,

Why not just allocate a bigger VTOC. The argument is that the regular
shuffling of thousands of CYls into contiguous extents to save one or two
cyls on a VTOC is valuable exercise.

I don't see it. I would give the Storage Admin help and guidance on sizing a
VTOC, and how to reallocate a larger one.

Ron

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
 Thompson, Steve
 Sent: Friday, March 05, 2010 10:47 AM
 To: IBM-MAIN@bama.ua.edu
 Subject: Re: [IBM-MAIN] Defrag
 
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
 Behalf Of Rick Fochtman
 Sent: Friday, March 05, 2010 12:33 PM
 To: IBM-MAIN@bama.ua.edu
 Subject: Re: Defrag
 
 --snip
 --
 AFAIK, you are limited to 16 extents on a volume (NON-VSAM, PDS, DAM,
 etc.). If you are allowed (or can) do multi-volume, then yes, you get 16
 
 [max] per volume for 59 volumes.
 
 Reclaiming space in the VTOC: If I can get all my space consolidated to
 just the DSCB #1, then all the other DSCBs (model 3s) become available,
 giving space for more allocations in the VTOC. If I remember correctly,
 there can be up to 4 Model 3 DSCBs to get you to 16 extents (for a data
 set) -- (non-VSAM, PDS, DAM, PS, etc.). Otherwise, once you have used up
 
 all the DSCBs in the VTOC, you can't allocate anything more, or even get
 
 a secondary extent on that volume. So defragging does recover space for
 a VTOC.
 unsnip
 --
 I can't speak for Extended Format, but for non-Extended Format datasets,
 
 you can only have one FORMAT-3 DSCB per dataset (Except for the special
 case of ISAM, now long dead.)
 
 Rick
 SNIP
 
 Based on the doc, if an F1DSCB can only have 3 extents, and an F4DSCB
 can only have 4 extents, but a simple PS data set is limited to 16
 Extents on a volume, then we have a problem.
 
 It has been 14+ years since I've had to do DSCB handling (OBS/ACS WYLBUR
 would try to get a PDS to a single extent...). So I don't recall the
 actual layouts and only went by what IBM's doc says. And I could very
 well have misread or misinterpreted DFP/DFSMS's verbiage.
 
 But the point was recovering space in a VTOC...
 
 Regards,
 Steve Thompson
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html

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

Re: Defrag

2010-03-05 Thread Rick Fochtman


---snip--


Steve,

Why not just allocate a bigger VTOC. The argument is that the regular
shuffling of thousands of CYls into contiguous extents to save one or two
cyls on a VTOC is valuable exercise.

I don't see it. I would give the Storage Admin help and guidance on sizing a
VTOC, and how to reallocate a larger one.

Ron
 


-unsnip---
Or how to extend an existing VTOC...

Rick

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

Re: Defrag

2010-03-05 Thread Thompson, Steve

Because that's not our problem. 

I thought I was answering the original poster's question and extended it
out to the VTOC and repercussions there, along with possibly running out
of space in the VTOC, which is why you might want to do DEFRAG.

Regards,
Steve Thompson

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ron Hawkins
Sent: Friday, March 05, 2010 3:29 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Defrag

Steve,

Why not just allocate a bigger VTOC. The argument is that the regular
shuffling of thousands of CYls into contiguous extents to save one or
two
cyls on a VTOC is valuable exercise.

I don't see it. I would give the Storage Admin help and guidance on
sizing a
VTOC, and how to reallocate a larger one.

Ron

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
 Thompson, Steve
 Sent: Friday, March 05, 2010 10:47 AM
 To: IBM-MAIN@bama.ua.edu
 Subject: Re: [IBM-MAIN] Defrag
 
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
 Behalf Of Rick Fochtman
 Sent: Friday, March 05, 2010 12:33 PM
 To: IBM-MAIN@bama.ua.edu
 Subject: Re: Defrag
 

--snip
 --
 AFAIK, you are limited to 16 extents on a volume (NON-VSAM, PDS, DAM,
 etc.). If you are allowed (or can) do multi-volume, then yes, you get
16
 
 [max] per volume for 59 volumes.
 
 Reclaiming space in the VTOC: If I can get all my space consolidated
to
 just the DSCB #1, then all the other DSCBs (model 3s) become
available,
 giving space for more allocations in the VTOC. If I remember
correctly,
 there can be up to 4 Model 3 DSCBs to get you to 16 extents (for a
data
 set) -- (non-VSAM, PDS, DAM, PS, etc.). Otherwise, once you have used
up
 
 all the DSCBs in the VTOC, you can't allocate anything more, or even
get
 
 a secondary extent on that volume. So defragging does recover space
for
 a VTOC.

unsnip
 --
 I can't speak for Extended Format, but for non-Extended Format
datasets,
 
 you can only have one FORMAT-3 DSCB per dataset (Except for the
special
 case of ISAM, now long dead.)
 
 Rick
 SNIP
 
 Based on the doc, if an F1DSCB can only have 3 extents, and an F4DSCB
 can only have 4 extents, but a simple PS data set is limited to 16
 Extents on a volume, then we have a problem.
 
 It has been 14+ years since I've had to do DSCB handling (OBS/ACS
WYLBUR
 would try to get a PDS to a single extent...). So I don't recall the
 actual layouts and only went by what IBM's doc says. And I could very
 well have misread or misinterpreted DFP/DFSMS's verbiage.
 
 But the point was recovering space in a VTOC...
 
 Regards,
 Steve Thompson
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html

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

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

Re: LPARs: More or Less?

Gentlemen,

I am indeed very grateful to you all and thank you all.

There is, indeed, compelling evidence supporting the case for fewer and even
no LPARs but, unfortunately, it is proprietary and cannot be presented.

I know that all sounds a little too convenient, but it is true.

But thank you all and rest assured I have, indeed, read and learned and
appreciate very much all that you all have written and said.

Please, no hard feelings.

Thank you.
On Fri, Mar 5, 2010 at 2:37 PM, Ted MacNEIL eamacn...@yahoo.ca wrote:

 I'm still kind of curious what exactly you mean by:
 -  Performance:  wasted CPU cycles especially for handshaking between
   LPARs doing shared I/O

 So am I.
 I haven't seen these issues since the early days of MDF and PR/SM in the
 1980's.

 I have thoughts on what you mean by these kinds of things, but I am
 reserving judgement.

 I'm not.
 This sounds like a diatribe against something that has matured in the last
 25 years.

 Rather than say it's bad because I say it's bad, present some evidence.

 -
 Too busy driving to stop for gas!

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




-- 
George Henke
(C) 845 401 5614

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

Re: LPARs: More or Less?

2010-03-05 Thread Gibney, Dave

  Just a nit. On supported IBM hardware, there is no valid argument for
NO LPARs. Basic mode is not available. Even if you only have one image,
it is still an LPAR.

Dave Gibney
Information Technology Services
Washington State University


 -Original Message-
 From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
 Behalf Of George Henke
 Sent: Friday, March 05, 2010 1:50 PM
 To: IBM-MAIN@bama.ua.edu
 Subject: Re: LPARs: More or Less?
 
 Gentlemen,
 
 I am indeed very grateful to you all and thank you all.
 
 There is, indeed, compelling evidence supporting the case for fewer
and
 even
 no LPARs but, unfortunately, it is proprietary and cannot be
presented.
 
 I know that all sounds a little too convenient, but it is true.
 
 But thank you all and rest assured I have, indeed, read and learned
and
 appreciate very much all that you all have written and said.
 
 Please, no hard feelings.
 
 Thank you.
 On Fri, Mar 5, 2010 at 2:37 PM, Ted MacNEIL eamacn...@yahoo.ca
wrote:
 
  I'm still kind of curious what exactly you mean by:
  -  Performance:  wasted CPU cycles especially for handshaking
between
LPARs doing shared I/O
 
  So am I.
  I haven't seen these issues since the early days of MDF and PR/SM in
 the
  1980's.
 
  I have thoughts on what you mean by these kinds of things, but I am
  reserving judgement.
 
  I'm not.
  This sounds like a diatribe against something that has matured in
the
 last
  25 years.
 
  Rather than say it's bad because I say it's bad, present some
 evidence.
 
  -
  Too busy driving to stop for gas!
 
 
-
 -
   For IBM-MAIN subscribe / signoff / archive access instructions,
  send email to lists...@bama.ua.edu with the message: GET IBM-MAIN
 INFO
  Search the archives at http://bama.ua.edu/archives/ibm-main.html
 
 
 
 
 --
 George Henke
 (C) 845 401 5614
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html

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

Re: z9 / z10 instruction speed(s)

2010-03-05 Thread Shane Ginnane

Until you tell them the (upfront) cost to get into a mainframe - or the
cost to turn on those CPs.
Then the look of awe turns to derisive laughter.

And growing DASD is only a big deal to us because of our history - ask
gil about ZFS; ask a Linux admin about LVM (or even EVMS). Who cares
about the underlying hardware - it's the filesystem (your data) that
matters. Whack in some new disk, grow your data (dynamically) across it.
Even the mainframe vendors know this - they keep swapping out the drives
for bigger ones.

I say we still have a fight on our hands.

Shane ...

On Sat, Mar 6th, 2010 at 6:01 AM, Edward Jaffe wrote:

 People with PC-only experience are always astonished when I tell them
 
 about modern mainframe provisioning capabilities. They always assume
 
 when your hard drive fills up you need a new one or when your CPU is
 too 
 slow you need a new one. What we do seems like magic to them.
 
 Any sufficiently advanced technology is indistinguishable from
 magic. 
 --  Arthur C. Clarke, Profiles of The Future, 1961

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

Re: LPARs: More or Less?

Gentlemen,

I am indeed very grateful to you all and thank you all.

There is, indeed, compelling evidence supporting the case for fewer and even
no LPARs but, unfortunately, it is proprietary and cannot be presented, for
obvious reasons.

I know that all sounds just a little too convenient, but it is true.

But thank you all and rest assured I have, indeed, read and learned and
appreciate very much all that you all have written and said.

Please, no hard feelings.

Thank you.

On Fri, Mar 5, 2010 at 2:28 PM, Scott Rowe scott.r...@joann.com wrote:

 That's your reply?  IBM owes me money?  Why?  Because I did my job?

 Now you will probably go on to say that nobody has refuted your position,
 right?

 Are you really interested in having an intelligent discussion here? You
 seem to just be posting long diatribes and ignoring or dismissing all the
 well thought out responses you receive.

 I'm still kind of curious what exactly you mean by:
 -  Performance:  wasted CPU cycles especially for handshaking between
   LPARs doing shared I/O
 I have thoughts on what you mean by these kinds of things, but I am
 reserving judgement.

  George Henke gahe...@gmail.com 3/5/2010 12:15 PM 
 No, I'm saying that it's preposterous for you to say such a thing,
 because
 I do not believe it is prevalent. . . .  I recently was involved in
 situation where management was desiring to do such a thing, through their
 own ignorance of the technology, but I was able to defeat it.
 IBM owes you money.


  CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains
 confidential and privileged information intended only for the addressee.  If
 you are not the intended recipient, please be advised that you have received
 this material in error and that any forwarding, copying, printing,
 distribution, use or disclosure of the material is strictly prohibited.  If
 you have received this material in error, please (i) do not read it, (ii)
 reply to the sender that you received the message in error, and (iii) erase
 or destroy the material. Emails are not secure and can be intercepted,
 amended, lost or destroyed, or contain viruses. You are deemed to have
 accepted these risks if you communicate with us by email. Thank you.


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




-- 
George Henke
(C) 845 401 5614

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

Re: LPARs: More or Less?

2010-03-05 Thread Guy Gardoit

This whole thread is compelling evidence that some like to spread any
nonsense they can dream up.   Worth a few laughs anyway 

On Fri, Mar 5, 2010 at 1:55 PM, Gibney, Dave gib...@wsu.edu wrote:

  Just a nit. On supported IBM hardware, there is no valid argument for
 NO LPARs. Basic mode is not available. Even if you only have one image,
 it is still an LPAR.

 Dave Gibney
 Information Technology Services
 Washington State University


  -Original Message-
  From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
  Behalf Of George Henke
  Sent: Friday, March 05, 2010 1:50 PM
  To: IBM-MAIN@bama.ua.edu
   Subject: Re: LPARs: More or Less?
 
  Gentlemen,
 
  I am indeed very grateful to you all and thank you all.
 
  There is, indeed, compelling evidence supporting the case for fewer
 and
  even
  no LPARs but, unfortunately, it is proprietary and cannot be
 presented.
 
  I know that all sounds a little too convenient, but it is true.
 
  But thank you all and rest assured I have, indeed, read and learned
 and
  appreciate very much all that you all have written and said.
 
  Please, no hard feelings.
 
  Thank you.
  On Fri, Mar 5, 2010 at 2:37 PM, Ted MacNEIL eamacn...@yahoo.ca
 wrote:
 
   I'm still kind of curious what exactly you mean by:
   -  Performance:  wasted CPU cycles especially for handshaking
 between
 LPARs doing shared I/O
  
   So am I.
   I haven't seen these issues since the early days of MDF and PR/SM in
  the
   1980's.
  
   I have thoughts on what you mean by these kinds of things, but I am
   reserving judgement.
  
   I'm not.
   This sounds like a diatribe against something that has matured in
 the
  last
   25 years.
  
   Rather than say it's bad because I say it's bad, present some
  evidence.
  
   -
   Too busy driving to stop for gas!
  
  
 -
  -
For IBM-MAIN subscribe / signoff / archive access instructions,
   send email to lists...@bama.ua.edu with the message: GET IBM-MAIN
  INFO
   Search the archives at http://bama.ua.edu/archives/ibm-main.html
  
 
 
 
  --
  George Henke
  (C) 845 401 5614
 
  --
  For IBM-MAIN subscribe / signoff / archive access instructions,
  send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
  Search the archives at http://bama.ua.edu/archives/ibm-main.html

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




-- 
Guy Gardoit
z/OS Systems Programming

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

Re: LPARs: More or Less?

There is, indeed, compelling evidence supporting the case for fewer and even 
no LPARs but, unfortunately, it is proprietary and cannot be presented, for 
obvious reasons.

With all due respect, BS.
How can the number of LPARs be proprietort?

Sniff! Sniff! I smell a cop-out.

If it was a secret, why did you even engage in this discussion?

S**t, or get off the pot!
-
Too busy driving to stop for gas!

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

IBM SoftCopy Librarian

2010-03-05 Thread John P. Baker

All,

 

Has anyone had any success getting the IBM SoftCopy Librarian to run under
Windows 7?

 

IBM updated version 4.3 was made to run under Windows Vista.

 

However, when attempting to run it under Windows 7, I receive the following
error message -

 

IOException opening log file:java.io.FileNotFoundException: C:\Program Files
(x86)\IBM\SoftCopy Librarian\log.txt

 

Any help will be greatly appreciated.

 

John P. Baker

Chief Software Architect

HFD Technologies


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

Re: SHAREWARE at Its Finest