Re: Dataset space information

[retired mainframer]

If all you want to know is how the dataset is allocated on the DASD, the TSO 
LISTDS command with the LABEL operand will display the DSCB including the 
extents.  The display is in a pseudo-dump format and the DFSMSdfp Advanced 
Services manual shows the internal structure.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of michelbutz
> Sent: Tuesday, May 03, 2016 1:23 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Dataset space information
> 
> This all started by me trying to find out how space was taken by a dataset 
> DSCB info which
> led me to CVAFDIR
> It needed the DEB of the VTOC
> Maybe I should of used OBTAIN/CAMLIST

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

AW: Re: High number of samples seen in IEAVEPS1. What does this tell me?

[Peter Hunkeler]

>The tool is improperly counting samples in Pause processing as using CPU
rather than counting them as delays.  Strobe had the same issue years
ago, when Pause/Release was first introduced.




MA-Tune has it right, it was me who was wrong: I thought IEAVEPS1 is POST, and 
therfore I would not have expected many samples to show up for IEAVEPS1, not 
matter whether waiting or active samples. (BTW, the samples show the code is 
waiting there).


As stated previously, the question marks arose because I had mistaken IEAVEPS1 
to be POST. Looking at the samples knowing that IEAVEPS1 is PAUSE, the question 
marks disappear.


--
Peter Hunkeler


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

Re: Dataset space information

[michelbutz]

For CVAF I need the DEB of the VTOC 

Sent from my iPhone

> On May 3, 2016, at 7:24 PM, Mike Shaw  wrote:
> 
>> On 5/3/2016 11:29 AM, michelbutz wrote:
>> Hi
>> ..
> 
> Michael, since you said "...what is the VTOC..." it looks like you have a 
> long row to hoe..
> 
> To read the VTOC of a DASD volume you can issue a RDJFCB for a DDNAME that is 
> allocated to the volume, set the DSN in that JFCB to all x'04' characters, 
> then use OPEN TYPE=J to open the VTOC with that JFCB.
> 
> You can then read the entire with EXCP or BSAM to get the DSCBs and 
> interrogate each one in turn.
> 
> If you just want space info for one DS, maybe CVAF is better.
> 
> We have tried CVAF, BSAM, and EXCP; EXCP with a chained channel program is 
> fastest. If you don't care about speed, then use CVAF.
> 
> Mike Shaw
> MVS/QuickRef Support Group
> Chicago-Soft, Ltd.
> 
> --
> 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: Dataset space information

[Edward Finnell]

IIRC there's one already coded up on cbttape.org  file182 with PDS  command.
 
 
In a message dated 5/3/2016 6:25:11 P.M. Central Daylight Time,  
techsupp...@quickref.com writes:

If you  just want space info for one DS, maybe CVAF is better.

We have tried  CVAF, BSAM, and EXCP; EXCP with a chained channel program 
is fastest. If  you don't care about speed, then use  CVAF.


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

Re: Dataset space information

[Mike Shaw]

On 5/3/2016 11:29 AM, michelbutz wrote:

Hi
..



Michael, since you said "...what is the VTOC..." it looks like you have 
a long row to hoe..


To read the VTOC of a DASD volume you can issue a RDJFCB for a DDNAME 
that is allocated to the volume, set the DSN in that JFCB to all x'04' 
characters, then use OPEN TYPE=J to open the VTOC with that JFCB.


You can then read the entire with EXCP or BSAM to get the DSCBs and 
interrogate each one in turn.


If you just want space info for one DS, maybe CVAF is better.

We have tried CVAF, BSAM, and EXCP; EXCP with a chained channel program 
is fastest. If you don't care about speed, then use CVAF.


Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.

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

Re: SRB dispatching question

[michelbutz]

Thanks I am going to try the GTF trace

Sent from my iPhone

> On May 3, 2016, at 9:02 AM, Blaicher, Christopher Y.  
> wrote:
> 
> Peter,
> Obviously I didn't fully put on my thinking cap yesterday when I mentioned 
> the LOCAL LOCK.
> 
> I was attempting to think of what might be causing the poster's perceived 
> condition of SRB #2 not appearing to run in the address space of the PAUSED 
> global SRB #1.
> Your comment seems to be backing my understanding that once SRB #1 did the 
> PAUSE, SRB #2, or any other qualifying unit of work, was free to run in the 
> address space subject to normal dispatching rules.
> 
> Michel,
> You may want to run this situation on a test machine and start a GTF trace 
> and see what is happening from that.  It should answer the question about if 
> the second SRB is being dispatched or not.
> 
> Chris Blaicher
> Technical Architect
> Mainframe Development
> Syncsort Incorporated
> 50 Tice Boulevard, Woodcliff Lake, NJ 07677
> P: 201-930-8234  |  M: 512-627-3803
> E: cblaic...@syncsort.com
> 
> www.syncsort.com
> 
> 
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Peter Relson
> Sent: Tuesday, May 3, 2016 7:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SRB dispatching question
> 
> I'll point out that the very fact that a global SRB paused very likely means 
> that you did not consider the SRB itself truly to be global. The system will 
> no longer treat it as such after the pause.
> 
> Chris mentioned the local lock. I'm not sure why. You can't pause a work unit 
> that is holding the local lock. Obviously some other running work unit could 
> hold the local lock and thus prevent an SRB scheduled with LLOCK=YES from 
> beginning.
> 
> In the scenario posed
> SRB 1 scheduled to address space A pauses SRB 2 was scheduled to address 
> space A (from anywhere) SRB 2 will run, according to normal dispatch priority 
> rules.
> 
> Peter Relson
> z/OS Core Technology Design
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> 
> 
> 
> ATTENTION: -
> 
> The information contained in this message (including any files transmitted 
> with this message) may contain proprietary, trade secret or other 
> confidential and/or legally privileged information. Any pricing information 
> contained in this message or in any files transmitted with this message is 
> always confidential and cannot be shared with any third parties without prior 
> written approval from Syncsort. This message is intended to be read only by 
> the individual or entity to whom it is addressed or by their designee. If the 
> reader of this message is not the intended recipient, you are on notice that 
> any use, disclosure, copying or distribution of this message, in any form, is 
> strictly prohibited. If you have received this message in error, please 
> immediately notify the sender and/or Syncsort and destroy all copies of this 
> message in your possession, custody or control.
> 
> --
> 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: IBM secure z/OS software delivery: Don't get locked out!

[Jesse 1 Robinson]

OK, just learned from a colleague who actually read the doc (!) that with the 
addition of two lines in , HTTPS is used to download an order 
instead of FTP. I missed that tweak. Mea culpa.

   downloadmethod="https" 
   downloadkeyring="javatruststore"   

.
.
.
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: Jesse 1 Robinson 
Sent: Tuesday, May 03, 2016 1:59 PM
To: 'IBM Mainframe Discussion List' 
Subject: Re: IBM secure z/OS software delivery: Don't get locked out!

Sorry to harp on a question that I've asked before, but I need to ask it again. 
We cannot use FTPS here because the proxy appliance we're required to go 
through (Blue Coat) does not understand it. We get 'syntax error' from the 
appliance with FTPS keywords. We have no problem with Shopz orders getting 
delivered directly to the mainframe. In the past I was told that we should be 
fine because this indicates that HPPTS is working. However, we also see the 
messages below in a Shopz order. Looks a lot like vanilla FTP. I need some 
reassurance. ;-)

DATE 05/02/16  TIME 13:44:35SMP/E FTP Output   SMP/E 36.74  

> /bin/ftp -e proxyz.sce.com 21 



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kurt Quackenbush
Sent: Tuesday, May 03, 2016 7:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IBM secure z/OS software delivery: Don't get locked out!

>> Well, the date for the end of the transition has been announced:
>> "As of AUGUST 14, 2016, all unsecured connections will be rejected by 
>> IBM download servers used for all z/OS product and service orders."
>
> Including for example SCRT software, Red Alerts and freebies (RACF 
> goodies, RMF Spreadsheet software, et al.) from www.ibm.com?

No, it only affects "IBM download servers used for all z/OS product and service 
orders."

Kurt Quackenbush -- IBM, SMP/E Development


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

Re: High number of samples seen in IEAVEPS1. What does this tell me?

[Greg Dyck]

On 5/3/2016 4:30 AM, Peter Hunkeler wrote:

I'm analyzing a job using CA's MA-Tune (similar to Strobe). Question is if 
there is that could be optimized. Looking at the MA-Tune reports which are 
based on 100 samples per second for 1 minute, I see that the job is seen in 
IEAVEPS1 for some 20%. IEAVEPS1 is POST, IIRC.

I thought that POST would be a quick process and therefore I'm wondering it 
appears at the top of the list. I'd like to understand a bit better what I'm 
seeing and I'm *not* saying this is a problem.

The program does a lot with DB2, and when a DB2 call is made, I'd expect the 
TCB to go into a WAIT until the SRB in DB2 completes and POSTs the TCB. 
Watching from 9000 ft, is this about right?


Why do I not see any entry reporting the WAIT (IEAVEWT1 or similar)? Is this 
just bad luck with sampling?


I would have thought that POSTing is quick, so I wonder why I often see a 
couple of IEAVEPS1 entries in a row? Of yourse 1/100s is a long time so other 
things may have happened inbetween, not being caught ba MA-Tune's sampling. I 
wonder, however, if and what could case this to take longer that what I would 
expect.

Any clue?


The tool is improperly counting samples in Pause processing as using CPU 
rather than counting them as delays.  Strobe had the same issue years 
ago, when Pause/Release was first introduced.

Greg

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

Re: SRB dispatching question

[Greg Dyck]

On 5/1/2016 3:45 PM, michelbutz wrote:

Hi

If a nonpreamtable scope=global SRB does a pause
And another SRB is scheduled does it get dispatched ?


Being non-preemptable means that z/OS won't take control away from the 
unit of work without cause.  Cause being something like a page fault 
requiring a page-in from DASD or a SETLOCK request for a local lock that 
is unavailable.  Or if you *explicitly* request to give up control by 
performing a SUSPEND w/Token or a Pause.


Once the SRB has has lost or given up control the next ready unit of 
work will get control based on address space and minor priorities.  If 
the work required the local lock and it is not available then the work 
is 'not ready' until the local lock becomes available.

Greg

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

Re: IBM secure z/OS software delivery: Don't get locked out!

[Jesse 1 Robinson]

Sorry to harp on a question that I've asked before, but I need to ask it again. 
We cannot use FTPS here because the proxy appliance we're required to go 
through (Blue Coat) does not understand it. We get 'syntax error' from the 
appliance with FTPS keywords. We have no problem with Shopz orders getting 
delivered directly to the mainframe. In the past I was told that we should be 
fine because this indicates that HPPTS is working. However, we also see the 
messages below in a Shopz order. Looks a lot like vanilla FTP. I need some 
reassurance. ;-)

DATE 05/02/16  TIME 13:44:35SMP/E FTP Output   SMP/E 36.74  

> /bin/ftp -e proxyz.sce.com 21 

Using 'SYS1.TCPPARMS(FTPDATA)' for local site configuration parameters. 
IBM FTP CS V2R1 
FTP: EXIT has been set. 
Connecting to: proxyz.glbi.sce.com 192.212.253.130 port: 21.
 
220 Blue Coat FTP Service   
NAME (proxyz.sce.com:USERID):   

> s4n85...@deliverycb-bld.dhe.ibm.com   
>>> USER s4n85...@deliverycb-bld.dhe.ibm.com
331 Password required for S4n85789. 
PASSWORD:   

>   
>>> PASS
230 Virtual user S4n85789 logged in.
Command:

> BINARY
>>> TYPE I  
200 Command okay.   
Command:

> GET "/2016050262968/PROD/GIMPAF.XML" "/SMPE/zosnts/ORD00030-02May2016-13.44.35
> /GIMPAF.XML" (REPLACE 
>>> PORT 172,28,138,10,17,217   
200 PORT command successful.
>>> RETR /2016050262968/PROD/GIMPAF.XML 
150 File status okay; about to open data connection.
226 Transfer complete, closing data connection. 
2720 bytes transferred in 0.005 seconds.  Transfer rate 544.00 Kbytes/sec.  

.
.
.
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 Kurt Quackenbush
Sent: Tuesday, May 03, 2016 7:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IBM secure z/OS software delivery: Don't get locked out!

>> Well, the date for the end of the transition has been announced:
>> "As of AUGUST 14, 2016, all unsecured connections will be rejected by 
>> IBM download servers used for all z/OS product and service orders."
>
> Including for example SCRT software, Red Alerts and freebies (RACF 
> goodies, RMF Spreadsheet software, et al.) from www.ibm.com?

No, it only affects "IBM download servers used for all z/OS product and service 
orders."

Kurt Quackenbush -- IBM, SMP/E Development


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

Re: SRB dispatching question

[Greg Dyck]

On 5/2/2016 12:54 PM, Blaicher, Christopher Y. wrote:

What parameters were on the IEAMSCHD macros for the two SRB's?  If the 
LLOCK=YES parm is set on both, then there is your problem.


A Pause is not allowed while holding *any* class of lock.  The Pause 
request will fail.

Greg

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

Re: Dataset space information

[michealbutz]

thanks that maybe a lot easier 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rob Scott
Sent: Tuesday, May 3, 2016 4:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dataset space information

If you need to find the space info for a single dataset - use CAMLST SEARCH to 
get the F1-DSCB and then CAMLST SEEK to process the F3-DSCBs.

For PDS/Es - you need to use FAMS (not a public interface).

For VSAM you can also use IGGCSI00

For bulk dataset info requests - you can use the DCOLLECT output and 
post-process it.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of michelbutz
Sent: Tuesday, May 3, 2016 9:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dataset space information

This all started by me trying to find out how space was taken by a dataset DSCB 
info which led me to CVAFDIR It needed the DEB of the VTOC Maybe I should of 
used OBTAIN/CAMLIST

Sent from my iPhone

> On May 3, 2016, at 4:09 PM, J R  wrote:
>
> The RDJFCB doesn't care too much about the DCB other than for the DDNAME and 
> where to put the copy of the JFCB.
>
> I'm not really sure what you're trying to do.  Unless you actually want to 
> access your dataset rather than its DSCB, why do you want to access the VTOC?
>
> Back in the '60s, this sort of thing was in the System Programmer's Guide.  
> It may be in Using Datasets or something similar now.
>
> However , you've lost me now.  I don't know why you need the DEB.  But you 
> should be able to get to it from the DCB.
>
> Sent from my iPhone
>
>> On May 3, 2016, at 15:54, michelbutz  wrote:
>>
>> Okay then the DCB on the open type=j is for the VTOC how about the 
>> DCB for the RDJFCB The original DCB in my program was for VB Dataset 
>> I hate bothering everybody is this documented anywhere i.e how to get 
>> the deb of the VTOC
>>
>>
>> Sent from my iPhone
>>
>>> On May 3, 2016, at 3:44 PM, J R  wrote:
>>>
>>> You should use BSAM, ie. READ, not GET, KEYLEN=44, BLKSIZE=140? (Not sure, 
>>> it's been a long time). Then read until you see your damage in the key 
>>> area. Or, if you are more adventurous, you could use BDAM and search 
>>> directly for the key you are interested in.
>>>
>>> Sent from my iPhone
>>>
 On May 3, 2016, at 15:11, michelbutz  wrote:

 Something strange is bombed on the open Message IEC141I the dataset 
 it in the message is sys1.vtoc The DCB whose DSCB I am trying to 
 access is a VB have that  DCB on the open type=j

 Sent from my iPhone

> On May 3, 2016, at 2:35 PM, J R  wrote:
>
> Do the RDJFCB first, *then* move the 44X'4' to JFCBDSNM.
>
> Sent from my iPhone
>
>> On May 3, 2016, at 14:30, michelbutz  wrote:
>>
>> I am still getting return code 4 in R15 CVSTAT is 8
>>
>> I first move 44X'04' to JFCBDSNM
>> I then do a READJFCB FILE
>> Everything is okay I get R15 = 0
>> I then do OPEN FILE,TYPE=J
>> R15 = 0
>> I then do ICM. R11,B'0111',DCBDEBA XC 
>> BUFLIST(BFLHLN+BFLELN),BUFLIST OI  BFLHFL,BFLHDSCB MVI. BFLHNOE,1 
>> LA. R6,DS1FMTID ST. R6,BFLEBUF OI.  BFLEFL,BFLECHR MVI.
>> BFLELTH,DSCBLTH
>>
>> CVAFDIR ACCESS=READ,DSN=DSN,BUFLIST=BUFLIST,DEB=(R11)
>>
>> I get rerun code 4 in R15 and CVSTAT is 08 invalid DEB
>>
>> Sent from my iPhone
>>
>>> On May 3, 2016, at 1:56 PM, J R  wrote:
>>>
>>> Nope.
>>>
>>> Sent from my iPhone
>>>
 On May 3, 2016, at 13:55, Staller, Allan  
 wrote:

 ITYM 44x'40'

 

 So, as I posted before:

 VTOC DSN is 44X'4'

 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
>>>
>>> 
>>> -- 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: Dataset space information

[J R]

I agree.  For a single dataset, OBTAIN/CAMLST would be much simpler. 

Sent from my iPhone

> On May 3, 2016, at 16:38, michealbutz  wrote:
> 
> thanks that maybe a lot easier 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Rob Scott
> Sent: Tuesday, May 3, 2016 4:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Dataset space information
> 
> If you need to find the space info for a single dataset - use CAMLST SEARCH 
> to get the F1-DSCB and then CAMLST SEEK to process the F3-DSCBs.
> 
> For PDS/Es - you need to use FAMS (not a public interface).
> 
> For VSAM you can also use IGGCSI00
> 
> For bulk dataset info requests - you can use the DCOLLECT output and 
> post-process it.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of michelbutz
> Sent: Tuesday, May 3, 2016 9:23 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Dataset space information
> 
> This all started by me trying to find out how space was taken by a dataset 
> DSCB info which led me to CVAFDIR It needed the DEB of the VTOC Maybe I 
> should of used OBTAIN/CAMLIST
> 
> Sent from my iPhone
> 
>> On May 3, 2016, at 4:09 PM, J R  wrote:
>> 
>> The RDJFCB doesn't care too much about the DCB other than for the DDNAME and 
>> where to put the copy of the JFCB.
>> 
>> I'm not really sure what you're trying to do.  Unless you actually want to 
>> access your dataset rather than its DSCB, why do you want to access the VTOC?
>> 
>> Back in the '60s, this sort of thing was in the System Programmer's Guide.  
>> It may be in Using Datasets or something similar now.
>> 
>> However , you've lost me now.  I don't know why you need the DEB.  But you 
>> should be able to get to it from the DCB.
>> 
>> Sent from my iPhone
>> 
>>> On May 3, 2016, at 15:54, michelbutz  wrote:
>>> 
>>> Okay then the DCB on the open type=j is for the VTOC how about the 
>>> DCB for the RDJFCB The original DCB in my program was for VB Dataset 
>>> I hate bothering everybody is this documented anywhere i.e how to get 
>>> the deb of the VTOC
>>> 
>>> 
>>> Sent from my iPhone
>>> 
 On May 3, 2016, at 3:44 PM, J R  wrote:
 
 You should use BSAM, ie. READ, not GET, KEYLEN=44, BLKSIZE=140? (Not sure, 
 it's been a long time). Then read until you see your damage in the key 
 area. Or, if you are more adventurous, you could use BDAM and search 
 directly for the key you are interested in.
 
 Sent from my iPhone
 
> On May 3, 2016, at 15:11, michelbutz  wrote:
> 
> Something strange is bombed on the open Message IEC141I the dataset 
> it in the message is sys1.vtoc The DCB whose DSCB I am trying to 
> access is a VB have that  DCB on the open type=j
> 
> Sent from my iPhone
> 
>> On May 3, 2016, at 2:35 PM, J R  wrote:
>> 
>> Do the RDJFCB first, *then* move the 44X'4' to JFCBDSNM.
>> 
>> Sent from my iPhone
>> 
>>> On May 3, 2016, at 14:30, michelbutz  wrote:
>>> 
>>> I am still getting return code 4 in R15 CVSTAT is 8
>>> 
>>> I first move 44X'04' to JFCBDSNM
>>> I then do a READJFCB FILE
>>> Everything is okay I get R15 = 0
>>> I then do OPEN FILE,TYPE=J
>>> R15 = 0
>>> I then do ICM. R11,B'0111',DCBDEBA XC 
>>> BUFLIST(BFLHLN+BFLELN),BUFLIST OI  BFLHFL,BFLHDSCB MVI. BFLHNOE,1 
>>> LA. R6,DS1FMTID ST. R6,BFLEBUF OI.  BFLEFL,BFLECHR MVI.
>>> BFLELTH,DSCBLTH
>>> 
>>> CVAFDIR ACCESS=READ,DSN=DSN,BUFLIST=BUFLIST,DEB=(R11)
>>> 
>>> I get rerun code 4 in R15 and CVSTAT is 08 invalid DEB
>>> 
>>> Sent from my iPhone
>>> 
 On May 3, 2016, at 1:56 PM, J R  wrote:
 
 Nope.
 
 Sent from my iPhone
 
> On May 3, 2016, at 13:55, Staller, Allan 
>  wrote:
> 
> ITYM 44x'40'
> 
> 
> 
> So, as I posted before:
> 
> VTOC DSN is 44X'4'
> 
> 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
 
 
 -- 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 
>>> instructio

Re: Dataset space information

[Rob Scott]

If you need to find the space info for a single dataset - use CAMLST SEARCH to 
get the F1-DSCB and then CAMLST SEEK to process the F3-DSCBs.

For PDS/Es - you need to use FAMS (not a public interface).

For VSAM you can also use IGGCSI00

For bulk dataset info requests - you can use the DCOLLECT output and 
post-process it.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of michelbutz
Sent: Tuesday, May 3, 2016 9:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dataset space information

This all started by me trying to find out how space was taken by a dataset DSCB 
info which led me to CVAFDIR It needed the DEB of the VTOC Maybe I should of 
used OBTAIN/CAMLIST

Sent from my iPhone

> On May 3, 2016, at 4:09 PM, J R  wrote:
>
> The RDJFCB doesn't care too much about the DCB other than for the DDNAME and 
> where to put the copy of the JFCB.
>
> I'm not really sure what you're trying to do.  Unless you actually want to 
> access your dataset rather than its DSCB, why do you want to access the VTOC?
>
> Back in the '60s, this sort of thing was in the System Programmer's Guide.  
> It may be in Using Datasets or something similar now.
>
> However , you've lost me now.  I don't know why you need the DEB.  But you 
> should be able to get to it from the DCB.
>
> Sent from my iPhone
>
>> On May 3, 2016, at 15:54, michelbutz  wrote:
>>
>> Okay then the DCB on the open type=j is for the VTOC how about the
>> DCB for the RDJFCB The original DCB in my program was for VB Dataset
>> I hate bothering everybody is this documented anywhere i.e how to get
>> the deb of the VTOC
>>
>>
>> Sent from my iPhone
>>
>>> On May 3, 2016, at 3:44 PM, J R  wrote:
>>>
>>> You should use BSAM, ie. READ, not GET, KEYLEN=44, BLKSIZE=140? (Not sure, 
>>> it's been a long time). Then read until you see your damage in the key 
>>> area. Or, if you are more adventurous, you could use BDAM and search 
>>> directly for the key you are interested in.
>>>
>>> Sent from my iPhone
>>>
 On May 3, 2016, at 15:11, michelbutz  wrote:

 Something strange is bombed on the open Message IEC141I the dataset
 it in the message is sys1.vtoc The DCB whose DSCB I am trying to
 access is a VB have that  DCB on the open type=j

 Sent from my iPhone

> On May 3, 2016, at 2:35 PM, J R  wrote:
>
> Do the RDJFCB first, *then* move the 44X'4' to JFCBDSNM.
>
> Sent from my iPhone
>
>> On May 3, 2016, at 14:30, michelbutz  wrote:
>>
>> I am still getting return code 4 in R15 CVSTAT is 8
>>
>> I first move 44X'04' to JFCBDSNM
>> I then do a READJFCB FILE
>> Everything is okay I get R15 = 0
>> I then do OPEN FILE,TYPE=J
>> R15 = 0
>> I then do ICM. R11,B'0111',DCBDEBA XC
>> BUFLIST(BFLHLN+BFLELN),BUFLIST OI  BFLHFL,BFLHDSCB MVI. BFLHNOE,1
>> LA. R6,DS1FMTID ST. R6,BFLEBUF OI.  BFLEFL,BFLECHR MVI.
>> BFLELTH,DSCBLTH
>>
>> CVAFDIR ACCESS=READ,DSN=DSN,BUFLIST=BUFLIST,DEB=(R11)
>>
>> I get rerun code 4 in R15 and CVSTAT is 08 invalid DEB
>>
>> Sent from my iPhone
>>
>>> On May 3, 2016, at 1:56 PM, J R  wrote:
>>>
>>> Nope.
>>>
>>> Sent from my iPhone
>>>
 On May 3, 2016, at 13:55, Staller, Allan  
 wrote:

 ITYM 44x'40'

 

 So, as I posted before:

 VTOC DSN is 44X'4'

 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
>>>
>>> 
>>> -- 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: Dataset space information

[michelbutz]

This all started by me trying to find out how space was taken by a dataset DSCB 
info which led me to CVAFDIR
It needed the DEB of the VTOC 
Maybe I should of used OBTAIN/CAMLIST

Sent from my iPhone

> On May 3, 2016, at 4:09 PM, J R  wrote:
> 
> The RDJFCB doesn't care too much about the DCB other than for the DDNAME and 
> where to put the copy of the JFCB.  
> 
> I'm not really sure what you're trying to do.  Unless you actually want to 
> access your dataset rather than its DSCB, why do you want to access the VTOC? 
>  
> 
> Back in the '60s, this sort of thing was in the System Programmer's Guide.  
> It may be in Using Datasets or something similar now. 
> 
> However , you've lost me now.  I don't know why you need the DEB.  But you 
> should be able to get to it from the DCB.  
> 
> Sent from my iPhone
> 
>> On May 3, 2016, at 15:54, michelbutz  wrote:
>> 
>> Okay then the DCB on the open type=j is for the VTOC how about the DCB for 
>> the RDJFCB 
>> The original DCB in my program was for VB
>> Dataset 
>> I hate bothering everybody is this documented anywhere i.e how to get the 
>> deb of the VTOC 
>> 
>> 
>> Sent from my iPhone
>> 
>>> On May 3, 2016, at 3:44 PM, J R  wrote:
>>> 
>>> You should use BSAM, ie. READ, not GET, KEYLEN=44, BLKSIZE=140? (Not sure, 
>>> it's been a long time). Then read until you see your damage in the key 
>>> area. Or, if you are more adventurous, you could use BDAM and search 
>>> directly for the key you are interested in. 
>>> 
>>> Sent from my iPhone
>>> 
 On May 3, 2016, at 15:11, michelbutz  wrote:
 
 Something strange is bombed on the open 
 Message IEC141I the dataset it in the message is sys1.vtoc
 The DCB whose DSCB I am trying to access is a VB have that  DCB on the 
 open type=j 
 
 Sent from my iPhone
 
> On May 3, 2016, at 2:35 PM, J R  wrote:
> 
> Do the RDJFCB first, *then* move the 44X'4' to JFCBDSNM. 
> 
> Sent from my iPhone
> 
>> On May 3, 2016, at 14:30, michelbutz  wrote:
>> 
>> I am still getting return code 4 in R15 CVSTAT is 8
>> 
>> I first move 44X'04' to JFCBDSNM
>> I then do a READJFCB FILE
>> Everything is okay I get R15 = 0
>> I then do OPEN FILE,TYPE=J
>> R15 = 0
>> I then do ICM. R11,B'0111',DCBDEBA
>> XC BUFLIST(BFLHLN+BFLELN),BUFLIST
>> OI  BFLHFL,BFLHDSCB
>> MVI. BFLHNOE,1
>> LA. R6,DS1FMTID
>> ST. R6,BFLEBUF
>> OI.  BFLEFL,BFLECHR
>> MVI. BFLELTH,DSCBLTH
>> 
>> CVAFDIR ACCESS=READ,DSN=DSN,BUFLIST=BUFLIST,DEB=(R11)
>> 
>> I get rerun code 4 in R15 and CVSTAT is 08 invalid DEB
>> 
>> Sent from my iPhone
>> 
>>> On May 3, 2016, at 1:56 PM, J R  wrote:
>>> 
>>> Nope. 
>>> 
>>> Sent from my iPhone
>>> 
 On May 3, 2016, at 13:55, Staller, Allan  
 wrote:
 
 ITYM 44x'40'
 
 
 
 So, as I posted before:  
 
 VTOC DSN is 44X'4'
 
 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
>>> 
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>> 
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
>> --
>> 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 / arc

Re: Dataset space information

[J R]

The RDJFCB doesn't care too much about the DCB other than for the DDNAME and 
where to put the copy of the JFCB.  

I'm not really sure what you're trying to do.  Unless you actually want to 
access your dataset rather than its DSCB, why do you want to access the VTOC?  

Back in the '60s, this sort of thing was in the System Programmer's Guide.  It 
may be in Using Datasets or something similar now. 

However , you've lost me now.  I don't know why you need the DEB.  But you 
should be able to get to it from the DCB.  

Sent from my iPhone

> On May 3, 2016, at 15:54, michelbutz  wrote:
> 
> Okay then the DCB on the open type=j is for the VTOC how about the DCB for 
> the RDJFCB 
> The original DCB in my program was for VB
> Dataset 
> I hate bothering everybody is this documented anywhere i.e how to get the deb 
> of the VTOC 
> 
> 
> Sent from my iPhone
> 
>> On May 3, 2016, at 3:44 PM, J R  wrote:
>> 
>> You should use BSAM, ie. READ, not GET, KEYLEN=44, BLKSIZE=140? (Not sure, 
>> it's been a long time). Then read until you see your damage in the key area. 
>> Or, if you are more adventurous, you could use BDAM and search directly for 
>> the key you are interested in. 
>> 
>> Sent from my iPhone
>> 
>>> On May 3, 2016, at 15:11, michelbutz  wrote:
>>> 
>>> Something strange is bombed on the open 
>>> Message IEC141I the dataset it in the message is sys1.vtoc
>>> The DCB whose DSCB I am trying to access is a VB have that  DCB on the open 
>>> type=j 
>>> 
>>> Sent from my iPhone
>>> 
 On May 3, 2016, at 2:35 PM, J R  wrote:
 
 Do the RDJFCB first, *then* move the 44X'4' to JFCBDSNM. 
 
 Sent from my iPhone
 
> On May 3, 2016, at 14:30, michelbutz  wrote:
> 
> I am still getting return code 4 in R15 CVSTAT is 8
> 
> I first move 44X'04' to JFCBDSNM
> I then do a READJFCB FILE
> Everything is okay I get R15 = 0
> I then do OPEN FILE,TYPE=J
> R15 = 0
> I then do ICM. R11,B'0111',DCBDEBA
> XC BUFLIST(BFLHLN+BFLELN),BUFLIST
> OI  BFLHFL,BFLHDSCB
> MVI. BFLHNOE,1
> LA. R6,DS1FMTID
> ST. R6,BFLEBUF
> OI.  BFLEFL,BFLECHR
> MVI. BFLELTH,DSCBLTH
> 
> CVAFDIR ACCESS=READ,DSN=DSN,BUFLIST=BUFLIST,DEB=(R11)
> 
> I get rerun code 4 in R15 and CVSTAT is 08 invalid DEB
> 
> Sent from my iPhone
> 
>> On May 3, 2016, at 1:56 PM, J R  wrote:
>> 
>> Nope. 
>> 
>> Sent from my iPhone
>> 
>>> On May 3, 2016, at 13:55, Staller, Allan  
>>> wrote:
>>> 
>>> ITYM 44x'40'
>>> 
>>> 
>>> 
>>> So, as I posted before:  
>>> 
>>> VTOC DSN is 44X'4'
>>> 
>>> 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
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>> 
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> 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: Dataset space information

[michelbutz]

Okay then the DCB on the open type=j is for the VTOC how about the DCB for the 
RDJFCB 
The original DCB in my program was for VB
Dataset 
I hate bothering everybody is this documented anywhere i.e how to get the deb 
of the VTOC 


Sent from my iPhone

> On May 3, 2016, at 3:44 PM, J R  wrote:
> 
> You should use BSAM, ie. READ, not GET, KEYLEN=44, BLKSIZE=140? (Not sure, 
> it's been a long time). Then read until you see your damage in the key area. 
> Or, if you are more adventurous, you could use BDAM and search directly for 
> the key you are interested in. 
> 
> Sent from my iPhone
> 
>> On May 3, 2016, at 15:11, michelbutz  wrote:
>> 
>> Something strange is bombed on the open 
>> Message IEC141I the dataset it in the message is sys1.vtoc
>> The DCB whose DSCB I am trying to access is a VB have that  DCB on the open 
>> type=j 
>> 
>> Sent from my iPhone
>> 
>>> On May 3, 2016, at 2:35 PM, J R  wrote:
>>> 
>>> Do the RDJFCB first, *then* move the 44X'4' to JFCBDSNM. 
>>> 
>>> Sent from my iPhone
>>> 
 On May 3, 2016, at 14:30, michelbutz  wrote:
 
 I am still getting return code 4 in R15 CVSTAT is 8
 
 I first move 44X'04' to JFCBDSNM
 I then do a READJFCB FILE
 Everything is okay I get R15 = 0
 I then do OPEN FILE,TYPE=J
 R15 = 0
 I then do ICM. R11,B'0111',DCBDEBA
 XC BUFLIST(BFLHLN+BFLELN),BUFLIST
 OI  BFLHFL,BFLHDSCB
 MVI. BFLHNOE,1
 LA. R6,DS1FMTID
 ST. R6,BFLEBUF
 OI.  BFLEFL,BFLECHR
 MVI. BFLELTH,DSCBLTH
 
 CVAFDIR ACCESS=READ,DSN=DSN,BUFLIST=BUFLIST,DEB=(R11)
 
 I get rerun code 4 in R15 and CVSTAT is 08 invalid DEB
 
 Sent from my iPhone
 
> On May 3, 2016, at 1:56 PM, J R  wrote:
> 
> Nope. 
> 
> Sent from my iPhone
> 
>> On May 3, 2016, at 13:55, Staller, Allan  
>> wrote:
>> 
>> ITYM 44x'40'
>> 
>> 
>> 
>> So, as I posted before:  
>> 
>> VTOC DSN is 44X'4'
>> 
>> 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
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>> 
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Bypassing Duplicate DASD Volsers during zOS System IPL

[Mark Post]

>>> On 5/3/2016 at 02:54 PM, Jasi Grewal  wrote: 
> Greetings, Is there a way to have system bypass dasd volsers duplicates 
> during system IPL as I am aware, we can add in IODF as OFFLINE=YES but we 
> have many z/OS systems and many DASD which are duplicates.
> 
> These duplicates are being created by our zLinux Environments and we share 
> the same DASD Controller with them.
> Is there an easy way to have zOS System ignore duplicates and instead of 
> prompting with Duplicate replies.

Are these Linux systems running on z/VM as the hypervisor?  If so, stop 
DEDICATEing DASD volumes to them and make them minidisks from cylinder 1-END.  
That way, z/VM will be in control of the volser and z/OS shouldn't be seeing 
duplicates after that.

If they're not running as guests, but in an LPAR, then you should have your 
Linux support team update their DASD formatting process to include assigning a 
unique volser.


Mark Post

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

Re: Dataset space information

[J R]

dataset, not damage!  (Danged predictive text.)

Sent from my iPhone

> On May 3, 2016, at 15:45, J R  wrote:
> 
> You should use BSAM, ie. READ, not GET, KEYLEN=44, BLKSIZE=140? (Not sure, 
> it's been a long time). Then read until you see your damage in the key area. 
> Or, if you are more adventurous, you could use BDAM and search directly for 
> the key you are interested in. 
> 
> Sent from my iPhone
> 
>> On May 3, 2016, at 15:11, michelbutz  wrote:
>> 
>> Something strange is bombed on the open 
>> Message IEC141I the dataset it in the message is sys1.vtoc
>> The DCB whose DSCB I am trying to access is a VB have that  DCB on the open 
>> type=j 
>> 
>> Sent from my iPhone
>> 
>>> On May 3, 2016, at 2:35 PM, J R  wrote:
>>> 
>>> Do the RDJFCB first, *then* move the 44X'4' to JFCBDSNM. 
>>> 
>>> Sent from my iPhone
>>> 
 On May 3, 2016, at 14:30, michelbutz  wrote:
 
 I am still getting return code 4 in R15 CVSTAT is 8
 
 I first move 44X'04' to JFCBDSNM
 I then do a READJFCB FILE
 Everything is okay I get R15 = 0
 I then do OPEN FILE,TYPE=J
 R15 = 0
 I then do ICM. R11,B'0111',DCBDEBA
 XC BUFLIST(BFLHLN+BFLELN),BUFLIST
 OI  BFLHFL,BFLHDSCB
 MVI. BFLHNOE,1
 LA. R6,DS1FMTID
 ST. R6,BFLEBUF
 OI.  BFLEFL,BFLECHR
 MVI. BFLELTH,DSCBLTH
 
 CVAFDIR ACCESS=READ,DSN=DSN,BUFLIST=BUFLIST,DEB=(R11)
 
 I get rerun code 4 in R15 and CVSTAT is 08 invalid DEB
 
 Sent from my iPhone
 
> On May 3, 2016, at 1:56 PM, J R  wrote:
> 
> Nope. 
> 
> Sent from my iPhone
> 
>> On May 3, 2016, at 13:55, Staller, Allan  
>> wrote:
>> 
>> ITYM 44x'40'
>> 
>> 
>> 
>> So, as I posted before:  
>> 
>> VTOC DSN is 44X'4'
>> 
>> 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
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>> 
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Dataset space information

[J R]

You should use BSAM, ie. READ, not GET, KEYLEN=44, BLKSIZE=140? (Not sure, it's 
been a long time). Then read until you see your damage in the key area. Or, if 
you are more adventurous, you could use BDAM and search directly for the key 
you are interested in. 

Sent from my iPhone

> On May 3, 2016, at 15:11, michelbutz  wrote:
> 
> Something strange is bombed on the open 
> Message IEC141I the dataset it in the message is sys1.vtoc
> The DCB whose DSCB I am trying to access is a VB have that  DCB on the open 
> type=j 
> 
> Sent from my iPhone
> 
>> On May 3, 2016, at 2:35 PM, J R  wrote:
>> 
>> Do the RDJFCB first, *then* move the 44X'4' to JFCBDSNM. 
>> 
>> Sent from my iPhone
>> 
>>> On May 3, 2016, at 14:30, michelbutz  wrote:
>>> 
>>> I am still getting return code 4 in R15 CVSTAT is 8
>>> 
>>> I first move 44X'04' to JFCBDSNM
>>> I then do a READJFCB FILE
>>> Everything is okay I get R15 = 0
>>> I then do OPEN FILE,TYPE=J
>>> R15 = 0
>>> I then do ICM. R11,B'0111',DCBDEBA
>>> XC BUFLIST(BFLHLN+BFLELN),BUFLIST
>>> OI  BFLHFL,BFLHDSCB
>>> MVI. BFLHNOE,1
>>> LA. R6,DS1FMTID
>>> ST. R6,BFLEBUF
>>> OI.  BFLEFL,BFLECHR
>>> MVI. BFLELTH,DSCBLTH
>>> 
>>> CVAFDIR ACCESS=READ,DSN=DSN,BUFLIST=BUFLIST,DEB=(R11)
>>> 
>>> I get rerun code 4 in R15 and CVSTAT is 08 invalid DEB
>>> 
>>> Sent from my iPhone
>>> 
 On May 3, 2016, at 1:56 PM, J R  wrote:
 
 Nope. 
 
 Sent from my iPhone
 
> On May 3, 2016, at 13:55, Staller, Allan  
> wrote:
> 
> ITYM 44x'40'
> 
> 
> 
> So, as I posted before:  
> 
> VTOC DSN is 44X'4'
> 
> 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
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>> 
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Helpful tip for z/OS consultants

[R.S.]

W dniu 2016-05-03 o 21:06, Itschak Mugzach pisze:

I agree with John. This is a management decision and it will be done with
you or with any other consultant. so, shouldn't it be you?

It depends.
There are activities which are 100% legal, but your conscience have 
objections. I'd prefer to not be an executioner if possible. Of course 
there's another approach: what will my family eat tomorrow?

Last, but not least, sometimes you don't know a priori how the things are.

--
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: Dataset space information

[michelbutz]

Something strange is bombed on the open 
Message IEC141I the dataset it in the message is sys1.vtoc
The DCB whose DSCB I am trying to access is a VB have that  DCB on the open 
type=j 

Sent from my iPhone

> On May 3, 2016, at 2:35 PM, J R  wrote:
> 
> Do the RDJFCB first, *then* move the 44X'4' to JFCBDSNM. 
> 
> Sent from my iPhone
> 
>> On May 3, 2016, at 14:30, michelbutz  wrote:
>> 
>> I am still getting return code 4 in R15 CVSTAT is 8
>> 
>> I first move 44X'04' to JFCBDSNM
>> I then do a READJFCB FILE
>> Everything is okay I get R15 = 0
>> I then do OPEN FILE,TYPE=J
>> R15 = 0
>> I then do ICM. R11,B'0111',DCBDEBA
>> XC BUFLIST(BFLHLN+BFLELN),BUFLIST
>> OI  BFLHFL,BFLHDSCB
>> MVI. BFLHNOE,1
>> LA. R6,DS1FMTID
>> ST. R6,BFLEBUF
>> OI.  BFLEFL,BFLECHR
>> MVI. BFLELTH,DSCBLTH
>> 
>> CVAFDIR ACCESS=READ,DSN=DSN,BUFLIST=BUFLIST,DEB=(R11)
>> 
>> I get rerun code 4 in R15 and CVSTAT is 08 invalid DEB
>> 
>> Sent from my iPhone
>> 
>>> On May 3, 2016, at 1:56 PM, J R  wrote:
>>> 
>>> Nope. 
>>> 
>>> Sent from my iPhone
>>> 
 On May 3, 2016, at 13:55, Staller, Allan  
 wrote:
 
 ITYM 44x'40'
 
 
 
 So, as I posted before:  
 
 VTOC DSN is 44X'4'
 
 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
>>> 
>>> --
>>> 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: Helpful tip for z/OS consultants

[Itschak Mugzach]

I agree with John. This is a management decision and it will be done with
you or with any other consultant. so, shouldn't it be you?

ITschak

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

On Tue, May 3, 2016 at 8:52 PM, John Mattson 
wrote:

> Much like any job you take, so much depends on the corporate culture,
> personalities, as well as the situation.  I am working happily in a
> decommissioning situation where their interests and mine match very well.
> Were I to give advice to someone entering such a job, I would say insist on
> knowing who you will be working with, their "fate", and that they be
> included in the interview, or you at least meet them before committing.  It
> is a reasonable request.   As to their resenting you, that is illogical, as
> Spock would say.  I have been displaced myself, but I did not blame the
> workers who were just trying to have jobs themselves.  Blame, if any, goes
> on management, not you.  I suspect this was a very unhappy shop before any
> of this happened.
>
> --
> 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

Bypassing Duplicate DASD Volsers during zOS System IPL

[Jasi Grewal]

Greetings, Is there a way to have system bypass dasd volsers duplicates during 
system IPL as I am aware, we can add in IODF as OFFLINE=YES but we have many 
z/OS systems and many DASD which are duplicates.

These duplicates are being created by our zLinux Environments and we share the 
same DASD Controller with them.
Is there an easy way to have zOS System ignore duplicates and instead of 
prompting with Duplicate replies.

Any advise would be appreciate it.
Thank you in advance,

Jasi Grewal.

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

Re: Inside the Secret Meeting Where Wall Street Tested Digital Cash (Blockchain)

[Rob Schramm]

Except the comment is more about expert system interventions (custom
software, paper, tape histories, people) in transactions and moving to a
system that utilizes blockchain to replace "mainframe era" operations.  My
own experience in banking, indicates that the process is still full of
processes, people & paper driven.  Blockchain may provide not only a way to
move money without single points of failure (auditing etc), but contain
very complicated relationships under better security/audits and movement
thru systems.

Rob Schramm

On Mon, May 2, 2016 at 12:18 PM Mark Regan  wrote:

>
> http://www.bloomberg.com/news/articles/2016-05-02/inside-the-secret-meeting-where-wall-street-tested-digital-cash
> Them seem to forget that the zSystem can do Blockchain too.
>
>
> http://www.ibmsystemsmag.com/mainframe/trends/IBM-Announcements/z-Systems_LinuxONE_Blockchain/
>
> From the Bloomberg article:
> ‘Mainframe Era’
>
> Nasdaq and Citigroup partnered to explore how they can work together, said
> Brad Peterson, the exchange-owner’s chief information officer. He said
> blockchain also could be used for reference data -- how specific stocks or
> bonds are identified across all markets, for example.
>
> Wall Street was one of the earliest beneficiaries of computers replacing
> office systems. Now 30 years later, those legacy systems can be a hindrance
> to further technological evolution, he said.
>
> “That’s the great opportunity -- how to unlock that ability to work your
> way out from under the mainframe era,” he said.
>
> --
> 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: Rexx EXEC SHOWALC Panel Member

[Richards, Robert B.]

Thanks Ren. I'll check it out.

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brenton, Ren
Sent: Tuesday, May 03, 2016 2:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Rexx EXEC SHOWALC Panel Member

All I have is a CLIST, sorry:  But here it is:

PROC 0 
   
/*  SYSTEM.SP.CLIST(SHOWALC)   
/*  04-20-93   
/*  DISPLAYS SYSTEM ALLOCATED FILES - ABLE TO BROWSE/EDIT THRU ISPF */ 
   
ISPEXEC TBCREATE TSODD NAMES(SDDNAME SDSN SDISP) NOWRITE REPLACE   
   
SET SYSOUTTRAP = 1000  
LISTALC STATUS SYSNAMES
SET SYSOUTTRAP = 0 
SET LINECOUNT  = &SYSOUTLINE   
SET SDSN   = &STR()
SET I  = 1 
   
DO WHILE &I <= &LINECOUNT  
  SET CURLINE = &&SYSOUTLINE&I 
  SET PARSED  = NO 
  SET LINELEN = &LENGTH(&STR(&CURLINE))
  IF &STR(&CURLINE) ¬= &STR() THEN DO  
IF &LINELEN >= 12 THEN DO  
  IF &SUBSTR(1:2,&STR(&CURLINE)) = &STR(  ) THEN DO
SET PARSED  = YES  
SET SDDNAME = &SUBSTR(3:10,&STR(&CURLINE))
SET SDISP   = &SUBSTR(12:&LINELEN,&STR(&CURLINE)) 
ISPEXEC TBADD TSODD   
SET SDSN = &STR() 
  END 
END   
IF &PARSED = NO THEN DO   
  IF &LINELEN >= 11 THEN DO   
IF &SUBSTR(1:10,&STR(&CURLINE)) = &STR(TERMFILE  ) THEN DO
  SET PARSED  = YES   
  SET SDDNAME = &SUBSTR(11:&LINELEN,&STR(&CURLINE))   
  SET SDSN= &STR((TERMINAL))  
  SET SDISP   = &STR(*)   
  ISPEXEC TBADD TSODD 
  SET SDSN = &STR()   
END   
  END 
END   
IF &PARSED = NO THEN DO   
  SET SDSN = &STR(&CURLINE)   
END   
  END 
  SET I = &I + 1  
END   
  
ISPEXEC TBTOP TSODD   
SET OLDCRP = 0
SET DONE   = NO   
DO WHILE &DONE = NO   
  SET SELDSN = &STR() 
  ISPEXEC CONTROL DISPLAY REFRESH 
  ISPEXEC TBDISPL TSODD PANEL(SHOWALC) CSRROW(&OLDCRP) +  
AUTOSEL(NO) POSITION(CRPNUM)  
  IF &STR(&SELDSN) = &STR() THEN DO   
SET DONE = YES
  END 
  ELSE DO 
SET OLDCRP  = &CRPNUM 
SET SKIPNUM = &ZTDTOP - &CRPNUM   
ISPEXEC TBSKIP TSODD NUMBER(&SKIPNUM) NOREAD  
IF &SUBSTR(1:1,&STR(&SELDSN)) = &STR(*) THEN DO   
  SET SELDSN = &SUBSTR(2:&LENGTH(&STR(&SELDSN)),&STR(&SELDSN))
END   
IF &STR(&SELDSN) = &STR((TERMINAL)) THEN DO   
  SET ZEDSMSG = &STR(ALLOCATED TO TERMINAL)   
  SET

Re: Dataset space information

[J R]

Do the RDJFCB first, *then* move the 44X'4' to JFCBDSNM. 

Sent from my iPhone

> On May 3, 2016, at 14:30, michelbutz  wrote:
> 
> I am still getting return code 4 in R15 CVSTAT is 8
> 
> I first move 44X'04' to JFCBDSNM
> I then do a READJFCB FILE
> Everything is okay I get R15 = 0
> I then do OPEN FILE,TYPE=J
> R15 = 0
> I then do ICM. R11,B'0111',DCBDEBA
> XC BUFLIST(BFLHLN+BFLELN),BUFLIST
> OI  BFLHFL,BFLHDSCB
> MVI. BFLHNOE,1
> LA. R6,DS1FMTID
> ST. R6,BFLEBUF
> OI.  BFLEFL,BFLECHR
> MVI. BFLELTH,DSCBLTH
> 
> CVAFDIR ACCESS=READ,DSN=DSN,BUFLIST=BUFLIST,DEB=(R11)
> 
> I get rerun code 4 in R15 and CVSTAT is 08 invalid DEB
> 
> Sent from my iPhone
> 
>> On May 3, 2016, at 1:56 PM, J R  wrote:
>> 
>> Nope. 
>> 
>> Sent from my iPhone
>> 
>>> On May 3, 2016, at 13:55, Staller, Allan  
>>> wrote:
>>> 
>>> ITYM 44x'40'
>>> 
>>> 
>>> 
>>> So, as I posted before:  
>>> 
>>> VTOC DSN is 44X'4'
>>> 
>>> 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
>> 
>> --
>> 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: Scheduled STCs running as instream procs?

[Lindy Mayfield]

That was the message I got.  And I forget exactly but $DPROCLIB gave me I think 
something like MSTJCL00, MSTJCL01, then some dataset names.

Cancelling a started task caused it to start right up again. 

So my problem was that normally I can work backwards on MVS to find the source 
code of the STC, but here I couldn't.  Some automation software was in control, 
and that instream message was new to me.  

If I was smarter I could have a) figured out where/how MSTJCLxx was allocated, 
b) figure out what automation software was used (probably Tivoli or one of 
those), or c) found somebody who knew. 

I honestly had to write a simple Rexx program to look at the control blocks to 
show what security program was being used, even though I was told and it was 
clear it was RACF.  I just saw too many messages starting ACF9, and hardly 
any ICH so perhaps they had major message suppression going on there that 
I'd never seen before. 

Br, 
Lindy

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dan D
Sent: tiistaina 3. toukokuuta 2016 20.58
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Scheduled STCs running as instream procs?


Willy,

If you look at the SYSMSGS of a started job you will still see ...
3 IEFC001I PROCEDURE procname WAS EXPANDED USING INSTREAM PROCEDURE
DEFINITION  

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

Re: Rexx EXEC SHOWALC Panel Member

[Brenton, Ren]

All I have is a CLIST, sorry:  But here it is:

PROC 0 
   
/*  SYSTEM.SP.CLIST(SHOWALC)   
/*  04-20-93   
/*  DISPLAYS SYSTEM ALLOCATED FILES - ABLE TO BROWSE/EDIT THRU ISPF */ 
   
ISPEXEC TBCREATE TSODD NAMES(SDDNAME SDSN SDISP) NOWRITE REPLACE   
   
SET SYSOUTTRAP = 1000  
LISTALC STATUS SYSNAMES
SET SYSOUTTRAP = 0 
SET LINECOUNT  = &SYSOUTLINE   
SET SDSN   = &STR()
SET I  = 1 
   
DO WHILE &I <= &LINECOUNT  
  SET CURLINE = &&SYSOUTLINE&I 
  SET PARSED  = NO 
  SET LINELEN = &LENGTH(&STR(&CURLINE))
  IF &STR(&CURLINE) ¬= &STR() THEN DO  
IF &LINELEN >= 12 THEN DO  
  IF &SUBSTR(1:2,&STR(&CURLINE)) = &STR(  ) THEN DO
SET PARSED  = YES  
SET SDDNAME = &SUBSTR(3:10,&STR(&CURLINE))
SET SDISP   = &SUBSTR(12:&LINELEN,&STR(&CURLINE)) 
ISPEXEC TBADD TSODD   
SET SDSN = &STR() 
  END 
END   
IF &PARSED = NO THEN DO   
  IF &LINELEN >= 11 THEN DO   
IF &SUBSTR(1:10,&STR(&CURLINE)) = &STR(TERMFILE  ) THEN DO
  SET PARSED  = YES   
  SET SDDNAME = &SUBSTR(11:&LINELEN,&STR(&CURLINE))   
  SET SDSN= &STR((TERMINAL))  
  SET SDISP   = &STR(*)   
  ISPEXEC TBADD TSODD 
  SET SDSN = &STR()   
END   
  END 
END   
IF &PARSED = NO THEN DO   
  SET SDSN = &STR(&CURLINE)   
END   
  END 
  SET I = &I + 1  
END   
  
ISPEXEC TBTOP TSODD   
SET OLDCRP = 0
SET DONE   = NO   
DO WHILE &DONE = NO   
  SET SELDSN = &STR() 
  ISPEXEC CONTROL DISPLAY REFRESH 
  ISPEXEC TBDISPL TSODD PANEL(SHOWALC) CSRROW(&OLDCRP) +  
AUTOSEL(NO) POSITION(CRPNUM)  
  IF &STR(&SELDSN) = &STR() THEN DO   
SET DONE = YES
  END 
  ELSE DO 
SET OLDCRP  = &CRPNUM 
SET SKIPNUM = &ZTDTOP - &CRPNUM   
ISPEXEC TBSKIP TSODD NUMBER(&SKIPNUM) NOREAD  
IF &SUBSTR(1:1,&STR(&SELDSN)) = &STR(*) THEN DO   
  SET SELDSN = &SUBSTR(2:&LENGTH(&STR(&SELDSN)),&STR(&SELDSN))
END   
IF &STR(&SELDSN) = &STR((TERMINAL)) THEN DO   
  SET ZEDSMSG = &STR(ALLOCATED TO TERMINAL)   
  SET ZEDLMSG = &STR(THE TERMINAL CANNOT BE BROWSED.) 
  ISPEXEC SETMSG MSG(ISRZ001) 
END   
ELSE DO   
  CONTROL NO

Re: Dataset space information

[michelbutz]

I am still getting return code 4 in R15 CVSTAT is 8

I first move 44X'04' to JFCBDSNM
I then do a READJFCB FILE
Everything is okay I get R15 = 0
I then do OPEN FILE,TYPE=J
R15 = 0
I then do ICM. R11,B'0111',DCBDEBA
XC BUFLIST(BFLHLN+BFLELN),BUFLIST
OI  BFLHFL,BFLHDSCB
MVI. BFLHNOE,1
LA. R6,DS1FMTID
ST. R6,BFLEBUF
OI.  BFLEFL,BFLECHR
MVI. BFLELTH,DSCBLTH

CVAFDIR ACCESS=READ,DSN=DSN,BUFLIST=BUFLIST,DEB=(R11)

I get rerun code 4 in R15 and CVSTAT is 08 invalid DEB

Sent from my iPhone

> On May 3, 2016, at 1:56 PM, J R  wrote:
> 
> Nope. 
> 
> Sent from my iPhone
> 
>> On May 3, 2016, at 13:55, Staller, Allan  wrote:
>> 
>> ITYM 44x'40'
>> 
>> 
>> 
>> So, as I posted before:  
>> 
>> VTOC DSN is 44X'4'
>> 
>> 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
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Rexx EXEC SHOWALC Panel Member

[Richards, Robert B.]

Now that we have the panel, I'm missing the EXEC!  :-)

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brenton, Ren
Sent: Tuesday, May 03, 2016 1:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Rexx EXEC SHOWALC Panel Memeber

Here is the panel we have for SHOWALC:

)ATTR FORMAT(MIX)
  @ TYPE(OUTPUT) INTENS(LOW)  CAPS(OFF)
  ! TYPE(INPUT)  INTENS(HIGH) CAPS(ON) PAD(_) )BODY
+SHOWALC --%CURRENT TSO DATASET ALLOCATIONS+---
+   &ZDATE  &ZTIME
%COMMAND ===>_ZCMD%SCROLL%===>_VSVS
+
%SEL   DD NAMEDATASET NAMES IN ORDER OF CONCATENATIONDISPOSITION
+---      -----
)MODEL
 !X+  @SDDNAME   @SDSN  @SDISP
)INIT
  &X = ' '
  IF (&VSVS = '')
&VSVS = 'PAGE'
)REINIT
)PROC
  IF (&ZTDSELS ¬= )
&SELDSN = &SDSN
  VPUT (VSVS) PROFILE
)END


Ren
Ext 1448


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of George Rodriguez
Sent: Tuesday, May 03, 2016 9:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Rexx EXEC SHOWALC Panel Memeber

Is there someone that knows anything about this EXEC? I'm missing the panel 
member for the EXEC.

*George Rodriguez*
*Specialist II - IT Solutions*
*IT Enterprise Applications*
*PX - 47652*
*(561) 357-7652 (office)*
*(954) 415-7586 (mobile)*
*School District of Palm Beach County*
*3348 Forest Hill Blvd.*
*Room B-251*
*West Palm Beach, FL. 33406-5869*
*Florida's Only A-Rated Urban District For Eight Consecutive Years*

--


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


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

The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.


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

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

Re: Rexx EXEC SHOWALC Panel Memeber

[George Rodriguez]

Thanks Ren! You're the BEST!


*George Rodriguez*
*Specialist II - IT Solutions*
*IT Enterprise Applications*
*PX - 47652*
*(561) 357-7652 (office)*
*(954) 415-7586 (mobile)*
*School District of Palm Beach County*
*3348 Forest Hill Blvd.*
*Room B-251*
*West Palm Beach, FL. 33406-5869*
*Florida's Only A-Rated Urban District For Eight Consecutive Years*

On Tue, May 3, 2016 at 1:24 PM, Brenton, Ren  wrote:

> Here is the panel we have for SHOWALC:
>
> )ATTR FORMAT(MIX)
>   @ TYPE(OUTPUT) INTENS(LOW)  CAPS(OFF)
>   ! TYPE(INPUT)  INTENS(HIGH) CAPS(ON) PAD(_)
> )BODY
> +SHOWALC --%CURRENT TSO DATASET
> ALLOCATIONS+---
> +   &ZDATE  &ZTIME
> %COMMAND ===>_ZCMD
> %SCROLL%===>_VSVS
> +
> %SEL   DD NAMEDATASET NAMES IN ORDER OF CONCATENATION
> DISPOSITION
> +---      ---
> --
> )MODEL
>  !X+  @SDDNAME   @SDSN  @SDISP
> )INIT
>   &X = ' '
>   IF (&VSVS = '')
> &VSVS = 'PAGE'
> )REINIT
> )PROC
>   IF (&ZTDSELS ¬= )
> &SELDSN = &SDSN
>   VPUT (VSVS) PROFILE
> )END
>
>
> Ren
> Ext 1448
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of George Rodriguez
> Sent: Tuesday, May 03, 2016 9:56 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Rexx EXEC SHOWALC Panel Memeber
>
> Is there someone that knows anything about this EXEC? I'm missing the
> panel member for the EXEC.
>
> *George Rodriguez*
> *Specialist II - IT Solutions*
> *IT Enterprise Applications*
> *PX - 47652*
> *(561) 357-7652 (office)*
> *(954) 415-7586 (mobile)*
> *School District of Palm Beach County*
> *3348 Forest Hill Blvd.*
> *Room B-251*
> *West Palm Beach, FL. 33406-5869*
> *Florida's Only A-Rated Urban District For Eight Consecutive Years*
>
> --
>
>
> *Disclaimer: *Under Florida law, e-mail addresses are public records. If
> you do not want your e-mail address released in response to a public
> records request, do not send electronic mail to this entity. Instead,
> contact this office by phone or in writing.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the
> message: INFO IBM-MAIN
>
> The information contained in this message is proprietary and/or
> confidential. If you are not the intended recipient, please: (i) delete the
> message and all copies; (ii) do not disclose, distribute or use the message
> in any manner; and (iii) notify the sender immediately. In addition, please
> be aware that any message addressed to our domain is subject to archiving
> and review by persons other than the intended recipient. Thank you.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

-- 


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


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

Re: Scheduled STCs running as instream procs?

[Dan D]

"Willy Jensen" wrote ...
> A started job will not tell you from where it came. On the other hand, it
will also not say instream.
> 
> Willy 
> 

Willy,

If you look at the SYSMSGS of a started job you will still see ...
3 IEFC001I PROCEDURE procname WAS EXPANDED USING INSTREAM PROCEDURE
DEFINITION  
Or 
2 IEFC001I PROCEDURE procname WAS EXPANDED USING SYSTEM LIBRARY dataset-name
I even got one to use a JCLLIB statement ...
4 IEFC001I PROCEDURE procname WAS EXPANDED USING PRIVATE LIBRARY
dataset-name

The trick is to programmatically READ sysmsgs.

DanD

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

Re: Dataset space information

[J R]

Nope. 

Sent from my iPhone

> On May 3, 2016, at 13:55, Staller, Allan  wrote:
> 
> ITYM 44x'40'
> 
> 
> 
> So, as I posted before:  
> 
> VTOC DSN is 44X'4'
> 
> 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

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

Re: Dataset space information

[Staller, Allan]

ITYM 44x'40'



So, as I posted before:  

VTOC DSN is 44X'4'

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: Helpful tip for z/OS consultants

[John Mattson]

Much like any job you take, so much depends on the corporate culture,
personalities, as well as the situation.  I am working happily in a
decommissioning situation where their interests and mine match very well.
Were I to give advice to someone entering such a job, I would say insist on
knowing who you will be working with, their "fate", and that they be
included in the interview, or you at least meet them before committing.  It
is a reasonable request.   As to their resenting you, that is illogical, as
Spock would say.  I have been displaced myself, but I did not blame the
workers who were just trying to have jobs themselves.  Blame, if any, goes
on management, not you.  I suspect this was a very unhappy shop before any
of this happened.

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

Re: Dataset space information

[J R]

So, as I posted before:  

VTOC DSN is 44X'4'

Sent from my iPhone

> On May 3, 2016, at 12:55, John McKown  wrote:
> 
>> On Tue, May 3, 2016 at 11:39 AM, michelbutz  wrote:
>> 
>> I have seen examples in the DFSMS advanced services using CVAFDIR one of
>> the parameters is the DEB of the VTOC is there a way to get that
>> Normally when you open a dataset its in the DCB
>> 
>> ​
> 
> The data extent block (DEB) can be obtained by opening a DCB for INPUT,
> using the RDJFCB and OPEN TYPE=J macros. (After issuing an OPEN TYPE=J
> macro, the DCB's DCBDEBA field contains the DEB's address.) The DCB's
> DDNAME must identify a DD statement allocated to the unit whose VTOC is to
> be accessed. Once your program issues the RDJFCB macro, it must initialize
> the JFCBDSNM field with the data set name of the format-4 DSCB: 44 bytes of
> X'04'. The RDJFCB macro is described under RDJFCB Macro Specification
> ;
> the OPEN macro is described under OPEN - Initialize Data Control Block for
> Processing the JFCB
> 
> . For an extended address volume the DCB macro must point to a DCBE where
> the EADSCB=OK keyword is specified. If you do not code this option, the
> OPEN function will issue ABEND 113-48 and message IEC142I.
> 
> ​
> 
> 
> 
> So you need to ​allocate the volume​, either with JCL or DYNALLOC, and
> specify both DISP=SHR and VOL=SER=aa. One convention is to use a data
> set name of FORMAT4.DSCB as the DSN, e.g.
> 
> //VTOC DD DISP=SHR,UNIT=SYSALLDA,VOL=SER=aa,DSN=FORMAT4.DSCB
> 
> You have a DCB with a DDNAME=VTOC. You do a RDJFCB on the DD. You then
> modify the data set name in the returned.
> 
> 
> 
> 
>   - Changing the data set name field or member field in the JFCB. See RDJFCB
>   Security
>   
> 
>and RDJFCB Use by Authorized Programs
>   
> .
>   You can open a VTOC by reading the JFCB, changing the data set name to 44
>   bytes of X'04' and then issuing the OPEN macro with TYPE=J. Use BSAM or
>   EXCP. If you use BSAM, also code RECFM=F, KEYLEN=44 and BLKSIZE=96 on the
>   DCB macro. For an extended address volume the DCB macro must point to a
>   DCBE where the EADSCB=OK keyword is specified. You'll find examples of
>   opening an EXCP DCB for a VTOC in Example of Using the CVAFFILT Macro
>   
> 
>andExample of using the CVAFSEQ macro to process a volume in physical
>   sequential order
>   
> 
>   .
> 
> 
> 
> 
> 
> -- 
> The unfacts, did we have them, are too imprecisely few to warrant our
> certitude.
> 
> Maranatha! <><
> John McKown
> 
> --
> 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: SRB dispatching question

[Ed Jaffe]

On 5/3/2016 4:50 AM, Peter Relson wrote:

The system will no longer treat it as such after the pause.


So the "globalness" of an SRB is an attribute known only at scheduling 
time and not something saved/restored in an SSRB? Good to know...


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

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

Re: Rexx EXEC SHOWALC Panel Memeber

[Brenton, Ren]

Here is the panel we have for SHOWALC:

)ATTR FORMAT(MIX)
  @ TYPE(OUTPUT) INTENS(LOW)  CAPS(OFF)
  ! TYPE(INPUT)  INTENS(HIGH) CAPS(ON) PAD(_)
)BODY
+SHOWALC --%CURRENT TSO DATASET ALLOCATIONS+---
+   &ZDATE  &ZTIME
%COMMAND ===>_ZCMD%SCROLL%===>_VSVS
+
%SEL   DD NAMEDATASET NAMES IN ORDER OF CONCATENATIONDISPOSITION
+---      -----
)MODEL
 !X+  @SDDNAME   @SDSN  @SDISP
)INIT
  &X = ' '
  IF (&VSVS = '')
&VSVS = 'PAGE'
)REINIT
)PROC
  IF (&ZTDSELS ¬= )
&SELDSN = &SDSN
  VPUT (VSVS) PROFILE
)END


Ren
Ext 1448


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of George Rodriguez
Sent: Tuesday, May 03, 2016 9:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Rexx EXEC SHOWALC Panel Memeber

Is there someone that knows anything about this EXEC? I'm missing the panel 
member for the EXEC.

*George Rodriguez*
*Specialist II - IT Solutions*
*IT Enterprise Applications*
*PX - 47652*
*(561) 357-7652 (office)*
*(954) 415-7586 (mobile)*
*School District of Palm Beach County*
*3348 Forest Hill Blvd.*
*Room B-251*
*West Palm Beach, FL. 33406-5869*
*Florida's Only A-Rated Urban District For Eight Consecutive Years*

--


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


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

The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.


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

Re: Dataset space information

[John McKown]

On Tue, May 3, 2016 at 11:39 AM, michelbutz  wrote:

> I have seen examples in the DFSMS advanced services using CVAFDIR one of
> the parameters is the DEB of the VTOC is there a way to get that
> Normally when you open a dataset its in the DCB
>
> ​

The data extent block (DEB) can be obtained by opening a DCB for INPUT,
using the RDJFCB and OPEN TYPE=J macros. (After issuing an OPEN TYPE=J
macro, the DCB's DCBDEBA field contains the DEB's address.) The DCB's
DDNAME must identify a DD statement allocated to the unit whose VTOC is to
be accessed. Once your program issues the RDJFCB macro, it must initialize
the JFCBDSNM field with the data set name of the format-4 DSCB: 44 bytes of
X'04'. The RDJFCB macro is described under RDJFCB Macro Specification
;
the OPEN macro is described under OPEN - Initialize Data Control Block for
Processing the JFCB

. For an extended address volume the DCB macro must point to a DCBE where
the EADSCB=OK keyword is specified. If you do not code this option, the
OPEN function will issue ABEND 113-48 and message IEC142I.

​



So you need to ​allocate the volume​, either with JCL or DYNALLOC, and
specify both DISP=SHR and VOL=SER=aa. One convention is to use a data
set name of FORMAT4.DSCB as the DSN, e.g.

//VTOC DD DISP=SHR,UNIT=SYSALLDA,VOL=SER=aa,DSN=FORMAT4.DSCB

You have a DCB with a DDNAME=VTOC. You do a RDJFCB on the DD. You then
modify the data set name in the returned.




   - Changing the data set name field or member field in the JFCB. See RDJFCB
   Security
   

and RDJFCB Use by Authorized Programs
   
.
   You can open a VTOC by reading the JFCB, changing the data set name to 44
   bytes of X'04' and then issuing the OPEN macro with TYPE=J. Use BSAM or
   EXCP. If you use BSAM, also code RECFM=F, KEYLEN=44 and BLKSIZE=96 on the
   DCB macro. For an extended address volume the DCB macro must point to a
   DCBE where the EADSCB=OK keyword is specified. You'll find examples of
   opening an EXCP DCB for a VTOC in Example of Using the CVAFFILT Macro
   

andExample of using the CVAFSEQ macro to process a volume in physical
   sequential order
   

   .





-- 
The unfacts, did we have them, are too imprecisely few to warrant our
certitude.

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: Dataset space information

[michelbutz]

I have seen examples in the DFSMS advanced services using CVAFDIR one of the 
parameters is the DEB of the VTOC is there a way to get that 
Normally when you open a dataset its in the DCB

Sent from my iPhone

> On May 3, 2016, at 12:15 PM, John McKown  wrote:
> 
>> On Tue, May 3, 2016 at 10:54 AM, michelbutz  wrote:
>> 
>> I am sorry dont understand what is the VTOC
>> Dataset name, there is another dataset on that volume sys1.vvds.v
>> concentrated to the volser
> 
> ​SYS1.VTOCIX.aa (aa is _normally_ the same as the volser, but need
> not necessarily be) is a _index_ into the actual VTOC itself. It does not
> contain the VTOC information.
> SYS1.VVDS.Vaa (aa, again, is _normally_ the same as the volser, but
> need not necessarily be) is a VSAM-like data set which contains SMS
> information for data sets in the VTOC.
> 
> The VTOC is the Volume Table Of Contents. IT IS NOT A DATA SET!!! It does
> _not_ show up in a VTOC listing of data sets on a volume. The VOL1 record
> on a volume contains a field which points to where the VTOC exists. The
> VTOC is "self described" in the type 4 VTOC record. The VTOC most closely
> resembles a keyed BDAM data set (remember, it's not a data set!) which has
> a 44 byte hardware key. The hardware key is the same as the DSN. For the
> VTOC, the hardware key is 44x'04', that is 44 repetitions of the hex value
> x'04'. When z/OS processes the VARY ONLINE command for a DASD device, it
> reads the VOL1 record. This validates the volume serial is unique and it
> then stores the address of the VTOC in the UCB for other users, such as
> DADSM allocation.​
> 
> ​I don't know what you want to do, but personally, I prefer using the
> output from the IDCAMS DCOLLECT command for data set information. Of
> course, it is not useful for a "one off" data set requirement. If you want
> a VTOC mapping of where data sets reside on a volume, for some reason, then
> using ADRDSSU with a PARM='TYPRUN=NORUN' and a DEFRAG command will get you
> a fairly nice listing.
> 
> You could also do a IEHLIST of the volume.
> 
> ​Oh, and I also use the REXX / TSO LISTDSI command for data set information
> retrieval.​
> 
> 
> -- 
> The unfacts, did we have them, are too imprecisely few to warrant our
> certitude.
> 
> Maranatha! <><
> John McKown
> 
> --
> 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: Dataset space information

[John McKown]

On Tue, May 3, 2016 at 10:54 AM, michelbutz  wrote:

> I am sorry dont understand what is the VTOC
> Dataset name, there is another dataset on that volume sys1.vvds.v
> concentrated to the volser
>

​SYS1.VTOCIX.aa (aa is _normally_ the same as the volser, but need
not necessarily be) is a _index_ into the actual VTOC itself. It does not
contain the VTOC information.
SYS1.VVDS.Vaa (aa, again, is _normally_ the same as the volser, but
need not necessarily be) is a VSAM-like data set which contains SMS
information for data sets in the VTOC.

The VTOC is the Volume Table Of Contents. IT IS NOT A DATA SET!!! It does
_not_ show up in a VTOC listing of data sets on a volume. The VOL1 record
on a volume contains a field which points to where the VTOC exists. The
VTOC is "self described" in the type 4 VTOC record. The VTOC most closely
resembles a keyed BDAM data set (remember, it's not a data set!) which has
a 44 byte hardware key. The hardware key is the same as the DSN. For the
VTOC, the hardware key is 44x'04', that is 44 repetitions of the hex value
x'04'. When z/OS processes the VARY ONLINE command for a DASD device, it
reads the VOL1 record. This validates the volume serial is unique and it
then stores the address of the VTOC in the UCB for other users, such as
DADSM allocation.​

​I don't know what you want to do, but personally, I prefer using the
output from the IDCAMS DCOLLECT command for data set information. Of
course, it is not useful for a "one off" data set requirement. If you want
a VTOC mapping of where data sets reside on a volume, for some reason, then
using ADRDSSU with a PARM='TYPRUN=NORUN' and a DEFRAG command will get you
a fairly nice listing.

You could also do a IEHLIST of the volume.

​Oh, and I also use the REXX / TSO LISTDSI command for data set information
retrieval.​


-- 
The unfacts, did we have them, are too imprecisely few to warrant our
certitude.

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: Dataset space information

[michelbutz]

I am sorry dont understand what is the VTOC 
Dataset name, there is another dataset on that volume sys1.vvds.v concentrated 
to the volser 

Sent from my iPhone

> On May 3, 2016, at 11:46 AM, J R  wrote:
> 
> VTOC DSN is 44X'4' 
> 
> Sent from my iPhone
> 
>> On May 3, 2016, at 11:30, michelbutz  wrote:
>> 
>> Hi
>> 
>> I need to obtain dataset space information 
>> 
>> I have been looking at the DFSMS advanced services and there seems like a 
>> few away of going about this 
>> 
>> The OBTAIN and camlist seems like the easiest 
>> As all it needs is a dataset name and volser
>> 
>> The CVAF macros seems like the must current
>> But I would need to get (if I am using for instance)
>> CVAFDIR the DEB of the VTOC
>> 
>> 
>> BTW is the VTOC dataset name SYS1.VTOCIX.  (Volser) ?
>> 
>> I guess that would mean allocating and opening it
>> 
>> Any suggestions ?
>> 
>> Sent from my iPhone
>> --
>> 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: Dataset space information

[J R]

VTOC DSN is 44X'4' 

Sent from my iPhone

> On May 3, 2016, at 11:30, michelbutz  wrote:
> 
> Hi
> 
> I need to obtain dataset space information 
> 
> I have been looking at the DFSMS advanced services and there seems like a few 
> away of going about this 
> 
> The OBTAIN and camlist seems like the easiest 
> As all it needs is a dataset name and volser
> 
> The CVAF macros seems like the must current
> But I would need to get (if I am using for instance)
> CVAFDIR the DEB of the VTOC
> 
> 
> BTW is the VTOC dataset name SYS1.VTOCIX.  (Volser) ?
> 
> I guess that would mean allocating and opening it
> 
> Any suggestions ?
> 
> Sent from my iPhone
> --
> 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: SRB dispatching question

[Tom Marchant]

On Tue, 3 May 2016 13:02:43 +, Blaicher, Christopher Y. wrote:

>once SRB #1 did the PAUSE, SRB #2, or any other qualifying unit of work, [is] 
>free to run in the address space

It seems to me that whether or not SRB #1 PAUSEs, SRB #2 can be dispatched on 
another processor. When SRB # 1 pauses, SRB #2 can be dispatched on the same 
processor.

-- 
Tom Marchant

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

Dataset space information

[michelbutz]

Hi

I need to obtain dataset space information 

I have been looking at the DFSMS advanced services and there seems like a few 
away of going about this 

The OBTAIN and camlist seems like the easiest 
As all it needs is a dataset name and volser

The CVAF macros seems like the must current
But I would need to get (if I am using for instance)
CVAFDIR the DEB of the VTOC


BTW is the VTOC dataset name SYS1.VTOCIX.  (Volser) ?

I guess that would mean allocating and opening it

Any suggestions ?

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

Re: PDS I/O Performance Improvement

[ronjhawk...@sbcglobal.net]

Chuck, 
It does not sound like VIO was ever an option to improve this utility.
I think you identified early on that directory search is the main issue with 
this PDS, so your options are PDSE V2, PDSE, LA add/remove.
VIO would be an option if the PDS was smaller, but reading all the members 
(1400 Cyls) into VIO just to touch some portion of the members makes no sense.
Ron


Sent via the Samsung Galaxy S®6 active, an AT&T 4G LTE smartphone 
Original message From: Chuck Kreiter  
Date: 5/2/2016  13:48  (GMT-08:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 
[IBM-MAIN] PDS I/O Performance Improvement 
VIO might not be an option as the dataset is 1400 cylinders.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ron Hawkins
Sent: Monday, May 2, 2016 2:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PDS I/O Performance Improvement

Skip,

VIO is still a great way to handle small, temp data sets. I've used the method 
mentioned below where VLF was no help, and LLA Freeze a hindrance, and it works 
surprisingly well. At less than 1Mb per CYL it’s far from being expensive. Then 
again, I was a big fan of VFETCH too... Not unlike building a custom LSR pool 
just for one problematic file.

I'm pretty sure the majority of shops are using DFSMS to limit and direct small 
allocations to VIO. None of that nasty IO - in and out like the Flash. The best 
IO is the one you don't do, so why bother with all that VTOC IO just to create 
and delete a one track data set that you may or may not write to?

20MB (~25 Cyls) is a fairly reasonable max vio size limit, but being a lab I 
have coded special cases in the ACS routines where I let 0.5GB into VIO. It's 
nice when I'm in control of 100% of what is running.

Ron



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Thursday, April 28, 2016 3:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] PDS I/O Performance Improvement

Since DASD has become so fast, many shops--including ours--long ago dropped VIO 
processing. A VIO request simply goes to a SYSALLDA volume. In any case, VIO 
would be very expensive way to improve performance of a very large data set.

.
.
.
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 Dana Mitchell
Sent: Thursday, April 28, 2016 7:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: PDS I/O Performance Improvement

Wow! flashback from the 80's!

We had a CICS region, seriously storage constrained with huge COBOL programs,  
it would do storage compressions multiple times a minute.  A temporary 
performance boost came from copying the main loadlib into VIO dataset at starup.

Dana
 
On Thu, 28 Apr 2016 14:22:37 +0100, Martin Packer  
wrote:

>If it's a matter of repeated reading why not copy to VIO in Central 
>Storage and read from there?


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

AW: Re: High number of samples seen in IEAVEPS1. What does this tell me?

[Peter Hunkeler]

> IEAVEPS1 is task Pause, not Post.
 >
>> Well that's why it's spending a lot of time there! PAUSE tends to do that to 
>> you.




Indeed! Now it all seems to makes more sense: The TCB is being PAUSEd until DB2 
finishes its work. MA-Tune finds the TCB not dispatched and looks at the OPSW 
in the RB, which points to PAUSE.


Anyway, I still am interested to learn how the flow from the application TCB/RB 
to DBM1, its SRB and back are working.


--
Peter Hunkeler





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

Re: IBM secure z/OS software delivery: Don't get locked out!

[Elardus Engelbrecht]

Kurt Quackenbush wrote:

>> Including for example SCRT software, Red Alerts and freebies (RACF goodies, 
>> RMF Spreadsheet software, et al.) from www.ibm.com?

>No, it only affects "IBM download servers used for all z/OS product and 
>service orders."

Many thanks for your kind clarification!

Much appreciated.

Groete / Greetings
Elardus Engelbrecht

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

Re: IBM secure z/OS software delivery: Don't get locked out!

[Kurt Quackenbush]

Well, the date for the end of the transition has been announced:
"As of AUGUST 14, 2016, all unsecured connections will be rejected
by IBM download servers used for all z/OS product and service
orders."


Including for example SCRT software, Red Alerts and freebies (RACF
goodies, RMF Spreadsheet software, et al.) from www.ibm.com?


No, it only affects "IBM download servers used for all z/OS product and 
service orders."


Kurt Quackenbush -- IBM, SMP/E Development

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

Re: High number of samples seen in IEAVEPS1. What does this tell me?

[Charles Mills]

Well that's why it's spending a lot of time there! PAUSE tends to do that to 
you.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Streitman
Sent: Tuesday, May 03, 2016 6:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: High number of samples seen in IEAVEPS1. What does this tell me?

IEAVEPS1 is task Pause, not Post.

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

AW: Re: High number of samples seen in IEAVEPS1. What does this tell me?

[Peter Hunkeler]

> Is it possible that the process being monitored is running disabled or
holding a lock before the POST? When it releases the lock or similar,
MA-Tune will pop out of its wait state and report the first instruction it
sees, which could be the POST.



I doubt. This is a plain normal COBOL application processing DB2 data. The 
apppication is not running disable, and I don't think that any of the DB2 code 
involved in EXEC SQL is running disabled, but I do not really know.


I never thought how this works in detail, but this how I understand it might be 
working:

The application is doing an EXEC SQL, which is calling DB2 code (DSNxLI), still 
in the applications address space under the TCB/RB. DSNxLI is taking over and 
has a) to switch to the DBM1 address space and b) to schedule an SRB to perform 
the work on behalf of the TCB/RB. The TCB/RB will be put into a WAIT. Later, 
when finished, the SRB cross-memory posts the TCB/RB.


Is this roughly right? I'm just curious.




--
Peter Hunkeler


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

Rexx EXEC SHOWALC Panel Memeber

[George Rodriguez]

Is there someone that knows anything about this EXEC? I'm missing the panel
member for the EXEC.

*George Rodriguez*
*Specialist II - IT Solutions*
*IT Enterprise Applications*
*PX - 47652*
*(561) 357-7652 (office)*
*(954) 415-7586 (mobile)*
*School District of Palm Beach County*
*3348 Forest Hill Blvd.*
*Room B-251*
*West Palm Beach, FL. 33406-5869*
*Florida's Only A-Rated Urban District For Eight Consecutive Years*

-- 


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


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

Re: IBM secure z/OS software delivery: Don't get locked out!

[Elardus Engelbrecht]

Kurt Quackenbush wrote:

>Well, the date for the end of the transition has been announced: "As of AUGUST 
>14, 2016, all unsecured connections will be rejected by IBM download servers 
>used for all z/OS product and service orders."

Including for example SCRT software, Red Alerts and freebies (RACF goodies, RMF 
Spreadsheet software, et al.) from www.ibm.com? 

Or is that (download via SSL protocal) only for SMP/E related downloads?

Many thanks in advance. (And thanks for providing that PDF in the URL in your 
post.)

Hmmm, I see in your PDF and subesquent links things like 'generation data group 
extended' and 'digital signatures for SMF records' and similar animals... 
Interesting, Can't wait to lay my hands on that goodies... ;-)

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: High number of samples seen in IEAVEPS1. What does this tell me?

[Paul Streitman]

IEAVEPS1 is task Pause, not Post.

Paul Streitman
z/OS Core Components Development

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

Re: High number of samples seen in IEAVEPS1. What does this tell me?

[Charles Mills]

Is it possible that the process being monitored is running disabled or
holding a lock before the POST? When it releases the lock or similar,
MA-Tune will pop out of its wait state and report the first instruction it
sees, which could be the POST.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: Tuesday, May 03, 2016 4:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: High number of samples seen in IEAVEPS1. What does this tell me?

I'm analyzing a job using CA's MA-Tune (similar to Strobe). Question is if
there is that could be optimized. Looking at the MA-Tune reports which are
based on 100 samples per second for 1 minute, I see that the job is seen in
IEAVEPS1 for some 20%. IEAVEPS1 is POST, IIRC.

I thought that POST would be a quick process and therefore I'm wondering it
appears at the top of the list. I'd like to understand a bit better what I'm
seeing and I'm *not* saying this is a problem.

The program does a lot with DB2, and when a DB2 call is made, I'd expect the
TCB to go into a WAIT until the SRB in DB2 completes and POSTs the TCB.
Watching from 9000 ft, is this about right?


Why do I not see any entry reporting the WAIT (IEAVEWT1 or similar)? Is this
just bad luck with sampling?


I would have thought that POSTing is quick, so I wonder why I often see a
couple of IEAVEPS1 entries in a row? Of yourse 1/100s is a long time so
other things may have happened inbetween, not being caught ba MA-Tune's
sampling. I wonder, however, if and what could case this to take longer that
what I would expect.

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

Re: SRB dispatching question

[Blaicher, Christopher Y.]

Peter,
Obviously I didn't fully put on my thinking cap yesterday when I mentioned the 
LOCAL LOCK.

I was attempting to think of what might be causing the poster's perceived 
condition of SRB #2 not appearing to run in the address space of the PAUSED 
global SRB #1.
Your comment seems to be backing my understanding that once SRB #1 did the 
PAUSE, SRB #2, or any other qualifying unit of work, was free to run in the 
address space subject to normal dispatching rules.

Michel,
You may want to run this situation on a test machine and start a GTF trace and 
see what is happening from that.  It should answer the question about if the 
second SRB is being dispatched or not.

Chris Blaicher
Technical Architect
Mainframe Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

www.syncsort.com





-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Relson
Sent: Tuesday, May 3, 2016 7:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SRB dispatching question

I'll point out that the very fact that a global SRB paused very likely means 
that you did not consider the SRB itself truly to be global. The system will no 
longer treat it as such after the pause.

Chris mentioned the local lock. I'm not sure why. You can't pause a work unit 
that is holding the local lock. Obviously some other running work unit could 
hold the local lock and thus prevent an SRB scheduled with LLOCK=YES from 
beginning.

In the scenario posed
SRB 1 scheduled to address space A pauses SRB 2 was scheduled to address space 
A (from anywhere) SRB 2 will run, according to normal dispatch priority rules.

Peter Relson
z/OS Core Technology Design


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





ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

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

Re: SRB dispatching question

[michelbutz]

Thanks so much the documentation for IEAVPSE2 says "NO LOCKS HELD"

Sent from my iPhone

> On May 3, 2016, at 7:50 AM, Peter Relson  wrote:
> 
> I'll point out that the very fact that a global SRB paused very likely 
> means that you did not consider the SRB itself truly to be global. The 
> system will no longer treat it as such after the pause. 
> 
> Chris mentioned the local lock. I'm not sure why. You can't pause a work 
> unit that is holding the local lock. Obviously some other running work 
> unit could hold the local lock and thus prevent an SRB scheduled with 
> LLOCK=YES from beginning. 
> 
> In the scenario posed
> SRB 1 scheduled to address space A pauses
> SRB 2 was scheduled to address space A (from anywhere)
> SRB 2 will run, according to normal dispatch priority rules.
> 
> Peter Relson
> z/OS Core Technology Design
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: IBM secure z/OS software delivery: Don't get locked out!

[Kurt Quackenbush]

Well, the date for the end of the transition has been announced: "As of 
AUGUST 14, 2016, all unsecured connections will be rejected by IBM 
download servers used for all z/OS product and service orders."


http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/FLASH10863

As I suggested in March, if you haven't done so already, its time to 
upgrade your download processes before you're stuck with no 
direct-to-z/OS download capability.


On 3/4/2016 9:24 AM, Kurt Quackenbush wrote:

IBM will be turning off its unencrypted FTP servers for downloading
products and PTFs over the Internet, maybe as soon as next month, April
2016!  See my blog post for information on how to prepare (watch the wrap):

https://www.ibm.com/developerworks/community/blogs/e0c474f8-3aad-4f01-8bca-f2c12b576ac9/entry/Secure_z_OS_software_delivery_Don_t_get_locked_out?lang=en


Kurt Quackenbush -- IBM, SMP/E Development

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

Re: SRB dispatching question

[Peter Relson]

I'll point out that the very fact that a global SRB paused very likely 
means that you did not consider the SRB itself truly to be global. The 
system will no longer treat it as such after the pause. 

Chris mentioned the local lock. I'm not sure why. You can't pause a work 
unit that is holding the local lock. Obviously some other running work 
unit could hold the local lock and thus prevent an SRB scheduled with 
LLOCK=YES from beginning. 

In the scenario posed
SRB 1 scheduled to address space A pauses
SRB 2 was scheduled to address space A (from anywhere)
SRB 2 will run, according to normal dispatch priority rules.

Peter Relson
z/OS Core Technology Design


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

High number of samples seen in IEAVEPS1. What does this tell me?

[Peter Hunkeler]

I'm analyzing a job using CA's MA-Tune (similar to Strobe). Question is if 
there is that could be optimized. Looking at the MA-Tune reports which are 
based on 100 samples per second for 1 minute, I see that the job is seen in 
IEAVEPS1 for some 20%. IEAVEPS1 is POST, IIRC.

I thought that POST would be a quick process and therefore I'm wondering it 
appears at the top of the list. I'd like to understand a bit better what I'm 
seeing and I'm *not* saying this is a problem.

The program does a lot with DB2, and when a DB2 call is made, I'd expect the 
TCB to go into a WAIT until the SRB in DB2 completes and POSTs the TCB. 
Watching from 9000 ft, is this about right?


Why do I not see any entry reporting the WAIT (IEAVEWT1 or similar)? Is this 
just bad luck with sampling?


I would have thought that POSTing is quick, so I wonder why I often see a 
couple of IEAVEPS1 entries in a row? Of yourse 1/100s is a long time so other 
things may have happened inbetween, not being caught ba MA-Tune's sampling. I 
wonder, however, if and what could case this to take longer that what I would 
expect.

Any clue?


--
Peter Hunkeler







--
Peter Hunkeler

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

Re: SAVING JOB OUTPUT IN A PDSE FROM SDSF

[willie bunter]

Thanks for the suggestion.  I tried it out as a test and it worked.  The only 
drawback is that I will have to include the output of the job after the  
//SYSUT1 DD *

As a test I tried inserting the dsn as in the SYSUT1 DD * however it did not 
work. I got the folowing :

 DATA SET UTILITY - GENERATE
IEB311I CONFLICTING DCB PARAMETERS 

Here is the jcl I used:

/*
//STEP  EXEC  PGM=IEBGENER
//SYSUT2 DD DSN=SYS2.CNTL.SHR(XF),DISP=(MOD,CATLG),   
//  UNIT=SYSALLDA,SPACE=(500,(500,,5))
//SYSUT1 DD DSN=SYS2.XF,DISP=SHR  
//SYSPRINT  DD  SYSOUT=(,)
//SYSPRINT DD  SYSOUT=*   
//SYSIN   DD   *  
/*

On Fri, 4/29/16, R.S.  wrote:

 Subject: Re: SAVING JOB OUTPUT IN A PDSE FROM SDSF
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Friday, April 29, 2016, 5:06 PM
 
 W dniu 2016-04-29 o
 22:30, Paul Gilmartin pisze:
 > On
 2016-04-29, at 09:58, R.S. wrote:
  That deserves an SR.  Works
 in JCL; works everywhere else.  The statement is
  patently false.
 >>> No, it isn't. MOD is not
 allowed for *member* od PDS or PDSE.
 >>> MOD is allowed for PO dataset,
 i.e. for IEFBR14 MOD,DELETE
 >>>
 >>> Try IEBGENER  //SYSUT2 DD
 DSN=HLQ.SOME.PO(MEMBER),DISP=(MOD,CATLG)
 >>>
 > My test job
 step:
 > //STEP  EXEC  PGM=IEBGENER
 > //SYSUT2 DD
 DSN=&SYSUID..SOME.PO(MEMBER),DISP=(MOD,CATLG),
 > //  UNIT=SYSALLDA,SPACE=(500,(500,,5))
 > //SYSUT1 DD *
 > 
    Test Data
 > //SYSPRINT 
 DD  SYSOUT=(,)
 > //SYSIN 
    DD  *
 > //*
 >
 > And log output:
 >
 > 14.10.00 JOB00158 
 -                                     
 -TIMINGS (MINS.)--                     
     -PAGING COUNTS
 > 14.10.00
 JOB00158  -STEPNAME PROCSTEP   
 RC   EXCP   CONN   
    TCB       SRB  CLOCK       
   SERV  WORKLOAD  PAGE  SWAP   VIO SWAPS
 > 14.10.00 JOB00158  -STEP           
      00     47     22 
      .00       .00 
    .0           116  BATCH   
     0     0     0 
    0
 > 14.10.00 JOB00158 
 IEF404I PDSMOD - ENDED - TIME=14.10.00
 >
 14.10.00 JOB00158  -PDSMOD   ENDED.  NAME-Paul
 Gilmartin       TOTAL TCB CPU TIME=      .00
 TOTAL ELAPSED TIME=    .0
 > 14.10.00
 JOB00158  $HASP395 PDSMOD   ENDED - RC=
 >
 > Works for me.
 You are right. Please rerun the job. I bet
 you'll get SB214 abend.
 My description
 was innacurate (I'm sorry for that!), however I meant
 MOD 
 as appending existing memebr. It is not
 possible.
 BTW: simple JCL workaound is to
 copy member to a PS, append it and then 
 overwrite the member (overwrite is possible,
 despite of PDS vs PDSE 
 internal processing,
 I mean what enduser see).
 
 Regarding SDSF, the forbiden DISP and DSORG
 combination can be result of 
 SDSF dialog
 logic, not the access method restriction.
 
 Unfortunately, it is possible
 to overwrite a member by mistake using the 
 dialog
 
 Regards
 -- 
 Radoslaw Skorupka
 Lodz,
 Poland
 
 
 
 
 
 
 --
 Tre tej wiadomoci moe
 zawiera informacje prawnie chronione Banku przeznaczone
 wycznie do uytku subowego adresata. Odbiorc moe by jedynie
 jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie
 jeste adresatem niniejszej wiadomoci lub pracownikiem
 upowanionym do jej przekazania adresatowi, informujemy, e
 jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne
 dziaanie o podobnym charakterze jest prawnie zabronione i
 moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy
 niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale
 usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane
 lub zapisane na dysku.
 
 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
 Sd Rejonowy dla m. st. Warszawy XII Wydzia
 Gospodarczy Krajowego Rejestru Sdowego, nr rejestru
 przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug
 stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w
 caoci wpacony) wynosi 168.955.696 zotych.
 
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to list

Re: $HASP152

[גדי בן אבי]

I found that the terminal where the problem was originating, was defined wrong, 
and instead of sending a $ it was sending the cent sign.
I changed that, so we'll see what happens.
Gadi

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Tuesday, May 03, 2016 12:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: $HASP152

Gadi wrote:

>When our operator issues the command $EPRT1 from SDSF he gets:
>$HASP152 PRT1 COMMAND REJECTED

You have got good replies. Perhaps you're looking up the wrong JES2 manuals.

I have some questions:

Do you have RACF authority or not? JES2 will not show you.

Issue $TDEBUG,SECURITY=YES and retry above command. Follow up on any messages 
you get.

It also could means someone else issued that command and JES2 is not finished 
with it.

Alternative - check your Infoprint.

>If he issue the command from the console, the command is accepted.

From Master Console?

When finished issue $TDEBUG,SECURITY=NO

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

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

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

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

Re: $HASP152

[Elardus Engelbrecht]

Gadi wrote:

>When our operator issues the command $EPRT1 from SDSF he gets:
>$HASP152 PRT1 COMMAND REJECTED

You have got good replies. Perhaps you're looking up the wrong JES2 manuals.

I have some questions: 

Do you have RACF authority or not? JES2 will not show you.

Issue $TDEBUG,SECURITY=YES and retry above command. Follow up on any messages 
you get.

It also could means someone else issued that command and JES2 is not finished 
with it.

Alternative - check your Infoprint.

>If he issue the command from the console, the command is accepted.

From Master Console?

When finished issue $TDEBUG,SECURITY=NO

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: $HASP152

[גדי בן אבי]

I looked at the manual.
It's next to useless.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Itschak Mugzach
Sent: Tuesday, May 03, 2016 11:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: $HASP152

The msg is not issued as result of authority issue but the printer status.
Have a look at the msg manual.

ITschak
בתאריך 3 במאי 2016 11:23,‏ "גדי בן אבי"  כתב:

The command was issued, so the operator has authority to issue commands.
The group that the operator is in has CMDAUTH(ALL) and CMDLEV(7) Gadi

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Finnell
Sent: Tuesday, May 03, 2016 11:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: $HASP152

Do a WHO on command line. Look for groupindx. This tells which tier of Groups 
the operator is in. The authority is COMMANDs in ISFPARMS..


In a message dated 5/3/2016 1:50:18 A.M. Central Daylight Time, 
gad...@malam.com writes:

When our  operator issues the command $EPRT1 from SDSF he gets:
$HASP152 PRT1   COMMAND  REJECTED



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

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

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

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

--
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: $HASP152

[Itschak Mugzach]

The msg is not issued as result of authority issue but the printer status.
Have a look at the msg manual.

ITschak
בתאריך 3 במאי 2016 11:23,‏ "גדי בן אבי"  כתב:

The command was issued, so the operator has authority to issue commands.
The group that the operator is in has CMDAUTH(ALL) and CMDLEV(7)
Gadi

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Edward Finnell
Sent: Tuesday, May 03, 2016 11:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: $HASP152

Do a WHO on command line. Look for groupindx. This tells which tier of
Groups the operator is in. The authority is COMMANDs in ISFPARMS..


In a message dated 5/3/2016 1:50:18 A.M. Central Daylight Time,
gad...@malam.com writes:

When our  operator issues the command $EPRT1 from SDSF he gets:
$HASP152 PRT1   COMMAND  REJECTED



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

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

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

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

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

Re: $HASP152

[גדי בן אבי]

The command was issued, so the operator has authority to issue commands.
The group that the operator is in has CMDAUTH(ALL) and CMDLEV(7)
Gadi

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Finnell
Sent: Tuesday, May 03, 2016 11:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: $HASP152

Do a WHO on command line. Look for groupindx. This tells which tier of Groups 
the operator is in. The authority is COMMANDs in ISFPARMS..


In a message dated 5/3/2016 1:50:18 A.M. Central Daylight Time,
gad...@malam.com writes:

When our  operator issues the command $EPRT1 from SDSF he gets:
$HASP152 PRT1   COMMAND  REJECTED



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

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

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

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

Re: $HASP152

[Edward Finnell]

Do a WHO on command line. Look for groupindx. This tells which tier of  
Groups the operator is in. The authority is COMMANDs in ISFPARMS.. 
 
 
In a message dated 5/3/2016 1:50:18 A.M. Central Daylight Time,  
gad...@malam.com writes:

When our  operator issues the command $EPRT1 from SDSF he gets:
$HASP152 PRT1   COMMAND  REJECTED



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