date:20141029

Ed Gould wrote:

>There are still quite a few items that DFDSS hasn't caught up with but thats a 
>different horse to flog. Although I was reading an article about z/OS and 
>there are a few things percolating up the like dynamic DASD and the like that 
>will make us wonder why it took so long.

Possible reasons: Backward compatibility issues? No business case to catch up? 
Integrity issues?

Groete / Greetings
Elardus Engelbrecht

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

Re: Has Anyone Seen this in ISPF before?

In <54510682.2040...@rochester.rr.com>, on 10/29/2014
   at 11:23 AM, Thomas Conley  said:

>This is not an ISPF issue.

The corruption is not an ISPF issue, but the failure to range check
the length *is* an ISPF issue. 
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: QUESTION ABOUT VSAM / VSAM EXTENDED

In
,
on 10/23/2014
   at 12:03 PM, Mike Schwab  said:

>3.5 in Floppy disks were 1440 sectors of 512 for 720KiB then 2880
>sectors for 1440KiB or 1.40MiB but labeled them as 1.44M.

512*2880 is 1474560 bytes. 1474560/1024/1024 is 1.25.  1474560/1024000
is 1.44.

1.40MiB would be 1468006.40B.

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

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

Re: [ANN] Lua4z: the Lua programming language on z/OS, with batteries

In <5449b49c.3040...@gmail.com>, on 10/24/2014
   at 10:08 AM, David Crayford  said:

>I don't want to be too disparaging about REXX but I've profiled it 
>extensively and it is not an effecient implementation.

That depends on what "it" is. What did you profile? OS/2 CREXX? OS/2
OREXX? z/OS REXX? z/VM REXX? Regina?

For EXECIO profiling, were you accessing single records or multiple
records?

OOREXX on a PC might well outperform, e.g., TSO/E REXX. on z for some
tasks.

Note: one possible reason to learn lua is that the wiki folks are
using it for some of their tools.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Abend s0077

In
,
on 10/27/2014
   at 08:33 AM, Peter Relson  said:

>What is missing, which will be corrected, is that the "Programmer 
>Response" does not have a line such as "for codes that are 
>described as IBM use only, contact the system programmer".

Please don't! Tat's as bad as "This message is self explanatory."
Assume that the person reading it *is* the systems programmer, and
tell *him* what action to take, including the diagnostic data that he
should report.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: DFHSM QUESTION - EXPIRATION OF DSN

2014-10-29 Thread Ed Gould


On Oct 29, 2014, at 6:44 PM, Gibney, Dave wrote:
-- 
SNIP- 
-
  From the comment it could have been a dataset that didn't have a  
local

standard name.
I had a standard (DASD) that if it didn't have a valid dsorg it  
was deleted. I

regularly went through and deleted them.


25 years ago or more, so did I. With SMS, HSM and DSROG via a  
DEFAULT DATACLAS, I don't have to do this manual deletion of  
obvious errors.


Ahhh the luxury of SMS I could have done so as well, BTW it was not a  
manual effort but a production job that ran once a day (DMS) and it  
was fully automatic.


I disliked DMS for a lot of reasons but it did have a lot of features  
that it took DFDSS 25+ years to catch up up with There are still  
quite a few items that DFDSS hasn't caught up with but thats a  
different horse to flog . Although I was reading an article about Z/ 
os and there are a few things percolating up the like dynamic DASD  
and the like that will make us wonder why it took so long.


Ed

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

Re: DFHSM QUESTION - EXPIRATION OF DSN

2014-10-29 Thread z/OS scheduler

Esmie,

If I am you, I will do the following to find out for myself what the state
of affairs are.

I will create a dataset with

Expiration Attributes

   Expire after Days Non-usage  . : 10
   Expire after Date/Days . . . . : NOLIMIT
   Retention Limit  . . . . . . . : 0

Migration Attributes
  Primary Days Non-usage  . : 4
  Level 1 Days Date/Days  . : 7
  Command or Auto Migrate . : BOTH

And see what happens in the 10 days.
There is nothing like the satisfaction of trying it and finding the answer
yourself.

Greetings

James


2014-10-29 11:32 GMT+00:00 esmie moo :

> Good Morning Gentle Readers,
>
> I have a question about the expiration of a dsn by HSM.  The rule says the
> following :
>
>  Expiration Attributes
>
>Expire after Days Non-usage  . : 540
>Expire after Date/Days . . . . : NOLIMIT
>Retention Limit  . . . . . . . : 0
>
> However the Migration attributes are as follows:
>
> Migration Attributes
>   Primary Days Non-usage  . : 4
>   Level 1 Days Date/Days  . : 7
>   Command or Auto Migrate . : BOTH
>
> My question is will HSM delete the dsn if it is NOT migrated?  I think
> that the DSN needs to be migrated in order for HSM to delte the dsn.  Could
> anybody confirm my comprehension or mis-comprehension should it be the case?
>
> Thanks.
>
> --
> 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: DFHSM QUESTION - EXPIRATION OF DSN

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Ed Gould
> Sent: Wednesday, October 29, 2014 4:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM QUESTION - EXPIRATION OF DSN
> 
> On Oct 29, 2014, at 6:14 PM, Gibney, Dave wrote:
> 
> >> -Original Message-
> >> From: IBM Mainframe Discussion List [mailto:IBM-
> m...@listserv.ua.edu]
> >> On Behalf Of Ed Gould
> >> Sent: Wednesday, October 29, 2014 4:04 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: DFHSM QUESTION - EXPIRATION OF DSN
> >>
> >> On Oct 29, 2014, at 4:39 PM, R.S. wrote:
> >>
> >>> W dniu 2014-10-29 o 18:47, Gibney, Dave pisze:
>  HSM will happily back-up empty datasets. INVALID datasets are
>  another matter. But, it is an easy matter to define a DEFAULT
>  DATACLAS with DSORG=PS and never have another invalid dataset.
> 
> >>> True.
> >>> However I would prefer to have some feature to avoid creation of
> >>> invalid datasets.
> >>> I saw a lot of invalid datasets and none of them was really need by
> >>> the creator.
> >>>
> >>
> >> R.S.
> >>   Define invalid datasets, please.
> >
> > From HSM's perspective, they lack a DSORG. Most frequently created by
> > JCL where the program doesn't actually OPEN the output file for some
> > reason.
> > On non-SMS disk, they can also lack an EOF mark with older z/OS (or
> > perhaps OS390)
> >
> 
>   From the comment it could have been a dataset that didn't have a local
> standard name.
> I had a standard (DASD) that if it didn't have a valid dsorg it was deleted. I
> regularly went through and deleted them.

25 years ago or more, so did I. With SMS, HSM and DSROG via a DEFAULT DATACLAS, 
I don't have to do this manual deletion of obvious errors.

> 
> Ed
> 
> --
> 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: DFHSM QUESTION - EXPIRATION OF DSN

2014-10-29 Thread Ed Gould

On Oct 29, 2014, at 6:14 PM, Gibney, Dave wrote:

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Ed Gould
Sent: Wednesday, October 29, 2014 4:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM QUESTION - EXPIRATION OF DSN

On Oct 29, 2014, at 4:39 PM, R.S. wrote:

W dniu 2014-10-29 o 18:47, Gibney, Dave pisze:
HSM will happily back-up empty datasets. INVALID datasets are  
another

matter. But, it is an easy matter to define a DEFAULT DATACLAS with
DSORG=PS and never have another invalid dataset.

True.
However I would prefer to have some feature to avoid creation of
invalid datasets.
I saw a lot of invalid datasets and none of them was really need by
the creator.

R.S.
  Define invalid datasets, please.

From HSM's perspective, they lack a DSORG. Most frequently created  
by JCL where the program doesn't actually OPEN the output file for  
some reason.
On non-SMS disk, they can also lack an EOF mark with older z/OS (or  
perhaps OS390)

 From the comment it could have been a dataset that didn't have a  
local standard name.
I had a standard (DASD) that if it didn't have a valid dsorg it was  
deleted. I regularly went through and deleted them.

Ed

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

Re: DFHSM QUESTION - EXPIRATION OF DSN

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Ed Gould
> Sent: Wednesday, October 29, 2014 4:04 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM QUESTION - EXPIRATION OF DSN
> 
> On Oct 29, 2014, at 4:39 PM, R.S. wrote:
> 
> > W dniu 2014-10-29 o 18:47, Gibney, Dave pisze:
> >> HSM will happily back-up empty datasets. INVALID datasets are another
> >> matter. But, it is an easy matter to define a DEFAULT DATACLAS with
> >> DSORG=PS and never have another invalid dataset.
> >>
> > True.
> > However I would prefer to have some feature to avoid creation of
> > invalid datasets.
> > I saw a lot of invalid datasets and none of them was really need by
> > the creator.
> >
> 
> R.S.
>   Define invalid datasets, please.

>From HSM's perspective, they lack a DSORG. Most frequently created by JCL 
>where the program doesn't actually OPEN the output file for some reason.
On non-SMS disk, they can also lack an EOF mark with older z/OS (or perhaps 
OS390)

> 
> Ed
> 
> --
> 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: DFHSM QUESTION - EXPIRATION OF DSN

2014-10-29 Thread Ed Gould


On Oct 29, 2014, at 4:39 PM, R.S. wrote:


W dniu 2014-10-29 o 18:47, Gibney, Dave pisze:
HSM will happily back-up empty datasets. INVALID datasets are  
another matter. But, it is an easy matter to define a DEFAULT  
DATACLAS with DSORG=PS and never have another invalid dataset.



True.
However I would prefer to have some feature to avoid creation of  
invalid datasets.
I saw a lot of invalid datasets and none of them was really need by  
the creator.




R.S.
 Define invalid datasets, please.

Ed

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

Re: DFHSM QUESTION - EXPIRATION OF DSN



> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of R.S.
> Sent: Wednesday, October 29, 2014 2:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM QUESTION - EXPIRATION OF DSN
> 
> W dniu 2014-10-29 o 18:47, Gibney, Dave pisze:
> > HSM will happily back-up empty datasets. INVALID datasets are another
> matter. But, it is an easy matter to define a DEFAULT DATACLAS with
> DSORG=PS and never have another invalid dataset.
> >
> True.
> However I would prefer to have some feature to avoid creation of invalid
> datasets.
> I saw a lot of invalid datasets and none of them was really need by the
> creator.
> 

A side effect of doing this is that you can also eliminate MODLDSCB's for 
Generation datasets.
 
>  From the other hand such common issues gave me a lot of consultant work ;-)
> 
> --
> 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 authorized
> 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.
> 
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
> www.mBank.pl, e-mail: kont...@mbank.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.2014 r. kapitał zakładowy mBanku
> S.A. (w całości wpłacony) wynosi 168.696.052 złote.
> 
> 
> --
> 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

AW: Re: AW: Re: MEMLIMIT not honoured by DB2 utility job


>> Do you say that DFSORT will ignore MEMLIMIT?
 >
>Yes, and no.
>I had problems with some DB2 ulitity (reorg) which use DFSORT under the
>cover. It consumed to much virtual memory causing paging.
>I set MEMLIMIT in the jobcard. After that the problem still occured, but
>DFSORT, instead of using 64-bit memory objects, was using dataspaces and
>hiperspaces. So, formally MEMLIMIT was honored, because
>dataspace/hiperspaces do not count for the limit.
>After that I limited total amount of memory for DFSORT (some DFSORT
>knob) and it helped.


It seems to me that our case is different. The IEF message clearly states that 
the job was using roughly 250G of *above the bar* storage. So MEMLIMIT was not 
honoured.


--


Peter Hunkeler



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

Re: DFHSM QUESTION - EXPIRATION OF DSN

W dniu 2014-10-29 o 18:47, Gibney, Dave pisze:

HSM will happily back-up empty datasets. INVALID datasets are another matter.
But, it is an easy matter to define a DEFAULT DATACLAS with DSORG=PS and never
have another invalid dataset.

True.
However I would prefer to have some feature to avoid creation of invalid
datasets.
I saw a lot of invalid datasets and none of them was really need by the
creator.

From the other hand such common issues gave me a lot of consultant work ;-)

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

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.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.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote.

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

Re: QUESTION ABOUT VSAM / VSAM EXTENDED - IAMPRINT OUTPUT

2014-10-29 Thread Mike Schwab

Extended VSAM can be released.  Standard VSAM cannot be released.
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/defks.htm

On Wed, Oct 29, 2014 at 12:01 PM, Willie Bunter
<001409bd2345-dmarc-requ...@listserv.ua.edu> wrote:
> I defined the dsn as VSAM EXTENDED format and I ran a LISTCAT to compare the 
> before and after allocation.
> Everything is okay except for the following:
> When the dsn was NOT VSAM EXTENDED format the IAM100 IAM FILE ANALYSIS output 
> showed :
>
> TOTAL EXTENTS  =49  -  TOTAL SPACE ALLOCATED - =   1956000 TRACKS
> PRIMARY SPACE  =  4350  -  SECONDARY SPACE --- =  4350 CYL
> MULTIVOLUME -- =   PRIMARY  -  MAX SECONDARY - =  4350 CYL
> RELEASE -- =NO  -  SHARE OPTIONS - = 2
> DATA COMPRESS  =  SOFTWARE  -  INDEX COMPRESS  =   YES
> TOTAL RECORDS  = 447700657  -  INSERTS --- = 0
> UPDATES -- = 0  -  DELETES --- = 0
> HIGH USED RBA  = 104538978  -  HIGH ALLOCATED RBA  = 104538978 KB
> FILE DEFINED - =  2014.298  -  10/25/2014 -  6:26 PM - =  18:26:54
> FILE LOADED -- =  2014.298  -  10/25/2014 -  6:53 PM - =  18:53:07
>
> However when the dsn is defined as VSAM EXTENDED it shows
> TOTAL EXTENTS  = 2  -  TOTAL SPACE ALLOCATED - = 95250 TRACKS
> PRIMARY SPACE  =  6350  -  SECONDARY SPACE --- =  6350 CYL
> MULTIVOLUME -- =   PRIMARY  -  MAX SECONDARY - =  6350 CYL
> RELEASE -- =   YES  -  SHARE OPTIONS - = 2
> FILE DEFINED - =  2014.300  -  10/27/2014 -  1:17 PM - =  13:17:06
> NUMBER OF IAM DATA BLOCKS  = 0
> EXTENDED HIGH ALLOCATED RBN -- = 0
>
> I cannot understand why it is showing RELEASE -- =   YES ?  I thought 
> it could be coming from
> Space Constraint Relief . . . : YES
> I tried a test and changed the Space Constraint Relief . . . : NO however the 
> result was the same.
>
> Could someone shed some light?
>
> Thanks.
>
> --
> 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: DFHSM QUESTION - EXPIRATION OF DSN

HSM will happily back-up empty datasets. INVALID datasets are another matter. 
But, it is an easy matter to define a DEFAULT DATACLAS with DSORG=PS and never 
have another invalid dataset.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Willie Bunter
> Sent: Wednesday, October 29, 2014 6:14 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM QUESTION - EXPIRATION OF DSN
> 
> Bob,
> 
> We have a similar situation at our end.  There is a dsn with the following
> atribute:
> 
> Expire after Days Non-usage  . : 365.
> 
> Migration Attributes
>   Primary Days Non-usage  . : 2
>   Level 1 Days Date/Days  . : 10
>   Command or Auto Migrate . : BOTH
> 
> What if the DSN is empty and not backed (because HSM doesn't backup empty
> dsns) would the dsn be deleted after 365 days non-usage / non referenced?
> 
> --
> 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: QUESTION ABOUT VSAM / VSAM EXTENDED - IAMPRINT OUTPUT

I defined the dsn as VSAM EXTENDED format and I ran a LISTCAT to compare the 
before and after allocation.
Everything is okay except for the following:
When the dsn was NOT VSAM EXTENDED format the IAM100 IAM FILE ANALYSIS output 
showed :

TOTAL EXTENTS  =49  -  TOTAL SPACE ALLOCATED - =   1956000 TRACKS
PRIMARY SPACE  =  4350  -  SECONDARY SPACE --- =  4350 CYL   
MULTIVOLUME -- =   PRIMARY  -  MAX SECONDARY - =  4350 CYL   
RELEASE -- =NO  -  SHARE OPTIONS - = 2   
DATA COMPRESS  =  SOFTWARE  -  INDEX COMPRESS  =   YES   
TOTAL RECORDS  = 447700657  -  INSERTS --- = 0   
UPDATES -- = 0  -  DELETES --- = 0   
HIGH USED RBA  = 104538978  -  HIGH ALLOCATED RBA  = 104538978 KB
FILE DEFINED - =  2014.298  -  10/25/2014 -  6:26 PM - =  18:26:54   
FILE LOADED -- =  2014.298  -  10/25/2014 -  6:53 PM - =  18:53:07   

However when the dsn is defined as VSAM EXTENDED it shows 
TOTAL EXTENTS  = 2  -  TOTAL SPACE ALLOCATED - = 95250 TRACKS
PRIMARY SPACE  =  6350  -  SECONDARY SPACE --- =  6350 CYL   
MULTIVOLUME -- =   PRIMARY  -  MAX SECONDARY - =  6350 CYL   
RELEASE -- =   YES  -  SHARE OPTIONS - = 2   
FILE DEFINED - =  2014.300  -  10/27/2014 -  1:17 PM - =  13:17:06   
NUMBER OF IAM DATA BLOCKS  = 0   
EXTENDED HIGH ALLOCATED RBN -- = 0  

I cannot understand why it is showing RELEASE -- =   YES ?  I thought 
it could be coming from 
Space Constraint Relief . . . : YES  
I tried a test and changed the Space Constraint Relief . . . : NO however the 
result was the same.

Could someone shed some light?

Thanks.

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

Re: TS1150 and software installation

2014-10-29 Thread Tom Brennan

I don't want tape for product installations, but I can understand why 
others might.


The biggest problem I see with DVD/Internet installation is that the 
processes often seem to be created by non-mainframe people.  So you 
might see giant FTP's to/from PC's, firewall issues, USS files, Java, 
NFS, and even X-Windows as part of the installation process.  For some 
mainframe folks, these things are just not part of their regular 
activity.  A couple of months ago I went through such a process that 
literally took weeks because of network/security limitations, wrong 
turns, Java levels, HFS space, etc.  The end result was a group of MVS 
datasets, the same as a 5-minute IEBCOPY job from tape would have produced.


John Eells wrote:

I would like to hear from anyone who really *needs* tape delivery, 
whether on 3590 or on newer devices, along with the reason why it's 
needed.  You can post here if you want, but to avoid clutter you can 
just send me a note: ee...@us.ibm.com




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

Re: Has Anyone Seen this in ISPF before?

2014-10-29 Thread Thomas Conley


On 10/29/2014 11:35 AM, parke...@gmail.com wrote:

OK. Thanks. We are using RACF. What would dump? I will forward this to my boss 
to see what he wants to do.




IRRDBU00 will unload your RACF database to a flat file.  Also, look at 
the IRRUT100, IRRUT200, and IRRUT400 utilities.  One of them has a 
function to test the integrity of your RACF database.  Good luck.


Regards,
Tom Conley

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

Re: Has Anyone Seen this in ISPF before?

2014-10-29 Thread Thomas Conley


On 10/29/2014 7:50 AM, parke...@gmail.com wrote:

I appreciate all of the responses. I did a profile prefix(atljp), which fixed 
the problem. I have never seen such an odd occurrence in ISPF before.

John


John,

This is not an ISPF issue.  The corruption of the PREFIX data is a 
serious issue affecting your external security manager (ESM, such as 
RACF, ACF2, or TopSecret).  I'm assuming you have an ESM and are not 
using UADS.  The TSO PROFILE PREFIX command can't corrupt the data and 
store a value > 8 characters.  This is a bad problem to have, and you 
should continue to research to figure out what happened.  The earlier 
suggestion to unload your ESM database to check the prefix value is a 
good one.  You should check to see if other prefix values are corrupted, 
and if so, open a PMR with your ESM vendor


Regards,
Tom Conley

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

Re: DFHSM QUESTION - EXPIRATION OF DSN

Thanks for the tip.  This is very handy.

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

AW: Re: MEMLIMIT not honoured by DB2 utility job

>> Pretty sure that I read somewhere that DB2 has been written to ignore 
>> memlimit.>> Thanks. Will try to find this in DB2 docs.

I have found plenty of places where the discussion is about DB2's DBM1 and IRLM 
address spaces. Those ignore any MEMLIMIT setting and set this limit to values 
defined in DB2.

I could not find anything related to the utility program DSNX9WLM regarding 
MEMLIMIT.  Waiting for an answer from my DB2 colleagues.

--
Peter Hunkeler


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

Re: Configuring Swabar options programmatically

2014-10-29 Thread Mike Schwab

I use an IMACRO clist to set editing options for a member.

2014-10-29 7:31 GMT-05:00 גדי בן אבי :
> Hi,
>
> Is it possible to configure the swapbar options in z/OS v2.1 programmatically 
> in REXX?
>
> I would like to write a program that will set standard initial options.
>
> Thanks
>
> Gadi
>
> 
> לשימת לבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה 
> שלה (להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, 
> מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או 
> שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף 
> להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין 
> להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.
>
> Please note that in accordance with Malam and/or its subsidiaries 
> (hereinafter : "Malam") regulations and signatory rights, no offer, 
> agreement, concession or representation is binding on the Malam, unless 
> accompanied by a duly signed separate document (or a scanned version 
> thereof), affixed with the Malam seal.
>
> --
> 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: AW: Re: MEMLIMIT not honoured by DB2 utility job

W dniu 2014-10-29 o 15:10, Peter Hunkeler pisze:

Some hints:
REGION=0 means ignore MEMLIMIT.

I understand that specifying REGION=0K/M and *not* specifying MEMLIMIT (and not
having IEFUSI limiting it) implies MEMLIMIT=NOLIMIT. But if MEMLIMIT *is*
explicitly specified, it will be honoured and REGION=0K/M does not have any
influence in MEMLIMIT.

Correct.

DFSORT can consume memory even if MEMLIMIT is applied. It would use

dataspaces or hiperspaces instead. Does the ulitility invoke DFSORT
under the cover?

Do you say that DFSORT will ignore MEMLIMIT?

Yes, and no.
I had problems with some DB2 ulitity (reorg) which use DFSORT under the
cover. It consumed to much virtual memory causing paging.
I set MEMLIMIT in the jobcard. After that the problem still occured, but
DFSORT, instead of using 64-bit memory objects, was using dataspaces and
hiperspaces. So, formally MEMLIMIT was honored, because
dataspace/hiperspaces do not count for the limit.
After that I limited total amount of memory for DFSORT (some DFSORT
knob) and it helped.

Regards

--
Radoslaw Skorupka
Lodz, Poland

---
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2014 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.696.052 zote.

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

Re: DFHSM QUESTION - EXPIRATION OF DSN

Staller, Allan wrote:

>Expire means deleted and uncatalogued. 

Thanks. That will settle some burning issues with my storage admin who think it 
is RACF, but I could prove it is HSM. 

>Backups (if any) are handled as described in the MGMTCLAS for the dataset. 
>This is an entirely different set of processing. 

Yes, thanks for refreshing my memory. One of my DBAs found out too late there 
were no HSM backups for his *important* datasets. He could restore from an old 
DFDSS backup his old versions, rebuild the members and he is back in business.

Who said this? "He who has backup, laugh the last and loudest!"

Much appreciated!

Groete / Greetings 
Elardus Engelbrecht 

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

AW: Re: MEMLIMIT not honoured by DB2 utility job

> Pretty sure that I read somewhere that DB2 has been written to ignore 
> memlimit.

Thanks. Will try to find this in DB2 docs.

--Peter Hunkeler


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

AW: Re: MEMLIMIT not honoured by DB2 utility job

> Some hints:
> REGION=0 means ignore MEMLIMIT.
I understand that specifying REGION=0K/M and *not* specifying MEMLIMIT (and not 
having IEFUSI limiting it) implies MEMLIMIT=NOLIMIT. But if MEMLIMIT *is* 
explicitly specified, it will be honoured and REGION=0K/M does not have any 
influence in MEMLIMIT.


> DFSORT can consume memory even if MEMLIMIT is applied. It would use
dataspaces or hiperspaces instead. Does the ulitility invoke DFSORT
under the cover?


Do you say that DFSORT will ignore MEMLIMIT?


--


Peter Hunkeler

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

Re: Some help with racf

Carlos Bodra - Pessoal wrote:

>We are getting following console log for a adrssu job. Can anyone tell
>me what is wrong? Is racf avoiding volume usage? How can we chance this?

>  09.07.11 JOB07892  IEC089I 01  RACF VOL SET CONFLICT
>0506,CS0001,PCP0P442,STEP01

>  09.07.11 JOB07892  IEC502E R 0506,CS0001,SL,PCP0P442,STEP01
>  09.07.11 JOB07892 *IEC501A M
>0506,PRIVAT,SL,COMP,PCP0P442,STEP01,F5199.CFPP.GERAL
>  09.07.12 JOB07892  IEC089I 01  RACF VOL SET CONFLICT

... etc ...

Please post your DFDSS input statements too.

I would also ask beside Lizettes questions:

She mentioned TAPEVOL class.

Check whether ALL or NONE of tyour volsers are included in the TAPEVOL. If you 
have say 20 volsers, but you defined just 15, then you have a problem.

If all are defined check the accesses for them.

She also said about tapemanagement. Check with the admin how they are handling 
and passing access requests to RACF.

But then, this is worrying to me (edited for readability):

>   //CART1  DD DSN=F5199.CFPP.GERAL,
>//   DISP=(,CATLG),LABEL=(,SL),UNIT=VTL,VOL=SER=SCRTCH

You want to use a volser = SCRTCH? ???

As stated in JCL Ref:

"Do not code a volume serial number as SCRTCH, PRIVAT, or Ln (L with five 
numbers); these are used in messages to ask the operator to mount a volume. 
SCRTCH is used when the dataset being created on the non-specific volume is 
temporary [DISP=(NEW,DELETE) or "

Groete / Greetings
Elardus Engelbrecht

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

Re: DFHSM QUESTION - EXPIRATION OF DSN

2014-10-29 Thread Staller, Allan

Expire means deleted and uncatalogued.

Backups (if any) are handled as described in the MGMTCLAS for the dataset. 
This is an entirely different set of processing.

Staller, Allan wrote:

>Minor correction:

Thanks.

>After 4 days of non-usage, the dsn *will* migrate to ML1. 
>After 7  days of non-usage, it will migrate to ML2.  If not already migrated 
>to ML1, it will migrate directly to ML2.
>After 540 days, it will expire.

Just a little question if you don't mind, please:

'expire' - does it means it is deleted and uncataloged?

What about its backup(s)? Will it stays (with later HBDEL) or not? 

Ok, I will migrate back to under my rock...

Groete / Greetings
Elardus Engelbrecht

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

Re: DFHSM QUESTION - EXPIRATION OF DSN

Thank you Bob.

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

Re: Some help with racf

Some basic questions

What level of z/OS?
What do you use for your tape management data base (RMM, CA1, other?)

How often is this happening?
Did you recently change tapevol processing in RACF?

When was the last time this job ran successfully?

What manuals or internet searches have you done?

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Carlos Bodra - Pessoal
> Sent: Wednesday, October 29, 2014 6:57 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Some help with racf
> 
> We are getting following console log for a adrssu job. Can anyone tell me
what is
> wrong? Is racf avoiding volume usage? How can we chance this?
> 
> 9.07.05 JOB07892  WEDNESDAY, 29 OCT 2014 
>   09.07.05 JOB07892  IRR010I  USERID P000442  IS ASSIGNED TO THIS JOB.
>   09.07.10 JOB07892  ICH70001I P000442  LAST ACCESS AT 09:05:36 ON
> WEDNESDAY, OCTOBER 29, 2014
>   09.07.10 JOB07892  $HASP373 PCP0P442 STARTED - INIT 27   - CLASS E -
> SYS PD00
>   09.07.10 JOB07892  IEF403I PCP0P442 - STARTED - TIME=09.07.10
>   09.07.10 JOB07892 *IEF233A M
> 0506,SCRTCH,,PCP0P442,STEP01,F5199.CFPP.GERAL
>   09.07.11 JOB07892  IEC089I 01  RACF VOL SET CONFLICT
> 0506,CS0001,PCP0P442,STEP01
>   09.07.11 JOB07892  IEC502E R 0506,CS0001,SL,PCP0P442,STEP01
>   09.07.11 JOB07892 *IEC501A M
> 0506,PRIVAT,SL,COMP,PCP0P442,STEP01,F5199.CFPP.GERAL
>   09.07.12 JOB07892  IEC089I 01  RACF VOL SET CONFLICT
> 0506,CS0002,PCP0P442,STEP01
>   09.07.12 JOB07892  IEC502E R 0506,CS0002,SL,PCP0P442,STEP01
>   09.07.12 JOB07892 *IEC501A M
> 0506,PRIVAT,SL,COMP,PCP0P442,STEP01,F5199.CFPP.GERAL
>   09.07.12 JOB07892  IEC089I 01  RACF VOL SET CONFLICT
> 0506,CS0003,PCP0P442,STEP01
>   09.07.12 JOB07892  IEC502E R 0506,CS0003,SL,PCP0P442,STEP01
>   09.07.12 JOB07892 *IEC501A M
> 0506,PRIVAT,SL,COMP,PCP0P442,STEP01,F5199.CFPP.GERAL
>   09.07.12 JOB07892  IEC089I 01  RACF VOL SET CONFLICT
> 0506,CS0004,PCP0P442,STEP01
>   09.07.12 JOB07892  IEC502E R 0506,CS0004,SL,PCP0P442,STEP01
>   09.07.12 JOB07892 *IEC501A M
> 0506,PRIVAT,SL,COMP,PCP0P442,STEP01,F5199.CFPP.GERAL
>   09.07.12 JOB07892  IEC089I 01  RACF VOL SET CONFLICT
> 0506,CS0005,PCP0P442,STEP01
>   09.07.12 JOB07892  IEC502E R 0506,CS0005,SL,PCP0P442,STEP01
>   09.07.12 JOB07892 *IEC501A M
> 0506,PRIVAT,SL,COMP,PCP0P442,STEP01,F5199.CFPP.GERAL
>   09.07.12 JOB07892  IEC089I 01  RACF VOL SET CONFLICT
> 0506,CS0006,PCP0P442,STEP01
>   09.07.12 JOB07892  IEC502E R 0506,CS0006,SL,PCP0P442,STEP01
>   09.07.12 JOB07892 *IEC501A M
> 0506,PRIVAT,SL,COMP,PCP0P442,STEP01,F5199.CFPP.GERAL
>   09.07.12 JOB07892  IEC089I 01  RACF VOL SET CONFLICT
> 0506,CS0007,PCP0P442,STEP01
>   09.07.12 JOB07892  IEC502E R 0506,CS0007,SL,PCP0P442,STEP01
>   09.07.12 JOB07892 *IEC501A M
> 0506,PRIVAT,SL,COMP,PCP0P442,STEP01,F5199.CFPP.GERAL
>   09.07.12 JOB07892  IEC089I 01  RACF VOL SET CONFLICT
> 0506,CS0008,PCP0P442,STEP01
>   09.07.12 JOB07892  IEC502E R 0506,CS0008,SL,PCP0P442,STEP01
>   09.07.12 JOB07892 *IEC501A M
> 0506,PRIVAT,SL,COMP,PCP0P442,STEP01,F5199.CFPP.GERAL
>   1 //PCP0P442 JOB
> (5100,,99),MSGCLASS=P,CLASS=E,NOTIFY=P000442 JOB07892
> //* 00013000
>   2 //STEP01 EXEC
> PGM=ADRDSSU,REGION=4096K  00014400
>   3 //SYSPRINT   DD
> SYSOUT=(A,,STD1)00015005
>   4 //SYSOUT DD
> SYSOUT=(A,,STD1)00016002
>   5 //CART1  DD
> DSN=F5199.CFPP.GERAL,   00017000
> //
> DISP=(,CATLG),LABEL=(,SL),UNIT=VTL,VOL=SER=SCRTCH  00018004
>   6 //SYSIN  DD
> DDNAME=SYSIPT   00019000
>   7 //SYSIPT DD *
> /*  M E S T R E >
> MM0008
>   ICH70001I P000442  LAST ACCESS AT 09:05:36 ON WEDNESDAY,
> OCTOBER 29, 2014
>   IEF236I ALLOC. FOR PCP0P442 STEP01
>   IEF237I JES2 ALLOCATED TO SYSPRINT
>   IEF237I JES2 ALLOCATED TO SYSOUT
>   IGD100I 0506 ALLOCATED TO DDNAME CART1DATACLAS ()
> 
> 
> --
> 
> *Carlos Bodra
> IBM Certified zEnterprise
> Sao Paulo - SP - BRAZIL*
> 

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

Re: Some help with racf

If you have not done so, there is a RACF List
You can join at this url
http://www.listserv.uga.edu/archives/racf-l.html

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Carlos Bodra - Pessoal
> Sent: Wednesday, October 29, 2014 6:57 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Some help with racf
> 
> We are getting following console log for a adrssu job. Can anyone tell me
what is
> wrong? Is racf avoiding volume usage? How can we chance this?
> 
> 9.07.05 JOB07892  WEDNESDAY, 29 OCT 2014 
>   09.07.05 JOB07892  IRR010I  USERID P000442  IS ASSIGNED TO THIS JOB.
>   09.07.10 JOB07892  ICH70001I P000442  LAST ACCESS AT 09:05:36 ON
> WEDNESDAY, OCTOBER 29, 2014
>   09.07.10 JOB07892  $HASP373 PCP0P442 STARTED - INIT 27   - CLASS E -
> SYS PD00
>   09.07.10 JOB07892  IEF403I PCP0P442 - STARTED - TIME=09.07.10
>   09.07.10 JOB07892 *IEF233A M
> 0506,SCRTCH,,PCP0P442,STEP01,F5199.CFPP.GERAL
>   09.07.11 JOB07892  IEC089I 01  RACF VOL SET CONFLICT
> 0506,CS0001,PCP0P442,STEP01
>   09.07.11 JOB07892  IEC502E R 0506,CS0001,SL,PCP0P442,STEP01
>   09.07.11 JOB07892 *IEC501A M
> 0506,PRIVAT,SL,COMP,PCP0P442,STEP01,F5199.CFPP.GERAL
>   09.07.12 JOB07892  IEC089I 01  RACF VOL SET CONFLICT
> 0506,CS0002,PCP0P442,STEP01
>   09.07.12 JOB07892  IEC502E R 0506,CS0002,SL,PCP0P442,STEP01
>   09.07.12 JOB07892 *IEC501A M
> 0506,PRIVAT,SL,COMP,PCP0P442,STEP01,F5199.CFPP.GERAL
>   09.07.12 JOB07892  IEC089I 01  RACF VOL SET CONFLICT
> 0506,CS0003,PCP0P442,STEP01
>   09.07.12 JOB07892  IEC502E R 0506,CS0003,SL,PCP0P442,STEP01
>   09.07.12 JOB07892 *IEC501A M
> 0506,PRIVAT,SL,COMP,PCP0P442,STEP01,F5199.CFPP.GERAL
>   09.07.12 JOB07892  IEC089I 01  RACF VOL SET CONFLICT
> 0506,CS0004,PCP0P442,STEP01
>   09.07.12 JOB07892  IEC502E R 0506,CS0004,SL,PCP0P442,STEP01
>   09.07.12 JOB07892 *IEC501A M
> 0506,PRIVAT,SL,COMP,PCP0P442,STEP01,F5199.CFPP.GERAL
>   09.07.12 JOB07892  IEC089I 01  RACF VOL SET CONFLICT
> 0506,CS0005,PCP0P442,STEP01
>   09.07.12 JOB07892  IEC502E R 0506,CS0005,SL,PCP0P442,STEP01
>   09.07.12 JOB07892 *IEC501A M
> 0506,PRIVAT,SL,COMP,PCP0P442,STEP01,F5199.CFPP.GERAL
>   09.07.12 JOB07892  IEC089I 01  RACF VOL SET CONFLICT
> 0506,CS0006,PCP0P442,STEP01
>   09.07.12 JOB07892  IEC502E R 0506,CS0006,SL,PCP0P442,STEP01
>   09.07.12 JOB07892 *IEC501A M
> 0506,PRIVAT,SL,COMP,PCP0P442,STEP01,F5199.CFPP.GERAL
>   09.07.12 JOB07892  IEC089I 01  RACF VOL SET CONFLICT
> 0506,CS0007,PCP0P442,STEP01
>   09.07.12 JOB07892  IEC502E R 0506,CS0007,SL,PCP0P442,STEP01
>   09.07.12 JOB07892 *IEC501A M
> 0506,PRIVAT,SL,COMP,PCP0P442,STEP01,F5199.CFPP.GERAL
>   09.07.12 JOB07892  IEC089I 01  RACF VOL SET CONFLICT
> 0506,CS0008,PCP0P442,STEP01
>   09.07.12 JOB07892  IEC502E R 0506,CS0008,SL,PCP0P442,STEP01
>   09.07.12 JOB07892 *IEC501A M
> 0506,PRIVAT,SL,COMP,PCP0P442,STEP01,F5199.CFPP.GERAL
>   1 //PCP0P442 JOB
> (5100,,99),MSGCLASS=P,CLASS=E,NOTIFY=P000442 JOB07892
> //* 00013000
>   2 //STEP01 EXEC
> PGM=ADRDSSU,REGION=4096K  00014400
>   3 //SYSPRINT   DD
> SYSOUT=(A,,STD1)00015005
>   4 //SYSOUT DD
> SYSOUT=(A,,STD1)00016002
>   5 //CART1  DD
> DSN=F5199.CFPP.GERAL,   00017000
> //
> DISP=(,CATLG),LABEL=(,SL),UNIT=VTL,VOL=SER=SCRTCH  00018004
>   6 //SYSIN  DD
> DDNAME=SYSIPT   00019000
>   7 //SYSIPT DD *
> /*  M E S T R E >
> MM0008
>   ICH70001I P000442  LAST ACCESS AT 09:05:36 ON WEDNESDAY,
> OCTOBER 29, 2014
>   IEF236I ALLOC. FOR PCP0P442 STEP01
>   IEF237I JES2 ALLOCATED TO SYSPRINT
>   IEF237I JES2 ALLOCATED TO SYSOUT
>   IGD100I 0506 ALLOCATED TO DDNAME CART1DATACLAS ()
> 
> 
> --
> 
> *Carlos Bodra
> IBM Certified zEnterprise
> Sao Paulo - SP - BRAZIL*
> 
> --
> 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

Some help with racf

2014-10-29 Thread Carlos Bodra - Pessoal

We are getting following console log for a adrssu job. Can anyone tell 
me what is wrong? Is racf avoiding volume usage? How can we chance this?


9.07.05 JOB07892  WEDNESDAY, 29 OCT 2014 
 09.07.05 JOB07892  IRR010I  USERID P000442  IS ASSIGNED TO THIS JOB.
 09.07.10 JOB07892  ICH70001I P000442  LAST ACCESS AT 09:05:36 ON 
WEDNESDAY, OCTOBER 29, 2014
 09.07.10 JOB07892  $HASP373 PCP0P442 STARTED - INIT 27   - CLASS E - 
SYS PD00

 09.07.10 JOB07892  IEF403I PCP0P442 - STARTED - TIME=09.07.10
 09.07.10 JOB07892 *IEF233A M 0506,SCRTCH,,PCP0P442,STEP01,F5199.CFPP.GERAL
 09.07.11 JOB07892  IEC089I 01  RACF VOL SET CONFLICT 
0506,CS0001,PCP0P442,STEP01

 09.07.11 JOB07892  IEC502E R 0506,CS0001,SL,PCP0P442,STEP01
 09.07.11 JOB07892 *IEC501A M 
0506,PRIVAT,SL,COMP,PCP0P442,STEP01,F5199.CFPP.GERAL
 09.07.12 JOB07892  IEC089I 01  RACF VOL SET CONFLICT 
0506,CS0002,PCP0P442,STEP01

 09.07.12 JOB07892  IEC502E R 0506,CS0002,SL,PCP0P442,STEP01
 09.07.12 JOB07892 *IEC501A M 
0506,PRIVAT,SL,COMP,PCP0P442,STEP01,F5199.CFPP.GERAL
 09.07.12 JOB07892  IEC089I 01  RACF VOL SET CONFLICT 
0506,CS0003,PCP0P442,STEP01

 09.07.12 JOB07892  IEC502E R 0506,CS0003,SL,PCP0P442,STEP01
 09.07.12 JOB07892 *IEC501A M 
0506,PRIVAT,SL,COMP,PCP0P442,STEP01,F5199.CFPP.GERAL
 09.07.12 JOB07892  IEC089I 01  RACF VOL SET CONFLICT 
0506,CS0004,PCP0P442,STEP01

 09.07.12 JOB07892  IEC502E R 0506,CS0004,SL,PCP0P442,STEP01
 09.07.12 JOB07892 *IEC501A M 
0506,PRIVAT,SL,COMP,PCP0P442,STEP01,F5199.CFPP.GERAL
 09.07.12 JOB07892  IEC089I 01  RACF VOL SET CONFLICT 
0506,CS0005,PCP0P442,STEP01

 09.07.12 JOB07892  IEC502E R 0506,CS0005,SL,PCP0P442,STEP01
 09.07.12 JOB07892 *IEC501A M 
0506,PRIVAT,SL,COMP,PCP0P442,STEP01,F5199.CFPP.GERAL
 09.07.12 JOB07892  IEC089I 01  RACF VOL SET CONFLICT 
0506,CS0006,PCP0P442,STEP01

 09.07.12 JOB07892  IEC502E R 0506,CS0006,SL,PCP0P442,STEP01
 09.07.12 JOB07892 *IEC501A M 
0506,PRIVAT,SL,COMP,PCP0P442,STEP01,F5199.CFPP.GERAL
 09.07.12 JOB07892  IEC089I 01  RACF VOL SET CONFLICT 
0506,CS0007,PCP0P442,STEP01

 09.07.12 JOB07892  IEC502E R 0506,CS0007,SL,PCP0P442,STEP01
 09.07.12 JOB07892 *IEC501A M 
0506,PRIVAT,SL,COMP,PCP0P442,STEP01,F5199.CFPP.GERAL
 09.07.12 JOB07892  IEC089I 01  RACF VOL SET CONFLICT 
0506,CS0008,PCP0P442,STEP01

 09.07.12 JOB07892  IEC502E R 0506,CS0008,SL,PCP0P442,STEP01
 09.07.12 JOB07892 *IEC501A M 
0506,PRIVAT,SL,COMP,PCP0P442,STEP01,F5199.CFPP.GERAL
 1 //PCP0P442 JOB 
(5100,,99),MSGCLASS=P,CLASS=E,NOTIFY=P000442 JOB07892

//* 00013000
 2 //STEP01 EXEC 
PGM=ADRDSSU,REGION=4096K  00014400
 3 //SYSPRINT   DD 
SYSOUT=(A,,STD1)00015005
 4 //SYSOUT DD 
SYSOUT=(A,,STD1)00016002
 5 //CART1  DD 
DSN=F5199.CFPP.GERAL,   00017000
   // 
DISP=(,CATLG),LABEL=(,SL),UNIT=VTL,VOL=SER=SCRTCH  00018004
 6 //SYSIN  DD 
DDNAME=SYSIPT   00019000

 7 //SYSIPT DD *
   /*  M E S T R E > 
MM0008

 ICH70001I P000442  LAST ACCESS AT 09:05:36 ON WEDNESDAY, OCTOBER 29, 2014
 IEF236I ALLOC. FOR PCP0P442 STEP01
 IEF237I JES2 ALLOCATED TO SYSPRINT
 IEF237I JES2 ALLOCATED TO SYSOUT
 IGD100I 0506 ALLOCATED TO DDNAME CART1DATACLAS ()


--

*Carlos Bodra
IBM Certified zEnterprise
Sao Paulo - SP - BRAZIL*

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

Re: DFHSM QUESTION - EXPIRATION OF DSN

Hmmm, will this thread ever *expires* ? :-D  ;-D  :-D

Staller, Allan wrote:

>Minor correction:

Thanks.

>After 4 days of non-usage, the dsn *will* migrate to ML1. 
>After 7  days of non-usage, it will migrate to ML2.  If not already migrated 
>to ML1, it will migrate directly to ML2.
>After 540 days, it will expire.

Just a little question if you don't mind, please:

'expire' - does it means it is deleted and uncataloged?

What about its backup(s)? Will it stays (with later HBDEL) or not? 

Ok, I will migrate back to under my rock...

Groete / Greetings
Elardus Engelbrecht

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

Re: DFHSM QUESTION - EXPIRATION OF DSN

2014-10-29 Thread Staller, Allan

There is a bit that can be set. 

Check the dfHSM Implementation Guide for
" Disabling delete-if-backed-up (DBU) processing for SMS data Sets"


We have a similar situation at our end.  There is a dsn with the following 
atribute:

Expire after Days Non-usage  . : 365.

Migration Attributes 
  Primary Days Non-usage  . : 2  
  Level 1 Days Date/Days  . : 10   
  Command or Auto Migrate . : BOTH   

What if the DSN is empty and not backed (because HSM doesn't backup empty dsns) 
would the dsn be deleted after 365 days non-usage / non referenced?



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

Re: DFHSM QUESTION - EXPIRATION OF DSN

2014-10-29 Thread Richards, Robert B.

Yes. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Willie Bunter
Sent: Wednesday, October 29, 2014 9:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM QUESTION - EXPIRATION OF DSN

Bob,

We have a similar situation at our end.  There is a dsn with the following 
atribute:

Expire after Days Non-usage  . : 365.

Migration Attributes 
  Primary Days Non-usage  . : 2  
  Level 1 Days Date/Days  . : 10   
  Command or Auto Migrate . : BOTH   

What if the DSN is empty and not backed (because HSM doesn't backup empty dsns) 
would the dsn be deleted after 365 days non-usage / non referenced?

--
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: DFHSM QUESTION - EXPIRATION OF DSN

2014-10-29 Thread Staller, Allan


After 4 days of non-usage, the dsn *will* migrate to ML1. After 7 more days of 
non-usage, it will migrate to ML2. After 540 days, it will expire.


Minor correction:

After 4 days of non-usage, the dsn *will* migrate to ML1. 
After 7  days of non-usage, it will migrate to ML2.  If not already migrated to 
ML1, it will migrate directly to ML2.
After 540 days, it will expire.


HTH,


After 4 days of non-usage, the dsn *will* migrate to ML1. After 7 more days of 
non-usage, it will migrate to ML2. After 540 days, it will expire.

If the dataset has not migrated, numerous possible conditions exist:

1) it was referenced and therefore not eligible for migration because of usage.
2) it has not been backed up and is not eligible for migration
3) the volume is not eligible for migration and/or backup
4) something else is afoot that we are not aware of (premature ending of space 
management windows, etc.)

Bob
snipage
I have a question about the expiration of a dsn by HSM.  The rule says the 
following :

 Expiration Attributes
  
   Expire after Days Non-usage  . : 540   
   Expire after Date/Days . . . . : NOLIMIT   
   Retention Limit  . . . . . . . : 0 

However the Migration attributes are as follows:

Migration Attributes
  Primary Days Non-usage  . : 4 
  Level 1 Days Date/Days  . : 7 
  Command or Auto Migrate . : BOTH  

My question is will HSM delete the dsn if it is NOT migrated?  I think that the 
DSN needs to be migrated in order for HSM to delte the dsn.  Could anybody 
confirm my comprehension or mis-comprehension should it be the case?


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

Re: Configuring Swabar options programmatically

What options are you thinking of setting that are not in the ISRCONFG
process?

Could you provide examples?


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of ??? ?? ???
> Sent: Wednesday, October 29, 2014 5:32 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Configuring Swabar options programmatically
> 
> Hi,
> 
> Is it possible to configure the swapbar options in z/OS v2.1
programmatically in
> REXX?
> 
> I would like to write a program that will set standard initial options.
> 
> Thanks
> 
> Gadi
> 

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

Re: DFHSM QUESTION - EXPIRATION OF DSN

Bob,

We have a similar situation at our end.  There is a dsn with the following 
atribute:

Expire after Days Non-usage  . : 365.

Migration Attributes 
  Primary Days Non-usage  . : 2  
  Level 1 Days Date/Days  . : 10   
  Command or Auto Migrate . : BOTH   

What if the DSN is empty and not backed (because HSM doesn't backup empty dsns) 
would the dsn be deleted after 365 days non-usage / non referenced?

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

Re: MEMLIMIT not honoured by DB2 utility job

W dniu 2014-10-29 o 13:58, Peter Hunkeler pisze:

We've got a DB2 utility job (running DB2 Utilities Stored Procedures,
PGM=DSNX9WLM), thst is using much more storage that we want it to use.

Some time ago, we found that REGION=0M was specified but no MEMLIMIT. Since
we're running with the default IEFUSI (do nothing, successfully), this implied
MEMLIMIT=NOLIMIT. The JCL had been change to specify MEMLIMIT=25G.

We've had this job using ~250G storage, i.e. 10 time more. This value is what
the system reports in IEF032I at step end, as well as the value MainView
reports.

DSNX9WLM is not in the PPT, so NOHONOURIEFUSIREGION does not apply. What else
would allow a job to ignore MEMLIMIT?

--
Peter Hunkeler

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

Some hints:
REGION=0 means ignore MEMLIMIT.
DFSORT can consume memory even if MEMLIMIT is applied. It would use
dataspaces or hiperspaces instead. Does the ulitility invoke DFSORT
under the cover?

--
Radoslaw Skorupka
Lodz, Poland

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

Re: MEMLIMIT not honoured by DB2 utility job

2014-10-29 Thread Jousma, David

Pretty sure that I read somewhere that DB2 has been written to ignore memlimit.

_
Dave Jousma
Assistant Vice President, Mainframe Engineering
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: Wednesday, October 29, 2014 8:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: MEMLIMIT not honoured by DB2 utility job

We've got a DB2 utility job (running DB2 Utilities Stored Procedures, 
PGM=DSNX9WLM), thst is using much more storage that we want it to use. 


Some time ago, we found that REGION=0M was specified but no MEMLIMIT. Since 
we're running with the default IEFUSI (do nothing, successfully), this implied 
MEMLIMIT=NOLIMIT. The JCL had been change to specify MEMLIMIT=25G.


We've had this job using ~250G storage, i.e. 10 time more. This value is what 
the system reports in IEF032I at step end, as well as the value MainView 
reports.


 DSNX9WLM is not in the PPT, so NOHONOURIEFUSIREGION does not apply. What else 
would allow a job to ignore MEMLIMIT?

--
Peter Hunkeler

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

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

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

Re: DFHSM QUESTION - EXPIRATION OF DSN

2014-10-29 Thread esmie moo

Bob,

Thanks very much for your help.

On Wed, 10/29/14, Richards, Robert B.  wrote:

 Subject: Re: DFHSM QUESTION - EXPIRATION OF DSN
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Wednesday, October 29, 2014, 8:50 AM

 If the dsn is not
 migrated because migration is broken for that dataset *and*
 540 days go by, then YES, it will expire if it has not been
 referenced. For 540 days. It is not a matter of
 precedence.

 An exception to
 all this is threshold mangement. If HSM doesn't think
 the volume meets criteria to qualify for PSM or SSM, then a
 dataset can sit on a primary volume forever.

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of esmie moo
 Sent: Wednesday,
 October 29, 2014 8:24 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: DFHSM QUESTION - EXPIRATION OF
 DSN

 Bob,

 I understand that.  Hoever,
 if the dsn is not migrated will it be deleted?  Does the
 Expiration attributes take precdence over the Migration
 attributes/

 On Wed, 10/29/14, Richards, Robert B. 
 wrote:

  Subject: Re: DFHSM
 QUESTION - EXPIRATION OF DSN
  To: IBM-MAIN@LISTSERV.UA.EDU
  Received: Wednesday, October 29, 2014, 7:53
 AM

  Esmie,

  You are posing an invalid
  situation for what you specified.

  After 4 days of non-usage,
 the dsn *will*  migrate to ML1. After 7 more days of
 non-usage, it will  migrate to ML2. After 540 days, it will
 expire.

  If the dataset
 has not
  migrated, numerous possible
 conditions exist:

  1) it
 was referenced and
  therefore not eligible
 for migration because of usage.
  2) it has
 not been backed up and is not  eligible for migration
  3) the volume is not
  eligible
 for migration and/or backup
  4)
  something else is afoot that we are not aware
 of (premature  ending of space management windows, etc.)

  Bob

  -Original Message-

 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
 On Behalf Of esmie moo
  Sent: Wednesday,
  October 29, 2014 7:32 AM
  To:
 IBM-MAIN@LISTSERV.UA.EDU
  Subject: DFHSM QUESTION - EXPIRATION OF DSN

  Good Morning Gentle
  Readers,

  I
 have a question
  about the expiration of a
 dsn by HSM.  The rule says the  following :

   Expiration
  Attributes                       

     Expire
  after Days
 Non-usage  . : 540
     Expire after
 Date/Days . . . . :
  NOLIMIT
     Retention Limit  . . . . . . . :
  0         

  However the Migration attributes are as
  follows:

 Migration
  Attributes               

  Primary Days
 Non-usage  . : 4
    Level 1 Days
 Date/Days  . : 7 

   Command or Auto Migrate .
  : BOTH  

  My question is
  will HSM delete the dsn if it is NOT
 migrated?  I think  that the DSN needs to be migrated in
 order for HSM to delte  the dsn.  Could anybody confirm my
 comprehension or  mis-comprehension should it be the
 case?

  Thanks.

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

MEMLIMIT not honoured by DB2 utility job

We've got a DB2 utility job (running DB2 Utilities Stored Procedures, 
PGM=DSNX9WLM), thst is using much more storage that we want it to use.


Some time ago, we found that REGION=0M was specified but no MEMLIMIT. Since 
we're running with the default IEFUSI (do nothing, successfully), this implied 
MEMLIMIT=NOLIMIT. The JCL had been change to specify MEMLIMIT=25G.


We've had this job using ~250G storage, i.e. 10 time more. This value is what 
the system reports in IEF032I at step end, as well as the value MainView 
reports.


 DSNX9WLM is not in the PPT, so NOHONOURIEFUSIREGION does not apply. What else 
would allow a job to ignore MEMLIMIT?

--
Peter Hunkeler

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

Re: DFHSM QUESTION - EXPIRATION OF DSN

2014-10-29 Thread Richards, Robert B.

If the dsn is not migrated because migration is broken for that dataset *and* 
540 days go by, then YES, it will expire if it has not been referenced. For 540 
days. It is not a matter of precedence.

An exception to all this is threshold mangement. If HSM doesn't think the 
volume meets criteria to qualify for PSM or SSM, then a dataset can sit on a 
primary volume forever.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of esmie moo
Sent: Wednesday, October 29, 2014 8:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM QUESTION - EXPIRATION OF DSN

Bob,

I understand that.  Hoever, if the dsn is not migrated will it be deleted?  
Does the Expiration attributes take precdence over the Migration attributes/


On Wed, 10/29/14, Richards, Robert B.  wrote:

 Subject: Re: DFHSM QUESTION - EXPIRATION OF DSN
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Wednesday, October 29, 2014, 7:53 AM
 
 Esmie,
 
 You are posing an invalid
 situation for what you specified.
 
 After 4 days of non-usage, the dsn *will*  migrate to ML1. After 7 more days 
of non-usage, it will  migrate to ML2. After 540 days, it will expire.
 
 If the dataset has not
 migrated, numerous possible conditions exist:
 
 1) it was referenced and
 therefore not eligible for migration because of usage.
 2) it has not been backed up and is not  eligible for migration
 3) the volume is not
 eligible for migration and/or backup
 4)
 something else is afoot that we are not aware of (premature  ending of space 
management windows, etc.)
 
 Bob
 
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]  On 
Behalf Of esmie moo
 Sent: Wednesday,
 October 29, 2014 7:32 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: DFHSM QUESTION - EXPIRATION OF DSN
 
 Good Morning Gentle
 Readers,
 
 I have a question
 about the expiration of a dsn by HSM.  The rule says the  following :
 
  Expiration
 Attributes                        
                                
               
    Expire
 after Days Non-usage  . : 540
    Expire after Date/Days . . . . :
 NOLIMIT
    Retention Limit  . . . . . . . :
 0         
 
 However the Migration attributes are as
 follows:
 
 Migration
 Attributes                
  
 Primary Days Non-usage  . : 4
   Level 1 Days Date/Days  . : 7 
    
   Command or Auto Migrate .
 : BOTH  
 
 My question is
 will HSM delete the dsn if it is NOT migrated?  I think  that the DSN needs to 
be migrated in order for HSM to delte  the dsn.  Could anybody confirm my 
comprehension or  mis-comprehension should it be the case?
 
 Thanks.
 
 --
 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: TS1150 and software installation

W dniu 2014-10-28 o 22:00, John Eells pisze:

r.skoru...@snip-it.pl (R.S.) wrote:

A new tape drive was announced recently.
Tech specification says there is no upport for the oldest Jaguar
cartridges (JA aka ETC).
The question is how IBM solved a problem with software distribution?

Are there any plans to use new tape carts as an option for Shopzseries
software?

Radoslaw, I'm going to turn this around on you: Is there some reason
you can't use DVD- or Internet-based installation?

As it happens, we're looking very hard at this now because:

- Our competitors' tape drives don't read IBM recording formats (and
vice-versa); and,
- A lot of customers don't use real physical tapes at all any more,
relying on cross-site network-based backup and DR strategies instead;
and,
- A truly substantial majority use Internet-based installation today,
both for ServerPacs, products via Product ServerPac and CBPDO, and
service.

I would like to hear from anyone who really *needs* tape delivery,
whether on 3590 or on newer devices, along with the reason why it's
needed. You can post here if you want, but to avoid clutter you can
just send me a note: ee...@us.ibm.com

Well,
I do use Internet Delivery for all (rather few) CBPDO installations.
I always use ServerPac on tapes for z/OS, CICS, DB2 upgrade.

I like tapes, because it is easier to manage big amounts of data. For
Internet Delivery you have to store it on PC (yes, it can be avoided,
but the rules does not allow me to connect SMP/E to Internet)), then
upload it to HFS space - which means a lot of space. Then unzip it +
receive in one or two steps. Again, a lot of disk space consumed.

Tape is much more convenient.
Note, the z/VM installation does not require all disk space on the
stages as above - data is copied directly from DVD (or ftp) to "TGT"
volumes.

BTW: I still keep Magstar drives, the only purpose of it is software
installation. The TCO is zero since it is not under any support. I also
caould use Jaguar JA media, but I prefer standalone MAGSTAR over
library-resident Jaguars.

Regards

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

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

Configuring Swabar options programmatically

2014-10-29 Thread גדי בן אבי

Hi,

Is it possible to configure the swapbar options in z/OS v2.1 programmatically 
in REXX?

I would like to write a program that will set standard initial options.

Thanks

Gadi


לשימת לבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה שלה 
(להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, 
מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או 
שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף 
להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין 
להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.

Please note that in accordance with Malam and/or its subsidiaries (hereinafter 
: "Malam") regulations and signatory rights, no offer, agreement, concession or 
representation is binding on the Malam, unless accompanied by a duly signed 
separate document (or a scanned version thereof), affixed with the Malam seal.

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

Re: ZFS dataset space allocation query

W dniu 2014-10-29 o 10:41, John Compton pisze:

I've recently been having a bit of fun(?) solving a problem where one of
our ZFS clusters was allowed to fill all the space allocated to it.

Along the way I (re)discovered in "Distributed File Service zSeries File
System Administration" (SC24-5989):

...Assuming that each volume is a 3390 with 3338 cylinders (with 3336
cylinders free), that there are 15 tracks per cylinder and that you can get
6 8K blocks per track (15 x 6 = 90 8K blocks per cylinder), you should get
90 x 3336 = 300240 8K blocks per volume and 10 x 300240 = 3002400 8K blocks
in the aggregate...

My question is: "Is there any way to change that 8K block size up to
something larger?"

IMHO no, you can't change it.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: DFHSM QUESTION - EXPIRATION OF DSN

2014-10-29 Thread esmie moo

Bob,

I understand that.  Hoever, if the dsn is not migrated will it be deleted?  
Does the Expiration attributes take precdence over the Migration attributes/

On Wed, 10/29/14, Richards, Robert B.  wrote:

 Subject: Re: DFHSM QUESTION - EXPIRATION OF DSN
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Wednesday, October 29, 2014, 7:53 AM

 Esmie,

 You are posing an invalid
 situation for what you specified.

 After 4 days of non-usage, the dsn *will*
 migrate to ML1. After 7 more days of non-usage, it will
 migrate to ML2. After 540 days, it will expire.

 If the dataset has not
 migrated, numerous possible conditions exist:

 1) it was referenced and
 therefore not eligible for migration because of usage.
 2) it has not been backed up and is not
 eligible for migration
 3) the volume is not
 eligible for migration and/or backup  
 4)
 something else is afoot that we are not aware of (premature
 ending of space management windows, etc.)

 Bob

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of esmie moo
 Sent: Wednesday,
 October 29, 2014 7:32 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: DFHSM QUESTION - EXPIRATION OF DSN

 Good Morning Gentle
 Readers,

 I have a question
 about the expiration of a dsn by HSM.  The rule says the
 following :

  Expiration
 Attributes                        

    Expire
 after Days Non-usage  . : 540       
    Expire after Date/Days . . . . :
 NOLIMIT   
    Retention Limit  . . . . . . . :
 0         

 However the Migration attributes are as
 follows:

 Migration
 Attributes                

 Primary Days Non-usage  . : 4     
   Level 1 Days Date/Days  . : 7 

   Command or Auto Migrate .
 : BOTH  

 My question is
 will HSM delete the dsn if it is NOT migrated?  I think
 that the DSN needs to be migrated in order for HSM to delte
 the dsn.  Could anybody confirm my comprehension or
 mis-comprehension should it be the case?

 Thanks.

 --
 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: DFHSM QUESTION - EXPIRATION OF DSN

2014-10-29 Thread Richards, Robert B.

Esmie,

You are posing an invalid situation for what you specified.

After 4 days of non-usage, the dsn *will* migrate to ML1. After 7 more days of 
non-usage, it will migrate to ML2. After 540 days, it will expire.

If the dataset has not migrated, numerous possible conditions exist:

1) it was referenced and therefore not eligible for migration because of usage.
2) it has not been backed up and is not eligible for migration
3) the volume is not eligible for migration and/or backup  
4) something else is afoot that we are not aware of (premature ending of space 
management windows, etc.)

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of esmie moo
Sent: Wednesday, October 29, 2014 7:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DFHSM QUESTION - EXPIRATION OF DSN

Good Morning Gentle Readers,

I have a question about the expiration of a dsn by HSM.  The rule says the 
following :

 Expiration Attributes
  
   Expire after Days Non-usage  . : 540   
   Expire after Date/Days . . . . : NOLIMIT   
   Retention Limit  . . . . . . . : 0 

However the Migration attributes are as follows:

Migration Attributes
  Primary Days Non-usage  . : 4 
  Level 1 Days Date/Days  . : 7 
  Command or Auto Migrate . : BOTH  

My question is will HSM delete the dsn if it is NOT migrated?  I think that the 
DSN needs to be migrated in order for HSM to delte the dsn.  Could anybody 
confirm my comprehension or mis-comprehension should it be the case?

Thanks.

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

DFHSM QUESTION - EXPIRATION OF DSN

2014-10-29 Thread esmie moo

Good Morning Gentle Readers,

I have a question about the expiration of a dsn by HSM.  The rule says the 
following :

 Expiration Attributes
  
   Expire after Days Non-usage  . : 540   
   Expire after Date/Days . . . . : NOLIMIT   
   Retention Limit  . . . . . . . : 0 

However the Migration attributes are as follows:

Migration Attributes
  Primary Days Non-usage  . : 4 
  Level 1 Days Date/Days  . : 7 
  Command or Auto Migrate . : BOTH  

My question is will HSM delete the dsn if it is NOT migrated?  I think that the 
DSN needs to be migrated in order for HSM to delte the dsn.  Could anybody 
confirm my comprehension or mis-comprehension should it be the case?

Thanks.

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

Re: ZFS dataset space allocation query