AW: Re: [Bulk] Re: [IBM-MAIN] Minimum Volume Sizes in the Wild

[Peter Hunkeler]

When I was with IBM Education, we used to run class labs on minimal z/OS 
(OS/390, MVS/...) systems as VM guests. The volumes were VM mini volumes just 
as large as needed. If VM is still the base for those labs, I'm pretty sure 
there still are volumes of various small sizes.

Not sure however if this matters for your query.

--Peter Hunkeler


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Tuesday, June 28, 2016 9:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Minimum Volume Sizes in the Wild

What is the *smallest* volume size everyone sees in general use?

For example, will we create any problems if we assume that "everyone"
has or can define at least a 3390-9 size volume these days?  What if we chose 
3390-27?



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

Re: [Bulk] Re: [IBM-MAIN] Minimum Volume Sizes in the Wild

[Ron Hawkins]

John,

I'm not sure what you mean by "general use."

For HDS Business Continuity Manager software some customers will allocate a 
small volume for the command devices (let's say 10 cyls), often using the odd 
cyls left over on a Parity Group after formatting a bunch of common sized 
volumes (-3, -9, -27, etc). They are also handy for JES2 Checkpoints, RACF 
Primary/Secondary, etc. EMC pushed the idea decades ago with the hypervolume 
concept.

The various vendor thin provisioning capabilities may be reducing the frequency 
of this approach, as you can use the whole Parity Group for the pool, allocate 
a 3390-A in the pool, and then just use a few Cyls for your JES2 Checkpoint. 
Iceberg/RVA users will be familiar with this.

Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Beaver
Sent: Tuesday, June 28, 2016 6:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [Bulk] Re: [IBM-MAIN] Minimum Volume Sizes in the Wild

The smallest I've seen is a MOD3.  And that is just because it had a CAT on it

Steve  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Al Loeffler
Sent: Tuesday, June 28, 2016 8:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Minimum Volume Sizes in the Wild

I use 3390-27 for z/OS and other software installation, but I also use other 
sizes (3390-1, 3390-3, 3390-9, 3390-54) for operational and user datasets.

Al Loeffler

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Tuesday, June 28, 2016 9:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Minimum Volume Sizes in the Wild

What is the *smallest* volume size everyone sees in general use?

For example, will we create any problems if we assume that "everyone" 
has or can define at least a 3390-9 size volume these days?  What if we chose 
3390-27?

--
John Eells
IBM Poughkeepsie
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

--
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: Minimum Volume Sizes in the Wild

[Steve Beaver]

The smallest I've seen is a MOD3.  And that is just because it had a CAT on it

Steve  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Al Loeffler
Sent: Tuesday, June 28, 2016 8:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Minimum Volume Sizes in the Wild

I use 3390-27 for z/OS and other software installation, but I also use other 
sizes (3390-1, 3390-3, 3390-9, 3390-54) for operational and user datasets.

Al Loeffler

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Tuesday, June 28, 2016 9:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Minimum Volume Sizes in the Wild

What is the *smallest* volume size everyone sees in general use?

For example, will we create any problems if we assume that "everyone" 
has or can define at least a 3390-9 size volume these days?  What if we chose 
3390-27?

--
John Eells
IBM Poughkeepsie
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

--
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: Minimum Volume Sizes in the Wild

[Al Loeffler]

I use 3390-27 for z/OS and other software installation, but I also use other 
sizes (3390-1, 3390-3, 3390-9, 3390-54) for operational and user datasets.

Al Loeffler

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Tuesday, June 28, 2016 9:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Minimum Volume Sizes in the Wild

What is the *smallest* volume size everyone sees in general use?

For example, will we create any problems if we assume that "everyone" 
has or can define at least a 3390-9 size volume these days?  What if we chose 
3390-27?

--
John Eells
IBM Poughkeepsie
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

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

Re: Netstat (EZANS) for z/OS 2.2

[Anthony Thompson]

It's not at all difficult to keep it working. Update the initialization section 
of the EZANS REXX from around line 180-ish on. I don't think there have been 
any changes to the netstat command syntax since z/OS 1.13.

Ant. 

/**/
/**/
/* Determine release of this z/OS system and initialize our   */
/* release identifier variable: z/OS VnRn */
/**/
/* Also initialize a numeric representation of this release to be */
/* used when determining which functions are available at which   */
/* releases.  Format of this is 'oovvrr' - oo is 01 for z/OS, vv is   */
/* 2-digit version, and rr is 2-digit release.  z/OS V1R4: '010104'   */
/**/
/**/

address ISPEXEC "VGET (ZOS390RL ZSYSID) ASIS"   
parse var ZOS390RL EZANSOS " " EZANSOSV "." EZANSOSR "." EZANSOSM . 
EZANSOSV = right(EZANSOSV,2)
if ezatracei then do
   say h||'ZOS390RL='ZOS390RL   
   say h||'OS='EZANSOS  
   say h||'VV='EZANSOSV 
   say h||'RR='EZANSOSR 
   say h||'MM='EZANSOSM  
end 

EZANSOSV = right(EZANSOSV,1)
If EZANSOSR < '10' then 
   EZANSOSR = right(EZANSOSR,1) 
EZANSREL = EZANSOS||" V"||EZANSOSV||'R'||EZANSOSR   

if ezatracei then say h||'EZANSREL='EZANSREL
EZANSHDT = EZANSREL||' CS TCP/IP NETSTAT'   

if ezatracei then say h||'EZANSHDT='EZANSHDT

zosv1r4 = '010104'  
zosv1r5 = '010105'  
zosv1r6 = '010106'  
zosv1r7 = '010107'  
zosv1r8 = '010108'  
zosv1r9 = '010109'  
zosv1r10 = '010110' 
zosv1r11 = '010111' 
zosv1r12 = '010112' 
zosv1r13 = '010113' 
zosv2r1  = '010201' /* Ant1 */  
zosv2r2  = '010202' /* Ant2 */  

thisrel = zosv1r4   

if EZANSREL = 'z/OS V1R4' then  
   thisrel = zosv1r4
if EZANSREL = 'z/OS V1R5' then  
   thisrel = zosv1r5
if EZANSREL = 'z/OS V1R6' then  
   thisrel = zosv1r6
if EZANSREL = 'z/OS V1R7' then  
   thisrel = zosv1r7
if EZANSREL = 'z/OS V1R8' then  
   thisrel = zosv1r8
if EZANSREL = 'z/OS V1R9' then   
   thisrel = zosv1r9 
if EZANSREL = 'z/OS V1R10' then  
   thisrel = zosv1r10
if EZANSREL = 'z/OS V1R11' then  
   thisrel = zosv1r11
if EZANSREL = 'z/OS V1R12' then  
   thisrel = zosv1r12
if EZANSREL = 'z/OS V1R13' then  
   thisrel = zosv1r13
if EZANSREL = 'z/OS V2R1'  then /* Ant1 */   
   thisrel = zosv2r1/* Ant1 */   
if EZANSREL = 'z/OS V2R2'  then /* Ant2 */   
   thisrel = zosv2r2/* Ant2 */   
 
EZANSCRL = thisrel   
address ISPEXEC "VPUT (EZANSCRL) SHARED" 
 
If ezatracei then say h||'Thisrel='thisrel   


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Wednesday, 29 June 2016 1:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Netstat (EZANS) for z/OS 2.2

My last conversations with IBM on this is - not supported.  It was a tool 
developed by an IBMer that retired and the Communication Server Team preferred 
not to 

Re: Verify record cound against the file trailer [by SORT?]

[Sri h Kolusu]

Peter,

My apologies for the typo about not changing the hex notation to character 
notation for the Trailer include statement. I just modified the control 
cards to suit your new requirement and forgot to change it in all place. 
My Bad.

Thanks,
Kolusu
DFSORT Development
IBM Corporation



From:   "Farley, Peter x23353" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   06/28/2016 03:27 PM
Subject:Re: Verify record cound against the file trailer [by 
SORT?]
Sent by:IBM Mainframe Discussion List 



Many thanks once more Sri for your generous help.  UFF was indeed the key 
factor.

For the archives, one small correction:

  INCLUDE=(16,4,CH,EQ,X'0999',AND,$ TRL RECORD

Should be:

  INCLUDE=(16,4,CH,EQ,C'0999',AND,$ TRL RECORD

(C'0999" for the trailer, not X'0999').

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Sri h Kolusu
Sent: Tuesday, June 28, 2016 4:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Verify record cound against the file trailer [by SORT?]

Peter,

It is quite simple to verify the variable length. You just need to use UFF 

( Unsigned free format ) instead of ZD which will automatically format the 

variable value by ignoring any thing other than a numeric and pad it with 
zeros.

Example :

//SYSINDD * 
  OPTION COPY 
  INREC IFTHEN=(WHEN=INIT, 
   BUILD=(1,4,   $ RDW 
  SEQNUM,11,ZD,  $ RECORD NUMBER 
  005,15)),  $ INDICATOR+COUNT 
  IFTHEN=(WHEN=(16,4,CH,EQ,C'0999'), $ IF TRL  RECORD 
   OVERLAY=(5:5,11,ZD,SUB,+2,M11,LENGTH=11)) $ SUBTRACT 2 
 
  OUTFIL FNAMES=SORTOUT,NULLOFL=RC4, 
  INCLUDE=(16,4,CH,EQ,X'0999',AND,$ TRL RECORD 
   (05,11,UFF,EQ,20,11,UFF))  $ IS COUNT=TRL COUNT? 
//* 


Thanks,
Kolusu
DFSORT Development
IBM Corporation



From:   "Farley, Peter x23353" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   06/28/2016 01:00 PM
Subject:Re: Verify record cound against the file trailer [by 
SORT?]
Sent by:IBM Mainframe Discussion List 



Thanks again Sri, your new version also worked as long as I changed the 
OUTFIL DD name.

Another colleague came to me with this one today.  How could we handle 
variable-length count data in a trailer?  For example (RECFM=VB file):

,This is a header
0100,data record 1
0100,data record 2
Etc.
0100,data record 21
0999,21

The last record is a trailer with variable-length data record count. 
Maximum count field length is 11.

TIA for any suggestions you can offer.

Peter
--

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@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

Possible RFE: OMVS PDS-member serialization?

[Paul Gilmartin]

Would there be much support for an RFE like this?  (Would
it be a duplicate -- the idea seems obvious?)  Any
suggested changes or paraphrases or clearer terminology?

Enhance OMVS "cp" and other utilities to employ ISPF-like
member-level serialization.  This would allow OMVS to update
PDS libraries that are othewise allocated SHR.  For example:

I'm editing CLIST(FOO) with z/OS ISPF Edit.  From a Solaris NFS
client, I try:

user@SunOS.5.11: cd clist
user@SunOS.5.11: date >foo
ksh: foo: cannot create [Permission denied]

( ... which really means "data set in use".)  So I CANcel my
Edit session, then:

user@SunOS.5.11: date >foo  # Succeeds!

NFS appears to be using ISPF serialization with member granularity.
In my experience, FTP Server does likewise.

Now, from z/OS UNIX System services:

user@OS/390.25.00: date | cp /dev/fd/0 "//CLIST(foo)"
cp: FSUM6259 target file "//CLIST(foo)": EDC5061I An error occurred when 
attempting to define a file to the system.

... CLIST is allocated; member is not in use, but "cp" doesn't know any better.
I log off TSO, then:

user@OS/390.25.00: date | cp /dev/fd/0 "//CLIST(foo)"  # Succeeds!

It's an undue burden to need to log off in order to update with OMVS
data sets that are allocated in TSO LOGON PROC.  OMVS should use
the techniques that NFS and FTP use.

If the restriction is intrinsic to the "C" Runtime, consider this
an RFE on "C".  So much the better to have a broader solution.

Thanks,
gil

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

Re: Verify record cound against the file trailer [by SORT?]

[Farley, Peter x23353]

Many thanks once more Sri for your generous help.  UFF was indeed the key 
factor.

For the archives, one small correction:

  INCLUDE=(16,4,CH,EQ,X'0999',AND,$ TRL RECORD

Should be:

  INCLUDE=(16,4,CH,EQ,C'0999',AND,$ TRL RECORD

(C'0999" for the trailer, not X'0999').

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sri h Kolusu
Sent: Tuesday, June 28, 2016 4:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Verify record cound against the file trailer [by SORT?]

Peter,

It is quite simple to verify the variable length. You just need to use UFF 
( Unsigned free format ) instead of ZD which will automatically format the 
variable value by ignoring any thing other than a numeric and pad it with 
zeros.

Example :

//SYSINDD * 
  OPTION COPY 
  INREC IFTHEN=(WHEN=INIT, 
   BUILD=(1,4,   $ RDW 
  SEQNUM,11,ZD,  $ RECORD NUMBER 
  005,15)),  $ INDICATOR+COUNT 
  IFTHEN=(WHEN=(16,4,CH,EQ,C'0999'), $ IF TRL  RECORD 
   OVERLAY=(5:5,11,ZD,SUB,+2,M11,LENGTH=11)) $ SUBTRACT 2 
 
  OUTFIL FNAMES=SORTOUT,NULLOFL=RC4, 
  INCLUDE=(16,4,CH,EQ,X'0999',AND,$ TRL RECORD 
   (05,11,UFF,EQ,20,11,UFF))  $ IS COUNT=TRL COUNT? 
//* 


Thanks,
Kolusu
DFSORT Development
IBM Corporation



From:   "Farley, Peter x23353" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   06/28/2016 01:00 PM
Subject:Re: Verify record cound against the file trailer [by 
SORT?]
Sent by:IBM Mainframe Discussion List 



Thanks again Sri, your new version also worked as long as I changed the 
OUTFIL DD name.

Another colleague came to me with this one today.  How could we handle 
variable-length count data in a trailer?  For example (RECFM=VB file):

,This is a header
0100,data record 1
0100,data record 2
Etc.
0100,data record 21
0999,21

The last record is a trailer with variable-length data record count. 
Maximum count field length is 11.

TIA for any suggestions you can offer.

Peter
--

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

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

Destination z article: A Rewarding z/VSE Community

[Gabe Goldberg]

A Rewarding z/VSE Community
Fans focus on participation and knowledge sharing

http://destinationz.org/Mainframe-Solution/Trends/A-Rewarding-z-VSE-Community.aspx

http://tinyurl.com/he7wosp




--
Gabriel Goldberg, Computers and Publishing, inc.g...@gabegold.com
3401 Silver Maple Place, Falls Church, VA 22042   (703) 204-0433
LinkedIn:http://www.linkedin.com/in/gabegold Twitter: GabeG0


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

Re: Minimum Volume Sizes in the Wild

[Gibney, Dave]

We are on the third EMC RAID array since SLED days. First one with PAV. Looking 
at 4th array next year.

We've always migrated to like size volumes and added on to the end. Added some 
mod 9's from 1 to 2 and mod 27's from 2 to 3. Mostly for System work.

Mod 3's have always been fine for application files and Adabas.




> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Clark Morris
> Sent: Tuesday, June 28, 2016 2:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Minimum Volume Sizes in the Wild
> 
> [Default] On 28 Jun 2016 11:31:30 -0700, in bit.listserv.ibm-main
> gib...@wsu.edu (Gibney, Dave) wrote:
> 
> >Mostly Mod-3s, some smaller and mostly special uses. Enough Mod-9 and
> Mod-27 to do Serverpac.
> 
> Given that my netbook has a 320 GB drive, most notebook solid state drives
> are over 100 GB, the standard storage for a tablet seems to be
> 32 GB and all of the drives attached to my desk top are at least 1 terabyte,
> shouldn't EAV devices be gaining more prominence?  I find mod 9 and mod
> 27 devices laughably small in the current environment.
> Even EAV devices may become small compared to what is available in other
> environments.
> 
> Clark Morris
> >
> >> -Original Message-
> >> From: IBM Mainframe Discussion List [mailto:IBM-
> m...@listserv.ua.edu]
> >> On Behalf Of John Eells
> >> Sent: Tuesday, June 28, 2016 9:19 AM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Minimum Volume Sizes in the Wild
> >>
> >> What is the *smallest* volume size everyone sees in general use?
> >>
> >> For example, will we create any problems if we assume that "everyone"
> >> has or can define at least a 3390-9 size volume these days?  What if
> >> we chose 3390-27?
> >>
> >> --
> >> John Eells
> >> IBM Poughkeepsie
> >> 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
> >
> >--
> >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: Minimum Volume Sizes in the Wild

[Mark Zelden]

On Tue, 28 Jun 2016 12:19:28 -0400, John Eells  wrote:

>What is the *smallest* volume size everyone sees in general use?
>
>For example, will we create any problems if we assume that "everyone"
>has or can define at least a 3390-9 size volume these days?  What if we
>chose 3390-27?
>

I know if you assumed 3390-27 was available, it would be a problem for some, 
shops I know of.  3390-9 would have been a problem a few years ago for
some of those shops, but I'm pretty sure everyone has 3390-9 available now.   

Best regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Minimum Volume Sizes in the Wild

[Clark Morris]

[Default] On 28 Jun 2016 11:31:30 -0700, in bit.listserv.ibm-main
gib...@wsu.edu (Gibney, Dave) wrote:

>Mostly Mod-3s, some smaller and mostly special uses. Enough Mod-9 and Mod-27 
>to do Serverpac.

Given that my netbook has a 320 GB drive, most notebook solid state
drives are over 100 GB, the standard storage for a tablet seems to be
32 GB and all of the drives attached to my desk top are at least 1
terabyte, shouldn't EAV devices be gaining more prominence?  I find
mod 9 and mod 27 devices laughably small in the current environment.
Even EAV devices may become small compared to what is available in
other environments.

Clark Morris
>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of John Eells
>> Sent: Tuesday, June 28, 2016 9:19 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Minimum Volume Sizes in the Wild
>> 
>> What is the *smallest* volume size everyone sees in general use?
>> 
>> For example, will we create any problems if we assume that "everyone"
>> has or can define at least a 3390-9 size volume these days?  What if we chose
>> 3390-27?
>> 
>> --
>> John Eells
>> IBM Poughkeepsie
>> 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
>
>--
>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: Minimum Volume Sizes in the Wild

[Lester, Bob]

We have Mod9's and Mod54's only.  We had INFOPAC on Mod54s - huge 
vtoc/vtocix/vvds!  

BobL

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Tuesday, June 28, 2016 3:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Minimum Volume Sizes in the Wild [ EXTERNAL ]

Yep.  100 for JES2 checkpoints.  500+ for catalog volumes.  Some mod 3s for ML1 
and Mobius datasets due to large number of small datasets.
Mod 9s for most volumes.  Storage groups are 1TB+ so new space is Mod 27s (due 
to IPL volumes).  z/OS 2.2 installer wants Mod 40s, don't have uncarved space.  
So next purchase I assume we will do Mod 60s for EAV and leave space to expand.

SYS  NUM  FRE CAPACITY
MOD VOLS SPC   GB
  0016   90  00,000.128
0001  0020   00  00,002.000
0002  0005   81  00,000.945
0010  0008   91  00,007.568
0014  0001   39  00,001.416
0015  0027   84  00,038.367
0030  0227   36  00,644.226
0090  2315   29  19,709.910
0294  0346   27  09,634.024
  2965   28  30,038.584


On Tue, Jun 28, 2016 at 11:23 AM, Richards, Robert B.
 wrote:
> Custom volumes at 100 cylinders and at 1113 cylinders
>
> I would hope your second statement is true, but there are always 
> outliers! :-)
>
> Bob
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of John Eells
> Sent: Tuesday, June 28, 2016 12:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Minimum Volume Sizes in the Wild
>
> What is the *smallest* volume size everyone sees in general use?
>
> For example, will we create any problems if we assume that "everyone"
> has or can define at least a 3390-9 size volume these days?  What if we chose 
> 3390-27?
>
> --
> John Eells
> IBM Poughkeepsie
> 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
>
> --
> 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

This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies. 
OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or 
disclose the content of all email communications.


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

Re: Minimum Volume Sizes in the Wild

[Mike Schwab]

Yep.  100 for JES2 checkpoints.  500+ for catalog volumes.  Some mod
3s for ML1 and Mobius datasets due to large number of small datasets.
Mod 9s for most volumes.  Storage groups are 1TB+ so new space is Mod
27s (due to IPL volumes).  z/OS 2.2 installer wants Mod 40s, don't
have uncarved space.  So next purchase I assume we will do Mod 60s for
EAV and leave space to expand.

SYS  NUM  FRE CAPACITY
MOD VOLS SPC   GB
  0016   90  00,000.128
0001  0020   00  00,002.000
0002  0005   81  00,000.945
0010  0008   91  00,007.568
0014  0001   39  00,001.416
0015  0027   84  00,038.367
0030  0227   36  00,644.226
0090  2315   29  19,709.910
0294  0346   27  09,634.024
  2965   28  30,038.584


On Tue, Jun 28, 2016 at 11:23 AM, Richards, Robert B.
 wrote:
> Custom volumes at 100 cylinders and at 1113 cylinders
>
> I would hope your second statement is true, but there are always outliers! :-)
>
> Bob
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of John Eells
> Sent: Tuesday, June 28, 2016 12:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Minimum Volume Sizes in the Wild
>
> What is the *smallest* volume size everyone sees in general use?
>
> For example, will we create any problems if we assume that "everyone"
> has or can define at least a 3390-9 size volume these days?  What if we chose 
> 3390-27?
>
> --
> John Eells
> IBM Poughkeepsie
> 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
>
> --
> 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: Verify record cound against the file trailer [by SORT?]

[Sri h Kolusu]

Peter,

It is quite simple to verify the variable length. You just need to use UFF 
( Unsigned free format ) instead of ZD which will automatically format the 
variable value by ignoring any thing other than a numeric and pad it with 
zeros.

Example :

//SYSINDD * 
  OPTION COPY 
  INREC IFTHEN=(WHEN=INIT, 
   BUILD=(1,4,   $ RDW 
  SEQNUM,11,ZD,  $ RECORD NUMBER 
  005,15)),  $ INDICATOR+COUNT 
  IFTHEN=(WHEN=(16,4,CH,EQ,C'0999'), $ IF TRL  RECORD 
   OVERLAY=(5:5,11,ZD,SUB,+2,M11,LENGTH=11)) $ SUBTRACT 2 
 
  OUTFIL FNAMES=SORTOUT,NULLOFL=RC4, 
  INCLUDE=(16,4,CH,EQ,X'0999',AND,$ TRL RECORD 
   (05,11,UFF,EQ,20,11,UFF))  $ IS COUNT=TRL COUNT? 
//* 


Thanks,
Kolusu
DFSORT Development
IBM Corporation



From:   "Farley, Peter x23353" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   06/28/2016 01:00 PM
Subject:Re: Verify record cound against the file trailer [by 
SORT?]
Sent by:IBM Mainframe Discussion List 



Thanks again Sri, your new version also worked as long as I changed the 
OUTFIL DD name.

Another colleague came to me with this one today.  How could we handle 
variable-length count data in a trailer?  For example (RECFM=VB file):

,This is a header
0100,data record 1
0100,data record 2
Etc.
0100,data record 21
0999,21

The last record is a trailer with variable-length data record count. 
Maximum count field length is 11.

TIA for any suggestions you can offer.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Sri h Kolusu
Sent: Monday, June 27, 2016 8:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Verify record cound against the file trailer [by SORT?]

Peter,

Your control cards looks good. I cannot comment on syncsort's NULLOFL 
behavior. I think Alan had already pointed the obvious.  So you control 
cards should work as expected with that minor tweak.

I believe you just need to set the return code if the counts do NOT match 
and there is no point in making another copy of the dataset. So why not 
copy only the relevant portions that we need. Some thing like this 

//SYSINDD * 
  OPTION COPY 
  INREC IFTHEN=(WHEN=INIT, 
   BUILD=(1,4,   $ RDW 
  005,01,$ INDICATOR 
  SEQNUM,11,ZD,  $ RECORD NUMBER 
  145,11)),  $ RECORD COUNT 
  IFTHEN=(WHEN=(5,1,CH,EQ,X'FF'),$ IF TRL  RECORD 
   OVERLAY=(6:6,11,ZD,SUB,+2,M11,LENGTH=11)) $ SUBTRACT 2 
 
  OUTFIL FNAMES=SORTOUT,NULLOFL=RC4, 
  INCLUDE=(5,1,CH,EQ,X'FF',AND,  $ TRL RECORD 
   (06,11,ZD,EQ,17,11,ZD))   $ IS COUNT=TRL COUNT? 
//*


Further if you have any questions please let me know

Thanks,
Kolusu
DFSORT Development
IBM Corporation



From:   "Farley, Peter x23353" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   06/27/2016 04:03 PM
Subject:Re: Verify record cound against the file trailer [by 
SORT?]
Sent by:IBM Mainframe Discussion List 



Hi Sri,

I am a colleague of Victor's, and the initial problem was not stated quite 

correctly.  The input file is RECFM=VB, and the trailer record is 
identified by X'FF' in the first data position.  The record count to be 
checked in the trailer record is at positions 145-155 (11 digits, ZD). The 

count in the trailer record does not include either the header record 
(X'00' in the first position) nor the trailer record, so the count in the 
trailer record should be the actual record count minus 2.  The desired 
result is to check the trailer count versus the actual data record count 
and set RC=4  if they do not agree.

Unfortunately we do not actually have access to DFSORT any more, only 
Syncsort.  May I ask you to please verify for me that if we were using 
DFSORT that the control cards below would do what we wish?  If so then I 
can go to our Systems Programmers to open a ticket with Syncsort for 
assistance in verifying the operation of NULLOFL=RC4 in their product.

When I use these control cards with Syncsort, the output file is null (has 

no records) but Syncsort is not setting RC=4, so I will go to them for 
support if the control cards I am using should give RC=4.

  OPTION COPY 
* ADD SEQNUM BETWEEN RDW AND DATA. 
  INREC IFTHEN=(WHEN=INIT,BUILD=(1,4,5:SEQNUM,11,ZD,16:5)),
* USE SEQNUM-2 TO PUT COUNT OF DATA RECORDS IN  POS 20 OF 
* LAST RECORD (IDENTIFIED BY X'FF'). 
  IFTHEN=(WHEN=(16,1,BI,EQ,X'FF'), 
 OVERLAY=(020:5,11,ZD,SUB,+2,M11,LENGTH=11)) 
  OUTFIL NULLOFL=RC4, 
  INCLUDE=(016,1,BI,EQ,X'FF',AND, 
   (160,11,ZD,EQ,20,11,ZD)), 
 BUILD=(1,4,5:5) 

Thank you for your generous and expert assistance on this forum.

Re: Verify record cound against the file trailer [by SORT?]

[Farley, Peter x23353]

Thanks again Sri, your new version also worked as long as I changed the OUTFIL 
DD name.

Another colleague came to me with this one today.  How could we handle 
variable-length count data in a trailer?  For example (RECFM=VB file):

,This is a header
0100,data record 1
0100,data record 2
Etc.
0100,data record 21
0999,21

The last record is a trailer with variable-length data record count.  Maximum 
count field length is 11.

TIA for any suggestions you can offer.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sri h Kolusu
Sent: Monday, June 27, 2016 8:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Verify record cound against the file trailer [by SORT?]

Peter,

Your control cards looks good. I cannot comment on syncsort's NULLOFL 
behavior. I think Alan had already pointed the obvious.  So you control 
cards should work as expected with that minor tweak.

I believe you just need to set the return code if the counts do NOT match 
and there is no point in making another copy of the dataset. So why not 
copy only the relevant portions that we need. Some thing like this 

//SYSINDD * 
  OPTION COPY 
  INREC IFTHEN=(WHEN=INIT, 
   BUILD=(1,4,   $ RDW 
  005,01,$ INDICATOR 
  SEQNUM,11,ZD,  $ RECORD NUMBER 
  145,11)),  $ RECORD COUNT 
  IFTHEN=(WHEN=(5,1,CH,EQ,X'FF'),$ IF TRL  RECORD 
   OVERLAY=(6:6,11,ZD,SUB,+2,M11,LENGTH=11)) $ SUBTRACT 2 
 
  OUTFIL FNAMES=SORTOUT,NULLOFL=RC4,  
  INCLUDE=(5,1,CH,EQ,X'FF',AND,  $ TRL RECORD 
   (06,11,ZD,EQ,17,11,ZD))   $ IS COUNT=TRL COUNT? 
//*


Further if you have any questions please let me know

Thanks,
Kolusu
DFSORT Development
IBM Corporation



From:   "Farley, Peter x23353" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   06/27/2016 04:03 PM
Subject:Re: Verify record cound against the file trailer [by 
SORT?]
Sent by:IBM Mainframe Discussion List 



Hi Sri,

I am a colleague of Victor's, and the initial problem was not stated quite 
correctly.  The input file is RECFM=VB, and the trailer record is 
identified by X'FF' in the first data position.  The record count to be 
checked in the trailer record is at positions 145-155 (11 digits, ZD). The 
count in the trailer record does not include either the header record 
(X'00' in the first position) nor the trailer record, so the count in the 
trailer record should be the actual record count minus 2.  The desired 
result is to check the trailer count versus the actual data record count 
and set RC=4  if they do not agree.

Unfortunately we do not actually have access to DFSORT any more, only 
Syncsort.  May I ask you to please verify for me that if we were using 
DFSORT that the control cards below would do what we wish?  If so then I 
can go to our Systems Programmers to open a ticket with Syncsort for 
assistance in verifying the operation of NULLOFL=RC4 in their product.

When I use these control cards with Syncsort, the output file is null (has 
no records) but Syncsort is not setting RC=4, so I will go to them for 
support if the control cards I am using should give RC=4.

  OPTION COPY 
* ADD SEQNUM BETWEEN RDW AND DATA. 
  INREC IFTHEN=(WHEN=INIT,BUILD=(1,4,5:SEQNUM,11,ZD,16:5)),
* USE SEQNUM-2 TO PUT COUNT OF DATA RECORDS IN  POS 20 OF 
* LAST RECORD (IDENTIFIED BY X'FF'). 
  IFTHEN=(WHEN=(16,1,BI,EQ,X'FF'), 
 OVERLAY=(020:5,11,ZD,SUB,+2,M11,LENGTH=11)) 
  OUTFIL NULLOFL=RC4, 
  INCLUDE=(016,1,BI,EQ,X'FF',AND, 
   (160,11,ZD,EQ,20,11,ZD)), 
 BUILD=(1,4,5:5) 

Thank you for your generous and expert assistance on this forum.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Sri h Kolusu
Sent: Monday, June 27, 2016 3:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Verify record cound against the file trailer [by SORT?]

Victor Gil,

It is quite simple to verify the number of records and validate it against 

the trailer record and if the record count match the return code is 0 and 
if the count is off then the return code is set to 4.

I assumed that the trailer record is not counted as part of the record 
count. If it is indeed counted then simply remove the ",START=0" on the 
INREC statement.

Use the following JCL

//STEP0100 EXEC PGM=SORT 
//SYSOUT   DD SYSOUT=* 
//SORTIN   DD * 
A 
B 
C 
D 
RECS=5 
//SORTOUT  DD SYSOUT=* 
//SYSINDD * 
  OPTION COPY 
  INREC OVERLAY=(81:SEQNUM,5,ZD,START=0) 

  OUTFIL NULLOFL=RC4, 
  INCLUDE=(1,5,CH,EQ,C'RECS=',AND, 
   (06,5,ZD,EQ,81,5,ZD)) 
//* 

The above job will end with RC=4 as there are only 4 records but the 
trailer says 5 records.

Further if you have any questions please let me know

--

This message and any 

Capturing TSO TEST output

[Joseph Reichman]

Hi

Would anyone know if you can capture TSO TEST
Output into clist variables using SYSOUTTRAP
And SYSOUTLINE

Thanks 

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

Re: Chown query

[Paul Gilmartin]

On Tue, 28 Jun 2016 23:41:34 +0530, zos reader wrote:

>Thanks All, it worked.
>
Protip:  "chmod g+s groupname ." on the parent directory will cause files
created under it to inherit its group name.  (Maybe not for NFS.)

I would not use "chmod -R g+s groupname .", but
 "chmod g+s groupname . */. */*/. [...]" should be OK.

(Maybe not f

>On Tue, Jun 28, 2016 at 11:04 PM, Jack J. Woehr wrote:
>
>> Nims,Alva John (Al) wrote:
>>
>>>  From "man chown"
>>>
>> There's also the "chgrp" command in Unix to CHange GRouP

-- gil

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

Re: ZOS 2.2 Install - Alias to Catalog

[John Eells]

Dazzo, Matt wrote:

Software upgrade, the previous install was not used as a model.


Software Upgrade is really intended to be used only when you will keep 
things on the same relative target volumes.  That is, the same data sets 
that are on the first volume on your existing system will still be on 
the first volume built by ServerPac, and the same is true for subsequent 
volumes in the target volume set.  It is also mostly intended for use 
with indirect cataloging, though I will admit the documentation could be 
clearer about that.


As it says on the panel where you select SU vs. FSR:

"Software Upgrade installs only the SMP/E-maintained libraries,
SMP/E zones, and CustomPac sample data sets. Operational data sets,
including system control files (like LOGREC and VTAMLST), a security
system database, and a master catalog must already exist. These
existing operational data sets must be updated as required for new
products and product changes before the first IPL."

SU will generate a job to update your existing master catalog to reflect 
the placement of the data sets in your order.  If they are not in the 
same relative places as the ones you are IPLed from, havoc might (well, 
probably will) ensue either quickly or at the next (attempted) IPL.  The 
chances of them winding up on the same relative volumes are a lot less 
than 100% unless both the old and new volumes are so large that all the 
data sets for each order fit on one volume.


As you did not model after the prior installation, where things will 
wind up depends on order content, volume size, and any changes to data 
set size in the new order vs. the old one.


If you still have the old ServerPac order's data sets around, you can 
probably go into the dialog and save the configuration for that older 
order.  Then, select it for merge when you create the work configuration 
for the new order.  That will carry forward all the stuff you did the 
last time for anything that existed in the old order, which is generally 
less work overall.  If everything fits on the "same" volumes, the SU 
path will create a job that basically only adds new entries to your 
master catalog, which ought to be harmless.


You can also fool Mother Nature by creating a temporary catalog, but 
that will still leave you the task of reconciling catalog entries with 
actual data set placement later.


HTH...

--
John Eells
IBM Poughkeepsie
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

FW: Where is format of Job ID documented?

[Barry Merrill]

One addition for the archives for this thread:

 SMF 6 records written by PRINTWAY/INFOPRINT BASIC Mode contain
JCTJOBID='PSnn'.

 (which could be confused with type 6 records written by PSF, which contain
PSFn).

Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694

 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Barry Merrill
Sent: Wednesday, June 15, 2016 3:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where is format of Job ID documented?

NO, but MXG has discovered these possibilities:


/* THIS ROUTINE EXPECTS JCTJOBID AND JOB AS 8-BYTE CHARACTERS, */
 /* AND SUBSYS AS A 4-BYTE CHARACTER AS INPUT.  */

 /* JCTJOBID OF ONE LETTER AND 7 DIGITS EXIST, BUT THE MAXIMUM  */
 /* JESNR IS 99 BECAUSE THE 1ST WHEN SEVEN IS ALWAYS ZERO.  */

 /* IT CREATES THE 4-BYTE CHARACTER TYPETASK AND NUMERIC JESNR  */
 /* IT IS %INCLUDE-D AFTER JCTJOBID AND SUBSYS EXIST.   */

 TYPETASK='';
 JESNR=.;
 IF SUBSYS=''  THEN SUBSYS=''; /*EARLY ASIDS,TMNT */
 IF JCTJOBID=JOB OR (JCTJOBID LE ' ' AND SUBSYS='STC')
 OR (JCTJOBID EQ 'MSTR' AND SUBSYS='SMS') THEN DO;
   JESNR=.;
   TYPETASK='STC';
 END;
 ELSE DO;
   IF INPUT(SUBSTR(JCTJOBID,2,7),?? 7.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,2,7),?? 7.);
 TYPETASK=SUBSTR(JCTJOBID,1,1);
   END;
   ELSE IF INPUT(SUBSTR(JCTJOBID,3,6),?? 6.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,3,6),?? 6.);
 TYPETASK=SUBSTR(JCTJOBID,1,2);
   END;
   ELSE IF INPUT(SUBSTR(JCTJOBID,4,5),?? 5.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,4,5),?? 5.);
 TYPETASK=SUBSTR(JCTJOBID,1,3);
   END;
   ELSE IF INPUT(SUBSTR(JCTJOBID,5,4),?? 4.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,5,4),?? 4.);
 TYPETASK=SUBSTR(JCTJOBID,1,4);
   END;
   IF SUBSYS='TCP ' THEN TYPETASK='TCP ';
   ELSE IF SUBSYS='PSF ' THEN TYPETASK='PSF ';
   ELSE IF SUBSYS='VPS ' THEN TYPETASK='VPS ';
   ELSE IF TYPETASK=:'J' THEN DO;
 IF  SUBSYS='TSO ' THEN TYPETASK='TSU ';
 ELSE IF SUBSYS='JES2' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='JES3' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='STC ' THEN TYPETASK='STC ';
 ELSE IF SUBSYS='OMVS' THEN TYPETASK='OMVS';
 ELSE   TYPETASK='JOB ';
   END;
   ELSE IF TYPETASK=:'O' OR SUBSYS='OMVS' THEN TYPETASK='OMVS';
   ELSE IF TYPETASK=:'G' THEN TYPETASK='JOBG';
   ELSE IF TYPETASK=:'S' THEN TYPETASK='STC ';
   ELSE IF TYPETASK=:'A' THEN TYPETASK=SUBSYS;/*ASCH-OR-OMVS:CH16.150*/
   ELSE IF TYPETASK=:'T' THEN TYPETASK='TSU ';
   ELSE IF TYPETASK=:'I' AND SUBSYS='STC' THEN TYPETASK='STC  ';
   ELSE DO;
 IF  SUBSYS='STC ' THEN TYPETASK='STC ';
 ELSE IF SUBSYS='TSO ' THEN TYPETASK='TSU ';
 ELSE IF SUBSYS='JES2' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='JES3' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='STC ' THEN TYPETASK='STC ';
 ELSE IF SUBSYS='OMVS' THEN TYPETASK='OMVS';
 ELSE DO;
   IF PRODUCT='' THEN PRODUCT='';;
   IF SUBTYPE=.  THEN SUBTYPE=.;
   IF PRODUCT='PERFMON ' AND SUBTYPE=3 THEN DO;
 TYPETASK='STC';
 SUBSYS='PERFMON';
   END;
 END;
   END;
   IF TYPETASK=' ' THEN DO;
 BADVJESN+1;
 IF BADVJESN LE 2 THEN
   PUT '*** WARNING - TYPETASK NOT DECODED: ' /  +10
   _N_= SYSTEM= ID= SUBTYPE= JOB=
   JCTJOBID= SUBSYS= TYPETASK= JESNR= ;
   END;
   
 END;
  /* END OF MEMBER VGETJESN - GET JESNR AND TYPETASK FROM JCTJOBID */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Wednesday, June 15, 2016 3:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Where is format of Job ID documented?

Yeah, I know, JOBn or Tnnn.

Is there a formal description somewhere? Where?

Charles 

--
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: Minimum Volume Sizes in the Wild

[Porowski, Ken]

Primarily -3 and -9, nothing larger, a few smaller @ 503 CYLs

>

CIT | Ken Porowski | VP Mainframe Engineering | Information Technology | +1 973 
740 5459 (tel) | ken.porow...@cit.com




This email message and any accompanying materials may contain proprietary, 
privileged and confidential information of CIT Group Inc. or its subsidiaries 
or affiliates (collectively, “CIT”), and are intended solely for the 
recipient(s) named above.  If you are not the intended recipient of this 
communication, any use, disclosure, printing, copying or distribution, or 
reliance on the contents, of this communication is strictly prohibited.  CIT 
disclaims any liability for the review, retransmission, dissemination or other 
use of, or the taking of any action in reliance upon, this communication by 
persons other than the intended recipient(s).  If you have received this 
communication in error, please reply to the sender advising of the error in 
transmission, and immediately delete and destroy the communication and any 
accompanying materials.  To the extent permitted by applicable law, CIT and 
others may inspect, review, monitor, analyze, copy, record and retain any 
communications sent from or received at this email address.


-Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of John Eells
> Sent: Tuesday, June 28, 2016 9:19 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Minimum Volume Sizes in the Wild
>
> What is the *smallest* volume size everyone sees in general use?
>
> For example, will we create any problems if we assume that "everyone"
> has or can define at least a 3390-9 size volume these days?  What if
> we chose 3390-27?
>
> --
> John Eells
> IBM Poughkeepsie
> 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

--
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: Minimum Volume Sizes in the Wild

[Gibney, Dave]

Mostly Mod-3s, some smaller and mostly special uses. Enough Mod-9 and Mod-27 to 
do Serverpac.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of John Eells
> Sent: Tuesday, June 28, 2016 9:19 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Minimum Volume Sizes in the Wild
> 
> What is the *smallest* volume size everyone sees in general use?
> 
> For example, will we create any problems if we assume that "everyone"
> has or can define at least a 3390-9 size volume these days?  What if we chose
> 3390-27?
> 
> --
> John Eells
> IBM Poughkeepsie
> 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

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

Re: Chown query

[zos reader]

Thanks All, it worked.

Have a good day.

Samat

On Tue, Jun 28, 2016 at 11:04 PM, Jack J. Woehr  wrote:

> Nims,Alva John (Al) wrote:
>
>>  From "man chown"
>>
>>
> There's also the "chgrp" command in Unix to CHange GRouP
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the
> universe
> www.softwoehr.com # with a fine understanding of human fallibility. -
> Carl Sagan
>
>
> --
> 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: ZOS 2.2 Install - Alias to Catalog

[Dazzo, Matt]

Software upgrade, the previous install was not used as a model.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Tuesday, June 28, 2016 12:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ZOS 2.2 Install - Alias to Catalog

Are you using the Full System Replacement or Software Upgrade installation 
path?  If the latter, did you use your prior saved configuration to model the 
new one after?

Dazzo, Matt wrote:
> I am working on a software upgrade install of zos 2.2 and have a question 
> about what catalog to use in the 'ALIAS TO CATALOG' cpp install panel.  After 
> the install is complete I'd like to continue to us my current master catalog 
> for zos 2.2. So do I create a new temporary user catalog as the zos 2.2 mcat 
> and plug that name in that panel entry or do I put my current master cat name 
> in the panel entry? Below is a snip it of the panel.
>
> Thanks Matt
>
>
> S  AliasSTA Target System Catalog Data Set Name   Type
> -   ---   
> AOP  CATALOG.Z22MCAT  
>  MCAT
> ASM   M  CATALOG.Z22MCAT  
>  MCAT

--
John Eells
IBM Poughkeepsie
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

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

Re: EXTERNAL: Minimum Volume Sizes in the Wild

[Jerry Whitteridge]

The answer to that is what I call IBM Standard Answer #2 - It depends !

In our shop we still have some uses of smaller than Mod 9 but I'd say as a 
general rule our smallest "Standard Volume;" would be a Mod 9.  To create new 
"smaller than Mod 9" would be an effort.

Jerry Whitteridge
Manager Mainframe Systems & Storage
Albertsons - Safeway Inc.
925 738 9443
Corporate Tieline - 89443

If you feel in control
you just aren't going fast enough.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Tuesday, June 28, 2016 9:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Minimum Volume Sizes in the Wild

What is the *smallest* volume size everyone sees in general use?

For example, will we create any problems if we assume that "everyone"
has or can define at least a 3390-9 size volume these days?  What if we
chose 3390-27?

--
John Eells
IBM Poughkeepsie
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

 Warning: All e-mail sent to this address will be received by the corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient. This e-mail may contain proprietary information and is intended only 
for the use of the intended recipient(s). If the reader of this message is not 
the intended recipient(s), you are notified that you have received this message 
in error and that any review, dissemination, distribution or copying of this 
message is strictly prohibited. If you have received this message in error, 
please notify the sender immediately.


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

Re: Chown query

[Jack J. Woehr]

Nims,Alva John (Al) wrote:

 From "man chown"



There's also the "chgrp" command in Unix to CHange GRouP

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: Chown query

[Nims,Alva John (Al)]

From "man chown"

chown [-fhR] owner[:group] pathname ...

put the owner in followed by a ":" then the group name.

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of zos reader
Sent: Tuesday, June 28, 2016 10:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Chown query

Hi,

I created a new directory with 755 permission and the directory should have the 
group and owner as same as the previous one, as like owner should be TSMMEV and 
and group should be TSMHXC.

Old one:-
#file:  /products/test/DB2/db10534/

*#owner: TSMMEV
#group: TSMHXC
user::rwx
group::rwx
other::r-x

Newly created:-

#file:  /products/test/DB2/db105535/

*#owner: OPSME1
#group: OPSYS1
user::rwx
group::r-x
other::r-x

I need to change the Owner as TSMMEV from OPSME1 and group as TSMHXC from 
OPSYS1.

chown -r TSMMEV
I know that chown command will work, but when i tried to find the location of 
owner TSMMEV & group TSMHXC, i not aware of the command.

Can you please help me on this.

Regards,
Samat

--
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: Minimum Volume Sizes in the Wild

[David Purdy]

General use is -9 and -27. -3 are in use but vanishing.  No -54 yet.  

David



On Tuesday, June 28, 2016 John Eells  wrote:
What is the *smallest* volume size everyone sees in general use?

For example, will we create any problems if we assume that "everyone" 
has or can define at least a 3390-9 size volume these days? What if we 
chose 3390-27?

-- 
John Eells
IBM Poughkeepsie
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

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

Re: Minimum Volume Sizes in the Wild

[Styles, Andy (SD EP zPlatform)]

Sadly we still have some 3380's defined. Don't gasp...

  Original Message
From: Chuck Kreiter
Sent: Tuesday, 28 June 2016 17:52
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Minimum Volume Sizes in the Wild


-- This email has reached the Bank via an external source --


We are actively eliminating mod-3's and mod-9's from our environment.  Next 
DASD refresh will only have 27's and 54's.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Tuesday, June 28, 2016 10:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Minimum Volume Sizes in the Wild

What is the *smallest* volume size everyone sees in general use?

For example, will we create any problems if we assume that "everyone"
has or can define at least a 3390-9 size volume these days?  What if we chose 
3390-27?

--
John Eells
IBM Poughkeepsie
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

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


Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. 
Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England 
and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered 
Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. 
Telephone: 03457 801 801. Cheltenham & Gloucester plc. Registered Office: 
Barnett Way, Gloucester GL4 3RL. Registered in England and Wales 2299428. 
Telephone: 0345 603 1637

Lloyds Bank plc, Bank of Scotland plc are authorised by the Prudential 
Regulation Authority and regulated by the Financial Conduct Authority and 
Prudential Regulation Authority.

Cheltenham & Gloucester plc is authorised and regulated by the Financial 
Conduct Authority.

Halifax is a division of Bank of Scotland plc. Cheltenham & Gloucester Savings 
is a division of Lloyds Bank plc.

HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in 
Scotland no. SC218813.

This e-mail (including any attachments) is private and confidential and may 
contain privileged material. If you have received this e-mail in error, please 
notify the sender and delete it (including any attachments) immediately. You 
must not copy, distribute, disclose or use any of the information in it or any 
attachments. Telephone calls may be monitored or recorded.


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

Re: Minimum Volume Sizes in the Wild

[Chuck Kreiter]

We are actively eliminating mod-3's and mod-9's from our environment.  Next 
DASD refresh will only have 27's and 54's.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Tuesday, June 28, 2016 10:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Minimum Volume Sizes in the Wild

What is the *smallest* volume size everyone sees in general use?

For example, will we create any problems if we assume that "everyone" 
has or can define at least a 3390-9 size volume these days?  What if we chose 
3390-27?

--
John Eells
IBM Poughkeepsie
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

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

Re: Minimum Volume Sizes in the Wild

[Lizette Koehler]

I have 3390 mod3s running around still.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Richards, Robert B.
> Sent: Tuesday, June 28, 2016 9:24 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Minimum Volume Sizes in the Wild
> 
> Custom volumes at 100 cylinders and at 1113 cylinders
> 
> I would hope your second statement is true, but there are always outliers! :-)
> 
> Bob
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John Eells
> Sent: Tuesday, June 28, 2016 12:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Minimum Volume Sizes in the Wild
> 
> What is the *smallest* volume size everyone sees in general use?
> 
> For example, will we create any problems if we assume that "everyone"
> has or can define at least a 3390-9 size volume these days?  What if we chose
> 3390-27?
> 
> --
> John Eells
> IBM Poughkeepsie
> 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: Minimum Volume Sizes in the Wild

[Richards, Robert B.]

Custom volumes at 100 cylinders and at 1113 cylinders

I would hope your second statement is true, but there are always outliers! :-)

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Tuesday, June 28, 2016 12:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Minimum Volume Sizes in the Wild

What is the *smallest* volume size everyone sees in general use?

For example, will we create any problems if we assume that "everyone" 
has or can define at least a 3390-9 size volume these days?  What if we chose 
3390-27?

--
John Eells
IBM Poughkeepsie
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

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

Re: ZOS 2.2 Install - Alias to Catalog

[John Eells]

Are you using the Full System Replacement or Software Upgrade 
installation path?  If the latter, did you use your prior saved 
configuration to model the new one after?


Dazzo, Matt wrote:

I am working on a software upgrade install of zos 2.2 and have a question about 
what catalog to use in the 'ALIAS TO CATALOG' cpp install panel.  After the 
install is complete I'd like to continue to us my current master catalog for 
zos 2.2. So do I create a new temporary user catalog as the zos 2.2 mcat and 
plug that name in that panel entry or do I put my current master cat name in 
the panel entry? Below is a snip it of the panel.

Thanks Matt


S  AliasSTA Target System Catalog Data Set Name   Type
-   ---   
AOP  CATALOG.Z22MCAT
   MCAT
ASM   M  CATALOG.Z22MCAT   
MCAT


--
John Eells
IBM Poughkeepsie
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

Minimum Volume Sizes in the Wild

[John Eells]

What is the *smallest* volume size everyone sees in general use?

For example, will we create any problems if we assume that "everyone" 
has or can define at least a 3390-9 size volume these days?  What if we 
chose 3390-27?


--
John Eells
IBM Poughkeepsie
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: ZOS 2.2 Install - Alias to Catalog

[Dazzo, Matt]

New dsn's go down as SSA.SYS1.LINKLIB. Then later get renamed to SYS1.LINKLIB 
on the new res volume without updating the catalog? That would leave the 
indirect catalog entry for SYS1.LINKLIB  pointing to the new res volume at IPL. 
Then there is a cleanup of SSA.* dsn's. Where am I going wrong? Thanks Matt

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of retired mainframer
Sent: Tuesday, June 28, 2016 11:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ZOS 2.2 Install - Alias to Catalog

How do you intend to handle the DSNs that are common when the datasets are not, 
e.g., SYS1.LINKLIB?

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Dazzo, Matt
> Sent: Tuesday, June 28, 2016 8:41 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: ZOS 2.2 Install - Alias to Catalog
> 
> I am working on a software upgrade install of zos 2.2 and have a 
> question
about what
> catalog to use in the 'ALIAS TO CATALOG' cpp install panel.  After the
install is complete
> I'd like to continue to us my current master catalog for zos 2.2. So 
> do I
create a new
> temporary user catalog as the zos 2.2 mcat and plug that name in that
panel entry or do I put
> my current master cat name in the panel entry? Below is a snip it of 
> the
panel.
> 
> Thanks Matt
> 
> 
> S  AliasSTA Target System Catalog Data Set Name   Type
> -   ---   
>AOP  CATALOG.Z22MCAT
MCAT
>ASM   M  CATALOG.Z22MCAT
MCAT

--
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: ZOS 2.2 Install - Alias to Catalog

[retired mainframer]

How do you intend to handle the DSNs that are common when the datasets are
not, e.g., SYS1.LINKLIB?

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Dazzo, Matt
> Sent: Tuesday, June 28, 2016 8:41 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: ZOS 2.2 Install - Alias to Catalog
> 
> I am working on a software upgrade install of zos 2.2 and have a question
about what
> catalog to use in the 'ALIAS TO CATALOG' cpp install panel.  After the
install is complete
> I'd like to continue to us my current master catalog for zos 2.2. So do I
create a new
> temporary user catalog as the zos 2.2 mcat and plug that name in that
panel entry or do I put
> my current master cat name in the panel entry? Below is a snip it of the
panel.
> 
> Thanks Matt
> 
> 
> S  AliasSTA Target System Catalog Data Set Name   Type
> -   ---   
>AOP  CATALOG.Z22MCAT
MCAT
>ASM   M  CATALOG.Z22MCAT
MCAT

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

Re: Netstat (EZANS) for z/OS 2.2

[Mark Regan]

BTW, since EZANS is a TCPIP tool, you should post to the IBMTCP-L mailing
list.

On Tue, Jun 28, 2016 at 11:31 AM Richards, Robert B. <
robert.richa...@opm.gov> wrote:

> Has EZANS been customized for z/OS 2.2?
>
> Bob
>
> --
> 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: Netstat (EZANS) for z/OS 2.2

[Lizette Koehler]

My last conversations with IBM on this is - not supported.  It was a tool
developed by an IBMer that retired and the Communication Server Team preferred
not to continue with it.

So I am thinking NO.

But I have been wrong before.  So who knows.  I am not aware of an alternate at
this time.

You might try posting on the TCPIP list.  They may have more information.  But
back on Sep 2014, a few of us on the TCPIP list tried to get IBM to support it.

>From IBM at that time:

As noted at the bottom of the README.txt for EZANS, the EZANS tool has
not been provided as part of an IBM product.   As such the tool would not
be enhanced nor supported by IBM.  In regards to the z/OS V2R1 release, 
I believe that the tool just invokes the Netstat commands and displays 
the output.  So that feature of the tool should not be affected by the 
current z/OS release.  But support for any new Netstat report options, 
modifiers, and filters would be missing from the tool.



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Richards, Robert B.
> Sent: Tuesday, June 28, 2016 8:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Netstat (EZANS) for z/OS 2.2
> 
> Has EZANS been customized for z/OS 2.2?
> 
> Bob
> 

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

Re: Netstat (EZANS) for z/OS 2.2

[Mark Regan]

I believed they stopped at z/OS v1.13. See
http://www-01.ibm.com/support/docview.wss?uid=swg24029203


On Tue, Jun 28, 2016 at 11:31 AM Richards, Robert B. <
robert.richa...@opm.gov> wrote:

> Has EZANS been customized for z/OS 2.2?
>
> Bob
>
> --
> 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

ZOS 2.2 Install - Alias to Catalog

[Dazzo, Matt]

I am working on a software upgrade install of zos 2.2 and have a question about 
what catalog to use in the 'ALIAS TO CATALOG' cpp install panel.  After the 
install is complete I'd like to continue to us my current master catalog for 
zos 2.2. So do I create a new temporary user catalog as the zos 2.2 mcat and 
plug that name in that panel entry or do I put my current master cat name in 
the panel entry? Below is a snip it of the panel.

Thanks Matt


S  AliasSTA Target System Catalog Data Set Name   Type
-   ---   
   AOP  CATALOG.Z22MCAT 
  MCAT
   ASM   M  CATALOG.Z22MCAT   
MCAT



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

Netstat (EZANS) for z/OS 2.2

[Richards, Robert B.]

Has EZANS been customized for z/OS 2.2?

Bob

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

Re: RACF questio

[Scott Ford]

We pass the RACF command image, i.e.; adduser  name(x)
dfltgrp(x) password(x) and its length


Scott

On Tuesday, June 28, 2016, Lou Losee  wrote:

> Scott,
> What is the function code(s) you are passing in the plist?  Are you using a
> reference to the function code in the plist and not the function code
> itself?
>
> Regards,
> Lou
>
> --
> Artificial Intelligence is no match for Natural Stupidity
>   - Unknown
>
> On Tue, Jun 28, 2016 at 9:50 AM, Scott Ford  > wrote:
>
> > Lou,
> >
> > We are seeing all RACF commands failing using r_admin from a STC, but we
> > invoke an ID with SPECIAL, but I noticed the STC ID has Trusted=no...
> >
> > Scott
> >
> > On Tuesday, June 28, 2016, Lou Losee >
> wrote:
> >
> > > What RACF function are you invoking?
> > >
> > > Regards,
> > > Lou
> > >
> > > --
> > > Artificial Intelligence is no match for Natural Stupidity
> > >   - Unknown
> > >
> > > On Tue, Jun 28, 2016 at 9:35 AM, Scott Ford  
> > > > wrote:
> > >
> > > > All,
> > > >
> > > > I know there's a RACF list, but I have a weird issue.  I am seeing a
> > RACF
> > > > rtncd 8 SAF rtncd 8 and RACF reason code 0 , I have never seen a
> > > 'incorrect
> > > > function code', I have digging through manuals, anyone else seen this
> > one
> > > > or have a hint on how I find out what is causing it ?
> > > >
> > > > My apologies again,
> > > >
> > > > Regards,
> > > >
> > > > Scott
> > > >
> > > >
> --
> > > > 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
>

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

Re: RACF questio

[Lou Losee]

Scott,
What is the function code(s) you are passing in the plist?  Are you using a
reference to the function code in the plist and not the function code
itself?

Regards,
Lou

--
Artificial Intelligence is no match for Natural Stupidity
  - Unknown

On Tue, Jun 28, 2016 at 9:50 AM, Scott Ford  wrote:

> Lou,
>
> We are seeing all RACF commands failing using r_admin from a STC, but we
> invoke an ID with SPECIAL, but I noticed the STC ID has Trusted=no...
>
> Scott
>
> On Tuesday, June 28, 2016, Lou Losee  wrote:
>
> > What RACF function are you invoking?
> >
> > Regards,
> > Lou
> >
> > --
> > Artificial Intelligence is no match for Natural Stupidity
> >   - Unknown
> >
> > On Tue, Jun 28, 2016 at 9:35 AM, Scott Ford  > > wrote:
> >
> > > All,
> > >
> > > I know there's a RACF list, but I have a weird issue.  I am seeing a
> RACF
> > > rtncd 8 SAF rtncd 8 and RACF reason code 0 , I have never seen a
> > 'incorrect
> > > function code', I have digging through manuals, anyone else seen this
> one
> > > or have a hint on how I find out what is causing it ?
> > >
> > > My apologies again,
> > >
> > > Regards,
> > >
> > > Scott
> > >
> > > --
> > > 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: RACF questio

[Scott Ford]

Lou,

We are seeing all RACF commands failing using r_admin from a STC, but we
invoke an ID with SPECIAL, but I noticed the STC ID has Trusted=no...

Scott

On Tuesday, June 28, 2016, Lou Losee  wrote:

> What RACF function are you invoking?
>
> Regards,
> Lou
>
> --
> Artificial Intelligence is no match for Natural Stupidity
>   - Unknown
>
> On Tue, Jun 28, 2016 at 9:35 AM, Scott Ford  > wrote:
>
> > All,
> >
> > I know there's a RACF list, but I have a weird issue.  I am seeing a RACF
> > rtncd 8 SAF rtncd 8 and RACF reason code 0 , I have never seen a
> 'incorrect
> > function code', I have digging through manuals, anyone else seen this one
> > or have a hint on how I find out what is causing it ?
> >
> > My apologies again,
> >
> > Regards,
> >
> > Scott
> >
> > --
> > 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: RACF questio

[Lou Losee]

What RACF function are you invoking?

Regards,
Lou

--
Artificial Intelligence is no match for Natural Stupidity
  - Unknown

On Tue, Jun 28, 2016 at 9:35 AM, Scott Ford  wrote:

> All,
>
> I know there's a RACF list, but I have a weird issue.  I am seeing a RACF
> rtncd 8 SAF rtncd 8 and RACF reason code 0 , I have never seen a 'incorrect
> function code', I have digging through manuals, anyone else seen this one
> or have a hint on how I find out what is causing it ?
>
> My apologies again,
>
> Regards,
>
> Scott
>
> --
> 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: Request for confirmation of an RCF

[Charles Mills]

Thanks. Will do.

I don't see any great need to change the macro itself. It's not the only
macro in MVS where you need to specify something that could possibly be
inferred instead. There is something to be said for consistent defaults,
even when the default for X= could have been made dependent on the value
specified for Y=. Certainly easier to implement.

In answer to your other question (and keeping it on this main thread) yes, I
am pretty confident I want/need COMMON rather than SHARED. I would be happy
to explain the application off-line.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Tuesday, June 28, 2016 6:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Request for confirmation of an RCF

(sorry for omitting the "F" from the subject line previously)

It is confirmed that in order to DETACH  a 64-bit memory object you must
specify AFFINITY=SYSTEM,V64COMMON=YES (otherwise the request fails)

This is certainly not obvious, but it is what it is, and likely cannot be
changed compatibly.

By all means ask that the doc for REQUEST=DETACH make it clear that you must
specify this, and ask that the doc for REQUEST=DETACH,AFFINITY= be fixed.

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

RACF questio

[Scott Ford]

All,

I know there's a RACF list, but I have a weird issue.  I am seeing a RACF
rtncd 8 SAF rtncd 8 and RACF reason code 0 , I have never seen a 'incorrect
function code', I have digging through manuals, anyone else seen this one
or have a hint on how I find out what is causing it ?

My apologies again,

Regards,

Scott

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

Re: Chown query

[Rob Schramm]

Lookup the "find " command with exec.  You should be able to recursively
find and chown all files and directories.

Rob Schramm

Ps a simple Google of "Unix find user chown" will give a variety of answers

On Tue, Jun 28, 2016, 10:01 AM zos reader  wrote:

> Hi,
>
> I created a new directory with 755 permission and the directory should have
> the group and owner as same as the previous one, as like owner should be
> TSMMEV and and group should be TSMHXC.
>
> Old one:-
> #file:  /products/test/DB2/db10534/
>
> *#owner: TSMMEV
> #group: TSMHXC
> user::rwx
> group::rwx
> other::r-x
>
> Newly created:-
>
> #file:  /products/test/DB2/db105535/
>
> *#owner: OPSME1
> #group: OPSYS1
> user::rwx
> group::r-x
> other::r-x
>
> I need to change the Owner as TSMMEV from OPSME1 and group as TSMHXC
> from OPSYS1.
>
> chown -r TSMMEV
> I know that chown command will work, but when i tried to find the location
> of
> owner TSMMEV & group TSMHXC, i not aware of the command.
>
> Can you please help me on this.
>
> Regards,
> Samat
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 

Rob Schramm
The Art of Mainframe, Inc

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

Re: HMC automation

[R.S.]

W dniu 2016-06-28 o 14:49, McElhaney, Robert pisze:

Thanks. My objective is to DECREASE from 407 to 502 during overnight batch 
window, then INCREASE from 502 to 407 for prime time.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Parwez Hamid
Sent: Tuesday, June 28, 2016 6:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: HMC automation

Excellent point. Capacity on Demand options e.g CBU or On/Off Capacity on 
Demand do not allow to DECREASE the permanent capacity setting of the systeem. 
These options are for increasing permanent capacity temporarily only.  
Additional details in the Redbook - IBM System z10 Capacity on Demand - 
SG24-7504-01. Although it says z10 in the title, the content is still valid for 
current z Systems



As it was said, you cannot increase MSU power and decrease "CPU model". 
For example 501 -> 408 conversion is MSU increase, but it is NOT 
available as an option for CoD. You can add processors and/or increase 
processor speed (5xx->6xx).


BTW: What is your goal???

I think you are trying to use wrong tool to achieve your goal.
Do you want to decrease your system during overnight? Voila, use defined 
capacity (softcapping) or just WLM policy. It should be easier and cheaper.


My €0,02

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.

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.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


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

Chown query

[zos reader]

Hi,

I created a new directory with 755 permission and the directory should have
the group and owner as same as the previous one, as like owner should be
TSMMEV and and group should be TSMHXC.

Old one:-
#file:  /products/test/DB2/db10534/

*#owner: TSMMEV
#group: TSMHXC
user::rwx
group::rwx
other::r-x

Newly created:-

#file:  /products/test/DB2/db105535/

*#owner: OPSME1
#group: OPSYS1
user::rwx
group::r-x
other::r-x

I need to change the Owner as TSMMEV from OPSME1 and group as TSMHXC
from OPSYS1.

chown -r TSMMEV
I know that chown command will work, but when i tried to find the location of
owner TSMMEV & group TSMHXC, i not aware of the command.

Can you please help me on this.

Regards,
Samat

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

Re: HMC automation

[Mike Schwab]

IBM capacity is defined as the maximum usage over a 4 hour rolling
period.  If you have a temporary high usage period exceeding your
capacity that isn't too high and not too long, you aren't impacted.

You go too long or too high and the processor starts to slow down so
the total usage does not exceed your 4 hour rolling period.  At that
time you need to limit your usage or upgrade to a high model to meet
the peak 4 hour rolling period.



On Tue, Jun 28, 2016 at 5:34 AM, Geoff Rousell  wrote:
> Robert,
>
> whether this is CBU or OOCoD, you cannot DECREASE the subcapacity model as 
> part of the activation.
> In other words you cannot go from 5xx to 4xx, only from 4xx to 5xx.
>
> Did you actually mean 402 to 507?
>
> Geoff Rousell
> IBM z Systems SE
>
> --
> 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: Request for confirmation of an RCF

[Peter Relson]

(sorry for omitting the "F" from the subject line previously)

It is confirmed that in order to DETACH  a 64-bit memory object you must 
specify
AFFINITY=SYSTEM,V64COMMON=YES 
(otherwise the request fails)

This is certainly not obvious, but it is what it is, and likely cannot be 
changed compatibly.

By all means ask that the doc for REQUEST=DETACH make it clear that you 
must specify this, and ask that the doc for REQUEST=DETACH,AFFINITY= be 
fixed.

Peter Relson
z/OS Core Technology Design


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

Re: HMC automation

[McElhaney, Robert]

Thanks. My objective is to DECREASE from 407 to 502 during overnight batch 
window, then INCREASE from 502 to 407 for prime time.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Parwez Hamid
Sent: Tuesday, June 28, 2016 6:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: HMC automation

Excellent point. Capacity on Demand options e.g CBU or On/Off Capacity on 
Demand do not allow to DECREASE the permanent capacity setting of the systeem. 
These options are for increasing permanent capacity temporarily only.  
Additional details in the Redbook - IBM System z10 Capacity on Demand - 
SG24-7504-01. Although it says z10 in the title, the content is still valid for 
current z Systems

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

Machine Learning for WLM

[Sankaranarayanan, Vignesh]

I came across this paper titled "SELF-LEARNING PREDICTION SYSTEM FOR 
OPTIMISATION OF WORKLOAD MANAGEMENT IN A MAINFRAME OPERATING SYSTEM"

As I was learning the basics of ML, this is the exact application that came to 
mind, being a zOS guy.
I guess you can say I'm curious to find out where this research went and want 
to know if there's anything further progress/research on this I can learn from.

Link: 
https://www.researchgate.net/profile/Martin_Bogdan/publication/220708659_Self-Learning_Prediction_System_for_Optimisation_of_Workload_Management_in_a_Mainframe_Operating_System/links/02e7e528f64afcd9e900.pdf

Any thoughts on why/how this can/can't be done... ?

- Vignesh
Mainframe Infrastructure


MARKSANDSPENCER.COM

Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know 
and then delete it from your system; you should not copy, disclose, or 
distribute its contents to anyone nor act in reliance on this e-mail, as this 
is prohibited and may be unlawful.

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

Re: Request for confirmation of an RC

[Peter Relson]

>> Are you using shared-common? 

>That is the intent. My goal is something "like ECSA, only bigger." Am I 
not
>on the right track?

I think you're not grasping what I asked, but perhaps my terminology is 
not clear. By "shared-common" I meant REQUEST=GETSHARED (to be used 
subsequently with REQUEST=SHAREMEMOBJ). That is quite different from 
REQUEST=GETCOMMON. AFFINITY has a lot of relevance to "shared".

>Is "affected only by" the right phrase? Should it be "require the
>specification of"?

You seem to like the term "require the specification of". It is surely not 
correct here, because that eliminates the case of "or is implicitly asked 
for by letting it default".
I would tend to use "is in effect" rather than "require the specification 
of". But here it is perhaps trying to say something like "applies for ... 
only".
I'm checking with the developer as to what the behavior of AFFINITY is for 
REQUEST=GETCOMMON -- how does "letting it default" differ from specifying 
AFFINITY=SYSTEM,V64COMMON=YES

Peter Relson
z/OS Core Technology Design


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

Re: HMC automation

[Parwez Hamid]

Excellent point. Capacity on Demand options e.g CBU or On/Off Capacity on 
Demand do not allow to DECREASE the permanent capacity setting of the systeem. 
These options are for increasing permanent capacity temporarily only.  
Additional details in the Redbook - IBM System z10 Capacity on Demand - 
SG24-7504-01. Although it says z10 in the title, the content is still valid for 
current z Systems

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

Re: HMC automation

[Geoff Rousell]

Robert,

whether this is CBU or OOCoD, you cannot DECREASE the subcapacity model as part 
of the activation.
In other words you cannot go from 5xx to 4xx, only from 4xx to 5xx. 

Did you actually mean 402 to 507?

Geoff Rousell
IBM z Systems SE

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