Re: IBM C/C++ compiler cost?

[Timothy Sipples]

John,

One major factor that will influence the price is whether the C/C++
compiler is fenced to a zNALC LPAR or not. I'll sketch out for you the two
scenarios so you know the right question(s) to ask your IBM dude or
dudette.

In the "usual" scenario, the price depends on your total z/OS MSUs on your
machine (or in your Sysplex if you have aggregated pricing).  For example,
let's assume you have no zNALC LPARs (and no NALC and no z/OS.e, the older
offerings) and you have five normal z/OS LPARs.  You install and run the
C/C++ compiler in LPARs 2 and 3.  You have a single machine.  In that case
your C/C++ compiler price will be regular price, and it will be equal to
the number of MSUs your sub-capacity report shows for z/OS across all 5
LPARs.  (The C/C++ compiler is not separately reported.  It is considered
an element of the operating system.) I'm assuming sub-capacity VWLC here,
and that you're submitting SCRT reports. Thus, if you set an LPAR group
capacity limit (now available in the newer z/OSes), your total C/C++ price
cannot exceed that group limit. It also cannot exceed the sum total of
individual LPAR limits.

Now let's suppose you have 5 "usual" z/OS LPARs and 2 zNALC z/OS LPARs.
You install and run the C/C++ compiler in 1 zNALC LPAR but not in any of
the "usual" z/OS LPARs.  You still have a single machine.  In that case
your C/C++ compiler price will be the zNALC price -- it's an operating
system element, so it gets that benefit, too.  And the price will be equal
to the number of MSUs your sub-capacity report shows for the total of your
zNALC LPARs.

The Sysplex examples aren't really more complicated.  Just insert
"qualifying aggregated Sysplex" everywhere it says "single machine" above.
I think the minimum number of MSUs is 3 in any of these cases -- unless
it's zero, of course.

So, to oversimplify a bit, the zNALC "domain" is treated much like a
separate machine.  If the workload qualifies, you can license software
separately to that zNALC domain, even on a single machine (or single
Sysplex), and it will be treated separately even if it is something like a
base operating system element that ordinarily wouldn't be.  The same is
true in reverse: products licensed to the regular z/OS LPARs aren't counted
over on the zNALC side if they're not licensed to the zNALC LPARs.

Net net, you'll want to read the zNALC announcement to see if you qualify
-- and if your use of the C/C++ compiler would qualify, in particular.  For
example, if you're porting code currently running on distributed UNIX to
your mainframe using that compiler to do it, then you just might.  Or if
you're considering buying a new vendor application, and that application is
capable of running on distributed UNIX or Windows, but you'd much rather
run that application on your mainframe on z/OS, and you need a C/C++
compiler to support the application, then you might qualify.  If you think
you might qualify, send IBM a completed zNALC questionnaire to find out for
sure.  If you do qualify, you'd then consider whether it makes sense to
carve out another LPAR, which has its own pros and cons.  It may or may not
make sense to do that just for that one compiler, especially if you have a
"small" machine.

OK, now, to answer your question directly (since I've done it before
publicly, so water under the bridge I guess): U.S. commercial use pricing
for 3 MSUs (the minimum) of the IBM C/C++ compiler, with or without Debug,
on zNALC LPAR(s) is ... $6 per month.  So the marketing people might say,
"As low as 19.4 cents per day !!!  Order NOW, and we'll also include 3 MSUs
of Debug Tool, absolutely free(*)!  BUT THAT'S NOT ALL"  Please be
aware that that number could be a LOT different -- even orders of magnitude
different -- depending on your circumstances.  Also, that doesn't include
the base zNALC z/OS charge, although your mileage varies a lot on how you'd
fairly divide that.

(*) Actually, "free" means "no additional charge."  The lawyers make us say
that, because stuff like your time is presumably worth more than zero.
When they say free, they really mean free.  And they never say free.  Even
their pro bono work is "no additional charge."

- - - - -
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: IBMLink, again

[Kevin Keyes]

thanks

Paul [EMAIL PROTECTED] wrote:

My latest update to Record 79232,033,000:

RESPOND ELECTRONICALLY: cp-extent   
Yow!

I attempted to update this by adding a 40-line example  
in C, followed by some comments.  This appears to have  
overstressed IBMLink: Most of my C code is missing; 
the remainder is garbled, and IBM's LAST TWO UPDATES 
ARE ENTIRELY MISSING.  I guess that's OK because I  
really wasn't very happy with what IBM had to say.   

-- gil 


(Summarizing, they said "WAD", of course.  My comments,
which survived, were a courteous (yes!) disagreement
with WAD.)

I had thought it an advantage of IBMLink WWW that I
could so easily cut-and-paste samples, test cases,
and log excerpts.  I guess I should exercise
moderation.  (Unlikely?)

-- gil

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

  


--
Kevin M. Keyes
Director of International Operations
Phoenix Software International
310-338-0400 Ext: 310
[EMAIL PROTECTED]
www.phoenixsoftware.com
www.vikingsoft.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: SVCDUMP processing question

[Jim Mulder]

> Well, I guess it depends on what "unit of work"  means.  If it means
> the TCB or RB, I agree.  If it means the whole address space, then
> I'm not so sure.  But I suspect it *does* mean the TCB or RB.  I had
> not been thinking of it like that.

  In MVS, a unit of work is a TCB or an SRB/SSRB.  But SLIP A=SYNCSVCD
works only with enabled unlocked TCBs. 

  Every SVCDUMP sets the tasks in an address space nondispatchable
while dumping that address space.  But for an asynchronous dump, 
this is asynchronous with repsect to the unit of work which issued
the SDUMP macro.

> Are all SVCDUMPS synchronous? 

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A870/20.1.2?SHELF=EZ2ZO10I&DT=20060620155240

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

--
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: SVCDUMP processing question

[Jim Mulder]

IBM Mainframe Discussion List  wrote on 03/26/2008 
06:14:38 PM:
> Interesting.  I can't find SYNC in the Auth Services Guide or under
> SDUMP/SDUMPX in the Auth Services Macros.  I *can* find a very
> brief description of QUIESCE under SDUMP:
>   Specifies that the system is to be set nondispatchable until the
>contents of the SQA and the CSA are dumped (YES)
> I wish they had said something other than "the system".  I guess
> that means NOTHING is despatched except the dump processing.

  QUIESCE=YES sets all address spaces nondispatchable except those
which have either ASCBXMPT or ASCBPXMT turned on in the ASCB (IHAASCB). 

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

--
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: More SDSF security questions

[Rich Smrcina]

Mark Zelden wrote:

But I see 2 problems:

1) That still won't get you to fall into the ISFOPER group since it
has TSOAUTH(JCL,OPER) and batch only gets TSOAUTH(JCL).  Did you
read my post from yesterday on this?


Yes, I didn't have the ability to respond to all of the emails yesterday 
and I was flying today and struggling with internet access at the hotel 
this afternoon... :(


I posted my NTBL several posts ago.

I saw your post, but the key was in the excellent description from your 
last post.




2) If you create a group with just TSOAUTH(JCL) and ILPROC(BATCH) and
give it "super user" authority, anyone running SDSF in batch will have that
authority.   


I will walk you though this:



That all worked!  My batch job can now see all of the JES jobs.  Thanks 
for the careful guidance, it is greatly appreciated.


Also, thanks to everyone else that responded with assistance.

--
Rich Smrcina
VM Assist, Inc.
Phone: 414-491-6001
Ans Service:  360-715-2467
rich.smrcina at vmassist.com
http://www.linkedin.com/in/richsmrcina

Catch the WAVV!  http://www.wavv.org
WAVV 2008 - Chattanooga - April 18-22, 2008

--
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: SVCDUMP processing question

[Patrick O'Keefe]

On Wed, 26 Mar 2008 19:48:32 -0400, Bob Rutledge <[EMAIL PROTECTED]> wrote:

>...
>> Under SLIP ACTION=SYNCSVCD, it says:
>>
>> "SLIP will stop the unit of work before starting the dump ...
>
>I should have added that, since SYNCSVCD is used (only) with 
>PER traps, ...

Aha!  That explains why I can't find anything comparable to ACTION
other than on SLIP.

>...it can be more than "good for diagnosis".  You really 
>want the work that altered that storage or fetched that unexpected
>instruction to sit still while it's having its picture taken.
>...

Well, I guess it depends on what "unit of work"  means.  If it means
the TCB or RB, I agree.  If it means the whole address space, then
I'm not so sure.  But I suspect it *does* mean the TCB or RB.  I had
not been thinking of it like that.

Today I saw an SVCDUMP that had "SYNC DUMP" in its title and 
wondered what that implied.  It was taken during an ECSA shortage
event where many address spaces locked up.  I was afraid the dumps
were adding to the problem.   (Maybe they were.  Are all SVCDUMPS
synchronous?)  It's probably more likely we still have QUIESCE=YES
somewhere.

BTW, I *DID* need remedial manual reading.  I didn't know that one
BookManager found a reference in a section you then have to switch
to a browser FIND function to find additional references in that 
section.  You don't (or at least *I* don't) get multiple BookManager
search results for multiple hits in the same section.  :-(

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: SVCDUMP processing question

[Bob Rutledge]

Bob Rutledge wrote:

Patrick O'Keefe wrote:

...
Just from the concept of "synchronous" I assume something is suspended 
in SYNCSVCD processing.  And I assume that something

is not as extensive as with QUIESCE=YES.   My gut feeling is "all
processing in the dumped address space" is suspended (which could be 
good for diagnosis but bad for processing) but that's a
guess.  


Under SLIP ACTION=SYNCSVCD, it says:

"SLIP will stop the unit of work before starting the dump to ensure that 
the restart occurs after the dump has completed."


And from this side of the Blue Divide, that's as good as it gets.


I should have added that, since SYNCSVCD is used (only) with PER traps, it can 
be more than "good for diagnosis".  You really want the work that altered that 
storage or fetched that unexpected instruction to sit still while it's having 
its picture taken.


Bob

--
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: SVCDUMP processing question

[Bob Rutledge]

Patrick O'Keefe wrote:
On Wed, 26 Mar 2008 18:42:02 -0400, Bob Rutledge 
<[EMAIL PROTECTED]> wrote:



...

I can find SYNCSVCD under SLIP in an old Commands manual (1.4
I think) but not in our 1.8 manual.  Odd.  ...

No comment.  However...

http://publibz.boulder.ibm.com/cgi-

bin/bookmgr_OS390/BOOKS/IEA2G171/4.52.5.7?
SHELF=EZ2ZO10I&DT=20070123043204&CASE=

...


Ok.  I'm blind.  Or maybe I mistyped my search arg.  
I now see it in multiple syntax diagrams.

And in the z/OS Diagnosis Guide it says the SLIP ACTION can specify
SVCD or SYNCSVCD.  That's nice.  It agrees with the Commands
manual.  But I'm still a bit short on descriptions and explanations.

Just from the concept of "synchronous" I assume something is 
suspended in SYNCSVCD processing.  And I assume that something

is not as extensive as with QUIESCE=YES.   My gut feeling is "all
processing in the dumped address space" is suspended (which 
could be good for diagnosis but bad for processing) but that's a
guess.  


Under SLIP ACTION=SYNCSVCD, it says:

"SLIP will stop the unit of work before starting the dump to ensure that the 
restart occurs after the dump has completed."


And from this side of the Blue Divide, that's as good as it gets.

Bob

--
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: SVCDUMP processing question

[Patrick O'Keefe]

On Wed, 26 Mar 2008 18:42:02 -0400, Bob Rutledge 
<[EMAIL PROTECTED]> wrote:

>...
>> I can find SYNCSVCD under SLIP in an old Commands manual (1.4
>> I think) but not in our 1.8 manual.  Odd.  ...
>
>No comment.  However...
>
>http://publibz.boulder.ibm.com/cgi-
bin/bookmgr_OS390/BOOKS/IEA2G171/4.52.5.7?
SHELF=EZ2ZO10I&DT=20070123043204&CASE=
>...

Ok.  I'm blind.  Or maybe I mistyped my search arg.  
I now see it in multiple syntax diagrams.
And in the z/OS Diagnosis Guide it says the SLIP ACTION can specify
SVCD or SYNCSVCD.  That's nice.  It agrees with the Commands
manual.  But I'm still a bit short on descriptions and explanations.

Just from the concept of "synchronous" I assume something is 
suspended in SYNCSVCD processing.  And I assume that something
is not as extensive as with QUIESCE=YES.   My gut feeling is "all
processing in the dumped address space" is suspended (which 
could be good for diagnosis but bad for processing) but that's a
guess.  

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

IBMLink, again

[Paul [EMAIL PROTECTED]]

My latest update to Record 79232,033,000:

RESPOND ELECTRONICALLY: cp-extent   
Yow!

I attempted to update this by adding a 40-line example  
in C, followed by some comments.  This appears to have  
overstressed IBMLink: Most of my C code is missing; 
the remainder is garbled, and IBM's LAST TWO UPDATES 
ARE ENTIRELY MISSING.  I guess that's OK because I  
really wasn't very happy with what IBM had to say.   

-- gil 

(Summarizing, they said "WAD", of course.  My comments,
which survived, were a courteous (yes!) disagreement
with WAD.)

I had thought it an advantage of IBMLink WWW that I
could so easily cut-and-paste samples, test cases,
and log excerpts.  I guess I should exercise
moderation.  (Unlikely?)

-- gil

--
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: SVCDUMP processing question

[Bob Rutledge]

Patrick O'Keefe wrote:
On Wed, 26 Mar 2008 17:34:26 -0400, Thompson, Steve 
<[EMAIL PROTECTED]> wrote:


...

At least two places to look: MVS Authorized Services Guide and MVS
System Commands discusses the SYNC aspects.

QUIESCE is a new one on me, and I can't find anything for such an 

option

with a dump.
...


Interesting.  I can't find SYNC in the Auth Services Guide or under
SDUMP/SDUMPX in the Auth Services Macros.  I *can* find a very
brief description of QUIESCE under SDUMP:
  Specifies that the system is to be set nondispatchable until the
   contents of the SQA and the CSA are dumped (YES)
I wish they had said something other than "the system".  I guess
that means NOTHING is despatched except the dump processing.

I can find SYNCSVCD under SLIP in an old Commands manual (1.4
I think) but not in our 1.8 manual.  Odd.  SVCD is mentioned so 
I'm pretty sure I didn't get the wrong manual.


Maybe I should extend the remedial training to include manual
reading.


No comment.  However...

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2G171/4.52.5.7?SHELF=EZ2ZO10I&DT=20070123043204&CASE=

Bob

--
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: SVCDUMP processing question

[Patrick O'Keefe]

On Wed, 26 Mar 2008 17:34:26 -0400, Thompson, Steve 
<[EMAIL PROTECTED]> wrote:

...
>At least two places to look: MVS Authorized Services Guide and MVS
>System Commands discusses the SYNC aspects.
>
>QUIESCE is a new one on me, and I can't find anything for such an 
option
>with a dump.
>...

Interesting.  I can't find SYNC in the Auth Services Guide or under
SDUMP/SDUMPX in the Auth Services Macros.  I *can* find a very
brief description of QUIESCE under SDUMP:
  Specifies that the system is to be set nondispatchable until the
   contents of the SQA and the CSA are dumped (YES)
I wish they had said something other than "the system".  I guess
that means NOTHING is despatched except the dump processing.

I can find SYNCSVCD under SLIP in an old Commands manual (1.4
I think) but not in our 1.8 manual.  Odd.  SVCD is mentioned so 
I'm pretty sure I didn't get the wrong manual.

Maybe I should extend the remedial training to include manual
reading.

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

Link for I-Series?

[Thompson, Steve]

Is there an equivalent list server for the AS/400 systems as we have
here with IBM-Main? 

I have this ugly feeling I'm going to need it.

Regards,
Steve Thompson

-- All opinions expressed by me are my own and may not necessarily
reflect those of my employer. --


--
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: SVCDUMP processing question

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Bob Rutledge
Sent: Wednesday, March 26, 2008 4:54 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SVCDUMP processing question

Thompson, Steve wrote:

> QUIESCE is a new one on me, and I can't find anything for such an 
> option with a dump.

Under SDUMP[X]...

,QUIESCE=YES
,QUIESCE=NO
Specifies that the system is to be set nondispatchable until the
contents of the SQA and the CSA are dumped (YES), or that the system is
to be left  dispatchable (NO). If the SDATA parameter does not specify
SQA or CSA, the QUIESCE=YES request is ignored.


You just know that when the day is full of 'rupts, you are going to miss
something. And I missed that one. I was even doing SEARCH with reader
and looking at the INDEX area.

Regards,
Steve Thompson

-- All opinions expressed by me are my own and may not necessarily
reflect those of my employer. --

--
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: SMF System Logger - limitations of MANx

[Scott Barry]

On Wed, 26 Mar 2008 13:36:17 -0700, Skip Robinson 
<[EMAIL PROTECTED]> wrote:

>A comment on duplicate data. I haven't dug into the actual data produced by
>IFASMFDL , but the doc says (in effect) that some duplicate records are
>inevitable (my extrapolation) because the utility begins by dumping the
>entire block that contains START time and continues through dumping the
>entire block that contains END time. Thus some duplicate records are
>unavoidable because on average the start and end time records are most
>likely to fall somewhere within a block.
>
>However, we process data with MXG, which my SMF SME assures me has no
>problem with duplicate data.
>
>.
>.
>JO.Skip Robinson
>Southern California Edison Company
>Electric Dragon Team Paddler
>SHARE MVS Program Co-Manager
>626-302-7535 Office
>323-715-0595 Mobile
>[EMAIL PROTECTED]
>
>
>
> Scott Barry
> <[EMAIL PROTECTED]
> COM>   To
> Sent by: IBM  IBM-MAIN@bama.ua.edu
> Mainframe  cc
> Discussion List
> <[EMAIL PROTECTED] Subject
> .edu> Re: SMF System Logger - limitations
>   of MANx
>
> 03/26/2008 11:02
> AM
>
>
> Please respond to
>   IBM Mainframe
>  Discussion List
> <[EMAIL PROTECTED]
>   .edu>
>
>
>
>
>
>
>On Wed, 26 Mar 2008 09:38:10 -0700, Skip Robinson
><[EMAIL PROTECTED]> wrote:
>
>>We've had occasional episodes of lost data.
>>
>
>
>
>
>Two points for consideration:
>
>1) a possible technique for avoiding SMF data loss (such as SMF 101s or
>116s -- you can decide an approach and types considered non-critical) is to
>
>setup an automation rule that fires when the SYSLOG message occurs,
>stating "SMF is at 75% BUFFERS..." (message IEE986E).  The SET SMF
>command would then enable an alternate SMFPRMxx member deactivating
>some subset of non-critical, large-volume contributor SMF record type(s),
>such as SMF 101s.  At some point, the condition is relieved and the normal
>production SMFPRMxx member would be re-enabled in a similar fashion, or
>after some defined time-period.
>
>2) the issue of duplicate SMF data occurring across IFASMFDL (SMF
>Logstream enabled) dumps (see note #1 below) still does not get addressed,
>without requiring a secondary data-filter pass (and/or sort with
>noduplicates).  Some would say that this duplicate-data condition is
>unacceptable, given the extra data handling required.  And it doesn't have
>to
>be linked to any accounting/chargeback scenario, either.
>
>
>Scott Barry
>SBBWorks, Inc.
>_
>
>Note #1:  most concerning is intraday dumping, for example, using CA MICS
>Incremental Database Update feature -- although MICS will reject any data
>already processed.
>
>Links:
>
>BUFSIZMAX, BUFUSEWARN, and NOBUFFS - Specifying SMF buffer options
>(mind any broken URL):
>http://publib.boulder.ibm.com/infocenter/zos/v1r9/topic/com.ibm.zos.r9.ieag2
0
>
>0/buffopt.htm
>
>--
>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 MXG data sources such as CICS, DB2, IMS (large-volume candidates and 
out-of-the-box MXG), there is no SORT NODUP operation performed during 
PDB build processing to remove adjacent duplicate records -- these PDB files 
are typically copied directly to their final destination, normally tape due to 
volume.  Also, PDB build processing does not provide a check for "prior input 
data already processed - this record rejected".  I do realize that SMF record 
types have header timestamps only granular to 1/100 of a second -- another 
challenge exacerbated by SMF System Logger deployment, because, again, 
dumping a MANx file represented a finite start and end point as compared to 
the SMF Syste Logger architecture providing a continuous data-pipe.

Sincerely,

Scott Barry
SBBWorks, Inc.

--
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: SVCDUMP processing question

[Bob Rutledge]

Thompson, Steve wrote:

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Patrick O'Keefe
Sent: Wednesday, March 26, 2008 3:23 PM
To: IBM-MAIN@bama.ua.edu
Subject: SVCDUMP processing question

I need remedial training in MVS disagnostic techniques.  :-(

I seem to have combined the concepts of QUIESCE yes/no and SYNCH /
ASYNCH.  I sort of understand that QUIESCE=YES protects common storage
during dump capture by limiting the dispatching of other address spaces
(and probably have the details horribly 
wrong).   What does SYNCSVCD do?  Something similar with multiple 
taks within a single address space?


I know QUIESCE=YES has caused us all kinds of performance problems in
the past so we gone to NO everywhere we could find the option.  However,
we still are getting synchronous SVC dumps taken.  I'm not sure we even
have the option of setting that except for SLIP dumps.  Is that a
problem?


At least two places to look: MVS Authorized Services Guide and MVS
System Commands discusses the SYNC aspects.

QUIESCE is a new one on me, and I can't find anything for such an option
with a dump.


Under SDUMP[X]...

,QUIESCE=YES
,QUIESCE=NO
Specifies that the system is to be set nondispatchable until the contents of the 
SQA and the CSA are dumped (YES), or that the system is to be left  dispatchable 
(NO). If the SDATA parameter does not specify SQA or CSA, the QUIESCE=YES 
request is ignored.


Bob

--
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: Displaying multiple volumes allocated from DSLIST

[Greg Shirey]

According to this (somewhat old) redbook, the same amount of space is
used.
http://www.redbooks.ibm.com/redbooks/pdfs/sg246979.pdf

>From the "SMS enhancements" chapter: 
"If a data set, with one primary and five candidate volumes was in a
data class with a DVC of less than 7, then 24 bytes of TIOT space is
required. If the same data set was using a data class with a DVC of 20,
then it would require 80 bytes of TIOT space."

It also says this:
"Note: DVC for VSAM striped data sets is supported even though they are
not eligible for Space Constraint Relief."

Is that more or less confusing?  :-)

Greg Shirey
Ben E. Keith Company

-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Mark Zelden
Sent: Wednesday, March 26, 2008 4:14 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Displaying multiple volumes allocated from DSLIST


It does cost.  It takes space in the TIOT.  IIRC, 4 bytes for each
candidate. 
Depending on how many DDs are in a step and the TIOT size defined in
ALLOCxx this could cause a problem.  It also can have an effect on
catalog
space requirements.In z/OS 1.3 IBM came up with  DVC (Dynamic
Volume Count) which only stores the volumes specified / used in the 
catalog.  I'm not clear if it still takes up the same amount of space in
the TIOT - I would have to research that.

But now I am a little confused... the z/OS 1.6 manual that I opened up
just
said that DVC is  "a feature supported only for multi-striped VSAM data
sets"
and had the "changed bar" (|) next to it.

I am leaving for the day so someone perhaps can shed some light on 
this and I'll follow up tomorrow.

--
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: SVCDUMP processing question

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Patrick O'Keefe
Sent: Wednesday, March 26, 2008 3:23 PM
To: IBM-MAIN@bama.ua.edu
Subject: SVCDUMP processing question

I need remedial training in MVS disagnostic techniques.  :-(

I seem to have combined the concepts of QUIESCE yes/no and SYNCH /
ASYNCH.  I sort of understand that QUIESCE=YES protects common storage
during dump capture by limiting the dispatching of other address spaces
(and probably have the details horribly 
wrong).   What does SYNCSVCD do?  Something similar with multiple 
taks within a single address space?

I know QUIESCE=YES has caused us all kinds of performance problems in
the past so we gone to NO everywhere we could find the option.  However,
we still are getting synchronous SVC dumps taken.  I'm not sure we even
have the option of setting that except for SLIP dumps.  Is that a
problem?


At least two places to look: MVS Authorized Services Guide and MVS
System Commands discusses the SYNC aspects.

QUIESCE is a new one on me, and I can't find anything for such an option
with a dump.

Regards,
Steve Thompson

-- All opinions expressed by me are my own and may not necessarily
reflect those of my employer. --

--
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: Displaying multiple volumes allocated from DSLIST

[Gilbert Cardenas]

On Wed, 26 Mar 2008 16:14:21 -0500, Mark Zelden 
<[EMAIL PROTECTED]> wrote:

>On Wed, 26 Mar 2008 21:38:09 +, Ted MacNEIL 
<[EMAIL PROTECTED]> wrote:
>
>>>It's just showing that you have 2 additional candidate volumes allocated.
>They have not yet been assigned.
>>
>>It's a control block thing.
>>It doesn't cost anything; it can protect you from future growth problems.
>>
>>The last two shops I worked at had 20 volumes allocated in most 
dataclasses.
>>I would recommend the 59 vol max.
>>It doesn't cost; it can save.
>>Especially, since only the secondary allocation size is 'remembered' on all
>future volumes.
>>
>
>It does cost.  It takes space in the TIOT.  IIRC, 4 bytes for each candidate.
>Depending on how many DDs are in a step and the TIOT size defined in
>ALLOCxx this could cause a problem.  It also can have an effect on catalog
>space requirements.In z/OS 1.3 IBM came up with  DVC (Dynamic
>Volume Count) which only stores the volumes specified / used in the
>catalog.  I'm not clear if it still takes up the same amount of space in
>the TIOT - I would have to research that.
>
>But now I am a little confused... the z/OS 1.6 manual that I opened up just
>said that DVC is  "a feature supported only for multi-striped VSAM data sets"
>and had the "changed bar" (|) next to it.
>
>I am leaving for the day so someone perhaps can shed some light on
>this and I'll follow up tomorrow.
>
>Mark
>--
>Mark Zelden
>Sr. Software and Systems Architect - z/OS Team Lead
>Zurich North America / Farmers Insurance Group - ZFUS G-ITO
>mailto:[EMAIL PROTECTED]
>z/OS Systems Programming expert at 
http://expertanswercenter.techtarget.com/
>Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
>
>--


Thank you all for all the good information.  BTW, we are on z./OS 1.7 going to 
1.9 soon.   I had forgotten that I was also using the following attributes for 
this dataclas:

Space Constraint Relief . . . Y 
  Reduce Space Up To (%)  . . 50
  Dynamic Volume Count  . . . 5 

I am not really having any issues with any of the allocations, I was just 
curious why some datasets listed as multi-volume datasets did not show the 
additional volumes but now it kind of makes sense.

Thanks again,
Gil.

--
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: Displaying multiple volumes allocated from DSLIST

[Mark Zelden]

On Wed, 26 Mar 2008 21:38:09 +, Ted MacNEIL <[EMAIL PROTECTED]> wrote:

>>It's just showing that you have 2 additional candidate volumes allocated.
They have not yet been assigned.
>
>It's a control block thing.
>It doesn't cost anything; it can protect you from future growth problems.
>
>The last two shops I worked at had 20 volumes allocated in most dataclasses.
>I would recommend the 59 vol max.
>It doesn't cost; it can save.
>Especially, since only the secondary allocation size is 'remembered' on all
future volumes.
>

It does cost.  It takes space in the TIOT.  IIRC, 4 bytes for each candidate. 
Depending on how many DDs are in a step and the TIOT size defined in
ALLOCxx this could cause a problem.  It also can have an effect on catalog
space requirements.In z/OS 1.3 IBM came up with  DVC (Dynamic
Volume Count) which only stores the volumes specified / used in the 
catalog.  I'm not clear if it still takes up the same amount of space in
the TIOT - I would have to research that.

But now I am a little confused... the z/OS 1.6 manual that I opened up just
said that DVC is  "a feature supported only for multi-striped VSAM data sets"
and had the "changed bar" (|) next to it.

I am leaving for the day so someone perhaps can shed some light on 
this and I'll follow up tomorrow.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
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: Displaying multiple volumes allocated from DSLIST

[Blaicher, Chris]

A small caveat for your recommendation of 59 volumes.

It does cost something to have 59 volumes for everything.  It greatly
reduces the total number of data sets you can have in your JCL.  If all
data sets only have a single DD you can have 3,273 DD's.  If all data
sets are defined with 59 volumes the limit drops to 259 DD's.  This is
if you specify TIOT SIZE(64) in the ALLOCxx member.  If you specify a
smaller SIZE the numbers go down proportionally.

DB2 utilities being used on a partitioned object can require a
significant number of DD's for optimum performance.

Chris Blaicher
BMC Software, Inc.

The opinions expressed are mine, not BMC's.

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ted MacNEIL
Sent: Wednesday, March 26, 2008 4:38 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Displaying multiple volumes allocated from DSLIST

>It's just showing that you have 2 additional candidate volumes
allocated. They have not yet been assigned. 

It's a control block thing.
It doesn't cost anything; it can protect you from future growth
problems.

The last two shops I worked at had 20 volumes allocated in most
dataclasses.
I would recommend the 59 vol max.
It doesn't cost; it can save.
Especially, since only the secondary allocation size is 'remembered' on
all future volumes.

-
Too busy driving to stop for gas!

--
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: z/OS 1.4 to 1.7 upgrade differences question

[Pommier, Rex R.]

Mark,

I'll open a PMR on 1.7.  I just wanted to know if it was a documented
change that I had somehow missed before opening a PMR.

Thanks.


Rex 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Mark Zelden
Sent: Wednesday, March 26, 2008 2:23 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/OS 1.4 to 1.7 upgrade differences question

On Wed, 26 Mar 2008 15:13:16 -0400, Daniel McLaughlin
<[EMAIL PROTECTED]> wrote:

>Since we're talking 1.4 to 1.7 will IBM do that?
>
>Just curious.
>

>>
>> Hmmm.. It appears that panel ISRUAIES is being used instead of 
>> ISRUAIP for non-sms flat files.  I've confirmed the same behavior on 
>> z/OS 1.8
>and
>> z/OS 1.9.   I have a 1.6 system left and it looks correct.   This
should
>> be APAR-able.  Open a PMR with IBM ISPF support.
>>

Assuming it is not intentional for some reason (panel ISRUAIP still
exists in hlq.SISPPENU) they should if the customer pushes for it.  z/OS
1.7 doesn't
hit EOS (end of service) until September 2008.   But there could be a
reason
that IBM decided they always should use panel ISRUAIES.  I just can't
imagine what that reason could be.

Mark

--
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: Displaying multiple volumes allocated from DSLIST

[Ted MacNEIL]

>It's just showing that you have 2 additional candidate volumes allocated. They 
>have not yet been assigned. 

It's a control block thing.
It doesn't cost anything; it can protect you from future growth problems.

The last two shops I worked at had 20 volumes allocated in most dataclasses.
I would recommend the 59 vol max.
It doesn't cost; it can save.
Especially, since only the secondary allocation size is 'remembered' on all 
future volumes.

-
Too busy driving to stop for gas!

--
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: SMF System Logger - limitations of MANx

[Skip Robinson]

A comment on duplicate data. I haven't dug into the actual data produced by
IFASMFDL , but the doc says (in effect) that some duplicate records are
inevitable (my extrapolation) because the utility begins by dumping the
entire block that contains START time and continues through dumping the
entire block that contains END time. Thus some duplicate records are
unavoidable because on average the start and end time records are most
likely to fall somewhere within a block.

However, we process data with MXG, which my SMF SME assures me has no
problem with duplicate data.

.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[EMAIL PROTECTED]


   
 Scott Barry   
 <[EMAIL PROTECTED] 
 COM>   To 
 Sent by: IBM  IBM-MAIN@bama.ua.edu
 Mainframe  cc 
 Discussion List   
 <[EMAIL PROTECTED] Subject 
 .edu> Re: SMF System Logger - limitations 
   of MANx 
   
 03/26/2008 11:02  
 AM
   
   
 Please respond to 
   IBM Mainframe   
  Discussion List  
 <[EMAIL PROTECTED] 
   .edu>   
   
   




On Wed, 26 Mar 2008 09:38:10 -0700, Skip Robinson
<[EMAIL PROTECTED]> wrote:

>We've had occasional episodes of lost data.
>




Two points for consideration:

1) a possible technique for avoiding SMF data loss (such as SMF 101s or
116s -- you can decide an approach and types considered non-critical) is to

setup an automation rule that fires when the SYSLOG message occurs,
stating "SMF is at 75% BUFFERS..." (message IEE986E).  The SET SMF
command would then enable an alternate SMFPRMxx member deactivating
some subset of non-critical, large-volume contributor SMF record type(s),
such as SMF 101s.  At some point, the condition is relieved and the normal
production SMFPRMxx member would be re-enabled in a similar fashion, or
after some defined time-period.

2) the issue of duplicate SMF data occurring across IFASMFDL (SMF
Logstream enabled) dumps (see note #1 below) still does not get addressed,
without requiring a secondary data-filter pass (and/or sort with
noduplicates).  Some would say that this duplicate-data condition is
unacceptable, given the extra data handling required.  And it doesn't have
to
be linked to any accounting/chargeback scenario, either.


Scott Barry
SBBWorks, Inc.
_

Note #1:  most concerning is intraday dumping, for example, using CA MICS
Incremental Database Update feature -- although MICS will reject any data
already processed.

Links:

BUFSIZMAX, BUFUSEWARN, and NOBUFFS - Specifying SMF buffer options
(mind any broken URL):
http://publib.boulder.ibm.com/infocenter/zos/v1r9/topic/com.ibm.zos.r9.ieag20

0/buffopt.htm

--
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: JES2 NJE question: SNA(CTC) vs. TCPIP

[Patrick O'Keefe]

On Wed, 26 Mar 2008 11:44:05 -0400, Mark Pace 
<[EMAIL PROTECTED]> wrote:

>The difference is outbound vs inbound port numbers.  Outbound port 
numbers
>are almost always different and nothing to be concerned about.
>...

More specifically, the end making the connection (the end acting as
a "client") points to a specific address and port on the "server".
Unless the client has a need to use a specific source port its local
TCP/IP stack will allocate a random, unreserved port above 1024.
(I probably mean "above 1023".  You can look it up if you care.)

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

SVCDUMP processing question

[Patrick O'Keefe]

I need remedial training in MVS disagnostic techniques.  :-(

I seem to have combined the concepts of QUIESCE yes/no and
SYNCH / ASYNCH.  I sort of understand that QUIESCE=YES protects
common storage during dump capture by limiting the dispatching
of other address spaces (and probably have the details horribly 
wrong).   What does SYNCSVCD do?  Something similar with multiple 
taks within a single address space?

I know QUIESCE=YES has caused us all kinds of performance 
problems in the past so we gone to NO everywhere we could find
the option.  However, we still are getting synchronous SVC dumps
taken.  I'm not sure we even have the option of setting that except
for SLIP dumps.  Is that a problem?

Sorry if this is a bonehead question.
If it rates an RTFM, please point me to the FM.

Thank you.

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: Displaying multiple volumes allocated from DSLIST

[Raymond Noal]

Gilbert,

The display you are seeing for the data set's volume list is due to the fact 
that the data set is SMS managed. The "*" in the display of volumes indicates 
that SMS had additional volumes in its candidate list when the data set was 
allocated. The data set was only allocated on one volume - TMM829. This is 
normal for SMS allocated data sets.

HITACHI
 DATA SYSTEMS 
Raymond E. Noal 
Senior Technical Engineer 
Office: (408) 970 - 7978 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of 
Gilbert Cardenas
Sent: Wednesday, March 26, 2008 8:31 AM
To: IBM-MAIN@bama.ua.edu
Subject: Displaying multiple volumes allocated from DSLIST

When a dataset has multiple volumes allocated for example :

Command - Enter "/" to select action  Message   Volume 
---
 TAPEX.SMFCICS.DATA ?? 
 TAPEX.SMFCICS.DATA.G1506V00   TMM829+

And I select the dataset to view the attributes, there is a message that says:
To display multiple volumes press Enter or enter Cancel to Exit.
If I press enter all I get is the following:

All allocated volumes:  
More: + 
 Number of volumes allocated: 3 

 TMM829  *   *  

Is there anyway to tell what the other volumes are?

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

IBM C/C++ compiler cost?

[McKown, John]

Can anybody here tell me what the license fee is for the IBM C/C++
compiler? We had it at one time, but the last dying gasp of our previous
manager killed it in a vain attempt to keep his job (he eliminated a lot
of so-called "waste" to prove he was effective). I would like it back,
although to be honest, there is no real business need for it.

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

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
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

Re: z/OS 1.4 to 1.7 upgrade differences question

[Mark Zelden]

On Wed, 26 Mar 2008 15:13:16 -0400, Daniel McLaughlin
<[EMAIL PROTECTED]> wrote:

>Since we're talking 1.4 to 1.7 will IBM do that?
>
>Just curious.
>

>>
>> Hmmm.. It appears that panel ISRUAIES is being used instead of ISRUAIP
>> for non-sms flat files.  I've confirmed the same behavior on z/OS 1.8
>and
>> z/OS 1.9.   I have a 1.6 system left and it looks correct.   This should
>> be APAR-able.  Open a PMR with IBM ISPF support.
>>

Assuming it is not intentional for some reason (panel ISRUAIP still exists
in hlq.SISPPENU) they should if the customer pushes for it.  z/OS 1.7 doesn't
hit EOS (end of service) until September 2008.   But there could be a reason
that IBM decided they always should use panel ISRUAIES.  I just can't 
imagine what that reason could be.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
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: More SDSF security questions

[Schwarz, Barry A]

Your TSO session is in group ISFOPER.  Your batch job is in group
ISFUSER.  If the names are truly descriptive, one defines an operator
who should be able to see almost everything and the other a user who is
restricted to his own efforts.

-Original Message-
From: Rich Smrcina 
Sent: Tuesday, March 25, 2008 1:20 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: More SDSF security questions

In TSO, I get this from the WHO command on the P390 user:

USERID=P390,PROC=DBSPROC,TERMINAL=LCL701,GRPINDEX=2,GRPNAME=ISFOPER,
MVS=z/OS 01.04.00,JES2=z/OS 1.4,SDSF=HQX7707,ISPF=5.2,RMF/DA=NOTACC,

and from batch:

USERID=P390,PROC=BATCH,TERMINAL=BATCH,GRPINDEX=3,GRPNAME=ISFUSER,MVS=z/O
S
01.04
RMF/DA=NOTACC,SERVER=YES,SERVERNAME=SDSF,JESNAME=JES2,MEMBER=SYS1,SYSNAM
E=P390,

I tried a jobname of P390A and I still can only see the job that I'm
running.

--
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: z/OS 1.4 to 1.7 upgrade differences question

[Daniel McLaughlin]

Since we're talking 1.4 to 1.7 will IBM do that?

Just curious.

Daniel McLaughlin
Z-Series Systems Programmer
Information & Communications Technology
Crawford & Company
4680 N. Royal Atlanta
Tucker GA 30084 
phone: 770-621-3256 
fax: 770-621-3237
email: [EMAIL PROTECTED]
web: www.crawfordandcompany.com 



IBM Mainframe Discussion List  wrote on 03/26/2008 
03:09:17 PM:

> -- Information from the mail header 
> ---
> Sender:   IBM Mainframe Discussion List 
> Poster:   Mark Zelden <[EMAIL PROTECTED]>
> Subject:  Re: z/OS 1.4 to 1.7 upgrade differences question
> 
---
> 
> On Wed, 26 Mar 2008 13:08:07 -0500, Pommier, Rex R.
> <[EMAIL PROTECTED]> wrote:
> 
> 
> 
> >The question that I have is that once the dataset has been created 
under
> >1.7, looking at it under ISPF 3.4, it looks like this - notice the SMS
> >management class, etc:
> >
> 
> 
> 
> Hmmm.. It appears that panel ISRUAIES is being used instead of ISRUAIP
> for non-sms flat files.  I've confirmed the same behavior on z/OS 1.8 
and
> z/OS 1.9.   I have a 1.6 system left and it looks correct.   This should
> be APAR-able.  Open a PMR with IBM ISPF support.
> 
> Mark
> --
> Mark Zelden
> Sr. Software and Systems Architect - z/OS Team Lead
> Zurich North America / Farmers Insurance Group - ZFUS G-ITO
> mailto:[EMAIL PROTECTED]
> z/OS Systems Programming expert at 
http://expertanswercenter.techtarget.com/
> 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
> 



Best Overall Third-Party Claims Administrator - 2007 "Business Insurance" 
Readers Choice Awards
 
Consider the environment before printing this message.

This transmission is intended exclusively for the individual or entity to which 
it is addressed. This communication may contain information that is 
confidential, proprietary, privileged or otherwise exempt from disclosure. If 
you are not the named addressee, you are NOT authorized to read, print, retain, 
copy or disseminate this communication, its attachments or any part of them. If 
you have received this communication in error, please notify the sender 
immediately and delete this communication from all computers.  This 
communication does not form any contractual obligation on behalf of the sender, 
the sender's employer, or the employer's parent company, affiliates or 
subsidiaries.

--
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: z/OS 1.4 to 1.7 upgrade differences question

[Mark Zelden]

On Wed, 26 Mar 2008 13:08:07 -0500, Pommier, Rex R.
<[EMAIL PROTECTED]> wrote:



>The question that I have is that once the dataset has been created under
>1.7, looking at it under ISPF 3.4, it looks like this - notice the SMS
>management class, etc:
>



Hmmm.. It appears that panel ISRUAIES is being used instead of ISRUAIP
for non-sms flat files.  I've confirmed the same behavior on z/OS 1.8 and
z/OS 1.9.   I have a 1.6 system left and it looks correct.   This should
be APAR-able.  Open a PMR with IBM ISPF support.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
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: z9 BC Hardware Upgrade

[Brian France]

Matt,
 At the end of October we did just what you're doing. No 
problems putting in on the existing OS on the existing frame. As far 
as I know, and I've done this several times before, that PSP maint is 
not a problem to go on ahead to time as unless you're actually 
running the machine that uses it, the code just sits there. A lot of 
the PTF's are for HCD to gen ahead.


At 02:46 PM 3/26/2008, you wrote:

Well, you COULD just put it on and see if it IPLs.

But FWIW, we did the same thing a little over a year ago.  I'm 
pretty sure we were at 1.4 and there was considerably more service 
than 3 PTFs.  Ran on the z890 just fine.




 -Original Message-
From:   IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] 
On Behalf Of Matt Dazzo

Sent:   Wednesday, March 26, 2008 1:32 PM
To: IBM-MAIN@bama.ua.edu
Subject:z9 BC Hardware Upgrade

We maybe moving from a z890 to a z9 BC machine. We are running 
zos1.7 at RSU0709 maintenance level. I checked the hardware bucket 
for the z9-bc and ran the extract file through the host compare 
program and found only 3 PTF's required. My question is how do I 
determine if these PTF's can coexist on both machines? There seems 
to be no coexistence information in the PTF.


Thanks Matt

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



Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Administrative Information Services - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
[EMAIL PROTECTED]

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan





--
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: Displaying multiple volumes allocated from DSLIST

[Ted MacNEIL]

>That's kind of what I was thinking but I thought it was kind of weird because 
>the file has been closed so why would it hold on to the additional volume 
allocations especially if they weren't used.

So you can expand to those volumes if the dataset were to grow.

-
Too busy driving to stop for gas!

--
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: z9 BC Hardware Upgrade

[Miller, Pat]

Well, you COULD just put it on and see if it IPLs.

But FWIW, we did the same thing a little over a year ago.  I'm pretty sure we 
were at 1.4 and there was considerably more service than 3 PTFs.  Ran on the 
z890 just fine.



 -Original Message-
From:   IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]  On Behalf Of 
Matt Dazzo
Sent:   Wednesday, March 26, 2008 1:32 PM
To: IBM-MAIN@bama.ua.edu
Subject:z9 BC Hardware Upgrade

We maybe moving from a z890 to a z9 BC machine. We are running zos1.7 at 
RSU0709 maintenance level. I checked the hardware bucket for the z9-bc and ran 
the extract file through the host compare program and found only 3 PTF's 
required. My question is how do I determine if these PTF's can coexist on both 
machines? There seems to be no coexistence information in the PTF.   
 
Thanks Matt

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

z9 BC Hardware Upgrade

[Matt Dazzo]

We maybe moving from a z890 to a z9 BC machine. We are running zos1.7 at 
RSU0709 maintenance level. I checked the hardware bucket for the z9-bc and ran 
the extract file through the host compare program and found only 3 PTF's 
required. My question is how do I determine if these PTF's can coexist on both 
machines? There seems to be no coexistence information in the PTF.   
 
Thanks Matt

--
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: Import Connect:Direct self-signed certificate into RACF?

[Rob Schramm]

You might review a presentation by Wai Choi. It does a nice job of 
explaining what is needed for certificate verification server and client.

ftp://ftp.software.ibm.com/eserver/zseries/zos/racf/pdf/r05_racf_digital_certificate.pdf

Sometimes just keeping all the certificate "who's signing who" straight is 
helpful when trying to solve these types of problems.

Rob Schramm
Sirius Computer Solutions




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

z/OS 1.4 to 1.7 upgrade differences question

[Pommier, Rex R.]

Hi list.

I have a question (probably rather picky) going from z/OS 1.4 to 1.7.
During testing of the 1.7 upgrade, I had an applications programmer run
a batch COBOL/IDMS job that created and cataloged a new non-SMS dataset.
The JCL is shown below - quite straightforward, and the dataset ends up
on a non-SMS pack as expected.

//AGCYPROD EXEC PGM=AGCYPROD,REGION=0K  
//STEPLIB  DD DSN=MVS.CN6.LOADLIB,DISP=SHR  
// DD DSN=WSC.PROD.LOADLIB,DISP=SHR 
// DD DSN=IDMS.PROD.LOADLIB,DISP=SHR
//SYSLST   DD SYSOUT=*  
//SYSCTL   DD DSN=IDMS.SQL.SYSCTL,DISP=SHR  
//SYSIDMS  DD DSN=MVS.PROD.SKELETON(WSCPROD),DISP=SHR   
//SYSOUT   DD SYSOUT=*  
//SYSDBOUT DD SYSOUT=*  
//SYSUDUMP DD SYSOUT=D  
//OUTPUT   DD  DSN=MVS.CN6.AGENCY7, 
// DISP=(NEW,CATLG,DELETE), 
// UNIT=SYSDA,  
// DCB=(RECFM=FB,LRECL=110),
// SPACE=(CYL,(20,10),RLSE) 

The question that I have is that once the dataset has been created under
1.7, looking at it under ISPF 3.4, it looks like this - notice the SMS
management class, etc:

Data Set Name . . . . : MVS.CN6.AGENCY7

 

General DataCurrent Allocation

Management class . . :  **None**Allocated
cylinders : 2 
Storage class  . . . :  **None**Allocated
extents . : 1 
Volume serial . . . :   WSC003

Device type . . . . :   3390

Data class . . . . . :  **None**Current
Utilization  
Organization  . . . :   PS  Used cylinders
. . :   2 
Record format . . . :   FB  Used extents  .
. . :   1 
Record length . . . :   110

Block size  . . . . :   27940

1st extent cylinders:   2

Secondary cylinders :   10

Data set name type  :   SMS Compressible
:   NO   
 

Creation date . . . :   2008/03/26  Referenced date
. . :   2008/03/26 
  Expiration date . . : ***None***


When he runs the same JCL on a 1.4 system, the output from ISPF 3.4
looks like this - notice, no SMS information:

Data Set Name  . . . :  MVS.CN6.AGENCY7 
 

General DataCurrent Allocation

Volume serial . . . :   WSC001Allocated
cylinders : 2 
Device type . . . . :   3390Allocated
extents . : 1 
Organization  . . . :   PS

Record format . . . :   FB

Record length . . . :   110

Block size  . . . . :   27940   Current
Utilization  
1st extent cylinders:   2   Used cylinders
. . :   2 
Secondary cylinders :   10  Used extents  .
. . :   1 
 

Creation date . . . :   2008/03/25

Referenced date . . :   2008/03/25

 Expiration date . . :  ***None***  

As a control test, I allocated the same dataset on the 1.7 system using
ISPF 3.2 and it showed up without the SMS lines in the ISPF output.

I tried unsuccessfully to find some documentation that would explain the
difference between the 1.4 and 1.7 system.  Any ideas as to why the
dataset allocated with the batch JCL would show up differently under 1.7
versus 1.4?

Thanks.

Rex

--
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: SMF System Logger - limitations of MANx

[Scott Barry]

On Wed, 26 Mar 2008 09:38:10 -0700, Skip Robinson 
<[EMAIL PROTECTED]> wrote:

>We've had occasional episodes of lost data.
>
>One case, which we think we've fixed via changes to automation, is the
>other side of the event-driven nature of MANx management. A strength of
>traditional SMF recording is that you dump and clear a MANx cluster in
>response to a message saying that it needs dumping. That's why you don't
>have to worry much about whether you've collected ten hours or ten minutes
>worth of data. You dump whatever's there, clear the file, and move on. A
>problem crops up when you IPL with all defined SMF data sets in need of
>dumping. They're not necessarily 'full'; they just can't be opened because,
>well, who knows why. I've seen MANx data sets at 1% that nonetheless
>require dumping. Go figure. But if all MANx data sets are full at IPL, data
>starts getting buffered. In our shop, the messages that should trigger
>dumping come out before our automation product has hit the ground. Our
>so-far-untested automation change is to trigger a dump when buffering has
>reached a certain threshold. Without that additional check, you can lose
>data when you run out of buffers.
>
>Another case is harder to deal with. We dump straight to tape. Once in a
>while we have an extended tape outage for hardware or software 
maintenance.
>Of course we could code for this situation by writing first to DASD, then
>to tape. Heck, we could write a whole subsystem. Ad infinitum.
>
>System Logger in principle handles all these cases by its nature. As SMF
>records flow, Logger captures them and writes them to DASD. A new offload
>data set is allocated as often as necessary: once a day or once a minute.
>The full-at-IPL condition simply goes away. Logger never gets full. If tape
>is unavailable for some period of time, records simply accumulate until a
>dump job can eventually be run.
>
>The worst fallout of SMF data loss is that all records are treated alike.
>It's simple FIFO, records you need, records you might like to have, records
>that may or may not prove crucial down the road. You capture them all until
>recording is impaired, then you lose everything. The current complexity of
>managing Logger offload data is presumably temporary, although no relief
>has actually been announced. Given the well known historical problems with
>MANx data sets, I still think Logger is worth the effort today.
>
>.
>.
>JO.Skip Robinson
>Southern California Edison Company
>Electric Dragon Team Paddler
>SHARE MVS Program Co-Manager
>626-302-7535 Office
>323-715-0595 Mobile
>[EMAIL PROTECTED]
>
>
>
> "Vernooy, C.P. -
> SPLXM"
> <[EMAIL PROTECTED]  To
> .COM> IBM-MAIN@bama.ua.edu
> Sent by: IBM   cc
> Mainframe
> Discussion List   Subject
> <[EMAIL PROTECTED] Re: SMF System Logger - limitations
> .edu> of MANx
>
>
> 03/26/2008 12:44
> AM
>
>
> Please respond to
>   IBM Mainframe
>  Discussion List
> <[EMAIL PROTECTED]
>   .edu>
>
>
>
>
>
>
>"R.S." <[EMAIL PROTECTED]> wrote in message
>news:<[EMAIL PROTECTED]>...
>> Mark Zelden wrote:
>> [...]
>> > As mentioned... lots in the archives about this (even before the
>recent
>> > threads).
>> >
>> > 1) Speed of offloading (being able to keep up with records being
>written).
>> IMHO I can live with it (YMMV). In case of SMF (expected & accepted)
>> flood I can use more MANx datasets as a spill.
>
>This is not the solution: I have seen occasions where records are
>presented to SMF faster that SMF can write them to MANx. This will cause
>SMF to run out of buffers with records lost as a consequence.
>
>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


Two points for consideration:

1) a possible technique for avoiding SMF data loss (such as SMF 101s or 
116s -- you can decide an approach and types considered non-critical) is to 
setup an automation rule that fires when the SYSLOG message occurs, 
stating "SMF is at 75% BUFFERS..." (message IEE986E).  The SET SMF 
command would then enable an alternate SMFPRMxx member deactivating 
some subset of non-critical, large-volume contributor SMF record type(s), 
such as SMF 101s.  At some point, the condition is relieved and the normal 
production SMFPRMxx member would be re-enabled in a similar fashion, or 
after some defined time-period.

2) the issue of duplicate SMF data occurring across IFASMFDL (SMF 
Logstream enabled) dumps (see note #1 below) still does not get addressed

Re: Long translate (TR) instruction?

[William H. Blair]

Kirk Wolf said:

> I'm looking for the fastest way in assembler to 
> translate data in one buffer to another using a 
> 256-byte translate table.

Want my test program to help you decide? Let me know.
But don't waste your time. I already know the answer.

Look at my TR subroutine in a previous post as a place
to get started (if you need that).

Shmuel Metz (Seymour J.) said:

> The fastest way on one model may not be the fastest 
> way on another model.

True.  But -- I just knew you were expecting a but -- I
have been looking at this off and on for about 8 years,
and have had access to most (if not all) models of zXXX
hardware (currently I have access to a 2094, 2096, 2086
and a 2066). I have NEVER found an instruction sequence
that would run faster than a simple old-fashioned TR[T] 
(or MVC or CLC) loop on ANY z model machine - except an 
MVCL or CLCL for a "very large" number of bytes.  Since
very little code like this is on a performance-critical
path, I mostly just use whatever is convenient; in such
a case it does not really matter. If I believe the code
is on a performance-critical path I'll use a subroutine
that does it the old-fashioned way (TR/TRT/CLC/MVC loop
or whatever), unless I have special knowledge that lots
of bytes (more than 4KB) need to be MVCed/CLCed.  Thus,
if Mr. Wolf currently has a z box (Duh!) I can tell him
that the answer to that question -- TODAY -- is just do
an old-fashioned MVC loop (or an MVCL) to move the data
to the buffer where one will need it after translation, 
and then use an old-fashioned TR loop to actually do it
in that (output) buffer. On any z box that exists today
that is the fastest way. And I bet it stays that way in
the future, probably forever. Why? There is very little
that microcode/millicode can do faster than the current
raw, basic machine can do with these fundamental S/360-
era instructions. The same basic internal operations to
get the job done have to be done in each instance so it
does not matter whether the orders are coming from code
or millicode/microcode. Now, if the machine offered the
TR[T]L instructions, then probably -- just as it is the
case for MVCL and CLCL -- those would run just a little
faster than an old-fashioned basic TR[T] loop, but only
for large numbers of bytes. But we don't have TR[T]L so 
the System/360 instructions are still the fastest way. 

--
WB

--
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: Is IT becoming extinct?

[Howard Brazee]

On 26 Mar 2008 10:22:03 -0700, [EMAIL PROTECTED] (R.S.)
wrote:

>BTW: COBOL has serious disadvantages.
>(and the war began...)

Every tool has serious disadvantages - because no tool is all things
for all people.

It's not about the language though.  IS is about the data.We need
to make sure we have the right data accessible to the right people -
but not accessible to the wrong people.   

Often this is facilitated by having a big box database with lots of
rules in it.But what languages we use really doesn't matter.

--
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: Enhanced PSP Compare Program

[Matt Dazzo]

Thanks all, used SMPECSI instead of SMPCSI. 

>>> "Jousma, David" <[EMAIL PROTECTED]> 3/26/2008 12:46 PM >>>
Take the "E" out of SMPECSI 


___

Dave Jousma
Assistant Vice President
Mainframe Services
[EMAIL PROTECTED] 
616.653.8429


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Matt Dazzo
Sent: Wednesday, March 26, 2008 9:49 AM
To: IBM-MAIN@bama.ua.edu 
Subject: Re: Enhanced PSP Compare Program

Here's what I'm running, no difference to me.

//ESPSPT EXEC PGM=EPSPT,PARM='PZOS17A',
//REGION=0M
//STEPLIB  DD DISP=SHR,DSN=SMPE.EPSPT.HOST.TOOL.NEW
//SMPECSI  DD DISP=SHR,DSN=SMPE.ZOS17.GLOBAL.CSI   
//SYSINDD DISP=SHR,DSN=ST1MAT.DEV2096  
//OUTPUT   DD SYSOUT=* 
//OUTPUTL  DD SYSOUT=* 
//SYSPRINT DD SYSOUT=* 

>>> Mark Jacobs <[EMAIL PROTECTED]> 3/26/2008 9:40 AM >>>
Matt Dazzo wrote:
> I updated the program to the latest level. I tried to using the global

> csi and the target csi and I get the following messages. Job ends with

> cc=0 but I get an error in the report. Any ideas? Thanks  +
>   

This is what I use in my job, works fine;

//ZOS18EXEC PGM=EPSPT,PARM='MVST100',COND=(0,NE)  
//STEPLIB  DD   DSN=TECHSVC.TECHNAPF.LOADLIB,DISP=SHR 
//SMPCSI   DD   DSN=SMPE.ZOS18.GLOBAL.CSI,DISP=SHR

Where MVST100 is the name of the target zone.

> Report Level:1.04.11 Last Update:2007/06/28
> For target zone PZOS17A
> HOLD  APAR -RESOLVING SYSMOD-  RELEVANT
> FMID  NUMBER   NAME  RECEIVED  UPGRADE+SUBSET  
> -
> MSG 010: SEVERE ERROR: Target Zone Query Failed, Report to IBM 
> NOTE: An asterisk denotes an APAR that has been previously 
> mentioned in this report.  
> *  
> *  SUMMARY  *  
> *  
> NO APARs/PTFs required.
> FMIDs  applicable: 0   
> APARs  applied:0   
> APARs  required:   0   
> PTFs   received:   0   
> Report Level:1.04.11 Last Update:2007/06/28
> For target zone PZOS17A
> MSG 019: rc from zone qry = 12
> MSG 010: SEVERE ERROR: Target Zone Query Failed, Report to IBM
> MSG 098: RC =  , CC =   }D \  
> MSG 099: MSGBUFF = GIM44233IGIMMPVIA - A PREALLOCATED VSAM DATA SE
> MSG 099: MSGBUFF = T WAS NOT FOUND FOR THE GLOBAL ZONE.   
> MSG 099: MSGBUFF = GIM50504S ** OPEN PROCESSING FAILED FOR THE GLOBAL 
> MSG 099: MSGBUFF = ZONE.  
>
>   


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
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: SMF System Logger - limitations of MANx

[Mark Zelden]

On Wed, 26 Mar 2008 09:38:10 -0700, Skip Robinson <[EMAIL PROTECTED]>
wrote:

>We've had occasional episodes of lost data.
>
>One case, which we think we've fixed via changes to automation, is the
>other side of the event-driven nature of MANx management. A strength of
>traditional SMF recording is that you dump and clear a MANx cluster in
>response to a message saying that it needs dumping. That's why you don't
>have to worry much about whether you've collected ten hours or ten minutes
>worth of data. You dump whatever's there, clear the file, and move on. A
>problem crops up when you IPL with all defined SMF data sets in need of
>dumping. They're not necessarily 'full'; they just can't be opened because,
>well, who knows why. I've seen MANx data sets at 1% that nonetheless
>require dumping. Go figure. But if all MANx data sets are full at IPL, data
>starts getting buffered. In our shop, the messages that should trigger
>dumping come out before our automation product has hit the ground. Our
>so-far-untested automation change is to trigger a dump when buffering has
>reached a certain threshold. Without that additional check, you can lose
>data when you run out of buffers.
>

We (and many shops) use the "CBIPO" SMFDUMP program in combination
with IEFU29.  This is the one that dumps all the full data sets and also 
does a switch command.  We use the SMFDUMP program at midnight to
cut things off for daily processing and IEFU29 the rest of the time.  I also
use the SMFDUMP program at IPL time to take care of the situation 
described above.   Both processes use the same SMFDUMP proc. Here
is an example of what it looks like (some LPARs dump to tape instead
of disk):

//SMFDUMP PROC MAN='X',ALL=FALSE   
//*
//* THIS PROC IS NORMALLY STARTED VIA IEFU29 SMF EXIT WHEN AN  
//* SMF DATA SET SWITCH OCCURS (ONLY THE FIRST STEP RUNS): 
//*S SMFDUMP,MAN=SMF.DATA.SET.NAME 
//*
//* AT IPL TIME IS IS STARTED AS FOLLOWS TO RUN THE SMFDUMP
//* PROGRAM TO ENSURE ALL FULL SYS1.MANX DATA SETS ARE DUMPED: 
//*S SMFDUMP,ALL=TRUE  
//*
//* IT IS ALSO STARTED THIS WAY AT MIDNIGHT TO USE THE SMFDUMP 
//* PROGRAM WHICH FORCES AN SMF SWITCH IN ORDER TO CAPTURE ALL 
//* THE SMF DATA UP TO THAT POINT FOR DAILY PROCESSING.
//*
//TESTEXEC EXEC PGM=IEFBR14
//*
// 
//TESTONE  IF (TESTEXEC.RUN NE &ALL) THEN  
// 
//DUMPONE  EXEC PGM=IFASMFDP,TIME=1440 
//SYSPRINT DD SYSOUT=* 
//DUMPIN   DD DSN=&MAN,DISP=SHR
//DUMPOUT  DD DSN=hlq.&SYSNAME..SMF(+1),DISP=(,CATLG),  
// DCB=(SYS1.MODEL,LRECL=X,BLKSIZE=32756,RECFM=VBS),UNIT=SYSDA,
// SPACE=(CYL,(300,300),RLSE)
//SYSINDD DUMMY
// ENDIF   
// 
//TESTALL  IF (TESTEXEC.RUN EQ &ALL) THEN  
// 
//DUMPALL  EXEC PGM=SMFDUMP,TIME=1440  
//SYSPRINT DD SYSOUT=* 
//DUMPOUT  DD DSN=hlq.&SYSNAME..SMF(+1),DISP=(,CATLG),  
// DCB=(SYS1.MODEL,LRECL=X,BLKSIZE=32756,RECFM=VBS),UNIT=SYSDA,
// SPACE=(CYL,(300,300),RLSE)
//SYSINDD DUMMY
// ENDIF   


Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
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: Displaying multiple volumes allocated from DSLIST

[Cochran, Bill]

 As far as I know, once it is allocated and gets the candidates, it
doesn't release them. I'm not sure why it's getting 3 if you have 2
specified.


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Gilbert Cardenas
Sent: Wednesday, March 26, 2008 12:06 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Displaying multiple volumes allocated from DSLIST

On Wed, 26 Mar 2008 11:37:04 -0400, Cochran, Bill
<[EMAIL PROTECTED]> wrote:

>It's just showing that you have 2 additional candidate volumes 
>allocated. They have not yet been assigned.
>
>
>

That's kind of what I was thinking but I thought it was kind of weird
because the file has been closed so why would it hold on to the
additional volume allocations especially if they weren't used.
Also, in the dataclass to this dataset, I only specify a volume count of
2 but yet this shows 3 potential volumes?

--
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: TDS: DB2 7 to DB8 SMF Data Usage

[Scott Barry]

On Wed, 26 Mar 2008 16:08:13 +0100, Fabio D'Alfonso 
<[EMAIL PROTECTED]> wrote:

>Hi,
>I would know if moving from DB2 7 to DB2 8 changes the way SMF records 
are
>created when running DB2 / CICS|BATCH|TSO commands.
>
>Thanks
>Fabio D'Alfonso
>
>--
>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

Yes, it is possible that you will notice SMF 101 data volume / content 
changes, if you implement the new DB2 V8 option ACCUMACC.  IBM did not 
add a "number of times package allocated" count (IFCID 0239) until DB2 v9, 
necessary with ACCUMACC and thread-reuse, in order to more accurately 
derive average statistics.

Aside from DB2 V8, thread reuse can also contribute to SMF 101 data volume 
reduction, and presents some challenges with accurately counting thread-
executions (field QWACPCNT) and packages-allocated (?) with a given SMF 
101 record.


Scott Barry
SBBWorks, Inc.


DB2 Version 9.1 for z/OS - link to "New and Changed IFCIDs" documentation 
reference (mind any broken URL):
http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/topic/com.ibm.db29.doc
.relg/db2z_changedifcids.htm

TDS DB2 Package/DBRM table info (a pkgs allocated column will be needed):
http://publib.boulder.ibm.com/tividd/td/TDS390/SH19-6819-
08/en_US/HTML/DRLS9MST70.htm

--
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: Is IT becoming extinct?

[R.S.]

Daniel McLaughlin wrote:

Misstated - COBOL isn't perceived as sexy ,,,

WE have over 500 servers in the room and we call it the chicken farm.


COBOL vs distributed platforms ?
Apples and oranges.
The most popular banking application in Poland is written in COBOL, but 
the platform is Unix (formerly single flavor). From the other hand, it 
is possible to have non-COBOL applications on mainframe. We have some in 
Poland.


BTW: COBOL has serious disadvantages.
(and the war began...)
--
Radoslaw Skorupka
Lodz, Poland


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

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

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA  wynosi 
118.642.672 zote i zosta w caoci wpacony.

--
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: Console exits

[Richard Peurifoy]

Mark Pace wrote:

Thanks to all that made suggestions.  IEFU29 was the easiest alternative,
other than the IPL needed.  ;-)


An IPL is not needed. IEFU29 is handle thru the
dynamic exit facility, so you an issue a command
to add it. The module can be loaded by the exit
facility, or added to dynamic LPA. For more info
on this see the PROGxx member in INIT and TUNING
REF.

--
Richard

--
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: Virtual tape questions

[Mark Zelden]

>can HSM be run in a mode which does not append to its old tapes


We have a small LPAR that uses virtual tape only.  We send ML2 to
virtual tape and it starts a fresh tape each time ML2 migration
is done.  Since stacking is done on the back end there is no
point in possibly recalling a virtual tape from the back end
just to mod onto it.

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



*** PLEASE NOTE ***
This E-Mail/telefax message and any documents accompanying this
transmission may contain privileged and/or confidential information and is
intended solely for the addressee(s) named above.  If you are not the
intended addressee/recipient, you are hereby notified that any use of,
disclosure, copying, distribution, or reliance on the contents of this
E-Mail/telefax information is strictly prohibited and may result in legal
action against you. Please reply to the sender advising of the error in
transmission and immediately delete/destroy the message and any
accompanying documents.  Thank you.

--
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: SMF System Logger - limitations of MANx

[Skip Robinson]

We've had occasional episodes of lost data.

One case, which we think we've fixed via changes to automation, is the
other side of the event-driven nature of MANx management. A strength of
traditional SMF recording is that you dump and clear a MANx cluster in
response to a message saying that it needs dumping. That's why you don't
have to worry much about whether you've collected ten hours or ten minutes
worth of data. You dump whatever's there, clear the file, and move on. A
problem crops up when you IPL with all defined SMF data sets in need of
dumping. They're not necessarily 'full'; they just can't be opened because,
well, who knows why. I've seen MANx data sets at 1% that nonetheless
require dumping. Go figure. But if all MANx data sets are full at IPL, data
starts getting buffered. In our shop, the messages that should trigger
dumping come out before our automation product has hit the ground. Our
so-far-untested automation change is to trigger a dump when buffering has
reached a certain threshold. Without that additional check, you can lose
data when you run out of buffers.

Another case is harder to deal with. We dump straight to tape. Once in a
while we have an extended tape outage for hardware or software maintenance.
Of course we could code for this situation by writing first to DASD, then
to tape. Heck, we could write a whole subsystem. Ad infinitum.

System Logger in principle handles all these cases by its nature. As SMF
records flow, Logger captures them and writes them to DASD. A new offload
data set is allocated as often as necessary: once a day or once a minute.
The full-at-IPL condition simply goes away. Logger never gets full. If tape
is unavailable for some period of time, records simply accumulate until a
dump job can eventually be run.

The worst fallout of SMF data loss is that all records are treated alike.
It's simple FIFO, records you need, records you might like to have, records
that may or may not prove crucial down the road. You capture them all until
recording is impaired, then you lose everything. The current complexity of
managing Logger offload data is presumably temporary, although no relief
has actually been announced. Given the well known historical problems with
MANx data sets, I still think Logger is worth the effort today.

.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[EMAIL PROTECTED]


   
 "Vernooy, C.P. -  
 SPLXM"
 <[EMAIL PROTECTED]  To 
 .COM> IBM-MAIN@bama.ua.edu
 Sent by: IBM   cc 
 Mainframe 
 Discussion List   Subject 
 <[EMAIL PROTECTED] Re: SMF System Logger - limitations 
 .edu> of MANx 
   
   
 03/26/2008 12:44  
 AM
   
   
 Please respond to 
   IBM Mainframe   
  Discussion List  
 <[EMAIL PROTECTED] 
   .edu>   
   
   




"R.S." <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> Mark Zelden wrote:
> [...]
> > As mentioned... lots in the archives about this (even before the
recent
> > threads).
> >
> > 1) Speed of offloading (being able to keep up with records being
written).
> IMHO I can live with it (YMMV). In case of SMF (expected & accepted)
> flood I can use more MANx datasets as a spill.

This is not the solution: I have seen occasions where records are
presented to SMF faster that SMF can write them to MANx. This will cause
SMF to run out of buffers with records lost as a consequence.

Kees.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTE

Re: Enhanced PSP Compare Program

[Jousma, David]

Take the "E" out of SMPECSI 


___

Dave Jousma
Assistant Vice President
Mainframe Services
[EMAIL PROTECTED]
616.653.8429


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Matt Dazzo
Sent: Wednesday, March 26, 2008 9:49 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Enhanced PSP Compare Program

 Here's what I'm running, no difference to me.
 
//ESPSPT EXEC PGM=EPSPT,PARM='PZOS17A',
//REGION=0M
//STEPLIB  DD DISP=SHR,DSN=SMPE.EPSPT.HOST.TOOL.NEW
//SMPECSI  DD DISP=SHR,DSN=SMPE.ZOS17.GLOBAL.CSI   
//SYSINDD DISP=SHR,DSN=ST1MAT.DEV2096  
//OUTPUT   DD SYSOUT=* 
//OUTPUTL  DD SYSOUT=* 
//SYSPRINT DD SYSOUT=* 

>>> Mark Jacobs <[EMAIL PROTECTED]> 3/26/2008 9:40 AM >>>
Matt Dazzo wrote:
> I updated the program to the latest level. I tried to using the global

> csi and the target csi and I get the following messages. Job ends with

> cc=0 but I get an error in the report. Any ideas? Thanks  +
>   

This is what I use in my job, works fine;

//ZOS18EXEC PGM=EPSPT,PARM='MVST100',COND=(0,NE)  
//STEPLIB  DD   DSN=TECHSVC.TECHNAPF.LOADLIB,DISP=SHR 
//SMPCSI   DD   DSN=SMPE.ZOS18.GLOBAL.CSI,DISP=SHR

Where MVST100 is the name of the target zone.

> Report Level:1.04.11 Last Update:2007/06/28
> For target zone PZOS17A
> HOLD  APAR -RESOLVING SYSMOD-  RELEVANT
> FMID  NUMBER   NAME  RECEIVED  UPGRADE+SUBSET  
> -
> MSG 010: SEVERE ERROR: Target Zone Query Failed, Report to IBM 
> NOTE: An asterisk denotes an APAR that has been previously 
> mentioned in this report.  
> *  
> *  SUMMARY  *  
> *  
> NO APARs/PTFs required.
> FMIDs  applicable: 0   
> APARs  applied:0   
> APARs  required:   0   
> PTFs   received:   0   
> Report Level:1.04.11 Last Update:2007/06/28
> For target zone PZOS17A
> MSG 019: rc from zone qry = 12
> MSG 010: SEVERE ERROR: Target Zone Query Failed, Report to IBM
> MSG 098: RC =  , CC =   }D \  
> MSG 099: MSGBUFF = GIM44233IGIMMPVIA - A PREALLOCATED VSAM DATA SE
> MSG 099: MSGBUFF = T WAS NOT FOUND FOR THE GLOBAL ZONE.   
> MSG 099: MSGBUFF = GIM50504S ** OPEN PROCESSING FAILED FOR THE GLOBAL 
> MSG 099: MSGBUFF = ZONE.  
>
>   


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
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: Enhanced PSP Compare Program

[Birger Heede]

DDNAME is SMPCSI not SMPECSI

Birger Heede
IBM Denmark


Matt Dazzo wrote:

 Here's what I'm running, no difference to me.
 
//ESPSPT EXEC PGM=EPSPT,PARM='PZOS17A',
//REGION=0M
//STEPLIB  DD DISP=SHR,DSN=SMPE.EPSPT.HOST.TOOL.NEW
//SMPECSI  DD DISP=SHR,DSN=SMPE.ZOS17.GLOBAL.CSI   
//SYSINDD DISP=SHR,DSN=ST1MAT.DEV2096  
//OUTPUT   DD SYSOUT=* 
//OUTPUTL  DD SYSOUT=* 
//SYSPRINT DD SYSOUT=* 


Mark Jacobs <[EMAIL PROTECTED]> 3/26/2008 9:40 AM >>>

Matt Dazzo wrote:

I updated the program to the latest level. I tried to using the global csi and 
the target csi and I get the following messages. Job ends with cc=0 but I get 
an error in the report. Any ideas? Thanks
 +
  


This is what I use in my job, works fine;

//ZOS18EXEC PGM=EPSPT,PARM='MVST100',COND=(0,NE)  
//STEPLIB  DD   DSN=TECHSVC.TECHNAPF.LOADLIB,DISP=SHR 
//SMPCSI   DD   DSN=SMPE.ZOS18.GLOBAL.CSI,DISP=SHR


Where MVST100 is the name of the target zone.

Report Level:1.04.11 Last Update:2007/06/28
For target zone PZOS17A
HOLD  APAR -RESOLVING SYSMOD-  RELEVANT
FMID  NUMBER   NAME  RECEIVED  UPGRADE+SUBSET  
-  
MSG 010: SEVERE ERROR: Target Zone Query Failed, Report to IBM 
NOTE: An asterisk denotes an APAR that has been previously 
mentioned in this report.  
*  
*  SUMMARY  *  
*  
NO APARs/PTFs required.
FMIDs  applicable: 0   
APARs  applied:0   
APARs  required:   0   
PTFs   received:   0   
Report Level:1.04.11 Last Update:2007/06/28
For target zone PZOS17A
MSG 019: rc from zone qry = 12
MSG 010: SEVERE ERROR: Target Zone Query Failed, Report to IBM
MSG 098: RC =  , CC =   }D \  
MSG 099: MSGBUFF = GIM44233IGIMMPVIA - A PREALLOCATED VSAM DATA SE
MSG 099: MSGBUFF = T WAS NOT FOUND FOR THE GLOBAL ZONE.   
MSG 099: MSGBUFF = GIM50504S ** OPEN PROCESSING FAILED FOR THE GLOBAL 
MSG 099: MSGBUFF = ZONE.  

  

Kurt Quackenbush <[EMAIL PROTECTED]> 3/26/2008 9:21 AM >>>

You didn't show your EPSPT job, so this is a guess, but ensure the 
SMPCSI DD statement specifies the CSI data set for your global zone 
(SMPE.ZOS17.GLOBAL.CSI), not the CSI data set name for your target zone. 
  The PARM then specifies the name of your target zone (PZOS17A).


Kurt Quackenbush -- IBM, SMP/E Development

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

  





--
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: Virtual tape questions

[Staller, Allan]

The operating system does not know anything about the MVC's. MVC's are
mounted on drives direct attached to the VTS, bypassing MVS IO entirely.
The only places in "MVS land" that know anything about the MVC's are the
TMC (where they are usually marked in delete status) and the HSC CDS's.
Virtual tapes (VTV's) are tracked exactly like any physical media and
are known to MVS/TMS.

Data is never written directly to the MVC. It is only written to the
VTV. If the virtual tape volume has already been migrated to the MVC and
purged from the VTS cache, the only recourse is to recall the data from
the MVC back to the VTS cache and then perform the append (this is
possibly, but not necessarily faster than the physical equivalent).

Another poster indicated the SETSYS PARTIALTAPE operand of DFHSM. We use
this to minimize append processing. HSM media can be duplicated by HSM,
or as in your case, by the VTS. There are pros and cons to either
approach.

STK has a white paper on DFHSM and VTS that I am sure you can obtain
from the CRC.

All of that being said, the VTS is not necessarily the best performer
with append type data. YMMV.


First of all, real tape's update mode is primarily append.  But using
disk, once the virtual volume is written to a multi-volume cartridge,
assuming it's not the last volume on the multi-volume cartridge, no
physical straight-forward append seems possible.  I don't think it
chains virtual volume "extents" in different locations on the
mulit-volume cartridge or across them to simulate a virtual append ???
I assume for a non-scratch ring-in virtual mount of a pre-existing
volser it loads the original virtual volume data from the multi volume
cartridge to its disk cache and then after the job finishes appending
data it just marks the original data area free in its CDS directory and
rewrites the original data with appended data in a new location on a
multi-volume cartridge.

So virtual tape probably handles applications which append data to old
tapes rather poorly, fragmenting the data on the cartridges until
background reclaim processing reorganizes them.

Doesn't HSM L2 do a lot of append processing, adding to the end of
tapes?

This site doesn't currently replicate HSM L2 tape volumes nor sysout
archive migrate or backup tape volumes to the disaster recovery site.  I
am considering changing that.  Today I will quantify the increase in
data traffic.  But quantifying the increase in fragmentation and need
for reclaim/reorg is more difficult.  Should I even worry about it?

With virtual tape meeting the same objective of using more of the entire
physical tape, can HSM be run in a mode which does not append to its old
tapes?  That would use many more tpae volumes, but heck they're
"virtual."  How can I quantify the greatly increased number of volsers
that would require in my CA-1 tape library?  Is this even possible?


--
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: Enhanced PSP Compare Program

[Kurt Quackenbush]

MSG 099: MSGBUFF = GIM44233IGIMMPVIA - A PREALLOCATED VSAM DATA SE
MSG 099: MSGBUFF = T WAS NOT FOUND FOR THE GLOBAL ZONE.   
MSG 099: MSGBUFF = GIM50504S ** OPEN PROCESSING FAILED FOR THE GLOBAL 
MSG 099: MSGBUFF = ZONE.  


Looks like you didn't specify the SMPCSI DD statement.  Please try this:

//EPSPTEXEC PGM=EPSPT,PARM='PZOS17A'
//STEPLIB  DD   DSN=your.epspt.loadlib,DISP=SHR
//SMPCSI   DD   DSN=SMPE.ZOS17.GLOBAL.CSI,DISP=SHR

If that doesn't work for you, then show the JCL job you used and the output.

Kurt Quackenbush -- IBM, SMP/E Development

--
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: Is IT becoming extinct?

[Daniel McLaughlin]

Misstated - COBOL isn't perceived as sexy ,,,

WE have over 500 servers in the room and we call it the chicken farm.

Daniel McLaughlin
Z-Series Systems Programmer
Information & Communications Technology
Crawford & Company
4680 N. Royal Atlanta
Tucker GA 30084 
phone: 770-621-3256 
fax: 770-621-3237
email: [EMAIL PROTECTED]
web: www.crawfordandcompany.com 



IBM Mainframe Discussion List  wrote on 03/26/2008 
11:13:48 AM:

> -- Information from the mail header 
> ---
> Sender:   IBM Mainframe Discussion List 
> Poster:   Steve Comstock <[EMAIL PROTECTED]>
> Subject:  Re: Is IT becoming extinct?
> 
---
> 
> Daniel McLaughlin wrote:
> > COBOL isn't sexy anymore. High schools are teaching PC stuff. And yet 
a 
> > myriad of code being used is on our mainframes.
> 
> Well, COBOL isn't _percieved_ as sexy anymore.
> 
> But you can handle ASCII and UNICODE and XML in COBOL.
> You can code COBOL CGIs to run under your z/OS HTTP.
> What's sexier than the web these days?
> 
> 
> > 
> > I once automated myself out of a support job. 
> > 
> > I am a dinosaur.
> 
> I know the feeling. But we gotta' learn how to do
> the new stuff on the mainframe, and let management
> see it.
> 
> 
> Kind regards,
> 
> -Steve Comstock
> The Trainer's Friend, Inc.
> 
> 303-393-8716
> http://www.trainersfriend.com
> 
>z/OS Application development made easier
>  * Our classes include
> + How things work
> + Programming examples with realistic applications
> + Starter / skeleton code
> + Complete working programs
> + Useful utilities and subroutines
> + Tips and techniques
> 
> ==> call or email to receive a free sample student handout <==
> 
> --
> 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
> 



Best Overall Third-Party Claims Administrator - 2007 "Business Insurance" 
Readers Choice Awards
 
Consider the environment before printing this message.

This transmission is intended exclusively for the individual or entity to which 
it is addressed. This communication may contain information that is 
confidential, proprietary, privileged or otherwise exempt from disclosure. If 
you are not the named addressee, you are NOT authorized to read, print, retain, 
copy or disseminate this communication, its attachments or any part of them. If 
you have received this communication in error, please notify the sender 
immediately and delete this communication from all computers.  This 
communication does not form any contractual obligation on behalf of the sender, 
the sender's employer, or the employer's parent company, affiliates or 
subsidiaries.

--
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: Displaying multiple volumes allocated from DSLIST

[Gilbert Cardenas]

On Wed, 26 Mar 2008 11:37:04 -0400, Cochran, Bill 
<[EMAIL PROTECTED]> wrote:

>It's just showing that you have 2 additional candidate volumes
>allocated. They have not yet been assigned.
>
>
>Thanks,
>Bill Cochran
>AIT Mainframe Storage
>502-560-3025
>

That's kind of what I was thinking but I thought it was kind of weird because 
the file has been closed so why would it hold on to the additional volume 
allocations especially if they weren't used.
Also, in the dataclass to this dataset, I only specify a volume count of 2 but 
yet this shows 3 potential volumes?

--
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: Virtual tape questions

[Jack Kelly]

can HSM be run in a mode which does not append to its old tapes


I would image that you could get away with one ML2 tape per day. You could 
tell HSM to not reuse (append) to any tape (setsys partialtape) but your 
OCDS would probably get fairly large. I would simply execute a REXX to 
'markfull' the current daily ML2 tape. If you're using interval miggration 
, you could have several tapes in a day and then you have PSM and SSM, in 
addition to letting user manually migrate.
HTH

Jack Kelly
202-502-2390 (Office)

--
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: JES2 NJE question: SNA(CTC) vs. TCPIP

[Mark Pace]

The difference is outbound vs inbound port numbers.  Outbound port numbers
are almost always different and nothing to be concerned about.

On Wed, Mar 26, 2008 at 11:25 AM, Schwartz, Alan <[EMAIL PROTECTED]>
wrote:

> There was some discussion about this last month but my question wasn't
> covered.  I'm testing my first NJE/IP link and it's working.  When the
> connection was made today I got IAZ0543I NETSRV1 TCP/IP connection with IP
> Addr: xxx.xxx.com Port: 2465 Successful.  When I connected on Monday the
> port was 2963.  This is an unsecure definition so we opened the documented
> port 175.  Anyone know where these port numbers are coming from and why
> the
> change?
>
> Alan Schwartz
> Infrastructure Management Sr Analyst
>
> --
> 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
>



-- 
Mark Pace
Mainline Information Systems

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

Virtual tape questions

[Gregory Pinkowski]

This site uses an STK virtual tape system cluster, which accumulates many 
virtual tape volumes onto a disk array cache and then to 
multi-volume-cartridges loaded robotically.  It also replicates those virtual 
tape volumes to a disaster recovery site where they are cached and a second 
robotic system loads them to a different library of multi-volume cartridges.  
I'm just becoming familiar with STK virtual tape and making some observations 
and have many questions.

First of all, real tape's update mode is primarily append.  But using disk, 
once the virtual volume is written to a multi-volume cartridge, assuming it's 
not the last volume on the multi-volume cartridge, no physical straight-forward 
append seems possible.  I don't think it chains virtual volume "extents" in 
different locations on the mulit-volume cartridge or across them to simulate a 
virtual append ???  I assume for a non-scratch ring-in virtual mount of a 
pre-existing volser it loads the original virtual volume data from the multi 
volume cartridge to its disk cache and then after the job finishes appending 
data it just marks the original data area free in its CDS directory and 
rewrites the original data with appended data in a new location on a 
multi-volume cartridge.

So virtual tape probably handles applications which append data to old tapes 
rather poorly, fragmenting the data on the cartridges until background reclaim 
processing reorganizes them.

Doesn't HSM L2 do a lot of append processing, adding to the end of tapes?

This site doesn't currently replicate HSM L2 tape volumes nor sysout archive 
migrate or backup tape volumes to the disaster recovery site.  I am considering 
changing that.  Today I will quantify the increase in data traffic.  But 
quantifying the increase in fragmentation and need for reclaim/reorg is more 
difficult.  Should I even worry about it?

With virtual tape meeting the same objective of using more of the entire 
physical tape, can HSM be run in a mode which does not append to its old tapes? 
 That would use many more tpae volumes, but heck they're "virtual."  How can I 
quantify the greatly increased number of volsers that would require in my CA-1 
tape library?  Is this even possible?

--
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: Console exits

[Mark Pace]

Thanks to all that made suggestions.  IEFU29 was the easiest alternative,
other than the IPL needed.  ;-)



-- 
Mark Pace
Mainline Information Systems

--
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: Displaying multiple volumes allocated from DSLIST

[Cochran, Bill]

It's just showing that you have 2 additional candidate volumes
allocated. They have not yet been assigned. 


Thanks,
Bill Cochran
AIT Mainframe Storage
502-560-3025

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Gilbert Cardenas
Sent: Wednesday, March 26, 2008 11:31 AM
To: IBM-MAIN@bama.ua.edu
Subject: Displaying multiple volumes allocated from DSLIST

When a dataset has multiple volumes allocated for example :

Command - Enter "/" to select action  Message
Volume 

---
 TAPEX.SMFCICS.DATA
?? 
 TAPEX.SMFCICS.DATA.G1506V00
TMM829+

And I select the dataset to view the attributes, there is a message that
says:
To display multiple volumes press Enter or enter Cancel to Exit.
If I press enter all I get is the following:

All allocated volumes:  
More: + 
 Number of volumes allocated: 3 

 TMM829  *   *  

Is there anyway to tell what the other volumes are?

--
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: Displaying multiple volumes allocated from DSLIST

[George Rodriguez]

If you use a product like TLMS, they supply an exec called TI that will
provide the info you are looking for. I don't know of any other way to
get the other volumes.

Hope this helps...

Thanks,
George Rodriguez
Specialist, Systems Programmer
IT-Operations
(561) 357-7652 (office)
(561) 707-3496 (mobil)
School District of Palm Beach County
3348 Forest Hill Blvd.
Room B332
West Palm Beach, FL. 33406-5869
Rated "A" by the Florida Department of Education 2005, 2006 & 2007
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Gilbert Cardenas
Sent: Wednesday, March 26, 2008 11:31 AM
To: IBM-MAIN@bama.ua.edu
Subject: Displaying multiple volumes allocated from DSLIST

When a dataset has multiple volumes allocated for example :

Command - Enter "/" to select action  Message
Volume 

---
 TAPEX.SMFCICS.DATA
?? 
 TAPEX.SMFCICS.DATA.G1506V00
TMM829+

And I select the dataset to view the attributes, there is a message that
says:
To display multiple volumes press Enter or enter Cancel to Exit.
If I press enter all I get is the following:

All allocated volumes:  
More: + 
 Number of volumes allocated: 3 

 TMM829  *   *  

Is there anyway to tell what the other volumes are?

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

-
Under Florida law, e-mail addresses are public records. If you do
not want your e-mail address released in response to a public
records request, do not send electronic mail to this entity.
Instead, contact this office by phone or in writing.  

--
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: Displaying multiple volumes allocated from DSLIST

[Mueller, David]

 
If you type 'listc ent(/) all ' on the line-command for the dataset, it
will get you a dynamic list-cat display that will include all of the
volumes.

David Mueller | Systems Programmer | DMS/CITS
Phone: 850-414-9134 (Rm 107 SRC) | Fax: 850-921-8343
E-mail: [EMAIL PROTECTED]
"We serve those who serve Florida"
  


  
http://dmspulsesurvey.myflorida.com/is
 
 
 
-Original Message-
 
 
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Gilbert Cardenas
Sent: Wednesday, March 26, 2008 11:31 AM
To: IBM-MAIN@bama.ua.edu
Subject: Displaying multiple volumes allocated from DSLIST

When a dataset has multiple volumes allocated for example :

Command - Enter "/" to select action  Message
Volume 

---
 TAPEX.SMFCICS.DATA
?? 
 TAPEX.SMFCICS.DATA.G1506V00
TMM829+

And I select the dataset to view the attributes, there is a message that
says:
To display multiple volumes press Enter or enter Cancel to Exit.
If I press enter all I get is the following:

All allocated volumes:  
More: + 
 Number of volumes allocated: 3 

 TMM829  *   *  

Is there anyway to tell what the other volumes are?

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

Displaying multiple volumes allocated from DSLIST

[Gilbert Cardenas]

When a dataset has multiple volumes allocated for example :

Command - Enter "/" to select action  Message   Volume 
---
 TAPEX.SMFCICS.DATA ?? 
 TAPEX.SMFCICS.DATA.G1506V00   TMM829+

And I select the dataset to view the attributes, there is a message that says:
To display multiple volumes press Enter or enter Cancel to Exit.
If I press enter all I get is the following:

All allocated volumes:  
More: + 
 Number of volumes allocated: 3 

 TMM829  *   *  

Is there anyway to tell what the other volumes are?

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

JES2 NJE question: SNA(CTC) vs. TCPIP

[Schwartz, Alan]

There was some discussion about this last month but my question wasn't
covered.  I'm testing my first NJE/IP link and it's working.  When the
connection was made today I got IAZ0543I NETSRV1 TCP/IP connection with IP
Addr: xxx.xxx.com Port: 2465 Successful.  When I connected on Monday the
port was 2963.  This is an unsecure definition so we opened the documented
port 175.  Anyone know where these port numbers are coming from and why the
change?

Alan Schwartz
Infrastructure Management Sr Analyst

--
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: WLM and TSO

[Kelman, Tom]

Boy Dave, you are aggressive with your TSO goals.  Here we have them set
as follows.  I do like your third period though.  If they are doing
something in TSO that takes that much service than put them in never
never land.

Duration  Imp.Description
800   2   80% complete within 00:00:00.500
  3   Vel=60

Of course we need to be sure that TSO doesn't hurt out bread and butter
CICS transactions which are set at 85% within 00:00:00.150 and
importance level of 1.


Tom Kelman
Commerce Bank of Kansas City
(816) 760-7632


> Posted by Dave Thorn
> 
> It depends on your CPU speed and characteristics of TSO usage.  If
your
> users run lots of long transactions like searches, CLISTs, foreground
> things, they could suffer.  Most TSO activity (in my experience) is of
> the short variety, so as you see below I'm not shy about making 1st
> period imp=1, but for just 500 service units.  We also try to get some
> things through in period 2 with a pretty aggressive goal.  Works OK
> here, but probably not for everyone.
> 
> You might ask your users what they're trying to do when they hang.
> 
> Duration   Imp.  Description
> 
> 500 195% complete within 00:00:01.000
> 5   295% complete within 00:00:15.000
> 5Execution velocity of 5
> 
> Dave Thorn * Senior Technology Analyst * SunGard Computer Services *
600
> Laurel Oak Road, Voorhees, NJ, 08043
> Office 856 566-5412 * Mobile 609 781-0353 * Fax 856 566-3656
> 
> CONFIDENTIALITY:  This e-mail (including any attachments) may contain
> confidential, proprietary and privileged information, and unauthorized
> disclosure or use is prohibited.  If you received this e-mail in
error,
> please notify the sender and delete this e-mail from your system.
> 
>


> Posted by Aimee Houghton
> 
> I am no performance expert and I am basically mostly using Cheryl
Watson
> quickstart (or whatever it is called). We are only using one service
> class
> for TSO users.  For the most part it works fine but during batch
window
> we
> have times when the operators let a bunch of stuff run in high
priority
> batch service class.  During those times, TSO users tend to sit and
> hang.
> Of course, the operators bump up their own priority so they don't have
a
> problem.  I am looking for suggestions as to how to setup the service
> class
> for TSO users to avoid having them hang during these situations.
> 
> Here is my service class for TSO:
> 
> Base goal:
> CPU Critical flag: NO
> 
>   #  Duration   Imp  Goal description
>   -  -  -
>   1  800280% complete within 00:00:00.300
>   2 4Execution velocity of 40
> 
> 
> Here is my service class for PRDBATHI (which I am assuming is causing
> the
> problem):
> 
> Base goal:
> CPU Critical flag: NO
> 
>   #  Duration   Imp  Goal description
>   -  -  -
>   1 3Execution velocity of 40
> 
> 
> Any suggestions would be greatly appreciated.
> 
> Thanks,
> Aimee
> 




*
If you wish to communicate securely with Commerce Bank and its
affiliates, you must log into your account under Online Services at 
http://www.commercebank.com or use the Commerce Bank Secure
Email Message Center at https://securemail.commercebank.com

NOTICE: This electronic mail message and any attached files are
confidential. The information is exclusively for the use of the
individual or entity intended as the recipient. If you are not
the intended recipient, any use, copying, printing, reviewing,
retention, disclosure, distribution or forwarding of the message
or any attached file is not authorized and is strictly prohibited.
If you have received this electronic mail message in error, please
advise the sender by reply electronic mail immediately and
permanently delete the original transmission, any attachments
and any copies of this message from your computer 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: More SDSF security questions

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 03/24/2008
   at 03:30 PM, Rich Smrcina <[EMAIL PROTECTED]> said:

>I read sdsf. for the output.  This essentially works, the problem is 
>that when I run this in batch I only see myself.  If I run this in TSO I 
>can see all of the executing jobs on the system.

Compare your SDSF filter options in background with your SDSF filter
options in foreground.
 
-- 
 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: Long translate (TR) instruction?

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on
03/24/2008
   at 12:30 PM, Kirk Wolf <[EMAIL PROTECTED]> said:

>I'm looking for the fastest way in assembler to translate data in one
>buffer to another using a 256-byte translate table.

The fastest way on one model may not be the fastest way on another model.

>Any advise on the fastest instruction path to do this would be
>appreciated.

Time seveal approaches on the specific box you're targetting. 
 
-- 
 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

TDS: DB2 7 to DB8 SMF Data Usage

[Fabio D'Alfonso]

Hi,
I would know if moving from DB2 7 to DB2 8 changes the way SMF records are
created when running DB2 / CICS|BATCH|TSO commands.

Thanks
Fabio D'Alfonso

--
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: WLM and TSO

[Kelman, Tom]

Your goal for first period TSO looks good.  You probably want around 90%
of your TSO transactions completing within that period.  Check that out
and if you don't increase the duration slightly.  Another suggestion
would be to bump the second period TSO importance level to 3 so it is
running the same as your PRDBATHI.

Are you running CICS or IMS and if so what are their goals and
importance levels.  You want to make sure they run above batch and TSO.

Tom Kelman
Commerce Bank of Kansas City
(816) 760-7632

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Aimee Houghton
> Sent: Tuesday, March 25, 2008 10:01 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: WLM and TSO
> 
> I am no performance expert and I am basically mostly using Cheryl
Watson
> quickstart (or whatever it is called). We are only using one service
class
> for TSO users.  For the most part it works fine but during batch
window we
> have times when the operators let a bunch of stuff run in high
priority
> batch service class.  During those times, TSO users tend to sit and
hang.
> Of course, the operators bump up their own priority so they don't have
a
> problem.  I am looking for suggestions as to how to setup the service
> class
> for TSO users to avoid having them hang during these situations.
> 
> Here is my service class for TSO:
> 
> Base goal:
> CPU Critical flag: NO
> 
>   #  Duration   Imp  Goal description
>   -  -  -
>   1  800280% complete within 00:00:00.300
>   2 4Execution velocity of 40
> 
> 
> Here is my service class for PRDBATHI (which I am assuming is causing
the
> problem):
> 
> Base goal:
> CPU Critical flag: NO
> 
>   #  Duration   Imp  Goal description
>   -  -  -
>   1 3Execution velocity of 40
> 
> 
> Any suggestions would be greatly appreciated.
> 
> Thanks,
> Aimee
> 
> --
> 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




*
If you wish to communicate securely with Commerce Bank and its
affiliates, you must log into your account under Online Services at 
http://www.commercebank.com or use the Commerce Bank Secure
Email Message Center at https://securemail.commercebank.com

NOTICE: This electronic mail message and any attached files are
confidential. The information is exclusively for the use of the
individual or entity intended as the recipient. If you are not
the intended recipient, any use, copying, printing, reviewing,
retention, disclosure, distribution or forwarding of the message
or any attached file is not authorized and is strictly prohibited.
If you have received this electronic mail message in error, please
advise the sender by reply electronic mail immediately and
permanently delete the original transmission, any attachments
and any copies of this message from your computer 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: Is IT becoming extinct?

[Steve Comstock]

Daniel McLaughlin wrote:
COBOL isn't sexy anymore. High schools are teaching PC stuff. And yet a 
myriad of code being used is on our mainframes.


Well, COBOL isn't _percieved_ as sexy anymore.

But you can handle ASCII and UNICODE and XML in COBOL.
You can code COBOL CGIs to run under your z/OS HTTP.
What's sexier than the web these days?




I once automated myself out of a support job. 


I am a dinosaur.


I know the feeling. But we gotta' learn how to do
the new stuff on the mainframe, and let management
see it.


Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

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

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

==> call or email to receive a free sample student handout <==

--
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: Is IT becoming extinct?

[Steve Comstock]

Howard Brazee wrote:

On 26 Mar 2008 07:34:32 -0700, [EMAIL PROTECTED] (Ted MacNEIL) wrote:


At a price they were willing to pay, perhaps


Perhaps.
But, the main reason is nobody wanted to live there.


A company has a choice.   It can be located where skilled labor is
available and expensive - use external labor - or it can train its
labor in-house.

Training in-house used to be the standard.


Sigh. Those were the good old days!


Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

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

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

==> call or email to receive a free sample student handout <==

--
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: Is IT becoming extinct?

[Daniel McLaughlin]

COBOL isn't sexy anymore. High schools are teaching PC stuff. And yet a 
myriad of code being used is on our mainframes.

I once automated myself out of a support job. 

I am a dinosaur.

Daniel McLaughlin
Z-Series Systems Programmer
Information & Communications Technology
Crawford & Company
4680 N. Royal Atlanta
Tucker GA 30084 
phone: 770-621-3256 
fax: 770-621-3237
email: [EMAIL PROTECTED]
web: www.crawfordandcompany.com 




Best Overall Third-Party Claims Administrator - 2007 "Business Insurance" 
Readers Choice Awards
 
Consider the environment before printing this message.

This transmission is intended exclusively for the individual or entity to which 
it is addressed. This communication may contain information that is 
confidential, proprietary, privileged or otherwise exempt from disclosure. If 
you are not the named addressee, you are NOT authorized to read, print, retain, 
copy or disseminate this communication, its attachments or any part of them. If 
you have received this communication in error, please notify the sender 
immediately and delete this communication from all computers.  This 
communication does not form any contractual obligation on behalf of the sender, 
the sender's employer, or the employer's parent company, affiliates or 
subsidiaries.

--
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: Is IT becoming extinct?

[Howard Brazee]

On 26 Mar 2008 07:34:32 -0700, [EMAIL PROTECTED] (Ted MacNEIL) wrote:

>>At a price they were willing to pay, perhaps
>
>
>Perhaps.
>But, the main reason is nobody wanted to live there.

A company has a choice.   It can be located where skilled labor is
available and expensive - use external labor - or it can train its
labor in-house.

Training in-house used to be the standard.

--
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: Is IT becoming extinct?

[Ted MacNEIL]

>> couldn't find any new COBOL programmers.

>At a price they were willing to pay, perhaps


Perhaps.
But, the main reason is nobody wanted to live there.

-
Too busy driving to stop for gas!

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

[Steve Comstock]

Tom Marchant wrote:

On Wed, 26 Mar 2008 06:38:41 -0500, Jan MOEYERSONS wrote:


Help! I need somebody,



What was the point of posting that off-topic copyrighted work here?



Maybe it's a cry for help.
Maybe it's the OP just feeling whimsical.
Maybe the OP is on drugs.
Maybe we should contact the OP off-list.
Maybe we should move on.




Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

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

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

==> call or email to receive a free sample student handout <==

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

[Tom Marchant]

On Wed, 26 Mar 2008 06:38:41 -0500, Jan MOEYERSONS wrote:

>Help! I need somebody,
>

What was the point of posting that off-topic copyrighted work here?

-- 
Tom Marchant

--
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: Enhanced PSP Compare Program

[Matt Dazzo]

 Here's what I'm running, no difference to me.
 
//ESPSPT EXEC PGM=EPSPT,PARM='PZOS17A',
//REGION=0M
//STEPLIB  DD DISP=SHR,DSN=SMPE.EPSPT.HOST.TOOL.NEW
//SMPECSI  DD DISP=SHR,DSN=SMPE.ZOS17.GLOBAL.CSI   
//SYSINDD DISP=SHR,DSN=ST1MAT.DEV2096  
//OUTPUT   DD SYSOUT=* 
//OUTPUTL  DD SYSOUT=* 
//SYSPRINT DD SYSOUT=* 

>>> Mark Jacobs <[EMAIL PROTECTED]> 3/26/2008 9:40 AM >>>
Matt Dazzo wrote:
> I updated the program to the latest level. I tried to using the global csi 
> and the target csi and I get the following messages. Job ends with cc=0 but I 
> get an error in the report. Any ideas? Thanks
>  +
>   

This is what I use in my job, works fine;

//ZOS18EXEC PGM=EPSPT,PARM='MVST100',COND=(0,NE)  
//STEPLIB  DD   DSN=TECHSVC.TECHNAPF.LOADLIB,DISP=SHR 
//SMPCSI   DD   DSN=SMPE.ZOS18.GLOBAL.CSI,DISP=SHR

Where MVST100 is the name of the target zone.

> Report Level:1.04.11 Last Update:2007/06/28
> For target zone PZOS17A
> HOLD  APAR -RESOLVING SYSMOD-  RELEVANT
> FMID  NUMBER   NAME  RECEIVED  UPGRADE+SUBSET  
> -  
> MSG 010: SEVERE ERROR: Target Zone Query Failed, Report to IBM 
> NOTE: An asterisk denotes an APAR that has been previously 
> mentioned in this report.  
> *  
> *  SUMMARY  *  
> *  
> NO APARs/PTFs required.
> FMIDs  applicable: 0   
> APARs  applied:0   
> APARs  required:   0   
> PTFs   received:   0   
> Report Level:1.04.11 Last Update:2007/06/28
> For target zone PZOS17A
> MSG 019: rc from zone qry = 12
> MSG 010: SEVERE ERROR: Target Zone Query Failed, Report to IBM
> MSG 098: RC =  , CC =   }D \  
> MSG 099: MSGBUFF = GIM44233IGIMMPVIA - A PREALLOCATED VSAM DATA SE
> MSG 099: MSGBUFF = T WAS NOT FOUND FOR THE GLOBAL ZONE.   
> MSG 099: MSGBUFF = GIM50504S ** OPEN PROCESSING FAILED FOR THE GLOBAL 
> MSG 099: MSGBUFF = ZONE.  
>
>   
 Kurt Quackenbush <[EMAIL PROTECTED]> 3/26/2008 9:21 AM >>>
 
> You didn't show your EPSPT job, so this is a guess, but ensure the 
> SMPCSI DD statement specifies the CSI data set for your global zone 
> (SMPE.ZOS17.GLOBAL.CSI), not the CSI data set name for your target zone. 
>   The PARM then specifies the name of your target zone (PZOS17A).
>
> Kurt Quackenbush -- IBM, SMP/E Development
>
> --
> 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 
>
>   


-- 
Mark Jacobs
Time Customer Service
Tampa, FL


In accordance to the principles of Doublethink, it 
does not matter if the war is not real, or when it 
is, that victory is not possible. The war is not 
meant to be won. It is meant to be continuous.

The essential act of modern warfare is the destruction 
of the produce of human labor. A hierarchical society 
is only possible on the basis of poverty and ignorance. 
In principle, the war effort is always planned to
keep society on the brink of starvation. The war is waged 
by the ruling group against its own subjects. And its 
object is not victory over Eurasia or Eastasia, but to 
keep the very structure of society intact.

George Orwell - 1984

--
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: More SDSF security questions

[Mark Zelden]

On Wed, 26 Mar 2008 08:25:04 -0500, Rich Smrcina <[EMAIL PROTECTED]> wrote:

>Are you referring to the ISFPRM00 parmlib member?
>
>The ISFOPER group starts off like this:
>
>GROUP NAME(ISFOPER),/* Group name  */
>TSOAUTH(JCL,OPER),  /* User must have JCL and OPER */
>ACTION(ALL),/* All route codes displayed   */
>ACTIONBAR(YES), /* Display action bar on panels*/
>APPC(ON),   /* Include APPC sysout */
>AUPDT(2),   /* Minimum auto update interval*/
>AUTH(LOG,I,O,H,DA,PREF,DEST,/* Authorized functions*/
>  SYSID,ACTION,FINDLIM,ST,
>  INIT,PR,ULOG,MAS,SYSNAME,LI,
>  SO,NO,PUN,RDR,JC,SE,RES),
>CMDAUTH(ALL),   /* Commands allowed for all jobs   */
>
>I added:
>
>ILPROC(BATCH),
>
>and refreshed SDSF (F SDSF,REFRESH).
>
>I reran my job and I see just my job.
>
>Dennis Trojak wrote:
>> Add ILPROC=BATCH to your ISFOPER group name parameters in ISFGRP and it
>> should let you run batch jobs with your ISFOPER definitions for
>> userid=P390.
>> Dennis
>>
>
>--
>Rich Smrcina
>VM Assist, Inc.
>Phone: 414-491-6001
>Ans Service:  360-715-2467
>rich.smrcina at vmassist.com
>http://www.linkedin.com/in/richsmrcina
>

Rich,

Have you tried looking at the SDSF Operation and Customization manual?
If so, you can see a similar example.  Just adding ILPROC(BATCH) isn't
good enough.  You need to add an NTBL also.

But I see 2 problems:

1) That still won't get you to fall into the ISFOPER group since it
has TSOAUTH(JCL,OPER) and batch only gets TSOAUTH(JCL).  Did you
read my post from yesterday on this?

2) If you create a group with just TSOAUTH(JCL) and ILPROC(BATCH) and
give it "super user" authority, anyone running SDSF in batch will have that
authority.   

I will walk you though this:

1) Create a new group.  Copy it from ISFOPER or ISFSPROG (depending
on your requirements) and make sure it is defined *prior* to those 
based on TSOAUTH only. 

2) Remove the TSOAUTH() definition from this new group

3) In place of TSOAUTH add  IUID(idgroup1), 

4) Near the end of the ISFPRM00 member define an NTBL:

NTBL NAME(idgroup1)
  NTBLENT STRING(your_userid),OFFSET(1)
  NTBLENT STRING(other_userid1),OFFSET(1)  
  NTBLENT STRING(other_userid2),OFFSET(1)   

where "your_userid" is your userid.  Add other userids as required or
don't define them to that group. 

5) Use the "F SDSF,REFRESH" operator command to refresh the parms.

The authority will be the same from TSO and from batch based on the
userids defined in "idgroup1".

HTH,

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
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: Enhanced PSP Compare Program

[Mark Jacobs]

Matt Dazzo wrote:
> I updated the program to the latest level. I tried to using the global csi 
> and the target csi and I get the following messages. Job ends with cc=0 but I 
> get an error in the report. Any ideas? Thanks
>  +
>   

This is what I use in my job, works fine;

//ZOS18EXEC PGM=EPSPT,PARM='MVST100',COND=(0,NE)  
//STEPLIB  DD   DSN=TECHSVC.TECHNAPF.LOADLIB,DISP=SHR 
//SMPCSI   DD   DSN=SMPE.ZOS18.GLOBAL.CSI,DISP=SHR

Where MVST100 is the name of the target zone.

> Report Level:1.04.11 Last Update:2007/06/28
> For target zone PZOS17A
> HOLD  APAR -RESOLVING SYSMOD-  RELEVANT
> FMID  NUMBER   NAME  RECEIVED  UPGRADE+SUBSET  
> -  
> MSG 010: SEVERE ERROR: Target Zone Query Failed, Report to IBM 
> NOTE: An asterisk denotes an APAR that has been previously 
> mentioned in this report.  
> *  
> *  SUMMARY  *  
> *  
> NO APARs/PTFs required.
> FMIDs  applicable: 0   
> APARs  applied:0   
> APARs  required:   0   
> PTFs   received:   0   
> Report Level:1.04.11 Last Update:2007/06/28
> For target zone PZOS17A
> MSG 019: rc from zone qry = 12
> MSG 010: SEVERE ERROR: Target Zone Query Failed, Report to IBM
> MSG 098: RC =  , CC =   }D \  
> MSG 099: MSGBUFF = GIM44233IGIMMPVIA - A PREALLOCATED VSAM DATA SE
> MSG 099: MSGBUFF = T WAS NOT FOUND FOR THE GLOBAL ZONE.   
> MSG 099: MSGBUFF = GIM50504S ** OPEN PROCESSING FAILED FOR THE GLOBAL 
> MSG 099: MSGBUFF = ZONE.  
>
>   
 Kurt Quackenbush <[EMAIL PROTECTED]> 3/26/2008 9:21 AM >>>
 
> You didn't show your EPSPT job, so this is a guess, but ensure the 
> SMPCSI DD statement specifies the CSI data set for your global zone 
> (SMPE.ZOS17.GLOBAL.CSI), not the CSI data set name for your target zone. 
>   The PARM then specifies the name of your target zone (PZOS17A).
>
> Kurt Quackenbush -- IBM, SMP/E Development
>
> --
> 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
>
>   


-- 
Mark Jacobs
Time Customer Service
Tampa, FL


In accordance to the principles of Doublethink, it 
does not matter if the war is not real, or when it 
is, that victory is not possible. The war is not 
meant to be won. It is meant to be continuous.

The essential act of modern warfare is the destruction 
of the produce of human labor. A hierarchical society 
is only possible on the basis of poverty and ignorance. 
In principle, the war effort is always planned to
keep society on the brink of starvation. The war is waged 
by the ruling group against its own subjects. And its 
object is not victory over Eurasia or Eastasia, but to 
keep the very structure of society intact.

George Orwell - 1984

--
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: Enhanced PSP Compare Program

[Matt Dazzo]

I updated the program to the latest level. I tried to using the global csi and 
the target csi and I get the following messages. Job ends with cc=0 but I get 
an error in the report. Any ideas? Thanks
 
Report Level:1.04.11 Last Update:2007/06/28
For target zone PZOS17A
HOLD  APAR -RESOLVING SYSMOD-  RELEVANT
FMID  NUMBER   NAME  RECEIVED  UPGRADE+SUBSET  
-  
MSG 010: SEVERE ERROR: Target Zone Query Failed, Report to IBM 
NOTE: An asterisk denotes an APAR that has been previously 
mentioned in this report.  
*  
*  SUMMARY  *  
*  
NO APARs/PTFs required.
FMIDs  applicable: 0   
APARs  applied:0   
APARs  required:   0   
PTFs   received:   0   
Report Level:1.04.11 Last Update:2007/06/28
For target zone PZOS17A
MSG 019: rc from zone qry = 12
MSG 010: SEVERE ERROR: Target Zone Query Failed, Report to IBM
MSG 098: RC =  , CC =   }D \  
MSG 099: MSGBUFF = GIM44233IGIMMPVIA - A PREALLOCATED VSAM DATA SE
MSG 099: MSGBUFF = T WAS NOT FOUND FOR THE GLOBAL ZONE.   
MSG 099: MSGBUFF = GIM50504S ** OPEN PROCESSING FAILED FOR THE GLOBAL 
MSG 099: MSGBUFF = ZONE.  

>>> Kurt Quackenbush <[EMAIL PROTECTED]> 3/26/2008 9:21 AM >>>
You didn't show your EPSPT job, so this is a guess, but ensure the 
SMPCSI DD statement specifies the CSI data set for your global zone 
(SMPE.ZOS17.GLOBAL.CSI), not the CSI data set name for your target zone. 
  The PARM then specifies the name of your target zone (PZOS17A).

Kurt Quackenbush -- IBM, SMP/E Development

--
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: More SDSF security questions

[Rich Smrcina]

Are you referring to the ISFPRM00 parmlib member?

The ISFOPER group starts off like this:

GROUP NAME(ISFOPER),/* Group name  */
TSOAUTH(JCL,OPER),  /* User must have JCL and OPER */
ACTION(ALL),/* All route codes displayed   */
ACTIONBAR(YES), /* Display action bar on panels*/
APPC(ON),   /* Include APPC sysout */
AUPDT(2),   /* Minimum auto update interval*/
AUTH(LOG,I,O,H,DA,PREF,DEST,/* Authorized functions*/
 SYSID,ACTION,FINDLIM,ST,
 INIT,PR,ULOG,MAS,SYSNAME,LI,
 SO,NO,PUN,RDR,JC,SE,RES),
CMDAUTH(ALL),   /* Commands allowed for all jobs   */

I added:

ILPROC(BATCH),

and refreshed SDSF (F SDSF,REFRESH).

I reran my job and I see just my job.

Dennis Trojak wrote:

Add ILPROC=BATCH to your ISFOPER group name parameters in ISFGRP and it
should let you run batch jobs with your ISFOPER definitions for
userid=P390.
Dennis 



--
Rich Smrcina
VM Assist, Inc.
Phone: 414-491-6001
Ans Service:  360-715-2467
rich.smrcina at vmassist.com
http://www.linkedin.com/in/richsmrcina

Catch the WAVV!  http://www.wavv.org
WAVV 2008 - Chattanooga - April 18-22, 2008

--
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: Enhanced PSP Compare Program

[Kurt Quackenbush]

You didn't show your EPSPT job, so this is a guess, but ensure the 
SMPCSI DD statement specifies the CSI data set for your global zone 
(SMPE.ZOS17.GLOBAL.CSI), not the CSI data set name for your target zone. 
 The PARM then specifies the name of your target zone (PZOS17A).


Kurt Quackenbush -- IBM, SMP/E Development

--
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: z9 over-heating prevention

[Patrick Falcone]

This kind of also ties into the *gas gauge* available for z9 with driver 
upgrade. I thought this little pdf interesting.
   
  ftp://ftp.software.ibm.com/systems/z/pdf/z9_Gas_Gauge_Driver_manual.pdf
   
  under
   
  http://www-03.ibm.com/systems/z/advantages/energy/index.html

Timothy Sipples <[EMAIL PROTECTED]> wrote:
  One of the more interesting attributes is that the machine will do
everything possible to keep your work moving as best it can even if there's
a double MRU failure. It can slow down the processors to reduce heat. WLM
(assuming z/OS) is still in control, so heat-related forced slowdowns will
tend to disfavor work in lower service classes, starting with purely
discretionary workloads. You're probably already monitoring how well WLM is
meeting its goals, so that's one (indirect) way to get a warning that
something unusual is happening.

I think an MRU failure is a Call Home event, by the way. A technician is
going to initiate a telephone call to schedule installation of a
replacement part, if necessary.

If you're visiting IBM (in Poughkeepsie, for example), they may be able to
simulate a double MRU failure for you so you can see what happens, at least
if you request that demonstration ahead of time.

- - - - -
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: S0C4 in IEBCOPY on z/OS 1.8

[Mark Zelden]

For the archives   

Someone just wrote me about this post from June 2007 and I realized I
never followed up in IBM-MAIN.  

On Fri, 29 Jun 2007 09:54:00 -0500, Mark Zelden <[EMAIL PROTECTED]>
wrote:

>On Fri, 29 Jun 2007 09:47:20 -0400, Petersen, Jim
><[EMAIL PROTECTED]> wrote:
>
>>Wonder if anyone else has experienced this.   We just rolled out z/OS
>>1.8 to our 1st two Test/Dev LPARs and we have encountered a problem.
>>Our DB2 folks were copying a PDSE loadlib and got an IGW message in the
>>IEBCOPY followed by recursive S0C4 and S0C1 abends.  Essentially, until
>>this is resolved, we are stopped dead in our tracks from rolling out
>>z/OS 1.8 any further.
>>
>
>Nope.  But we rolled out to our biggest development environment this
>past weekend.  Even though we have several production LPARs running
>1.8, this was the one I was most concerned about.  Turns out I was right.
>We have 2 open LE issues.  One is an abend in a PL/I 2.3 program running
>in CICS TS 2.3 (also failed in 3.1).   Since it was holding up testing of a
>regulatory change due to go in this weekend, I almost had to back out
>on Tuesday.  We were able to STEPLIB to the z/OS 1.6 version of
>SCEERUN and use that in DFHRPL to get around the problem.  IBM has
>since provided a test fix that will get tested today.   No APAR number yet,
>but there will be one.
>

This first problem dragged on for a while between IBM LE and CICS support
and eventually we found the problem to be caused by an ISV software
product (eXpeditor).  The vendor had a fix for the problem already but
we didn't have it applied.

>The other is a LE U4094 reason 18 in a DB2 program in batch.  Still haven't
>proved it's not an application issue, but the app folks say that pointing
>to the production version of the program gets the same failure and this
>worked last week.  Unfortunately, there is no DB2 data sharing involved
>here, so we can't run this on another LPAR in the sysplex that is still 1.6.
>
>We are still working on getting more diagnostic information for IBM (running
>tests with changes to LE options) for the U4094 reason 18.
>

This was an application problem - actually a JCL problem.  One of those
cases where a hole was probably closed in LE.   The abending program had 
defined an output file as VB LRECL=6110, BLKSIZE=6144.  The output 
records were actually 458 bytes but the JCL had the DCB coded as
DCB=(RECFM=F,LRECL=456,BLKSIZE=456).  

The programmer fixed the JCL to resolve the problem.

--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
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: Is IT becoming extinct?

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Ted MacNEIL
> 
> [ snip ]
> One outsourced their development to India because they 
> couldn't find any new COBOL programmers.

At a price they were willing to pay, perhaps

-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

Re: help

[Daniel McLaughlin]

Sorry, not the American Idol tryouts!

Daniel McLaughlin
Z-Series Systems Programmer
Information & Communications Technology
Crawford & Company
4680 N. Royal Atlanta
Tucker GA 30084 
phone: 770-621-3256 
fax: 770-621-3237
email: [EMAIL PROTECTED]
web: www.crawfordandcompany.com 



IBM Mainframe Discussion List  wrote on 03/26/2008 
07:38:41 AM:

> -- Information from the mail header 
> ---
> Sender:   IBM Mainframe Discussion List 
> Poster:   Jan MOEYERSONS <[EMAIL PROTECTED]>
> Subject:  Re: help
> 
---
> 
> Help! I need somebody,
> Help! Not just anybody,
> Help! You know I need someone,
> To help me!
> 
> When I was young, but so much younger than today,
> I never needed anybody's help in any way,
> But now these days are gone and I'm not so self assured,
> Now I find I've changed my mind I've opened up the doors.
> 
> Help me if you can, I'm feeling down,
> And I do appreciate you being around,
> Help me get my feet back on the ground,
> Won't you please please help me?
> 
> And now my life has changed in oh so many ways,
> My independence seems to vanish in the haze,
> But ev'ry now and then I feel so insecure,
> I know that I just need you like I've never done before.
> 
> Help me if you can, I'm feeling down,
> And I do appreciate you being around,
> Help me get my feet back on the ground,
> Won't you please please help me?
> 
> When I was young, byt so much younger than today,
> I never needed anybody's help in any way,
> But now these days are gone and I'm not so self assured,
> Now I find I've changed my mind I've opened up the doors.
> 
> Help me if you can, I'm feeling down,
> And I do appreciate you being around,
> Help me get my feet back on the ground,
> Won't you please please help me?
> Help me. Help me. Ooh, ooh, ooh!
> 
> --
> 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
> 



Best Overall Third-Party Claims Administrator - 2007 "Business Insurance" 
Readers Choice Awards
 
Consider the environment before printing this message.

This transmission is intended exclusively for the individual or entity to which 
it is addressed. This communication may contain information that is 
confidential, proprietary, privileged or otherwise exempt from disclosure. If 
you are not the named addressee, you are NOT authorized to read, print, retain, 
copy or disseminate this communication, its attachments or any part of them. If 
you have received this communication in error, please notify the sender 
immediately and delete this communication from all computers.  This 
communication does not form any contractual obligation on behalf of the sender, 
the sender's employer, or the employer's parent company, affiliates or 
subsidiaries.

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

[Jan MOEYERSONS]

Help! I need somebody,
Help! Not just anybody,
Help! You know I need someone,
To help me!

When I was young, but so much younger than today,
I never needed anybody's help in any way,
But now these days are gone and I'm not so self assured,
Now I find I've changed my mind I've opened up the doors.

Help me if you can, I'm feeling down,
And I do appreciate you being around,
Help me get my feet back on the ground,
Won't you please please help me?

And now my life has changed in oh so many ways,
My independence seems to vanish in the haze,
But ev'ry now and then I feel so insecure,
I know that I just need you like I've never done before.

Help me if you can, I'm feeling down,
And I do appreciate you being around,
Help me get my feet back on the ground,
Won't you please please help me?

When I was young, byt so much younger than today,
I never needed anybody's help in any way,
But now these days are gone and I'm not so self assured,
Now I find I've changed my mind I've opened up the doors.

Help me if you can, I'm feeling down,
And I do appreciate you being around,
Help me get my feet back on the ground,
Won't you please please help me?
Help me. Help me. Ooh, ooh, ooh!

--
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: Long translate (TR) instruction?

[William H. Blair]

Edward Jaffe wrote:

> The following fragment should work if you prefer looping 
> TRE over traditional TR. TRE requires you to manually 
> translate the so-called "stop" character with an MVC. 
> But, at least there's no EXecute for the final segment.
>
>   LM   R14,R15,xx   Load string ptr and its length
>   LA   R1,xxPtr to translation table
>   XR   R0,R0Set stop char = x'00'
>   DO INFDo for translate
> TRE   R14,R1  Translate the string
> DOEXIT Z  Exit if no more data
> IF O  If iterate needed
>   ITERATE , Process another segment
> ENDIF ,   EndIf
> MVC   0(1,R14),0(R1)  Translate x'00' to whatever
> LAR14,1(,R14) Advance past stop character
> AHI   R15,-1 Decrement length remaining
> DOEXIT NPExit if no more data
>   ENDDO ,   EndDo for translate

Art Celestini wrote:

> It seems that the TRE instruction has been in z/Arch for at 
> least a few years.  If anyone is inclined to try this:
> 
>   XR   R1,R1 Clear for insert
>   LR15,LengthLoad string length
> Loop  IC   R1,Input-1(R15)   Get input byte
>   IC   R0,XlatTab(R1)Get translated character ...
>   STC  R0,Output-1(R15)  ... and store it in output
>   BCT  R15,Loop  Decrement length & loop until done
> 
> it would be interesting to see how it fares against 
> Ed Jaffe's code.

I did this, since I had a program I could just plug these code
segments into without doing a lot of work.  Results are below.

> I believe the OP said that the data to be translated had to 
> first be moved from one buffer to another.  The above does 
> that, but a move of some type needs to be added to Ed's code 
> to make it a true comparison.

Maybe, maybe not. I've got code that needs to translate stuff
in a buffer and it does not need it moved. And I have other
code that first moves it and then translates it, because it
doesn't want to clobber what it's translating. But, I did it
both ways, just to find out for sure if it made a difference.
It does not. The TRE loop is so much faster for any substantial
number of bytes (which I define as more than 256, since that
number or less can be handled directly, inline, simply by using 
the TR instruction) that the overhead of even a MVCL does not
even begin to eat into the gain by using a TRE loop. So, the
fact that with a TRE loop subroutine or macro you might whip
up you first have to move the data to be translated if you do
not want the original data clobbered is simply not relevant
from a performance perspective. Since there is no use for the 
non-TRE loop subroutine (because its performance is horrible
for any substantial number of bytes), we are left with the TRE
or TR subroutines, which translate the data directly in the 
buffer provided, which is what most programmers would want to 
have available to call most of the time anyway, IMHO. If not, 
then they would first have had to move the data to some other 
buffer before TR'ing it anyway.

As you will see below, the TRE loop was faster for me when I
gave it more than 7 to 19 bytes. I'd never give it that few
since for anything <= 256 I'd just code a TR inline. But if
I didn't know how many bytes, then you can see that there is
plenty of CPU time left to test for 256 or less and do a TR
inline if so, or else call the TR[E] subroutine if I had more
than 256.  Regardless, an ordinary TR loop is still faster 
than using TRE. But this is what you would expect. The TR
loop code is not any more complicated than the TRE loop code
in the first place. It's just different. TRE does not replace
TR. It's for another purpose, basically, not for performance.

I revised the code above to suit my own personal taste and
needs. I made an improvement in the TRE subroutine proposed 
by Edward Jaffe to allow the caller to specify the "test" 
character, so that performance will not suffer if the data 
to be translated contains a lot of null bytes (as Ed's would). 
That meant that the MVC had to become an IC + STC. 

Here is the code for the subroutines I called repeatedly to
gather the timing figures: 

**--
**   
** NOTE: ENTER VIABAS   R8,NOTR WITH REGS SET AS FOLLOWS:   
**   R14 = INPUT BUFFER ADDRESS 
**   R15 = OUTPUT BUFFER ADDRESS
**   R0  = LENGTH OF BOTH INPUT AND OUTPUT BUFFER (MAY BE ZERO) 
**   R1  = 256-BYTE TRANSLATE TABLE ADDRESS 
**   
**--
NOTR LTR   R2,R0 

Re: Console exits

[Dave Cartwright]

On Tue, 25 Mar 2008 13:35:28 -0400, Mark Pace <[EMAIL PROTECTED]> 
wrote:

>I would like to write a console exit. I have an example for msg IEE362A, but
>it is a single line message.  The message I want to trap and process is
>IEE391A which is a multiple line message.  Can anyone point me at the manual
>that describes exits for the console?
>


Don't bother, that wheel has been invented many times before. IMHO the best 
solution is TSSO off the CBT tape, but be sure to get the latest version from 
the Updates section.  Browse through file 001 for other console exits.  I put 
the MLWTO code into TSSO and I'm sorry but I can't remember what manuals.  
Certainly Volume 1 of System Messages for the message format and in the 
case of TSSO the Sub-System Intefaces guide.  Do they still do System Exits?

http://cbttape.org/


Good luck
Dave

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

Jonathan Miller/PHEAA is out of the office.

[Jonathan Miller]

I will be out of the office starting  03/26/2008 and will not return until
03/27/2008.



==
This message contains privileged and confidential information intended for the 
above addressees only.  If you
receive this message in error please delete or destroy this message and/or 
attachments.  

The sender of this message will fully cooperate in the civil and criminal 
prosecution of any individual engaging
in the unauthorized use of this 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: SMF System Logger - limitations of MANx

[Vernooy, C.P. - SPLXM]

"R.S." <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> Mark Zelden wrote:
> [...]
> > As mentioned... lots in the archives about this (even before the
recent
> > threads).
> > 
> > 1) Speed of offloading (being able to keep up with records being
written).  
> IMHO I can live with it (YMMV). In case of SMF (expected & accepted) 
> flood I can use more MANx datasets as a spill.

This is not the solution: I have seen occasions where records are
presented to SMF faster that SMF can write them to MANx. This will cause
SMF to run out of buffers with records lost as a consequence.

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.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286 
**

--
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: Is IT becoming extinct?

[R.S.]

Ian wrote:

I did a polls recently to see what new development is happening on CICS
specifically.
The result was very surprising. Out of 190 votes only 5% said that they have
no new development plans.
48% said that the new development is in Natural
28% said COBOL


1. This is based on 190 votes. Only 190.
2. This thread is about COBOL popularity. IMHO it is quite obvious that 
CICS environment is biased. As well as mainframe at all (at least z/OS 
and VSE). It's like asking VSAM users "what's your favority operating 
system?".


BTW: Someone mentioned huge value of COBOL code (10T$).
1. How it is measured ?
2. What about other language's value? Maybe this value is only half of 
C's value? Such number, without any comparison proves nothing.


My $0.02 (how it's measured ? )
--
Radoslaw Skorupka
Lodz, Poland


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

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

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA  wynosi 
118.642.672 zote i zosta w caoci wpacony.

--
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: z9 over-heating prevention

[Timothy Sipples]

One of the more interesting attributes is that the machine will do
everything possible to keep your work moving as best it can even if there's
a double MRU failure. It can slow down the processors to reduce heat. WLM
(assuming z/OS) is still in control, so heat-related forced slowdowns will
tend to disfavor work in lower service classes, starting with purely
discretionary workloads. You're probably already monitoring how well WLM is
meeting its goals, so that's one (indirect) way to get a warning that
something unusual is happening.

I think an MRU failure is a Call Home event, by the way. A technician is
going to initiate a telephone call to schedule installation of a
replacement part, if necessary.

If you're visiting IBM (in Poughkeepsie, for example), they may be able to
simulate a double MRU failure for you so you can see what happens, at least
if you request that demonstration ahead of time.

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