Re: TIOT exceeded

[Jake Anderson]

Hi

The TIOT started failing when the JCL started deleted a group of  GDGs.
Using DISP=OLD,DELETE

Jake
On Jun 20, 2016 2:32 AM, "Greg Dyck"  wrote:

> On 6/18/2016 11:03 AM, Jake Anderson wrote:
>
>> Is there a way to know if the DD chain has approached the end or it has
>> approached the end of Chain. Is there a way to tweak the JCL to overcome
>> TIOT exceeded values ?
>>
>
> The TIOT is a fixed sized array of entries, not a chain.  The size is
> defined in PARMLIB member ALLOCxx, with a maximum allowed size of 64K. Only
> when an allocation request fails due to insufficient TIOT space do you know
> it is full.
>
> The primary 'tweak' for SMS managed datasets that can reduce the space
> used for each DD in the TIOT is to reduce the dynamic volume count (DYNVOL)
> specification defined for the data class (
> http://www-01.ibm.com/support/docview.wss?uid=isg3T165).
>
> It is possible to dynamically allocated datasets using the extended TIOT
> (aka, XTIOT).  This requires the application be updated appropriately (
> http://publibz.boulder.ibm.com/zoslib/pdf/oa34634.pdf).  For non-VSAM
> datasets you must also change PARMLIB member DEVSUPxx to specify
> NON_VSAM_XTIOT=YES.  VSAM datasets may be allocated using the XTIOT without
> any changes to PARMLIB.
>
> Greg
>
> --
> 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: TIOT exceeded

[Jake Anderson]

Hi,

The JCL abended even before reaching the Limit of 48k set in our Shop. on
every GDG deletion DD statement, we had 256 generations and it was same for
4 DD statements.

Is there any reason even if the TIOT size is set at 48k But the Job abends
before the DD statement reached 2454 ?

On Mon, Jun 20, 2016 at 12:30 PM, Jake Anderson 
wrote:

> Hi
>
> The TIOT started failing when the JCL started deleted a group of  GDGs.
> Using DISP=OLD,DELETE
>
> Jake
> On Jun 20, 2016 2:32 AM, "Greg Dyck"  wrote:
>
>> On 6/18/2016 11:03 AM, Jake Anderson wrote:
>>
>>> Is there a way to know if the DD chain has approached the end or it has
>>> approached the end of Chain. Is there a way to tweak the JCL to overcome
>>> TIOT exceeded values ?
>>>
>>
>> The TIOT is a fixed sized array of entries, not a chain.  The size is
>> defined in PARMLIB member ALLOCxx, with a maximum allowed size of 64K. Only
>> when an allocation request fails due to insufficient TIOT space do you know
>> it is full.
>>
>> The primary 'tweak' for SMS managed datasets that can reduce the space
>> used for each DD in the TIOT is to reduce the dynamic volume count (DYNVOL)
>> specification defined for the data class (
>> http://www-01.ibm.com/support/docview.wss?uid=isg3T165).
>>
>> It is possible to dynamically allocated datasets using the extended TIOT
>> (aka, XTIOT).  This requires the application be updated appropriately (
>> http://publibz.boulder.ibm.com/zoslib/pdf/oa34634.pdf).  For non-VSAM
>> datasets you must also change PARMLIB member DEVSUPxx to specify
>> NON_VSAM_XTIOT=YES.  VSAM datasets may be allocated using the XTIOT without
>> any changes to PARMLIB.
>>
>> Greg
>>
>> --
>> 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: Where is format of Job ID documented?

[Barry Merrill]

 FWIW, this old change does document the actual existence of JCTJOBID='A':

 Change 08.224  Support for MVS/ESA 4.2 (RMF 4.2.1).
 Jan 28, 1991

   d. The JCTJOBID field from which TYPETASK and JESNR are
  extracted has changed with APPC.  Instead of three
  characters JOB/STC/TSU follwed by the five digit JESNR
  the JCTJOBID will contain an "A" and a seven digit
  number, which MXG stores in TYPETASK and JESNR, but
  the maximum JESNR is 999,999 because the first of the
  seven digits is always a zero.  You should check if
  any reporting programs use TYPETASK for selection, and
  to ensure they are coded robustly so they will not
  fail if TYPETASK='A' is encountered.  The JCTJOBID
  change was not compatibly implemented and changed
  VMAC6,VMAC30,VMAC32,VMAC26J2, and VMAC26J3.  SMF
  records use the fieldname SMFnnJNM for the eight byte
  JCTJOBID field.  This IBM change in that field could
  also affect "banner page" printing code in your SMF
  exits.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Zelden
Sent: Sunday, June 19, 2016 1:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where is format of Job ID documented?

On Sat, 18 Jun 2016 21:00:38 +, Jesse 1 Robinson  
wrote:

>How could I determine if APPC output is clogging my spool? I don't see any at 
>the moment. 

Set PREFIX=* ,  DEST= (null)  and OWNER=* in SDSF.

Issue "H ALL"  and sort on JOBID and look for Annn Issue "O" and sort on 
JOBID and look for Annn

This assumes you don't have any SDSF parms or SDSF SAF security rules 
preventing you from seeing the output.  

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

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

CICS - TS MAIN, AUX question

[Sankaranarayanan, Vignesh]

Hi Folks,

I've been seeing a lot of TS buffer and string waits in some of my CICS 
regions, and also noticed that I can benefit by increasing the CISIZE of TS AUX.
Is there any way for me to calculate the CPU and I/O consumed/wasted on string 
& buffer waits BEFORE implementing this change.
This way, I can say that 'x' system resources was saved by doing this basic 
fine-tuning task.

Happy to look into SMF as well but I reckon CICS SMF is compressed and I 
therefore can't read it manually.

Thanks in advance!

- 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: TIOT exceeded

[Elardus Engelbrecht]

Jake Anderson wrote:

>The JCL abended even before reaching the Limit of 48k set in our Shop. on 
>every GDG deletion DD statement, we had 256 generations and it was same for 4 
>DD statements.

>Is there any reason even if the TIOT size is set at 48k But the Job abends 
>before the DD statement reached 2454 ?

Do you have in your single JCL over 2454 DD statements or one DD with over 2454 
datasets?

If so, just split up your job to delete these GDGs.

Or review your GDG base settings so older generations can be deleted 
automatically.

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: TIOT exceeded

[Jake Anderson]

Hi Elardus,

I am running a IEFBR14, to delete multivolume GDG members by just
specifying the GDG base in the with Four DD statements for four different
GDG bases.

So I could see each GDG base has around 279 GDG members. So I dont think it
reached 2454.


On Mon, Jun 20, 2016 at 3:45 PM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> Jake Anderson wrote:
>
> >The JCL abended even before reaching the Limit of 48k set in our Shop. on
> every GDG deletion DD statement, we had 256 generations and it was same for
> 4 DD statements.
>
> >Is there any reason even if the TIOT size is set at 48k But the Job
> abends before the DD statement reached 2454 ?
>
> Do you have in your single JCL over 2454 DD statements or one DD with over
> 2454 datasets?
>
> If so, just split up your job to delete these GDGs.
>
> Or review your GDG base settings so older generations can be deleted
> automatically.
>
> 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
>

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

OT, funny. A good comic about "Code Quality"

[John McKown]

http://xkcd.com/1695/


-- 
"Pessimism is a admirable quality in an engineer. Pessimistic people check
their work three times, because they're sure that something won't be right.
Optimistic people check once, trust in Solis-de to keep the ship safe, then
blow everyone up."
"I think you're mistaking the word optimistic for inept."
"They've got a similar ring to my ear."

>From "Star Nomad" by Lindsay Buroker:

Maranatha! <><
John McKown

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

Re: Where is format of Job ID documented?

[Mark Zelden]

So I was looking at some of this APPC output getting purged and noticed
that the jobname purged is always ASCHINT with an STC job number.

I displayed one of the jobs in the spool by putting an LL next to the output in
SDSF and the Annn jobid I see in SDSF is displayed as the "TPJOBID" in the 
output.

MZELDEN  0210  $DOS(30087),OUTGRP=ITIMCMD.1.1,LONG  
   
STC30087 0211  $HASP686 OUTPUT(ASCHINT) 154 
   
 154 0211  $HASP686 OUTPUT(ASCHINT)   
OUTGRP=ITIMCMD.1.1,BURST=NO,FCB=,
 154 0211  $HASP686   FLASH=,FORMS=STD,HOLD=(NONE), 
   
 154 0211  $HASP686   
OFFS=(),OUTDISP=HOLD,PRIORITY=144,   
 154 0211  $HASP686   PRMODE=LINE,QUEUE=Y,RECORDS=(6 OF 
6),
 154 0211  $HASP686   ROUTECDE=LOCAL,SECLABEL=, 
   
 154 0211  $HASP686   TPJOBID=A0004237,TPJOBN=ITIMCMD,  
   
 154 0211  $HASP686   
TSOAVAIL=YES,UCS=,USERID=ITIAGNT,
 154 0211  $HASP686   WRITER=,REBUILD=NO,   
   
 154 0211  $HASP686   CRTIME=(2016.170,07:04:21)   


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/



On Mon, 20 Jun 2016 03:52:33 -0500, Barry Merrill  wrote:

> FWIW, this old change does document the actual existence of JCTJOBID='A':
>
> Change 08.224  Support for MVS/ESA 4.2 (RMF 4.2.1).
> Jan 28, 1991
>
>   d. The JCTJOBID field from which TYPETASK and JESNR are
>  extracted has changed with APPC.  Instead of three
>  characters JOB/STC/TSU follwed by the five digit JESNR
>  the JCTJOBID will contain an "A" and a seven digit
>  number, which MXG stores in TYPETASK and JESNR, but
>  the maximum JESNR is 999,999 because the first of the
>  seven digits is always a zero.  You should check if
>  any reporting programs use TYPETASK for selection, and
>  to ensure they are coded robustly so they will not
>  fail if TYPETASK='A' is encountered.  The JCTJOBID
>  change was not compatibly implemented and changed
>  VMAC6,VMAC30,VMAC32,VMAC26J2, and VMAC26J3.  SMF
>  records use the fieldname SMFnnJNM for the eight byte
>  JCTJOBID field.  This IBM change in that field could
>  also affect "banner page" printing code in your SMF
>  exits.
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Mark Zelden
>Sent: Sunday, June 19, 2016 1:47 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Where is format of Job ID documented?
>
>On Sat, 18 Jun 2016 21:00:38 +, Jesse 1 Robinson  
>wrote:
>
>>How could I determine if APPC output is clogging my spool? I don't see any at 
>>the moment. 
>
>Set PREFIX=* ,  DEST= (null)  and OWNER=* in SDSF.
>
>Issue "H ALL"  and sort on JOBID and look for Annn Issue "O" and sort on 
>JOBID and look for Annn
>
>This assumes you don't have any SDSF parms or SDSF SAF security rules 
>preventing you from seeing the output.  
>
>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
>
>--
>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: TIOT exceeded

[Lizette Koehler]

Jake,

This is a more helpful posting for your question.  We can see what your issue 
is with your question about TIOTs.  

Next, what error message do you get in your job when it fails?  Please post the 
entire message and not just the message ID.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jake Anderson
> Sent: Monday, June 20, 2016 1:18 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: TIOT exceeded
> 
> Hi,
> 
> The JCL abended even before reaching the Limit of 48k set in our Shop. on
> every GDG deletion DD statement, we had 256 generations and it was same for
> 4 DD statements.
> 
> Is there any reason even if the TIOT size is set at 48k But the Job abends
> before the DD statement reached 2454 ?
> 
> On Mon, Jun 20, 2016 at 12:30 PM, Jake Anderson 
> wrote:
> 
> > Hi
> >
> > The TIOT started failing when the JCL started deleted a group of  GDGs.
> > Using DISP=OLD,DELETE
> >
> > Jake
> > On Jun 20, 2016 2:32 AM, "Greg Dyck"  wrote:
> >
> >> On 6/18/2016 11:03 AM, Jake Anderson wrote:
> >>
> >>> Is there a way to know if the DD chain has approached the end or it
> >>> has approached the end of Chain. Is there a way to tweak the JCL to
> >>> overcome TIOT exceeded values ?
> >>>
> >>
> >> The TIOT is a fixed sized array of entries, not a chain.  The size is
> >> defined in PARMLIB member ALLOCxx, with a maximum allowed size of
> >> 64K. Only when an allocation request fails due to insufficient TIOT
> >> space do you know it is full.
> >>
> >> The primary 'tweak' for SMS managed datasets that can reduce the
> >> space used for each DD in the TIOT is to reduce the dynamic volume
> >> count (DYNVOL) specification defined for the data class (
> >> http://www-01.ibm.com/support/docview.wss?uid=isg3T165).
> >>
> >> It is possible to dynamically allocated datasets using the extended
> >> TIOT (aka, XTIOT).  This requires the application be updated
> >> appropriately (
> >> http://publibz.boulder.ibm.com/zoslib/pdf/oa34634.pdf).  For non-VSAM
> >> datasets you must also change PARMLIB member DEVSUPxx to specify
> >> NON_VSAM_XTIOT=YES.  VSAM datasets may be allocated using the XTIOT without
> any changes to PARMLIB.
> >>
> >> Greg
> >>

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

Re: owner-ibm-main

[Ron Hawkins]

Maybe you should be asking Symantic...

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Campbell Jay
Sent: Sunday, June 19, 2016 11:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] owner-ibm-main

Am I being SPAMed ?
They're getting annoying.

Supposedly from  owner-ibm-m...@listserv.ua.edu   sometimes with no From:

Text...

X-Brightmail-Tracker:
H4sIA+NgFlrNLMWRWlGSWpSXmKPExsXCdV5DVffPnbRwg4nfTCxev023WPm/mdHi

4qc9jA7MHkfWHmQOYIzisklJzcksSy3St0vgyujZfYGtgKECRDUwMkxgZFjAyLCKUTYswCjY

19XXMSAg2NfdwEgvpVgvs6g4L7VELz2/bBMjyK7bgbE7GNd8dDzEKMDBqMTD27kiLVyINbGs

uDL3EKMkB5OSKO+e7tRwIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8x28DlfOmJFZWpRblw6Sk

OViUxHk/TXweIiSQnliSmp2aWpBaBJOV4eBQkuCdCtIoWJSanlqRlplTgpBm4uAEGc4DNPw8

2PDigsTc4sx0iPwpRkOOfYtvrGXiuPDsAZC8AiKFWPLy81KlxHkzQBoEQBoySvPgZl5iFJUS

5mVkYGAQ4gG6IzezBCL+ilEc6GVhXgVgUAvxZOaVwG15BXQAE9ABmvOSQQ4oSURISTUwcva0

/D49q2btxbqy0iMKH98kP9qzzmHfzxmPhHKc1V81F7rdqv/AZO1p43tbYp1uYnbjwkpZh73Z

811VFB3OHPtx7fqJjKWybfULRV+vkWuXC/jCE6dgcSBo+ZfnHo75U24eKsg+tZ5XKTrzemfX
JZPZC9vm9W99w5r98r2/Vr8d09zHXnVPlFiKMxINtZiLihMBA4pxRz4CAAA=
Date: Sun Jun 19 12:57:16 2016

Jay Campbell
IBM OS Support Section

--
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: TIOT exceeded

[Jake Anderson]

Lizette,

The error message was

IEF240I JOBNAME STEPNAME - TASK I/O TABLE EXCEEDS TIOT LIMIT OF 0048K

I found that the GDG members were created on Multivolume.

On Mon, Jun 20, 2016 at 6:48 PM, Lizette Koehler 
wrote:

> Jake,
>
> This is a more helpful posting for your question.  We can see what your
> issue is with your question about TIOTs.
>
> Next, what error message do you get in your job when it fails?  Please
> post the entire message and not just the message ID.
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Jake Anderson
> > Sent: Monday, June 20, 2016 1:18 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: TIOT exceeded
> >
> > Hi,
> >
> > The JCL abended even before reaching the Limit of 48k set in our Shop. on
> > every GDG deletion DD statement, we had 256 generations and it was same
> for
> > 4 DD statements.
> >
> > Is there any reason even if the TIOT size is set at 48k But the Job
> abends
> > before the DD statement reached 2454 ?
> >
> > On Mon, Jun 20, 2016 at 12:30 PM, Jake Anderson <
> justmainfra...@gmail.com>
> > wrote:
> >
> > > Hi
> > >
> > > The TIOT started failing when the JCL started deleted a group of  GDGs.
> > > Using DISP=OLD,DELETE
> > >
> > > Jake
> > > On Jun 20, 2016 2:32 AM, "Greg Dyck"  wrote:
> > >
> > >> On 6/18/2016 11:03 AM, Jake Anderson wrote:
> > >>
> > >>> Is there a way to know if the DD chain has approached the end or it
> > >>> has approached the end of Chain. Is there a way to tweak the JCL to
> > >>> overcome TIOT exceeded values ?
> > >>>
> > >>
> > >> The TIOT is a fixed sized array of entries, not a chain.  The size is
> > >> defined in PARMLIB member ALLOCxx, with a maximum allowed size of
> > >> 64K. Only when an allocation request fails due to insufficient TIOT
> > >> space do you know it is full.
> > >>
> > >> The primary 'tweak' for SMS managed datasets that can reduce the
> > >> space used for each DD in the TIOT is to reduce the dynamic volume
> > >> count (DYNVOL) specification defined for the data class (
> > >> http://www-01.ibm.com/support/docview.wss?uid=isg3T165).
> > >>
> > >> It is possible to dynamically allocated datasets using the extended
> > >> TIOT (aka, XTIOT).  This requires the application be updated
> > >> appropriately (
> > >> http://publibz.boulder.ibm.com/zoslib/pdf/oa34634.pdf).  For non-VSAM
> > >> datasets you must also change PARMLIB member DEVSUPxx to specify
> > >> NON_VSAM_XTIOT=YES.  VSAM datasets may be allocated using the XTIOT
> without
> > any changes to PARMLIB.
> > >>
> > >> Greg
> > >>
>
> --
> 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: owner-ibm-main

[Campbell Jay]

Correct.  Our very own Messaging Gateway.

Jay Campbell
IBM OS Support Section


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of Ron Hawkins
Sent: Monday, June 20, 2016 9:29 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: owner-ibm-main

Maybe you should be asking Symantic...

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Campbell Jay
Sent: Sunday, June 19, 2016 11:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] owner-ibm-main

Am I being SPAMed ?
They're getting annoying.

Supposedly from  owner-ibm-m...@listserv.ua.edu   sometimes with no From:

Text...

X-Brightmail-Tracker:
H4sIA+NgFlrNLMWRWlGSWpSXmKPExsXCdV5DVffPnbRwg4nfTCxev023WPm/mdHi

4qc9jA7MHkfWHmQOYIzisklJzcksSy3St0vgyujZfYGtgKECRDUwMkxgZFjAyLCKUTYswCjY

19XXMSAg2NfdwEgvpVgvs6g4L7VELz2/bBMjyK7bgbE7GNd8dDzEKMDBqMTD27kiLVyINbGs

uDL3EKMkB5OSKO+e7tRwIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8x28DlfOmJFZWpRblw6Sk

OViUxHk/TXweIiSQnliSmp2aWpBaBJOV4eBQkuCdCtIoWJSanlqRlplTgpBm4uAEGc4DNPw8

2PDigsTc4sx0iPwpRkOOfYtvrGXiuPDsAZC8AiKFWPLy81KlxHkzQBoEQBoySvPgZl5iFJUS

5mVkYGAQ4gG6IzezBCL+ilEc6GVhXgVgUAvxZOaVwG15BXQAE9ABmvOSQQ4oSURISTUwcva0

/D49q2btxbqy0iMKH98kP9qzzmHfzxmPhHKc1V81F7rdqv/AZO1p43tbYp1uYnbjwkpZh73Z

811VFB3OHPtx7fqJjKWybfULRV+vkWuXC/jCE6dgcSBo+ZfnHo75U24eKsg+tZ5XKTrzemfX
JZPZC9vm9W99w5r98r2/Vr8d09zHXnVPlFiKMxINtZiLihMBA4pxRz4CAAA=
Date: Sun Jun 19 12:57:16 2016

Jay Campbell
IBM OS Support Section

--
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: WAIT >1 (Friday type question, a day late)

[Gord Tomlin]

On 2016-06-19 14:15, Stevet wrote:

Try EVENTS. I've not used this for a few years, but I think it does what you 
want. Sorry, but I'm doing electrical work and can't get to manuals right now.


EVENTS will do this, but I don't think that was Charles's question. I 
think he is asking whether anyone has encountered a situation where it 
was actually useful to wait until more than one ECB is posted.


For me, the answer is "no, I haven't." I have plenty of code that waits 
on multiple ECBs using EVENTS, but it always wants to get to work when 
any one of the ECBs is posted.


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

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

Re: CICS - TS MAIN, AUX question

[Rugen, Len]

Look at the TS part of 
https://share.confex.com/share/116/webprogram/Handout/Session8269/SHARE%20Anaheim%20CICS%20Performance%20Tutorial%20-%20Other%20Tuning%20Areas%2002102011.pdf

It's been several years, but I had an installation where TS was heavily used.  
It had used MAIN storage, but as the system grew, it would cause SOS, so it was 
changed to AUX, but not given enough buffers, so it severely impacted 
performance.  

Note the part above that talks about TS uses delayed write to the VSAM file.  
Note also that TS should be TEMPORARY, it's not for long term storage.  

The CICS statistics program can be used to report on TS usage, but I don't 
remember the format.  

I was able to determine that I had S average sessions retaining TS data, each 
session could be contained in B TS buffers, so I allocated (S * B) * 1.5 TS 
buffers.  TS VSAM writes went down by over 90%, but TS was there if there were 
abandoned sessions leaving data.

Net result was I got back to BETTER than TS Main performance, most of the data 
was never written to VSAM, and it used a lot less main storage.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sankaranarayanan, Vignesh
Sent: Monday, June 20, 2016 4:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CICS - TS MAIN, AUX question

Hi Folks,

I've been seeing a lot of TS buffer and string waits in some of my CICS 
regions, and also noticed that I can benefit by increasing the CISIZE of TS AUX.
Is there any way for me to calculate the CPU and I/O consumed/wasted on string 
& buffer waits BEFORE implementing this change.
This way, I can say that 'x' system resources was saved by doing this basic 
fine-tuning task.

Happy to look into SMF as well but I reckon CICS SMF is compressed and I 
therefore can't read it manually.

Thanks in advance!

- 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

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

Did someone say Spiritual Pyrotechnics?

[Adam Dobrin]

You all have been totally missing the Apocalypse.  I want to help you catch
up, because truth be told, you're closer to me than you think.  I have an
archive, but first, I'd like to suggest you read this message... it's about
language, artificial intelligence, and history.  Oh, and *that's religion.*


   - Kurzweil luminates... Zelda too.
   
Sent
   Friday, June 17, 2016Adam Dobrin on Artificial Intelligence Adonai
   (אֲדֹנָי, lit. "My Lords") is the plural form of adon ("lord") along with
   the first-person singular pronoun enclitic.[n 3] As with Elohim, Adonai's
   grammatical form is usually explained as a plural of majesty. In the Hebrew
   Scriptures, it is only used to refer to God. As the pronunciation of the
   Tetragrammaton came to be avoided in the Hellenistic period, Jews began to
   read "Adonai" at its appearances in scripture and […]
   - There archive is there too.

-a
ᐧ

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

Re: TIOT exceeded

[R.S.]

W dniu 2016-06-20 o 10:17, Jake Anderson pisze:

Hi,

The JCL abended even before reaching the Limit of 48k set in our Shop. on
every GDG deletion DD statement, we had 256 generations and it was same for
4 DD statements.

Is there any reason even if the TIOT size is set at 48k But the Job abends
before the DD statement reached 2454 ?


Did you check a DATACLASS for those datasets?
What is DVC? (Dynamic Volume Count)?

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

Re: WAIT >1 (Friday type question, a day late)

[John McKown]

On Sun, Jun 19, 2016 at 11:52 AM, Charles Mills  wrote:

> Oh sure. The basic "wait for one of many." My code waits for an any one of
> an operator command, a timer expiration, or "real work."
>
> My question was does anyone issue a wait with a completion count of more
> than one? "Wake me when two of these five ECBs have been posted"?
>
> Charles
>
>
​That is a good question. I can think of a reason, as you said, to wait for
"1 of n". And I can think of a reason ​to wait for "n of n". I've even
thought of a reason to wait for what I'll call "1+1 of n" (i.e. what until
one specific ECB is posted, plus one of "n" other ECBs). The closest that I
can envision for "2 of n" might be if the "n" are "n" worker threads which
produce "some output" and, for some reason that I can't envision, the
parent needs at least 2 worker products in order to do something else. But
that idea is so vague that it is basically useless. Hum, maybe a case of
"efficiency" in the aforementioned scenario. Suppose that you need "n"
worker threads to produce "product". These thread each take a relatively
"large" amount of time. Your main thread does something with this
"product", but it does it quickly. It would be more efficient to accumulate
"m" (From "Star Nomad" by Lindsay Buroker:

Maranatha! <><
John McKown

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

Re: TIOT exceeded

[David Betten]

I may be mistaken but I don't think Dynamic Volume Count is the real issue
with using up TIOT entries.  What I'd be more concerned about is Volume
Count as if there's a high number like 59, a TIOT entry will be created for
each candidate volume.Dynamic Volume Count is only a factor if Space
Constraint Relief is set to YES and then volumes are dynamically added as
needed up to the DVC value.  When I've set up test environments in the
past, I usually set Volume Count to 1, with Space Constraint Relief set to
YES and a Dynamic Volume Count of something like 16.  This usually works
quite well for me.  This causes my data sets to initially be allocated on a
single volume but have the ability to go multi-volume if needed.

Of course I'm speaking about non-striped data sets here.


Have a nice day,
Dave Betten
z/OS Performance Specialist
Cloud and Systems Performance
IBM Corporation
email:  bet...@us.ibm.com

IBM Mainframe Discussion List  wrote on
06/20/2016 10:03:34 AM:

> From: "R.S." 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 06/20/2016 10:04 AM
> Subject: Re: TIOT exceeded
> Sent by: IBM Mainframe Discussion List 
>
> W dniu 2016-06-20 o 10:17, Jake Anderson pisze:
> > Hi,
> >
> > The JCL abended even before reaching the Limit of 48k set in our Shop.
on
> > every GDG deletion DD statement, we had 256 generations and it was same
for
> > 4 DD statements.
> >
> > Is there any reason even if the TIOT size is set at 48k But the Job
abends
> > before the DD statement reached 2454 ?
> >
> Did you check a DATACLASS for those datasets?
> What is DVC? (Dynamic Volume Count)?
>
> --
> 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 zapisanena
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

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

Re: OT, funny. A good comic about "Code Quality"

[Elardus Engelbrecht]

John McKown wrote:

>http://xkcd.com/1695/

Haha! Good one! ;-D 

John, I remember that you posted this below reply of this on 5 Aug 2009 where 
you replied that APL2 is "better":

>Mark T. Regan, K8MTR
> Subject: Fwd: How To Write Unmaintainable Code
> How To Write Unmaintainable Code Ensure a job for life ;-)
 
> http://freeworld.thc.org/root/phun/unmaintain.html?repost=forPosterity

That website is still Ok and fun to read!


Apparently according to Gary Green and other posters (Bruce Black et al.) you 
could write whole program in ONE line using APL with those characters designed 
for that languange!

Gary Green said on Wed, 23 May 2007 in thread 'Re: Non-Standard Mainframe 
Language?' this:

"I tried APL once, back in 77.  I thought it was the perfect programming 
language.  One could write an entire program on/in one line of code. "

Talking about quality of code! ;-D

Is it Friday today? 

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: AW: Re: Highest address "below the bar"

[Steve Smith]

It's the bar!  Only 4KB thick, a big improvement over what I originally
called* the bar from x'8000' through x''.  That one however, is
now available for certain uses, although I would avoid it for the same
reasons it was originally black-listed.

*In no way is this a claim I have naming rights.

On Fri, Jun 17, 2016 at 12:27 PM, Walt Farrell 
wrote:

> On Fri, 17 Jun 2016 11:21:44 -0400, Jim Mulder  wrote:
>
> >> >>For diagnostic purposes, then 4K page at 7000 is always
> >> >>left invalid in z/OS.
> >> >
> >> >That makes the highest numbered, accessible byte to be at address
> >x'7FFFEFFF'
> >> >
> >> That might be due to a requirement of ANSI C that there always be an
> >address
> >> algebraically greater than that of any accessible object, for loop
> >termination
> >> conditions.
> >
> >  Not likely.  It has been that way since the first release of MVS/XA,
> >circa 1982. That was a time when MVS still ruled with arrogance, and it
> >would takes some doses of marketplace reality changes a few years later
> >before
> >MVS became interested in accommodating C and Unix.
>
> In any case, "ANSI" C didn't exist until (I think) 1989, though the
> standardization effort began in 1983. So the technique is certainly older
> than ANSI C, and not related to it.
>
> --
> Walt
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
sas

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

Re: WAIT >1 (Friday type question, a day late)

[Charles Mills]

@John, thanks, exactly the *sort* of answer I was looking for.

It was just a Friday question, as I said. No real problem here. I just have 
this "why? whatever for" thought every time I look at the WAIT documentation.

> the parent needs at least 2 worker products in order to do something else

Or perhaps at least one "worker product" plus some necessary "output" resource. 
Although then "any 2 of n" would not solve the problem.

Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Monday, June 20, 2016 7:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WAIT >1 (Friday type question, a day late)

On Sun, Jun 19, 2016 at 11:52 AM, Charles Mills  wrote:

> Oh sure. The basic "wait for one of many." My code waits for an any 
> one of an operator command, a timer expiration, or "real work."
>
> My question was does anyone issue a wait with a completion count of 
> more than one? "Wake me when two of these five ECBs have been posted"?
>
> Charles
>
>
​That is a good question. I can think of a reason, as you said, to wait for
"1 of n". And I can think of a reason ​to wait for "n of n". I've even thought 
of a reason to wait for what I'll call "1+1 of n" (i.e. what until one specific 
ECB is posted, plus one of "n" other ECBs). The closest that I can envision for 
"2 of n" might be if the "n" are "n" worker threads which produce "some output" 
and, for some reason that I can't envision, the parent needs at least 2 worker 
products in order to do something else. But that idea is so vague that it is 
basically useless. Hum, maybe a case of "efficiency" in the aforementioned 
scenario. Suppose that you need "n"
worker threads to produce "product". These thread each take a relatively 
"large" amount of time. Your main thread does something with this "product", 
but it does it quickly. It would be more efficient to accumulate "m" (

Re: TIOT exceeded

[David Betten]

Thank you to Alex Brodsky for questioning me offline about this. It
prompted me to do some more reasearch and it appears the opening of my post
("I may be mistaken") was right on. I found this link that describes the
effect of dynamic volume count on TIOT size

http://www-01.ibm.com/support/docview.wss?uid=isg3T165


Have a nice day,
Dave Betten
z/OS Performance Specialist
Cloud and Systems Performance
IBM Corporation
email:  bet...@us.ibm.com
1-720-396-3882

IBM Mainframe Discussion List  wrote on
06/20/2016 10:30:08 AM:

> From: David Betten/Gaithersburg/IBM@IBMUS
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 06/20/2016 10:31 AM
> Subject: Re: TIOT exceeded
> Sent by: IBM Mainframe Discussion List 
>
> I may be mistaken but I don't think Dynamic Volume Count is the real
issue
> with using up TIOT entries.  What I'd be more concerned about is Volume
> Count as if there's a high number like 59, a TIOT entry will be created
for
> each candidate volume.Dynamic Volume Count is only a factor if Space
> Constraint Relief is set to YES and then volumes are dynamically added as
> needed up to the DVC value.  When I've set up test environments in the
> past, I usually set Volume Count to 1, with Space Constraint Relief set
to
> YES and a Dynamic Volume Count of something like 16.  This usually works
> quite well for me.  This causes my data sets to initially be allocated on
a
> single volume but have the ability to go multi-volume if needed.
>
> Of course I'm speaking about non-striped data sets here.
>
>
> Have a nice day,
> Dave Betten
> z/OS Performance Specialist
> Cloud and Systems Performance
> IBM Corporation
> email:  bet...@us.ibm.com
>
> IBM Mainframe Discussion List  wrote on
> 06/20/2016 10:03:34 AM:
>
> > From: "R.S." 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date: 06/20/2016 10:04 AM
> > Subject: Re: TIOT exceeded
> > Sent by: IBM Mainframe Discussion List 
> >
> > W dniu 2016-06-20 o 10:17, Jake Anderson pisze:
> > > Hi,
> > >
> > > The JCL abended even before reaching the Limit of 48k set in our
Shop.
> on
> > > every GDG deletion DD statement, we had 256 generations and it was
same
> for
> > > 4 DD statements.
> > >
> > > Is there any reason even if the TIOT size is set at 48k But the Job
> abends
> > > before the DD statement reached 2454 ?
> > >
> > Did you check a DATACLASS for those datasets?
> > What is DVC? (Dynamic Volume Count)?
> >
> > --
> > 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 zapisanena
> 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
>
> --
> 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: WAIT >1 (Friday type question, a day late)

[Tony Harminc]

On 20 June 2016 at 11:02, Charles Mills  wrote:

> It was just a Friday question, as I said. No real problem here. I just
> have this "why? whatever for" thought every time I look at the WAIT
> documentation.


If you process a lot of trace tables (which IIRC you do), it might be
interesting to scan for WAIT entries with R0 <> 1. (Well, the high bit is
for LONG=YES, so you'd have to filter that out.) This would perhaps tell
you if there is any routine, or at least frequent, use of this kind of WAIT
on a system.

Tony H.

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

DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME

[willie bunter]

Good Day To All,

I would like to recover a dsn which was migrated to ML2.  Because of a mistake 
in the assigning of the management class no back up was taken.

I remember recovering a dsn under the same circumstances.  I remember locating 
the dsn in the HSM.JOURNAL.BACKUP.V000 (found in column 13 in HEX) and the 
volser of the ML2. (which  I found in column 77) 

I browsed the online HSM.JOURNAL (using the first and second HLQ)  however I 
was unable to locate the dsn.  My question is do I need to wait for the CDS 
Journal backup to be run (which will execute tonight at 8 p.m) or is there 
something else I can try?

Thanks.

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

Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME

[Lizette Koehler]

If your first statement is No BACKUP has been taken, then the file is most 
likely lost.

When was the file migrated?

Can you show us the results from a HLIST dsn(/) BOTH 

It will help to know when it was migrated.

CDS Backups and Journals can be performed anytime.  You just have to know what 
kind of performance impact will be felt while it is running


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of willie bunter
> Sent: Monday, June 20, 2016 9:35 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
> 
> Good Day To All,
> 
> I would like to recover a dsn which was migrated to ML2.  Because of a mistake
> in the assigning of the management class no back up was taken.
> 
> I remember recovering a dsn under the same circumstances.  I remember locating
> the dsn in the HSM.JOURNAL.BACKUP.V000 (found in column 13 in HEX) and the
> volser of the ML2. (which  I found in column 77)
> 
> I browsed the online HSM.JOURNAL (using the first and second HLQ)  however I
> was unable to locate the dsn.  My question is do I need to wait for the CDS
> Journal backup to be run (which will execute tonight at 8 p.m) or is there
> something else I can try?
> 
> Thanks.
> 

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

Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME

[Staller, Allan]

Why not just HRECALL the dataset?

Of course, if the migrated copy  is the damaged dataset, and there are no 
backups, you are out of luck.




I would like to recover a dsn which was migrated to ML2.  Because of a mistake 
in the assigning of the management class no back up was taken.

I remember recovering a dsn under the same circumstances.  I remember locating 
the dsn in the HSM.JOURNAL.BACKUP.V000 (found in column 13 in HEX) and the 
volser of the ML2. (which  I found in column 77) 

I browsed the online HSM.JOURNAL (using the first and second HLQ)  however I 
was unable to locate the dsn.  My question is do I need to wait for the CDS 
Journal backup to be run (which will execute tonight at 8 p.m) or is there 
something else I can try?


This email � including attachments � may contain confidential information. If 
you are not the intended recipient, do not copy, distribute or act on it. 
Instead, notify the sender immediately and delete the message.

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

Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME

[retired mainframer]

Why would the absence of a backup have any impact on the ability to recall a 
migrated dataset?

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Monday, June 20, 2016 9:41 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
> 
> If your first statement is No BACKUP has been taken, then the file is most 
> likely lost.

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

Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME

[retired mainframer]

Why are you looking in the JOURNAL?  It contains only "recent" data since the 
last CDS backup.  How long ago was the dataset migrated?  To find the DSN, you 
need to look in the backup copy that covers the time frame when the migration 
occurred.  But if you need to look up anything about the dataset, you really 
should be looking in the MCDS.

Why do you think you need to know the ML2 volume?  ML2 datasets are catalogued 
on MIGRAT2.  Does the DSN show up in 3.4?
What happens if you issue an HRECALL against the DSN?  If the migrated copy is 
valid, that should be all you need.  

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of willie bunter
> Sent: Monday, June 20, 2016 9:35 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
> 
> Good Day To All,
> 
> I would like to recover a dsn which was migrated to ML2.  Because of a 
> mistake in the
> assigning of the management class no back up was taken.
> 
> I remember recovering a dsn under the same circumstances.  I remember 
> locating the dsn in
> the HSM.JOURNAL.BACKUP.V000 (found in column 13 in HEX) and the volser of
> the ML2. (which  I found in column 77)
> 
> I browsed the online HSM.JOURNAL (using the first and second HLQ)  however I 
> was
> unable to locate the dsn.  My question is do I need to wait for the CDS 
> Journal backup to be
> run (which will execute tonight at 8 p.m) or is there something else I can 
> try?

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

Re: Highest address "below the bar

[Tom Marchant]

On Mon, 20 Jun 2016 01:16:42 +, Rob Schramm wrote:

>Any region size in excess of 16m gives you that amount above the line plus
>everything that is available below the line.  REGION=64M is 64M above and
>(assuming you have a 10M below the line YBTLRMV) gives you the 10M below as
>well.  Been that way for as long as I remember. This also assumes there are
>no exits messing with the REGION.

Not quite. From the JCL Reference:


 If your installation does not change the IBM-supplied default limits in the 
IEALIMIT 
or IEFUSI exit routine modules, then specifying various values for the region 
size 
has the following results:

...

A value greater than 16,384K or 16M and less than or equal to 32,768K or 32M -- 
gives the job step all the storage available below 16 megabytes. The resulting 
size 
of the region below 16 megabytes depends on system options and what system 
software is installed. The extended region size is the default value of 32 
megabytes.

A value greater than 32,768K or 32M and less than or equal to 2,096,128K or 
2047M 
-- gives the job step all the storage available below 16 megabytes. The 
resulting 
size of the region below 16 megabytes depends on system options and what system 
software is installed. The extended region size is the specified value. If the 
region 
size specified is not available above 16 megabytes, the job step receives 
whatever 
storage is available above 16 megabytes, up to the requested amount, and the 
resulting size of the region above 16 megabytes depends on system options and 
what system software is installed.


-- 
Tom Marchant

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

Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME

[willie bunter]

Hallo to All,

The dsn was migrated about 2 years ago and for some reason it was deleted today 
(in error).  I am dusting off some old doc and as I had said earlier I am 
checking to see what I did.  Keep you all posted if I stumble on to something.


On Mon, 6/20/16, Lizette Koehler  wrote:

 Subject: Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Monday, June 20, 2016, 12:41 PM
 
 If your first statement
 is No BACKUP has been taken, then the file is most likely
 lost.
 
 When was the file
 migrated?
 
 Can you show us
 the results from a HLIST dsn(/) BOTH 
 
 It will help to know when it was migrated.
 
 CDS Backups and Journals can
 be performed anytime.  You just have to know what kind of
 performance impact will be felt while it is running
 
 
 Lizette
 
 
 > -Original
 Message-
 > From: IBM Mainframe
 Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On
 > Behalf Of willie bunter
 > Sent: Monday, June 20, 2016 9:35 AM
 > To: IBM-MAIN@LISTSERV.UA.EDU
 > Subject: DFHSM QUESTION - RECOVER DSN FROM
 ML2 VOLUME
 > 
 > Good
 Day To All,
 > 
 > I
 would like to recover a dsn which was migrated to ML2. 
 Because of a mistake
 > in the assigning
 of the management class no back up was taken.
 > 
 > I remember
 recovering a dsn under the same circumstances.  I remember
 locating
 > the dsn in the
 HSM.JOURNAL.BACKUP.V000 (found in column 13 in HEX) and
 the
 > volser of the ML2. (which  I found
 in column 77)
 > 
 > I
 browsed the online HSM.JOURNAL (using the first and second
 HLQ)  however I
 > was unable to locate
 the dsn.  My question is do I need to wait for the CDS
 > Journal backup to be run (which will
 execute tonight at 8 p.m) or is there
 >
 something else I can try?
 > 
 > 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: Highest address "below the bar

[Rob Schramm]

Oops.. forgot about the 32m.

Rob Schramm

On Mon, Jun 20, 2016, 1:14 PM Tom Marchant <
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 20 Jun 2016 01:16:42 +, Rob Schramm wrote:
>
> >Any region size in excess of 16m gives you that amount above the line plus
> >everything that is available below the line.  REGION=64M is 64M above and
> >(assuming you have a 10M below the line YBTLRMV) gives you the 10M below
> as
> >well.  Been that way for as long as I remember. This also assumes there
> are
> >no exits messing with the REGION.
>
> Not quite. From the JCL Reference:
>
> 
>  If your installation does not change the IBM-supplied default limits in
> the IEALIMIT
> or IEFUSI exit routine modules, then specifying various values for the
> region size
> has the following results:
>
> ...
>
> A value greater than 16,384K or 16M and less than or equal to 32,768K or
> 32M --
> gives the job step all the storage available below 16 megabytes. The
> resulting size
> of the region below 16 megabytes depends on system options and what system
> software is installed. The extended region size is the default value of 32
> megabytes.
>
> A value greater than 32,768K or 32M and less than or equal to 2,096,128K
> or 2047M
> -- gives the job step all the storage available below 16 megabytes. The
> resulting
> size of the region below 16 megabytes depends on system options and what
> system
> software is installed. The extended region size is the specified value. If
> the region
> size specified is not available above 16 megabytes, the job step receives
> whatever
> storage is available above 16 megabytes, up to the requested amount, and
> the
> resulting size of the region above 16 megabytes depends on system options
> and
> what system software is installed.
> 
>
> --
> Tom Marchant
>
> --
> 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: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME

[willie bunter]

I am checking the journal file hoping to find any trace of the dsn.  I don't 
have a backup of the dsn that is why I am trying to find the ML2 volser.

I cannot issue the HRECALL because the dsn doesn't exist.  The same reason I 
cannot issue the HRECOVER because there is no backup.

On Mon, 6/20/16, retired mainframer  wrote:

 Subject: Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Monday, June 20, 2016, 1:05 PM
 
 Why are you looking in
 the JOURNAL?  It contains only "recent" data
 since the last CDS backup.  How long ago was the dataset
 migrated?  To find the DSN, you need to look in the backup
 copy that covers the time frame when the migration
 occurred.  But if you need to look up anything about the
 dataset, you really should be looking in the MCDS.
 
 Why do you think you need to
 know the ML2 volume?  ML2 datasets are catalogued on
 MIGRAT2.  Does the DSN show up in 3.4?
 What
 happens if you issue an HRECALL against the DSN?  If the
 migrated copy is valid, that should be all you need.  
 
 > -Original Message-
 > From: IBM Mainframe Discussion List
 [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On
 > Behalf Of willie bunter
 > Sent: Monday, June 20, 2016 9:35 AM
 > To: IBM-MAIN@LISTSERV.UA.EDU
 > Subject: DFHSM QUESTION - RECOVER DSN FROM
 ML2 VOLUME
 > 
 > Good
 Day To All,
 > 
 > I
 would like to recover a dsn which was migrated to ML2. 
 Because of a mistake in the
 > assigning
 of the management class no back up was taken.
 > 
 > I remember
 recovering a dsn under the same circumstances.  I remember
 locating the dsn in
 > the
 HSM.JOURNAL.BACKUP.V000 (found in column 13 in HEX) and
 the volser of
 > the ML2. (which  I found
 in column 77)
 > 
 > I
 browsed the online HSM.JOURNAL (using the first and second
 HLQ)  however I was
 > unable to locate
 the dsn.  My question is do I need to wait for the CDS
 Journal backup to be
 > run (which will
 execute tonight at 8 p.m) or is there something else I can
 try?
 
 --
 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 - RECOVER DSN FROM ML2 VOLUME

[Staller, Allan]

If the dataset was *DELETED* you will have a tough time.

If the dataset was uncataloged, 

DEF NVSAM(name('dsn') DEVT() VOL(MIGRAT)

And then recall the dataset.


I cannot issue the HRECALL because the dsn doesn't exist.  The same reason I 
cannot issue the HRECOVER because there is no backup.






This email � including attachments � may contain confidential information. If 
you are not the intended recipient, do not copy, distribute or act on it. 
Instead, notify the sender immediately and delete the message.

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

Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME

[Elardus Engelbrecht]

willie bunter wrote:

>I am checking the journal file hoping to find any trace of the dsn.  I don't 
>have a backup of the dsn that is why I am trying to find the ML2 volser.

Urggg. I feel your pain. As a previous Storage Admin I had to handle 
those pain.


>I cannot issue the HRECALL because the dsn doesn't exist.  The same reason I 
>cannot issue the HRECOVER because there is no backup.

Ok. Let us go back. Did you ever issued the HLIST command as kindly suggested 
by Lizette? 

If so, then I retract my question. Sorry for being bothersome.

Please show us HOW that dataset was deleted (Post JCL + messages confirming 
that action). 

Perhaps it was just uncataloged / renamed or such? (SMF audit trails could help 
you there)

Or use ISMF to scan your volsers to see if there is a [uncataloged] copy 
lurking somewhere...

Perhaps you can scan your tape management system to see if there is a copy 
sitting somewhere?

Or do you have any Peer-to-Peer Remote Copy [1] or similar technology? Perhaps 
there is a version sitting on your remote site?

Groete / Greetings
Elardus Engelbrecht

[1] - I know that any actions are immediately duplicated to remote, but perhaps 
the line was hopefully down or something?

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

Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME

[Joel C. Ewing]

On 06/20/2016 12:19 PM, willie bunter wrote:
> Hallo to All,
>
> The dsn was migrated about 2 years ago and for some reason it was deleted 
> today (in error).  I am dusting off some old doc and as I had said earlier I 
> am checking to see what I did.  Keep you all posted if I stumble on to 
> something.
>
> 
> On Mon, 6/20/16, Lizette Koehler  wrote:
>
>  Subject: Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
>  To: IBM-MAIN@LISTSERV.UA.EDU
>  Received: Monday, June 20, 2016, 12:41 PM
>  
>  If your first statement
>  is No BACKUP has been taken, then the file is most likely
>  lost.
>  
>  When was the file
>  migrated?
>  
>  Can you show us
>  the results from a HLIST dsn(/) BOTH 
>  
>  It will help to know when it was migrated.
>  
>  CDS Backups and Journals can
>  be performed anytime.  You just have to know what kind of
>  performance impact will be felt while it is running
>  
>  
>  Lizette
>  
>  
>  > -Original
>  Message-
>  > From: IBM Mainframe
>  Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>  On
>  > Behalf Of willie bunter
>  > Sent: Monday, June 20, 2016 9:35 AM
>  > To: IBM-MAIN@LISTSERV.UA.EDU
>  > Subject: DFHSM QUESTION - RECOVER DSN FROM
>  ML2 VOLUME
>  > 
>  > Good
>  Day To All,
>  > 
>  > I
>  would like to recover a dsn which was migrated to ML2. 
>  Because of a mistake
>  > in the assigning
>  of the management class no back up was taken.
>  > 
>  > I remember
>  recovering a dsn under the same circumstances.  I remember
>  locating
>  > the dsn in the
>  HSM.JOURNAL.BACKUP.V000 (found in column 13 in HEX) and
>  the
>  > volser of the ML2. (which  I found
>  in column 77)
>  > 
>  > I
>  browsed the online HSM.JOURNAL (using the first and second
>  HLQ)  however I
>  > was unable to locate
>  the dsn.  My question is do I need to wait for the CDS
>  > Journal backup to be run (which will
>  execute tonight at 8 p.m) or is there
>  >
>  something else I can try?
>  > 
>  > Thanks.
>  > 
>  
>  --
> ...
Depending on how desperate you are to recover the data:
If you don't delay and
(1) you act before the physical tape that contained the ML2 data set is
recycled or physically scratched,
(2) you save recent backups of the production DFHSM control data sets
made from before the ML2 data set was deleted, and
(3) you have access to an isolated test z/OS system which has access to
tape drives and on which you can bring up a test DFHSM;

then it should be possible to

ON THE TEST z/OS SYSTEM:
Port the old DFHSM data sets to the test system and bring up DFHSM on
those old data sets with everything HELD except for recall;
optionally set up an isolated user catalog and alias for the lost data set;
catalog (with IDCAMS) the lost data set to VOLSER MIGRAT;
set up any ACS definitions and/or storage pools needed to support a
recall of the data set (this doesn't need to replicate the production
environment as long as the STORCLAS of  the data sets maps to a pool
with adequate space -- don't know if MGMTCLAS and DATACLAS have to be
defined on test system for recall to work);
HRECALL the data set to the test storage pool;
Use dss to make a tape backup of the data set that can be ported back to
production;

ON THE PRODUCTION SYSTEM:
Read and restore the data set from  tape written on test z/OS using dss
on the production system;

ON THE TEST z/OS SYSTEM:
Clean up the no-longer-needed stuff created on the test z/OS system.

This is potentially a lot of work and may require some experimentation
to get all the pieces right.. I'm pretty sure I actually did this once
or twice; but it took the better part of a day and was a long time ago.


-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: Where is format of Job ID documented?

[Jesse 1 Robinson]

I see the same thing as Mark. (What is LL?) I had previously ignored ASCHINTs 
because they were STC. So what happens to the TPJOBID Annn ? Are they real 
spool thingies?

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Zelden
Sent: Monday, June 20, 2016 6:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Where is format of Job ID documented?

So I was looking at some of this APPC output getting purged and noticed that 
the jobname purged is always ASCHINT with an STC job number.

I displayed one of the jobs in the spool by putting an LL next to the output in 
SDSF and the Annn jobid I see in SDSF is displayed as the "TPJOBID" in the 
output.

MZELDEN  0210  $DOS(30087),OUTGRP=ITIMCMD.1.1,LONG  
   
STC30087 0211  $HASP686 OUTPUT(ASCHINT) 154 
   
 154 0211  $HASP686 OUTPUT(ASCHINT)   
OUTGRP=ITIMCMD.1.1,BURST=NO,FCB=,
 154 0211  $HASP686   FLASH=,FORMS=STD,HOLD=(NONE), 
   
 154 0211  $HASP686   
OFFS=(),OUTDISP=HOLD,PRIORITY=144,   
 154 0211  $HASP686   PRMODE=LINE,QUEUE=Y,RECORDS=(6 OF 
6),
 154 0211  $HASP686   ROUTECDE=LOCAL,SECLABEL=, 
   
 154 0211  $HASP686   TPJOBID=A0004237,TPJOBN=ITIMCMD,  
   
 154 0211  $HASP686   
TSOAVAIL=YES,UCS=,USERID=ITIAGNT,
 154 0211  $HASP686   WRITER=,REBUILD=NO,   
   
 154 0211  $HASP686   CRTIME=(2016.170,07:04:21)   


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/



On Mon, 20 Jun 2016 03:52:33 -0500, Barry Merrill  wrote:

> FWIW, this old change does document the actual existence of JCTJOBID='A':
>
> Change 08.224  Support for MVS/ESA 4.2 (RMF 4.2.1).
> Jan 28, 1991
>
>   d. The JCTJOBID field from which TYPETASK and JESNR are
>  extracted has changed with APPC.  Instead of three
>  characters JOB/STC/TSU follwed by the five digit JESNR
>  the JCTJOBID will contain an "A" and a seven digit
>  number, which MXG stores in TYPETASK and JESNR, but
>  the maximum JESNR is 999,999 because the first of the
>  seven digits is always a zero.  You should check if
>  any reporting programs use TYPETASK for selection, and
>  to ensure they are coded robustly so they will not
>  fail if TYPETASK='A' is encountered.  The JCTJOBID
>  change was not compatibly implemented and changed
>  VMAC6,VMAC30,VMAC32,VMAC26J2, and VMAC26J3.  SMF
>  records use the fieldname SMFnnJNM for the eight byte
>  JCTJOBID field.  This IBM change in that field could
>  also affect "banner page" printing code in your SMF
>  exits.
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>On Behalf Of Mark Zelden
>Sent: Sunday, June 19, 2016 1:47 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Where is format of Job ID documented?
>
>On Sat, 18 Jun 2016 21:00:38 +, Jesse 1 Robinson  
>wrote:
>
>>How could I determine if APPC output is clogging my spool? I don't see any at 
>>the moment. 
>
>Set PREFIX=* ,  DEST= (null)  and OWNER=* in SDSF.
>
>Issue "H ALL"  and sort on JOBID and look for Annn Issue "O" and 
>sort on JOBID and look for Annn
>
>This assumes you don't have any SDSF parms or SDSF SAF security rules 
>preventing you from seeing the output.  
>
>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

RFE: Ability to associate a JOBCLASS with any PROCLIB

[Frank Swarbrick]

"Currently only the PROCLIBs named PROCxx can be referenced by the JOBCLASS 
PROCLIB= statement.This should be enhanced to allow any named PROCLIB to be 
referenced."

If this seems worthwhile to you, please vote:
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=90223



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

IRRXUTIL not authorized, but it is.

[Itschak Mugzach]

co-posted to ibm-main and racf-l (which said to be sleepy lately ;-)
I have a rexx exec running a protected user with AUDITOR attribute that has
read access to IRR.RADMIN.LISTUSER. on call x = IRRXUTIL("extract","user",
muki","mystem","r_") I get 12 12 8 8 24 which means the user is not
authorized to the service. Am I missing something?

ITschak

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

Re: Where is format of Job ID documented?

[Mark Zelden]

On Mon, 20 Jun 2016 18:16:54 +, Jesse 1 Robinson  
wrote:

>I see the same thing as Mark. (What is LL?) I had previously ignored ASCHINTs 
>because
>they were STC. So what happens to the TPJOBID Annn ? Are they real spool 
>thingies? 

LL just adds ",long" to the display ("list long").They are real spool 
"thingies".  They are
output groups associated with the ASCHINT STC.   They are assigned the Annn
TPJOBID.   Who knows what this looked like "back in the day" compared to now 
from
a JES2 standpoint.  I guess I would have to dig up some old JES2 manuals and see
if there was such an animal as TPJOBID.   I don't have time.  :-)   

So to bring this full circle, even though SDSF displays these output groups as
an Ann jobname and the numbers appear to be counted and even reset
like normal job numbers (my client resets the job numbers every shift for
some archaic reason to know what shift a job ran on and I see Annn also
reset), there are actually only 2 flavors  -  JOBn/Jnnn and
STCn/Snnn.   The RANGE= parm for JOBDEF mentioned in
an earlier post doesn't need a doc update after all.   

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: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME

[Lizette Koehler]

So I will use an infamous phrase here:  Open an SR with IBM before you do 
anything else.

Sometimes they have tools that can help you or at least provide guidance that 
this list may not be privy to.

Next, you need to know what volume the dataset resided on.
If you do full volume dumps - weekly, monthly or daily - you might have a 
chance to find the dataset.

DFHSM only knows what it knows.  If you did a physical delete and not removed 
the catalog entry, then you should see a LISTC or 3.4 entry for 

Data_set_Deleted_Name MIGRAT

If the problem is the dataset was just plain deleted and there is no longer a 
catalog entry, you need to find a full volume or other DR volume backup for 
recovery.

DFHSM will have nothing available to you.  If there is anything left in DFHSM, 
then either a product like VANTAGE with the DFHSM function included could help. 
 Otherwise contact IBM.


Please explain further what is the specific events and issues.  

Otherwise, open an SR with IBM quick. 

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Staller, Allan
> Sent: Monday, June 20, 2016 10:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
> 
> If the dataset was *DELETED* you will have a tough time.
> 
> If the dataset was uncataloged,
> 
> DEF NVSAM(name('dsn') DEVT() VOL(MIGRAT)
> 
> And then recall the dataset.
> 
> 
> I cannot issue the HRECALL because the dsn doesn't exist.  The same reason I
> cannot issue the HRECOVER because there is no backup.
> 
> 
> 

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

Re: Where is format of Job ID documented?

[Mark Zelden]

I meant to add one other point before I posted, but forgot.   Someone mentioned
having to do "something" to purge these APPC jobs.   If you have regular "mass" 
purge
commands scheduled by some automation (for example $OJOBQ, $PJOBQ, or
$POJOBQ) in order to purge APPC output you need to add the ",PROTECTED" operand 
to the command(s).  All APPC output is protected - as are OMVS "thingies" (lol) 
like BPXAS.

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/


On Mon, 20 Jun 2016 13:44:37 -0500, Mark Zelden  wrote:

>On Mon, 20 Jun 2016 18:16:54 +, Jesse 1 Robinson  
>wrote:
>
>>I see the same thing as Mark. (What is LL?) I had previously ignored ASCHINTs 
>>because
>>they were STC. So what happens to the TPJOBID Annn ? Are they real spool 
>>thingies? 
>
>LL just adds ",long" to the display ("list long").They are real spool 
>"thingies".  They are
>output groups associated with the ASCHINT STC.   They are assigned the Annn
>TPJOBID.   Who knows what this looked like "back in the day" compared to now 
>from
>a JES2 standpoint.  I guess I would have to dig up some old JES2 manuals and 
>see
>if there was such an animal as TPJOBID.   I don't have time.  :-)   
>
>So to bring this full circle, even though SDSF displays these output groups as
>an Ann jobname and the numbers appear to be counted and even reset
>like normal job numbers (my client resets the job numbers every shift for
>some archaic reason to know what shift a job ran on and I see Annn also
>reset), there are actually only 2 flavors  -  JOBn/Jnnn and
>STCn/Snnn.   The RANGE= parm for JOBDEF mentioned in
>an earlier post doesn't need a doc update after all.   
>
>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

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

Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME

[Greg Shirey]

In the z/OS 1.13 DFSMShsm Storage Admin manual, there is a page titled:   

1.20.9 Case 9: Reestablish access to previously deleted migrated data sets (no 
backup exists, ML2 only)

Here is a link: 

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2s6a2/1.20.9?SHELF=ALL13BE9&DT=20120808094757

Back when I worked at a shop that had HSM, I had to use this procedure several 
times.  I would assume it is still valid.   
Note, however, that the last step reads: 

" If you follow all steps correctly and you are still unable to recall the data 
set, contact IBM Support."

Regards,
Greg Shirey
Ben E. Keith Company 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Monday, June 20, 2016 1:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME

 

If the problem is the dataset was just plain deleted and there is no longer a 
catalog entry, you need to find a full volume or other DR volume backup for 
recovery.

DFHSM will have nothing available to you.  If there is anything left in DFHSM, 
then either a product like VANTAGE with the DFHSM function included could help. 
 Otherwise contact IBM.


 


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

Re: IRRXUTIL not authorized, but it is.

[Roach, Dennis]

FACILITY is RACLISTd. Did you refresh?

Dennis Roach, CISSP, PMP
AIG
IAM Access Administration – Consumer | Identy & Access Management

2929 Allen Parkway, America Building, 3rd Floor | Houston, TX 77019
Phone:  713-831-8799

dennis.ro...@aig.com | www.aig.com 

All opinions expressed by me are mine and may not agree with my employer or any 
person, company, or thing, living or dead, on or near this or any other planet, 
moon, asteroid, or other spatial object, natural or manufactured, since the 
beginning of time.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Itschak Mugzach
Sent: Monday, June 20, 2016 1:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IRRXUTIL not authorized, but it is.

co-posted to ibm-main and racf-l (which said to be sleepy lately ;-) I have a 
rexx exec running a protected user with AUDITOR attribute that has read access 
to IRR.RADMIN.LISTUSER. on call x = IRRXUTIL("extract","user",
muki","mystem","r_") I get 12 12 8 8 24 which means the user is not authorized 
to the service. Am I missing something?

ITschak

--
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: IRRXUTIL not authorized, but it is.

[Itschak Mugzach]

Yes i did. Somehow, the "EXTRACT" permission was not covered by the generic
profile. may be it is a non-generic check? Other users was able to use the
service, but not the protected one.

ITschak


ITschak Mugzach
Z/OS, ISV Products and Application Security & Risk Assessments Professional

On Mon, Jun 20, 2016 at 3:29 PM, Roach, Dennis  wrote:

> FACILITY is RACLISTd. Did you refresh?
>
> Dennis Roach, CISSP, PMP
> AIG
> IAM Access Administration – Consumer | Identy & Access Management
>
> 2929 Allen Parkway, America Building, 3rd Floor | Houston, TX 77019
> Phone:  713-831-8799
>
> dennis.ro...@aig.com | www.aig.com
>
> All opinions expressed by me are mine and may not agree with my employer
> or any person, company, or thing, living or dead, on or near this or any
> other planet, moon, asteroid, or other spatial object, natural or
> manufactured, since the beginning of time.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Itschak Mugzach
> Sent: Monday, June 20, 2016 1:44 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IRRXUTIL not authorized, but it is.
>
> co-posted to ibm-main and racf-l (which said to be sleepy lately ;-) I
> have a rexx exec running a protected user with AUDITOR attribute that has
> read access to IRR.RADMIN.LISTUSER. on call x = IRRXUTIL("extract","user",
> muki","mystem","r_") I get 12 12 8 8 24 which means the user is not
> authorized to the service. Am I missing something?
>
> ITschak
>
> --
> 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: OT, funny. A good comic about "Code Quality"

[Andy Wood]

On Mon, 20 Jun 2016 09:46:44 -0500, Elardus Engelbrecht 
 wrote:

. . .
>
>"I tried APL once, back in 77.  I thought it was the perfect programming 
>language.  One could write an entire program on/in one line of code. "
>

The only thing I remember about APL is ")OFF".

For some reason (lost in the mists of time) we regularly had TSO users who 
managed to "accidentally" invoke the APL interpreter, which was almost 
impossible to terminate unless you knew the above magic incantation.

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

Re: OT, funny. A good comic about "Code Quality"

[Walter Davies]

In the early 80's IBM's software configuration programs were written in
APL. Was a contractor  for them at the time.

On Mon, Jun 20, 2016 at 1:03 PM, Andy Wood  wrote:

> On Mon, 20 Jun 2016 09:46:44 -0500, Elardus Engelbrecht <
> elardus.engelbre...@sita.co.za> wrote:
>
> . . .
> >
> >"I tried APL once, back in 77.  I thought it was the perfect programming
> language.  One could write an entire program on/in one line of code. "
> >
>
> The only thing I remember about APL is ")OFF".
>
> For some reason (lost in the mists of time) we regularly had TSO users who
> managed to "accidentally" invoke the APL interpreter, which was almost
> impossible to terminate unless you knew the above magic incantation.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 



Walter Davies
Supervising IT Analyst
walter.dav...@edcgov.us
(530) 621-5420

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

Re: OT, funny. A good comic about "Code Quality"

[Rugen, Len]

I worked where IBM's Information Center was installed, it was a CMS product 
written in APL.  

I had to "fix" something, creating an array "yourboat" just so I could  it :-)  


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Andy Wood
Sent: Monday, June 20, 2016 3:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: OT, funny. A good comic about "Code Quality"

On Mon, 20 Jun 2016 09:46:44 -0500, Elardus Engelbrecht 
 wrote:

. . .
>
>"I tried APL once, back in 77.  I thought it was the perfect programming 
>language.  One could write an entire program on/in one line of code. "
>

The only thing I remember about APL is ")OFF".

For some reason (lost in the mists of time) we regularly had TSO users who 
managed to "accidentally" invoke the APL interpreter, which was almost 
impossible to terminate unless you knew the above magic incantation.

--
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 - RECOVER DSN FROM ML2 VOLUME

[willie bunter]

Elardus 

The user said that she did a HDEL besides the dsn.  I did a HLIST however it 
was unsuccessful.

I am looking at the suggestion posted earlier about the doc to recover a 
deleted ML2 dsn.


On Mon, 6/20/16, Elardus Engelbrecht  wrote:

 Subject: Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Monday, June 20, 2016, 1:58 PM
 
 willie bunter wrote:
 
 >I am checking the journal file hoping to find any trace
 of the dsn.  I don't have a backup of the dsn that is
 why I am trying to find the ML2 volser.
 
 Urggg. I feel your pain. As a previous Storage Admin
 I had to handle those pain.
 
 
 >I cannot issue the HRECALL because the dsn doesn't
 exist.  The same reason I cannot issue the HRECOVER
 because there is no backup.
 
 Ok. Let us go back. Did you ever issued the HLIST command as
 kindly suggested by Lizette? 
 
 If so, then I retract my question. Sorry for being
 bothersome.
 
 Please show us HOW that dataset was deleted (Post JCL +
 messages confirming that action). 
 
 Perhaps it was just uncataloged / renamed or such? (SMF
 audit trails could help you there)
 
 Or use ISMF to scan your volsers to see if there is a
 [uncataloged] copy lurking somewhere...
 
 Perhaps you can scan your tape management system to see if
 there is a copy sitting somewhere?
 
 Or do you have any Peer-to-Peer Remote Copy [1] or similar
 technology? Perhaps there is a version sitting on your
 remote site?
 
 Groete / Greetings
 Elardus Engelbrecht
 
 [1] - I know that any actions are immediately duplicated to
 remote, but perhaps the line was hopefully down or
 something?
 
 --
 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

Display in ULOG of SDSF

[Pierre Fichaud]

I've issued a MODIFY to my STC in ULOG. 
It is a DISPLAY command for my STC.
The answer is not seen in the ULOG. It shows up in my STC's output (JESMSGLG) 
though.
If I issue a D PROG,APF in the ULOG, I see the response displayed in the ULOG.

I have captured the CONSNAME, CONSID and CART when the modify is done and I use 
the CONSNAME and CART to issue the WTO.
I have not coded MCSFLAG,ROUTCDE or DESC.

I'd like the output of my internal display command to be displayed in the ULOG.
Any help here would be appreciated.
Thanks, in advance, Pierre.


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

Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME

[Walter Davies]

Just because you delete a data set if it has backups they might still be
there. Try allocating the old DSN as empty and restore from a backup. I
have done that before.

On Mon, Jun 20, 2016 at 2:02 PM, willie bunter <
001409bd2345-dmarc-requ...@listserv.ua.edu> wrote:

> Elardus
>
> The user said that she did a HDEL besides the dsn.  I did a HLIST however
> it was unsuccessful.
>
> I am looking at the suggestion posted earlier about the doc to recover a
> deleted ML2 dsn.
>
> 
> On Mon, 6/20/16, Elardus Engelbrecht 
> wrote:
>
>  Subject: Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
>  To: IBM-MAIN@LISTSERV.UA.EDU
>  Received: Monday, June 20, 2016, 1:58 PM
>
>  willie bunter wrote:
>
>  >I am checking the journal file hoping to find any trace
>  of the dsn.  I don't have a backup of the dsn that is
>  why I am trying to find the ML2 volser.
>
>  Urggg. I feel your pain. As a previous Storage Admin
>  I had to handle those pain.
>
>
>  >I cannot issue the HRECALL because the dsn doesn't
>  exist.  The same reason I cannot issue the HRECOVER
>  because there is no backup.
>
>  Ok. Let us go back. Did you ever issued the HLIST command as
>  kindly suggested by Lizette?
>
>  If so, then I retract my question. Sorry for being
>  bothersome.
>
>  Please show us HOW that dataset was deleted (Post JCL +
>  messages confirming that action).
>
>  Perhaps it was just uncataloged / renamed or such? (SMF
>  audit trails could help you there)
>
>  Or use ISMF to scan your volsers to see if there is a
>  [uncataloged] copy lurking somewhere...
>
>  Perhaps you can scan your tape management system to see if
>  there is a copy sitting somewhere?
>
>  Or do you have any Peer-to-Peer Remote Copy [1] or similar
>  technology? Perhaps there is a version sitting on your
>  remote site?
>
>  Groete / Greetings
>  Elardus Engelbrecht
>
>  [1] - I know that any actions are immediately duplicated to
>  remote, but perhaps the line was hopefully down or
>  something?
>
>  --
>  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
>



-- 



Walter Davies
Supervising IT Analyst
walter.dav...@edcgov.us
(530) 621-5420

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

Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME

[Greg Shirey]

Willie has already posted that there is no backup.  The data set along with the 
catalog entry has been deleted - as long as the ML2 tape has not been recycled, 
it can be retrieved from there.  There is a documented procedure for doing this 
in the HSM administration manual.   

Regards,
Greg Shirey
Ben E. Keith Company 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Walter Davies
Sent: Monday, June 20, 2016 4:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME

Just because you delete a data set if it has backups they might still be there. 
Try allocating the old DSN as empty and restore from a backup. I have done that 
before.



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

Re: TIOT exceeded

[Lizette Koehler]

Why not run with TIOT set to 64K?  I know a lot of shops that have set that to 
the maximum of 64K

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jake Anderson
> Sent: Monday, June 20, 2016 6:35 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: TIOT exceeded
> 
> Lizette,
> 
> The error message was
> 
> IEF240I JOBNAME STEPNAME - TASK I/O TABLE EXCEEDS TIOT LIMIT OF 0048K
> 
> I found that the GDG members were created on Multivolume.
> 
> On Mon, Jun 20, 2016 at 6:48 PM, Lizette Koehler 
> wrote:
> 
> > Jake,
> >
> > This is a more helpful posting for your question.  We can see what
> > your issue is with your question about TIOTs.
> >
> > Next, what error message do you get in your job when it fails?  Please
> > post the entire message and not just the message ID.
> >
> > Lizette
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake Anderson
> > > Sent: Monday, June 20, 2016 1:18 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: TIOT exceeded
> > >
> > > Hi,
> > >
> > > The JCL abended even before reaching the Limit of 48k set in our
> > > Shop. on every GDG deletion DD statement, we had 256 generations and
> > > it was same
> > for
> > > 4 DD statements.
> > >
> > > Is there any reason even if the TIOT size is set at 48k But the Job
> > abends
> > > before the DD statement reached 2454 ?
> > >
> > > On Mon, Jun 20, 2016 at 12:30 PM, Jake Anderson <
> > justmainfra...@gmail.com>
> > > wrote:
> > >
> > > > Hi
> > > >
> > > > The TIOT started failing when the JCL started deleted a group of  GDGs.
> > > > Using DISP=OLD,DELETE
> > > >
> > > > Jake
> > > > On Jun 20, 2016 2:32 AM, "Greg Dyck"  wrote:
> > > >
> > > >> On 6/18/2016 11:03 AM, Jake Anderson wrote:
> > > >>
> > > >>> Is there a way to know if the DD chain has approached the end or
> > > >>> it has approached the end of Chain. Is there a way to tweak the
> > > >>> JCL to overcome TIOT exceeded values ?
> > > >>>
> > > >>
> > > >> The TIOT is a fixed sized array of entries, not a chain.  The
> > > >> size is defined in PARMLIB member ALLOCxx, with a maximum allowed
> > > >> size of 64K. Only when an allocation request fails due to
> > > >> insufficient TIOT space do you know it is full.
> > > >>
> > > >> The primary 'tweak' for SMS managed datasets that can reduce the
> > > >> space used for each DD in the TIOT is to reduce the dynamic
> > > >> volume count (DYNVOL) specification defined for the data class (
> > > >> http://www-01.ibm.com/support/docview.wss?uid=isg3T165).
> > > >>
> > > >> It is possible to dynamically allocated datasets using the
> > > >> extended TIOT (aka, XTIOT).  This requires the application be
> > > >> updated appropriately (
> > > >> http://publibz.boulder.ibm.com/zoslib/pdf/oa34634.pdf).  For
> > > >> non-VSAM datasets you must also change PARMLIB member DEVSUPxx to
> > > >> specify NON_VSAM_XTIOT=YES.  VSAM datasets may be allocated using
> > > >> the XTIOT
> > without
> > > any changes to PARMLIB.
> > > >>
> > > >> Greg
> > > >>

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

Re: IRRXUTIL not authorized, but it is.

[Scott Ford]

You need more than 'irr.radmin.listuser', it's performing and extract not
listuser..
We use it in our product

Scott

On Monday, June 20, 2016, Itschak Mugzach  wrote:

> Yes i did. Somehow, the "EXTRACT" permission was not covered by the generic
> profile. may be it is a non-generic check? Other users was able to use the
> service, but not the protected one.
>
> ITschak
>
>
> ITschak Mugzach
> Z/OS, ISV Products and Application Security & Risk Assessments Professional
>
> On Mon, Jun 20, 2016 at 3:29 PM, Roach, Dennis  > wrote:
>
> > FACILITY is RACLISTd. Did you refresh?
> >
> > Dennis Roach, CISSP, PMP
> > AIG
> > IAM Access Administration – Consumer | Identy & Access Management
> >
> > 2929 Allen Parkway, America Building, 3rd Floor | Houston, TX 77019
> > Phone:  713-831-8799
> >
> > dennis.ro...@aig.com | www.aig.com
> >
> > All opinions expressed by me are mine and may not agree with my employer
> > or any person, company, or thing, living or dead, on or near this or any
> > other planet, moon, asteroid, or other spatial object, natural or
> > manufactured, since the beginning of time.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU
> ] On
> > Behalf Of Itschak Mugzach
> > Sent: Monday, June 20, 2016 1:44 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU 
> > Subject: IRRXUTIL not authorized, but it is.
> >
> > co-posted to ibm-main and racf-l (which said to be sleepy lately ;-) I
> > have a rexx exec running a protected user with AUDITOR attribute that has
> > read access to IRR.RADMIN.LISTUSER. on call x =
> IRRXUTIL("extract","user",
> > muki","mystem","r_") I get 12 12 8 8 24 which means the user is not
> > authorized to the service. Am I missing something?
> >
> > ITschak
> >
> > --
> > 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: owner-ibm-main

[CM Poncelet]

If all else fails, try the following:
- access https://www.spamcop.net/mcgi?action=loginform and then forward 
the complete spam email (headers+body) to them. (I am a member of 
Spamcop, but non-members too can report spam.)
- set up an email filter to trap all emails from 
"owner-ibm-m...@listserv.ua.edu" and move them to the 'trash' folder. 
BTW Other 'from' filter rules might be needed if no 'From:' is 
displayed. If so, either check the email headers to find the first 
'From:' in the headers and use that as the 'from' filter, or else 
include a rule to 'trash' any email from " @listserv.ua.edu" that has no 
'From:'.


E,g, These are in the sender's email headers:

Sender: IBM Mainframe Discussion List 
From: Ron Hawkins   ( <-- this is the first 'From:' 
in the headers)

CP


Ron Hawkins wrote:


Maybe you should be asking Symantic...

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Campbell Jay
Sent: Sunday, June 19, 2016 11:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] owner-ibm-main

Am I being SPAMed ?
They're getting annoying.

Supposedly from  owner-ibm-m...@listserv.ua.edu   sometimes with no From:

Text...

X-Brightmail-Tracker:
H4sIA+NgFlrNLMWRWlGSWpSXmKPExsXCdV5DVffPnbRwg4nfTCxev023WPm/mdHi

4qc9jA7MHkfWHmQOYIzisklJzcksSy3St0vgyujZfYGtgKECRDUwMkxgZFjAyLCKUTYswCjY

19XXMSAg2NfdwEgvpVgvs6g4L7VELz2/bBMjyK7bgbE7GNd8dDzEKMDBqMTD27kiLVyINbGs

uDL3EKMkB5OSKO+e7tRwIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8x28DlfOmJFZWpRblw6Sk

OViUxHk/TXweIiSQnliSmp2aWpBaBJOV4eBQkuCdCtIoWJSanlqRlplTgpBm4uAEGc4DNPw8

2PDigsTc4sx0iPwpRkOOfYtvrGXiuPDsAZC8AiKFWPLy81KlxHkzQBoEQBoySvPgZl5iFJUS

5mVkYGAQ4gG6IzezBCL+ilEc6GVhXgVgUAvxZOaVwG15BXQAE9ABmvOSQQ4oSURISTUwcva0

/D49q2btxbqy0iMKH98kP9qzzmHfzxmPhHKc1V81F7rdqv/AZO1p43tbYp1uYnbjwkpZh73Z

811VFB3OHPtx7fqJjKWybfULRV+vkWuXC/jCE6dgcSBo+ZfnHo75U24eKsg+tZ5XKTrzemfX
JZPZC9vm9W99w5r98r2/Vr8d09zHXnVPlFiKMxINtZiLihMBA4pxRz4CAAA=
Date: Sun Jun 19 12:57:16 2016

Jay Campbell
IBM OS Support Section

--
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: TIOT exceeded

[Jake Anderson]

Hi Lizette

Apology to ask

I am not still able to understand the calculation of TIOT usage in my case.

It was just 1027 GDG members spanning across multiple volume.

So how did it exhaust the TIOT ? Is there a formula that would help me to
determine?

Jake
On Jun 21, 2016 3:23 AM, "Lizette Koehler"  wrote:

> Why not run with TIOT set to 64K?  I know a lot of shops that have set
> that to the maximum of 64K
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Jake Anderson
> > Sent: Monday, June 20, 2016 6:35 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: TIOT exceeded
> >
> > Lizette,
> >
> > The error message was
> >
> > IEF240I JOBNAME STEPNAME - TASK I/O TABLE EXCEEDS TIOT LIMIT OF 0048K
> >
> > I found that the GDG members were created on Multivolume.
> >
> > On Mon, Jun 20, 2016 at 6:48 PM, Lizette Koehler <
> stars...@mindspring.com>
> > wrote:
> >
> > > Jake,
> > >
> > > This is a more helpful posting for your question.  We can see what
> > > your issue is with your question about TIOTs.
> > >
> > > Next, what error message do you get in your job when it fails?  Please
> > > post the entire message and not just the message ID.
> > >
> > > Lizette
> > >
> > >
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List
> > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake Anderson
> > > > Sent: Monday, June 20, 2016 1:18 AM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Re: TIOT exceeded
> > > >
> > > > Hi,
> > > >
> > > > The JCL abended even before reaching the Limit of 48k set in our
> > > > Shop. on every GDG deletion DD statement, we had 256 generations and
> > > > it was same
> > > for
> > > > 4 DD statements.
> > > >
> > > > Is there any reason even if the TIOT size is set at 48k But the Job
> > > abends
> > > > before the DD statement reached 2454 ?
> > > >
> > > > On Mon, Jun 20, 2016 at 12:30 PM, Jake Anderson <
> > > justmainfra...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi
> > > > >
> > > > > The TIOT started failing when the JCL started deleted a group of
> GDGs.
> > > > > Using DISP=OLD,DELETE
> > > > >
> > > > > Jake
> > > > > On Jun 20, 2016 2:32 AM, "Greg Dyck"  wrote:
> > > > >
> > > > >> On 6/18/2016 11:03 AM, Jake Anderson wrote:
> > > > >>
> > > > >>> Is there a way to know if the DD chain has approached the end or
> > > > >>> it has approached the end of Chain. Is there a way to tweak the
> > > > >>> JCL to overcome TIOT exceeded values ?
> > > > >>>
> > > > >>
> > > > >> The TIOT is a fixed sized array of entries, not a chain.  The
> > > > >> size is defined in PARMLIB member ALLOCxx, with a maximum allowed
> > > > >> size of 64K. Only when an allocation request fails due to
> > > > >> insufficient TIOT space do you know it is full.
> > > > >>
> > > > >> The primary 'tweak' for SMS managed datasets that can reduce the
> > > > >> space used for each DD in the TIOT is to reduce the dynamic
> > > > >> volume count (DYNVOL) specification defined for the data class (
> > > > >> http://www-01.ibm.com/support/docview.wss?uid=isg3T165).
> > > > >>
> > > > >> It is possible to dynamically allocated datasets using the
> > > > >> extended TIOT (aka, XTIOT).  This requires the application be
> > > > >> updated appropriately (
> > > > >> http://publibz.boulder.ibm.com/zoslib/pdf/oa34634.pdf).  For
> > > > >> non-VSAM datasets you must also change PARMLIB member DEVSUPxx to
> > > > >> specify NON_VSAM_XTIOT=YES.  VSAM datasets may be allocated using
> > > > >> the XTIOT
> > > without
> > > > any changes to PARMLIB.
> > > > >>
> > > > >> Greg
> > > > >>
>
> --
> 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