Re: ASM and HiperPAV

[Barbara Nitz]

>See APAR OA32453 (closed last year). It addresses the problem(s) associated 
>with using HYPERPAV (and the WLMPAV option) for paging devices.

If I read the apar right, this addresses the WLMPAV option in that it is no 
longer needed to be set. How many IOs does ASM start concurrently to the same 
paging device? Still two at the most, and the second only for a simple page 
fault when the first is busy with a long-running channel program?

Thank you, Barbara

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

Re: COBOL Upgrade

[Ed Gould]

I would be more concerned about LE than anything.

Ed

On Jan 25, 2012, at 4:19 PM, Tom Ross wrote:

We are (finally) looking at the possibilities of moving up on  
COBOL from OS/VS
with Report Writer and from  COBOL II to the new COBOL 4.2 with  
Report Writer.
I would like to hear from folks who have already made that  
journey, especially

about any specific things that went well - or didn't.


I'm thinking that there must be a COBOL list out there somewhere   
as well, maybe
more than one.  Can anyone tell me its address and the process to  
subscribe?


I have not heard of such a thing.  You can ask questions at the  
COBOL Cafe:

https://www.ibm.com/developerworks/rational/community/cafe/cobol.html

Migration is really not too tough from VS COBOL II to Enterprise  
COBOL, the

compilers are similar.  For moving OS/VS COBOL programs to Enterprise
many changes might be necessary, that is why IBM has a tool CCCA to  
do it

automatically.  There are other vendors with such tools as well.

We have added every problem every encountered in COBOL migration into
our COBOL Migration Guide, it is truly an excellent manual!
http://www-01.ibm.com/software/awdtools/cobol/zos/library/

Cheers,
TomR  >> COBOL is the Language of the Future! <<

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


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

Re: zEnterprise Use Cases

[Martin Packer]

I'm hoping those of us of a certain vintage will find my blog post on the 
subject resonates:

https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker/entry/haven_t_we_been_here_before4?lang=en_us

Martin Packer,
Mainframe Performance Consultant, zChampion
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






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

Re: [MVS-OE] Can one cause pthread_create / BPXPTATT / BPXINLPA to have SVAREA=YES ?

[Jim Mulder]

> Re: [MVS-OE] Can one cause pthread_create / BPXPTATT / BPXINLPA to 
> have SVAREA=YES ?
> 
> Sent by:
> 
> IBM Mainframe Discussion List 
> 
> On Sun, 29 Jan 2012 16:19:32 -0500 Duane Hughes  
wrote:
> 
> :>> It seems that pthread_create under zOS1.11 does not establish an 
FSA. Is
> :>there
> :>> some option to force it?
> 
> :>There is no option that tells the pthread_create service to do the 
ATTACH
> :>with a save area.
> 
> Thanks, Duane.
> 
> It appears that in zOS1.9 there was an FSA.
> 
> At any rate, would the "Post-process initiation exit (BPX_POSPROC_INIT)" 
get
> control in the right place?

  The ATTACH for pthread TCBs was changed to specify SVAREA=NO 
in z/OS 1.10.  The 152 bytes (144 for the FSA + 8 for LE anchor) below
16MB was a significant contributor to virtual storage constraints when 
running a large number of pthreads. 

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

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

Re: [MVS-OE] Can one cause pthread_create / BPXPTATT / BPXINLPA to have SVAREA=YES ?

[Binyamin Dissen]

On Sun, 29 Jan 2012 16:19:32 -0500 Duane Hughes  wrote:

:>> It seems that pthread_create under zOS1.11 does not establish an FSA. Is
:>there
:>> some option to force it?

:>There is no option that tells the pthread_create service to do the ATTACH
:>with a save area.

Thanks, Duane.

It appears that in zOS1.9 there was an FSA.

At any rate, would the "Post-process initiation exit (BPX_POSPROC_INIT)" get
control in the right place?

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: IBM announces 6% price increase for z/OS

[John Gilmore]

Not only are such references inappropriate, they are offensive.

The presidential election campaign has begun, and it time for us to
have a moratorium on things political here.

We cannot agree.  We can shut up about this topic.

--jg

On 1/29/12, Gord Tomlin  wrote:
> On 2012-01-29 08:45, Chase, John wrote:
>> Uncle Ben's Funny
>> Money has increased the money supply nearly fourfold the past couple of
>> years.
>
> These "Uncle Ben" references are inappropriate.
>
> --
>
> Regards, Gord Tomlin
> Action Software International
> (a division of Mazda Computer Corporation)
> Tel: (905) 470-7113, Fax: (905) 470-6507
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>


-- 
John Gilmore, Ashland, MA 01721 - USA

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

Re: IBM announces 6% price increase for z/OS

[Gord Tomlin]

On 2012-01-29 08:45, Chase, John wrote:

Uncle Ben's Funny
Money has increased the money supply nearly fourfold the past couple of
years.


These "Uncle Ben" references are inappropriate.

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

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

Can one cause pthread_create / BPXPTATT / BPXINLPA to have SVAREA=YES ?

[Binyamin Dissen]

It seems that pthread_create under zOS1.11 does not establish an FSA. Is there
some option to force it?

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: Annoying ISPF prob

[Shmuel Metz (Seymour J.)]

In , on 01/28/2012
   at 12:12 PM, Graham Hobbs  said:

>How might I subscribe to bit.listserv.ispf-l

Why would you want to? Subscribe[1] to ISPF-L; those reading
bit.listserv.ispf-l will see your messages after a brief delay.

[1] Send the SUBSCRIBE command to lists...@bama.ua.edu
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: IBM announces 6% price increase for z/OS

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Scott Chapman
> 
> [ snip ]
> 
> My theory about the z/OS price increase is that they did this so the
September release can be z/OS
> v2r1, at the same price as the new (raised) z/OS v1r13 price.
Otherwise if they just released v2 with
> a price increase there'd probably be a lot of people trying to hang on
to v1r13 for as long as
> possible.

Don't ignore "anticipation of inflation" as a reason.  Uncle Ben's Funny
Money has increased the money supply nearly fourfold the past couple of
years.  When that "funny money" finally goes into circulation, the value
of money will decrease "noticeably".  It's just "supply and demand":
when the supply goes up without a corresponding increase in demand, the
"price" (perceived value) of the oversupplied good goes down.

-jc-

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

Re: ABCs volume 13, JES3, revision available

[Jan Vanbrabant]

Yep, me too!
Jan

On Sun, Jan 29, 2012 at 10:19 AM, J R  wrote:

> I have been trying to download the SG24-7717-01 version
> since early yesterday, but I consistently end up with the
> SG24-7717-00 (June 2009) version.
>
> Is anyone else having this problem?
>
>  > Date: Sat, 28 Jan 2012 18:27:47 -0500
> > From: johnwgilmore0...@gmail.com
> > Subject: ABCs volume 13, JES3, revision available
> > To: IBM-MAIN@bama.ua.edu
> >
> > There is a new, significantly revised version of volume 13 available
> > for downloading at the IBM Redbooks site.
> >
> > John Gilmore, Ashland, MA 01721 - USA
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>

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

Re: ABCs volume 13, JES3, revision available

[J R]

I have been trying to download the SG24-7717-01 version 
since early yesterday, but I consistently end up with the 
SG24-7717-00 (June 2009) version.  

Is anyone else having this problem?  

  > Date: Sat, 28 Jan 2012 18:27:47 -0500
> From: johnwgilmore0...@gmail.com
> Subject: ABCs volume 13, JES3, revision available
> To: IBM-MAIN@bama.ua.edu
> 
> There is a new, significantly revised version of volume 13 available
> for downloading at the IBM Redbooks site.
> 
> John Gilmore, Ashland, MA 01721 - USA
  
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: 3390s on SAN?

[O'Brien, David W. (NIH/CIT) [C]]

Ron,

  Thank you very much. That's precisely the type of info I needed.

Thank You,
Dave O'Brien
NIH Contractor

From: Ron Hawkins [ronjhawk...@sbcglobal.net]
Sent: Friday, January 27, 2012 10:03 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: 3390s on SAN?

David,

Firstly, I work for HDS.

I'm assuming you mean that the VSP is the storage in the non-mainframe dept,
and the aging HDS DASD is a 9980V or earlier controller.

In order for the VSP to support CKD volumes you will need to install a FICON
feature. This is two boards for a total of 16 FICON ports. These will take
up two half slots in the controller, which means they can share the slot
with a fibre channel board. You cannot define CKD volumes in the VSP unless
there are FICON boards installed.

I'm not sure what your capacity demands are, but if you are at less than
100,000 4KiB IOPS you should be OK with these boards using just two ports
per board. The architecture change in the VSP means you need to be sure you
have enough Virtual Storage Directors (VSD) to handle the total IO load
though. VSD is a fancy name for Microprocessor Board - we don't put the MP
on the Front or Back end cards any more. If the dark side is worried about
sharing these you can assign CKD volumes and LUNs to different VSD so the
activity is physically separated. That's not a recommendation, it's just
something you can do to appease any concerns.

CKD volumes are formatted into a whole parity group. A parity group can be
4xHDD (R5 3D+1P, R10 2D+2D), or 8xHDD (R5 7D+1P, R6 6D+2P). Then there is a
method called concatenation that allows you to widen the RAID 10 stripe to
8xHDD, and the RAID 5 stripe to 16xHDD or 32xHDD. And finally there is a new
facility called MF-HDP (Hitachi Dynamic Pooling) that can "chunk" a volume
across up to 2KxHDD, where a chunk is 672 tracks. MF-HDP is supported on
RAID-5 and RAID-6 (recommended).

MF-HDP creates virtual volumes in a HDP Pool. The sum of the virtual volumes
can be greater than the actual parity group(s), but I'd dredge up all my old
Iceberg/RVA experience with Net Capacity Load before going that route. All
the volumes in the pool are 3390-A (any size you want) so the Dynamic Volume
Expansion method (DVE) is a simpler route than over provisioning. It's a
simple thing to create a bucket load of standard size volumes in the pool -
15 minutes in the Storage Navigator GUI to create a couple of thousand
volumes. (I love this in the lab).

>From the small amount of info you gave it sounds like an investment in some
FICON Boards, a few spindles and the MF-HDP setup and you could be up and
running on the VSP. If there's any concern about running open and Mainframe
in the same Global cache you can carve out a Cache Logical Partition (CLPR)
for the CKD Parity Groups and the dark side will be none the wiser.
Personally I don't see a problem with this, but the first four CLPR are free
and it gives some people nice warm and fuzzy feelings. Just make it equal to
the cache in your current HDS Controller and you'll be good.

With dedicated VSD, CLPR, Channels and RAID Group it's a bit like a condo
for MF and the dark side. You get your own apartment, kitchen, and bathroom,
but you have to share the corridors, lift and stairs :-)

And you may want to check your current disk activity rates before jumping
straight into 600GB drives. You don't want reduce 64x73GB HDD to 8x600GB HDD
and find you're stalling because you need to handle 2000 read cache misses a
second. SSD would make that no-brainer, but they are expensive.

Good Luck

Ron




> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of
> O'Brien, David W. (NIH/CIT) [C]
> Sent: Thursday, January 26, 2012 7:53 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: [IBM-MAIN] 3390s on SAN?
>
> There is an internal proposal to carve several TB of dasd from one of our
non-
> mainframe depts. And use it to replace our aging HDS DASD.
>
> Question: How easy/difficult is this to accomplish?
> We re-configured an array from 3390 mod-3s to mod 27/50s but the entire
array
> needed to be cleared of data. I'm assuming the same will be true in this
case.
> I'm also assuming that the disks will need to be re-modeled (I am probably
not
> using the correct terminology) to be mainframe compliant.
> Are my assumptions correct?
> Thank You,
> Dave O'Brien
> NIH Contractor
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
to
> lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.u