Channel types

2010-09-15 Thread Miklos Szigetvari 

 Hi

We would like to categorize the channels as in the Mainframe Concept book
 
(http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zos.znetwork/znetwork_74.htm)
CCW channel or Coupling channel or QDIO/OSA.
Can I make this from the channel type codes ?

--
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: Channel types

2010-09-15 Thread R.S. 

Miklos Szigetvari pisze:


 Hi

We would like to categorize the channels as in the Mainframe Concept book
 (http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zos.znetwork/znetwork_74.htm) 


CCW channel or Coupling channel or QDIO/OSA.
Can I make this from the channel type codes ?


In fact you just did it.

What do you want to achieve?
I'm asking, because there are different point of view:
CHPID type - as in HCD, i.e. CNC, FC, FCV, CTC, etc. A physical channel 
can be defined as one of allowable types. For ESCON you have 4 choices.
Channel card type - i.e. FICON Express2, Express4, Express8 - all those 
cards support same set of CHPID types.

Channel media - related to Channel card type.
CPC - machine model sometimes decides wht CHPID can be used, i.e. CFR 
cannot be defined on z9, even if the same card do support CFR.


CCW channels:
Bus&Tag, ESCON, FICON (no-Express, Express, Express2,4,8)
CHPID: BL, BY, CTC, CNC, CVC, CBY, FC, FCP, FCP

CF link channels:
ISC(fiber optic 2-3 generations), ICB (copper, several incompatible 
generations, ICB, ICB-3, ICB-4), PSIFB (Infiniband), IC (internal, 
emulated).

CHPID: CFP, CFR, CFS, CBP, CBR, CBS, ICP, ICR, ICS, CIB

Network channels:
Variuos OSA cards, IQD - emulated.
CHPID: OSA, OSE, OSD, OSC, OSN, IQD (and OSM, OSX for z196)

Remark: I intentionally excluded channel types available in Multiprise 
machines (EIO, DSD, ISD) and machines older than 9672 (IOC).



HTH
--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci 
wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 
2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec 
podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym 
BRE Banku SA bd w caoci opacone.

--
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: Channel types

2010-09-15 Thread Miklos Szigetvari 

 On 9/15/2010 10:57 AM, R.S. wrote:

Miklos Szigetvari pisze:


 Hi

We would like to categorize the channels as in the Mainframe Concept 
book
 (http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zos.znetwork/znetwork_74.htm) 


CCW channel or Coupling channel or QDIO/OSA.
Can I make this from the channel type codes ?


In fact you just did it.

What do you want to achieve?
I'm asking, because there are different point of view:
CHPID type - as in HCD, i.e. CNC, FC, FCV, CTC, etc. A physical 
channel can be defined as one of allowable types. For ESCON you have 4 
choices.
Channel card type - i.e. FICON Express2, Express4, Express8 - all 
those cards support same set of CHPID types.

Channel media - related to Channel card type.
CPC - machine model sometimes decides wht CHPID can be used, i.e. CFR 
cannot be defined on z9, even if the same card do support CFR.


CCW channels:
Bus&Tag, ESCON, FICON (no-Express, Express, Express2,4,8)
CHPID: BL, BY, CTC, CNC, CVC, CBY, FC, FCP, FCP

CF link channels:
ISC(fiber optic 2-3 generations), ICB (copper, several incompatible 
generations, ICB, ICB-3, ICB-4), PSIFB (Infiniband), IC (internal, 
emulated).

CHPID: CFP, CFR, CFS, CBP, CBR, CBS, ICP, ICR, ICS, CIB

Network channels:
Variuos OSA cards, IQD - emulated.
CHPID: OSA, OSE, OSD, OSC, OSN, IQD (and OSM, OSX for z196)

Remark: I intentionally excluded channel types available in Multiprise 
machines (EIO, DSD, ISD) and machines older than 9672 (IOC).



HTH

Hi

Thank you very much.
We want to say,  from the RMF  channel activity reports, that
  the DISK was active x% and the NETWORK was active y% in the last  
period,  for a performance monitor tool from us.
(I feel it has not too many sense, but this tool exits on other 
platforms ... )

From the RMF I got the acronyms and channel types.

--
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: Channel types

2010-09-15 Thread Ron Hawkins 
Miklos,

By "the disk" I assume you mean the volume. How can you figure out how busy
a volume is?

RMF does not report how busy a FICON channel is, only the FICON Channel MP.

What is the tool that reports FCP Channel busy and LUN busy on other
platforms. 

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Miklos Szigetvari
> Sent: Wednesday, September 15, 2010 2:27 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] Channel types
> 
>   On 9/15/2010 10:57 AM, R.S. wrote:
> > Miklos Szigetvari pisze:
> >>
> >>  Hi
> >>
> >> We would like to categorize the channels as in the Mainframe Concept
> >> book
> >>
>
(http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ib
m.
> zos.znetwork/znetwork_74.htm)
> >>
> >> CCW channel or Coupling channel or QDIO/OSA.
> >> Can I make this from the channel type codes ?
> >
> > In fact you just did it.
> >
> > What do you want to achieve?
> > I'm asking, because there are different point of view:
> > CHPID type - as in HCD, i.e. CNC, FC, FCV, CTC, etc. A physical
> > channel can be defined as one of allowable types. For ESCON you have 4
> > choices.
> > Channel card type - i.e. FICON Express2, Express4, Express8 - all
> > those cards support same set of CHPID types.
> > Channel media - related to Channel card type.
> > CPC - machine model sometimes decides wht CHPID can be used, i.e. CFR
> > cannot be defined on z9, even if the same card do support CFR.
> >
> > CCW channels:
> > Bus&Tag, ESCON, FICON (no-Express, Express, Express2,4,8)
> > CHPID: BL, BY, CTC, CNC, CVC, CBY, FC, FCP, FCP
> >
> > CF link channels:
> > ISC(fiber optic 2-3 generations), ICB (copper, several incompatible
> > generations, ICB, ICB-3, ICB-4), PSIFB (Infiniband), IC (internal,
> > emulated).
> > CHPID: CFP, CFR, CFS, CBP, CBR, CBS, ICP, ICR, ICS, CIB
> >
> > Network channels:
> > Variuos OSA cards, IQD - emulated.
> > CHPID: OSA, OSE, OSD, OSC, OSN, IQD (and OSM, OSX for z196)
> >
> > Remark: I intentionally excluded channel types available in Multiprise
> > machines (EIO, DSD, ISD) and machines older than 9672 (IOC).
> >
> >
> > HTH
>  Hi
> 
> Thank you very much.
>  We want to say,  from the RMF  channel activity reports, that
>the DISK was active x% and the NETWORK was active y% in the last
> period,  for a performance monitor tool from us.
> (I feel it has not too many sense, but this tool exits on other
> platforms ... )
>  From the RMF I got the acronyms and channel types.
> 
> --
> 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: z/OS sms dasd selection?

2010-09-15 Thread Ron Hawkins 
Mike,

The volumes you are referring to would have to have a different size (3390-9
or larger) for MSR to make a difference, and the CU/DASD in the storage
formatted as RAMAC (3390-3R) for availability to make a difference. If these
things are not different then columns 3 to 7 will not make a difference.

Guaranteed Space, Init ACC Response and Sustained Data Rate do not affect
the EDL.

I suspect the broken VTOC Index is affecting the Freespace values used to
build or exclude the volumes from the Primary EDL.

Ron

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Mike Schwab
> Sent: Tuesday, September 14, 2010 3:17 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] z/OS sms dasd selection?
> 
> In our shop, we occasionally have our VTOC Indexes get disabled.
> Unfortunately, these volumes then fill up with datasets and cause out
> of space abends, even though there is plenty of space on other
> volumes.  I suspect that Storage Class performance requirement columns
> 3, 4, 5, 6, 7, 13, 15 are causing low performance request classes to
> get allocated to these volumes instead of volumes with working
> indexes.  Setting the volume to Disabled, New then rebuilding the
> index does work, but I am trying to avoid the volume filling up in the
> meantime.
> 
> So, would changing those columns (or your list of columns) to blanks,
> or the same value, across all storage classes, stop the skewed
> allocations?
> 
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
> 
> --
> 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: Channel types

2010-09-15 Thread Miklos Szigetvari 

 Hi
On 9/15/2010 12:24 PM, Ron Hawkins wrote:

Miklos,

By "the disk" I assume you mean the volume. How can you figure out how busy
a volume is?


Not a volume,  the complete system, all the DISK channel's
(if we can figure out this)

RMF does not report how busy a FICON channel is, only the FICON Channel MP.

What is the tool that reports FCP Channel busy and LUN busy on other
platforms.

I don't know if any tool can report this.

My colleagues want to get four nice charts about CPU , STORAGE , DISK 
and  NET activity.
On the other side, it has some sense to ask how active was the complete 
DISK or NETWORK system

in a period.


Ron


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On

Behalf Of

Miklos Szigetvari
Sent: Wednesday, September 15, 2010 2:27 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: [IBM-MAIN] Channel types

   On 9/15/2010 10:57 AM, R.S. wrote:

Miklos Szigetvari pisze:

  Hi

We would like to categorize the channels as in the Mainframe Concept
book


(http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ib
m.

zos.znetwork/znetwork_74.htm)

CCW channel or Coupling channel or QDIO/OSA.
Can I make this from the channel type codes ?

In fact you just did it.

What do you want to achieve?
I'm asking, because there are different point of view:
CHPID type - as in HCD, i.e. CNC, FC, FCV, CTC, etc. A physical
channel can be defined as one of allowable types. For ESCON you have 4
choices.
Channel card type - i.e. FICON Express2, Express4, Express8 - all
those cards support same set of CHPID types.
Channel media - related to Channel card type.
CPC - machine model sometimes decides wht CHPID can be used, i.e. CFR
cannot be defined on z9, even if the same card do support CFR.

CCW channels:
Bus&Tag, ESCON, FICON (no-Express, Express, Express2,4,8)
CHPID: BL, BY, CTC, CNC, CVC, CBY, FC, FCP, FCP

CF link channels:
ISC(fiber optic 2-3 generations), ICB (copper, several incompatible
generations, ICB, ICB-3, ICB-4), PSIFB (Infiniband), IC (internal,
emulated).
CHPID: CFP, CFR, CFS, CBP, CBR, CBS, ICP, ICR, ICS, CIB

Network channels:
Variuos OSA cards, IQD - emulated.
CHPID: OSA, OSE, OSD, OSC, OSN, IQD (and OSM, OSX for z196)

Remark: I intentionally excluded channel types available in Multiprise
machines (EIO, DSD, ISD) and machines older than 9672 (IOC).


HTH

  Hi

Thank you very much.
  We want to say,  from the RMF  channel activity reports, that
the DISK was active x% and the NETWORK was active y% in the last
period,  for a performance monitor tool from us.
(I feel it has not too many sense, but this tool exits on other
platforms ... )
  From the RMF I got the acronyms and channel types.

--
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: Another brain-dead quoted PROC parm question

2010-09-15 Thread Jan MOEYERSONS 
On Tue, 14 Sep 2010 09:35:51 -0700, Charles Mills  
wrote:

>I can't get it to work, sadly. You had me real encouraged.
>
>//FOO  PROC  M=''
>//  SET Q=
>//  SET P=&Q.&M.&Q
>//STEP1  EXEC PGM=IEFBR14,PARM=&Q.&P.&Q
>...
>//STEP2 EXEC FOO,M='Life isn''t fair'
>
>Gives me a JCL error IEFC629I INCORRECT USE OF APOSTROPHE ON THE SET
>STATEMENT on the second SET statement.
>
You're right. With apostrophes in the text it does not work...

Sorry, then I don't know. Or should that be: 'Sorry, I dont know'...

Cheers,

Jantje.

--
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: DFSMS and System Managed Buffering

2010-09-15 Thread Yifat Oren 
Tobias,

The reason you are not seeing the expected savings is that the IDCAMS REPRO
has already set and used the optimal number of data buffers regardless of
the DATACLAS change (so, no change has actually taken place; optimal
buffering was used for both before and after runs). 

You should see the savings when programs that are not taking care of their
VSAM buffering start using these data sets.

I too think that 1MB is a bit constrictive for direct access LSR (bias=do)
buffering.

Best Regards,
Yifat
 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Tobias Cafiero
Sent: יום ג 14 ספטמבר 2010 18:44
To: IBM-MAIN@bama.ua.edu
Subject: DFSMS and System Managed Buffering

Hello, 
I'm testing the SMB option in the DFSMS DATACLS Constructs, but don't
yet see a performance boost as promised. At this point I'm using just a
del/define,repro and pointing to the SMB DATACLS. The DATACLS is extended
and contains the following values:

Record Access Bias  . . . . : SYSTEM
System Managed Buffer  . . . : 1M 

The STORCLS is our standard non-striped type. Has anyone implemented SMB on
their system.

Thanks in Advance
Tobias Cafiero  

--
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: z/OS V 1.12 diffe rences and z196 (the new mainf rame) impa cts‏

2010-09-15 Thread john gilmore 
This thread has gone on and on in the usual way, with posters talking at cross 
purposes.
 
I do not wish to trivialize Peter Relson's comment, but one interpretation of 
what he said that seems to me to be at once reasonable, helpful, and consistent 
with his words is just that
 
1) an amode(24) program that is unaware that amode(31) and amode(64) exist will 
not itself be impacted by the existence of amode(31) and amode(64), and
 
2) an amode(31) program that is unaware that amode(64) exists will not itself 
be impacted by the existence  of amode(64).
 
THis formulation, which is also consistent with the rules of English syntax, is 
notable for what it does not say or imply.  It does not 
 
1) say or imply that an amode(31) routine that invokes an amode(24) routine 
will not be impacted adversely by that amode(24) routine's ignorance of its 
requirements, or
 
2) say or imply that an amode(64) routine that invokes an amode(31) routine 
will  not be impacted adversely by that amode(31) routine's ignorance of its 
requirements.
 
An invoking routine higher in the  sequence
 
amode(64) > amode(31) > amode(24)
 
than a routine it invokes must take its own environment-preserving precautions. 
 It cannot expect a routine that is a fortiori ignorant of its more stringent 
requirements to take these precautions for it.
 
To repeat myself now, since it would appear to be necessary, Peter Relson's 
formulation is notable for its asymmetry.  It does not, for example, say that 
an amode(64) routine cannot be adversely impacted by the blissfully ignorant 
functioning of an amode(31) or amode(24) routine that it invokes.  It says only 
that that this blissful ignorance will not be intruded upon in its private 
garden.
 
John Gilmore Ashland, MA 01721-1817 USA

  

--
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: z/os 1.11 upgrade and pl/1 jcl sensitivity

2010-09-15 Thread Shmuel Metz (Seymour J.) 
In <3fd1837f9564834ab2063f30e2b2c...@mail.cenhud.com>, on 09/14/2010
   at 03:56 PM, Tim Brown  said:

>Now we are seeing it for DD statements for output files. These had
>been grandfathered since many programmers always replicated someone
>elses JCL, and so on and so on... (Dont touch whats not broken)

Blindly copied JCL is by definition broken.
 
-- 
 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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS, TCP/IP, and OSA

2010-09-15 Thread Shmuel Metz (Seymour J.) 
In
<6b34aedeeb35274e81437a445900b2d7934...@hdqsrvexcvs.ssfcuad.ssfcu.org>,
on 09/14/2010
   at 05:22 PM, "Ward, Mike S"  said:

>Hello all, I have a question. I was talking with someone that said
>you don't need OSA's to run tcpip under z/os and use it to
>communicate with the outside world. If that's true then what would be
>used instead of an OSA?

3172? Cisco?
 
-- 
 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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS V1.12 differences and z196 (the new mainframe) impacts

2010-09-15 Thread Robert A. Rosenberg 
At 14:22 -0400 on 09/14/2010, George Henke wrote about Re: z/OS V1.12 
differences and z196 (the new mainframe) imp:



Which compromises the entire purpose of the SAVE/RESTORE Register Convention
which has been held "sacred" since the beginning of S/360, PCP, and/or "S"
cubed.



If the 64-bit program calling the 24/31 bit program wants to insure 
the integrity of the high end of the registers, it is ITS 
responsibility to save them around the call. That is the function of 
the 64-bit storing Save Area formats. So long as the called program 
wants a old-style Format 1 Save area, the high end is subject to 
being altered.





On Tue, Sep 14, 2010 at 1:28 PM, Binyamin Dissen 
 wrote:



 On Tue, 14 Sep 2010 11:08:59 -0500 Walt Farrell 
 wrote:

 :>On Tue, 14 Sep 2010 10:26:30 -0500, McKown, John
 :> wrote:

 :>>> -Original Message-
 :>>> From: IBM Mainframe Discussion List
 :>>> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin
 :>>> Sent: Tuesday, September 14, 2010 10:23 AM
 :>>> To: IBM-MAIN@bama.ua.edu
 :>>> Subject: Re: z/OS V1.12 differences and z196 (the new
 :>>> mainframe) impacts

 :>>> On Tue, 14 Sep 2010 11:04:47 -0400, David Cole wrote:

 :>>> >>Except for regs 0,1,15 your assertion is true.

 :>>> >>The high halves of those regs are not preserved across any interface
 :>>> >>unless otherwise documented.

 :>>> >This is in contradiction to a verbal statement he made at a
 :>>> >presentation several years earlier wherein he flatly stated that no
 :>>> >preexisting AMODE(24/31) program would ever behave differently (due
 :>>> >to the widening of the registers) when run in z/OS vis-a-vis OS/390.
 :>>> >Unfortunately, I don't have "the video".

 :>>> Ah, semantics!  Can a program run in AMODE(24/31) in OS/390
 :>>> (in a supported configuration) and use grande registers?

 :>>Sure. Why not. I use them for 64 bit numbers where I used to use a
 register
 :>pair. Can OS/390 run on z hardware? I don't remember anymore. But use of
 :>Grande registers in application code cannot be stopped by the OS. Of
 course,
 :>if you call other routines, you'd better store them yourself. Because
 :>somebody else might be doing the same.

 :>In this context, John, it seems to me that "pre-existing" means "before
 :>64-bit registers existed", and thus your programs that use 64-bit
 registers
 :>don't count. Pre-existing programs would only use 32-bit registers, and
 :>would not have any knowledge of the high-halves of the 64-bit registers,
 and
 :>are not affected by this change.

 I have to agree with IBM in this context. Pre-Z programs did not use the
 top
 half and thus can run unchanged. New Z programs have to take into
 consideration that the entire 64 bits of R15-R1 can change.

 --
 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: 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: z/OS sms dasd selection?

2010-09-15 Thread John H Kington 
Mike,
Ron is correct about the broken vtoc index messing up the free space info
that SMS tracks and changing MSR will not have any effect. If you have
an automation tool, I recommend having it issue a v sms command to
put the volume in disable for new allocations whenever a vtoc disabled
message appears and send you an alert.
Regards,
John
>The volumes you are referring to would have to have a different size (3390-9
>or larger) for MSR to make a difference, and the CU/DASD in the storage
>formatted as RAMAC (3390-3R) for availability to make a difference. If these
>things are not different then columns 3 to 7 will not make a difference.
>
>Guaranteed Space, Init ACC Response and Sustained Data Rate do not affect
>the EDL.
>
>I suspect the broken VTOC Index is affecting the Freespace values used to
>build or exclude the volumes from the Primary EDL.
>

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Mike Schwab
> Sent: Tuesday, September 14, 2010 3:17 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] z/OS sms dasd selection?
>
> In our shop, we occasionally have our VTOC Indexes get disabled.
> Unfortunately, these volumes then fill up with datasets and cause out
> of space abends, even though there is plenty of space on other
> volumes.  I suspect that Storage Class performance requirement columns
> 3, 4, 5, 6, 7, 13, 15 are causing low performance request classes to
> get allocated to these volumes instead of volumes with working
> indexes.  Setting the volume to Disabled, New then rebuilding the
> index does work, but I am trying to avoid the volume filling up in the
> meantime.
>
> So, would changing those columns (or your list of columns) to blanks,
> or the same value, across all storage classes, stop the skewed
> allocations?
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> --
> 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

NOTICE:  The information contained in this electronic mail transmission is 
intended by Convergys Corporation for the use of the named individual or entity 
to which it is directed and may contain information that is privileged or 
otherwise confidential.  If you have received this electronic mail transmission 
in error, please delete it from your system without copying or forwarding it, 
and notify the sender of the error by reply email or by telephone (collect), so 
that the sender's address records can be corrected.

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

VSAM Quick Index‏

2010-09-15 Thread Doug Fuerst 
 Has anyone converted from Quick Index back to regular IDCAMS 
processing? We only have about 12 jobs actually using QI and would like 
to eliminate it.

Thanks.

Doug Fuerst

--
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: VSAM Quick Index‏

2010-09-15 Thread Larry Crilley 
Ah.  VQI.  Makes me yearn for the old days at Softworks.  A great company
with some great people!  I did very little work on VQI during my long tenure
a Softworks, but I am very familiar with it.  When IDCAMS was updated to use
the internal house sort (back in 91, 92 ??), the need for VQI really became
slim to none.  The only real case you can make for keeping VQI is if you
need to build multiple alternate indexes over a single cluster.  VQI can
build multiple alternate indexes with one pass (read) of the input file.
VQI accomplished its task much faster than IDCAMS when IDCAMS has its own
internal sort.

I would think you could convert your job(s) to use IDCAMS and not suffer
much, if any, performance.

Larry Crilley
Dino-Software Corporation
800.480.DINO
www.dino-software.com

T-REX - Superior ICF catalog mgmt with full Tape support and HSM Auditing
REORGadon - First ever online REORG for HSM
TERADON - First ever REPRO MERGECAT While-OPEN 
XTINCT - Secure DASD/TAPE data eradication
RTD – DASD Real Time Defrag
DAL - DINO healthcheck Analysis service for Legato 
SENTINEL – Real-time FTP Management. All Secure, all the time.


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Doug Fuerst
Sent: Wednesday, September 15, 2010 8:51 AM
To: IBM-MAIN@bama.ua.edu
Subject: VSAM Quick Index‏

  Has anyone converted from Quick Index back to regular IDCAMS 
processing? We only have about 12 jobs actually using QI and would like 
to eliminate it.
Thanks.

Doug Fuerst

--
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: z/OS, TCP/IP, and OSA

2010-09-15 Thread Hal Merritt 
Technically true, I suppose, but what's the point? OSA's come pretty much as 
standard equipment these days. 
 


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Ward, Mike S
Sent: Tuesday, September 14, 2010 5:22 PM
To: IBM-MAIN@bama.ua.edu
Subject: z/OS, TCP/IP, and OSA

Hello all, I have a question. I was talking with someone that said you
don't need OSA's to run tcpip under z/os and use it to communicate with
the outside world. If that's true then what would be used instead of an
OSA?

 
NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all 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: Does anyone combine OMEGAMON and OMEGAVIEW in the same CSI?

2010-09-15 Thread Kurt Quackenbush 

So if I had OMEGAMON and OMEGAVIEW in the same CSI with different TZONEs and
DZONEs and specified XZGROUP and XZREQ parms, the PTF that went on OMEGAMON
would have also been applied to OMEGAVIEW and I would have avoided the
ensuing OC4 and having to apply it twice.


I have no specific knowledge of OMEGAMON/OMEGAVIEW and the subject PTF 
which started this thread, so I was a bit vague in my prior response to 
the question.  However, I don't anyone to misinterpret what I said or 
what XZGROUP/XZREQ will do for you.  It is possible when applying PTFs 
to one target using these operands to identify missing requisite PTFs in 
other target zones.  Such requisite PTFs must be identified by ++IFREQ 
statements.  This does not mean those requisites will be automatically 
applied to the other target zones.


Kurt Quackenbush -- IBM, SMP/E Development

--
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: z/OS V1.12 differences and z196 (the new mainframe) impacts

2010-09-15 Thread Tom Marchant 
On Wed, 15 Sep 2010 08:00:07 -0400, Robert A. Rosenberg wrote:
>
>If the 64-bit program calling the 24/31 bit program wants to insure
>the integrity of the high end of the registers, it is ITS
>responsibility to save them around the call.

That is incorrect.  As clearly documented in the Assembler Services 
Guide, 


Unless otherwise defined by the individual interface, the calling 
program should expect, upon return, that  
- The low halves (Bits 32-63) of GPRs 2 through 13 are unchanged  
- The high halves (Bits 0-31) of GPRs 2 through 14 are unchanged


>So long as the called program
>wants a old-style Format 1 Save area, the high end is subject to
>being altered.

There is no such thing as a format 1 save area.  You are referring 
to a standard 72-byte save area.  

-- 
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: z/OS V1.12 differences and z196 (the new mainframe) impacts

2010-09-15 Thread Binyamin Dissen 
On Wed, 15 Sep 2010 08:00:07 -0400 "Robert A. Rosenberg" 
wrote:

:>At 14:22 -0400 on 09/14/2010, George Henke wrote about Re: z/OS V1.12 
:>differences and z196 (the new mainframe) imp:

:>>Which compromises the entire purpose of the SAVE/RESTORE Register Convention
:>>which has been held "sacred" since the beginning of S/360, PCP, and/or "S"
:>>cubed.

:>If the 64-bit program calling the 24/31 bit program wants to insure 
:>the integrity of the high end of the registers, it is ITS 
:>responsibility to save them around the call. That is the function of 
:>the 64-bit storing Save Area formats. So long as the called program 
:>wants a old-style Format 1 Save area, the high end is subject to 
:>being altered.

I would distinguish between R15-R1 and the other registers. A program must
maintain the integrity of the callers top half of R2-R14. 

Of course, if a 64Bit routine calls a routine that expects to be in AM31 in
AM64, all bets are off.

:>>On Tue, Sep 14, 2010 at 1:28 PM, Binyamin Dissen >>  wrote:

:>>>  On Tue, 14 Sep 2010 11:08:59 -0500 Walt Farrell 
:>>>  wrote:

:>>>  :>On Tue, 14 Sep 2010 10:26:30 -0500, McKown, John
:>>>  :> wrote:

:>>>  :>>> -Original Message-
:>>>  :>>> From: IBM Mainframe Discussion List
:>>>  :>>> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin
:>>>  :>>> Sent: Tuesday, September 14, 2010 10:23 AM
:>>>  :>>> To: IBM-MAIN@bama.ua.edu
:>>>  :>>> Subject: Re: z/OS V1.12 differences and z196 (the new
:>>>  :>>> mainframe) impacts

:>>>  :>>> On Tue, 14 Sep 2010 11:04:47 -0400, David Cole wrote:

:>>>  :>>> >>Except for regs 0,1,15 your assertion is true.

:>>>  :>>> >>The high halves of those regs are not preserved across any 
interface
:>>>  :>>> >>unless otherwise documented.

:>>>  :>>> >This is in contradiction to a verbal statement he made at a
:>>>  :>>> >presentation several years earlier wherein he flatly stated that no
:>>>  :>>> >preexisting AMODE(24/31) program would ever behave differently (due
:>>>  :>>> >to the widening of the registers) when run in z/OS vis-a-vis OS/390.
:>>>  :>>> >Unfortunately, I don't have "the video".

:>>>  :>>> Ah, semantics!  Can a program run in AMODE(24/31) in OS/390
:>>>  :>>> (in a supported configuration) and use grande registers?

:>>>  :>>Sure. Why not. I use them for 64 bit numbers where I used to use a
:>>>  register
:>>>  :>pair. Can OS/390 run on z hardware? I don't remember anymore. But use of
:>>>  :>Grande registers in application code cannot be stopped by the OS. Of
:>>>  course,
:>>>  :>if you call other routines, you'd better store them yourself. Because
:>>>  :>somebody else might be doing the same.

:>>>  :>In this context, John, it seems to me that "pre-existing" means "before
:>>>  :>64-bit registers existed", and thus your programs that use 64-bit
:>>>  registers
:>>>  :>don't count. Pre-existing programs would only use 32-bit registers, and
:>>>  :>would not have any knowledge of the high-halves of the 64-bit registers,
:>>>  and
:>>>  :>are not affected by this change.

:>>>  I have to agree with IBM in this context. Pre-Z programs did not use the
:>>>  top
:>>>  half and thus can run unchanged. New Z programs have to take into
:>>>  consideration that the entire 64 bits of R15-R1 can change.

--
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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS V1.12 differences and z196 (the new mainframe) impacts

2010-09-15 Thread Tom Marchant 
On Tue, 14 Sep 2010 13:38:15 -0500, Mike Schwab wrote:

>On Tue, Sep 14, 2010 at 12:15 PM, Tony Harminc wrote:
>
>> Well, we had this discussion at great length a few years ago... The
>> pre-existing 24- or 31-bit program that's been running for many years
>> now gets called by a 64-bit program, issues a GETMAIN which now zeros
>> the high half of 64-bit R1, does some stuff, and returns to its
>> caller, restoring the only R1 it knows about, which is 32 bits.
>>
>> The 64-bit caller has had its R1 clobbered by calling the pre-existing
>> program, even though the pre-existing program used no 64-bit
>> instructions or services and restored R1 as it always has done, and as
>> its documentation states.

The programmer who wrote the 64-bit program should not expect that 
the bits 0-31 of registers 0, 1 and 15 are preserved.

>
>This is just like a 31 bit program calling a 24 bit program.  You have
>to save your own registers and set up the with 24 bit addresses before
>calling the 24 bit program.

No, you don't have to save your own registers if you are a 31-bit 
program calling a 24-bit program.  You do, of course, have to ensure 
that the called program will get control in AMODE(24) and must expect 
that it will return in AMODE(24), but that is a very different discussion.

An AMODE(64) program does not have to save its registers either. 
Read the Assembler Services Guide chapter on Linkage Conventions.

>
>System interrupts do have to restore all 64 bits of the register, but not
calls.

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

A most curious result

2010-09-15 Thread kopplin 
Some years ago, in pursuit of Headcount reduction, a decision was made to 
suppress the 
display of WTORs that weren't recognized by automation (OPS/MVS) as important.  
This
had the desired effect, and headcount reduction proceeded.  In the years since 
then,
the remaining operators have learned to do the displays and check for 
unanswered WTORs.
But this happens on a very intermittent basis.

So, on July 28, a batch job was giving trouble, and one of the operators 
entered:

F R,R,EXIT=   (This will cause MAINVIEW to terminate the address space)

Which promptly generated a WTOR which was not seen because of the rule 
described in
the first paragraph above.  The job was later removed via the MVS FORCE command.

Fast forward from July 28 to September 11 (a date filled with premonitions of 
doom.)

An operator does the appropriate display and notices the WTOR.  Asks the MVS 
oncall
person how to deal with it, and gets a response to reply 'U'.  Oops.

This caused MAINVIEW to issue a couple of messages that it had terminated job 
.

Followed immediately by MVS and JES3 issuing messages that an IMS DBRC address 
space had
just gone away in the ugliest possible manner.

In all the fun and games that follow such an interesting event, it seems never 
to have 
occurred that there might be a correlation between the smoking gun in their 
hand, and
the hole in their foot.

Most curious.

--
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: z/OS, TCP/IP, and OSA

2010-09-15 Thread Scott Ford 
I think we need to know what the real issue with the question is in regard to 
OSA's TCP, etc.
There are several ways to 'skin the cat'  to do external TCPIP networking, 
OSA's 
and CISCO CIPS are the ones that I thnk folks are familiar with nowdays.
So Mike to answer thwe question you dont need an OSA to do TCPIP com outside, 
you could use a CIP, or another IP Gateway device.


 
Scott J Ford
 





From: Timothy Sipples 
To: IBM-MAIN@bama.ua.edu
Sent: Wed, September 15, 2010 12:59:36 AM
Subject: Re: z/OS, TCP/IP, and OSA

Another example was the Multiprise 3000, which did not have OSA hardware
but could run z/OS prior to Version 1 Release 6. A current example of z/OS
communicating using TCP/IP without OSA hardware is the Rational Developer
for System z Unit Test Feature.

That said, on an OSA-capable machine it's hard to imagine nowadays why you
wouldn't use OSA hardware for external TCP/IP connections.

- - - - -
Timothy Sipples
Resident Enterprise Architect
STG Value Creation & Complex Deals Team
IBM Growth Markets (Based in Singapore)
E-Mail: timothy.sipp...@us.ibm.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





--
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: z/OS V1.12 differences and z196 (the new mainframe) impacts

2010-09-15 Thread Shmuel Metz (Seymour J.) 
In , on 09/14/2010
   at 10:22 AM, Paul Gilmartin  said:

>Ah, semantics!  Can a program run in AMODE(24/31) in OS/390 (in a
>supported configuration) and use grande registers?

Yes. You might want to ask a different question.
 
-- 
 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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Issuing WTOR SVC In Multitask Environment

2010-09-15 Thread Shmuel Metz (Seymour J.) 
In <1284416005.6627.39.ca...@mckown5.johnmckown.net>, on 09/13/2010
   at 05:13 PM, John McKown  said:

>Is that like OS/360 PCP?

The original options in OS/360 were option 1, SSS, opption 2, MSS and
option 4, MPS. SSS became PCP, MSS became MFT and MPS became VMS[1],
then MVT. MFT II was somewhat of a cross between MFT and MVT.

[1] But did not play with a full DEC. Think MVT with all jobs
allocating from the same region.
 
-- 
 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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: EMC DLM box

2010-09-15 Thread Patrick Lyon 
On Tue, 14 Sep 2010 15:00:23 -0400, Sabo, Frank 
 wrote:

>Good afternoon everyone,
>
>Question does any one out there have an EMC DLM box?
>I have been trying to get one up and functional for a while now.
>
>I have genned the box to both HCD and SMS the problem that I am having is 
in the SMS  definitions for the box does not show up as manual as per EMC 
instead they show up a blank. In SMS 10 3 menu.
>
>LIBRARY ,DEVICELIBRARYLIBRARY
>NAME,TYPE  TYPE   ID
>--(2)---,--(3)---  ---(4)---  --(5)--
>PRODLIB1,  -  1
>
>If possible I would like to have a conversation with someone as to what I am 
doing wrong so that I can get this project moving forward.
>
>Thanks for any help that I can get.
>
>Frank W Sabo Jr.

Frank - I am going through my notes of when we set ours up.  

I do not see you mention you created anything with OAM.  Did you?

I'm not saying this is the issue, just looking at what we did.

--
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: DFSMS and System Managed Buffering

2010-09-15 Thread Tobias Cafiero 
Ron,
  I was expecting results similiar to the ones I saw in VSAM Demystified.  
Instead of using Repro, I'll  write something to do my testing. We will be 
using 
Dataset Striping and I am interested in putting them together. 

Tob 

--
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: DFSMS and System Managed Buffering

2010-09-15 Thread Ron Hawkins 
Yifat,

Without any other specification, such as BUFSP at define or BFND on the
REPRO, IDCAMS without SMB used to default to BUFND of two, and only read one
CI at a time.

Are you saying the default changed, or changed for Extended Format?

I suggested it would not make huge difference for REPRO because the default
CISZ for VSAM is 18K or 26K, and a large BUFND would not make a large
difference in elapsed time on a small to medium size dataset.

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Yifat Oren
> Sent: Wednesday, September 15, 2010 4:05 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] DFSMS and System Managed Buffering
> 
> Tobias,
> 
> The reason you are not seeing the expected savings is that the IDCAMS
REPRO
> has already set and used the optimal number of data buffers regardless of
> the DATACLAS change (so, no change has actually taken place; optimal
> buffering was used for both before and after runs).
> 
> You should see the savings when programs that are not taking care of their
> VSAM buffering start using these data sets.
> 
> I too think that 1MB is a bit constrictive for direct access LSR (bias=do)
> buffering.
> 
> Best Regards,
> Yifat
> 
> 

--
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: Issuing WTOR SVC In Multitask Environment

2010-09-15 Thread Mullen, Patrick 
I like it, reminds me of an old Python sketch:

Option 3: There is NOOO option 3!


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Shmuel Metz (Seymour J.)
Sent: September 14, 2010 2:02 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Issuing WTOR SVC In Multitask Environment


In <1284416005.6627.39.ca...@mckown5.johnmckown.net>, on 09/13/2010
   at 05:13 PM, John McKown  said:

>Is that like OS/360 PCP?

The original options in OS/360 were option 1, SSS, opption 2, MSS and
option 4, MPS. SSS became PCP, MSS became MFT and MPS became VMS[1],
then MVT. MFT II was somewhat of a cross between MFT and MVT.

[1] But did not play with a full DEC. Think MVT with all jobs
allocating from the same region.
 
-- 
 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: 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: A most curious result

2010-09-15 Thread Elardus Engelbrecht 
kopplin wrote:

>Some years ago, in pursuit of Headcount reduction, a decision was made to 
suppress the display of WTORs that weren't recognized by automation 
(OPS/MVS) as important. This had the desired effect, and headcount 
reduction proceeded.  In the years since then, the remaining operators have 
learned to do the displays and check for unanswered WTORs. But this happens 
on a very intermittent basis.

>So, on July 28, a batch job was giving trouble, and one of the operators 
entered:
>F R,R,EXIT=   (This will cause MAINVIEW to terminate the address 
space)
>Which promptly generated a WTOR which was not seen because of the rule 
described in the first paragraph above.  The job was later removed via the 
MVS FORCE command. Fast forward from July 28 to September 11 (a date 
filled with premonitions of doom.)

>An operator does the appropriate display and notices the WTOR.  Asks the 
MVS oncall person how to deal with it, and gets a response to reply 'U'.  Oops.

Make that OOPS! ;-D

>This caused MAINVIEW to issue a couple of messages that it had terminated 
job .
>Followed immediately by MVS and JES3 issuing messages that an IMS DBRC 
address space had just gone away in the ugliest possible manner.

Ouch! Your DBAs are perhaps not that happy?

>In all the fun and games that follow such an interesting event, it seems 
never to have occurred that there might be a correlation between the smoking 
gun in their hand, and the hole in their foot.

Reduce the headcount of the management is perhaps the best next step? ;)

If at least one person can learn this lesson: a WTOR is there for a reason -
 'eventual action needed'. 

>Most curious.

Yup! One of the most beautiful war stories in a long time! Thanks Kopplin!

Most entertaining. ;-D

Groete / Greetings
Elardus Engelbrecht

--
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: DFSMS and System Managed Buffering

2010-09-15 Thread Yifat Oren 
Ron,

The defaults have changed;

This is not the best pointer, but it's all I could find with a quick search
http://www-01.ibm.com/support/docview.wss?uid=isg1OA01898: "With OW51451,
REPRO uses AMDCIPCA (CI per CA) value for BUFND when SHROPT is not 4."

Such buffering (BUFND=CI/CA) will make a difference; espcially an elapsed
time difference (but also CPU).

Best Regards,
Yifat


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Ron Hawkins
Sent: יום ד 15 ספטמבר 2010 17:28
To: IBM-MAIN@bama.ua.edu
Subject: Re: DFSMS and System Managed Buffering

Yifat,

Without any other specification, such as BUFSP at define or BFND on the
REPRO, IDCAMS without SMB used to default to BUFND of two, and only read one
CI at a time.

Are you saying the default changed, or changed for Extended Format?

I suggested it would not make huge difference for REPRO because the default
CISZ for VSAM is 18K or 26K, and a large BUFND would not make a large
difference in elapsed time on a small to medium size dataset.

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Yifat Oren
> Sent: Wednesday, September 15, 2010 4:05 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] DFSMS and System Managed Buffering
> 
> Tobias,
> 
> The reason you are not seeing the expected savings is that the IDCAMS
REPRO
> has already set and used the optimal number of data buffers regardless 
> of the DATACLAS change (so, no change has actually taken place; 
> optimal buffering was used for both before and after runs).
> 
> You should see the savings when programs that are not taking care of 
> their VSAM buffering start using these data sets.
> 
> I too think that 1MB is a bit constrictive for direct access LSR 
> (bias=do) buffering.
> 
> Best Regards,
> Yifat
> 
> 

--
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: Channel types

2010-09-15 Thread Ron Hawkins 
Miklos,

Figuring out how busy all the channel processors are on the Host is easy. It
is reported in the Type 73 RMF record for the LPAR and the CEC. This does
not tell you how busy the channel is. A FICON Express Four channel maxes out
at approx 14,000 normal IOPS, but the FICON channel itself will handle more
than double that IO rate. The channel is not 100% busy when the FICON MP on
the host runs out of steam.

Also realize that this does not tell you how busy the channel processors are
on the Front End Director boards connecting the storage to the channel.
There is not a one to one correspondence because the storage typically has a
very different architecture and processing cost. For instance IBM storage
has a single microprocessor on each board which is shared by four channels,
while HDS has four micro-processors that are shared by all four channels on
the Board. RMF has no idea how busy these MP are in IBM and HDS, and there
is no way to estimate it.

This becomes even more complex and confusing when you have channel fan-in,
meaning multiple CEC connect to one storage port through a switch, or
multiple CEC connected to one board. The only way to measure channel busy
behavior is to understand channel path busy using RMF and the MP measurement
provided by the storage vendor.

For volume busy you are going to get some very unexpected results if you run
two or more LPARs, or PAV/HypePAV. The traditional measure for Device busy
is (Connect + Disconnect)/ Interval, but because Multiple Device Allegiance
and Parallel Access Volumes allow concurrent IO to the volume you can easily
end up with a volume greater than 100% busy. Because volume busy has little
to do with queuing for MDA and PAV what is the purpose of a Volume busy
measure? Note that a LUN Busy measurement on other platforms is just as
(in)accurate unless the Q-DEPTH is set to one.

If you really want disk and not volume busy, then again there is nothing in
RMF, and you have turn to the Storage vendor's internal performance numbers
for the Array Groups.

Of course the nice charts will be important for Capacity Plan trends, but
I'd be sure your colleagues understand how to apply the information they are
looking at. I still remember showing my manager a volume running at greater
than 100% busy on a 7980-3 because of Logical Device Allegiance and two CEC
access, and while I thought it was great he thought it was a problem.

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Miklos Szigetvari
> Sent: Wednesday, September 15, 2010 3:40 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] Channel types
> 
>   Hi
> On 9/15/2010 12:24 PM, Ron Hawkins wrote:
> > Miklos,
> >
> > By "the disk" I assume you mean the volume. How can you figure out how
busy
> > a volume is?
> >
> Not a volume,  the complete system, all the DISK channel's
> (if we can figure out this)
> > RMF does not report how busy a FICON channel is, only the FICON Channel
MP.
> >
> > What is the tool that reports FCP Channel busy and LUN busy on other
> > platforms.
> I don't know if any tool can report this.
> 
> My colleagues want to get four nice charts about CPU , STORAGE , DISK
> and  NET activity.
> On the other side, it has some sense to ask how active was the complete
> DISK or NETWORK system
> in a period.
> 
> > Ron
> >
> >> -Original Message-
> >> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> > Behalf Of
> >> Miklos Szigetvari
> >> Sent: Wednesday, September 15, 2010 2:27 AM
> >> To: IBM-MAIN@bama.ua.edu
> >> Subject: Re: [IBM-MAIN] Channel types
> >>
> >>On 9/15/2010 10:57 AM, R.S. wrote:
> >>> Miklos Szigetvari pisze:
>    Hi
> 
>  We would like to categorize the channels as in the Mainframe Concept
>  book
> 
> >
(http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ib
> > m.
> >> zos.znetwork/znetwork_74.htm)
>  CCW channel or Coupling channel or QDIO/OSA.
>  Can I make this from the channel type codes ?
> >>> In fact you just did it.
> >>>
> >>> What do you want to achieve?
> >>> I'm asking, because there are different point of view:
> >>> CHPID type - as in HCD, i.e. CNC, FC, FCV, CTC, etc. A physical
> >>> channel can be defined as one of allowable types. For ESCON you have 4
> >>> choices.
> >>> Channel card type - i.e. FICON Express2, Express4, Express8 - all
> >>> those cards support same set of CHPID types.
> >>> Channel media - related to Channel card type.
> >>> CPC - machine model sometimes decides wht CHPID can be used, i.e. CFR
> >>> cannot be defined on z9, even if the same card do support CFR.
> >>>
> >>> CCW channels:
> >>> Bus&Tag, ESCON, FICON (no-Express, Express, Express2,4,8)
> >>> CHPID: BL, BY, CTC, CNC, CVC, CBY, FC, FCP, FCP
> >>>
> >>> CF link channels:
> >>> ISC(fiber optic 2-3 generations), ICB (copper, several incompatible
> >>> generations, ICB, ICB-3, ICB-4), PSIFB (Infiniband), IC (inter

Re: A most curious result

2010-09-15 Thread Dazzo, Matt 
Yeah, but just think of the money saved by the head reduction. Isn't that 
wonderful.

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
kopplin
Sent: Wednesday, September 15, 2010 11:04 AM
To: IBM-MAIN@bama.ua.edu
Subject: A most curious result

Some years ago, in pursuit of Headcount reduction, a decision was made to 
suppress the 
display of WTORs that weren't recognized by automation (OPS/MVS) as important.  
This
had the desired effect, and headcount reduction proceeded.  In the years since 
then,
the remaining operators have learned to do the displays and check for 
unanswered WTORs.
But this happens on a very intermittent basis.

So, on July 28, a batch job was giving trouble, and one of the operators 
entered:

F R,R,EXIT=   (This will cause MAINVIEW to terminate the address space)

Which promptly generated a WTOR which was not seen because of the rule 
described in
the first paragraph above.  The job was later removed via the MVS FORCE command.

Fast forward from July 28 to September 11 (a date filled with premonitions of 
doom.)

An operator does the appropriate display and notices the WTOR.  Asks the MVS 
oncall
person how to deal with it, and gets a response to reply 'U'.  Oops.

This caused MAINVIEW to issue a couple of messages that it had terminated job 
.

Followed immediately by MVS and JES3 issuing messages that an IMS DBRC address 
space had
just gone away in the ugliest possible manner.

In all the fun and games that follow such an interesting event, it seems never 
to have 
occurred that there might be a correlation between the smoking gun in their 
hand, and
the hole in their foot.

Most curious.

--
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: DFSMS and System Managed Buffering

2010-09-15 Thread Ron Hawkins 
Tobias,

I'm a great fan of RAID-0 datasets (dataset striping) and the benefits of
LSR buffering.

They are two very different things though, and if you would like to
understand the benefit of each technique you may want to measure them
separately.

Data Set striping does two things. It flattens skew and increases
parallelism. The benefit Data set striping may go unnoticed unless you run
some background IO to create contention, or run multiple jobs reading the
same dataset.

For datasets converted from NSR to LSR I usually find that the major benefit
comes from the buffering of the Index Set for a KSDS with three or more
index levels. You may want to create some KSDS with one, two and three
levels and compare your results with and without LSR. If the dataset has the
VSAM defaults then the three level index will probably realize a 50-67%
reduction in IO because of LSR. However if NSR is specified with
BUFNI=INDEX-Set+1 the LSR performance benefit will be much smaller.

In one shop I used ACC-SRS to force BUFNI=8 into the JCL of every KSDS
allocation which cancelled most of the benefit expected from LSR buffering.

A typical symptom to look for is a KSDS where IO count to the Index is three
or more times the IO count to the Data. This is a sure sign of three level
index, or greater, that is reloading the Index Set and a good target for
SMB, BLSR, or some old fashioned Index buffers. It would definitely make for
a good test program for your experiments. It is likely that optimizing this
IO challenge will discount the benefit of dataset striping.

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Tobias Cafiero
> Sent: Wednesday, September 15, 2010 8:17 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] DFSMS and System Managed Buffering
> 
> Ron,
>   I was expecting results similiar to the ones I saw in VSAM Demystified.
> Instead of using Repro, I'll  write something to do my testing. We will be
> using
> Dataset Striping and I am interested in putting them together.
> 
> Tob
> 
> --
> 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

Registers in a SLIP IF dump

2010-09-15 Thread Tony Harminc 
Where do the general register values (reported under "CPU STATUS" in
IPCS) come from when a SLIP IF with ACTION=SVCD takes a dump? I have
had no reason to distrust these values in the past, but now I have
such a dump where some of the values are "impossible" for the PSW
address, while others are believable. A couple appear to have been
ANDed or ORed with one or two bits. In general the impossible values
are not only inconsistent with executing at this PSW address, but are
not consistent with any of the code in this module (for example the
current code base register points to the middle of an instruction
later in the module). And there are no execution errors before or
after the PER interrupt that would be consistent with these bad
register values; everything proceeds quite normally.

Surely this wouldn't be different with ACTION=SYNCSVCD, would it? Even
if with ACTION=SVCD, processing can continue after the PER event and
before the dump is taken, the GR values should have been captured in
the FLIH and saved, no?

The code is in task mode, not AR mode, key 8, enabled for everything,
and the PER range is one MVC instruction, i.e. not an SVC or PC or
anything equally dubious.

IPCS reports that its level matches that of the dumping system, which
is z/OS R10.

Tony H.

--
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: z/OS, TCP/IP, and OSA

2010-09-15 Thread Stan Weyman 
You could try a 2216.  I may have one in my garage holding up some other 
junk .  OSA is really the way to go these days.  In addition to TCPIP 
communications, with the proper OSA card and configuration, you can even use 
then for console support and eliminate those incredibly expensive OS/2 boxes 
IBM dubbed the 2074s.  Very big, very heavy and very useless these days.

Stan Weyman 
Senior Software Engineer
stan.wey...@emc.com
EMC²  (508)249-3966
where information lives
It is wise to keep in mind that neither
success nor failure is ever final...

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Hal Merritt
Sent: Wednesday, September 15, 2010 9:47 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/OS, TCP/IP, and OSA

Technically true, I suppose, but what's the point? OSA's come pretty much as 
standard equipment these days. 
 


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Ward, Mike S
Sent: Tuesday, September 14, 2010 5:22 PM
To: IBM-MAIN@bama.ua.edu
Subject: z/OS, TCP/IP, and OSA

Hello all, I have a question. I was talking with someone that said you
don't need OSA's to run tcpip under z/os and use it to communicate with
the outside world. If that's true then what would be used instead of an
OSA?

 
NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all 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

--
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: z/OS V1.12 differences and z196 (the new mainframe) impacts

2010-09-15 Thread Robert A. Rosenberg 
At 09:46 -0500 on 09/15/2010, Tom Marchant wrote about Re: z/OS V1.12 
differences and z196 (the new mainframe) imp:



On Wed, 15 Sep 2010 08:00:07 -0400, Robert A. Rosenberg wrote:


If the 64-bit program calling the 24/31 bit program wants to insure
the integrity of the high end of the registers, it is ITS
responsibility to save them around the call.


That is incorrect.  As clearly documented in the Assembler Services
Guide,


Unless otherwise defined by the individual interface, the calling
program should expect, upon return, that 
- The low halves (Bits 32-63) of GPRs 2 through 13 are unchanged 
- The high halves (Bits 0-31) of GPRs 2 through 14 are unchanged



Please reread my statement. I am talking about an 64-bit program 
calling a 24/31-bit program (legacy or not) NOT just making a system 
call. The only way to insure that the high end of the registers are 
preserved after the return to the 64-bit program is to restore them 
after the return. Otherwise the 24/31-bit program may use the high 
ends (such as for arithmetic) but not bother to do the preservation 
itself.



 >So long as the called program

wants a old-style Format 1 Save area, the high end is subject to
being altered.


There is no such thing as a format 1 save area.  You are referring
to a standard 72-byte save area.


Yes I mean the standard 72-bute SA. I thought it was documented as a 
Format 1 SA   but did not have a word0 eye-catcher/magic-key.



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


--
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: LE dump - CEE3DMP of 64 bit registers

2010-09-15 Thread zMan 
On Tue, Sep 14, 2010 at 10:23 PM, John McKown  wrote:
> Is there some magic to make LE dump the full 64 bit general registers
> when CALL'ing CEE3DMP from an Enterprise COBOL 3.2 program? Yes, I know
> COBOL doesn't use the high fullword of the regs. Something, somewhere,
> is changing the high word of some regs which is causing DFSORT to abend
> when the internal SORT verb finishes the INPUT PROCEDURE.
>
> Or am I going to need to write my own HLASM subroutine to, once again,
> repair lack of forethought on IBM's part?

One of my people says:
The LE dump summary does not contain the high order bytes of any
registers.  You have to get the SYSUDUMP.
It's not that hard though is it?  Allocate a DD for SYSUDUMP.
Annoying yes.  Difficult no.
-- 
zMan -- "I've got a mainframe and I'm not afraid to use 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: LE dump - CEE3DMP of 64 bit registers

2010-09-15 Thread McKown, John 
> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of zMan
> Sent: Wednesday, September 15, 2010 11:47 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: LE dump - CEE3DMP of 64 bit registers
> 
> On Tue, Sep 14, 2010 at 10:23 PM, John McKown 
>  wrote:
> > Is there some magic to make LE dump the full 64 bit general 
> registers
> > when CALL'ing CEE3DMP from an Enterprise COBOL 3.2 program? 
> Yes, I know
> > COBOL doesn't use the high fullword of the regs. Something, 
> somewhere,
> > is changing the high word of some regs which is causing 
> DFSORT to abend
> > when the internal SORT verb finishes the INPUT PROCEDURE.
> >
> > Or am I going to need to write my own HLASM subroutine to, 
> once again,
> > repair lack of forethought on IBM's part?
> 
> One of my people says:
> The LE dump summary does not contain the high order bytes of any
> registers.  You have to get the SYSUDUMP.
> It's not that hard though is it?  Allocate a DD for SYSUDUMP.
> Annoying yes.  Difficult no.
> -- 
> zMan -- "I've got a mainframe and I'm not afraid to use it"

How would I get a dump and continue processing? I don't see an LE function to 
do that. No matter, I wrote my own HLASM code.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-691-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
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: DFSMS and System Managed Buffering

2010-09-15 Thread Ron Hawkins 
Yifat,

Thanks for that info.

So it was OW51451 that changed the default for REPRO, and it was a long time
ago. I need to get out in the real world more...

For a load on small to medium sized files I still don't think it will make
much of a difference for elapsed time or CPU, unless you have some oddball
CISZ like the one in this APAR example (CISZ=512). All of the IO would be
DFW.

Personally I would consider ignoring the BUFND=2 recommendation in the APAR
and use BLSR with the Deferred Write Option. The elapsed times will be much
closer to the Load results because you do not rewrite the CI every time you
insert a record.

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Yifat Oren
> Sent: Wednesday, September 15, 2010 9:05 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] DFSMS and System Managed Buffering
> 
> Ron,
> 
> The defaults have changed;
> 
> This is not the best pointer, but it's all I could find with a quick
search
> http://www-01.ibm.com/support/docview.wss?uid=isg1OA01898: "With OW51451,
> REPRO uses AMDCIPCA (CI per CA) value for BUFND when SHROPT is not 4."
> 
> Such buffering (BUFND=CI/CA) will make a difference; espcially an elapsed
> time difference (but also CPU).
> 
> Best Regards,
> Yifat
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf
> Of Ron Hawkins
> Sent: יום ד 15 ספטמבר 2010 17:28
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: DFSMS and System Managed Buffering
> 
> Yifat,
> 
> Without any other specification, such as BUFSP at define or BFND on the
> REPRO, IDCAMS without SMB used to default to BUFND of two, and only read
one
> CI at a time.
> 
> Are you saying the default changed, or changed for Extended Format?
> 
> I suggested it would not make huge difference for REPRO because the
default
> CISZ for VSAM is 18K or 26K, and a large BUFND would not make a large
> difference in elapsed time on a small to medium size dataset.
> 
> Ron
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of
> > Yifat Oren
> > Sent: Wednesday, September 15, 2010 4:05 AM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Re: [IBM-MAIN] DFSMS and System Managed Buffering
> >
> > Tobias,
> >
> > The reason you are not seeing the expected savings is that the IDCAMS
> REPRO
> > has already set and used the optimal number of data buffers regardless
> > of the DATACLAS change (so, no change has actually taken place;
> > optimal buffering was used for both before and after runs).
> >
> > You should see the savings when programs that are not taking care of
> > their VSAM buffering start using these data sets.
> >
> > I too think that 1MB is a bit constrictive for direct access LSR
> > (bias=do) buffering.
> >
> > Best Regards,
> > Yifat
> >
> >
> 
> --
> 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: Registers in a SLIP IF dump

2010-09-15 Thread Dave Day 
Tony,
I don't have a dump in front of me to check this for sure, but I believe 
field CVTSDBF points to an area where the contents of the registers at the time 
of dump are formatted.  I know there is a pointer in the CVT to such and area, 
as I had the same problem some time back.  I should have saved my notes, but 
did not.  I just ran thru the CVT fields trying to see which for sure, and that 
one seems to come the closest, as far as the comment to the right of the field 
in the listing for the CVT.  Hope this helps, and sorry I couldn't nail it for 
certain.

--Dave

--
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: Registers in a SLIP IF dump

2010-09-15 Thread Doug Henry 
On Wed, 15 Sep 2010 13:28:19 -0400, Tony Harminc  
wrote:

>Where do the general register values (reported under "CPU STATUS" in
>IPCS) come from when a SLIP IF with ACTION=SVCD takes a dump? 

Hi Tony,
Not answering your actual question but I assume you want the active regs at 
the time of the slip.

>From z/OS V1R11.0 MVS Diagnosis: Tools and Service Aids 
 2.7.11  Reading the SDUMPX 4K SQA buffer  © Copyright IBM Corp. 1988, 
2009 
  The following SVC 
dumps contain 
problem data in an SDUMPX 4K system queue   
area (SQA) buffer:  

An SVC dump requested by a SLIP operator command

Other SVC dumps, when indicated in the explanation of the dump title.   

An SVC dump requested by an SDUMP or SDUMPX macro with a 
BUFFER=YES 
parameter   


To obtain the buffer, use the following IPCS subcommand:

LIST 0 DOMAIN(SDUMPBUFFER) LENGTH(4096) 

Doug

--
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: Registers in a SLIP IF dump

2010-09-15 Thread Jim Mulder 
> Where do the general register values (reported under "CPU STATUS" in
> IPCS) come from when a SLIP IF with ACTION=SVCD takes a dump? I have
> had no reason to distrust these values in the past, but now I have
> such a dump where some of the values are "impossible" for the PSW
> address, while others are believable. A couple appear to have been
> ANDed or ORed with one or two bits. In general the impossible values
> are not only inconsistent with executing at this PSW address, but are
> not consistent with any of the code in this module (for example the
> current code base register points to the middle of an instruction
> later in the module). And there are no execution errors before or
> after the PER interrupt that would be consistent with these bad
> register values; everything proceeds quite normally.
> 
> Surely this wouldn't be different with ACTION=SYNCSVCD, would it? Even
> if with ACTION=SVCD, processing can continue after the PER event and
> before the dump is taken, the GR values should have been captured in
> the FLIH and saved, no?
> 
> The code is in task mode, not AR mode, key 8, enabled for everything,
> and the PER range is one MVC instruction, i.e. not an SVC or PC or
> anything equally dubious.
> 
> IPCS reports that its level matches that of the dumping system, which
> is z/OS R10.

  For a SLIP dump, STATUS CPU REGS  obtains the registers and PSW
from the SLIP section in the dump header record.  These should be
the registers and PSW from the event (in your case, a PER IF event)
which caused the SLIP to match.  These should be the same 
values as those that SLIP stored in the 4k buffer pointed to by
CVTSDBF.

  For speculating about the cause of the "impossible" values,
I would need to see the dump.  If this dump is from a 
z9, z10, or z196 processor, LCCABEA2 in the LCCA of the
CPU on which the PER event occurred may be of interest. 

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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: LE dump - CEE3DMP of 64 bit registers

2010-09-15 Thread Steve Comstock 

On 9/15/2010 10:46 AM, zMan wrote:

On Tue, Sep 14, 2010 at 10:23 PM, John McKown  wrote:

Is there some magic to make LE dump the full 64 bit general registers
when CALL'ing CEE3DMP from an Enterprise COBOL 3.2 program? Yes, I know
COBOL doesn't use the high fullword of the regs. Something, somewhere,
is changing the high word of some regs which is causing DFSORT to abend
when the internal SORT verb finishes the INPUT PROCEDURE.

Or am I going to need to write my own HLASM subroutine to, once again,
repair lack of forethought on IBM's part?


One of my people says:
The LE dump summary does not contain the high order bytes of any
registers.  You have to get the SYSUDUMP.
It's not that hard though is it?  Allocate a DD for SYSUDUMP.
Annoying yes.  Difficult no.


Actually, you also need to ensure you have the right
setting for the TERMTHDACT runtime option. You want
one of these choices:

UADUMP - CEEDUMP + SYSUDUMP after condition handling before clean up
UAONLY - no CEEDUMP; SYSUDUMP as above
UATRACE - trace from CEEDUMP + SYSUDUMP after condition handling before clean up
UAIMM - SYSUDUMP before condition handling

Also note: in z/OS 1.12 LE dumps will provide all 64-bits of
   the GPRs


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

--
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: LE dump - CEE3DMP of 64 bit registers

2010-09-15 Thread Steve Comstock 

On 9/15/2010 10:59 AM, McKown, John wrote:

-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of zMan
Sent: Wednesday, September 15, 2010 11:47 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: LE dump - CEE3DMP of 64 bit registers

On Tue, Sep 14, 2010 at 10:23 PM, John McKown
  wrote:

Is there some magic to make LE dump the full 64 bit general

registers

when CALL'ing CEE3DMP from an Enterprise COBOL 3.2 program?

Yes, I know

COBOL doesn't use the high fullword of the regs. Something,

somewhere,

is changing the high word of some regs which is causing

DFSORT to abend

when the internal SORT verb finishes the INPUT PROCEDURE.

Or am I going to need to write my own HLASM subroutine to,

once again,

repair lack of forethought on IBM's part?


One of my people says:
The LE dump summary does not contain the high order bytes of any
registers.  You have to get the SYSUDUMP.
It's not that hard though is it?  Allocate a DD for SYSUDUMP.
Annoying yes.  Difficult no.
--
zMan -- "I've got a mainframe and I'm not afraid to use it"


How would I get a dump and continue processing? I don't see an
LE function to do that. No matter, I wrote my own HLASM code.


CEE3DMP will create an LE dump and continue running




--
John McKown
Systems Engineer IV
IT


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

--
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: Possible DFSORT problem?

2010-09-15 Thread McKown, John 
This is where I was getting an S0C4-38 in ICEF64A. I think that have found the 
problem. However, I cannot do anything about it due to the fact that it is, I 
believe, in a OEM product which we have a perpetual license for, and so did not 
renew maintenance on it. I.e. we are unsupported. It appears to me that the 
high fullword (bits 0..31) of general registers 2 and 3 are corrupted. I came 
to this conclusion by dumping the registers via an HLASM subroutine just before 
a COBOL READ verb, then immediately after the READ verb. That showed that the 
high words of GPRs 2&3 were changed. I then took the OEM product out of the mix 
and reran the program with no problems and no apparent corruption.

My thanks to IBM's DFSORT people for their help on this!

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-691-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

--
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: LE dump - CEE3DMP of 64 bit registers

2010-09-15 Thread McKown, John 
Yes, I know CEE3DMP does continue after dumping. Now, back to my original 
question. How to get CEE3DMP to dump the 64-bit registers?!? It doesn't matter 
anyway, I wrote a smallish HLASM program to dump them using WTO. I was too lazy 
to OPEN, SNAPX, CLOSE to put the data out to a DD.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-691-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Steve Comstock
> Sent: Wednesday, September 15, 2010 2:04 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: LE dump - CEE3DMP of 64 bit registers
> 
> On 9/15/2010 10:59 AM, McKown, John wrote:
> >> -Original Message-
> >> From: IBM Mainframe Discussion List
> >> [mailto:ibm-m...@bama.ua.edu] On Behalf Of zMan
> >> Sent: Wednesday, September 15, 2010 11:47 AM
> >> To: IBM-MAIN@bama.ua.edu
> >> Subject: Re: LE dump - CEE3DMP of 64 bit registers
> >>
> >> On Tue, Sep 14, 2010 at 10:23 PM, John McKown
> >>   wrote:
> >>> Is there some magic to make LE dump the full 64 bit general
> >> registers
> >>> when CALL'ing CEE3DMP from an Enterprise COBOL 3.2 program?
> >> Yes, I know
> >>> COBOL doesn't use the high fullword of the regs. Something,
> >> somewhere,
> >>> is changing the high word of some regs which is causing
> >> DFSORT to abend
> >>> when the internal SORT verb finishes the INPUT PROCEDURE.
> >>>
> >>> Or am I going to need to write my own HLASM subroutine to,
> >> once again,
> >>> repair lack of forethought on IBM's part?
> >>
> >> One of my people says:
> >> The LE dump summary does not contain the high order bytes of any
> >> registers.  You have to get the SYSUDUMP.
> >> It's not that hard though is it?  Allocate a DD for SYSUDUMP.
> >> Annoying yes.  Difficult no.
> >> --
> >> zMan -- "I've got a mainframe and I'm not afraid to use it"
> >
> > How would I get a dump and continue processing? I don't see an
> > LE function to do that. No matter, I wrote my own HLASM code.
> 
> CEE3DMP will create an LE dump and continue running
> 
> 
> >
> > --
> > John McKown
> > Systems Engineer IV
> > IT
> 
> -- 
> 
> Kind regards,
> 
> -Steve Comstock
> The Trainer's Friend, Inc.
> 
> 303-393-8716
> http://www.trainersfriend.com
> 
> * To get a good Return on your Investment, first make an investment!
>+ Training your people is an excellent investment
> 
> --
> 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: z/OS, TCP/IP, and OSA

2010-09-15 Thread R.S. 

W dniu 2010-09-15 19:35, Stan Weyman pisze:


 You could try a 2216.  I may have one in my garage holding up some other 
junk.  OSA is really the way to go these days.
Agreed. While OSA alternatives are still available none of them is 
reasonable.



In addition to TCPIP communications, with the proper OSA card and 
configuration, you can even use then for console support and eliminate those 
incredibly expensive OS/2 boxes IBM dubbed the 2074s.  Very big, very heavy and 
very useless these days.
I dare to disagree. 2074 can be small, rack-mounted, IT IS very cheap, 
much cheaper than OSA port. Last but not least - single 2074 supports 
many CPCs, while OSA ICC supports only ons (his own) CPC.
Of course if one wants to pay bucks for HW support then things may look 
quite differently.


--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci 
wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 
2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec 
podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym 
BRE Banku SA bd w caoci opacone.

--
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: z/OS sms dasd selection?

2010-09-15 Thread Schwarz, Barry A 
One has to wonder how you are managing to hose your VTOC index datasets often 
enough for you to raise the issue here.

On the other had, since indexing is a requirement for an SMS volume, how is it 
that SMS is even considering an index-disabled volume for a new allocation?

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Mike Schwab
Sent: Tuesday, September 14, 2010 3:17 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/OS sms dasd selection?

In our shop, we occasionally have our VTOC Indexes get disabled.
Unfortunately, these volumes then fill up with datasets and cause out
of space abends, even though there is plenty of space on other
volumes.  I suspect that Storage Class performance requirement columns
3, 4, 5, 6, 7, 13, 15 are causing low performance request classes to
get allocated to these volumes instead of volumes with working
indexes.  Setting the volume to Disabled, New then rebuilding the
index does work, but I am trying to avoid the volume filling up in the
meantime.

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

Initiators

2010-09-15 Thread gsg 
Is there any reason why you shouldn't have alot of initiators defined, but have 
alot of them drained.  Is there any performance considerations?

Thanks

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

2010-09-15 Thread McKown, John 
> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of gsg
> Sent: Wednesday, September 15, 2010 2:56 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Initiators
> 
> Is there any reason why you shouldn't have alot of initiators 
> defined, but have 
> alot of them drained.  Is there any performance considerations?
> 
> Thanks

So long as the shop is disciplined, then having defined, but drained, 
initiators are 0 cost. We are not disciplined. We had to remove initiators 
because we couldn't stop the NOC from "firing up another one for this really 
hot job!".

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-691-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
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: z/OS V1.12 differences and z196 (the new mainframe) impacts

2010-09-15 Thread Tom Marchant 
On Wed, 15 Sep 2010 13:10:37 -0400, Robert A. Rosenberg wrote:

>At 09:46 -0500 on 09/15/2010, Tom Marchant wrote about Re: z/OS V1.12
>differences and z196 (the new mainframe) imp:
>
>>On Wed, 15 Sep 2010 08:00:07 -0400, Robert A. Rosenberg wrote:
>>>
>>>If the 64-bit program calling the 24/31 bit program wants to insure
>>>the integrity of the high end of the registers, it is ITS
>>>responsibility to save them around the call.
>>
>>That is incorrect.  As clearly documented in the Assembler Services
>>Guide,
>>
>>
>>Unless otherwise defined by the individual interface, the calling
>>program should expect, upon return, that 
>>- The low halves (Bits 32-63) of GPRs 2 through 13 are unchanged 
>>- The high halves (Bits 0-31) of GPRs 2 through 14 are unchanged
>>
>
>Please reread my statement. I am talking about an 64-bit program
>calling a 24/31-bit program (legacy or not) NOT just making a system
>call. 

Please read the Assembler Services Guide.  The Linkage Conventions 
chapter is _not_ to describe the interface for making a system call. 
It describes the linkage conventions for normal programs.  The first 
paragraph in that chapter reads:


Linkage conventions are the register and save area conventions a program
must follow when it receives control from another program or when it calls
another program. It is important that all programs follow the linkage
conventions described here to ensure that the programs can successfully pass
control from one to the other while preserving register contents and
parameter data that they need to run successfully.


>The only way to insure that the high end of the registers are
>preserved after the return to the 64-bit program is to restore them
>after the return. Otherwise the 24/31-bit program may use the high
>ends (such as for arithmetic) but not bother to do the preservation
>itself.

This is simply incorrect.

The linkage conventions describe what each program must do to 
restore the caller's registers when returning.  If you are calling a 
program that follows the linkage conventions describes in the 
Assembler Services Guide, you are assured that registers are saved 
as I quoted above.  If you call a program that does not follow the 
linkage conventions, all bets are off.

The linkage conventions do _not_ say that an AMODE(64) program 
must restore bits 0-31.  It says that bits 0-63 of registers 2 through 
13 and bits 0-31 of register 14 are unchanged.  A program, regardless 
of AMODE, may not legitimately use the high halves of registers 
(except for 15, 0 and 1) without preserving them.

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

2010-09-15 Thread Thompson, Steve 
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of gsg
Sent: Wednesday, September 15, 2010 2:56 PM
To: IBM-MAIN@bama.ua.edu
Subject: Initiators

Is there any reason why you shouldn't have alot of initiators defined,
but have 
alot of them drained.  Is there any performance considerations?

Thanks


Each initiator, drained or running, takes up room in the SQA for ASCBs
and such. Other than that, there is some storage taken within JES2 (or
JES3).

That's about the only real overhead I can think of for excess, but
drained, INITS.

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

LE dumps and 64-bit registers

2010-09-15 Thread William M Klein 
This is just a follow on to another thread.  

 

For information on LE dumps and 64-bit registers.  See:

 
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CEEA11B0/CHANGES.
1 

which documents the enhancement,

  "Language Environment can now display the contents of high registers, if
known, in dumps and in VERBX LEDATA output."

   

and in particular,

 
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea11b0/1.3.2.4.
1 



which states (with revision bars - indicating this is new)

 

"This information shows the current values at the time the condition was
raised. The high halves of the general registers are dumped, in case they
are useful for debugging some applications."

 

 * * *

 

Of course, if you aren't *at* LE 1.12 yet (and how many are?), then this
isn't available yet.  

 

However, I did think it worth documenting this, for anyone who might think
that IBM wasn't dealing with this "issue".


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

2010-09-15 Thread O'Brien, David W. (NIH/CIT) [C] 
Wouldn't you be better served by putting the initiators under WLM control? Then 
you would have as many initiators as you need without over committing CPU.
 
Thank You,
Dave O'Brien
NIH Contractor

From: McKown, John [john.mck...@healthmarkets.com]
Sent: Wednesday, September 15, 2010 3:59 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Initiators

> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of gsg
> Sent: Wednesday, September 15, 2010 2:56 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Initiators
>
> Is there any reason why you shouldn't have alot of initiators
> defined, but have
> alot of them drained.  Is there any performance considerations?
>
> Thanks

So long as the shop is disciplined, then having defined, but drained, 
initiators are 0 cost. We are not disciplined. We had to remove initiators 
because we couldn't stop the NOC from "firing up another one for this really 
hot job!".

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-691-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM



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

2010-09-15 Thread Burrell, C. Todd (CDC/OCOO/ITSO) (CTR) 
Why not just put them under WLM control, and then the system controls
how many you use (up to your set limits)?  This is much easier than
manually stopping and starting initiators, and it takes the control away
from operators who usually do not understand the impact starting too
many initiators can have on system performance. 

C. Todd Burrell 
PMP, MCSE 2003:Security
Security+, Network+
ITIL V3 Foundations
CSC Lead z/OS Systems Programmer 
ITSO 
(404) 723-2017 (Cell) 



-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of gsg
Sent: Wednesday, September 15, 2010 3:56 PM
To: IBM-MAIN@bama.ua.edu
Subject: Initiators

Is there any reason why you shouldn't have alot of initiators defined,
but have 
alot of them drained.  Is there any performance considerations?

Thanks

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

2010-09-15 Thread Tom Marchant 
On Wed, 15 Sep 2010 16:06:55 -0400, Thompson, Steve wrote:

>Each initiator, drained or running, takes up room in the SQA for ASCBs
>and such.

An address space is created when the initiator is started.  When the 
initiator is drained the address space ends.  There is no ASCB for a 
drained initiator.

I agree with Dave O'Brien.  WLM managed initiators are a good thing 
as long as they work for you.

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

2010-09-15 Thread gsg 
Thanks everyone for your replies.  We haven't started using WLM YET, but I'll 
look into it.

Thanks again.

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

2010-09-15 Thread Thompson, Steve 
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Tom Marchant
Sent: Wednesday, September 15, 2010 3:42 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Initiators

On Wed, 15 Sep 2010 16:06:55 -0400, Thompson, Steve wrote:

>Each initiator, drained or running, takes up room in the SQA for ASCBs
>and such.

An address space is created when the initiator is started.  When the 
initiator is drained the address space ends.  There is no ASCB for a 
drained initiator.



And where does the ASCB go? It isn't pageable now is it?

I thought all of these had to be configured in IEASYSxx. And that is
even if it is WLM controlled.

" MAXUSER=nn 

This parameter specifies a value that, under most conditions, the system
uses to limit the number of jobs and started tasks that can run
concurrently during a given IPL. The number includes time sharing jobs,
batch jobs, started system tasks, the master scheduler, JES2 or JES3.
MAXUSER entries can also include ASIDs that have been marked
non-reusable if their total number exceeds the RSVNONR value. This
parameter is also used to allocate console control block areas in CSA
that contain run-time job description data."

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: Where is APF documented?

2010-09-15 Thread Edward Jaffe 

 On 9/9/2010 4:35 PM, Chris Craddock wrote:

yeah I know, I just didn't feel like going off on one of my normal rants
about integrity exposures. It seems like nobody listens anyway.


Some of us do... :-)

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

PoPs

2010-09-15 Thread Rick Fochtman 
Is it my imagination or have a number of B2xx opcodes been deleted from 
the latest PoPs instruction tables?


I use those tables to keep my own personnal disassembler up-to-date.

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: Where is APF documented?

2010-09-15 Thread Chuck Arney 
>  On 9/9/2010 4:35 PM, Chris Craddock wrote:
>> yeah I know, I just didn't feel like going off on one of my normal
rants
>> about integrity exposures. It seems like nobody listens anyway.

and on 9/15/2010 Ed Jaffe wrote:
> Some of us do... :-)

Yep.  When Chris speaks I listen.  Usually it is entertaining and
sometimes even educational. 

Chuck Arney
illustro Systems International, LLC
http://www.illustro.com
Internet-enable your applications with z/Ware V2
Voice: 214-800-8900 X#5562
--
This e-mail is private and may be confidential and is for the intended
recipient only. If misdirected, please notify us by telephone and
confirm that it has been deleted from your system and any copies
destroyed. If you are not the intended recipient you are strictly
prohibited from using, printing, copying, distributing or disseminating
this e-mail or any information contained in it.  
  
We use reasonable measures to virus scan all E-mails leaving illustro
but no warranty is given that this E-mail and any attachments are virus
free. You should ensure you have adequate measures in place for your own
virus checking.

--
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: Registers in a SLIP IF dump

2010-09-15 Thread Tony Harminc 
On 15 September 2010 14:51, Jim Mulder  wrote:

>  For a SLIP dump, STATUS CPU REGS  obtains the registers and PSW
> from the SLIP section in the dump header record.

Well...

> These should be
> the registers and PSW from the event (in your case, a PER IF event)
> which caused the SLIP to match.
> These should be the same values as those that SLIP stored in the 4k buffer
pointed to by CVTSDBF.

CVTSDBF points to an area that appears to be the same as that displayed by
the LIST 0 DOMAIN(SDUMPBUFFER) LENGTH(4096) command that Doug Henry
suggested (for which thanks!).

The registers in this area are both "non-impossible" and consistent with
those saved just before the PER event.

Essentially the code looks like this:

STM   R0,R15,SAVEX

CLI   something
BETARGET

B faraway
TARGET  MVC   <== PER IF is set on this instruction only
MVC   <== reported PSW in the dump points here

Some of the reported registers that were not changed in the code between the
STM and the PER'd MVC are different both from those found in SAVEX, and from
"common sense" values, including the code base register used by the BE to
reach the MVC.

The registers displayed by the STATUS CPU REGS command (the command line
equivalent to IPCS 2.2, I assume) are the bogus ones.

> For speculating about the cause of the "impossible" values, I would need
to see the dump.

I''ve been doing this for enough decades to have encountered a lot of
"impossible" things. My first assumption is always that my code is wrong,
but here the question was just about where IPCS (and the SVC DUMP process
for SLIP IF) gets the GR values it reports. We seem to have ruled out the
values in the dump, since good-looking values are available in the SDUMP
buffer. So what is STATUS CPU REGS reporting? Not the values from the SDUMP
buffer, not the TCB GR SA values, and not those in any of the RB SAs. The
description of the command in the IPCS book doesn't appear to say. I looked
at the dump header record directly (i.e. not via IPCS), and there is a SLIP
subsection, with the field PRDSLGPR containing registers that match those in
the SDUMP Buffer, but not those displayed by STATUS CPU REGS.

Ah - even stranger... The bogus R1 value is found (by IPCS brute force
search) in just a couple of places in storage in the dump. One is in an SCVA
for a different SLIP trap than the one that triggered. This different trap
was inactive at the time, but was a similar IF trap for the same job, but a
different load module. The SCVA for the one that did trigger has the good
regs. The only other place the bogus R1 value occurs in storage in this dump
is in what appears to be a dump header record for a previous dump.

Is IPCS perhaps running the SCE/SCVA chain and getting confused about what
triggered? That seems like an odd thing for it to do, given that the correct
info is in the dump header record.

> If this dump is from a z9, z10, or z196 processor, LCCABEA2 in the LCCA of
the
> CPU on which the PER event occurred may be of interest.

LCCABEA2 points to the BE in the snippet above. But I don't think this code
is the problem.

Thanks.

Tony H.

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

2010-09-15 Thread Farley, Peter x23353 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Rick Fochtman
> Sent: Wednesday, September 15, 2010 5:57 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: PoPs
> 
> Is it my imagination or have a number of B2xx opcodes been deleted from
> the latest PoPs instruction tables?

I think it is just your imagination.  B2B8 (SRNMP, SET BFP ROUNDING MODE) has 
been added in the latest version, but none have been deleted AFAICS.  I 
compared Appendix B, the third table "Instructions Arranged by Operation Code" 
in the latest (-8) and prior (-7) versions of the manual.  All the B2xx 
instructions from the prior version are there plus the new one.

Unless you mean as compared to an earlier version than (-7)?

Peter
--
This message and any attachments are intended only for the use of the addressee 
and
may contain information that is privileged and confidential. If the reader of 
the 
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.


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

2010-09-15 Thread Ted MacNEIL 
>Wouldn't you be better served by putting the initiators under WLM control? 
>Then you would have as many initiators as you need without over committing CPU.
 
1: WLM managed inits are not a panacea.
2: Undisciplined operators can still wreak havoc.

-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

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

2010-09-15 Thread Ted MacNEIL 
>Why not just put them under WLM control, and then the system controls
how many you use (up to your set limits)?  This is much easier than manually 
stopping and starting initiators, and it takes the control away
from operators who usually do not understand the impact starting too many 
initiators can have on system performance. 

It does not take control away.
It just moves the control.
Operators can still start extra jobs.

And, WLM controlled inits don't help in all situations.


-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

--
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: LE dump - CEE3DMP of 64 bit registers

2010-09-15 Thread John McKown 
On Wed, 2010-09-15 at 14:21 -0500, McKown, John wrote:
> Yes, I know CEE3DMP does continue after dumping. Now, back to my original 
> question. How to get CEE3DMP to dump the 64-bit registers?!? It doesn't 
> matter anyway, I wrote a smallish HLASM program to dump them using WTO. I was 
> too lazy to OPEN, SNAPX, CLOSE to put the data out to a DD.
> 
> --
> John McKown 

I got the answer off-line. Upgrade to z/OS 1.12. CEE3DMP in that release
does what I need. Not likely at this shop.

--
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: Registers in a SLIP IF dump

2010-09-15 Thread Jim Mulder 
Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

IBM Mainframe Discussion List  wrote on 09/15/2010 
06:44:22 PM:

> >  For a SLIP dump, STATUS CPU REGS  obtains the registers and PSW
> > from the SLIP section in the dump header record.
> 
> Well...
> 
> > These should be
> > the registers and PSW from the event (in your case, a PER IF event)
> > which caused the SLIP to match.
> > These should be the same values as those that SLIP stored in the 4k 
buffer
> pointed to by CVTSDBF.
> 
> CVTSDBF points to an area that appears to be the same as that displayed 
by
> the LIST 0 DOMAIN(SDUMPBUFFER) LENGTH(4096) command that Doug Henry
> suggested (for which thanks!).
> 
> The registers in this area are both "non-impossible" and consistent with
> those saved just before the PER event.
> 
> Essentially the code looks like this:
> 
> STM   R0,R15,SAVEX
> 
> CLI   something
> BETARGET
> 
> B faraway
> TARGET  MVC   <== PER IF is set on this instruction only
> MVC   <== reported PSW in the dump points here
> 
> Some of the reported registers that were not changed in the code between 
the
> STM and the PER'd MVC are different both from those found in SAVEX, and 
from
> "common sense" values, including the code base register used by the BE 
to
> reach the MVC.
> 
> The registers displayed by the STATUS CPU REGS command (the command line
> equivalent to IPCS 2.2, I assume) are the bogus ones.
> 
> > For speculating about the cause of the "impossible" values, I would 
need
> to see the dump.
> 
> I''ve been doing this for enough decades to have encountered a lot of
> "impossible" things. My first assumption is always that my code is 
wrong,
> but here the question was just about where IPCS (and the SVC DUMP 
process
> for SLIP IF) gets the GR values it reports. We seem to have ruled out 
the
> values in the dump, since good-looking values are available in the SDUMP
> buffer. So what is STATUS CPU REGS reporting? Not the values from the 
SDUMP
> buffer, not the TCB GR SA values, and not those in any of the RB SAs. 
The
> description of the command in the IPCS book doesn't appear to say. I 
looked
> at the dump header record directly (i.e. not via IPCS), and there is a 
SLIP
> subsection, with the field PRDSLGPR containing registers that match 
those in
> the SDUMP Buffer, but not those displayed by STATUS CPU REGS.
> 
> Ah - even stranger... The bogus R1 value is found (by IPCS brute force
> search) in just a couple of places in storage in the dump. One is in an 
SCVA
> for a different SLIP trap than the one that triggered. This different 
trap
> was inactive at the time, but was a similar IF trap for the same job, 
but a
> different load module. The SCVA for the one that did trigger has the 
good
> regs. The only other place the bogus R1 value occurs in storage in this 
dump
> is in what appears to be a dump header record for a previous dump.
> 
> Is IPCS perhaps running the SCE/SCVA chain and getting confused about 
what
> triggered? That seems like an odd thing for it to do, given that the 
correct
> info is in the dump header record.

 STATUS CPU REGS is doing a CBF REGGEN  to format the GPRs.  So you should
see the same thing as if you do the CBF REGGEN command yourself.

 REGGEN should be defined in your BLSCECT member as

DATA STRUCTURE(REGGEN) FIND(BLSSREGG) FORMAT(BLSQREG,HBB7703) + 
ENVIRONMENT(ALL)/* GPRs  @H3C*/

 The FIND routine (BLSSREGG), for a SLIP dump, uses the registers
in the SLIP section of the header record.  This processing knows 
nothing about SCVAs.

  And when I try this, using z/OS 1.10 IPCS, it seems to work as I have
described, and the registers displayed by STATUS CPU REGS, CBF REGGEN, 
and those in the 4k buffer, all seem to match.

  So you may want to open a PMR and send in your dump,
and also provide the output you get from

STATUS CPU REGS
CBF REGGEN
LIST 0. L(4160)  HEADER
LIST 0 DOMAIN(SDUMPBUFFER) LENGTH(4096)

 
 

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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Initiators

2010-09-15 Thread Norman Hollander on DesertWiz 
While I do recommend WLM-inits for many types of work, I don't recommend it
for all
types.  While you can use JES commands to limit the max number of inits by
Jobclass,
WLM-inits work well for similar types of workloads.  You can certainly have
multiple Service
Classes defined for WLM-inits, but you may know specifics about your
workloads that WLM
does not.  Example, if you have some DB2 batch running, and it optimally
uses 10 inits, WLM could
double it based on the CURRENT state of the system(s).  Just because the PI
is acceptable, may not
mean your DB2 databases can handle 20 or 50 parallel jobs.  Also jobs
dependent on real tape mounts,
or even lengthy HSM recalls, can skew how well WLM-inits work.  So, be sure
you know your workloads,
use both types of inits as appropriate.

zNorman

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Ted MacNEIL
Sent: Wednesday, September 15, 2010 Wednesday 4:01 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Initiators

>Why not just put them under WLM control, and then the system controls
how many you use (up to your set limits)?  This is much easier than manually
stopping and starting initiators, and it takes the control away from
operators who usually do not understand the impact starting too many
initiators can have on system performance. 

It does not take control away.
It just moves the control.
Operators can still start extra jobs.

And, WLM controlled inits don't help in all situations.


-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

--
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: z/OS sms dasd selection?

2010-09-15 Thread Mike Schwab 
We have a customer that uses the same DSNs on two different systems in
the same sysplex, in different catalogs on different volumes.  So
their DSNs are not ENQed across the sysplex causing problems on the
test system that shares volumes with another system.

On Wed, Sep 15, 2010 at 2:28 PM, Schwarz, Barry A
 wrote:
> One has to wonder how you are managing to hose your VTOC index datasets often 
> enough for you to raise the issue here.
>
> On the other had, since indexing is a requirement for an SMS volume, how is 
> it that SMS is even considering an index-disabled volume for a new allocation?
>

-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
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: DFSMS and System Managed Buffering

2010-09-15 Thread Pearce, Colin (GTS Pac Rim) 
Hi Tobias,

Have you tried coding the ACCBIAS option on the DD that points to the output 
file.  Whether you specify System or SO, VSAM will use the Create Optimization 
process (only on Repros).  If you also include MSG=SMBBIAS you will see the 
IEC161I 001(CO) -...  in the Job Log

Then you will know it's using CO processing.  If it is then you have the best 
that is available for Repro processing with Extended File Formats and SMB 
processing.

Colin Pearce


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Yifat Oren
Sent: Wednesday, September 15, 2010 7:05 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: DFSMS and System Managed Buffering

Tobias,

The reason you are not seeing the expected savings is that the IDCAMS REPRO has 
already set and used the optimal number of data buffers regardless of the 
DATACLAS change (so, no change has actually taken place; optimal buffering was 
used for both before and after runs). 

You should see the savings when programs that are not taking care of their VSAM 
buffering start using these data sets.

I too think that 1MB is a bit constrictive for direct access LSR (bias=do) 
buffering.

Best Regards,
Yifat
 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Tobias Cafiero
Sent: יום ג 14 ספטמבר 2010 18:44
To: IBM-MAIN@bama.ua.edu
Subject: DFSMS and System Managed Buffering

Hello, 
I'm testing the SMB option in the DFSMS DATACLS Constructs, but don't yet 
see a performance boost as promised. At this point I'm using just a 
del/define,repro and pointing to the SMB DATACLS. The DATACLS is extended and 
contains the following values:

Record Access Bias  . . . . : SYSTEM
System Managed Buffer  . . . : 1M 

The STORCLS is our standard non-striped type. Has anyone implemented SMB on 
their system.

Thanks in Advance
Tobias Cafiero  

--
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: z/OS, TCP/IP, and OSA

2010-09-15 Thread Pearce, Colin (GTS Pac Rim) 
2216s were used before, but as stated OSA now comes pretty much standard

Colin Pearce 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Hal Merritt
Sent: Wednesday, September 15, 2010 9:47 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/OS, TCP/IP, and OSA

Technically true, I suppose, but what's the point? OSA's come pretty
much as standard equipment these days. 
 


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ward, Mike S
Sent: Tuesday, September 14, 2010 5:22 PM
To: IBM-MAIN@bama.ua.edu
Subject: z/OS, TCP/IP, and OSA

Hello all, I have a question. I was talking with someone that said you
don't need OSA's to run tcpip under z/os and use it to communicate with
the outside world. If that's true then what would be used instead of an
OSA?

 
NOTICE: This electronic mail message and any files transmitted with it
are intended exclusively for the individual or entity to which it is
addressed. The message, together with any attachment, may contain
confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or
distribution is strictly prohibited. If you have received this message
in error, please immediately advise the sender by reply email and delete
all 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

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