AW: MF TCO Infrastructure Estimate - Medium Size Shop

[Uwe Oswald]

I would say that the major costs are software licenses. Hence with the given 
information you can't calculate TCO.

Best wishes from Germany
Uwe

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag 
von George Henke
Gesendet: Mittwoch, 1. August 2012 19:58
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: MF TCO Infrastructure Estimate - Medium Size Shop

I know this is a lot to ask, but does anyone have a rough idea of the TCO 
HW/SW/FTE, infrastructure and operations only, for a medium size shop with:


   - 8 LPARs across 2 CECs,
   - z/VM (2 instances),
   - zLINUX, z/OS (4 instances),
   - CICS (200 instances),
   - MQ, but no DB2.
   - the standard suite of PPs, and
   - 9.25 FTEs?


Once again, this is infrastructure and operations only, exclusive of 
applications or development.

Ballpark would be fine.
--
George Henke
(C) 845 401 5614

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

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

Re: REXX/SDSF ISFLOG ' failure'

[Henri Kuiper]

Just found the answer. Most docs specify 1.11 as minimal but it seems
ISFLOG was only added in 1.12

http://publib.boulder.ibm.com/infocenter/ieduasst/stgv1r0/topic/com.ibm.iea.zos/zos/1.13/Application-Middleware-Workload_Enablement/zOS_V1R13_SDSF_REXX-Operlog-Support.pdf

" .. SDSF/REXX was introduced in SDSF V1R9 and the ISFLOG command was
added in SDSF V1R12 to read or allocate syslog. ."

Thanks for your help!

On Wed, Aug 22, 2012 at 3:43 PM, Lizette Koehler wrote:

> Is there any dependence on the JES Activation level?
>
> Lizette
>
> >
> > I know the doc states that it will, I just can't seem to recall why it
> doesn't.  Possibly
> > just ptf's.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf
> > Of Henri Kuiper
> > Sent: Wednesday, August 22, 2012 8:23 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: REXX/SDSF ISFLOG ' failure'
> >
> > Bill,
> >
> > Thanks for your reply.
> > Weird, because the docs state it should be at level 1.11 ;(
> >
> > See http://ibmmainframeforum.com/viewtopic.php?f=31&t=6352 too.
> >
> > Someone there states it's working under z/OS 1.11
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: X86 server

[R.S.]

W dniu 2012-08-23 04:23, McKown, John pisze:

X64 hardware, as much as it has improved, is still not as reliable or
have the I/O capacity of the z hardware. E.g.: We had a TCM fail
once. A spare picked up the work, automatically restarting the
instruction stream, with no outage of any sort and no software
involvement. X86, from what I'm told, would at least require the OS
to do the equivalent of a checkpoint restart. Also had an OSA fail.
The other OSA did an ARP takeover and no IP sessions were lost. TCPIP
was informed, but all it did was put out a message and not start any
new sessions on the failing OSA. Our "open" people called me a liar
when I told them that.


So ?
We know:
- mainframe HW is more reliable and more "redundant" than pc HW.
- even mainframe HW sometimes do fail.

Now we have the followig choices:
- use one OSA card or more and pay for that
- use single BOOK configuration, or pay for more BOOKs
- use single CPC or multiple sysplexedd CPCs
- etc. etc

So, we have some choice: you may want more reliable equipment and pay 
more or less reliable one and pay less.
X64 would be another option to pay less for less reliablity. But it's 
not due to decision of IBM. And it has very little to do with 
technology, it has a lot of to do with business nd politics.





--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2012 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.410.984 złotych.



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

Re: disable zIIP usage for the remaining part of one Job

[Rob Scott]

The interface to control a program usage of zIIPs is a licensed feature that 
ISVs will build into their products - it is not something that is exposed to 
"normal" customers.

If you wish to disable zIIP processing for a specific program step, your only 
options as I see it are :

(1) Contact the vendor of the program to see if they have any runtime options 
to disable the zIIP usage by their code

Or

(2) Put a "wait on WTOR" jobstep in the JCL before the program jobstep and then 
manually vary the zIIP processor offline before replying to the WTOR.


Option (2) is obvious overkill - however it might be possible on a 
non-production system without too many complaints :-)  


Rob Scott
Lead Developer
Rocket Software
77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA
Tel: +1.781.684.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Monika Amiss
Sent: 23 August 2012 07:56
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: disable zIIP usage for the remaining part of one Job

Dear Group,

 do I have a chance to disable zIIP-usage during a job run by calling an 
Assembler program which does the disable. The disable should be only for this 
STEP.

  Any hint appreciated, with best regards Monika 

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

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

Re: ISPF Panel and LPAR name

[David Stokes]

>> But 'search engines' are for entertainment purposes - an  industry runs on 
>>science and engineering, not art and entertainment.

Wow, is this some kind of alternate universe thing?

Date:Wed, 22 Aug 2012 08:22:17 +0100
From:CM Poncelet 
Subject: Re: ISPF Panel and LPAR name

... because it is moving back towards suppressing intelligence (as Mao 
Tse Tung did in China, in the 1960s). We should not all be obliged to 
look at pictures just because the majority of people cannot read.

Yes, I understand the usefulness of Google's query completion etc. But 
'search engines' are for entertainment purposes - and industry runs on 
science and engineering, not art and entertainment.

You need to type the dataset name on every ISPF panel only because you 
are still invoking IBM's 'demo' (now default/'de facto') panels.

You can bypass ISR@PRIM at logon and display your own panels instead - 
then store, retrieve and display in them the datasets you want to 
access, e.g. by a VGET () on initial display of your panels 
and by a VPUT to save them (and any changes to them) on exit, from/to 
your profile pool. If you then take copies of the default ISPF panels, 
add to them the name of a variable which contains the DSN you want to 
process (and that is stored in your panels, e.g. &DSNA) - and you then 
save these modified ISPF panels in a dataset concatenated ahead of the 
default one on ISPPLIB - they will now be the ones that are displayed. 
If you next create TSO commands (in a table in ISPTLIB) which are 
associated with the ISPF functions you want to invoke (passing e.g. 
&DSNA to them), then issue your TSO commands (e.g. 'BR' for Browse or 
'ED' for Edit etc.), your modified ISPF panels will now contain your 
selected DSN. If you set PANELID ON, you will see the names of which 
panels you need to copy and modify. Admittedly, there is a bit more to 
it than that; but I'm sure you can figure it out.

BTW Bear in mind that Google now tracks everywhere you go on the web ... 
and then sells your info to advertisers : 
http://www.dailymail.co.uk/sciencetech/article-2105435/Three-simple-steps-delete-Google-browsing-history--late.html
 


Cheers, Chris Poncelet


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

Re: disable zIIP usage for the remaining part of one Job

[Robin Atwood]

I am have no experience using zIIPs but if an operator can offline one, so can 
NetView using the BCPii ProcOPs interface. Your batch step could issue a WTO 
that triggers an appropriate NetView Rexx script. Assuming you have NetView, of 
course. :)

HTH
-Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rob Scott
Sent: 23 August 2012 16:25
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: disable zIIP usage for the remaining part of one Job

The interface to control a program usage of zIIPs is a licensed feature that 
ISVs will build into their products - it is not something that is exposed to 
"normal" customers.

If you wish to disable zIIP processing for a specific program step, your only 
options as I see it are :

(1) Contact the vendor of the program to see if they have any runtime options 
to disable the zIIP usage by their code

Or

(2) Put a "wait on WTOR" jobstep in the JCL before the program jobstep and then 
manually vary the zIIP processor offline before replying to the WTOR.


Option (2) is obvious overkill - however it might be possible on a 
non-production system without too many complaints :-)  


Rob Scott
Lead Developer
Rocket Software
77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA
Tel: +1.781.684.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Monika Amiss
Sent: 23 August 2012 07:56
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: disable zIIP usage for the remaining part of one Job

Dear Group,

 do I have a chance to disable zIIP-usage during a job run by calling an 
Assembler program which does the disable. The disable should be only for this 
STEP.

  Any hint appreciated, with best regards Monika 

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

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN This message has been 
scanned by MailController - portal1.mailcontroller.co.uk

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

Re: ISPF Panel and LPAR name

[CM Poncelet]

Not quite. The 'real universe' produces the bread; the 'alternate 
universe' eats it. Cheers, CP


David Stokes wrote:

But 'search engines' are for entertainment purposes - an  industry runs on 
science and engineering, not art and entertainment.
 



Wow, is this some kind of alternate universe thing?

Date:Wed, 22 Aug 2012 08:22:17 +0100
From:CM Poncelet 
Subject: Re: ISPF Panel and LPAR name

... because it is moving back towards suppressing intelligence (as Mao 
Tse Tung did in China, in the 1960s). We should not all be obliged to 
look at pictures just because the majority of people cannot read.


Yes, I understand the usefulness of Google's query completion etc. But 
'search engines' are for entertainment purposes - and industry runs on 
science and engineering, not art and entertainment.


You need to type the dataset name on every ISPF panel only because you 
are still invoking IBM's 'demo' (now default/'de facto') panels.


You can bypass ISR@PRIM at logon and display your own panels instead - 
then store, retrieve and display in them the datasets you want to 
access, e.g. by a VGET () on initial display of your panels 
and by a VPUT to save them (and any changes to them) on exit, from/to 
your profile pool. If you then take copies of the default ISPF panels, 
add to them the name of a variable which contains the DSN you want to 
process (and that is stored in your panels, e.g. &DSNA) - and you then 
save these modified ISPF panels in a dataset concatenated ahead of the 
default one on ISPPLIB - they will now be the ones that are displayed. 
If you next create TSO commands (in a table in ISPTLIB) which are 
associated with the ISPF functions you want to invoke (passing e.g. 
&DSNA to them), then issue your TSO commands (e.g. 'BR' for Browse or 
'ED' for Edit etc.), your modified ISPF panels will now contain your 
selected DSN. If you set PANELID ON, you will see the names of which 
panels you need to copy and modify. Admittedly, there is a bit more to 
it than that; but I'm sure you can figure it out.


BTW Bear in mind that Google now tracks everywhere you go on the web ... 
and then sells your info to advertisers : 
http://www.dailymail.co.uk/sciencetech/article-2105435/Three-simple-steps-delete-Google-browsing-history--late.html 



Cheers, Chris Poncelet


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



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

"Delay" Problem with SSL and DVIPA

[Mauri Kanter]

Good morning list,

We are facing a strange "delay" problem with TN3270 and SSL which I describe 
below. 

The configuration is as follows: 
PRD1 and PRD2 are production LPARs. 
DEV1 and DEV2 are development LPARs 
PRD1 and DEV1 are on a z114 machine with two OSA cards shared among the LPARs 
PRD2 and DEV2 are on another z114 machine also with two OSA cards shared among 
the LPARs. 
Neither the machines nor the OSA cards are exactly equal but they are very 
similar in many aspects (mips, workload, etc) 

No network problems from the performance point of view… 

Ping times from my desktop are very good for all the IP addresses described 
below. And Normal work is ok. Everybody is happy. 

Below the several IP addresses involved: 
Each OSA card has an IP address. 
Each LPAR has a local VIPA for that LPAR. 
Each subplex has a dynamic DVIPA. 
DEV1 has VIPADEF defined on the VIPADynamic statement 
DEV2 has VIPABackup defined on the VIPADynamic statement 
PRD1 has VIPABackup defined on the VIPADynamic statement 
PRD2 has VIPADEF defined on the VIPADynamic statement 

For example: VIPADEF MOVE IMMED SERVICEMGR 255.255.255.240 xxx.xxx.xxx.xxx 

We use SSL to connect to TN2370. 

There is no VIPADIST DEFINE statement neither for the TN3270 SSL port nor the 
non-SSL port . 
When connecting via SSL to the TN3270 server of DEV1 using the DVIPA of the 
development subplex performance is very good. 
When connecting via SSL to the TN3270 servers of all the lpar VIPAs the 
performance is very good for all 4 LPARs. 

In particular, when pointing PCOMM to the lpar VIPA belonging to PRD2 the 
USSTAB shows up immediately in almost "no time" 

However … When pointing PCOMM to the DVIPA belonging to the production subplex 
it may take 5 seconds to get the USSTAB. According to our definitions, the LU 
name I get, and what I see from NETSTAT HOME, I see that the DVIPA is held by 
PRD2. 

To make things more confusing, if I use the non-SSL port of the TN3270 the 
"delay" disappears. 

So I do not understand if the problem is SSL, the network, or the distributor. 
I'm missing something here … 

Any ideas what to look for? The problem was reported to me lately and also 
lately we migrated to z/OS 1.13 from 1.11, but I can not confirm for granted 
that z/OS 1.13 is related to the problem. 

Thanks in advance for your help. 

Mauri. 

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

Re: SMF Type 99 quandry

[Scott Chapman]

I don't believe the policy interval has changed.  

There are multiple subtypes though, some of which may be useful to collect.  If 
you look in the SMF manual, you will see that there are several records that 
are written "every policy interval for each ".  In my experience, turning 
off at subtypes 1, 2, and 3 will avoid most of the volume, although not all of 
the remaining subtypes are necessarily directly useful to customers either.  Of 
the remaining subtypes, I most often use the subtype 6s.  But my approach to 
SMF data is to collect it all, until something becomes completely unbearable, 
just in case I need the data to analyze a problem.  My only exclusions at the 
moment are:
NOTYPE(92(10,11),99(1,2,3))

I just checked one of my busy systems from an hour yesterday afternoon and it 
generated just under 3 type 99s per second with an average length of 818 bytes. 
 Your results will vary.  

It would be nice if the report showed the subtypes and the volume by data size 
instead of just record counts, instead of having to write your own code, or use 
somebody else's to determine that.  Cheryl Watson wrote about some options: 
www.watsonwalker.com/SMFCounts.pdf

Scott Chapman

On Wed, 22 Aug 2012 13:06:38 -0700, Mark Yuhas  wrote:

>constructed ones is more than I expected.  I reviewed the SUMMARY
>ACTIVITY REPORT and discovered an inordinate amount of Type 99 records.
>
>I did some calculations for each LPAR and discovered that, on average,
>there are 5.16 Type 99 records being written every second.  Not one
>every 10 seconds.  Either the policy interval time length has changed or
>these Type 99 records are being written by some other component.
>

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

Changing Size of DFSMShsm Auto Backups of the Control Datasets

[George Rodriguez]

I found in the  z/OS DFSMShsm Implementation and Customization Guide,
member ALLOCBK1, which provides a sample job that defines four backup
versions of each control dataset and allocates those backup versions on
DASD volumes. I modified the JCL to allocate six backup versions that
mirrors what's out there now, but I don't know how to get DFSMShsm to use
the new allocations.

My original problem is that the MCDS is under allocated cylinders (20,5)
and I've reached the 16 extent limit.

Thanks in advance for the help!
*
*
*George Rodriguez*
*Specialist II - IT Solutions*
*Application Support / Quality Assurance*
*PX - 47652*
*(561) 357-7652 (office)*
*(561) 707-3496 (mobile)*
*School District of Palm Beach County*
*3348 Forest Hill Blvd.*
*Room B-251*
*West Palm Beach, FL. 33406-5869*
*Florida's Only A-Rated Urban District For Eighth Consecutive Years*

-- 


*Accredited District Since 2008; Re-certification - January 2013*

Home of Florida's first LEED Gold Certified School

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Changing Size of DFSMShsm Auto Backups of the Control Datasets

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

George,

There is an informational APAR describing how to do this, except you don't 
really need to. Just rename your current backup versions and allocate new ones 
using the same versions.

Regards,
Dave O'Brien

-Original Message-
From: George Rodriguez [mailto:george.rodrig...@palmbeachschools.org] 
Sent: Thursday, August 23, 2012 7:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Changing Size of DFSMShsm Auto Backups of the Control Datasets

I found in the  z/OS DFSMShsm Implementation and Customization Guide, member 
ALLOCBK1, which provides a sample job that defines four backup versions of each 
control dataset and allocates those backup versions on DASD volumes. I modified 
the JCL to allocate six backup versions that mirrors what's out there now, but 
I don't know how to get DFSMShsm to use the new allocations.

My original problem is that the MCDS is under allocated cylinders (20,5) and 
I've reached the 16 extent limit.

Thanks in advance for the help!
*
*
*George Rodriguez*
*Specialist II - IT Solutions*
*Application Support / Quality Assurance* *PX - 47652*
*(561) 357-7652 (office)*
*(561) 707-3496 (mobile)*
*School District of Palm Beach County*
*3348 Forest Hill Blvd.*
*Room B-251*
*West Palm Beach, FL. 33406-5869*
*Florida's Only A-Rated Urban District For Eighth Consecutive Years*

-- 


*Accredited District Since 2008; Re-certification - January 2013*

Home of Florida's first LEED Gold Certified School

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 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: ISPF Panel and LPAR name

[CM Poncelet]

Solomon's Book of Proverbs, chapter 26 verse 5

Shmuel Metz (Seymour J.) wrote:


In <50342f7d.6030...@bcs.org.uk>, on 08/22/2012
  at 02:01 AM, CM Poncelet  said:

 


Is that so?
   



Yes, they know what they are doing and why.

 



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

Re: X86 server

[McKown, John]

From what I recall from some time ago (my personal memory is like FLASH - the 
more I write, the more it is "worn out" and the faster it fails), back when 
PSI(?) had a z emulator on Itanium, IBM sued them. Some of the reasons given 
were: 
(1) that z/OS had a reputation in the field for extreme reliability; 
(2) much of z/OS's reliability was based on the z hardware's reliability and 
automatic recovery from errors; 
(3) allowing z/OS to run on non-z hardware would decrease z/OS's reliability 
due to decreased hardware reliability; 
(4) such reduction in reliability would adversely impact z/OS's reputation in 
the market place; 
(5) this would negatively impact sales and increase support costs
(6) therefore, allowing z/OS to run on non-z hardware (at least in a 
non-development environment) was not in IBM's best interest.

I know you pointed out that (as we say around here), the user can "risk assess" 
and accept the decreased reliability in return for decreased cost. IMO, that's 
one of the reasons for running MS-Windows servers. But I also know, at least 
from what I've experienced, that despite this "risk acceptance", that end users 
will complain loudly if they don't get what they're used to. I'm going to catch 
hell today for just this reason. I was _forced_ to make an ACS change to our 
STORCLAS SMS routine. We had allocated a special storage group for a specific 
set of data set names, which started with a given HLQ . We did this, with the 
provision that they would not be recovered at Disaster Recovery. This was 
accepted. Back then. However, in our latest D.R. test, we "caught hell" because 
those "production" data sets were not available. We said, "We know. That was 
agreed to when we separated them into their own pool." They said, "Well that's 
not acceptable anymore." Us: "You agreed to back up what you needed yourself." 
Them: "Well, we changed our mind!!" So I had to make an emergency change. Our 
ACS routines are "fragile" and I missed a change. This, after a few hours, 
caused disk space errors. And I got charged with all the problems associated 
with it because I am the one who made the change. I now don't believe much of 
anybody when they say that they will accept any responsibility for anything. 
Given time, they will renege on any agreement that they possibly can get away 
with reneging on. I am getting very cynical and sick of people in my old age.

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

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

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


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of R.S.
> Sent: Thursday, August 23, 2012 4:11 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: X86 server
> 
> W dniu 2012-08-23 04:23, McKown, John pisze:
> > X64 hardware, as much as it has improved, is still not as reliable or
> > have the I/O capacity of the z hardware. E.g.: We had a TCM fail
> > once. A spare picked up the work, automatically restarting the
> > instruction stream, with no outage of any sort and no software
> > involvement. X86, from what I'm told, would at least require the OS
> > to do the equivalent of a checkpoint restart. Also had an OSA fail.
> > The other OSA did an ARP takeover and no IP sessions were lost. TCPIP
> > was informed, but all it did was put out a message and not start any
> > new sessions on the failing OSA. Our "open" people called me a liar
> > when I told them that.
> 
> So ?
> We know:
> - mainframe HW is more reliable and more "redundant" than pc HW.
> - even mainframe HW sometimes do fail.
> 
> Now we have the followig choices:
> - use one OSA card or more and pay for that
> - use single BOOK configuration, or pay for more BOOKs
> - use single CPC or multiple sysplexedd CPCs
> - etc. etc
> 
> So, we have some choice: you may want more reliable equipment and pay
> more or less reliable one and pay less.
> X64 would be another option to pay less for less reliablity. But it's
> not due to decision of IBM. And it has very little to do with
> technology, it has a lot of to do with business nd politics.
> 
> 
> 
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> 
> 
> 
> 
> --
> Treść tej wiadomości może zawierać informacje prawnie chronione Banku
> przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być
> jedynie jej adresat z wyłączeniem dostępu osób trzecich. Je

Re: Changing Size of DFSMShsm Auto Backups of the Control Datasets

[Mike Schwab]

Run a consolidate on the dataset or defrag the volume (which would
also release extents, which could be bad on system data sets that are
limited to 1 extent).

Say, could we make that a customer request?

"Defrag should not release space if the secondary space amount is 0."

On Thu, Aug 23, 2012 at 6:51 AM, O'Brien, David W. (NIH/CIT) [C]
 wrote:
> George,
>
> There is an informational APAR describing how to do this, except you don't 
> really need to. Just rename your current backup versions and allocate new 
> ones using the same versions.
>
> Regards,
> Dave O'Brien
>
> -Original Message-
> From: George Rodriguez [mailto:george.rodrig...@palmbeachschools.org]
> Sent: Thursday, August 23, 2012 7:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Changing Size of DFSMShsm Auto Backups of the Control Datasets
>
> I found in the  z/OS DFSMShsm Implementation and Customization Guide, member 
> ALLOCBK1, which provides a sample job that defines four backup versions of 
> each control dataset and allocates those backup versions on DASD volumes. I 
> modified the JCL to allocate six backup versions that mirrors what's out 
> there now, but I don't know how to get DFSMShsm to use the new allocations.
>
> My original problem is that the MCDS is under allocated cylinders (20,5) and 
> I've reached the 16 extent limit.
>
> Thanks in advance for the help!
> *
> *
> *George Rodriguez*
> *Specialist II - IT Solutions*
> *Application Support / Quality Assurance* *PX - 47652*
> *(561) 357-7652 (office)*
> *(561) 707-3496 (mobile)*
> *School District of Palm Beach County*
> *3348 Forest Hill Blvd.*
> *Room B-251*
> *West Palm Beach, FL. 33406-5869*
> *Florida's Only A-Rated Urban District For Eighth Consecutive Years*
>
> --
>
>
> *Accredited District Since 2008; Re-certification - January 2013*
>
> Home of Florida's first LEED Gold Certified School
>
> 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 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Re: ISPF Panel and LPAR name

[Shmuel Metz (Seymour J.)]

In <645893134704.wa.paulgboulderaim@listserv.ua.edu>, on
08/22/2012
   at 09:36 AM, Paul Gilmartin  said:

>But isn't ISPF itself a large step moving TSO in the direction of
>what Windows later became? 

No.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: ISPF Panel and LPAR name

[Shmuel Metz (Seymour J.)]

In
,
on 08/22/2012
   at 10:54 AM, Kirk Talman  said:

>More accurately a session manager is Windows for z/OS.

Not even close. While I have had issues with TPX, the comparison is
still insulting.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: disable zIIP usage for the remaining part of one Job

[Lizette Koehler]

Some of the answers you have received is to vary the zIIP offline for the
remainder of the job.  Just be aware that this will probably affect all jobs
that could have used the zIIP during that time.

I would go with the other options, go to the support of the JOB and get them
to restructure it.

You did not explain why you want the zIIP disabled for this job.  Are you
able to provide that information?
If the code is an ISV, then definitely go to them for assistance, if it is
homegrown program, what is the requirement to turn off the zIIP?

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf
> Of Monika Amiss
> Sent: Wednesday, August 22, 2012 11:56 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: disable zIIP usage for the remaining part of one Job
> 
> Dear Group,
> 
>  do I have a chance to disable zIIP-usage during a job run by calling an
Assembler
> program which does the disable. The disable should be only for this STEP.
> 
>   Any hint appreciated, with best regards Monika
> 

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

Re: mvcl/mvcle padding byte

[Paul Schuster]

Actually I am interested to know if using the padding byte of x'B8' would be 
beneficial in clearing storage for a program's save area/local dynamic storage 
area since the program's save area would definitely be referenced.

Thank you.

Paul

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

Re: X86 server

[Uriel Carrasquilla]

When I think about zOS (MVS), I think about a solid reputation where RAS was 
the goal.
When I think Intel, I think about all the problems my company is willing to put 
up with because the applications require Windows (or Linux).
I can see why IBM will want to protect the zOS name and why IBM continues to 
invest in the MF HW business.  It is profitable, yes.  But then again, 
Microsoft is profitable and they did not built a business based on reliability 
but functionality and a GUI.
I subscribe to the idea that IBM must do what they can to protect their 
investment on the MF and that may be a the expense of turning off some 
customers.


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
R.S. [r.skoru...@bremultibank.com.pl]
Sent: Thursday, August 23, 2012 5:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: X86 server

W dniu 2012-08-23 04:23, McKown, John pisze:
> X64 hardware, as much as it has improved, is still not as reliable or
> have the I/O capacity of the z hardware. E.g.: We had a TCM fail
> once. A spare picked up the work, automatically restarting the
> instruction stream, with no outage of any sort and no software
> involvement. X86, from what I'm told, would at least require the OS
> to do the equivalent of a checkpoint restart. Also had an OSA fail.
> The other OSA did an ARP takeover and no IP sessions were lost. TCPIP
> was informed, but all it did was put out a message and not start any
> new sessions on the failing OSA. Our "open" people called me a liar
> when I told them that.

So ?
We know:
- mainframe HW is more reliable and more "redundant" than pc HW.
- even mainframe HW sometimes do fail.

Now we have the followig choices:
- use one OSA card or more and pay for that
- use single BOOK configuration, or pay for more BOOKs
- use single CPC or multiple sysplexedd CPCs
- etc. etc

So, we have some choice: you may want more reliable equipment and pay
more or less reliable one and pay less.
X64 would be another option to pay less for less reliablity. But it's
not due to decision of IBM. And it has very little to do with
technology, it has a lot of to do with business nd politics.




--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorised to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88.
Według stanu na dzień 01.01.2012 r. kapitał zakładowy BRE Banku SA (w całości 
wpłacony) wynosi 168.410.984 złotych.


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

Re: SMF Type 99 quandry

[Horst Sinram]

> According to the MVS Programming Workload Management Services manual, *a*
> Type SMF 99 record is written every policy interval (approximately 
> 10seconds). 

Mark, I don't think the book is saying that.  It says "SRM writes type 99 
record*s* for each policy interval, or approximately once every 10 seconds." 
In the MVS System Management Facilities (SMF) book 
(http://publibz.boulder.ibm.com/epubs/pdf/iea2g2c1.pdf) you can find a summary 
of what subtypes are written. And subtype 12-14 are written every 2 sec but 
they are very small as well.
Kind regards - Horst Sinram
IBM z/OS Workload Management & Capacity Management

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

Re: MF TCO Infrastructure Estimate - Medium Size Shop

[Uriel Carrasquilla]

We have a z10 with 7 IFLs using 1 CEC with two zVM production systems (2 LPAR) 
running about 80 Linux SuSE guests.
The same z10 has zOS with DB2, CICS, MQ, ACF2, SAVRS, TMS and your standard IBM 
companion facilities.
We did a TCO and software is your main entry.
I might be able to share information on how we did the TCO but suspect our 
lawyers would not let me give you our numbers.


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Edward Jaffe [edja...@phoenixsoftware.com]
Sent: Wednesday, August 22, 2012 5:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MF TCO Infrastructure Estimate - Medium Size Shop

On 8/1/2012 10:57 AM, George Henke wrote:
> I know this is a lot to ask, but does anyone have a rough idea of the TCO
> HW/SW/FTE, infrastructure and operations only, for a medium size shop with:
>
>
> - 8 LPARs across 2 CECs,
> - z/VM (2 instances),
> - zLINUX, z/OS (4 instances),
> - CICS (200 instances),
> - MQ, but no DB2.
> - the standard suite of PPs, and
> - 9.25 FTEs?
>
>
> Once again, this is infrastructure and operations only, exclusive of
> applications or development.
>
> Ballpark would be fine.

Before making any TCO calculations, I recommend taking a look at David
Rhoderick's excellent presentation from SHARE in Anaheim: zEnterprise Economics.
http://www.share.org/p/do/sd/topic=173&sid=4169

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

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

Re: X86 server

[Phil Smith]

John McKown wrote:
>From what I recall from some time ago (my personal memory is like FLASH - the 
>more I write, the more it is "worn out" and the faster it fails), back when 
>PSI(?) had a z emulator on Itanium, IBM sued them. Some of the reasons given 
>were:
>(1) that z/OS had a reputation in the field for extreme reliability;
>(2) much of z/OS's reliability was based on the z hardware's reliability and 
>automatic recovery from errors;
>(3) allowing z/OS to run on non-z hardware would decrease z/OS's reliability 
>due to decreased hardware reliability;
>(4) such reduction in reliability would adversely impact z/OS's reputation in 
>the market place;
>(5) this would negatively impact sales and increase support costs
>(6) therefore, allowing z/OS to run on non-z hardware (at least in a 
>non-development environment) was not in IBM's best interest.

Platform Solutions. They were indeed using a firmware layer on Itanium, built 
based on the old Amdahl IP.

Although the points you cite were part of the suit, the real meat of the issue 
was IBM's alleging that PSI had violated intellectual property agreements, as 
well as for encouraging violation of its licensing agreements. IBM finally put 
them out of their misery by buying them in 2008.
--
...phsiii

Phil Smith III
p...@voltage.com
Voltage Security, Inc.
www.voltage.com
(703) 476-4511 (home office)
(703) 568-6662 (cell)


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

Re: X86 server

[Bill Fairchild]

"We will accept responsibility for ..." to me sounds a lot like "if elected, I 
promise to ...".

Welcome to human reality.  It is part of the normal growth process to uncover 
and discard delusions.  Mencken said that the cynics were right 90 percent of 
the time.

Bill Fairchild
Programmer
Rocket Software
408 Chamberlain Park Lane • Franklin, TN 37069-2526 • USA
t: +1.617.614.4503 •  e: bfairch...@rocketsoftware.com • w: 
www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of McKown, John
Sent: Thursday, August 23, 2012 7:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: X86 server

I now don't believe much of anybody when they say that they will accept any 
responsibility for anything. Given time, they will renege on any agreement that 
they possibly can get away with reneging on. I am getting very cynical and sick 
of people in my old age.

--
John McKown

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

JES/2 Spool

[Pesce, Andy]

Has anyone seen a program out there that will take an output from JES/2 spool 
and write it to a dataset?
I know of a couple of software companies that market this.  Just wondering if 
someone has written one
or seen one on the CBT tape.

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

Re: JES/2 Spool

[Michael Wickman]

ftp can.

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Mike Wickman
Technical Services
Phone     913-236-1663
Cell  913-449-6423
Fax   913-236-1555
email     mwick...@waddell.com
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pesce, Andy
Sent: Thursday, August 23, 2012 10:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] JES/2 Spool

Has anyone seen a program out there that will take an output from JES/2 spool 
and write it to a dataset?
I know of a couple of software companies that market this.  Just wondering if 
someone has written one
or seen one on the CBT tape.

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








"This email is intended to be reviewed by only the intended recipient
 and may contain information that is privileged and/or confidential.
 If you are not the intended recipient, you are hereby notified that
 any review, use, dissemination, disclosure or copying of this email
 and its attachments, if any, is strictly prohibited.  If you have
 received this email in error, please immediately notify the sender by
 return email and delete this email from your system."


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

Re: JES/2 Spool

[Lizette Koehler]

Several options

On the CBT Tape is the JES2DISK 
In SDSF you have XDC or X? commands

You could write a rexx and use SDSF REXX to get it

You could use the NJE Offload


What version of z/OS and what do you have available

Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf
> Of Pesce, Andy
> Sent: Thursday, August 23, 2012 8:16 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: JES/2 Spool
> 
> Has anyone seen a program out there that will take an output from JES/2
spool and
> write it to a dataset?
> I know of a couple of software companies that market this.  Just wondering
if
> someone has written one or seen one on the CBT tape.
> 

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

Re: JES/2 Spool

[Steve Comstock]

On 8/23/2012 9:16 AM, Pesce, Andy wrote:

Has anyone seen a program out there that will take an output from JES/2 spool 
and write it to a dataset?
I know of a couple of software companies that market this.  Just wondering if 
someone has written one
or seen one on the CBT tape.



Well, you can do it manually from the SDSF menu. So I suppose
you could build a Rexx exec to use the SDSF interface without
too much trouble.




--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

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

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

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

Re: JES/2 Spool

[Mullen, Patrick]

Or run SDSF in a batch job, EXEC PGM=SDSF, with the commands in ISFIN.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Steve Comstock
Sent: Thursday, August 23, 2012 10:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES/2 Spool

On 8/23/2012 9:16 AM, Pesce, Andy wrote:
> Has anyone seen a program out there that will take an output from
JES/2 spool and write it to a dataset?
> I know of a couple of software companies that market this.  Just
wondering if someone has written one
> or seen one on the CBT tape.
>

Well, you can do it manually from the SDSF menu. So I suppose
you could build a Rexx exec to use the SDSF interface without
too much trouble.




-- 

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

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

* Try our tool for calculating your Return On Investment
 for training dollars at
   http://www.trainersfriend.com/ROI/roi.html

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

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

Re: JES/2 Spool

[McKown, John]

In exactly what manner? An external writer, as distributed by IBM can do that. 
But it is not likely what you want. I have a REXX program which uses the 
REXX/SDSF interface which can write to either a z/OS sequential data set or a 
z/OS UNIX file. My REXX leaves the job on the SPOOL. There is a free UNIX 
program called "fromdsn" which can do this. It is part of Dovetailed 
Technologies' Co:Z Data Set Pipes product (I love it!). This is freely 
available and downloadable from the web. File 790 from CBT is called SRS 
(Sysout Retrieval Services) and sounds like it might be what you could use.

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Pesce, Andy
> Sent: Thursday, August 23, 2012 10:16 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: JES/2 Spool
> 
> Has anyone seen a program out there that will take an output from JES/2
> spool and write it to a dataset?
> I know of a couple of software companies that market this.  Just
> wondering if someone has written one
> or seen one on the CBT tape.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

ZIP390 called by XMITIP

[Button, Chris]

Thought I would give this another try.  I just installed XMITIP 10.10 and have 
executed the IVPJOB.  We are using ZIP390 6.0 and I see these errors in STEP 
IVP7 of the IVPJOB which appears to be an APF abend:

XMITIP:   Using ZIP:   ZIP390
XMITIP:   zip file as: $doc.rtf
XMITIP:zip'ing file 'C116314.XMITIP.V1010.PDS($doc)'
XMITIP:name-in-archive of $doc.rtf not supported by ZIP390, using data set 
name.
   309 *-*  "Call" zip_load
   +++ RC(-1) +++
XMITIPZP: ZIP Msg: ZIP390   ENDED DUE TO ERROR+
XMITIPZP: ZIP Msg: SYSTEM ABEND CODE 0047REASON CODE 800BFAD8
XMITIPZP:
XMITIPZP: Error encountered during ZIP processing rc: -1
XMITIPZP:
XMITIPZP: ZIP Messages:
XMITIPZP:  ZIP100I ZIP/390 Rel:6.0 Build:05/17/11 by Data 21, Inc. (c)
XMITIPZP:  ZIP100I CPU: 03C7E5-2097-E12 LPAR:3 CP:02 GP:01 ZIIP:01 ZAAP:00 .
XMITIPZP:  ZIP100I CAP: 139MSU: 119SU/SEC: 32989.6907  .
XMITIPZP:  ZIP100I CEC: 277IMG: 139LPAR: TST2:0003  FLAG: C0   .
XMITIPZP:  ZIP101I GINCLUDE=DSN/CMNPROD.WSP.CNTL(GINCL1)10:29:50
XMITIPZP:  ZIP131I Close-R SYS00163/ Total Records = 2  10:29:50
XMITIPZP:  ZIP101I IPCRYPT=AES,256  10:29:50
XMITIPZP:  ZIP101I ECHO=YES 10:29:50
XMITIPZP:  ZIP101I ACTION=ZIP   10:29:50
XMITIPZP:  ZIP101I OBUFF=210K   10:29:50
XMITIPZP:  ZIP101I ARCHIVE=SEQ/D40829/23738/23738/VB10:29:50
XMITIPZP:  ZIP101I CMPRLVL=NORMAL   10:29:50
XMITIPZP:  ZIP101I MODE=TEXT10:29:50
XMITIPZP:  ZIP101I IFILE=TDSN/C116314.ZIPW.XM809452.J05595.RTF;$doc.rtf
XMITIPZP:  ZIP111I Zipping: C116314.ZIPW.XM809452.J05595.RTF MODE=TEXT
XMITIPZP:
  6858 *-*   "xmitipzp" translate(file_dsn zip_dsn) ,   
translate(zip_type
zip_load) ,  z_type fmt2l 
password ,
  method zip_unit hlq debug
   +++ RC(-1) +++
XMITIP:   Error reading generated zip file: 'C116314.ZIPw.zip1.J05595.T7788.ZIP'
XMITIP:   Ending XMITIP (RC=8).

I submitted a similar email back in February; the common response seemed to be 
to add ZIP390 and ZIPSRB to IKJTSOxx.  I have added both to sections AUTHCMD, 
AUTHPGM, and AUTHTSF but it still fails.  Just wondering if anyone has gone 
through this recently with ZIP390 v6 and have any other suggestions to try?

Regards,
Chris Button
Travelport



If you are not the intended recipient of this e-mail message, please notify the 
sender 
and delete all copies immediately. The sender believes this message and any 
attachments 
were sent free of any virus, worm, Trojan horse, and other forms of malicious 
code. 
This message and its attachments could have been infected during transmission. 
The 
recipient opens any attachments at the recipient's own risk, and in so doing, 
the 
recipient accepts full responsibility for such actions and agrees to take 
protective 
and remedial action relating to any malicious code. Travelport is not liable 
for any 
loss or damage arising from this message or its attachments.



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

Re: JES/2 Spool

[Mike Schwab]

We use 
http://www.docstoc.com/docs/52553279/MVS-Freeware-SYSOUT-Retrieval-Services-(SRS)

On Thu, Aug 23, 2012 at 10:16 AM, Pesce, Andy  wrote:
> Has anyone seen a program out there that will take an output from JES/2 spool 
> and write it to a dataset?
> I know of a couple of software companies that market this.  Just wondering if 
> someone has written one
> or seen one on the CBT tape.
>
-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: SMF Type 99 quandry

[Knutson, Sam]

My .02 I view the SMF Type 99 data as part of the z/OS "Flight Recorder" you 
don't need it till you want it then it is priceless.  The cost of not saving it 
may be recreating a painful performance problem or worse unable to recreate 
waiting for it to recur in production.  A large 4 member production Sysplex 
here cuts something like 2,522,546 SMF 99 records daily but only this day that 
is only 2.61 % of the total SMF. It is not significant when compared to the 
volume of CICS and DB2 SMF data we keep.   You can choose to retain these 
temporarily as recent past data in case you need them.  We finally decided it 
was easier to just include them in our archive tapes went against the grain 
with our data management team to throw anything away.   If you go spelunking 
there is some interesting data in the Type 99's to understand things that are 
happening on your system.   Hopefully you are also recording SMF Type 113 with 
HIS if on z10 or newer also data that can be very useful and again once you 
don't record it you cannot go back and get it.


    Best Regards, 

    Sam Knutson, GEICO 
    System z Team Leader 
    mailto:sknut...@geico.com 
    (office)  301.986.3574 
    (cell) 301.996.1318
  
"Think big, act bold, start simple, grow fast..." 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Yuhas
Sent: Wednesday, August 22, 2012 4:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMF Type 99 quandry

According to the MVS Programming Workload Management Services manual, a Type 
SMF 99 record is written every policy interval (approximately 10 seconds).  I 
have 5 LPARs - 3 production, 1 LPAR just constructed and 2 test LPARs.  The SMF 
activity for the 2 test LPARs and the newly constructed ones is more than I 
expected.  I reviewed the SUMMARY ACTIVITY REPORT and discovered an inordinate 
amount of Type 99 records.


 

I did some calculations for each LPAR and discovered that, on average, there 
are 5.16 Type 99 records being written every second.  Not one every 10 seconds. 
 Either the policy interval time length has changed or these Type 99 records 
are being written by some other component.

 

What am I missing?  Yes, I could turn off writing the Type 99 records.
But, is this indicative of some other problem?


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

This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

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

Re: X86 server

[Anne & Lynn Wheeler]

john.mck...@healthmarkets.com (McKown, John) writes:
> X64 hardware, as much as it has improved, is still not as reliable or
> have the I/O capacity of the z hardware. E.g.: We had a TCM fail
> once. A spare picked up the work, automatically restarting the
> instruction stream, with no outage of any sort and no software
> involvement. X86, from what I'm told, would at least require the OS to
> do the equivalent of a checkpoint restart. Also had an OSA fail. The
> other OSA did an ARP takeover and no IP sessions were lost. TCPIP was
> informed, but all it did was put out a message and not start any new
> sessions on the failing OSA. Our "open" people called me a liar when I
> told them that.

big cloud operators do hundreds of thousands of blades in megadatacenter
with lots of failure/recovery infrastructure to handle individual blade
failures (usually with lots of power, telco, provisioning provisioning).

Gray had been studying mix of failures issues (both at IBM and later at
Tandem) and by '84 published report that hardware failures had become
minority of failure modes (hardware reliability had increased so other
kinds of failures were starting to dominating). scan of '84 presentation
http://www.garlic.com/~lynn/grayft84.pdf

several of the big cloud operators have published detailed studies of
different component availability as part of building their own blades
... given optimal service life per dollar.

Cluster & take-over were increasingly being used to mask all kinds of
outages ... even able to handle geographic operations and handling
disasters taking out whole datacenter.

when we were doing ha/cmp ... we did a lot of failure mode study ... and
part of our marketing was against hardware fault-tolerant systems.  We
showed availability of ha/cmp clusters was higher than the
fault-tolerant systems. In competitive situation involving 1-800 number
server (i.e. maps 1-800 number to "real" number) ... it required
five-nines availability. hardware fault-tolerant system still required
scheduled system outage to do software upgrade ... which would blow
several decades of downtime budget. With cluster operation, we showed at
least as good hardware availability (with redundant systems) along with
capability of doing rolling software upgrades with no system outage.

the hardware fault tolerant vendor eventually came back with suggestion
that they could come out with redundant, cluster system operation ... to
handle the software upgrade issue. However, given reliability of
the underlying hardware operating in redundant, cluster system mode ...
there was no longer any justification for hardware fault tolerance.

part of ha/cmp was ip-address take-over ... which according to all the
standards should time-out mac/ip-address in arp caches. at the time,
most vendors were using BSD 4.3 tahoe or reno software for their tcp/ip
stacks. In 1989, we found a bug in the BSD4.3 tahoe/reno IP/ARP lookup
software. The ARP cache management was correctly timing out the ARP
cache entries (so if there was ip-address take-over, it would discover
the new MAC mapping). However, the BSD4.3 IP code had a performance
optimization where it saved the last ip/mac lookup results ... which
would only get reset if the client communicated with a different
ip-address (otherwise that saved ip/mac mapping would exist
forever). Since the "bug" existed in nearly every vendors implementation
(all using same BSD4.3 tahoe/reno software), we had to come up with a
work-around for the saved ip/mac bug. Any time there was ip-address
take-over, we would quickly saturate the local LAN with dummy traffic
from a different ip-address ... forcing all the machines on that LAN to
perform a real ARP cache lookup (resetting the "saved" value). Then the
next activity from the taken-over ip-address would force the clients to
do a real ARP cache lookup.

misc. past posts mentioning ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: JES/2 Spool

[Paul Gilmartin]

On Thu, 23 Aug 2012 08:23:57 -0700, Lizette Koehler wrote:

>Several options
> ...
>You could write a rexx and use SDSF REXX to get it
>  
There's much sample code in:

Title: z/OS V1R12.0 SDSF Operation and Customization
Document Number: SA22-7670-14

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/isf4csa0/13.14

-- gil

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

Re: X86 server

[Ward, Mike S]

IBM has always been a hardware company. In the 60's they wrote operating 
systems and gave them away as long as you purchased the hardware from them to 
run it on. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, August 22, 2012 6:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: X86 server

Which costs less?

On Wed, 22 Aug 2012 13:40:01 -0700, Edward Jaffe wrote:

>On 8/13/2012 10:01 PM, Jake anderson wrote:
>> Does IBM provides support running Z/OS on X86 ?
>
>Yes, with its RD&T offering:
>http://www.ibm.com/software/rational/products/devtest/systemz/
> 
What's IBM's economic rationale here?  If it's cheaper for them to make z/OS 
available on X86, then much that I read in this forum about the economic 
advantages of zSeries is untrue, and IBM's motive for not licensing z/OS for 
X86 is simply to compel customers to buy the more expensive hardware from IBM.

-- gil

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

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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

Re: JES/2 Spool

[Gibney, Dave]

E/JES has these functions as well. 

Dave Gibney
Information Technology Services
Washington State University


> In SDSF you have XDC or X? commands
> 
> You could write a rexx and use SDSF REXX to get it
> 
> You could use the NJE Offload
> 
> 
> What version of z/OS and what do you have available
> 
> Lizette
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-
> m...@listserv.ua.edu] On
> Behalf
> > Of Pesce, Andy
> > Sent: Thursday, August 23, 2012 8:16 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: JES/2 Spool
> >
> > Has anyone seen a program out there that will take an output from JES/2
> spool and
> > write it to a dataset?
> > I know of a couple of software companies that market this.  Just wondering
> if
> > someone has written one or seen one on the CBT tape.
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: X86 server

[McKown, John]

"has always been" -> "had always been". As you indicated, at first software was 
written in order to sell the hardware. It was basically "overhead". However, 
when PCMs such as Amdahl came along and simply started redistributing IBM 
software (which they got for free since they owned IBM hardware), IBM had to 
have some other way to recoup their costs. Also, they started unbundling when 
the courts found them guilty of a monopoly which included their refusal to 
distribute software to non-IBM customers. At least, as best as I can recall 
after lo these many years.

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

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

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


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Ward, Mike S
> Sent: Thursday, August 23, 2012 11:40 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: X86 server
> 
> IBM has always been a hardware company. In the 60's they wrote
> operating systems and gave them away as long as you purchased the
> hardware from them to run it on.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> Sent: Wednesday, August 22, 2012 6:00 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: X86 server
> 
> Which costs less?
> 
> On Wed, 22 Aug 2012 13:40:01 -0700, Edward Jaffe wrote:
> 
> >On 8/13/2012 10:01 PM, Jake anderson wrote:
> >> Does IBM provides support running Z/OS on X86 ?
> >
> >Yes, with its RD&T offering:
> >http://www.ibm.com/software/rational/products/devtest/systemz/
> >
> What's IBM's economic rationale here?  If it's cheaper for them to make
> z/OS available on X86, then much that I read in this forum about the
> economic advantages of zSeries is untrue, and IBM's motive for not
> licensing z/OS for X86 is simply to compel customers to buy the more
> expensive hardware from IBM.
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> ==
> This email, and any files transmitted with it, is confidential and
> intended solely for the use of the individual or entity to which it is
> addressed. If you have received this email in error, please notify the
> system manager. This message contains confidential information and is
> intended only for the individual named. If you are not the named
> addressee, you should not disseminate, distribute or copy this e-mail.
> Please notify the sender immediately by e-mail if you have received
> this message by mistake and delete this e-mail from your system. If you
> are not the intended recipient, you are notified that disclosing,
> copying, distributing or taking any action in reliance on the contents
> of this information is strictly prohibited.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Documenting SMS environment & ACS routines.

[McKown, John]

We have a rather "fragile" SMS environment at present. It has basically grown 
"ad hoc" over the course of almost 2 decades. I really need to document it very 
well. Once documented, I would like to use that in order to reengineer the 
environment. Any pointers would be greatly appreciated.

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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

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

CPU MF and HIS

[Grillo Paul]

Hi all,

Read an article in the magazine EnterpriseSystemsMedia.com, How to
Benefit From Hardware Instrumentation Services Data
by Bob St. John, John Burg, & Georges, 30 April 2012, about the new
measurement feature introduced in Z/OS 1.13 called HIS, I found it
very useful, because it comes to add along with the RMF, so that we
have in real time, the behavior of the operating system, address
spaces and processors, I wonder about those who already uses it
because we are migrating to this release.



Jorge Jr Campos

Mainframe Support Analyst

ww. tmsolutions.com. br

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

Re: Documenting SMS environment & ACS routines.

[George Rodriguez]

Using DFP segments can make the ACS routines very simple. When a file is
defined in Racf, you add the SMS Management Class and the SMS Storage Class
and in the ACS routine you add code that says, if the DFP Management class
segment is coded, use it. If the DFP Storage class segment is coded, use
it. I did that change in my last location and boy did it uncomplicate the
ACS routine...
*
*
*George Rodriguez*
*Specialist II - IT Solutions*
*Application Support / Quality Assurance*
*PX - 47652*
*(561) 357-7652 (office)*
*(561) 707-3496 (mobile)*
*School District of Palm Beach County*
*3348 Forest Hill Blvd.*
*Room B-251*
*West Palm Beach, FL. 33406-5869*
*Florida's Only A-Rated Urban District For Eight Consecutive Years*



On Thu, Aug 23, 2012 at 1:34 PM, McKown, John  wrote:

> We have a rather "fragile" SMS environment at present. It has basically
> grown "ad hoc" over the course of almost 2 decades. I really need to
> document it very well. Once documented, I would like to use that in order
> to reengineer the environment. Any pointers would be greatly appreciated.
>
> --
> John McKown
> Systems Engineer IV
> IT
>
> Administrative Services Group
>
> HealthMarkets(r)
>
> 9151 Boulevard 26 * N. Richland Hills * TX 76010
> (817) 255-3225 phone *
> john.mck...@healthmarkets.com * www.HealthMarkets.com
>
> Confidentiality Notice: This e-mail message may contain confidential or
> proprietary information. If you are not the intended recipient, please
> contact the sender by reply e-mail and destroy all copies of the original
> message. HealthMarkets(r) is the brand name for products underwritten and
> issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake
> Life Insurance Company(r), Mid-West National Life Insurance Company of
> TennesseeSM and The MEGA Life and Health Insurance Company.SM
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

-- 


*Accredited District Since 2008; Re-certification - January 2013*

Home of Florida's first LEED Gold Certified School

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Documenting SMS environment & ACS routines.

[McKown, John]

That's a good idea, if/when we try to upgrade how we do things. But my main 
emphasis right now is how to document them. I am not really very good at 
documenting. I could really use a "pattern". We no longer have our storage 
administrator; who did most of the coding. 

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of George Rodriguez
> Sent: Thursday, August 23, 2012 12:54 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Documenting SMS environment & ACS routines.
> 
> Using DFP segments can make the ACS routines very simple. When a file
> is
> defined in Racf, you add the SMS Management Class and the SMS Storage
> Class
> and in the ACS routine you add code that says, if the DFP Management
> class
> segment is coded, use it. If the DFP Storage class segment is coded,
> use
> it. I did that change in my last location and boy did it uncomplicate
> the
> ACS routine...
> *
> *
> *George Rodriguez*
> *Specialist II - IT Solutions*
> *Application Support / Quality Assurance*
> *PX - 47652*
> *(561) 357-7652 (office)*
> *(561) 707-3496 (mobile)*
> *School District of Palm Beach County*
> *3348 Forest Hill Blvd.*
> *Room B-251*
> *West Palm Beach, FL. 33406-5869*
> *Florida's Only A-Rated Urban District For Eight Consecutive Years*
> 
> 
> 
> On Thu, Aug 23, 2012 at 1:34 PM, McKown, John
>  > wrote:
> 
> > We have a rather "fragile" SMS environment at present. It has
> basically
> > grown "ad hoc" over the course of almost 2 decades. I really need to
> > document it very well. Once documented, I would like to use that in
> order
> > to reengineer the environment. Any pointers would be greatly
> appreciated.
> >
> > --
> > John McKown
> > Systems Engineer IV
> > IT
> >
> > Administrative Services Group
> >
> > HealthMarkets(r)
> >
> > 9151 Boulevard 26 * N. Richland Hills * TX 76010
> > (817) 255-3225 phone *
> > john.mck...@healthmarkets.com * www.HealthMarkets.com
> >
> > Confidentiality Notice: This e-mail message may contain confidential
> or
> > proprietary information. If you are not the intended recipient,
> please
> > contact the sender by reply e-mail and destroy all copies of the
> original
> > message. HealthMarkets(r) is the brand name for products underwritten
> and
> > issued by the insurance subsidiaries of HealthMarkets, Inc. -The
> Chesapeake
> > Life Insurance Company(r), Mid-West National Life Insurance Company
> of
> > TennesseeSM and The MEGA Life and Health Insurance Company.SM
> >
> > -
> -
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-
> MAIN
> >
> 
> --
> 
> 
> *Accredited District Since 2008; Re-certification - January 2013*
> 
> Home of Florida's first LEED Gold Certified School
> 
> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: "Delay" Problem with SSL and DVIPA

[Gibney, Dave]

I suggest you ask this on IBMTCP-L. You will find more help there. 
Specifically, Chris Mason :)

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Mauri Kanter
> Sent: Thursday, August 23, 2012 3:16 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: "Delay" Problem with SSL and DVIPA
> 
> Good morning list,
> 
> We are facing a strange "delay" problem with TN3270 and SSL which I
> describe below.
> 
> The configuration is as follows:
> PRD1 and PRD2 are production LPARs.
> DEV1 and DEV2 are development LPARs
> PRD1 and DEV1 are on a z114 machine with two OSA cards shared among the
> LPARs
> PRD2 and DEV2 are on another z114 machine also with two OSA cards shared
> among the LPARs.
> Neither the machines nor the OSA cards are exactly equal but they are very
> similar in many aspects (mips, workload, etc)
> 
> No network problems from the performance point of view…
> 
> Ping times from my desktop are very good for all the IP addresses described
> below. And Normal work is ok. Everybody is happy.
> 
> Below the several IP addresses involved:
> Each OSA card has an IP address.
> Each LPAR has a local VIPA for that LPAR.
> Each subplex has a dynamic DVIPA.
> DEV1 has VIPADEF defined on the VIPADynamic statement
> DEV2 has VIPABackup defined on the VIPADynamic statement
> PRD1 has VIPABackup defined on the VIPADynamic statement
> PRD2 has VIPADEF defined on the VIPADynamic statement
> 
> For example: VIPADEF MOVE IMMED SERVICEMGR 255.255.255.240
> xxx.xxx.xxx.xxx
> 
> We use SSL to connect to TN2370.
> 
> There is no VIPADIST DEFINE statement neither for the TN3270 SSL port nor
> the non-SSL port .
> When connecting via SSL to the TN3270 server of DEV1 using the DVIPA of the
> development subplex performance is very good.
> When connecting via SSL to the TN3270 servers of all the lpar VIPAs the
> performance is very good for all 4 LPARs.
> 
> In particular, when pointing PCOMM to the lpar VIPA belonging to PRD2 the
> USSTAB shows up immediately in almost "no time"
> 
> However … When pointing PCOMM to the DVIPA belonging to the production
> subplex it may take 5 seconds to get the USSTAB. According to our definitions,
> the LU name I get, and what I see from NETSTAT HOME, I see that the DVIPA
> is held by PRD2.
> 
> To make things more confusing, if I use the non-SSL port of the TN3270 the
> "delay" disappears.
> 
> So I do not understand if the problem is SSL, the network, or the distributor.
> I'm missing something here …
> 
> Any ideas what to look for? The problem was reported to me lately and also
> lately we migrated to z/OS 1.13 from 1.11, but I can not confirm for granted
> that z/OS 1.13 is related to the problem.
> 
> Thanks in advance for your help.
> 
> Mauri.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Documenting SMS environment & ACS routines.

[Gibney, Dave]

My SMS routines are all pretty straight forward (after I seriously rewrote them 
a few years back due when they were in the state you describe :)

Filtlist(s)
Entry writes/debug (Each routine echoes the primary variable it will be 
using(for non-Temp datasets:)
A Select where most of the work is done. (Each possible outcome writes a unique 
message code)
Exit writes/debug (What did the routine set)

When I was reworking them, I made extensive use of ISMF's Naviquest. Naviquest 
had a strange learning curve, but was useful in the end. From what I read in 
you posts, you may not like it. It is basically running ISMF test panels, etc. 
in batch and is not cpu friendly.

I wrote a bit of Rexx to turn my debug output on and off, but in the end, I 
usually just leave the writes turned on.


Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of McKown, John
> Sent: Thursday, August 23, 2012 11:04 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Documenting SMS environment & ACS routines.
> 
> That's a good idea, if/when we try to upgrade how we do things. But my main
> emphasis right now is how to document them. I am not really very good at
> documenting. I could really use a "pattern". We no longer have our storage
> administrator; who did most of the coding.
> 
> --
> John McKown
> Systems Engineer IV
> IT
> 
> Administrative Services Group
> 
> HealthMarkets(r)
> 
> 9151 Boulevard 26 * N. Richland Hills * TX 76010
> (817) 255-3225 phone *
> john.mck...@healthmarkets.com * www.HealthMarkets.com
> 
> Confidentiality Notice: This e-mail message may contain confidential or
> proprietary information. If you are not the intended recipient, please contact
> the sender by reply e-mail and destroy all copies of the original message.
> HealthMarkets(r) is the brand name for products underwritten and issued by
> the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life
> Insurance Company(r), Mid-West National Life Insurance Company of
> TennesseeSM and The MEGA Life and Health Insurance Company.SM
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-
> m...@listserv.ua.edu]
> > On Behalf Of George Rodriguez
> > Sent: Thursday, August 23, 2012 12:54 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Documenting SMS environment & ACS routines.
> >
> > Using DFP segments can make the ACS routines very simple. When a file
> > is
> > defined in Racf, you add the SMS Management Class and the SMS Storage
> > Class
> > and in the ACS routine you add code that says, if the DFP Management
> > class
> > segment is coded, use it. If the DFP Storage class segment is coded,
> > use
> > it. I did that change in my last location and boy did it uncomplicate
> > the
> > ACS routine...
> > *
> > *
> > *George Rodriguez*
> > *Specialist II - IT Solutions*
> > *Application Support / Quality Assurance*
> > *PX - 47652*
> > *(561) 357-7652 (office)*
> > *(561) 707-3496 (mobile)*
> > *School District of Palm Beach County*
> > *3348 Forest Hill Blvd.*
> > *Room B-251*
> > *West Palm Beach, FL. 33406-5869*
> > *Florida's Only A-Rated Urban District For Eight Consecutive Years*
> >
> >
> >
> > On Thu, Aug 23, 2012 at 1:34 PM, McKown, John
> >  > > wrote:
> >
> > > We have a rather "fragile" SMS environment at present. It has
> > basically
> > > grown "ad hoc" over the course of almost 2 decades. I really need to
> > > document it very well. Once documented, I would like to use that in
> > order
> > > to reengineer the environment. Any pointers would be greatly
> > appreciated.
> > >
> > > --
> > > John McKown
> > > Systems Engineer IV
> > > IT
> > >
> > > Administrative Services Group
> > >
> > > HealthMarkets(r)
> > >
> > > 9151 Boulevard 26 * N. Richland Hills * TX 76010
> > > (817) 255-3225 phone *
> > > john.mck...@healthmarkets.com * www.HealthMarkets.com
> > >
> > > Confidentiality Notice: This e-mail message may contain confidential
> > or
> > > proprietary information. If you are not the intended recipient,
> > please
> > > contact the sender by reply e-mail and destroy all copies of the
> > original
> > > message. HealthMarkets(r) is the brand name for products underwritten
> > and
> > > issued by the insurance subsidiaries of HealthMarkets, Inc. -The
> > Chesapeake
> > > Life Insurance Company(r), Mid-West National Life Insurance Company
> > of
> > > TennesseeSM and The MEGA Life and Health Insurance Company.SM
> > >
> > > -
> > -
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-
> > MAIN
> > >
> >
> > --
> >
> >
> > *Accredited District Since 2008; Re-certification - January 2013*
> >
> > Home of Florida's first LEED Gold Certified School
> >
> > Under Florida law, e-mail addresses are public r

Re: Documenting SMS environment & ACS routines.

[Lizette Koehler]

John,

This is one of the concerns with the ACS code.  The best you can do is
1) Add Comments in the ACS code to describe what it is to do
2) Add comments to the entries for Dataclas Mgmtclas Storclas and Storgrp
3) Create Test Cases to validate the ACS code still does what you want.
4) Create a Word Doc, TSO Text File, or other (sharepoint?) to keep information 
about your ACS code and structure.

Othere than that, I do not think there is any template that could be put 
inplace.

Lizette


-Original Message-
>From: "McKown, John" 
>Sent: Aug 23, 2012 11:04 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Documenting SMS environment & ACS routines.
>
>That's a good idea, if/when we try to upgrade how we do things. But my main 
>emphasis right now is how to document them. I am not really very good at 
>documenting. I could really use a "pattern". We no longer have our storage 
>administrator; who did most of the coding. 
>
>-- 
>John McKown
>Systems Engineer IV
>IT
>
>Administrative Services Group
>
>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of George Rodriguez
>> Sent: Thursday, August 23, 2012 12:54 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Documenting SMS environment & ACS routines.
>> 
>> Using DFP segments can make the ACS routines very simple. When a file
>> is
>> defined in Racf, you add the SMS Management Class and the SMS Storage
>> Class
>> and in the ACS routine you add code that says, if the DFP Management
>> class
>> segment is coded, use it. If the DFP Storage class segment is coded,
>> use
>> it. I did that change in my last location and boy did it uncomplicate
>> the
>> ACS routine...
>> *
>> *
>> *George Rodriguez*
>> *Specialist II - IT Solutions*
>> *Application Support / Quality Assurance*
>> *PX - 47652*
>> *(561) 357-7652 (office)*
>> *(561) 707-3496 (mobile)*
>> *School District of Palm Beach County*
>> *3348 Forest Hill Blvd.*
>> *Room B-251*
>> *West Palm Beach, FL. 33406-5869*
>> *Florida's Only A-Rated Urban District For Eight Consecutive Years*
>> 
>> 
>> 
>> On Thu, Aug 23, 2012 at 1:34 PM, McKown, John
>> > > wrote:
>> 
>> > We have a rather "fragile" SMS environment at present. It has
>> basically
>> > grown "ad hoc" over the course of almost 2 decades. I really need to
>> > document it very well. Once documented, I would like to use that in
>> order
>> > to reengineer the environment. Any pointers would be greatly
>> appreciated.
>> >
>> > --
>> > John McKown
>> > Systems Engineer IV
>> > IT
>> >

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

Re: Documenting SMS environment & ACS routines.

[Darth Keller]

I might sound like a broken record but I'll say it again - 

If you don't already know how to use Naviquest, learn to use it - if 
you're going to re-write code, it will be your friend.  Unless you have a 
test-plex or a 3rd party product, Naviquest will give you a safe way to 
test your code changes.  There is a Redbook and a Naviquest User's Guide - 
I don't have the links handy.

Create a test case library.  Create several test cases that exercise EVERY 
code segment.  Use the comment lines to establish your expected results. 
Run your test cases against the current code.  If you understand the code, 
your expected results will match your test results.  This may also reveal 
code segments to you which are actually 'orphaned' meaning they never get 
exercised/executed.

Make it a rule to never delete test cases.  Modify them as little as 
possible - only what's needed to keep them current.  If you need a new 
test case that is slightly different than an existing test case, copy the 
existing one & modify the new one as needed.

Once your test cases are in place and you've ensured that every current 
code segment is tested, you've got a test-bed to use for regression 
testing.  To me this means you can make code changes in a parallel 
environment, run the test cases through both the old & the new code & then 
compare the results - all of which you can do through the ISMF options or 
in batch  (ISMF testing ties up your TSO session and with a large set of 
test-cases can take significant time).  This should give you an exact 
understanding of what's changed.

And I always advise people to use WRITE statements.  In code I've written 
or modified, every EXIT statement is preceded by a WRITE statement.  These 
WRITES identify the exit points and gives me helpful information or values 
used in that code segment.  This is a huge time saver when you're trying 
to debug a problem and eliminates any lingering doubt as to where in the 
code the allocation fell out.

Using DFP segments -  I've only found them useful when identifying TSO 
users, but other than that I prefer the flexibility & control the SMS code 
gives me.  Simple does not necessarily equal better. 
HTH's -\
ddk






We have a rather "fragile" SMS environment at present. It has basically 
grown "ad hoc" over the course of almost 2 decades. I really need to 
document it very well. Once documented, I would like to use that in order 
to reengineer the environment. Any pointers would be greatly appreciated.

-- 
John McKown




This e-mail message and all attachments transmitted with it may
contain legally privileged and/or confidential information intended
solely for the use of the addressee(s). If the reader of this
message is not the intended recipient, you are hereby notified that
any reading, dissemination, distribution, copying, forwarding or
other use of this message or its attachments is strictly
prohibited. If you have received this message in error, please
notify the sender immediately and delete this message and all
copies and backups thereof. Thank you.

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

Re: "Delay" Problem with SSL and DVIPA

[Scott Ford]

Did you run a packet trace, to see where the delay is ? That would be the first 
thing ...in my mind..it's not always a case of reviewing definitions...

Scott ford
www.identityforge.com

On Aug 23, 2012, at 2:03 PM, "Gibney, Dave"  wrote:

> I suggest you ask this on IBMTCP-L. You will find more help there. 
> Specifically, Chris Mason :)
> 
> Dave Gibney
> Information Technology Services
> Washington State University
> 
> 
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of Mauri Kanter
>> Sent: Thursday, August 23, 2012 3:16 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: "Delay" Problem with SSL and DVIPA
>> 
>> Good morning list,
>> 
>> We are facing a strange "delay" problem with TN3270 and SSL which I
>> describe below.
>> 
>> The configuration is as follows:
>> PRD1 and PRD2 are production LPARs.
>> DEV1 and DEV2 are development LPARs
>> PRD1 and DEV1 are on a z114 machine with two OSA cards shared among the
>> LPARs
>> PRD2 and DEV2 are on another z114 machine also with two OSA cards shared
>> among the LPARs.
>> Neither the machines nor the OSA cards are exactly equal but they are very
>> similar in many aspects (mips, workload, etc)
>> 
>> No network problems from the performance point of view…
>> 
>> Ping times from my desktop are very good for all the IP addresses described
>> below. And Normal work is ok. Everybody is happy.
>> 
>> Below the several IP addresses involved:
>> Each OSA card has an IP address.
>> Each LPAR has a local VIPA for that LPAR.
>> Each subplex has a dynamic DVIPA.
>> DEV1 has VIPADEF defined on the VIPADynamic statement
>> DEV2 has VIPABackup defined on the VIPADynamic statement
>> PRD1 has VIPABackup defined on the VIPADynamic statement
>> PRD2 has VIPADEF defined on the VIPADynamic statement
>> 
>> For example: VIPADEF MOVE IMMED SERVICEMGR 255.255.255.240
>> xxx.xxx.xxx.xxx
>> 
>> We use SSL to connect to TN2370.
>> 
>> There is no VIPADIST DEFINE statement neither for the TN3270 SSL port nor
>> the non-SSL port .
>> When connecting via SSL to the TN3270 server of DEV1 using the DVIPA of the
>> development subplex performance is very good.
>> When connecting via SSL to the TN3270 servers of all the lpar VIPAs the
>> performance is very good for all 4 LPARs.
>> 
>> In particular, when pointing PCOMM to the lpar VIPA belonging to PRD2 the
>> USSTAB shows up immediately in almost "no time"
>> 
>> However … When pointing PCOMM to the DVIPA belonging to the production
>> subplex it may take 5 seconds to get the USSTAB. According to our 
>> definitions,
>> the LU name I get, and what I see from NETSTAT HOME, I see that the DVIPA
>> is held by PRD2.
>> 
>> To make things more confusing, if I use the non-SSL port of the TN3270 the
>> "delay" disappears.
>> 
>> So I do not understand if the problem is SSL, the network, or the 
>> distributor.
>> I'm missing something here …
>> 
>> Any ideas what to look for? The problem was reported to me lately and also
>> lately we migrated to z/OS 1.13 from 1.11, but I can not confirm for granted
>> that z/OS 1.13 is related to the problem.
>> 
>> Thanks in advance for your help.
>> 
>> Mauri.
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: "Delay" Problem with SSL and DVIPA

[Scott Ford]

A wireshark trace with a tcpip z/os packet trace will show you end to 
end...also look at error counts on the routers and switches, make sure packets 
are being dropped...

Scott ford
www.identityforge.com

On Aug 23, 2012, at 2:41 PM, Scott Ford  wrote:

> Did you run a packet trace, to see where the delay is ? That would be the 
> first thing ...in my mind..it's not always a case of reviewing definitions...
> 
> Scott ford
> www.identityforge.com
> 
> On Aug 23, 2012, at 2:03 PM, "Gibney, Dave"  wrote:
> 
>> I suggest you ask this on IBMTCP-L. You will find more help there. 
>> Specifically, Chris Mason :)
>> 
>> Dave Gibney
>> Information Technology Services
>> Washington State University
>> 
>> 
>>> -Original Message-
>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>>> On Behalf Of Mauri Kanter
>>> Sent: Thursday, August 23, 2012 3:16 AM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: "Delay" Problem with SSL and DVIPA
>>> 
>>> Good morning list,
>>> 
>>> We are facing a strange "delay" problem with TN3270 and SSL which I
>>> describe below.
>>> 
>>> The configuration is as follows:
>>> PRD1 and PRD2 are production LPARs.
>>> DEV1 and DEV2 are development LPARs
>>> PRD1 and DEV1 are on a z114 machine with two OSA cards shared among the
>>> LPARs
>>> PRD2 and DEV2 are on another z114 machine also with two OSA cards shared
>>> among the LPARs.
>>> Neither the machines nor the OSA cards are exactly equal but they are very
>>> similar in many aspects (mips, workload, etc)
>>> 
>>> No network problems from the performance point of view…
>>> 
>>> Ping times from my desktop are very good for all the IP addresses described
>>> below. And Normal work is ok. Everybody is happy.
>>> 
>>> Below the several IP addresses involved:
>>> Each OSA card has an IP address.
>>> Each LPAR has a local VIPA for that LPAR.
>>> Each subplex has a dynamic DVIPA.
>>> DEV1 has VIPADEF defined on the VIPADynamic statement
>>> DEV2 has VIPABackup defined on the VIPADynamic statement
>>> PRD1 has VIPABackup defined on the VIPADynamic statement
>>> PRD2 has VIPADEF defined on the VIPADynamic statement
>>> 
>>> For example: VIPADEF MOVE IMMED SERVICEMGR 255.255.255.240
>>> xxx.xxx.xxx.xxx
>>> 
>>> We use SSL to connect to TN2370.
>>> 
>>> There is no VIPADIST DEFINE statement neither for the TN3270 SSL port nor
>>> the non-SSL port .
>>> When connecting via SSL to the TN3270 server of DEV1 using the DVIPA of the
>>> development subplex performance is very good.
>>> When connecting via SSL to the TN3270 servers of all the lpar VIPAs the
>>> performance is very good for all 4 LPARs.
>>> 
>>> In particular, when pointing PCOMM to the lpar VIPA belonging to PRD2 the
>>> USSTAB shows up immediately in almost "no time"
>>> 
>>> However … When pointing PCOMM to the DVIPA belonging to the production
>>> subplex it may take 5 seconds to get the USSTAB. According to our 
>>> definitions,
>>> the LU name I get, and what I see from NETSTAT HOME, I see that the DVIPA
>>> is held by PRD2.
>>> 
>>> To make things more confusing, if I use the non-SSL port of the TN3270 the
>>> "delay" disappears.
>>> 
>>> So I do not understand if the problem is SSL, the network, or the 
>>> distributor.
>>> I'm missing something here …
>>> 
>>> Any ideas what to look for? The problem was reported to me lately and also
>>> lately we migrated to z/OS 1.13 from 1.11, but I can not confirm for granted
>>> that z/OS 1.13 is related to the problem.
>>> 
>>> Thanks in advance for your help.
>>> 
>>> Mauri.
>>> 
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Documenting SMS environment & ACS routines.

[Gibney, Dave]

I agree with Darth, except I don't like EXIT. My routines all leave via the 
bottom. My last statement is a write of what the routine set.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Darth Keller
> Sent: Thursday, August 23, 2012 11:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Documenting SMS environment & ACS routines.
> 
> I might sound like a broken record but I'll say it again -
> 
> If you don't already know how to use Naviquest, learn to use it - if
> you're going to re-write code, it will be your friend.  Unless you have a
> test-plex or a 3rd party product, Naviquest will give you a safe way to
> test your code changes.  There is a Redbook and a Naviquest User's Guide -
> I don't have the links handy.
> 
> Create a test case library.  Create several test cases that exercise EVERY
> code segment.  Use the comment lines to establish your expected results.
> Run your test cases against the current code.  If you understand the code,
> your expected results will match your test results.  This may also reveal
> code segments to you which are actually 'orphaned' meaning they never get
> exercised/executed.
> 
> Make it a rule to never delete test cases.  Modify them as little as
> possible - only what's needed to keep them current.  If you need a new
> test case that is slightly different than an existing test case, copy the
> existing one & modify the new one as needed.
> 
> Once your test cases are in place and you've ensured that every current
> code segment is tested, you've got a test-bed to use for regression
> testing.  To me this means you can make code changes in a parallel
> environment, run the test cases through both the old & the new code & then
> compare the results - all of which you can do through the ISMF options or
> in batch  (ISMF testing ties up your TSO session and with a large set of
> test-cases can take significant time).  This should give you an exact
> understanding of what's changed.
> 
> And I always advise people to use WRITE statements.  In code I've written
> or modified, every EXIT statement is preceded by a WRITE statement.  These
> WRITES identify the exit points and gives me helpful information or values
> used in that code segment.  This is a huge time saver when you're trying
> to debug a problem and eliminates any lingering doubt as to where in the
> code the allocation fell out.
> 
> Using DFP segments -  I've only found them useful when identifying TSO
> users, but other than that I prefer the flexibility & control the SMS code
> gives me.  Simple does not necessarily equal better.
> HTH's -\
> ddk
> 
> 
> 
> 
> 
> 
> We have a rather "fragile" SMS environment at present. It has basically
> grown "ad hoc" over the course of almost 2 decades. I really need to
> document it very well. Once documented, I would like to use that in order
> to reengineer the environment. Any pointers would be greatly appreciated.
> 
> --
> John McKown
> 
> 
> 
> 
> This e-mail message and all attachments transmitted with it may
> contain legally privileged and/or confidential information intended
> solely for the use of the addressee(s). If the reader of this
> message is not the intended recipient, you are hereby notified that
> any reading, dissemination, distribution, copying, forwarding or
> other use of this message or its attachments is strictly
> prohibited. If you have received this message in error, please
> notify the sender immediately and delete this message and all
> copies and backups thereof. Thank you.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Auditors Don't Know Squat!

[Bobbie Justice]

I'm not even sure they read the script the night before, more likely in the 
elevator on their way in the building. 

sorry, but it's been more stupid and absolutely absurd auditor nonsense today.

Bobbie Jo Justice


On Fri, 17 Aug 2012 07:26:20 -0700, John Mattson  
wrote:

>On another track...
>It seems from my past experiences, that most auditors are fresh out of
>college and working from a prepared script they read the night before.
>Perhaps auditing is "boot camp" for accountants in training.  That would
>"account" for a lot of the messes: the S&L debacle, Coopers&Lybrand, .com
>mess, mortgage meltdown, and bank frauds.  What junior auditor is going to
>report that Morgan Stanley is cooking the books.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: ISPF Panel and LPAR name

[Shmuel Metz (Seymour J.)]

In <50359f17.2080...@bcs.org.uk>, on 08/23/2012
   at 04:10 AM, CM Poncelet  said:

>Well ... art/entertainment v. science/engineering as in Aesop's 
>fable about the Cicala and the Ant. Industry makes its own bread:
>it does not sing all summer and expect bread when winter arrives.

Nonsense. Using a search engine is not remotely analogous to singing
all summer. If anything, refusing to use a search engine is a
manifestation of the NIH syndrome.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: ISPF Panel and LPAR name

[Shmuel Metz (Seymour J.)]

In <50361ac9.1080...@bcs.org.uk>, on 08/23/2012
   at 12:58 PM, CM Poncelet  said:

>Solomon's Book of Proverbs, chapter 26 verse 5

Ah, the Devil quoting scripture.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: batch (was: ISPF Panel and LPAR name)

[Shmuel Metz (Seymour J.)]

In <50359115.9090...@bcs.org.uk>, on 08/23/2012
   at 03:10 AM, CM Poncelet  said:

>What happened to your sycophants, Metz?

I don't have, or want, any. There may be people who often agree with
me, but I'm not aware of one that won't point out any errors that I
make. For that matter, there have been cases where I was the first one
to point out an error in one of my postings.

But if you feel a need for sycophants, that's your business.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Documenting SMS environment & ACS routines.

[retired mainframer]

ISMF options 3, 4, 5, and 6 have the LSTPRT command to document the
properties of every data class, management class, storage class, and storage
group.

Option 7 can identify from where each of the ACS routines was compiled so
you can find the source if it still exists.  It can also identify any test
cases your storage admin used when he developed the system.

The D SMS system command can display the status of each storage group and
the volumes in that group.

Unfortunately, none of this will give you the philosophy or rationale of why
things are this way.  You will have to infer that based on your
understanding of your business environment and anything you know about the
admin himself.

:>: -Original Message-
:>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:>: Behalf Of McKown, John
:>: Sent: Thursday, August 23, 2012 10:35 AM
:>: To: IBM-MAIN@LISTSERV.UA.EDU
:>: Subject: Documenting SMS environment & ACS routines.
:>:
:>: We have a rather "fragile" SMS environment at present. It has basically
:>: grown "ad hoc" over the course of almost 2 decades. I really need to
:>: document it very well. Once documented, I would like to use that in
:>: order to reengineer the environment. Any pointers would be greatly
:>: appreciated.

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

Re: Changing Size of DFSMShsm Auto Backups of the Control Datasets

[retired mainframer]

Why do you think that additional backup copies will alleviate an
underallocation condition in the primary MCDS?

If you want to keep 6 copies of MCDS backups, you also need to keep 6 copies
of the BCDS, JRNL, and OCDS.  But keep in mind that their only purpose is
historical.

To inform HSM of the change you need to issue the SETSYS command with
CDSVERSIONBACKUP parameter with at least the BACKUPCOPIES subparameter.  And
then it would probably be a good idea to incorporate the change in the
ARCCMDxx member or PARMLIB.

I thought VSAM datasets could have more than 16 extents.

:>: -Original Message-
:>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:>: Behalf Of George Rodriguez
:>: Sent: Thursday, August 23, 2012 4:30 AM
:>: To: IBM-MAIN@LISTSERV.UA.EDU
:>: Subject: Changing Size of DFSMShsm Auto Backups of the Control Datasets
:>:
:>: I found in the  z/OS DFSMShsm Implementation and Customization Guide,
:>: member ALLOCBK1, which provides a sample job that defines four backup
:>: versions of each control dataset and allocates those backup versions on
:>: DASD volumes. I modified the JCL to allocate six backup versions that
:>: mirrors what's out there now, but I don't know how to get DFSMShsm to
:>: use
:>: the new allocations.
:>:
:>: My original problem is that the MCDS is under allocated cylinders (20,5)
:>: and I've reached the 16 extent limit.

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

Re: ZIP390 called by XMITIP

[retired mainframer]

In the job, is the STEPLIB or JOBLIB APF authorized?  Is the library
explicitly authorized or implicitly via LNKLST.  Is the main module of the
IVP authorized?

:>: -Original Message-
:>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:>: Behalf Of Button, Chris
:>: Sent: Thursday, August 23, 2012 8:47 AM
:>: To: IBM-MAIN@LISTSERV.UA.EDU
:>: Subject: ZIP390 called by XMITIP
:>:
:>: Thought I would give this another try.  I just installed XMITIP 10.10
:>: and have executed the IVPJOB.  We are using ZIP390 6.0 and I see these
:>: errors in STEP IVP7 of the IVPJOB which appears to be an APF abend:
:>:
:>: XMITIP:   Using ZIP:   ZIP390
:>: XMITIP:   zip file as: $doc.rtf
:>: XMITIP:zip'ing file 'C116314.XMITIP.V1010.PDS($doc)'
:>: XMITIP:name-in-archive of $doc.rtf not supported by ZIP390, using
:>: data set name.
:>:309 *-*  "Call" zip_load
:>:+++ RC(-1) +++
:>: XMITIPZP: ZIP Msg: ZIP390   ENDED DUE TO ERROR+
:>: XMITIPZP: ZIP Msg: SYSTEM ABEND CODE 0047REASON CODE 800BFAD8

snip

:>: I submitted a similar email back in February; the common response seemed
:>: to be to add ZIP390 and ZIPSRB to IKJTSOxx.  I have added both to
:>: sections AUTHCMD, AUTHPGM, and AUTHTSF but it still fails.  Just
:>: wondering if anyone has gone through this recently with ZIP390 v6 and
:>: have any other suggestions to try?

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

Re: X86 server

[Uriel Carrasquilla]

When I used to work for the stock exchange (in Vancouver), it was always the 
question about MF versus Tandem/Stratus fault-tolerant equipment.
Yes, most of the problems were not hardware related.
But one time we were hit by a massive failure in the primary and backup 
components that brought trading down.  It is black swan but can happen and the 
consequences can be nasty.
When it comes to our mission critical applications, we are still a long way 
from going to the clouds.
But for those systems that we can afford the risk, yes, we will go to the cloud.



From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Anne & Lynn Wheeler [l...@garlic.com]
Sent: Thursday, August 23, 2012 12:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: X86 server

john.mck...@healthmarkets.com (McKown, John) writes:
> X64 hardware, as much as it has improved, is still not as reliable or
> have the I/O capacity of the z hardware. E.g.: We had a TCM fail
> once. A spare picked up the work, automatically restarting the
> instruction stream, with no outage of any sort and no software
> involvement. X86, from what I'm told, would at least require the OS to
> do the equivalent of a checkpoint restart. Also had an OSA fail. The
> other OSA did an ARP takeover and no IP sessions were lost. TCPIP was
> informed, but all it did was put out a message and not start any new
> sessions on the failing OSA. Our "open" people called me a liar when I
> told them that.

big cloud operators do hundreds of thousands of blades in megadatacenter
with lots of failure/recovery infrastructure to handle individual blade
failures (usually with lots of power, telco, provisioning provisioning).

Gray had been studying mix of failures issues (both at IBM and later at
Tandem) and by '84 published report that hardware failures had become
minority of failure modes (hardware reliability had increased so other
kinds of failures were starting to dominating). scan of '84 presentation
http://www.garlic.com/~lynn/grayft84.pdf

several of the big cloud operators have published detailed studies of
different component availability as part of building their own blades
... given optimal service life per dollar.

Cluster & take-over were increasingly being used to mask all kinds of
outages ... even able to handle geographic operations and handling
disasters taking out whole datacenter.

when we were doing ha/cmp ... we did a lot of failure mode study ... and
part of our marketing was against hardware fault-tolerant systems.  We
showed availability of ha/cmp clusters was higher than the
fault-tolerant systems. In competitive situation involving 1-800 number
server (i.e. maps 1-800 number to "real" number) ... it required
five-nines availability. hardware fault-tolerant system still required
scheduled system outage to do software upgrade ... which would blow
several decades of downtime budget. With cluster operation, we showed at
least as good hardware availability (with redundant systems) along with
capability of doing rolling software upgrades with no system outage.

the hardware fault tolerant vendor eventually came back with suggestion
that they could come out with redundant, cluster system operation ... to
handle the software upgrade issue. However, given reliability of
the underlying hardware operating in redundant, cluster system mode ...
there was no longer any justification for hardware fault tolerance.

part of ha/cmp was ip-address take-over ... which according to all the
standards should time-out mac/ip-address in arp caches. at the time,
most vendors were using BSD 4.3 tahoe or reno software for their tcp/ip
stacks. In 1989, we found a bug in the BSD4.3 tahoe/reno IP/ARP lookup
software. The ARP cache management was correctly timing out the ARP
cache entries (so if there was ip-address take-over, it would discover
the new MAC mapping). However, the BSD4.3 IP code had a performance
optimization where it saved the last ip/mac lookup results ... which
would only get reset if the client communicated with a different
ip-address (otherwise that saved ip/mac mapping would exist
forever). Since the "bug" existed in nearly every vendors implementation
(all using same BSD4.3 tahoe/reno software), we had to come up with a
work-around for the saved ip/mac bug. Any time there was ip-address
take-over, we would quickly saturate the local LAN with dummy traffic
from a different ip-address ... forcing all the machines on that LAN to
perform a real ARP cache lookup (resetting the "saved" value). Then the
next activity from the taken-over ip-address would force the clients to
do a real ARP cache lookup.

misc. past posts mentioning ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

--
virtualization experience starting Jan1968, online at home since Mar1970

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

IEC161I 037(108,000,IGG0CLFE)-0257 under ZOS 1.10

[Alvaro Quintupray]

Hi.

 We have migrated from ZOS  1.8  to  ZOS  1.10   and  we are having  the 
following problem.

Whe I want open  a file  from CICS ( DESAAORA )  and the file  ( SIXFILET )   
is defined  with RLS = YES
then  we got the following  . . .

===
IEC161I 037(108,000,IGG0CLFE)-0257,DESAAORA,DESAAORA,SIXFILET,,, 
IEC161I DADO.TEST.VSAM1  
+DFHFC0500  DESAAORA RLS OPEN of file SIXFILET failed. VSAM has returned 
 code X'0008' in R15 and reason X'0094'. 

===

The problem is that  we don't have ZOS  1.10  support   and nobody know what is 
going on  . . . 


I  somebody know somethings . . . please. 

Regards.
Alvaro.

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

Re: IEC161I 037(108,000,IGG0CLFE)-0257 under ZOS 1.10

[Lizette Koehler]

A couple of things to check
1) At the time of the error, were there any messagse in SYSLOG?  maybe catalog 
messages?
2) Can you display the VSAM dataset in 3.4?  Can you do a LISTC and is it good 
- no error messages?
3) In CICS are there any additional DFH messages in the CICS logs?

Please post what you can.

Lizette


-Original Message-
>From: Alvaro Quintupray 
>Sent: Aug 23, 2012 1:02 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: IEC161I 037(108,000,IGG0CLFE)-0257 under ZOS 1.10
>
>Hi.
>
> We have migrated from ZOS  1.8  to  ZOS  1.10   and  we are having  the 
> following problem.
>
>Whe I want open  a file  from CICS ( DESAAORA )  and the file  ( SIXFILET )   
>is defined  with RLS = YES
>then  we got the following  . . .
>
>===
>IEC161I 037(108,000,IGG0CLFE)-0257,DESAAORA,DESAAORA,SIXFILET,,, 
>IEC161I DADO.TEST.VSAM1  
>+DFHFC0500  DESAAORA RLS OPEN of file SIXFILET failed. VSAM has returned 
> code X'0008' in R15 and reason X'0094'. 
>
>===
>
>The problem is that  we don't have ZOS  1.10  support   and nobody know what 
>is going on  . . . 
>
>
>I  somebody know somethings . . . please. 
>
>Regards.
>Alvaro.

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

Re: X86 server

[Anne & Lynn Wheeler]

john.mck...@healthmarkets.com (McKown, John) writes:
> "has always been" -> "had always been". As you indicated, at first
> software was written in order to sell the hardware. It was basically
> "overhead". However, when PCMs such as Amdahl came along and simply
> started redistributing IBM software (which they got for free since
> they owned IBM hardware), IBM had to have some other way to recoup
> their costs. Also, they started unbundling when the courts found them
> guilty of a monopoly which included their refusal to distribute
> software to non-IBM customers. At least, as best as I can recall after
> lo these many years.

re:
http://www.garlic.com/~lynn/2012l.html

23jun69 unbundling announcement was result of various litigation,
required starting to charge for application software, SE services,
hardware maint., etc. Company managed to make the case that kernel
software should still be free. misc. past unbundling posts
http://www.garlic.com/~lynn/submain.html#unbundle

FS effort in the early 70s was motivated by competition clone
controllers (it was going to have been radically different from 370),
The rise and fall of IBM
http://www.ecole.org/en/seances/CM07

IBM tried to react by launching a major project called the 'Future
System' (FS) in the early 1970's. The idea was to get so far ahead that
the competition would never be able to keep up, and to have such a high
level of integration that it would be impossible for competitors to
follow a compatible niche strategy. However, the project failed because
the objectives were too ambitious for the available technology.  Many of
the ideas that were developed were nevertheless adapted for later
generations. Once IBM had acknowledged this failure, it launched its
'box strategy', which called for competitiveness with all the different
types of compatible sub-systems. But this proved to be difficult because
of IBM's cost structure and its R&D spending, and the strategy only
resulted in a partial narrowing of the price gap between IBM and its
rivals.

... snip ...

misc. other Future System refs:
http://www.jfsowa.com/computer/memo125.htm
http://www.cs.clemson.edu/~mark/fs.html
http://en.wikipedia.org/wiki/IBM_Future_Systems_project
http://gdrean.perso.sfr.fr/papers/promises.html

during Future System period, internal politics killed off and/or
suspended 370 acitivty ... also I continued to work on 360/370 stuff
... and periodically ridiculed FS (which possibly wasn't the greatest
career enhancing activity). The lack of 370 products was credited with
allowing clone processors to gain market foothold.

and misc. past posts mentioning Future System
http://www.garlic.com/~lynn/submain.html#futuresys

In the wake of the FS failure, there was mad rush to get stuff back into
the 370 product pipelines ... this contributed to decisions to release
various pieces of stuff that I was doing all during the FS period ...
old email mentioning 360/370 stuff during FS period (one of my hobbies
was providing production operating systems for internal datacenters):
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102
http://www.garlic.com/~lynn/2006w.html#email750430

With the rise of the clone processors (made possible by the lack of
products during the FS period) and with effort to get stuff back into
the 370 product pipelines ... there was also a change in the decision to
start charging for kernel software. This was going to be a staged
conversion ... with new kernel add-ons being charged ... leaving base
software free ... at least during transition period. One of my pieces
selected to go out was my resource manager ... and it was selected as
the guinea pig for starting to charge for kernel software (initially
add-on pieces) and I got to spend some amount of time with business
people about kernel charging policies. misc. past posts mentioning
my resource manager and/or scheduling
http://www.garlic.com/~lynn/subtopic.html#fairshare

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: IEC161I 037(108,000,IGG0CLFE)-0257 under ZOS 1.10

[Scott Ford]

Alvaro,

Do you know how to use google ..

http://www.jatomes.com/Help/VsamRc.php

The rc and reason is there, 2 mins work

Scott ford
www.identityforge.com

On Aug 23, 2012, at 4:02 PM, Alvaro Quintupray  wrote:

> Hi.
> 
> We have migrated from ZOS  1.8  to  ZOS  1.10   and  we are having  the 
> following problem.
> 
> Whe I want open  a file  from CICS ( DESAAORA )  and the file  ( SIXFILET )   
> is defined  with RLS = YES
> then  we got the following  . . .
> 
> ===
> IEC161I 037(108,000,IGG0CLFE)-0257,DESAAORA,DESAAORA,SIXFILET,,, 
> IEC161I DADO.TEST.VSAM1  
> +DFHFC0500  DESAAORA RLS OPEN of file SIXFILET failed. VSAM has returned 
> code X'0008' in R15 and reason X'0094'. 
> 
> ===
> 
> The problem is that  we don't have ZOS  1.10  support   and nobody know what 
> is going on  . . . 
> 
> 
> I  somebody know somethings . . . please. 
> 
> Regards.
> Alvaro. 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: IEC161I 037(108,000,IGG0CLFE)-0257 under ZOS 1.10

[Quintupray Burgos Alvaro Eligio]

Hi  Lizette.

The messages from Cics

In  ESMSGLG

16.39.13 STC25178  IEC161I 
037(108,000,IGG0CLFE)-0257,DESAAORA,DESAAORA,SIXFILET,,,
16.39.13 STC25178  IEC161I DADO.TEST.VSAM1
16.39.13 STC25178  +DFHFC0500 DESAAORA RLS OPEN of file SIXFILET failed. VSAM 
has returned code X'0008' in R15 and reason X'0094'.

In  MSGUSR
DFHFC0200 23/08/2012 16:39:13 DESAAORA RLS file SIXFILET has been allocated to 
data set DADO.TEST.VSAM1. Module DFHFCRO.
DFHFC0201 23/08/2012 16:39:13 DESAAORA RLS file SIXFILET has been deallocated. 
Module DFHFCRO.

The messages from SYSLOG

STC25178 0010  IEC161I 
037(108,000,IGG0CLFE)-0257,DESAAORA,DESAAORA,SIXFILET,,,
STC25178 0010  IEC161I DADO.TEST.VSAM1
STC25178 0010  +DFHFC0500  DESAAORA RLS OPEN of file SIXFILET failed. VSAM 
has returned
code X'0008' in R15 and reason X'0094'.

In addition  the Liscat attached

Regards.
Alvaro.


-Mensaje original-
De: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] En nombre 
de Lizette Koehler
Enviado el: jueves, 23 de agosto de 2012 16:26
Para: IBM-MAIN@LISTSERV.UA.EDU
Asunto: Re: IEC161I 037(108,000,IGG0CLFE)-0257 under ZOS 1.10

A couple of things to check
1) At the time of the error, were there any messagse in SYSLOG?  maybe catalog 
messages?
2) Can you display the VSAM dataset in 3.4?  Can you do a LISTC and is it good 
- no error messages?
3) In CICS are there any additional DFH messages in the CICS logs?

Please post what you can.

Lizette


-Original Message-
>From: Alvaro Quintupray 
>Sent: Aug 23, 2012 1:02 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: IEC161I 037(108,000,IGG0CLFE)-0257 under ZOS 1.10
>
>Hi.
>
> We have migrated from ZOS  1.8  to  ZOS  1.10   and  we are having  the 
> following problem.
>
>Whe I want open  a file  from CICS ( DESAAORA )  and the file  ( SIXFILET )   
>is defined  with RLS = YES
>then  we got the following  . . .
>
>===
>IEC161I 037(108,000,IGG0CLFE)-0257,DESAAORA,DESAAORA,SIXFILET,,,
>IEC161I DADO.TEST.VSAM1
>+DFHFC0500  DESAAORA RLS OPEN of file SIXFILET failed. VSAM has
>+returned
> code X'0008' in R15 and reason X'0094'.
>
>===
>
>The problem is that  we don't have ZOS  1.10  support   and nobody know what 
>is going on  . . .
>
>
>I  somebody know somethings . . . please.
>
>Regards.
>Alvaro.

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


La información contenida en este correo electrónico, así como en cualquiera de 
sus adjuntos, es confidencial y está dirigida exclusivamente a el o los 
destinatarios indicados. Cualquier uso, reproducción, divulgación o 
distribución por otras personas distintas de el o los destinatarios está 
estrictamente prohibida. Si ha recibido este correo por error, por favor 
notifíquelo inmediatamente al remitente y bórrelo de su sistema sin dejar copia 
del mismo. BancoEstado no acepta responsabilidad alguna por cualquier perdida o 
daño como consecuencia, directa o indirecta, del uso indebido de este e-mail o 
de los adjuntos al mismo.

The information contained in this e-mail message may be privileged, 
confidential and protected from disclosure. If you are not the intended 
recipient, any further disclosure or use, dissemination, distribution or 
copying of this message or any attachment is strictly prohibited. If you think 
you have received this e-mail message in error, please E-mail the sender and 
delete the e-mail. BancoEstado is not liable for any loss or damage resulting 
from illegal use of this E-mail or any attachment.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
1 J E S 2  J O B  L O G  --  S Y S T E M  M V D 1  --  
N O D E  N 7  
0   
 
 17.11.49 JOB08755  THURSDAY,  23 AUG 2012  
 
 17.11.49 JOB08755  IRR010I  USERID AQUINTU  IS ASSIGNED TO THIS JOB.   
 
 17.11.49 JOB08755  ICH70001I AQUINTU  LAST ACCESS AT 17:11:04 ON THURSDAY, 
AUGUST 23, 2012  
 17.11.49 JOB08755  $HASP373 SIXLISCA STARTED - INIT 28   - CLASS 3 - SYS MVD1  
 
 17.11.49 JOB08755  IEF403I SIXLISCA - STARTED - TIME=17.11.49  
 
 17.11.49 JOB08755  - --TIMINGS 
(MINS.)

Re: IEC161I 037(108,000,IGG0CLFE)-0257 under ZOS 1.10

[Bill Fairchild]

Good advice.  I have wanted to give the same advice many times.
However, even if one can find in 2 minutes the relevant text that explains the 
error messages and tells exactly how to fix the problem, the text one reads may 
contain many technical terms that are gibberish to a novice.

Bill Fairchild
Programmer
Rocket Software
408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA
t: +1.617.614.4503 *  e: bfairch...@rocketsoftware.com * w: 
www.rocketsoftware.com


>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Scott Ford
>Sent: Thursday, August 23, 2012 4:07 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: IEC161I 037(108,000,IGG0CLFE)-0257 under ZOS 1.10
>Alvaro,
>Do you know how to use google ..
>http://www.jatomes.com/Help/VsamRc.php
>The rc and reason is there, 2 mins work
>Scott ford

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

Re: IEC161I 037(108,000,IGG0CLFE)-0257 under ZOS 1.10

[Quintupray Burgos Alvaro Eligio]

Scott.

I had already done the research about the Return Codes . . .  but  I 
want to thank  you for the Link.

The problem is that this does not solve my problem because everything works 
O.K,  on ZOS 1.8   but  not works  in ZOS 1.10

We have redefined the USER.CATALOG , ALIAS  and Files  under ZOS  1.10   and  
the problem following . . .

Regards.
Alvaro.



-Mensaje original-
De: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] En nombre 
de Scott Ford
Enviado el: jueves, 23 de agosto de 2012 17:07
Para: IBM-MAIN@LISTSERV.UA.EDU
Asunto: Re: IEC161I 037(108,000,IGG0CLFE)-0257 under ZOS 1.10

Alvaro,

Do you know how to use google ..

http://www.jatomes.com/Help/VsamRc.php

The rc and reason is there, 2 mins work

Scott ford
www.identityforge.com

On Aug 23, 2012, at 4:02 PM, Alvaro Quintupray  wrote:

> Hi.
>
> We have migrated from ZOS  1.8  to  ZOS  1.10   and  we are having  the 
> following problem.
>
> Whe I want open  a file  from CICS ( DESAAORA )  and the file  ( SIXFILET )   
> is defined  with RLS = YES
> then  we got the following  . . .
>
> ===
> IEC161I 037(108,000,IGG0CLFE)-0257,DESAAORA,DESAAORA,SIXFILET,,,
> IEC161I DADO.TEST.VSAM1
> +DFHFC0500  DESAAORA RLS OPEN of file SIXFILET failed. VSAM has
> +returned
> code X'0008' in R15 and reason X'0094'.
>
> ===
>
> The problem is that  we don't have ZOS  1.10  support   and nobody know what 
> is going on  . . .
>
>
> I  somebody know somethings . . . please.
>
> Regards.
> Alvaro.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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


La información contenida en este correo electrónico, así como en cualquiera de 
sus adjuntos, es confidencial y está dirigida exclusivamente a el o los 
destinatarios indicados. Cualquier uso, reproducción, divulgación o 
distribución por otras personas distintas de el o los destinatarios está 
estrictamente prohibida. Si ha recibido este correo por error, por favor 
notifíquelo inmediatamente al remitente y bórrelo de su sistema sin dejar copia 
del mismo. BancoEstado no acepta responsabilidad alguna por cualquier perdida o 
daño como consecuencia, directa o indirecta, del uso indebido de este e-mail o 
de los adjuntos al mismo.

The information contained in this e-mail message may be privileged, 
confidential and protected from disclosure. If you are not the intended 
recipient, any further disclosure or use, dissemination, distribution or 
copying of this message or any attachment is strictly prohibited. If you think 
you have received this e-mail message in error, please E-mail the sender and 
delete the e-mail. BancoEstado is not liable for any loss or damage resulting 
from illegal use of this E-mail or any attachment.

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

Re: IEC161I 037(108,000,IGG0CLFE)-0257 under ZOS 1.10

[Ed Finnell]

lookat goes back to 1.6 or so less than a minute?
 
 
In a message dated 8/23/2012 4:07:13 P.M. Central Daylight Time,  
scott_j_f...@yahoo.com writes:

The rc  and reason is there, 2 mins  work



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

Re: IEC161I 037(108,000,IGG0CLFE)-0257 under ZOS 1.10

[Scott Ford]

Bill,

No shame in not knowing ...

Scott ford
www.identityforge.com

On Aug 23, 2012, at 5:44 PM, Bill Fairchild  
wrote:

> Good advice.  I have wanted to give the same advice many times.
> However, even if one can find in 2 minutes the relevant text that explains 
> the error messages and tells exactly how to fix the problem, the text one 
> reads may contain many technical terms that are gibberish to a novice.
> 
> Bill Fairchild
> Programmer
> Rocket Software
> 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA
> t: +1.617.614.4503 *  e: bfairch...@rocketsoftware.com * w: 
> www.rocketsoftware.com
> 
> 
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>> Behalf Of Scott Ford
>> Sent: Thursday, August 23, 2012 4:07 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: IEC161I 037(108,000,IGG0CLFE)-0257 under ZOS 1.10
>> Alvaro,
>> Do you know how to use google ..
>> http://www.jatomes.com/Help/VsamRc.php
>> The rc and reason is there, 2 mins work
>> Scott ford
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: IEC161I 037(108,000,IGG0CLFE)-0257 under ZOS 1.10

[Scott Ford]

Does the vsam file verify with idcams ? If so, maybe it's the CICS file table 
entry...

Scott ford
www.identityforge.com

On Aug 23, 2012, at 6:06 PM, Quintupray Burgos Alvaro Eligio 
 wrote:

> Scott.
> 
>I had already done the research about the Return Codes . . .  but  I 
> want to thank  you for the Link.
> 
> The problem is that this does not solve my problem because everything works 
> O.K,  on ZOS 1.8   but  not works  in ZOS 1.10
> 
> We have redefined the USER.CATALOG , ALIAS  and Files  under ZOS  1.10   and  
> the problem following . . .
> 
> Regards.
> Alvaro.
> 
> 
> 
> -Mensaje original-
> De: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] En nombre 
> de Scott Ford
> Enviado el: jueves, 23 de agosto de 2012 17:07
> Para: IBM-MAIN@LISTSERV.UA.EDU
> Asunto: Re: IEC161I 037(108,000,IGG0CLFE)-0257 under ZOS 1.10
> 
> Alvaro,
> 
> Do you know how to use google ..
> 
> http://www.jatomes.com/Help/VsamRc.php
> 
> The rc and reason is there, 2 mins work
> 
> Scott ford
> www.identityforge.com
> 
> On Aug 23, 2012, at 4:02 PM, Alvaro Quintupray  
> wrote:
> 
>> Hi.
>> 
>>We have migrated from ZOS  1.8  to  ZOS  1.10   and  we are having  the 
>> following problem.
>> 
>> Whe I want open  a file  from CICS ( DESAAORA )  and the file  ( SIXFILET )  
>>  is defined  with RLS = YES
>> then  we got the following  . . .
>> 
>> ===
>> IEC161I 037(108,000,IGG0CLFE)-0257,DESAAORA,DESAAORA,SIXFILET,,,
>> IEC161I DADO.TEST.VSAM1
>> +DFHFC0500  DESAAORA RLS OPEN of file SIXFILET failed. VSAM has
>> +returned
>> code X'0008' in R15 and reason X'0094'.
>> 
>> ===
>> 
>> The problem is that  we don't have ZOS  1.10  support   and nobody know what 
>> is going on  . . .
>> 
>> 
>> I  somebody know somethings . . . please.
>> 
>> Regards.
>> Alvaro.
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions, send
>> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> La información contenida en este correo electrónico, así como en cualquiera 
> de sus adjuntos, es confidencial y está dirigida exclusivamente a el o los 
> destinatarios indicados. Cualquier uso, reproducción, divulgación o 
> distribución por otras personas distintas de el o los destinatarios está 
> estrictamente prohibida. Si ha recibido este correo por error, por favor 
> notifíquelo inmediatamente al remitente y bórrelo de su sistema sin dejar 
> copia del mismo. BancoEstado no acepta responsabilidad alguna por cualquier 
> perdida o daño como consecuencia, directa o indirecta, del uso indebido de 
> este e-mail o de los adjuntos al mismo.
> 
> The information contained in this e-mail message may be privileged, 
> confidential and protected from disclosure. If you are not the intended 
> recipient, any further disclosure or use, dissemination, distribution or 
> copying of this message or any attachment is strictly prohibited. If you 
> think you have received this e-mail message in error, please E-mail the 
> sender and delete the e-mail. BancoEstado is not liable for any loss or 
> damage resulting from illegal use of this E-mail or any attachment.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: IEC161I 037(108,000,IGG0CLFE)-0257 under ZOS 1.10

[Lizette Koehler]

I think you  need to run the DIAGNOSE between the usercat and the volume where 
the VSAM data set lives.

In fact look at running a DIAGNOSE and EXAMINE for all elements

Something like the following for the VVDS on the volume
//VVDSIN   DD DISP=SHR,DSN=SYS1.VPROD25.VVDS  
//DSNINDD DISP=SHR,DSN=my.vsam.dataset
//SYSINDD *   
  
  DIAGNOSE VVDS COMPAREDD(VVDSIN DSNIN)   


//WORK01   EXEC PGM=IDCAMS   
//SYSPRINT DD SYSOUT=R   
//SYSINDD *  
  EXAMINE -  
NAME(my.user.cat) - 
INDEXTEST DATATEST   
/*   


Lizette


-Original Message-
>From: Scott Ford 
>Sent: Aug 23, 2012 3:33 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: IEC161I 037(108,000,IGG0CLFE)-0257 under ZOS 1.10
>
>Does the vsam file verify with idcams ? If so, maybe it's the CICS file table 
>entry...
>
>Scott ford
>www.identityforge.com
>
>On Aug 23, 2012, at 6:06 PM, Quintupray Burgos Alvaro Eligio 
> wrote:
>
>> Scott.
>> 
>>I had already done the research about the Return Codes . . .  but  I 
>> want to thank  you for the Link.
>> 
>> The problem is that this does not solve my problem because everything works 
>> O.K,  on ZOS 1.8   but  not works  in ZOS 1.10
>> 
>> We have redefined the USER.CATALOG , ALIAS  and Files  under ZOS  1.10   and 
>>  the problem following . . .
>> 
>> Regards.
>> Alvaro.
>> 
>> 
>> 
>> -Mensaje original-
>> De: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] En 
>> nombre de Scott Ford
>> Enviado el: jueves, 23 de agosto de 2012 17:07
>> Para: IBM-MAIN@LISTSERV.UA.EDU
>> Asunto: Re: IEC161I 037(108,000,IGG0CLFE)-0257 under ZOS 1.10
>> 
>> Alvaro,
>> 
>> Do you know how to use google ..
>> 
>> http://www.jatomes.com/Help/VsamRc.php
>> 
>> The rc and reason is there, 2 mins work
>> 
>> Scott ford
>> www.identityforge.com
>> 
>> On Aug 23, 2012, at 4:02 PM, Alvaro Quintupray  
>> wrote:
>> 
>>> Hi.
>>> 
>>>We have migrated from ZOS  1.8  to  ZOS  1.10   and  we are having  the 
>>> following problem.
>>> 
>>> Whe I want open  a file  from CICS ( DESAAORA )  and the file  ( SIXFILET ) 
>>>   is defined  with RLS = YES
>>> then  we got the following  . . .
>>> 
>>> ===
>>> IEC161I 037(108,000,IGG0CLFE)-0257,DESAAORA,DESAAORA,SIXFILET,,,
>>> IEC161I DADO.TEST.VSAM1
>>> +DFHFC0500  DESAAORA RLS OPEN of file SIXFILET failed. VSAM has
>>> +returned
>>> code X'0008' in R15 and reason X'0094'.
>>> 
>>> ===
>>> 
>>> The problem is that  we don't have ZOS  1.10  support   and nobody know 
>>> what is going on  . . .
>>> 
>>> 
>>> I  somebody know somethings . . . please.
>>> 
>>> Regards.
>>> Alvaro.
>>> 

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

William Thurston (1946-2012)

[John Gilmore]

Thurston is dead too soon, at age 65, another cancer victim.

He was the greatest geometer/topologist of this age and one of the
great geometers of any age, a figure of Euclidean importance.

Immediately relevant here, he was also a distinguished computer
scientist.  His book,

Groups, tilings, and finite-state automata.  Boulder, CO: American
Mathematical Society, 1989.

will amply repay the attention of those of you who have theoretical interests.

John Gilmore, Ashland, MA 01721 - USA

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

Re: X86 server

[Anne & Lynn Wheeler]

uriel.carrasqui...@mail.mcgill.ca (Uriel Carrasquilla) writes:
> When I used to work for the stock exchange (in Vancouver), it was
> always the question about MF versus Tandem/Stratus fault-tolerant
> equipment.
> Yes, most of the problems were not hardware related.
> But one time we were hit by a massive failure in the primary and
> backup components that brought trading down.  It is black swan but can
> happen and the consequences can be nasty.
> When it comes to our mission critical applications, we are still a long way 
> from going to the clouds.
> But for those systems that we can afford the risk, yes, we will go to the 
> cloud.

re:
http://www.garlic.com/~lynn/2012l.html#16 X86 server
http://www.garlic.com/~lynn/2012l.html#18 X86 server

in ha/cmp we spent some amount of time with siac ... ran dataprocessing
for exchange ... they had a carefully selected datacenter in a building
that had lots of diverse routing ... two different water mains on
different sides of the building, different electrical mains on different
sides of the building to different substations, and four different telco
feeds on four sides of the building into four different central
exchanges (this besides UPS and power backup). past posts mentioning
ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

one of their outages was when the transformers in the basement blew-up
contaminanting the building with PCB ... and the building had to be
evacuated. misc. past posts mentioning SIAC
http://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL 
being used
http://www.garlic.com/~lynn/2007e.html#16 Attractive Alternatives to Mainframes
http://www.garlic.com/~lynn/2007k.html#41 DEC and news groups
http://www.garlic.com/~lynn/2007n.html#31 IBM obsoleting mainframe hardware
http://www.garlic.com/~lynn/2008b.html#36 windows time service
http://www.garlic.com/~lynn/2009g.html#2 Just posted third article about toxic 
assets in a series on the current financial crisis
http://www.garlic.com/~lynn/2009i.html#23 Why are z/OS people reluctant to use 
z/OS UNIX? (Are settlements a good argument for overnight batch COBOL ?)
http://www.garlic.com/~lynn/2009p.html#57 MasPar compiler and simulator
http://www.garlic.com/~lynn/2010q.html#37 Programmer Charged with thieft  
(maybe off topic)

I was out doing geographic separation and had coined the terms disaster
survivability and geographic survivability (to differentiate from
disaster recovery) ... some past posts
http://www.garlic.com/~lynn/submain.html#available

I was then asked to write a section for the corporate continuous
availability strategy document ... but when both rochester and POK
complained that they couldn't meet the requirements ... my section got
pulled.

I was also doing cluster scaleup ... mentioned in this early jan92
meeting in ellison's conference room
http://www.garlic.com/~lynn/95.html#13

and mainframe DB2 compalined if I was allowed to go ahead ... I would be
years ahead of them.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: How to retain volumes by days when VOLUME VRS is used in DFSMSrmm

[Mike Wood]

Massaki-san, you said

>Thank you very much for informing me that COUNT(0) is available only
above z/OS V1.9.

A customer wants to use both volume and data set name VRS.
I don't know its detailed reason.  The customer just ask us how to
retain volumes by days.   They also use data set VRSs.
I guess that if a volume doesn't match data set VRSs, they want to
retain the volume by volume VRS.
>
A: There are multiple ways to address the requirement, but knowing which would 
be best requires detailed knowledge about the customers situation and system 
release levels. You already have indicated that its an older, perhaps out of 
normal support release
Using volume VRSes you can either use generic volume and rmm retains cycles - 
i.e. a number of volumes, or you can sue specific volume VRSes and rmm will 
retain based on DAYS.  This is explained in the rmm G&R for ADDVRS subcommand.

To retain by DAYS you also have options such as:
- use the default retention period such as OPTION RETPD(5)
- use a data set VRS with DAYS COUNT(5) - This requires that you know the data 
set names of the files you plan to place on those volumes.

Mike Wood

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

Re: William Thurston (1946-2012)

[Scott Ford]

Yep, I had to google it. The big C ...

Scott ford
www.identityforge.com

On Aug 23, 2012, at 6:59 PM, John Gilmore  wrote:

> Thurston is dead too soon, at age 65, another cancer victim.
> 
> He was the greatest geometer/topologist of this age and one of the
> great geometers of any age, a figure of Euclidean importance.
> 
> Immediately relevant here, he was also a distinguished computer
> scientist.  His book,
> 
> Groups, tilings, and finite-state automata.  Boulder, CO: American
> Mathematical Society, 1989.
> 
> will amply repay the attention of those of you who have theoretical interests.
> 
> John Gilmore, Ashland, MA 01721 - USA
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

OS/390 CD collection free to a good home

[retired mainframer]

I have the complete 9 CD Online Library OS/390 Collection, dated September
1998, SK2T-6700-10.  If anyone has any use for it, I will gladly mail them
the CDs and the IBM binder.  I will wait a week or so for off-line responses
before contributing them to the city land-fill.

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

Re: OS/390 CD collection free to a good home

[Dan Skomsky @ Home]

I sure would be interested in them.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of retired mainframer
Sent: Thursday, August 23, 2012 7:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: OS/390 CD collection free to a good home

I have the complete 9 CD Online Library OS/390 Collection, dated September
1998, SK2T-6700-10.  If anyone has any use for it, I will gladly mail them
the CDs and the IBM binder.  I will wait a week or so for off-line responses
before contributing them to the city land-fill.

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

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

Using CR+

[Gibney, Dave]

Using Catalog Recovery Plus 7.4
DIAGNOSE VVDS-VTOC   
 
 COMPARE-VVDS(   
   DVLM02 -  
 )   
 MESSAGE-TEXT(ABBREVIATED)   
 SCRATCH(YES)
 AUTOFIX 

I get the following message about a harmless situation :)
If I choose to be anal about it, what suggestions would the list members have 
for "repairing" it.
The volume is SMS managed. z/OS 1.11

MCR11571I VVDS on DVLM02 at 29% using 3 of 10 Tracks in 1 Extent. 
  
  VVDS STRUCTURAL PROBLEMS DETECTED ON VOLUME DVLM02. 
  Errors found for 1 CI in the VVDS:  
  VVDS CI at RBA=00061000:
  - Field at offset + Len(4092) contains Non-Hexzeros.
  
  No Dataset-specific Errors detected on volume DVLM02.   
  The DVLM02 Catalog Names List has no errors.
  
MCR11563W Analysis proposes the following actions to volume DVLM02:   
Problems were detected but no update fixes were proposed. 
  
MCR11548I AUTOFIX Update Bypassed for Volume DVLM02, No fixes staged. 
  
Dave Gibney
Information Technology Services
Washington State University 

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

How often do you review your CFRM Policy?

[Roger Lowe]

Hi Listers,
   How often do you review your CFRM Policy and uodate it to 
reflect parameter changes?
For example, the SIZE keyword has a default unit value of 'K' - would you go 
ahead and change it to 'M', 'G' or 'T' or because the previous CFRM Policy had 
defined it using the default value of 'K', would you just leave it?

Thanks, Roger

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

Re: X86 server

[Anne & Lynn Wheeler]

mw...@ssfcu.org (Ward, Mike S) writes:
> IBM has always been a hardware company. In the 60's they wrote
> operating systems and gave them away as long as you purchased the
> hardware from them to run it on.

re:
http://www.garlic.com/~lynn/2012l.html#16 X86 server
http://www.garlic.com/~lynn/2012l.html#18 X86 server
http://www.garlic.com/~lynn/2012l.html#19 X86 server

became much less so after Guerstner resurrected ibm.

recent revenue was 83% software and services with everything else
... including all hardware, 17%.  mainframe, x86, and power hardware
were approx. $5B each

max configured z196 with 80 processors is rated for 50BIPS and goes for
$28M (about $560,000/BIPS) and at $28M, $5B represents approx. 180
max. configured z196 (180*50 or aggregate of 9TIPS processing)

ibm has base price of $1815 for e5-2600 blade ... which have ratings at
527BIPS (about $3.44/BIPS), at $1815, $5B represents approx. 2,754,800
e5-2600 blades (2754800*527 or aggregate of 1,452,000TIPS). Even if you
inflate the base blade price by a factor of ten times, that reduces the
number of blades (you could get for $5B) to 275,480 with aggregate
processing power of 145,000TIPS

On the other hand the major cloud operators have claimed that they
manufacturer blades with optimal components for 1/3rd the cost of brand
name blades ... with a cloud megadatacenter typically containing several
hundred thousand blades.

a couple recent ibm-main references to Guerstner's resurrect of ibm:
http://www.garlic.com/~lynn/2012b.html#74 IBM Doing Some Restructuring?
http://www.garlic.com/~lynn/2012g.html#34 Co-existance of z/OS and z/VM on same 
DASD farm

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: IEC161I 037(108,000,IGG0CLFE)-0257 under ZOS 1.10

[Scott Ford]

Alvaro:
 
What is really odd is the 0257 return code..I looked up the IEC161I for your 
release and no 0257 ..
I wonder if this is a bug ..

Scott J Ford
Software Engineer
http://www.identityforge.com/
 
 


 From: Quintupray Burgos Alvaro Eligio 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, August 23, 2012 5:18 PM
Subject: Re: IEC161I 037(108,000,IGG0CLFE)-0257 under ZOS 1.10
  
Hi  Lizette.

The messages from Cics

In  ESMSGLG

16.39.13 STC25178  IEC161I 
037(108,000,IGG0CLFE)-0257,DESAAORA,DESAAORA,SIXFILET,,,
16.39.13 STC25178  IEC161I DADO.TEST.VSAM1
16.39.13 STC25178  +DFHFC0500 DESAAORA RLS OPEN of file SIXFILET failed. VSAM 
has returned code X'0008' in R15 and reason X'0094'.

In  MSGUSR
DFHFC0200 23/08/2012 16:39:13 DESAAORA RLS file SIXFILET has been allocated to 
data set DADO.TEST.VSAM1. Module DFHFCRO.
DFHFC0201 23/08/2012 16:39:13 DESAAORA RLS file SIXFILET has been deallocated. 
Module DFHFCRO.

The messages from SYSLOG

STC25178 0010  IEC161I 
037(108,000,IGG0CLFE)-0257,DESAAORA,DESAAORA,SIXFILET,,,
STC25178 0010  IEC161I DADO.TEST.VSAM1
STC25178 0010  +DFHFC0500  DESAAORA RLS OPEN of file SIXFILET failed. VSAM 
has returned
                    code X'0008' in R15 and reason X'0094'.

In addition  the Liscat attached

Regards.
Alvaro.


-Mensaje original-
De: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] En nombre 
de Lizette Koehler
Enviado el: jueves, 23 de agosto de 2012 16:26
Para: IBM-MAIN@LISTSERV.UA.EDU
Asunto: Re: IEC161I 037(108,000,IGG0CLFE)-0257 under ZOS 1.10

A couple of things to check
1) At the time of the error, were there any messagse in SYSLOG?  maybe catalog 
messages?
2) Can you display the VSAM dataset in 3.4?  Can you do a LISTC and is it good 
- no error messages?
3) In CICS are there any additional DFH messages in the CICS logs?

Please post what you can.

Lizette


-Original Message-
>From: Alvaro Quintupray 
>Sent: Aug 23, 2012 1:02 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: IEC161I 037(108,000,IGG0CLFE)-0257 under ZOS 1.10
>
>Hi.
>
>     We have migrated from ZOS  1.8  to  ZOS  1.10   and  we are having  the 
>following problem.
>
>Whe I want open  a file  from CICS ( DESAAORA )  and the file  ( SIXFILET )   
>is defined  with RLS = YES
>then  we got the following  . . .
>
>===
>IEC161I 037(108,000,IGG0CLFE)-0257,DESAAORA,DESAAORA,SIXFILET,,,
>IEC161I DADO.TEST.VSAM1
>+DFHFC0500  DESAAORA RLS OPEN of file SIXFILET failed. VSAM has
>+returned
> code X'0008' in R15 and reason X'0094'.
>
>===
>
>The problem is that  we don't have ZOS  1.10  support   and nobody know what 
>is going on  . . .
>
>
>I  somebody know somethings . . . please.
>
>Regards.
>Alvaro.

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


La información contenida en este correo electrónico, así como en cualquiera de 
sus adjuntos, es confidencial y está dirigida exclusivamente a el o los 
destinatarios indicados. Cualquier uso, reproducción, divulgación o 
distribución por otras personas distintas de el o los destinatarios está 
estrictamente prohibida. Si ha recibido este correo por error, por favor 
notifíquelo inmediatamente al remitente y bórrelo de su sistema sin dejar copia 
del mismo. BancoEstado no acepta responsabilidad alguna por cualquier perdida o 
daño como consecuencia, directa o indirecta, del uso indebido de este e-mail o 
de los adjuntos al mismo.

The information contained in this e-mail message may be privileged, 
confidential and protected from disclosure. If you are not the intended 
recipient, any further disclosure or use, dissemination, distribution or 
copying of this message or any attachment is strictly prohibited. If you think 
you have received this e-mail message in error, please E-mail the sender and 
delete the e-mail. BancoEstado is not liable for any loss or damage resulting 
from illegal use of this E-mail or any attachment.

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

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

Re: IEC161I 037(108,000,IGG0CLFE)-0257 under ZOS 1.10

[Mike Schwab]

A PTF can add new error code, documented in the next release of the
manual.  And since the two past versions could be getting PTFs, the
first manual with the changed could be version + 3.

On Thu, Aug 23, 2012 at 9:40 PM, Scott Ford  wrote:
> Alvaro:
>
> What is really odd is the 0257 return code..I looked up the IEC161I for your 
> release and no 0257 ..
> I wonder if this is a bug ..
>
> Scott J Ford
> Software Engineer
> http://www.identityforge.com/

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

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

Re: JES/2 Spool

[Brian Westerman]

Our SyzSPOOL/z (WWW.SyzygyInc.com/SyzSpool.htm) product does exactly what you 
are looking for, and while it's not free, it's pretty close.  It's available to 
IBMMain participants for 50% off the regular price (which is already low), so 
for about $2,500 you get spool management and access to the spool data via ISPF 
or the WWW.

Brian

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