Re: CPU usage for paging

[Ted MacNEIL]

>If it's WebSphere Application Server on z/OS, and you can get up (at least for 
>an LPAR) z/OS 1.6 or
>higher and WAS 5.1 or higher, then you can
probably get a whole lot of CPU back with a zAAP on a z9 BC model.

The OP was asking for advice on how to determine the CPU requirement for paging.
NOT, a sales pitch, which is ALL you seem to do!

When in doubt.
PANIC!!

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

Re: CPU usage for paging

[Timothy Sipples]

Craig Dudley writes:
>I am looking for the RMF report(s) where I can find out
>how much CPU time my system (2066-0A2 w/8 GB) to perform
>paging. I am trying to determine how much CPU I will "get
>back" if we buy more memory. WAS on z is involved ;>)

If it's WebSphere Application Server on z/OS, and you can get up (at least
for an LPAR) z/OS 1.6 or higher and WAS 5.1 or higher, then you can
probably get a whole lot of CPU back with a zAAP on a z9 BC model.  Would
recommend crunching those numbers, too.

For reference, a z800-0A2 is 44 MSUs.  A z9 BC Model L04 is roughly the
same capacity -- depends on your workload, of course -- and only 36 MSUs.
Add a zAAP and you might not need something as large as the L04.  If you do
need more memory then that costs a bit less on the z9.

Another benefit is more precise capacity sizing.  You can look at this
backwards and forwards.  If the z800-0A2 becomes too small as you grow,
then the next step up is a -002.  But your MSUs increase to a whopping 60.
On the other hand, from a z9 BC L04 you can move to a U01 (38 MSUs) or a
P02 (41 MSUs) -- just a smidgen more capacity and not that giant leap.
This idea also works if your -0A2 is a little too big right now (because
the -001 was too small or otherwise not suitable).

Please ship your z800 to me.  I'd like to put it in my home data center,
OK?  I'm only half joking.

- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Specializing in Software Architectures Related to System z
Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
E-Mail: [EMAIL PROTECTED]
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Source maintenance was Re: SEQUENCE NUMBERS

[Rob Weiss]

Can you say IEBUPDTE? and Yes, XEDIT had it all over TSO's EDIT command.
But go back before XEDIT and it was not that nice.  I've said it before:
Maybe I've been doing this too many years.  (Can you say Autocoder?)

Rob Weiss
z/SWITA and z/Series I/T Security and Privacy Consultant
IBM Software Group Sales

IBM Mainframe Discussion List  wrote on 08/02/2006
10:44:11 PM:

> Shmuel Metz , Seymour J. wrote:
> >
> >> cms had "update" command from mid-60s ... which applied an update
> >> control file to source,
> >
> > I'm not sure when it came along, but by VM/SE there was a somewhat
> > more sophisticated UPDATE facility[1] with aux files, control files
> > and update files. I'd love to see a similar facility integrated with
> > ISPF.
> >
> > [1] Not only could the XEDIT editor process them, but it could
> > generate update files to reproduce the effects of an edit
> > session. That's one of the CMS facilities I miss the most.
> >
> CDC 6000 batch source maintenance tools (UPDATE?) even in the late
> 1960's had much more elegance than IBM counterparts.  User supplied
> source statements for the Assembler were constrained to 80-byte card
> images (72 columns + sequence), but the assembler actually supported 90
> byte input lines, which allowed library maintenance tools to introduce a
> much longer sequence identification which included a modification name
> (analogous to a SYSMOD ID) and a sequence number within that
> modification.  I believe the sequence numbers were generated
> automatically as part of the initial storing into the source library or
> updating of the source member, and then could be used afterwards to
> uniquely refer to a specific statement for future updates.   It was
> always clear which named modification introduced a statement without
> having to resort to manually inserted and possibly incorrect comments.
> Statements could be replaced or deleted, but the original statement was
> still retained in a disabled state and could be resurrected at a later
> time by another modification, or at any time you could choose to undo
> modifications and revert to an early source version.  I can still
> remember my disappointment on discovering the lack of comparable
> built-in facilities on MVS in the mid 1970's.
>
>
> --
> Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED]
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: compress a proclib

[Bruce Hewson]

Actually, because JES2 normally does not have a ENQueue on its PROCLIBS, 
you should be able to compress it with DISP=OLD. That will stop any I/O 
errors for JCLLIBs.

Regards
Bruce Hewson

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

Heads Up: OA17104 if you have zIIP support installed

[Brian Peterson]

IF 

you have JBB77S2 (z/OS 1.6) or JBB772S (z/OS 1.7) zIIP Web Deliverable
installed,

AND

if you have crypto, 

THEN

you WILL want the fix for OA17104.

Without OA17104's fix, when you shut down your ICSF started task, apparently
z/OS dispatching queue damage occurs resulting in a spin loop.

This APAR has yet to hit the ZOSV1R7 BCPZIIP PSP Bucket.

Brian

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

Re: Source maintenance was Re: SEQUENCE NUMBERS

[Joel C. Ewing]

Shmuel Metz , Seymour J. wrote:

In <[EMAIL PROTECTED]>, on 07/31/2006
   at 09:40 AM, Anne & Lynn Wheeler <[EMAIL PROTECTED]> said:


cms had "update" command from mid-60s ... which applied an update
control file to source,


I'm not sure when it came along, but by VM/SE there was a somewhat
more sophisticated UPDATE facility[1] with aux files, control files
and update files. I'd love to see a similar facility integrated with
ISPF.

[1] Not only could the XEDIT editor process them, but it could
generate update files to reproduce the effects of an edit
session. That's one of the CMS facilities I miss the most.
 


CDC 6000 batch source maintenance tools (UPDATE?) even in the late 
1960's had much more elegance than IBM counterparts.  User supplied 
source statements for the Assembler were constrained to 80-byte card 
images (72 columns + sequence), but the assembler actually supported 90 
byte input lines, which allowed library maintenance tools to introduce a 
much longer sequence identification which included a modification name 
(analogous to a SYSMOD ID) and a sequence number within that 
modification.  I believe the sequence numbers were generated 
automatically as part of the initial storing into the source library or 
updating of the source member, and then could be used afterwards to 
uniquely refer to a specific statement for future updates.   It was 
always clear which named modification introduced a statement without 
having to resort to manually inserted and possibly incorrect comments. 
Statements could be replaced or deleted, but the original statement was 
still retained in a disabled state and could be resurrected at a later 
time by another modification, or at any time you could choose to undo 
modifications and revert to an early source version.  I can still 
remember my disappointment on discovering the lack of comparable 
built-in facilities on MVS in the mid 1970's.



--
Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED]

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

Re: Test tools, was: Strobe equivalents

[Timothy Sipples]

I forgot to mention some others:

* IBM Application Workload Modeler
http://www.ibm.com/software/network/awm/index.html

If I mentioned DB2 Test Database Generators (for the DB2 shops) I should
also mention this one (for VSAM et. al.):

* IBM File Export for z/OS
http://www.ibm.com/software/awdtools/fileexport/index.html

For MQ-related testing specifically there are some SupportPacs available at
no additional charge that I'd look at first:

* Testing SupportPacs for MQ (Various)
http://www.ibm.com/support/docview.wss?uid=swg27007197

I can't even begin to describe the Web-related products (e.g. Rational
Performance Tester for z/OS, one of my favorites).  Like I said, there are
undoubtedly many others out there, and I encourage comparison shopping.
There is no shortage of testing products for mainframes. :-)

- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Specializing in Software Architectures Related to System z
Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
E-Mail: [EMAIL PROTECTED]
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Data set ENQueues and DEQueues in Jobs

[Robert A. Rosenberg]

At 12:22 -0400 on 08/01/2006, Wayne Driscoll wrote about Re: Data set 
ENQueues and DEQueues in Jobs:



I could see how a downgrade would be useful.  For instance: I have a
resource shared.  Now I need to update the resource, so I perform an
S->E.  Now, I want to allow others to see the update, but I don't want
to allow an exclusive user to lock me out of the resource, so a E->S
change would allow this to happen.


Even more importantly, as I've noted in prior messages in this 
thread, the capability to do a E->S downgrade would fix the current 
"Design Flaw" in the Initiator where if you follow a Job Step that 
has DISP=OLD/MOD for a Dataset with DISP=SHR Job Steps, these 
subsequent Job Steps keep the exclusive ENQ until the Job is over (or 
there are no more steps using the dataset). Support for E->S 
downgrade would allow other jobs to take off once the last 
DISP=OLD/MOD step is done and the first DISP=SHR step starts.


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

WRQ Reflections IBM Scripts (VBA)

[David Speake]

I can not find a LISTSERV or anything useful(like the Dino Ring) on this
subject. Can anyone point me to such or .  

More than you probably want to know on my current project.

We have a problem tracking system under CICS.
Mainframe problems usually involve a JOB name and or TSO USERID.
I have a script that, when I hit a hot key combo (CTRL-J) it:
  1) Checks for selected text and if found copies to clipboard,
  2) If not searches the screen for a couple of constants (JOBNAME/USERID)
  and copies susequent data field to clipboard - quit if not found,
  3) Checks to see if there is a Session up with the Name (Title Bar) TSO, 
 if not quit,  
  4) If already in ISPF it tries to see if SDSF is already in a screen (SWAP
  
 LIST) and a screen search. if not tries to SPLIT NEW  and ST.
Works pretty well - not bullet resistant yet but as things come up I fix. 
I would like to add 

  3b) Start TSO Reflection Session... log on (Forms for LPAR/USERID/PASWORD)
  etc. 
This ALMOST works but has an irritating glitch. The new Session Window comes
up but the FORMS are BEHIND it. They seem attached to the CICS Session
Window. If I can cure this I might even think about sharing with my
co-workers in the support area.

Surely some of you are in shops doing this kind of thing. 

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

Re: Data set ENQueues and DEQueues in Jobs

[Paul Gilmartin]

In a recent note, Edward Jaffe said:

> Date: Wed, 2 Aug 2006 12:58:12 -0700
> Reply-To: IBM Mainframe Discussion List 
> Sender:   IBM Mainframe Discussion List 
> From: Edward Jaffe <[EMAIL PROTECTED]>
> Organization: Phoenix Software International, Inc.
> Subject:  Re: Data set ENQueues and DEQueues in Jobs
> In-Reply-To:  <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Patrick O'Keefe wrote:
> > Ok, that will give 2 different devices with the same volser, but you
> > won't get 2 different volsers for the same device. In the case of ENQ/DEQ
> > you won't an ENQued device accessable by another name.  I *think* that
> > was the context of the statement, but I may be wrong.
> 
> While it isn't possible to have two different volsers for the same
> *physical* device, you can /easily/ have two different volsers for the
> same device number (which is all MVS knows)! Suppose you have a DASD
> subsystem attached as '80xx' on system "A". You could attach that same
> subsystem as '90xx'on system "B"!
> 
When two different entities are known by the same name, there's
no integrity hazard; merely an unnecessary restriction of
availability because of a superfluous ENQ, as happens today when
a systems programmer wants to build a copy of SYS1.LINKLIB for
testing (and then delete it).

If one entity is known by two different names, there is an
integrity hazard, because two systems may obtain EXCL ENQ of
it by the different names and unwittingly update it concurrently.

Are you sure that a single volume can't be known by two different
names?  Consider: surely it's possible to rename a volume (the
verb "clip" comes to mind).  Can one system dismount and rename
a volume while it remains mounted on another system, then
remount it by the new name while the other system still knows
it by the old name?

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

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

Re: S99RBXLN "Head's Up"

[Robert A. Rosenberg]

At 09:04 -0700 on 08/02/2006, Edward Jaffe wrote about Re: S99RBXLN 
"Head's Up":



IATYREGS is not an exception. *All* JES3 macros allow repeated inclusion.


If I remember correctly, so do the JES2 mapping macros. IOW: As they 
are expanded, they set a "I've been expanded/invoked" Global SETB 
flag and will jump to the end of the macro when called more than once 
(this handles the "expand all your prereqs" cases).


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

Re: compress a proclib

[Lizette Koehler]

I think there are actually a couple of solutions here.

1)  Do not put user proclibs in JES2.  Use the JCLLIB statement instead.
2)  If you do put a user proclib in JES2 then make it with only primary 
allocation and no seconday.  Allow for growth.  If it fills up then use the 
JCLLIB statement
3)  If you do need to compress a proclib in JES2 be aware during the compress 
process you can get I/O errors while the JCL is trying to convert.  Just 
resubmit the job.

To compress:

Use DISP=SHR in the COMPRESS JCL (usually IEBCOPY).
Next have a second batch job ready to go to access a proc in a different 
PROCxxx statement.  It is okay to use a dummy.  This process causes JES2 to 
close and reopen PROC00.  JES2 remembers the members TTR pointers and keeps 
them in storage, so it does not need to read the proclibs everytime to find out 
where they are.  The use of the other PROCxxx entry is to force JES2 to relearn 
the TTR pointers.

Be prepared to have jobs resubmitted should they get I/O errors during 
conversion.


My preference is to always use a JCLLIB for everything except SYSTEM Proclibs.  
And to always allocate my system proclibs with only primary and very big.  If 
you do have proclibs that have secondary extents, always scheule a compress job 
weekly when batch can be quiesced.

Lizette

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

Re: compress a proclib

[Mark Zelden]

On Wed, 2 Aug 2006 15:55:19 -0500, Mark Zelden <[EMAIL PROTECTED]> wrote:

>On Wed, 2 Aug 2006 15:49:24 -0500, McKown, John
><[EMAIL PROTECTED]> wrote:
>
>>OK, maybe I'm living a charmed life. But if I need to compress a
>>PROCLIB, I just run IEBCOPY with a DISP=SHR on it. I've never had a
>>problem.
>
>On Wed, 2 Aug 2006 15:46:36 -0500, Eric N. Bielefeld
><[EMAIL PROTECTED]> wrote:
>
>>I have never had a problem compressing a proclib on the fly.
>
>See the first post in the thread I metioned  - Curious Proclib Problem.
>Post was on Wed, Feb 28 2001.   I could quote it again here, but
>what fun would that be.  The archives are a beautiful thing.  :-)
>

Well.. I just re-read some of that thread and the problem was 
actually caused by allocating a new proclib / renaming a proclib. 
However, you can see the same symptoms after a compress. 

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group
mailto: [EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

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

Re: compress a proclib

[Mark Zelden]

On Wed, 2 Aug 2006 15:49:24 -0500, McKown, John
<[EMAIL PROTECTED]> wrote:

>OK, maybe I'm living a charmed life. But if I need to compress a
>PROCLIB, I just run IEBCOPY with a DISP=SHR on it. I've never had a
>problem. 

On Wed, 2 Aug 2006 15:46:36 -0500, Eric N. Bielefeld
<[EMAIL PROTECTED]> wrote:

>I have never had a problem compressing a proclib on the fly. 

See the first post in the thread I metioned  - Curious Proclib Problem.
Post was on Wed, Feb 28 2001.   I could quote it again here, but
what fun would that be.  The archives are a beautiful thing.  :-)

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group
mailto: [EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

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

Re: compress a proclib

[McKown, John]

OK, maybe I'm living a charmed life. But if I need to compress a
PROCLIB, I just run IEBCOPY with a DISP=SHR on it. I've never had a
problem. The only problem that I can think of that might occur is if a
job went to the converter and tried to use the PROCLIB during the actual
compress process. That job will get a JCL error. And you may get a nasty
message about the converter subtask abending. But JES2 stays up.

What am I doing right?

Oh, if I need to reallocate a PROCLIB, then I do the $PJES2,ABEND trick.
But only late at night and with everybody understand that there will be
a short outage for JES2.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited. 

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

Re: compress a proclib

[Eric N. Bielefeld]

I have never had a problem compressing a proclib on the fly.  It is probably 
not a recommended thing to do, and if the proclib is used by multiple 
systems, it may not be a good idea.  I always used a batch job to compress 
SYS1.PROCLIB.  The first step copied the PROCLIB to a new dataset using my 
TSOID as a high level qualifier.  The 2nd step did a compress with DISP=SHR 
coded on the PROCLIB DD statement.  As long as the dataset is not moved, and 
is in the same extents it was before, you should have no problems..


Eric Bielefeld
Sr. z/OS Systems Programmer
Milwaukee Wisconsin
414-475-7434

- Original Message - 
From: "Peter Ten Eyck" <[EMAIL PROTECTED]>



I have read various posting about the problems of compressing a PDS
proclib. I have a proclib call TEST.PROCLIB which out of space.

Data Set Name  . . . : TEST.PROCLIB

General Data  Current Allocation
Volume serial . . . : D90300  Allocated tracks  . : 1,478
Device type . . . . : 3390Allocated extents . : 16
Organization  . . . : PO  Maximum dir. blocks : 250
Record format . . . : FB
Record length . . . : 80
Block size  . . . . : 8880   Current Utilization
1st extent tracks . : 353Used tracks . . . . : 1,478
Secondary tracks  . : 75 Used extents  . . . : 16
  Used dir. blocks  . : 192
Creation date . . . : 1996/12/17  Number of members . : 1,215
Referenced date . . : 2006/08/02
Expiration date . . : ***None***

TEST.PROCLIB is known to JES2 through the following PROC (JES2 on z/OS 
1.4).


//JES2 PROC MEMBER=JES2PARM,ALTMEM=JES2PARM,
//  PLIB2='SYS2.PROCLIB',PLIB3='TEST.PROCLIB'
//IEFPROC  EXEC PGM=HASJES20,DPRTY=(15,15),TIME=1440,PERFORM=9
//ALTPARM  DD DISP=SHR,DSN=SYS1.PARMLIB(&ALTMEM)
//HASPPARM DD DISP=SHR,DSN=SYS1.PARMLIB(&MEMBER)
//PROC00   DD DISP=SHR,DSN=SYS1.PROCLIB
// DD DSN=&PLIB2,DISP=SHR
// DD DSN=&PLIB3,DISP=SHR
// DD DISP=SHR,DSN=CPAC.PROCLIB
// DD DISP=SHR,DSN=IPO1.PROCLIB
// DD DISP=SHR,DSN=SYS1.IBM.PROCLIB
// DD DISP=SHR,DSN=IOE.SIOEPROC
//HASPLIST DD DDNAME=IEFRDER

How do I resolve this problem if it is not "safe" to compress? 


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

Re: compress a proclib

[Mark Zelden]

On Wed, 2 Aug 2006 15:25:15 -0500, Peter Ten Eyck
<[EMAIL PROTECTED]> wrote:

>I have read various posting about the problems of compressing a PDS
>proclib. 

Then I'm wondering why you didn't find what you needed in the
archives.

>I have a proclib call TEST.PROCLIB which out of space.
>


>
>TEST.PROCLIB is known to JES2 through the following PROC (JES2 on z/OS 1.4).
>
>//JES2 PROC MEMBER=JES2PARM,ALTMEM=JES2PARM,
>//  PLIB2='SYS2.PROCLIB',PLIB3='TEST.PROCLIB'
>//IEFPROC  EXEC PGM=HASJES20,DPRTY=(15,15),TIME=1440,PERFORM=9
>//ALTPARM  DD DISP=SHR,DSN=SYS1.PARMLIB(&ALTMEM)
>//HASPPARM DD DISP=SHR,DSN=SYS1.PARMLIB(&MEMBER)
>//PROC00   DD DISP=SHR,DSN=SYS1.PROCLIB
>// DD DSN=&PLIB2,DISP=SHR
>// DD DSN=&PLIB3,DISP=SHR
>// DD DISP=SHR,DSN=CPAC.PROCLIB
>// DD DISP=SHR,DSN=IPO1.PROCLIB
>// DD DISP=SHR,DSN=SYS1.IBM.PROCLIB
>// DD DISP=SHR,DSN=IOE.SIOEPROC
>//HASPLIST DD DDNAME=IEFRDER
>
>How do I resolve this problem if it is not "safe" to compress?
>

Search the archives for "Curious Proclib Problem".  

$PJES2,ABEND and hot start (restart) is a 100% cure. Otherwise, this 
is from a post of mine that was in the thread I just mentioned:

"Another problem is that each converter subtask has its own DCB for the 
problib concatenation. The number of subtasks is defined by CNVTNUM in 
PCEDEF. There is a "trick" to try and close and re-open the concatenation, 
but the more subtasks you have, the harder it is to force them all 
to be closed and re-opened. You have to flood the system with enough 
"trick" jobs to force all the tasks to be busy."

"The "trick" job is to use a /*JOBPARM P=? pointing to a 
name that is not the PROCLIB concatenation thathas been changed. 
You can even make up a name - /*JOBPARM P=PROC999. You need to submit 
as many of these at once as you can (put multiple jobs in a data set 
and submit the data set)."

Regards,

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group
mailto: [EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

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

compress a proclib

[Peter Ten Eyck]

I have read various posting about the problems of compressing a PDS 
proclib. I have a proclib call TEST.PROCLIB which out of space. 

Data Set Name  . . . : TEST.PROCLIB
   
General Data  Current Allocation   
 Volume serial . . . : D90300  Allocated tracks  . : 1,478 
 Device type . . . . : 3390Allocated extents . : 16
 Organization  . . . : PO  Maximum dir. blocks : 250   
 Record format . . . : FB 
 Record length . . . : 80  
 Block size  . . . . : 8880   Current Utilization  
 1st extent tracks . : 353Used tracks . . . . : 1,478 
 Secondary tracks  . : 75 Used extents  . . . : 16
   Used dir. blocks  . : 192   
 Creation date . . . : 1996/12/17  Number of members . : 1,215 
 Referenced date . . : 2006/08/02  
 Expiration date . . : ***None***  

TEST.PROCLIB is known to JES2 through the following PROC (JES2 on z/OS 1.4).

//JES2 PROC MEMBER=JES2PARM,ALTMEM=JES2PARM,   
//  PLIB2='SYS2.PROCLIB',PLIB3='TEST.PROCLIB'  
//IEFPROC  EXEC PGM=HASJES20,DPRTY=(15,15),TIME=1440,PERFORM=9 
//ALTPARM  DD DISP=SHR,DSN=SYS1.PARMLIB(&ALTMEM)   
//HASPPARM DD DISP=SHR,DSN=SYS1.PARMLIB(&MEMBER)   
//PROC00   DD DISP=SHR,DSN=SYS1.PROCLIB
// DD DSN=&PLIB2,DISP=SHR  
// DD DSN=&PLIB3,DISP=SHR  
// DD DISP=SHR,DSN=CPAC.PROCLIB
// DD DISP=SHR,DSN=IPO1.PROCLIB
// DD DISP=SHR,DSN=SYS1.IBM.PROCLIB
// DD DISP=SHR,DSN=IOE.SIOEPROC
//HASPLIST DD DDNAME=IEFRDER   

How do I resolve this problem if it is not "safe" to compress?

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

Re: Data set ENQueues and DEQueues in Jobs

[Edward Jaffe]

Patrick O'Keefe wrote:
Ok, that will give 2 different devices with the same volser, but you 
won't get 2 different volsers for the same device. In the case of ENQ/DEQ
you won't an ENQued device accessable by another name.  I *think* that 
was the context of the statement, but I may be wrong.
  


While it isn't possible to have two different volsers for the same 
*physical* device, you can /easily/ have two different volsers for the 
same device number (which is all MVS knows)! Suppose you have a DASD 
subsystem attached as '80xx' on system "A". You could attach that same 
subsystem as '90xx'on system "B"!


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

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

Re: Data set ENQueues and DEQueues in Jobs

[Patrick O'Keefe]

On Wed, 2 Aug 2006 08:51:55 -0700, Edward Jaffe 
<[EMAIL PROTECTED]> wrote:

>...
>When duplicates volsers exist, you get prompted at IPL time to indicate
>which device should remain offline. There's nothing stopping an operator
>from responding differently as different systems are IPLed. Even without
>an IPL, you can vary one device offline and then vary another one online
>with the same volser. Two different physical devices. Same volser.
>...

Ok, that will give 2 different devices with the same volser, but you 
won't get 2 different volsers for the same device. In the case of ENQ/DEQ
you won't an ENQued device accessable by another name.  I *think* that 
was the context of the statement, but I may be wrong.

Pat O'Keefe  

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

Re: VTAM buffer trace

[Patrick O'Keefe]

On Wed, 2 Aug 2006 10:00:58 -0500, Johnston, Robert E 
<[EMAIL PROTECTED]> wrote:

>...
>I think I read something the past few days that said the trace must be
>active on the owning system. Whatever it said, I wasn't sure if it
>applied to me. Sounds like it does.
>...

Actually, you may need to run the trace on the system that owns primary LU,
the application the LU is in session with.  If you have to take the trace
on the system owning the device LU you might have to use the VTAM Internal
trace.

(Jees.  I use to know this stuff by heart.  My synapses are calcifying.)

Pat O'Keefe

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

Re: S99RBXLN "Head's Up"

[Paul Gilmartin]

In a recent note, Edward Jaffe said:

> Date: Wed, 2 Aug 2006 09:04:38 -0700
> >
> > IBM would have done well to follow such conventions uniformly.
> > They don't appear to, with some exceptions such as IATYREGS.
> 
> IATYREGS is not an exception. *All* JES3 macros allow repeated inclusion.
> 
Notice that I said "some exceptions", not "one exception".  And
I'll continue to consider the JES3 macros, jointly, exceptional
in this respect insofar as they differ from the preponderance
of IBM macros, which reside in SYS1.MACLIB and SYS1.MODGEN.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

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

Re: Finger trouble brings down NHS

[Ed Finnell]

 
In a message dated 8/2/2006 1:53:34 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

gotta  get me one of those IPS.  Much more fun than  UPS.



>>
Yeah just in time. Looks like Chris is gonna follow Katrina into the Gulf.  
Bump off Fla/,  bulk up and wham NOLA.
 
_http://www.nhc.noaa.gov/_ (http://www.nhc.noaa.gov/) 
 
What was it? Had a Datacom switch and had 3081's(mid eighties) and heavy  
construction severed one feed. Fortunately we had dual feeds and everything was 
 
fine, but single path to some Controllers. No problem...well it was if you 
just  laid off the guy with the passwords to the switch! Anyway finally got the 
master  from the vendor. Only a few more gray hairs.

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

Re: Finger trouble brings down NHS

[J R]

problem with the interruptible power supplies


I gotta get me one of those IPS.  Much more fun than UPS.



From: Phil Payne <[EMAIL PROTECTED]>
Reply-To: IBM Mainframe Discussion List 
To: IBM-MAIN@BAMA.UA.EDU
Subject: Finger trouble brings down NHS
Date: Wed, 2 Aug 2006 11:52:07 +0200

Well, a large part of it for over three days.  Anyone remember when a 
mainframe last brought
down a hospital for three days, let alone eighty of them?  Also a 
cautionary tale for the
outsourced - if there are only enough engineers to bring up n customers an 
hour, have you got

your priorities sorted out?

This really is a cautionary tale - making the intangible "what if it all 
goes wrong" much more

tangible.

And note the really good bit:

"The original outage was preceded on Sunday with a team of engineers being 
called to
investigate a problem with the interruptible power supplies that usually 
prevent losses of

electricity to the computers in CSC's Maidstone data centre.

While they where working an unexpected power spike was shot around the data 
centre, taking out

its main servers."

http://www.theregister.co.uk/2006/08/02/private_before_nhs/

(Giggle - http://www.theinquirer.net/default.aspx?article=32550 )
--
  Phil Payne
  http://www.isham-research.co.uk
  +44 7833 654 800

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


_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


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

Re: Heads up OA16212 Jes3 shops on Z/OS 1.7

[B Sysprog]

Have you also seen OA17548 - S0C4 in Vary Offline processing?
We have not seen these symptoms, but have an exposure b/c we have APARFix on 
for OA16173

and OA16743.

Seems to be some problems with allocate and JES3 in z/OS R7.

Best,
BK Kosmach
US Steel


From: "Habres, Richard (GTI)" <[EMAIL PROTECTED]>
Reply-To: IBM Mainframe Discussion List 
To: IBM-MAIN@BAMA.UA.EDU
Subject: Heads up OA16212 Jes3 shops on Z/OS 1.7
Date: Wed, 2 Aug 2006 09:14:39 -0400

We got hit with this yesterday and had to IPL 2 production systems.
DO NOT issue an MVS VARY ONLINE to a JES3 managed tape device that is
already online.
See APAR OA16212. PTFs not available yet.

Richard Habres
AVP;  Enterprise Storage Technology
Merrill Lynch


If you are not an intended recipient of this e-mail, please notify the 
sender, delete it and do not read, act upon, print, disclose, copy, retain 
or redistribute it. Click here for important additional terms relating to 
this e-mail. http://www.ml.com/email_terms/



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


_
FREE pop-up blocking with the new MSN Toolbar – get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/


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

Re: CPU usage for paging

[Ted MacNEIL]

>I may be wrong, but I don't think there is an RMF report that tells you how 
>much CPU is used by paging.

We used to use, as suggested by IBM, SRB time in performance group zero.
Now, in goal mode, would it be SRB in *MASTER*?

When in doubt.
PANIC!!

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

Re: VTAM buffer trace

[SUBSCRIBE IBM-MAIN tdell]

Check the SMIT panels on AIX ,  there is a fairly comprehensive set of
traces under Comm Server for AIX.  It should be able to tell you what's
going on. Also you can check the Topology database on AIX to see if has
information on the routing that's going on. Alternatively you can trace the
connection from both ends, which could give you a better picture of what's
happening.

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

Re: CPU usage for paging

[Jim Wagner]

The method in which I've acheived the most success in these types of 
scenarios was to model. Not to run a commercial, Best/1 was my tool of 
choice. In this manner you can take your actual workload and do different 
what if cases and see pretty accururately how your environment will perform 
after the change.

Good luck.

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

Re: Namespace Conflicts (Was: S99RBXLN "Head's Up")

[Ray Mullins]

And get them to at least do test assemblies on stuff xlated from PL/X.  (I
found one in DB2 V71 recently that was introduced by a recent PTF; a PMR has
been opened.)

Later,
Ray 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Edward Jaffe
Sent: Wednesday August 02 2006 09:10
To: IBM-MAIN@BAMA.UA.EDU
Subject: Namespace Conflicts (Was: S99RBXLN "Head's Up")

Richard Tsujimoto wrote:
> I think Paul made a good point about not creating labels that are 
> similar in format as the ones IBM distributes with their code.

And, we must keep reminding IBM to fix their macros when sloppy developers
choose too-common labels. My most recent effort in this regard led to the
creation of APAR OA17535.

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

Re: Java Packed Decimal

[Ray Mullins]

Unisys still covers the two different families, so if the Burroughs
equipment had it, then they do support it on that ClearPath line.  (POP for
Unisys, anyone?)

Later,
Ray

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Shmuel Metz (Seymour J.)
Sent: Wednesday August 02 2006 06:56
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Java Packed Decimal

In <[EMAIL PROTECTED]>,
on 08/01/2006
   at 09:16 AM, "Thompson, Steve (SCI TW)"
<[EMAIL PROTECTED]> said:

>I must assume that UNISYS uses PD.

Unisys has or had a  successor to the B6500 family, so they must have
supported PD. The 1108 didn't have PD, and I don't know whether the Unisys
successor added it.
 

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

Namespace Conflicts (Was: S99RBXLN "Head's Up")

[Edward Jaffe]

Richard Tsujimoto wrote:
I think Paul made a good point about not creating labels that are similar 
in format as the ones IBM distributes with their code.


And, we must keep reminding IBM to fix their macros when sloppy 
developers choose too-common labels. My most recent effort in this 
regard led to the creation of APAR OA17535.


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

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

Re: S99RBXLN "Head's Up"

[Edward Jaffe]

Paul Gilmartin wrote:

I believe it's a requirement of ANSI C that all standard library
headers should be coded so they may be #include'd repeatedly, and
subsequent invocations are benign.  This is usually accomplished
by similar conditional compilation.

And each library header must #include all its prerequisites so
the prerequisites are invisible to the end user.

IBM would have done well to follow such conventions uniformly.
They don't appear to, with some exceptions such as IATYREGS.
  


IATYREGS is not an exception. *All* JES3 macros allow repeated inclusion.

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

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

Re: CPU usage for paging

[Hal Merritt]

The relationship is not easy to quantify, and even harder to predict how
adding more of a resource will affect meeting your goals. IBM marketing
has some tools that will do a credible job of answering your questions.
Check with your business partner or friendly IBM rep.   

With ample main (a zero demand page in rate) and applications well tuned
to exploit main, you might see reductions of upwards of 20% of total CPU
consumption in I/O avoidance alone. You might also see some reductions
in batch clock times ranging from just measurable to drastic.   

"Well tuned" means sequential batch with maximum block sizes and optimal
buffer sizes, and onlines with very high buffer lookaside hit rates (98%
or more).  

Sorry, but I have zero experience with WAS.

HTH and good luck. 
 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Craig Dudley
Sent: Wednesday, August 02, 2006 9:57 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: CPU usage for paging

 <[EMAIL PROTECTED]>
 <[EMAIL PROTECTED]>
X-Mailer: CTM PowerMail version 5.2.3 build 4406 English
 
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi,
I am looking for the RMF report(s) where I can find out how much CPU
time
my system (2066-0A2 w/8 GB) to perform paging. I am trying to determine
how much CPU I will "get back" if we buy more memory.
WAS on z is involved ;>)
Thanks
-- 
Craig Dudley
Systems & Communications Sciences, Inc.
244 Poor Farm Rd.
New Ipswich, NH 03071-3922
603-878-1148   Fax 603-878-1929

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

Re: MIM configuration performance

[Mark Zelden]

On Wed, 2 Aug 2006 16:35:56 +0200, Vernooy, C.P. - SPLXM
<[EMAIL PROTECTED]> wrote:


>I was wondering if and why CTConly is faster than Dasdonly. We use Ficon
>and ESS and have no I/O queing and 100% cache hit ratio for the control
>file. In the Dasdonly configuration each system has to
>waitfor-read-writeback the control file, in a CTConly each system,
>except the Master, must request-update-sendback the controlfile, in both
>cases on Ficon speed. The Master will of course benefit from owning the
>VCF, but do the clients benefit substantially from CTC mode?

I would think the answer is HARDWARE RESERVE. Hardware reserve is 
still slow (FSVO of slow).   That is why in a GRS STAR (or MIM in CF)
configuration, the old ROTs go out the window for what is okay to
leave as a reserve. 

>
>With "allowable load" I refer to the MII activity rate that will not
>impact performance. I remember we removed SYSIGGV2 from converting to
>global enq when the Dasd control file was still on Escon chached disk,
>because this amount of activity in MIM was noticable in the system
>performance.

You're lucky you didn't end up with a deadlock then.  SYSIGGV2 should
be converted.  SYSVVDS / SYSVTOC should not be.  If you convert one
of them, you must convert both. 

>
>The CA doc seems outdated. It mentions 3088's and Escon but no Ficon and
>the reported cycletimes seem rather high to me for current hardware: 6
>msec cycletime for CTC and XCF, our Dasd cycletime is 3 - 4 msec.  Maybe
>Norman can trigger some updates on this matter?
>

Contact CA.

Cheers,

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group
mailto: [EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

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

Re: Data set ENQueues and DEQueues in Jobs

[Edward Jaffe]

Shmuel Metz (Seymour J.) wrote:

But there must be something  canonical across systems that is  unique
to the device for a cross-system ENQ involving devices to work.



The volume serial number.
  


When duplicates volsers exist, you get prompted at IPL time to indicate 
which device should remain offline. There's nothing stopping an operator 
from responding differently as different systems are IPLed. Even without 
an IPL, you can vary one device offline and then vary another one online 
with the same volser. Two different physical devices. Same volser.


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

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

Re: CPU usage for paging

[Eric N. Bielefeld]

Craig,

I may be wrong, but I don't think there is an RMF report that tells you how 
much CPU is used by paging.  Obviously, you can tell just how many pages per 
second you are doing.  Someone may have a rule of thumb that says that for X 
processor, so many pages per second equals 1% of the processor.


It might help if you told us just how many pages per second you are doing, 
and how many paging devices you have.  If you are running at 100% CPU 
utilization, adding memory will certainly buy pack a small percent of CPU. 
If you are running less than 100%, the lower page rate may drive up the 
processor usage to 100% because you are not waiting for paging.


At any rate, memory is getting cheaper all the time, and you would be wise 
to buy more.  If budgeting for more memory is tight, you can probably find 
something on the used market.


Eric Bielefeld
Sr. z/OS Systems Programmer
Milwaukee Wisconsin
414-475-7434

- Original Message - 
From: "Craig Dudley" <[EMAIL PROTECTED]>

Hi,
I am looking for the RMF report(s) where I can find out how much CPU time
my system (2066-0A2 w/8 GB) to perform paging. I am trying to determine
how much CPU I will "get back" if we buy more memory.
WAS on z is involved ;>)
Thanks
--
Craig Dudley
Systems & Communications Sciences, Inc.
244 Poor Farm Rd.
New Ipswich, NH 03071-3922
603-878-1148   Fax 603-878-1929 


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

Re: Data set ENQueues and DEQueues in Jobs

[(IBM Mainframe Discussion List)]

 
 
In <[EMAIL PROTECTED]>, on 08/01/2006
at  11:17 AM, "(IBM Mainframe Discussion List)"  <[EMAIL PROTECTED]>
said:

>>But there must be  something  canonical across systems that is  unique
>>to the  device for a cross-system ENQ involving devices to work.
 
In a message dated 8/2/2006 10:33:54 A.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:
 
>The volume serial number.
Alas, no. But I would argue that it is sound practice to keep them unique  
within the entire DASD farm.
Since device numbers are not necessarily canonical across systems, in a  
truly pathological case you could have volser W on device  number X on system 
Y, 
and volser W on device number X on system  Z, yet the two volsers labelled W 
are different volumes because the two devices  numbered X are different 
devices. 
 There is information in the  Configuration Data Record which is unique to 
the device.
 
Bill  Fairchild



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

Re: CPU usage for paging

[Craddock, Chris]

> I am looking for the RMF report(s) where I can find out how much CPU
time
> my system (2066-0A2 w/8 GB) to perform paging. I am trying to
determine
> how much CPU I will "get back" if we buy more memory.
> WAS on z is involved ;>)

I am not aware of any specific RMF report that gives you what you want.
You can make some estimates but that's about all, because there is a
non-linear relationship between paging and throughput.

That said, you can get page rates and paging response times from RMF and
make a fairly informed estimate of potential improvements in throughput
and responsiveness for % improvements (reductions) in the demand page-in
rate. The back of an envelope is as good a place as any for the
calculation of how much benefit per unit increase in memory capacity.

If you're not seeing significant paging delays and high demand page-in
rates, you may not have a problem that more memory will really help.
Other kinds of paging also takes up cpu time and competes for ASM
resources, but does not really impact responsiveness much.

If you are storage and cpu constrained, then adding memory will
typically increase the total system service rate, but without
necessarily lowering the cpu utilization much, if any.

CC

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

Re: Data set ENQueues and DEQueues in Jobs

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 08/01/2006
   at 11:17 AM, "(IBM Mainframe Discussion List)" <[EMAIL PROTECTED]>
said:

>But there must be something  canonical across systems that is  unique
>to the device for a cross-system ENQ involving devices to work.

The volume serial number.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Java Packed Decimal

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>,
on 08/01/2006
   at 09:16 AM, "Thompson, Steve (SCI TW)"
<[EMAIL PROTECTED]> said:

>I must assume that UNISYS uses PD.

Unisys has or had a  successor to the B6500 family, so they must have
supported PD. The 1108 didn't have PD, and I don't know whether the
Unisys successor added it.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Data set ENQueues and DEQueues in Jobs

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 08/01/2006
   at 11:01 AM, "(IBM Mainframe Discussion List)" <[EMAIL PROTECTED]>
said:

>Device numbers are canonical across  systems.

Alas, no. But I would argue that it is sound practice to keep them
consistent.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Data set ENQueues and DEQueues in Jobs

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 08/01/2006
   at 07:59 AM, Paul Gilmartin <[EMAIL PROTECTED]> said:

>You understood my intent.  And I briefly considered the UCB address,
>but passed over it because I don't know that it's guaranteed to be
>canonical across multiple systems.

The UCB address is pretty much guarantied to not be canonical, and the
device address is not guarantied to be canonical.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Data set ENQueues and DEQueues in Jobs

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 08/01/2006
   at 06:44 AM, Paul Gilmartin <[EMAIL PROTECTED]> said:

>View this from the perspective of the initiator: RET=CHNG is
>available, yet the initiator never exploits it -- it can't by design
>objective. 

You're overlooking DYNALLOC.

>Likewise, if RET=CHNG were not available, you could equally well
>simply DEQ and re-ENQ  with EXCL scope.

That wouldn't have the same effect and would be, in general,
disastrous.

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

Re: Data set ENQueues and DEQueues in Jobs

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 08/01/2006
   at 01:47 AM, "Robert A. Rosenberg" <[EMAIL PROTECTED]> said:

>You trimmed my quote back too far. I acknowledged in my statement 
>that the root cause of the need to not include the VOLSER in the 
>RNAME is that the ENQ is being done prior to the allocation of the 
>dataset being managed by the ENQ

That's only the tip of the iceberg. Regardless of when you do the ENQ
there are issues that must be dealt if you are to avoid a deadlock.

>So long as you do not know 
>which version of a dataset you are going to use,

The problem does not go away if you know which version.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

CPU usage for paging

[Craig Dudley]

 <[EMAIL PROTECTED]>
 <[EMAIL PROTECTED]>
X-Mailer: CTM PowerMail version 5.2.3 build 4406 English
 
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi,
I am looking for the RMF report(s) where I can find out how much CPU time
my system (2066-0A2 w/8 GB) to perform paging. I am trying to determine
how much CPU I will "get back" if we buy more memory.
WAS on z is involved ;>)
Thanks
-- 
Craig Dudley
Systems & Communications Sciences, Inc.
244 Poor Farm Rd.
New Ipswich, NH 03071-3922
603-878-1148   Fax 603-878-1929

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

Re: VTAM buffer trace

[Johnston, Robert E]

Hi John,
The AIX box is Ethernet connected thru a Visara 1174. It was connected
thru a 3174 - we are testing the Visara unit. So, no NCP.

I think I read something the past few days that said the trace must be
active on the owning system. Whatever it said, I wasn't sure if it
applied to me. Sounds like it does.

Thanks for your help...
Robert

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of John S. Giltner, Jr.
Sent: Tuesday, August 01, 2006 7:52 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: VTAM buffer trace


How is the AIX box connected?  If via NCP, then you can trace from the 
VTAM that owns the NCP, but you must trace the line in the NCP.  If not,

then you need to trace from the VTAM that owns the LU resides.


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

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

Re: Test tools, was: Strobe equivalents

[Clark Morris]

On 1 Aug 2006 22:11:44 -0700, in bit.listserv.ibm-main you wrote:

>
>
>Beate Kawelke writes:
>>We are currently looking for tools to help us manage test
>>scenarios - up to now to no avail. We would like to define
>>test scenarios and also manage the data / processes. For
>>example, a test scenario would consist of some user input
>>in ISPF panels, a server request, a result being displayed,
>>a dataset being created. After a major change to our
>>software, we would run that scenario (as automated as
>>possible) and check if the results are the same.
>>Anybody got input on that ?
>
>I'll give you some IBM examples (in no particular order), and there are
>undoubtedly others. As another commenter hinted, this category is gigantic
>in the mainframe "we're fanatical about software quality" world of
>application development.

That depends on the shop.  I've seen plenty of grungy mainframe
application code, both buggy and inefficient.  We all have the vendors
we like to hate for various reasons.  
>
>> some snippage
>- - - - -
>Timothy Sipples
>IBM Consulting Enterprise Software Architect
>Specializing in Software Architectures Related to System z
>Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
>E-Mail: [EMAIL PROTECTED]

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

Re: MIM configuration performance

[Ken Porowski]

Talk to MIM support, they have always been willing to review control
file configurations and settings and make recommendations for tuning.
IIRC there is/was a presentation/whitepaper on CF performance (SHARE,
CMG, CA conferences?) maybe even on their web site.  

Ken Porowski
AVP Systems Software
CIT Group
E: [EMAIL PROTECTED]



-Original Message-
Vernooy, C.P.

Hello list,

We are investigating the performance differences of the various MIM
Control File configurations. We are fully Ficon and combine four z/OS
1.6 Systems from two Sysplexes in the Mimplex, so our options are:
Dasdonly, CTCDasd and CTConly. 

Does anybody have information about performance and allowable load of
these three configurations?

Thanks

Kees.

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

Re: Finger trouble brings down NHS

[Perryman, Brian]

Nothing in my posting suggested that I got from the original posting the 
information about the NHS not using mainframes.



-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
Behalf Of Clark Morris
Sent: 02 August 2006 15:35
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Finger trouble brings down NHS


On 2 Aug 2006 05:30:34 -0700, in bit.listserv.ibm-main you wrote:

>I can't believe the cost of that system either - I think I saw on BBC News at 
>some point that it will end up having cost over 20 BILLION. That's UK Pounds.. 
>so more than that in USD.
>
>Gimme a mainframe and some decent programmers and I'll do it for a tenth of 
>that.. ;-)

Nohing in this posting excludes the possibility that the servers are
mainframes.  The physical disk drives probably would be the same
regardless of CPU, just the controllers, connections and operating
systems would be different.

-
This e-mail message is for the sole use of the intended recipient(s)and may 
contain confidential and privileged information of Transaction NetworkServices. 
 
Any unauthorized review, use, disclosure or distribution isprohibited.  If you 
are not the intended recipient, please contact thesender by reply e-mail and 
destroy all copies of the original message.

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

Re: MIM configuration performance

[Vernooy, C.P. - SPLXM]

""Mark Zelden"" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> On Wed, 2 Aug 2006 14:15:40 +0200, Vernooy, C.P. - SPLXM
> <[EMAIL PROTECTED]> wrote:
> 
> 
> >
> >We are investigating the performance differences of the various MIM
> >Control File configurations. We are fully Ficon and combine four z/OS
> >1.6 Systems from two Sysplexes in the Mimplex, so our options are:
> >Dasdonly, CTCDasd and CTConly. 
> >
> >Does anybody have information about performance and allowable load of
> >these three configurations?
> >
> 
> 1st  = CTCONLY
> 2nd  = CTCDASD
> 3rd  = DASDONLY  ** (see note below)
> 
> CTCDASD is the same performance as CTCONLY (since it uses CTCs) 
> except when a system joins the MIMplex.  Then the VCF (virtual 
> control file) temporarily migrates back to DASD during that 
> process.  
> 
> CTCONLY is of course better with FICON than ESCON.  That is what we
> use here since we share tape and dasd across sysplex boundries.
> 
> ** DASDONLY is also what is used when putting the control file in
> a coupling facility.  This is the best configuration of all and is 
> comparable to GRS STAR.  Of course you can only do this if your
> MIMplex = parallel sysplex. 
> 
> I am not sure what you mean by "allowable load".  

Mark and Ted,

Thanks for the info.
I was wondering if and why CTConly is faster than Dasdonly. We use Ficon
and ESS and have no I/O queing and 100% cache hit ratio for the control
file. In the Dasdonly configuration each system has to
waitfor-read-writeback the control file, in a CTConly each system,
except the Master, must request-update-sendback the controlfile, in both
cases on Ficon speed. The Master will of course benefit from owning the
VCF, but do the clients benefit substantially from CTC mode?

With "allowable load" I refer to the MII activity rate that will not
impact performance. I remember we removed SYSIGGV2 from converting to
global enq when the Dasd control file was still on Escon chached disk,
because this amount of activity in MIM was noticable in the system
performance.

The CA doc seems outdated. It mentions 3088's and Escon but no Ficon and
the reported cycletimes seem rather high to me for current hardware: 6
msec cycletime for CTC and XCF, our Dasd cycletime is 3 - 4 msec.  Maybe
Norman can trigger some updates on this matter?

Kees.


**
For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), 
its subsidiaries and/or its employees shall not be liable for the incorrect or 
incomplete transmission of this e-mail or any attachments, nor responsible for 
any delay in receipt.
**


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

Re: DFSORT and SS

[Reda, John]

Radoslaw,

If you have access to SyncSort you can accomplish everything you are
trying to do very easily.  

Answer to question #1.  To receive the desired output you will need to
use the parm of VLTESTI=2.  This tells the sort to treat just the single
comparison as false if the entire field is not present.  This is useful
when you have multiple comparisons and some fields are present and some
are not.  When the SS data type is used, VLTESTI is smart enough to look
for the string in the portion of the field that is present.  In your
first set of control cards, SyncSort will look for SMITH anywhere from
position 5 until the end of the record.
  
Answer to question #2.  SyncSort provides a HISTOGRM program that will
report on the lengths of the records in a VL data set.  This is
documented in the Programmer's Guide.  It is very easy to use.  If you
need help, let me know and I will be glad to work with you.  

Answer to question #3.  The following OUTFIL statement should do what
you are looking for in question #3.

  OUTFIL FILES=01,OMIT=(5,32000,SS,EQ,C'SMITH')
  OUTFIL FILES=02,SAVE

If this is not what you are looking for let me know.  I'm sure we can
help you out. 

Sincerely, 
John Reda
Software Services Manager
Syncsort Inc.
201-930-8260
 

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of R.S.
> Sent: Tuesday, August 01, 2006 12:42 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: DFSORT and SS
> 
> I have variable length records to filter.
> I should omit all records containing given string, i.e. SMITH.
> I used the following syntax:
> 
> OMIT COND=(5,32000,SS,EQ,C'SMITH')
> OPTION COPY,VLSHRT
> 
> Unfortunately it doesn't work. When I changed the lenght:
> OMIT COND=(5,900,SS,EQ,C'SMITH')
> then some records were filtered. I suspect that only records longer
than
> 904 bytes and containing SMITH in first 900 bytes (excluding RDW).
> 
> Q: How to fix it, I mean omit all records containing SMITH, regardless
> of the length ?
> 
> 
> Q2: What is simple method to find out records length, one by one, or
> just min and max ?
> 
> Q3: How can I split output, put record without the string in one
> dataset, and the rest (with the string) in another one ? Should I use
> OUTFIL or rather something else ?
> 
> Regards
> --
> Radoslaw Skorupka
> Lodz, Poland

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

Re: Finger trouble brings down NHS

[Clark Morris]

On 2 Aug 2006 05:30:34 -0700, in bit.listserv.ibm-main you wrote:

>I can't believe the cost of that system either - I think I saw on BBC News at 
>some point that it will end up having cost over 20 BILLION. That's UK Pounds.. 
>so more than that in USD.
>
>Gimme a mainframe and some decent programmers and I'll do it for a tenth of 
>that.. ;-)

Nohing in this posting excludes the possibility that the servers are
mainframes.  The physical disk drives probably would be the same
regardless of CPU, just the controllers, connections and operating
systems would be different.

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

Re: Finger trouble brings down NHS

[Ken Porowski]

I must be missing something, what is the reference to 'Finger trouble'? 

-Original Message-
Phil Payne

Well, a large part of it for over three days.  Anyone remember when a
mainframe last brought down a hospital for three days, let alone eighty
of them?  Also a cautionary tale for the outsourced - if there are only
enough engineers to bring up n customers an hour, have you got your
priorities sorted out?

This really is a cautionary tale - making the intangible "what if it all
goes wrong" much more tangible.

And note the really good bit:

"The original outage was preceded on Sunday with a team of engineers
being called to investigate a problem with the interruptible power
supplies that usually prevent losses of electricity to the computers in
CSC's Maidstone data centre.

While they where working an unexpected power spike was shot around the
data centre, taking out its main servers."

http://www.theregister.co.uk/2006/08/02/private_before_nhs/

(Giggle - http://www.theinquirer.net/default.aspx?article=32550 )
--
  Phil Payne
  http://www.isham-research.co.uk
  +44 7833 654 800

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

Re: LVL EDIT Macro - Was: Sequence numbers (AGAIN!)

[Gilbert Saint-Flour]

On Tuesday 01 August 2006 08:29, Tom Marchant wrote:

> On Mon, 31 Jul 2006 20:52:43 -0400, Gilbert Saint-Flour wrote:
>>
>> ... I have an EDIT macro called LVL which recycles "gas levels",
>> i.e. it compresses level numbers by reusing those which have no
>> corresponding record in the member and adjusting pos 79-80 
>> of the records, as needed. 

> Have you considered putting it on file 183?

I've considered it for years, but didn't think anyone would be 
interested. Anyway, it's there now at http://gsf-soft.com/Freeware/

-- 

 Gilbert Saint-Flour
 GSF Software
 http://gsf-soft.com/
 mailto:[EMAIL PROTECTED]

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

Re: Heads up OA16212 Jes3 shops on Z/OS 1.7

[Edward Jaffe]

Habres, Richard (GTI) wrote:
We got hit with this yesterday and had to IPL 2 production systems. 
DO NOT issue an MVS VARY ONLINE to a JES3 managed tape device that is
already online. 
See APAR OA16212. PTFs not available yet.
  


Yikes!. The APAR (against 5752SC1B4 -- i.e., allocation) describes, in 
detail, the problem scenario, impact, and verification steps without a 
single mention of JES3 until the problem summary at the end. This leads 
me to wonder if a vary online of an already-online tape device can 
introduce this problem regardless of how the vary is initiated. Also, 
it's not just z/OS 1.7 that appears to be affected. PTFs are being 
issued all the way back to HBB7707 (z/OS 1.4)!


In any case, don't forget to pass this information along to the folks 
reading JES3-L! Many of them don't subscribe to IBM-Main because of its 
sometimes poor signal-to-noise ratio, especially as the end of the week 
approaches.


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

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

Re: MIM configuration performance

[Mark Zelden]

On Wed, 2 Aug 2006 14:15:40 +0200, Vernooy, C.P. - SPLXM
<[EMAIL PROTECTED]> wrote:


>
>We are investigating the performance differences of the various MIM
>Control File configurations. We are fully Ficon and combine four z/OS
>1.6 Systems from two Sysplexes in the Mimplex, so our options are:
>Dasdonly, CTCDasd and CTConly. 
>
>Does anybody have information about performance and allowable load of
>these three configurations?
>

1st  = CTCONLY
2nd  = CTCDASD
3rd  = DASDONLY  ** (see note below)

CTCDASD is the same performance as CTCONLY (since it uses CTCs) 
except when a system joins the MIMplex.  Then the VCF (virtual 
control file) temporarily migrates back to DASD during that 
process.  

CTCONLY is of course better with FICON than ESCON.  That is what we
use here since we share tape and dasd across sysplex boundries.

** DASDONLY is also what is used when putting the control file in
a coupling facility.  This is the best configuration of all and is 
comparable to GRS STAR.  Of course you can only do this if your
MIMplex = parallel sysplex. 

I am not sure what you mean by "allowable load".  Obviously the more
systems you add, the more overhead. But this is not like GRS ring where 
performance goes to H E double hockey sticks when you have more than
2 systems.  I have 8 systems in our FICON CTCONLY MIMplex running 
MII, MIA, and MIC.  MII/MIC run in one asid and MIA runs in a
separate ASID.  I think the architecture of MIM has always been
more like a star (as opposed to a ring) and that is why it has 
always out performed GRS prior to GRS STAR.

Perhaps if Norman Hollandar is lurking he may have more information
since he works for CA.  You can also call the vendor, in my 
experience they are very good at working with customers on MIM 
performance / tuning issues. 

Regards,

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group
mailto: [EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

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

Re: MIM configuration performance

[Ted MacNEIL]

>Dasdonly
   -- slowest
>CTCDasd
  -- medium
>CTConly
  -- fastest

I think you will be hard pressed to break any of them.
We did around 20,000 DASD SIO/s in a 5-image three processor SYSPLEX (105, 1C5, 
1C8) with no measurable impact.

When in doubt.
PANIC!!

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

Heads up OA16212 Jes3 shops on Z/OS 1.7

[Habres, Richard (GTI)]

We got hit with this yesterday and had to IPL 2 production systems. 
DO NOT issue an MVS VARY ONLINE to a JES3 managed tape device that is
already online. 
See APAR OA16212. PTFs not available yet. 

Richard Habres 
AVP;  Enterprise Storage Technology 
Merrill Lynch


If you are not an intended recipient of this e-mail, please notify the sender, 
delete it and do not read, act upon, print, disclose, copy, retain or 
redistribute it. Click here for important additional terms relating to this 
e-mail. http://www.ml.com/email_terms/


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

Re: Command field in TSO/E Logon screen

[Steve Lee]

That field will be stowed in the UA dataset if you still use the
sys1.uads. If not, it is stowed from TSO segment in RACF database since
the UA converted to the RACF TSO segment... 


Regards, 
Steve Lee
Technical Services

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

Re: Command field in TSO/E Logon screen

[Itschak Mugzach]

Gadi, 

DO LU userid NORACF TSO. It will print your TSO segmemnt (stored in racf). As 
you can see, COMMAND is a field in this segment. 

TSO INFORMATION
---
ACCTNUM= XXX
PROC= $SPFQ
SIZE= 4096
MAXSIZE= 00010240
UNIT= SYSDA
USERDATA= 
COMMAND=

Regards, 

Itschak 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of גדי 
בן אבי
Sent: Wednesday, August 02, 2006 12:00 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Command field in TSO/E Logon screen


Hi,

The TSO/E logon screen has a field named command.

Where is the data in this field stored between sessions?

It looks like the data in the other fields comes from RACF.

TIA

GAdi

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Data set ENQueues and DEQueues in Jobs

[Walt Farrell]

On 8/1/2006 4:09 PM, [EMAIL PROTECTED] wrote:

In a recent note, Walt Farrell said:

On 8/1/2006 10:10 AM, Edward Jaffe wrote:

No. Holding a shared ENQ prevents others from acquiring an exclusive ENQ
on the same resource and modifying it. To maintain the integrity of the
resource, you use RET=CHNG to upgrade from shared to exclusive without
losing control. If you were required to DEQ and then re-ENQ to perform
the upgrade, you would lose control of the resource between the time you
inspected it and the time you had the necessary serialization to update
it. In the worst case scenario, someone else could change (or even
delete) the resource in-between!!

Of course, if anyone else also has the resource with a shared ENQ, your
RET=CHNG will fail, and at that point you have no choice but to DEQ and
try again from the beginning (presumably starting with EXC that time
around).


What do you gain by performing the DEQ?  The EXCL ENQ will immediately
fail and continue to fail until all other jobs DEQ the resource.
Isn't it as good or better simply to re-issue the RET=CHNG until
it works, or use the WAIT option if you have the authority.



Re-issuing the RET=CHNG is not guaranteed to ever work.  You might find, 
based on the vagaries of exactly when your program gets CPU time, that 
the resource is always ENQed SHR by someone else when you try to do your 
RET=CHNG.  DEQing and re-ENQing will succeed, possibly with an automatic 
WAIT.


I'm not sure what WAIT option you're referring to, when using RET=CHNG.

Walt Farrell, CISSP
z/OS Security Design, IBM

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

Re: Finger trouble brings down NHS

[Nigel Hadfield]

Well, that's the cost of the entire new IT system. What went down this time
was a relatively small part of the NHS's current IT. The BBC (initially at
least) reported this as a SAN failure. This follows swiftly on from a
well-publicised SAN failure at a largish UK ISP, and an entirely
unpublicised SAN failure that hit the email system at a major UK government
department.

Mainframes may well use the very same SANs, but I would expect the
backup/recovery and DR procedures to be much more robust.

Nigel


On 2/8/06 13:30, "Perryman, Brian" <[EMAIL PROTECTED]> wrote:

> I can't believe the cost of that system either - I think I saw on BBC News at
> some point that it will end up having cost over 20 BILLION. That's UK Pounds..
> so more than that in USD.
> 
> Gimme a mainframe and some decent programmers and I'll do it for a tenth of
> that.. ;-)
> This e-mail message is for the sole use of the intended recipient(s)and may
> contain confidential and privileged information of Transaction
> NetworkServices. 
> Any unauthorized review, use, disclosure or distribution isprohibited.  If you
> are not the intended recipient, please contact thesender by reply e-mail and
> destroy all copies of the original message.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Finger trouble brings down NHS

[Perryman, Brian]

http://www.timesonline.co.uk/article/0,,2-2203396,00.html


-
This e-mail message is for the sole use of the intended recipient(s)and may 
contain confidential and privileged information of Transaction NetworkServices. 
 
Any unauthorized review, use, disclosure or distribution isprohibited.  If you 
are not the intended recipient, please contact thesender by reply e-mail and 
destroy all copies of the original message.

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

Re: Finger trouble brings down NHS

[Crispin Hugo]

If it was IBM equipment then it would have been 37.6 Billion Dollars as UK
pays pound for dollar for hardware and software

Crispin Hugo 

Systems Programmer, Macro 4

http://www.macro4.com/

Macro 4 plc, The Orangery, Turners Hill Road, Worth, Crawley, RH10 4SS

Direct Line: +44 (0)1293 872121 Switchboard: +44 (0) 1293 872000

Fax: +44 (0) 1293 872001

This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system. E-mail transmission cannot be guaranteed to be
secure or error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender
therefore does not accept liability for any errors or omissions in the
contents of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This message is
provided for informational purposes and should not be construed as a
solicitation, offer or acceptance of any offer.

 






This email has been scanned for all known viruses by the MessageLabs Email 
Security Service and the Macro 4 plc internal virus protection system.


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

Re: Finger trouble brings down NHS

[Daniel A. McLaughlin]

roughtly 37.6 billion USD at an exchange rate of 1.88 per pound sterling.




Daniel McLaughlin
ZOS Systems Programmer
Crawford & Company
PH: 770 621 3256
*
"Everything comes to him who hustles while he waits."
? Thomas A. Edison











"Perryman, Brian" <[EMAIL PROTECTED]> 
Sent by: IBM Mainframe Discussion List 
08/02/2006 08:30 AM
Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@BAMA.UA.EDU
cc

Subject
Re: Finger trouble brings down NHS






I can't believe the cost of that system either - I think I saw on BBC News 
at some point that it will end up having cost over 20 BILLION. That's UK 
Pounds.. so more than that in USD.

Gimme a mainframe and some decent programmers and I'll do it for a tenth 
of that.. ;-)
This e-mail message is for the sole use of the intended recipient(s)and 
may 
contain confidential and privileged information of Transaction 
NetworkServices. 
Any unauthorized review, use, disclosure or distribution isprohibited.  If 
you 
are not the intended recipient, please contact thesender by reply e-mail 
and 
destroy all copies of the original message.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Finger trouble brings down NHS

[Perryman, Brian]

I can't believe the cost of that system either - I think I saw on BBC News at 
some point that it will end up having cost over 20 BILLION. That's UK Pounds.. 
so more than that in USD.

Gimme a mainframe and some decent programmers and I'll do it for a tenth of 
that.. ;-)
This e-mail message is for the sole use of the intended recipient(s)and may 
contain confidential and privileged information of Transaction NetworkServices. 
 
Any unauthorized review, use, disclosure or distribution isprohibited.  If you 
are not the intended recipient, please contact thesender by reply e-mail and 
destroy all copies of the original message.

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

Re: APF Authorized Code/Libraries.

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Hunkeler Peter (KIUB
34)
> 
> >>> There are two ways:
> >>OK, I can't count!
> >To paraphrase: There are 11 kinds of people in the world, those who 
> >understand base 3, and those who don't
> 
> 11 (base3) equals 4 (base10), doesn't it?
> 
> Maybe I just don't understand base 3. I used to know this as: 
> "There are 10 kinds of people in the world, those who 
> understand binary, and those who don't".

"Inflation".

See


or 

:-)

-jc-

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

Finger trouble brings down NHS

[Phil Payne]

Well, a large part of it for over three days.  Anyone remember when a mainframe 
last brought
down a hospital for three days, let alone eighty of them?  Also a cautionary 
tale for the
outsourced - if there are only enough engineers to bring up n customers an 
hour, have you got
your priorities sorted out?

This really is a cautionary tale - making the intangible "what if it all goes 
wrong" much more
tangible.

And note the really good bit:

"The original outage was preceded on Sunday with a team of engineers being 
called to
investigate a problem with the interruptible power supplies that usually 
prevent losses of
electricity to the computers in CSC's Maidstone data centre.

While they where working an unexpected power spike was shot around the data 
centre, taking out
its main servers."

http://www.theregister.co.uk/2006/08/02/private_before_nhs/

(Giggle - http://www.theinquirer.net/default.aspx?article=32550 )
-- 
  Phil Payne
  http://www.isham-research.co.uk
  +44 7833 654 800

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

MIM configuration performance

[Vernooy, C.P. - SPLXM]

Hello list,

 

We are investigating the performance differences of the various MIM
Control File configurations. We are fully Ficon and combine four z/OS
1.6 Systems from two Sysplexes in the Mimplex, so our options are:
Dasdonly, CTCDasd and CTConly. 

Does anybody have information about performance and allowable load of
these three configurations?

 

Thanks

Kees.

 



**
For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), 
its subsidiaries and/or its employees shall not be liable for the incorrect or 
incomplete transmission of this e-mail or any attachments, nor responsible for 
any delay in receipt.
**


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

Re: Command field in TSO/E Logon screen

[Terry Sambrooks]

Hi:

In response to the query:

"The TSO/E logon screen has a field named command.

Where is the data in this field stored between sessions?

It looks like the data in the other fields comes from RACF."

The contents of the command field, last line of the TSO Logon Screen, is also 
stored in RACF.

It forms part of the TSO Segment for a RACF defined user, and can be given an 
initial value when the Userid is created.

Kind regards - Terry

Terry Sambrooks
Director
KMS-IT Limited
228 Abbeydale Road South
Dore
Sheffield
S17 3LA
UK

Tel: +44 (0)114 262 0933
WEB:
www.legac-e.co.uk


Reg: England & Wales 3767263 at the above address

All outgoing E-mails are scanned but it remains the recipients responsibility 
to ensure that their system is protected from viruses, trojans, worms, and 
spy-ware.

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

Re: DFSORT and SS

[David Betten]

Frank Yaeger is always the best at answering these types of questions but
he's on vacation this week.  So I forwarded your question to Vicky Vezinaw
and she supplied the following answers.

ANSWER to Q1:

When you say:
 I used the following syntax:

 OMIT COND=(5,32000,SS,EQ,C'SMITH')
 OPTION COPY,VLSHRT

 Unfortunately it doesn't work.

Did you get a syntax error and are you using DFSORT R14 with the above
statements?  If not please be more specific about the problem you are
encountering.  If you are getting a syntax error, then you need PTF UQ90053
applied.  In that PTF, the maximum length for an SS field used with OUTFIL
INCLUDE and OUTFIL OMIT has been raised to 32752.

ANSWER to Q2:
-
You can run a simple job to get the minimum and maximum record length.  I
derived this JCL from an example in the DFSORT Application Programming
Guide (DISPLAY Operator example)

   DISPLAY FROM(INV) LIST(RDWLIST1) -
   TITLE('No Frills RDW Report') -
   ON(NUM) -
   ON(VLEN) -
   ON(1,4,HEX) -
   MINIMUM('Smallest') -
   MAXIMUM('Largest')

The INV is the DD for the input data set.  RDWLIST1 is the DD for the
output report data set.  The rdw's will be printed with the smallest and
largest RDW printed at the end of the report.


ANSWER to Q3:
-
You can use OUTFIL to accomplish this task.  I also derived the following
JCL from an example in our DFSORT Application Programming Guide (OUTFIL
description, under the SAVE description)

   OUTFIL INCLUDE=(8,6,CH,EQ,C'ACCTNG'),FNAMES=GP1
   OUTFIL SAVE,FNAMES=NOTINC

The DD GP1 data set will have the included records.  The DD NOTINC data set
will have all of the other records (in other words the records that did not
meet the INCLUDE condition).

I hope this helps you.


Have a nice day,
Dave Betten
DFSORT Development, Performance Lead
IBM Corporation
email:  [EMAIL PROTECTED]
1-240-715-4655, tie line 268-1499
DFSORT/MVSontheweb at http://www.ibm.com/storage/dfsort/

IBM Mainframe Discussion List  wrote on 08/01/2006
12:41:43 PM:

> I have variable length records to filter.
> I should omit all records containing given string, i.e. SMITH.
> I used the following syntax:
>
> OMIT COND=(5,32000,SS,EQ,C'SMITH')
> OPTION COPY,VLSHRT
>
> Unfortunately it doesn't work. When I changed the lenght:
> OMIT COND=(5,900,SS,EQ,C'SMITH')
> then some records were filtered. I suspect that only records longer than
> 904 bytes and containing SMITH in first 900 bytes (excluding RDW).
>
> Q: How to fix it, I mean omit all records containing SMITH, regardless
> of the length ?
>
>
> Q2: What is simple method to find out records length, one by one, or
> just min and max ?
>
> Q3: How can I split output, put record without the string in one
> dataset, and the rest (with the string) in another one ? Should I use
> OUTFIL or rather something else ?
>
> Regards
> --
> Radoslaw Skorupka
> Lodz, Poland
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Command field in TSO/E Logon screen

[גדי בן אבי]

Hi,

The TSO/E logon screen has a field named command.

Where is the data in this field stored between sessions?

It looks like the data in the other fields comes from RACF.

TIA

GAdi

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