Re: Dataset enqueue, how to find the culprit.

2015-09-18 Thread Lizette Koehler
So, it will depend on how often the TSO message for enqueue is produced.  If it 
is not frequent, you may have to set slips or live with rerunning the job.

Or if it is frequent, you might try adding a first step with DISP=OLD on your 
file.  then you would have a better idea of what is doing it or have the job 
wait until the file is freed.

You did not show what type of process is being used when this occurs.  So if 
this is REXX/CLIST that does LM functions, or an IEBCOPY, or other

Perhaps if you could describe the process and functions being used that this 
condition occurred,  we might provide better diags or alternatives.



Lizette


>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Toni Cecil
>Sent: Friday, September 18, 2015 12:21 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Dataset enqueue, how to find the culprit.
>
>Hello,
>yesterday I got the following dsn enqueue:
>IKJ56225I DATA SET TLF.ZPT.JCL.CNTL ALREADY IN USE, TRY LATER+ IKJ56225I DATA 
>SET IS ALLOCATED TO ANOTHER JOB OR USER SDAA004I - RETURN=(DD),PERM=YES 
>DSN=TLF.ZPT.JCL.CNTL(ZZZTXXXB), DISP=SHR SDAB005I - ERR=0210, INFO=, 
>REQUESTED DATA SET NOT AVAILABLE.
>SDAB005I ALLOCATED TO ANOTHER JOB.
>
>Is there a way to find today, who was "locking" the pds library ?? I run DAF 
>tool against TLF.ZPT.JCL.CNTL to see if something was shown about the enqueue, 
>but I didn't find anything, am I doing something wrong ?? Or is there any 
>other utility that could be more appropriate to check this "problem" ??
>
>Many thx, A.Cecilio.
>

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


Re: Recovery routine for ICHRTX00

2015-09-18 Thread Walt Farrell
On Fri, 18 Sep 2015 18:01:16 +, Leonardo Vaz  wrote:

>I want to make use of the MVS router exit ICHRTX00 but I am having trouble 
>defining a recovery routine for it. I can't use ESTAE-like routines because 
>locks can be held when the exit is called and I can't use FRR because it needs 
>Supervisor state and PSW key 0 while the exit might be called in any state and 
>key.
>
>This will be my first real recovery routine so I'm pretty sure I'm missing 
>something basic, does anyone has any ideas?

If you want recovery in that exit you basically need to determine the 
environment you were invoked in and do something appropriate. As you've 
noticed, "appropriate" will vary depending on the request type and other 
options, and will depend in some cases on how the caller has decided to invoke 
you.

Some are simpler than others. REQUEST=VERIFY, for example, is documented as 
requiring an environment where an SVC can be issued, and does not require any 
particular state or key. So for that you could use an ESTAE(X). Each request 
type has a documented programming environment.

So you start out by figuring out what you want to do in the routine (which 
request type(s) you want to process), and what environments they can be called 
in. If you only want one particular request type, I would filter other requests 
out before establishing your recovery as that will make things much simpler.

By the way, starting your recovery adventure with ICHRTX00 may not be your best 
choice. You should probably learn about recovery using (a) some simpler routine 
that (b) won't kill your system if you get it wrong.

-- 
Walt

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


Re: z/OS V2.2 IBM Education Assistance

2015-09-18 Thread Jantje.
On Thu, 17 Sep 2015 08:47:29 -0500, Mark Zelden  wrote:

>Thanks, I personally was not aware (that's what happens when I miss SHARE 3 
>summers in a row).  :-)
>
>Is there a generic link for the site?  

http://www-01.ibm.com/software/info/education/assistant/

I think...

Cheers,

Jantje.

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


Re: z/OS V2.2 Manuals are zipped up

2015-09-18 Thread Marna WALLE
Ed,
I just read on the internet:
Q:  Is it possible to disable automatic updates in the Adobe Reader DC? It's 
not under preferences where it used to be?
A:  Adobe Acrobat Reader DC is set up for continuous updating.

I guess I'm always auto-updating on this new level I'm now using!  Knob removed.
-Marna

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


Re: z/OS V2.2 Manuals are zipped up

2015-09-18 Thread Bill Godfrey
There is another way to get to the index.
Instead of clicking on the .pdx file, open any document in the directory that 
has the .pdx file.
Click on "Edit" then "Advanced Search".
Click on "Show More Options".
In the menu under "Look in:" click on "Select Index..."
The .pdx file will be the only choice shown. Click the "OK" button".
Enter what you want to search for.

This worked for Acrobat XI 11.0.12.

Bill

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


Re: Dataset enqueue, how to find the culprit.

2015-09-18 Thread Toni Cecil
Hello everyone,
I wnat to know how to debug this situation after it occurred, in this case,
the next day. In this particular case Connect Direct was unable to pick
this library for a transmission task becuase it was in use by someone (user
ou job).
I did run RMFMONIII DSND "Data set delays" with 100sec sampling moving
forward and rewinding on time and I coundn't find anything.
But basically, what tool do you normally use for a situation like this ???
to find the enqueue after the problem take place ??

Many thx for all your sugestions, A.Cecilio.


2015-09-18 17:23 GMT+01:00 Jousma, David :

> One of the quickest ways, is to go to ISPF option 3.4, and pull up that
> dataset, and do a "R" to rename it(don’t really rename it though).  When it
> says 'dataset in use", hit PF1 and you get a list of jobs with enqueues on
> it.
>
> _
> Dave Jousma
> Assistant Vice President, Mainframe Engineering
> david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
> p 616.653.8429
> f 616.653.2717
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Toni Cecil
> Sent: Friday, September 18, 2015 12:21 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Dataset enqueue, how to find the culprit.
>
> Hello,
> yesterday I got the following dsn enqueue:
> IKJ56225I DATA SET TLF.ZPT.JCL.CNTL ALREADY IN USE, TRY LATER+ IKJ56225I
> DATA SET IS ALLOCATED TO ANOTHER JOB OR USER SDAA004I -
> RETURN=(DD),PERM=YES DSN=TLF.ZPT.JCL.CNTL(ZZZTXXXB), DISP=SHR SDAB005I -
> ERR=0210, INFO=, REQUESTED DATA SET NOT AVAILABLE.
> SDAB005I ALLOCATED TO ANOTHER JOB.
>
> Is there a way to find today, who was "locking" the pds library ?? I run
> DAF tool against TLF.ZPT.JCL.CNTL to see if something was shown about the
> enqueue, but I didn't find anything, am I doing something wrong ?? Or is
> there any other utility that could be more appropriate to check this
> "problem" ??
>
> Many thx, A.Cecilio.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> This e-mail transmission contains information that is confidential and may
> be privileged.   It is intended only for the addressee(s) named above. If
> you receive this e-mail in error, please do not read, copy or disseminate
> it in any manner. If you are not the intended recipient, any disclosure,
> copying, distribution or use of the contents of this information is
> prohibited. Please reply to the message immediately by informing the sender
> that the message was misdirected. After replying, please erase it from your
> computer system. Your assistance in correcting this error is appreciated.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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


Recovery routine for ICHRTX00

2015-09-18 Thread Leonardo Vaz
Hello List!

I want to make use of the MVS router exit ICHRTX00 but I am having trouble 
defining a recovery routine for it. I can't use ESTAE-like routines because 
locks can be held when the exit is called and I can't use FRR because it needs 
Supervisor state and PSW key 0 while the exit might be called in any state and 
key.

This will be my first real recovery routine so I'm pretty sure I'm missing 
something basic, does anyone has any ideas?

Thanks,
Leo

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


Re: Dataset enqueue, how to find the culprit.

2015-09-18 Thread Richard Pinion
I think this setting for RMF will cut an SMF record for enqueue conditions.
RMF must be started pointing to the member which specifies ENQ(DETAIL).

EDIT   USER.PARMLIB(ERBRMF00) - 01.05  Columns 
1 00080 
Command ===>  Scroll 
===> CSR  
14   ENQ(DETAIL)
   



--- stars...@mindspring.com wrote:

From: Lizette Koehler 
To:   IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dataset enqueue, how to find the culprit.
Date: Fri, 18 Sep 2015 11:16:35 -0700

So, it will depend on how often the TSO message for enqueue is produced.  If it 
is not frequent, you may have to set slips or live with rerunning the job.

Or if it is frequent, you might try adding a first step with DISP=OLD on your 
file.  then you would have a better idea of what is doing it or have the job 
wait until the file is freed.

You did not show what type of process is being used when this occurs.  So if 
this is REXX/CLIST that does LM functions, or an IEBCOPY, or other

Perhaps if you could describe the process and functions being used that this 
condition occurred,  we might provide better diags or alternatives.



Lizette


>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Toni Cecil
>Sent: Friday, September 18, 2015 12:21 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Dataset enqueue, how to find the culprit.
>
>Hello,
>yesterday I got the following dsn enqueue:
>IKJ56225I DATA SET TLF.ZPT.JCL.CNTL ALREADY IN USE, TRY LATER+ IKJ56225I DATA 
>SET IS ALLOCATED TO ANOTHER JOB OR USER SDAA004I - RETURN=(DD),PERM=YES 
>DSN=TLF.ZPT.JCL.CNTL(ZZZTXXXB), DISP=SHR SDAB005I - ERR=0210, INFO=, 
>REQUESTED DATA SET NOT AVAILABLE.
>SDAB005I ALLOCATED TO ANOTHER JOB.
>
>Is there a way to find today, who was "locking" the pds library ?? I run DAF 
>tool against TLF.ZPT.JCL.CNTL to see if something was shown about the enqueue, 
>but I didn't find anything, am I doing something wrong ?? Or is there any 
>other utility that could be more appropriate to check this "problem" ??
>
>Many thx, A.Cecilio.
>

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




_
Netscape.  Just the Net You Need.

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


Re: Dataset enqueue, how to find the culprit.

2015-09-18 Thread Greg Shirey
According to Merriam-Webster online dictionary, one definition of "culprit" is 
"the source or cause of a problem." 

I suppose now there needs to be a discussion about whether the OP's situation 
could be defined as a problem... 

Regards,
Greg Shirey
Ben E. Keith Company


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ted MacNEIL
Sent: Friday, September 18, 2015 1:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dataset enqueue, how to find the culprit.

There is NO SUCH THINGS as a culprit!
They are just doing their job and so are you. They just happened to collide.

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


Re: IPCS BLS18028I message suppression

2015-09-18 Thread Kenneth J. Kripke
You cannot OUTTRAP Tputs, and, some of the outputs from IPCS utilize TPUTS.


Messages delivered via PUTLINE can be OUTTAP'ed. 

 

 

k.kri...@comcast.net 

 


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


Re: IPCS BLS18028I message suppression

2015-09-18 Thread Jim Mulder
> Interesting you should suggest that.
> I did a batch IPCS run with my REXX and sure enough, in TSO/Batch 
> the BLS18028I is captured by OUTTRAP and my REXX displays it as 
expected.
> 
> Question now is, why isn't it captured with the REXX is executed 
> interactively?
> 
> So, if IPCS is executed in interactive TSO, the BLS18028I messages 
> is issued to the "print" file that is displayed upon the terminal.
> If, however, the same REXX is executed in TSO/Batch, the message is 
> captured by OUTTRAP and placed in the stem that was passed in the 
> first OUTTRAP call. It does not appear in the print file nor on the 
> output associated with SYSTSPRT.
> 
> Interesting.
> 
> Since the primary use of this REXX will be batch as opposed to 
> interactive, I can live with it I guess.
> Just wish it would work the same regardless of environment.
> 
> C-
> 
> Charles (Chuck) Hardee
> Senior Systems Engineer/Database Administration
> EAS Information Technology
> 
> Thermo Fisher Scientific
> 300 Industry Drive | Pittsburgh, PA 15275
> Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 
490-9230
> chuck.har...@thermofisher.com  | www.thermofisher.com
> 
> WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or 
> copying of this e-mail or the information herein by anyone other 
> than the intended recipient, or an employee or agent of a system 
> responsible for delivering the message to the intended recipient, is
> prohibited. If you are not the intended recipient, please inform the
> sender and delete all copies.
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU
> ] On Behalf Of J R
> Sent: Friday, September 18, 2015 10:46 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IPCS BLS18028I message suppression
> 
> Assuming it is a TPUT and assuming your logic doesn't depend on it, 
> (yeah, I know)
> could you run it in batch?  This may prevent the message messing up 
> your report. 
> 
> 
> 
> > Date: Fri, 18 Sep 2015 14:12:45 +
> > From: chuck.hardee
> /snip/
> > Charles (Chuck) Hardee
> > Senior Systems Engineer/Database Administration
> > EAS Information Technology
> 
> > > It's more frustrating than technical, but I'm trying to produce a 
custom
> > report from
> > > the dump and this message gets in the way of the report's 
information.

  I can tell you what IPCS does.  The FIND subcommand processor BLSRFIND 
calls
BLSUTRMV to issue the message.  Comments in BLSUTRMV say that it does 
this: 


If ISPF services are not available, the message is 
transmitted to the terminal via the TSO IKJPUTL service 
routine.  IKJPUTL processing is sensitive to the TSO 
environment and the current context: 
 
A. The most common disposition of the message is to use the
   TPUT service to send the message to the terminal.  This 
   is the normal action in an interactive TSO session. 
 
B. In a batch TSO session, the most common disposition of 
   the message is to use QSAM PUT processing to write the 
   line to FILE(SYSTSPRT). 
 
C. During CLIST processing in either interactive or batch 
   TSO sessions, 
 
 CONTROL NOMSG 
 
   may be used to cause the message to be discarded. 
 
D. When TSO/E is installed and CLIST processing is active, 
 
 SET SYSOUTTRAP=decimal-number 
 
   may be used to cause the message to be captured in a 
CLIST variable. 
 
The several actions possible are services performed by 
IKJPUTL, not BLSUTRMV. 
 
 
  And the code agrees with these comments.  There is no checking
of batch vs. terminal.   It just calls IKJPUTL.  So I would guess
that whatever differences you are seeing would be a question for
TSO/E. 


Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

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


Re: Recovery routine for ICHRTX00

2015-09-18 Thread J O Skip Robinson
This may sound heretical, but I lean against recovery actions for system exits. 
In most cases, the environment in which a system-defined exit runs is protected 
already. Messages are issued, dumps are taken, and some semblance of order is 
restored. In many cases the exit is disabled so that repetitive abends are 
avoided. What actions would a user recovery environment take better than this? 
Test your exit for as long as possible on a sandbox system. Then move it to a 
development system for as long as possible. At long last move it to production. 
A user written recovery routine would probably take longer to debug than 
whatever exit code caused a failure in the first place. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Walt Farrell
Sent: Friday, September 18, 2015 6:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Recovery routine for ICHRTX00

On Fri, 18 Sep 2015 18:01:16 +, Leonardo Vaz  wrote:

>I want to make use of the MVS router exit ICHRTX00 but I am having trouble 
>defining a recovery routine for it. I can't use ESTAE-like routines because 
>locks can be held when the exit is called and I can't use FRR because it needs 
>Supervisor state and PSW key 0 while the exit might be called in any state and 
>key.
>
>This will be my first real recovery routine so I'm pretty sure I'm missing 
>something basic, does anyone has any ideas?

If you want recovery in that exit you basically need to determine the 
environment you were invoked in and do something appropriate. As you've 
noticed, "appropriate" will vary depending on the request type and other 
options, and will depend in some cases on how the caller has decided to invoke 
you.

Some are simpler than others. REQUEST=VERIFY, for example, is documented as 
requiring an environment where an SVC can be issued, and does not require any 
particular state or key. So for that you could use an ESTAE(X). Each request 
type has a documented programming environment.

So you start out by figuring out what you want to do in the routine (which 
request type(s) you want to process), and what environments they can be called 
in. If you only want one particular request type, I would filter other requests 
out before establishing your recovery as that will make things much simpler.

By the way, starting your recovery adventure with ICHRTX00 may not be your best 
choice. You should probably learn about recovery using (a) some simpler routine 
that (b) won't kill your system if you get it wrong.

--
Walt


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


Re: Dataset enqueue, how to find the culprit.

2015-09-18 Thread Richard Pinion
Run RMF, I think monitor I, with the following option.  This create
an RMF SMF enqueue record.

VIEW   USER.PARMLIB(ERBRMF00) - 01.05
Command ===> 
14   ENQ(DETAIL)

Then run the RMF postprocessor as below.

//STEP010  EXEC PGM=ERBRMFPP   
//MFPINPUT DD   DISP=SHR,DSN=your.smf.data   (Could be the currently 
active MANx, or an SMF offload data set. 
//MFPMSGDS DD   SYSOUT=*   
//SYSINDD   *  
SYSOUT (X) 
DATE(mmdd,mmdd)
NOSUMMARY  
REPORTS(ENQ)




--- acbi...@gmail.com wrote:

From: Toni Cecil 
To:   IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dataset enqueue, how to find the culprit.
Date: Fri, 18 Sep 2015 21:46:12 +0100

Hello everyone,
I wnat to know how to debug this situation after it occurred, in this case,
the next day. In this particular case Connect Direct was unable to pick
this library for a transmission task becuase it was in use by someone (user
ou job).
I did run RMFMONIII DSND "Data set delays" with 100sec sampling moving
forward and rewinding on time and I coundn't find anything.
But basically, what tool do you normally use for a situation like this ???
to find the enqueue after the problem take place ??

Many thx for all your sugestions, A.Cecilio.


2015-09-18 17:23 GMT+01:00 Jousma, David :

> One of the quickest ways, is to go to ISPF option 3.4, and pull up that
> dataset, and do a "R" to rename it(don’t really rename it though).  When it
> says 'dataset in use", hit PF1 and you get a list of jobs with enqueues on
> it.
>
> _
> Dave Jousma
> Assistant Vice President, Mainframe Engineering
> david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
> p 616.653.8429
> f 616.653.2717
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Toni Cecil
> Sent: Friday, September 18, 2015 12:21 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Dataset enqueue, how to find the culprit.
>
> Hello,
> yesterday I got the following dsn enqueue:
> IKJ56225I DATA SET TLF.ZPT.JCL.CNTL ALREADY IN USE, TRY LATER+ IKJ56225I
> DATA SET IS ALLOCATED TO ANOTHER JOB OR USER SDAA004I -
> RETURN=(DD),PERM=YES DSN=TLF.ZPT.JCL.CNTL(ZZZTXXXB), DISP=SHR SDAB005I -
> ERR=0210, INFO=, REQUESTED DATA SET NOT AVAILABLE.
> SDAB005I ALLOCATED TO ANOTHER JOB.
>
> Is there a way to find today, who was "locking" the pds library ?? I run
> DAF tool against TLF.ZPT.JCL.CNTL to see if something was shown about the
> enqueue, but I didn't find anything, am I doing something wrong ?? Or is
> there any other utility that could be more appropriate to check this
> "problem" ??
>
> Many thx, A.Cecilio.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> This e-mail transmission contains information that is confidential and may
> be privileged.   It is intended only for the addressee(s) named above. If
> you receive this e-mail in error, please do not read, copy or disseminate
> it in any manner. If you are not the intended recipient, any disclosure,
> copying, distribution or use of the contents of this information is
> prohibited. Please reply to the message immediately by informing the sender
> that the message was misdirected. After replying, please erase it from your
> computer system. Your assistance in correcting this error is appreciated.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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




_
Netscape.  Just the Net You Need.

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


Re: MPF message processing not started for msg

2015-09-18 Thread J O Skip Robinson
When you get 'terminated at end of memory', all bets are off. This generally 
happens when the address space has run out of storage to the point that 
recovery routines cannot run. No recovery, no message processing, no 
preservation of sysout, etc. Your MPF entries indicate user exit processing. 
Probably not going to happen.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brad Wissink
Sent: Friday, September 18, 2015 2:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: MPF message processing not started for msg

I have a batch job that abended with the following messages .

N C00 H50A 2015260 17:03:16.08 J0684125   $HASP310 U0051299 
TERMINATED AT END OF MEMORY
M 400 H50A 2015260 17:03:16.25    IEF402I U0051299 
FAILED IN ADDRESS SPACE 0058 892   
E   892   SYSTEM ABEND 
S04F - REASON CODE F30901  

I have two MPF message exits defined for one for each message.   

/*$HASP310 - JOBNAME TERMINATED AT END OF MEMORY  */
$HASP310,SUP(NO),USEREXIT(SY159)
/*IEF402I - JOBNAME FAILED IN ADDRESS SPACE SYSTEM ABEND SXXX */
IEF402I,SUP(NO),USEREXIT(SY147) 

I did a 'D MPF' to make sure the exits were defined and active.

Does anyone have an idea on why the exits were not called?


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


Re: Volkswagen Programmed Vehicle to Deactivate Pollution Control Systems

2015-09-18 Thread Richard Pinion
I understand the point you are making, that an employee is told
to do something that they know is illegal or immoral, and they 
do it anyway.  Having worked for a non-profit health insurance 
company many, many years ago, I was often asked if we intentionally
programmed the system to automatically reject a claim on first
submission, regardless of whether the claim met all criteria for
processing.  I was never asked to do that, nor was I aware of
any such code within their claims processing system.  Yet, the
public perspective was that the company did that.

Not sure how that story fits into the discussion at hand, but
it is late in the day, and I'm looking for ways to fill my time
until "Miller" time.



--- jba...@ngssallc.com wrote:

From: "John P. Baker" 
To:   IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Volkswagen Programmed Vehicle to Deactivate Pollution Control 
Systems
Date: Fri, 18 Sep 2015 16:54:45 -0400

Richard,

I think that there is a big difference here in that the programming staff at 
Volkswagen, if the initial reports are accurate, could not reasonably not have 
known that what they were coding was in furtherance of a crime.

John P. Baker

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richard Pinion
Sent: Friday, September 18, 2015 4:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Volkswagen Programmed Vehicle to Deactivate Pollution Control 
Systems

As an employee of a company who deals with HIPPA controlled/protected data, I 
feel very uncomfortable knowing that I can be charged either with a civil or 
criminal violation in the event that HIPPA data, under my control, is 
accidentally lost or stolen.  And I am not talking about an intentional leak of 
protected patient information.  What really floored me this year, when I took 
the yearly HIPPA certification online class, was HIPPA is administered under 
the Office of Civil Rights.

Regardless of my personal political theology, it makes me uncomfortable that if 
I offend a person or persons, the friendly neighborhood OCR representative 
could be asked to "look at" my activities as relating to HIPPA compliance.  I'm 
sure an unbiased and diligent OCR employee might uncover some violation(s) if 
they
investigated long and hard enough. 

--- jba...@ngssallc.com wrote:

From: "John P. Baker" 
To:   IBM-MAIN@LISTSERV.UA.EDU
Subject: Volkswagen Programmed Vehicle to Deactivate Pollution Control Systems
Date: Fri, 18 Sep 2015 15:56:34 -0400

http://www.foxbusiness.com/industries/2015/09/18/epa-says-vw-intentionally-v
iolates-clean-air-standards/?intcmp=hpbt1

In the referenced article, it is being reported that Volkswagen had their 
programming staff intentionally program the computers controlling the pollution 
control systems on certain 2008-2015 Audi and Volkswagen diesel vehicles to 
activate the full pollution control systems ONLY when the vehicle was 
undergoing official emissions testing.  At all other times, the pollution 
control systems were inactive and the vehicles were putting out emissions as 
high as 40 times the legal limit.

The company is facing $18 billion in fines.

It is unclear whether the Volkswagen executives who directed the scheme will 
face criminal charges.

It is also unclear whether the programming staff who wrote the code will face 
criminal charges.

Even though this is not a mainframe issue, it is an issue that directly affects 
us and our industry.  Hackers are already a significant black eye.
This is much worse.  It makes legitimate programmers look suspect.

It raises the uncomfortable question of whether or not we can or should be held 
criminally liable if we are directed to code a program or a change to a program 
that we know would have the effect of violating the law and we then knowingly 
proceed to code that program or a change to a program.

It has been suggested in the past that programmers should be licensed and/or 
bonded.

I am not particularly fond of either idea.  However, I would like to hear what 
others think.

John P. Baker

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
_
Netscape.  Just the Net You Need.
--
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




_
Netscape.  Just the Net You Need.


Re: Volkswagen Programmed Vehicle to Deactivate Pollution Control Systems

2015-09-18 Thread John P. Baker
Richard,

I think that there is a big difference here in that the programming staff at 
Volkswagen, if the initial reports are accurate, could not reasonably not have 
known that what they were coding was in furtherance of a crime.

John P. Baker

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richard Pinion
Sent: Friday, September 18, 2015 4:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Volkswagen Programmed Vehicle to Deactivate Pollution Control 
Systems

As an employee of a company who deals with HIPPA controlled/protected data, I 
feel very uncomfortable knowing that I can be charged either with a civil or 
criminal violation in the event that HIPPA data, under my control, is 
accidentally lost or stolen.  And I am not talking about an intentional leak of 
protected patient information.  What really floored me this year, when I took 
the yearly HIPPA certification online class, was HIPPA is administered under 
the Office of Civil Rights.

Regardless of my personal political theology, it makes me uncomfortable that if 
I offend a person or persons, the friendly neighborhood OCR representative 
could be asked to "look at" my activities as relating to HIPPA compliance.  I'm 
sure an unbiased and diligent OCR employee might uncover some violation(s) if 
they
investigated long and hard enough. 

--- jba...@ngssallc.com wrote:

From: "John P. Baker" 
To:   IBM-MAIN@LISTSERV.UA.EDU
Subject: Volkswagen Programmed Vehicle to Deactivate Pollution Control Systems
Date: Fri, 18 Sep 2015 15:56:34 -0400

http://www.foxbusiness.com/industries/2015/09/18/epa-says-vw-intentionally-v
iolates-clean-air-standards/?intcmp=hpbt1

In the referenced article, it is being reported that Volkswagen had their 
programming staff intentionally program the computers controlling the pollution 
control systems on certain 2008-2015 Audi and Volkswagen diesel vehicles to 
activate the full pollution control systems ONLY when the vehicle was 
undergoing official emissions testing.  At all other times, the pollution 
control systems were inactive and the vehicles were putting out emissions as 
high as 40 times the legal limit.

The company is facing $18 billion in fines.

It is unclear whether the Volkswagen executives who directed the scheme will 
face criminal charges.

It is also unclear whether the programming staff who wrote the code will face 
criminal charges.

Even though this is not a mainframe issue, it is an issue that directly affects 
us and our industry.  Hackers are already a significant black eye.
This is much worse.  It makes legitimate programmers look suspect.

It raises the uncomfortable question of whether or not we can or should be held 
criminally liable if we are directed to code a program or a change to a program 
that we know would have the effect of violating the law and we then knowingly 
proceed to code that program or a change to a program.

It has been suggested in the past that programmers should be licensed and/or 
bonded.

I am not particularly fond of either idea.  However, I would like to hear what 
others think.

John P. Baker

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
_
Netscape.  Just the Net You Need.
--
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


MPF message processing not started for msg

2015-09-18 Thread Brad Wissink
I have a batch job that abended with the following messages .

N C00 H50A 2015260 17:03:16.08 J0684125   $HASP310 U0051299 
TERMINATED AT END OF MEMORY
M 400 H50A 2015260 17:03:16.25    IEF402I U0051299 
FAILED IN ADDRESS SPACE 0058 892   
E   892   SYSTEM ABEND 
S04F - REASON CODE F30901  

I have two MPF message exits defined for one for each message.   

/*$HASP310 - JOBNAME TERMINATED AT END OF MEMORY  */
$HASP310,SUP(NO),USEREXIT(SY159)
/*IEF402I - JOBNAME FAILED IN ADDRESS SPACE SYSTEM ABEND SXXX */
IEF402I,SUP(NO),USEREXIT(SY147) 

I did a 'D MPF' to make sure the exits were defined and active.

Does anyone have an idea on why the exits were not called?

  

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


Re: z/OS V2.2 Manuals are zipped up

2015-09-18 Thread Marna WALLE
Thanks!  You've explained to me how to use it that even the person that created 
the index couldn't tell me.

However, I have a problem when I try to open that "zOS V2R2 PDFs July 2015.pdx" 
file.  Yes, I see the permission box, which is ok.  But after that I see an 
error "Search could not load the index (C:\\Userssnipped\zOS 
V2R2 PDFs July 2015.pdx.)  You may need to rebuild this index."  I've searched 
on this error, and the only thing I find is a workaround to use the index from 
within a browser (and not "standalone").

Do you know how to fix the problem that "search could not load"?

-Marna WALLE

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


Re: z/OS V2.2 Manuals are zipped up

2015-09-18 Thread Nims,Alva John (Al)
What release of Acrobat Reader are you running?
I am running "Adobe Acrobat Reader DC" 2015 Release, Version 2015.008.20082 and 
It has opened the index and I have also accomplished a search when I checked 
"In the index named zOS V2R2 PDFs July 2015.pdx"

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Marna WALLE
Sent: Friday, September 18, 2015 9:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS V2.2 Manuals are zipped up

Thanks!  You've explained to me how to use it that even the person that created 
the index couldn't tell me.

However, I have a problem when I try to open that "zOS V2R2 PDFs July 2015.pdx" 
file.  Yes, I see the permission box, which is ok.  But after that I see an 
error "Search could not load the index (C:\\Userssnipped\zOS 
V2R2 PDFs July 2015.pdx.)  You may need to rebuild this index."  I've searched 
on this error, and the only thing I find is a workaround to use the index from 
within a browser (and not "standalone").

Do you know how to fix the problem that "search could not load"?

-Marna WALLE  

--
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: IPCS BLS18028I message suppression

2015-09-18 Thread Lizette Koehler
I think it depends on what method IBM uses to produce the message.  I do not
think you can capture a TPUT message and suppress it.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Hardee, Chuck
> Sent: Friday, September 18, 2015 4:55 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IPCS BLS18028I message suppression
> 
> Hello Listers!
> 
> Has anyone figured out how to suppress the BLS18028I message.
> This is the message issued as a result of a FIND command when the object of
the
> FIND command was not found:
> 
> "BLS18028I Argument not found, searched to end of FINDAREA"
> 
> I am writing a REXX EXEC that issues various IPCS commands and I can suppress
> and/or capture most of them and then spit back the ones I'm interested in and
> handle the results of the others via the return code from the command.
However, no
> matter what combination of (NO)PRINT, (NO)TERMINAL, FLAG() and (NO)VERIFY I
> try, none of them seem to work for me.
> 
> For example, one would think, based upon the description of the FIND command
and
> the SETDEF operands discussion, that NOPRINT TERMINAL on the IPCS command
> and then wrapping the IPCS command with an OUTTRAP("msg.") and
> OUTTRAP("OFF") would allow the report to be clean and my REXX to know whether
> or not I found something via the return code.
> 
> It doesn't. The REXX is made aware of the success or failure of the FIND via
the
> return code, but when the FIND finds nothing, I always get the BLS18028I
message.
> 
> It's more frustrating than technical, but I'm trying to produce a custom
report from
> the dump and this message gets in the way of the report's information.
> 
> Thanks for taking the time.
> 
> Chuck
> 
> Charles (Chuck) Hardee
> Senior Systems Engineer/Database Administration EAS Information Technology
> 
> Thermo Fisher Scientific
> 300 Industry Drive | Pittsburgh, PA 15275 Phone +1 (724) 517-2633 | Mobile +1
(412)
> 877-2809 | FAX: +1 (412) 490-9230
> chuck.har...@thermofisher.com  |
> www.thermofisher.com

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


HTTP Server Domino Migration Health Check

2015-09-18 Thread Marna WALLE
If you've heard me talk about z/OS V2.2 migration, then I know you've heard me 
nag about getting an important migration health check to see if you're impacted 
by what I think of as the most important migration action in z/OS V2.2:  
Removal of the HTTP Server powered by Domino, and moving to the HTTP Server 
powered by Apache as its replacement.

The migration health check to see if you are using the Domino HTTP Server on a 
system is found here (not in any PTF):
http://www-03.ibm.com/systems/z/os/zos/installation/HTTP_Health_Checker.html

Today, we just updated that migration health check for a problem that was found 
only for z/OS R13 users.  If you are a z/OS V2.1 user, this problem did NOT 
apply to you, and you are fine with the level of the check you have now.  
However, if you running z/OS R13 and have run this health check before today, 
please download a new copy of it and run the check again.  This check will even 
run on unsupported releases prior to R13.

For everyone going to or through z/OS V2.2:  if you haven't already downloaded 
this check and run it, please do.  This check is very important to let you know 
if you have a Domino to Apache migration in your future.  This migration action 
might be quite a lot of work to do, so knowing if you are impacted now on z/OS 
R13 or V2.1 is critical.

As always, if there are any questions about this migration health check, please 
let me know.
-Marna WALLE
IBM System Installation, IBM Poughkeepsie

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


Re: z/OS V2.2 IBM Education Assistance

2015-09-18 Thread Marna WALLE
Hi Mark,
For the IBM Education Assistance (note: not IBM Education Assistant!), use this 
link:
http://www.redbooks.ibm.com/redbooks.nsf/pages/IBMIEA?Open

That is the "top page" for all the IBM Education Assistance levels, which is 
good to bookmark.

The other link (http://www-01.ibm.com/software/info/education/assistant/) is 
for IBM Education Assistant, and won't contain new z/OS modules.   I know it's 
a little confusing, but z/OS has "broken out" of using IBM Education Assistant, 
and created our own location that fits our needs better.  We called it "IBM 
Education Assistance" to indicate that the goals are the same - which is to 
deliver small education packets to you.  All of z/OS will be on the IBM 
Education Assistance location.

p.s.  Thanks for mentioning the z/OS V2.1 modules too - they are also found 
from that top page, for those that want to see z/OS V2.1 new stuff!

-Marna WALLE
z/OS System Installation, IBM Poughkeepsie

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


Re: z/OS V2.2 IBM Education Assistance

2015-09-18 Thread Nims,Alva John (Al)
"One more thing!"
#1. I do NOT know anything about Acrobat Search, but I am looking at what I 
have after unzipping the files on my system.

So I asked about the level of reader you are using, but I forgot to ask, in the 
directory that you have the " zOS V2R2 PDFs July 2015.pdx" do you have all the 
PDF files AND another directory, " zOS V2R2 PDFs July 2015" with files in it, 
"index.idx", "index1.idx" and "index2.idx"?

I know it is a bad thing to "assume" so that is why I am asking if you have the 
same file structure that we poor saps received when we downloaded the zip file 
and unzipped it.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Marna WALLE
Sent: Friday, September 18, 2015 9:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS V2.2 IBM Education Assistance

Hi Mark,
For the IBM Education Assistance (note: not IBM Education Assistant!), use this 
link:
http://www.redbooks.ibm.com/redbooks.nsf/pages/IBMIEA?Open

That is the "top page" for all the IBM Education Assistance levels, which is 
good to bookmark.

The other link (http://www-01.ibm.com/software/info/education/assistant/) is 
for IBM Education Assistant, and won't contain new z/OS modules.   I know it's 
a little confusing, but z/OS has "broken out" of using IBM Education Assistant, 
and created our own location that fits our needs better.  We called it "IBM 
Education Assistance" to indicate that the goals are the same - which is to 
deliver small education packets to you.  All of z/OS will be on the IBM 
Education Assistance location.

p.s.  Thanks for mentioning the z/OS V2.1 modules too - they are also found 
from that top page, for those that want to see z/OS V2.1 new stuff!

-Marna WALLE
z/OS System Installation, IBM Poughkeepsie

--
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 enqueue, how to find the culprit.

2015-09-18 Thread Richard Pinion
The old RMF TSO command RMFMON suboption SENQR will also tell you 
this information.


--- stars...@mindspring.com wrote:

From: Lizette Koehler 
To:   IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dataset enqueue, how to find the culprit.
Date: Fri, 18 Sep 2015 09:24:56 -0700

If you have RMF setup for ISPF, and the RMF VSAM files are available, you can 
use the ISPF RMF tool to go back in time for the enqueue information.

Did you look in syslog for any GRS information?
Did you go and look and see what other jobs were running when this job had this 
issue?


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Toni Cecil
> Sent: Friday, September 18, 2015 9:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Dataset enqueue, how to find the culprit.
> 
> Hello,
> yesterday I got the following dsn enqueue:
> IKJ56225I DATA SET TLF.ZPT.JCL.CNTL ALREADY IN USE, TRY LATER+ IKJ56225I DATA
> SET IS ALLOCATED TO ANOTHER JOB OR USER SDAA004I - RETURN=(DD),PERM=YES
> DSN=TLF.ZPT.JCL.CNTL(ZZZTXXXB), DISP=SHR SDAB005I - ERR=0210, INFO=,
> REQUESTED DATA SET NOT AVAILABLE.
> SDAB005I ALLOCATED TO ANOTHER JOB.
> 
> Is there a way to find today, who was "locking" the pds library ?? I run DAF 
> tool
> against TLF.ZPT.JCL.CNTL to see if something was shown about the enqueue, but 
> I
> didn't find anything, am I doing something wrong ?? Or is there any other 
> utility that
> could be more appropriate to check this "problem" ??
> 
> Many thx, A.Cecilio.
> 

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




_
Netscape.  Just the Net You Need.

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


Re: UNABLE TO RESTORE DSN USING DFDSS

2015-09-18 Thread willie bunter
Lizette,

I was able to restore the dsn to another volume (bypassed SMS).  All is well.  
Thanks again.


On Fri, 9/18/15, Lizette Koehler  wrote:

 Subject: Re: UNABLE TO RESTORE DSN USING DFDSS
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Friday, September 18, 2015, 12:26 PM
 
 The best options are
 always to look up message to see if they give a clue to
 your issue.  It is faster than waiting on the
 list.
 
 Lizette
 
 
 > -Original
 Message-
 > From: IBM Mainframe
 Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On
 > Behalf Of willie bunter
 > Sent: Friday, September 18, 2015 9:22
 AM
 > To: IBM-MAIN@LISTSERV.UA.EDU
 > Subject: Re: UNABLE TO RESTORE DSN USING
 DFDSS
 > 
 > Lizette,
 > 
 > You are right. 
 There is not enough space on the volume.  Yes, I am
 restoring
 the
 > dsns
 (which are SMS managed) with a rename.  The input dsns and
 output dsns
 are
 > located
 on the same Storage group.
 > 
 > Thanks for the help.
 >
 
 > On Fri, 9/18/15, Lizette Koehler 
 wrote:
 > 
 >  Subject:
 Re: UNABLE TO RESTORE DSN USING DFDSS
 > 
 To: IBM-MAIN@LISTSERV.UA.EDU
 >  Received: Friday, September 18, 2015,
 12:13 PM
 > 
 >  If you
 look up the
 >  IGD17365I - it states
 >  A SMS VTOC data set
 >  services extent reduction request for
 the data set  failed.
 >  One possible
 reason for the failure
 >  is that not
 enough space could be obtained;  other reasons are
 indicated by
 > preceding  messages.
 > 
 >  Do you have
 >  sufficient space on the volume for the
 restore?  Looks like  you need  at
 minimum
 > 4569TRK  You did
 not show us your control cards so I am  not sure if you
 are
 > restoring to  the same  volume or
 different volume.
 > 
 >  Lizette
 > 
 > 
 >  >
 >  -Original Message-
 >  > From: IBM
 > 
 Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
 On  > Behalf Of
 > willie bunter 
 > Sent: Friday, September 18, 2015 9:09  AM  > To:
 IBM-
 > m...@listserv.ua.edu 
 > Subject: UNABLE TO RESTORE DSN USING  DFDSS  > 
 >
 > Good  Day,  >  > I am
 trying  to restore a PS dsn using DFDSS with a
 > rename.  However I  have hit  a  >
 roadblock  with a few dsns with the same
 abend
 > MESSAGE :
 >  >  EXTENT REDUCTION FAILED FOR DATA
 SET  >  > Can someone suggest  how I can
 > bypass this problem?  Below is the
 abend
 >  message:
 > 
 >
 >  > ADR709E (001)-VDSS (01), AN
 ERROR OCCURRED  IN THE STORAGE
 >
 MANAGEMENT  > SUBSYSTEM  WHILE ALLOCATING DATA SET
 > SYSC12.SMFDUMP.G2725V00  >       
                   WITH  NEWNAME
 > HESP.SMFDUMP.G2725V00. SMS MESSAGES  >
 FOLLLOW.
 >  >  IGD17365I
 >  EXTENT REDUCTION FAILED FOR DATA SET
 >  >
 > 
 HESP.SMFDUMP.G2725V00
 >  > ADR809I
 >  (001)-VDSS (01), ADDITIONAL DIAGNOSTIC
 DATA FOR PRECEDING  > MESSAGE:
 > 
 >
 >                   
 SC=STANDARD MC= DC=
 >  >
 >  REQPRI=004569TRK
 REQSEC=50MB  REQVOLS=01  >  > Thanks.
 >  >
 > 
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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


Re: Dataset enqueue, how to find the culprit.

2015-09-18 Thread J O Skip Robinson
Well I'll be darned. I had not looked carefully at OP's message. That is 
*exactly* the context of the enqueue case I posted generically. SDAA004I is NDM 
or ConnectDirect depending on your perspective. We seem to have a lot of these 
self-clashes in our environment. I have not talked with the affected users, but 
it appears from the NDM control statements echoed in syslog that they are 
trying to send a data set from SystemX to SystemX with the same name. I suspect 
that they are requesting exclusive control of the 'target', i.e. OLD. But NDM 
is already using the data set as 'source', so it cannot obtain an exclusive 
enqueue for the same name. When the enqueue fails, the NDM process terminates, 
so a D GRS command a split second later shows no enqueue. That's how our 
(ancient) version of NDM works.

OP's situation may not be so simple, but I suggest looking the NDM process to 
see if there's a logic problem. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Friday, September 18, 2015 11:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dataset enqueue, how to find the culprit.

So, it will depend on how often the TSO message for enqueue is produced.  If it 
is not frequent, you may have to set slips or live with rerunning the job.

Or if it is frequent, you might try adding a first step with DISP=OLD on your 
file.  then you would have a better idea of what is doing it or have the job 
wait until the file is freed.

You did not show what type of process is being used when this occurs.  So if 
this is REXX/CLIST that does LM functions, or an IEBCOPY, or other

Perhaps if you could describe the process and functions being used that this 
condition occurred,  we might provide better diags or alternatives.



Lizette


>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>On Behalf Of Toni Cecil
>Sent: Friday, September 18, 2015 12:21 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Dataset enqueue, how to find the culprit.
>
>Hello,
>yesterday I got the following dsn enqueue:
>IKJ56225I DATA SET TLF.ZPT.JCL.CNTL ALREADY IN USE, TRY LATER+ IKJ56225I DATA 
>SET IS ALLOCATED TO ANOTHER JOB OR USER SDAA004I - RETURN=(DD),PERM=YES 
>DSN=TLF.ZPT.JCL.CNTL(ZZZTXXXB), DISP=SHR SDAB005I - ERR=0210, INFO=, 
>REQUESTED DATA SET NOT AVAILABLE.
>SDAB005I ALLOCATED TO ANOTHER JOB.
>
>Is there a way to find today, who was "locking" the pds library ?? I run DAF 
>tool against TLF.ZPT.JCL.CNTL to see if something was shown about the enqueue, 
>but I didn't find anything, am I doing something wrong ?? Or is there any 
>other utility that could be more appropriate to check this "problem" ??
>
>Many thx, A.Cecilio.


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


Re: Dataset enqueue, how to find the culprit.

2015-09-18 Thread Ted MacNEIL
There is NO SUCH THINGS as a culprit!
They are just doing their job and so are you. They just happened to collide.

-
-teD
-
  Original Message  
From: Richard Pinion
Sent: Friday, September 18, 2015 14:31
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Dataset enqueue, how to find the culprit.

I think this setting for RMF will cut an SMF record for enqueue conditions.
RMF must be started pointing to the member which specifies ENQ(DETAIL).

EDIT USER.PARMLIB(ERBRMF00) - 01.05 Columns 1 00080 
Command ===> Scroll ===> CSR 
14 ENQ(DETAIL) 



--- stars...@mindspring.com wrote:

From: Lizette Koehler 
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dataset enqueue, how to find the culprit.
Date: Fri, 18 Sep 2015 11:16:35 -0700

So, it will depend on how often the TSO message for enqueue is produced. If it 
is not frequent, you may have to set slips or live with rerunning the job.

Or if it is frequent, you might try adding a first step with DISP=OLD on your 
file. then you would have a better idea of what is doing it or have the job 
wait until the file is freed.

You did not show what type of process is being used when this occurs. So if 
this is REXX/CLIST that does LM functions, or an IEBCOPY, or other

Perhaps if you could describe the process and functions being used that this 
condition occurred, we might provide better diags or alternatives.



Lizette


>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Toni Cecil
>Sent: Friday, September 18, 2015 12:21 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Dataset enqueue, how to find the culprit.
>
>Hello,
>yesterday I got the following dsn enqueue:
>IKJ56225I DATA SET TLF.ZPT.JCL.CNTL ALREADY IN USE, TRY LATER+ IKJ56225I DATA 
>SET IS ALLOCATED TO ANOTHER JOB OR USER SDAA004I - RETURN=(DD),PERM=YES 
>DSN=TLF.ZPT.JCL.CNTL(ZZZTXXXB), DISP=SHR SDAB005I - ERR=0210, INFO=, 
>REQUESTED DATA SET NOT AVAILABLE.
>SDAB005I ALLOCATED TO ANOTHER JOB.
>
>Is there a way to find today, who was "locking" the pds library ?? I run DAF 
>tool against TLF.ZPT.JCL.CNTL to see if something was shown about the enqueue, 
>but I didn't find anything, am I doing something wrong ?? Or is there any 
>other utility that could be more appropriate to check this "problem" ??
>
>Many thx, A.Cecilio.
>

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




_
Netscape. Just the Net You Need.

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


Volkswagen Programmed Vehicle to Deactivate Pollution Control Systems

2015-09-18 Thread John P. Baker
http://www.foxbusiness.com/industries/2015/09/18/epa-says-vw-intentionally-v
iolates-clean-air-standards/?intcmp=hpbt1

 

In the referenced article, it is being reported that Volkswagen had their
programming staff intentionally program the computers controlling the
pollution control systems on certain 2008-2015 Audi and Volkswagen diesel
vehicles to activate the full pollution control systems ONLY when the
vehicle was undergoing official emissions testing.  At all other times, the
pollution control systems were inactive and the vehicles were putting out
emissions as high as 40 times the legal limit.

 

The company is facing $18 billion in fines.

 

It is unclear whether the Volkswagen executives who directed the scheme will
face criminal charges.

 

It is also unclear whether the programming staff who wrote the code will
face criminal charges.

 

Even though this is not a mainframe issue, it is an issue that directly
affects us and our industry.  Hackers are already a significant black eye.
This is much worse.  It makes legitimate programmers look suspect.

 

It raises the uncomfortable question of whether or not we can or should be
held criminally liable if we are directed to code a program or a change to a
program that we know would have the effect of violating the law and we then
knowingly proceed to code that program or a change to a program.

 

It has been suggested in the past that programmers should be licensed and/or
bonded.

 

I am not particularly fond of either idea.  However, I would like to hear
what others think.

 

John P. Baker

 


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


Re: Volkswagen Programmed Vehicle to Deactivate Pollution Control Systems

2015-09-18 Thread Richard Pinion
As an employee of a company who deals with HIPPA controlled/protected data, I 
feel
very uncomfortable knowing that I can be charged either with a civil or criminal
violation in the event that HIPPA data, under my control, is accidentally lost 
or
stolen.  And I am not talking about an intentional leak of protected patient
information.  What really floored me this year, when I took the yearly HIPPA
certification online class, was HIPPA is administered under the Office of Civil
Rights.

Regardless of my personal political theology, it makes me uncomfortable that
if I offend a person or persons, the friendly neighborhood OCR representative
could be asked to "look at" my activities as relating to HIPPA compliance.  I'm
sure an unbiased and diligent OCR employee might uncover some violation(s) if 
they
investigated long and hard enough. 



--- jba...@ngssallc.com wrote:

From: "John P. Baker" 
To:   IBM-MAIN@LISTSERV.UA.EDU
Subject: Volkswagen Programmed Vehicle to Deactivate Pollution Control Systems
Date: Fri, 18 Sep 2015 15:56:34 -0400

http://www.foxbusiness.com/industries/2015/09/18/epa-says-vw-intentionally-v
iolates-clean-air-standards/?intcmp=hpbt1

 

In the referenced article, it is being reported that Volkswagen had their
programming staff intentionally program the computers controlling the
pollution control systems on certain 2008-2015 Audi and Volkswagen diesel
vehicles to activate the full pollution control systems ONLY when the
vehicle was undergoing official emissions testing.  At all other times, the
pollution control systems were inactive and the vehicles were putting out
emissions as high as 40 times the legal limit.

 

The company is facing $18 billion in fines.

 

It is unclear whether the Volkswagen executives who directed the scheme will
face criminal charges.

 

It is also unclear whether the programming staff who wrote the code will
face criminal charges.

 

Even though this is not a mainframe issue, it is an issue that directly
affects us and our industry.  Hackers are already a significant black eye.
This is much worse.  It makes legitimate programmers look suspect.

 

It raises the uncomfortable question of whether or not we can or should be
held criminally liable if we are directed to code a program or a change to a
program that we know would have the effect of violating the law and we then
knowingly proceed to code that program or a change to a program.

 

It has been suggested in the past that programmers should be licensed and/or
bonded.

 

I am not particularly fond of either idea.  However, I would like to hear
what others think.

 

John P. Baker

 


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




_
Netscape.  Just the Net You Need.

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


Dataset enqueue, how to find the culprit.

2015-09-18 Thread Toni Cecil
Hello,
yesterday I got the following dsn enqueue:
IKJ56225I DATA SET TLF.ZPT.JCL.CNTL ALREADY IN USE, TRY LATER+
IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER
SDAA004I - RETURN=(DD),PERM=YES DSN=TLF.ZPT.JCL.CNTL(ZZZTXXXB),
DISP=SHR
SDAB005I - ERR=0210, INFO=, REQUESTED DATA SET NOT AVAILABLE.
SDAB005I ALLOCATED TO ANOTHER JOB.

Is there a way to find today, who was "locking" the pds library ?? I run
DAF tool against TLF.ZPT.JCL.CNTL to see if something was shown about the
enqueue, but I didn't find anything, am I doing something wrong ?? Or is
there any other utility that could be more appropriate to check this
"problem" ??

Many thx, A.Cecilio.

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


Re: UNABLE TO RESTORE DSN USING DFDSS

2015-09-18 Thread willie bunter
Lizette,

You are right.  There is not enough space on the volume.  Yes, I am restoring 
the dsns (which are SMS managed) with a rename.  The input dsns and output dsns 
are located on the same Storage group.

Thanks for the help.

On Fri, 9/18/15, Lizette Koehler  wrote:

 Subject: Re: UNABLE TO RESTORE DSN USING DFDSS
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Friday, September 18, 2015, 12:13 PM
 
 If you look up the
 IGD17365I - it states
 A SMS VTOC data set
 services extent reduction request for the data set
 failed.
 One possible reason for the failure
 is that not enough space could be obtained;
 other reasons are indicated by preceding
 messages.
 
 Do you have
 sufficient space on the volume for the restore?  Looks like
 you need
 at minimum 4569TRK 
 You did not show us your control cards so I am
 not sure if you are restoring to
 the same
 volume or different volume.
 
 Lizette
 
 
 >
 -Original Message-
 > From: IBM
 Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On
 > Behalf Of willie bunter
 > Sent: Friday, September 18, 2015 9:09
 AM
 > To: IBM-MAIN@LISTSERV.UA.EDU
 > Subject: UNABLE TO RESTORE DSN USING
 DFDSS
 > 
 > Good
 Day,
 > 
 > I am trying
 to restore a PS dsn using DFDSS with a rename.  However I
 have hit
 a
 > roadblock
 with a few dsns with the same abend MESSAGE :
 >  EXTENT REDUCTION FAILED FOR DATA SET
 > 
 > Can someone suggest
 how I can bypass this problem?  Below is the abend
 message:
 > 
 > ADR709E (001)-VDSS (01), AN ERROR OCCURRED
 IN THE STORAGE MANAGEMENT
 > SUBSYSTEM
 WHILE ALLOCATING DATA SET SYSC12.SMFDUMP.G2725V00
 >                          WITH
 NEWNAME HESP.SMFDUMP.G2725V00. SMS MESSAGES
 > FOLLLOW.
 >  IGD17365I
 EXTENT REDUCTION FAILED FOR DATA SET
 > 
 HESP.SMFDUMP.G2725V00
 > ADR809I
 (001)-VDSS (01), ADDITIONAL DIAGNOSTIC DATA FOR PRECEDING
 > MESSAGE:
 >       
                   SC=STANDARD MC= DC=
 >                         
 REQPRI=004569TRK REQSEC=50MB  REQVOLS=01
 > 
 > Thanks.
 > 
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN


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


Re: Dataset enqueue, how to find the culprit.

2015-09-18 Thread Jousma, David
One of the quickest ways, is to go to ISPF option 3.4, and pull up that 
dataset, and do a "R" to rename it(don’t really rename it though).  When it 
says 'dataset in use", hit PF1 and you get a list of jobs with enqueues on it.  

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Toni Cecil
Sent: Friday, September 18, 2015 12:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Dataset enqueue, how to find the culprit.

Hello,
yesterday I got the following dsn enqueue:
IKJ56225I DATA SET TLF.ZPT.JCL.CNTL ALREADY IN USE, TRY LATER+ IKJ56225I DATA 
SET IS ALLOCATED TO ANOTHER JOB OR USER SDAA004I - RETURN=(DD),PERM=YES 
DSN=TLF.ZPT.JCL.CNTL(ZZZTXXXB), DISP=SHR SDAB005I - ERR=0210, INFO=, 
REQUESTED DATA SET NOT AVAILABLE.
SDAB005I ALLOCATED TO ANOTHER JOB.

Is there a way to find today, who was "locking" the pds library ?? I run DAF 
tool against TLF.ZPT.JCL.CNTL to see if something was shown about the enqueue, 
but I didn't find anything, am I doing something wrong ?? Or is there any other 
utility that could be more appropriate to check this "problem" ??

Many thx, A.Cecilio.

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

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


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


Re: Dataset enqueue, how to find the culprit.

2015-09-18 Thread Lizette Koehler
If you have RMF setup for ISPF, and the RMF VSAM files are available, you can 
use the ISPF RMF tool to go back in time for the enqueue information.

Did you look in syslog for any GRS information?
Did you go and look and see what other jobs were running when this job had this 
issue?


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Toni Cecil
> Sent: Friday, September 18, 2015 9:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Dataset enqueue, how to find the culprit.
> 
> Hello,
> yesterday I got the following dsn enqueue:
> IKJ56225I DATA SET TLF.ZPT.JCL.CNTL ALREADY IN USE, TRY LATER+ IKJ56225I DATA
> SET IS ALLOCATED TO ANOTHER JOB OR USER SDAA004I - RETURN=(DD),PERM=YES
> DSN=TLF.ZPT.JCL.CNTL(ZZZTXXXB), DISP=SHR SDAB005I - ERR=0210, INFO=,
> REQUESTED DATA SET NOT AVAILABLE.
> SDAB005I ALLOCATED TO ANOTHER JOB.
> 
> Is there a way to find today, who was "locking" the pds library ?? I run DAF 
> tool
> against TLF.ZPT.JCL.CNTL to see if something was shown about the enqueue, but 
> I
> didn't find anything, am I doing something wrong ?? Or is there any other 
> utility that
> could be more appropriate to check this "problem" ??
> 
> Many thx, A.Cecilio.
> 

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


Re: Dataset enqueue, how to find the culprit.

2015-09-18 Thread Jousma, David
Sorry, you have to hit PF1 twice to get the display I mentioned.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Friday, September 18, 2015 12:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dataset enqueue, how to find the culprit.

One of the quickest ways, is to go to ISPF option 3.4, and pull up that 
dataset, and do a "R" to rename it(don’t really rename it though).  When it 
says 'dataset in use", hit PF1 and you get a list of jobs with enqueues on it.  

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Toni Cecil
Sent: Friday, September 18, 2015 12:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Dataset enqueue, how to find the culprit.

Hello,
yesterday I got the following dsn enqueue:
IKJ56225I DATA SET TLF.ZPT.JCL.CNTL ALREADY IN USE, TRY LATER+ IKJ56225I DATA 
SET IS ALLOCATED TO ANOTHER JOB OR USER SDAA004I - RETURN=(DD),PERM=YES 
DSN=TLF.ZPT.JCL.CNTL(ZZZTXXXB), DISP=SHR SDAB005I - ERR=0210, INFO=, 
REQUESTED DATA SET NOT AVAILABLE.
SDAB005I ALLOCATED TO ANOTHER JOB.

Is there a way to find today, who was "locking" the pds library ?? I run DAF 
tool against TLF.ZPT.JCL.CNTL to see if something was shown about the enqueue, 
but I didn't find anything, am I doing something wrong ?? Or is there any other 
utility that could be more appropriate to check this "problem" ??

Many thx, A.Cecilio.

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

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


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

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


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


Re: Dataset enqueue, how to find the culprit.

2015-09-18 Thread Lizette Koehler
That only works if the file is allocated now.

I think the OP wants to go back in time to find the enqueue.  The enqueue 
happened yesterday and today I want to know who had the file.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jousma, David
> Sent: Friday, September 18, 2015 9:25 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Dataset enqueue, how to find the culprit.
> 
> Sorry, you have to hit PF1 twice to get the display I mentioned.
> 
> _
> Dave Jousma
> Assistant Vice President, Mainframe Engineering david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f
> 616.653.2717
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jousma, David
> Sent: Friday, September 18, 2015 12:23 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Dataset enqueue, how to find the culprit.
> 
> One of the quickest ways, is to go to ISPF option 3.4, and pull up that 
> dataset, and do
> a "R" to rename it(don’t really rename it though).  When it says 'dataset in 
> use", hit
> PF1 and you get a list of jobs with enqueues on it.
> 
> _
> Dave Jousma
> Assistant Vice President, Mainframe Engineering david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f
> 616.653.2717
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Toni Cecil
> Sent: Friday, September 18, 2015 12:21 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Dataset enqueue, how to find the culprit.
> 
> Hello,
> yesterday I got the following dsn enqueue:
> IKJ56225I DATA SET TLF.ZPT.JCL.CNTL ALREADY IN USE, TRY LATER+ IKJ56225I DATA
> SET IS ALLOCATED TO ANOTHER JOB OR USER SDAA004I - RETURN=(DD),PERM=YES
> DSN=TLF.ZPT.JCL.CNTL(ZZZTXXXB), DISP=SHR SDAB005I - ERR=0210, INFO=,
> REQUESTED DATA SET NOT AVAILABLE.
> SDAB005I ALLOCATED TO ANOTHER JOB.
> 
> Is there a way to find today, who was "locking" the pds library ?? I run DAF 
> tool
> against TLF.ZPT.JCL.CNTL to see if something was shown about the enqueue, but 
> I
> didn't find anything, am I doing something wrong ?? Or is there any other 
> utility that
> could be more appropriate to check this "problem" ??
> 
> Many thx, A.Cecilio.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> This e-mail transmission contains information that is confidential and may be
> privileged.   It is intended only for the addressee(s) named above. If you 
> receive this
> e-mail in error, please do not read, copy or disseminate it in any manner. If 
> you are
> not the intended recipient, any disclosure, copying, distribution or use of 
> the
> contents of this information is prohibited. Please reply to the message 
> immediately
> by informing the sender that the message was misdirected. After replying, 
> please
> erase it from your computer system. Your assistance in correcting this error 
> is
> appreciated.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> This e-mail transmission contains information that is confidential and may be
> privileged.   It is intended only for the addressee(s) named above. If you 
> receive this
> e-mail in error, please do not read, copy or disseminate it in any manner. If 
> you are
> not the intended recipient, any disclosure, copying, distribution or use of 
> the
> contents of this information is prohibited. Please reply to the message 
> immediately
> by informing the sender that the message was misdirected. After replying, 
> please
> erase it from your computer system. Your assistance in correcting this error 
> is
> appreciated.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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


Re: UNABLE TO RESTORE DSN USING DFDSS

2015-09-18 Thread Lizette Koehler
The best options are always to look up message to see if they give a clue to
your issue.  It is faster than waiting on the list.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of willie bunter
> Sent: Friday, September 18, 2015 9:22 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: UNABLE TO RESTORE DSN USING DFDSS
> 
> Lizette,
> 
> You are right.  There is not enough space on the volume.  Yes, I am restoring
the
> dsns (which are SMS managed) with a rename.  The input dsns and output dsns
are
> located on the same Storage group.
> 
> Thanks for the help.
> 
> On Fri, 9/18/15, Lizette Koehler  wrote:
> 
>  Subject: Re: UNABLE TO RESTORE DSN USING DFDSS
>  To: IBM-MAIN@LISTSERV.UA.EDU
>  Received: Friday, September 18, 2015, 12:13 PM
> 
>  If you look up the
>  IGD17365I - it states
>  A SMS VTOC data set
>  services extent reduction request for the data set  failed.
>  One possible reason for the failure
>  is that not enough space could be obtained;  other reasons are indicated by
> preceding  messages.
> 
>  Do you have
>  sufficient space on the volume for the restore?  Looks like  you need  at
minimum
> 4569TRK  You did not show us your control cards so I am  not sure if you are
> restoring to  the same  volume or different volume.
> 
>  Lizette
> 
> 
>  >
>  -Original Message-
>  > From: IBM
>  Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]  On  > Behalf Of
> willie bunter  > Sent: Friday, September 18, 2015 9:09  AM  > To: IBM-
> m...@listserv.ua.edu  > Subject: UNABLE TO RESTORE DSN USING  DFDSS  >  >
> Good  Day,  >  > I am trying  to restore a PS dsn using DFDSS with a
> rename.  However I  have hit  a  > roadblock  with a few dsns with the same
abend
> MESSAGE :
>  >  EXTENT REDUCTION FAILED FOR DATA SET  >  > Can someone suggest  how I can
> bypass this problem?  Below is the abend
>  message:
>  >
>  > ADR709E (001)-VDSS (01), AN ERROR OCCURRED  IN THE STORAGE
> MANAGEMENT  > SUBSYSTEM  WHILE ALLOCATING DATA SET
> SYSC12.SMFDUMP.G2725V00  >                          WITH  NEWNAME
> HESP.SMFDUMP.G2725V00. SMS MESSAGES  > FOLLLOW.
>  >  IGD17365I
>  EXTENT REDUCTION FAILED FOR DATA SET
>  >
>  HESP.SMFDUMP.G2725V00
>  > ADR809I
>  (001)-VDSS (01), ADDITIONAL DIAGNOSTIC DATA FOR PRECEDING  > MESSAGE:
>  >
>                    SC=STANDARD MC= DC=
>  >
>  REQPRI=004569TRK REQSEC=50MB  REQVOLS=01  >  > Thanks.
>  >
> 

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


UNABLE TO RESTORE DSN USING DFDSS

2015-09-18 Thread willie bunter
Good Day,

I am trying to restore a PS dsn using DFDSS with a rename.  However I have hit 
a roadblock with a few dsns with the same abend MESSAGE :
 EXTENT REDUCTION FAILED FOR DATA SET

Can someone suggest how I can bypass this problem?  Below is the abend message:

ADR709E (001)-VDSS (01), AN ERROR OCCURRED IN THE STORAGE MANAGEMENT SUBSYSTEM 
WHILE ALLOCATING DATA SET SYSC12.SMFDUMP.G2725V00
 WITH NEWNAME HESP.SMFDUMP.G2725V00. SMS MESSAGES 
FOLLLOW.
 IGD17365I EXTENT REDUCTION FAILED FOR DATA SET
 HESP.SMFDUMP.G2725V00   
ADR809I (001)-VDSS (01), ADDITIONAL DIAGNOSTIC DATA FOR PRECEDING MESSAGE: 
 SC=STANDARD MC= DC=   
 REQPRI=004569TRK REQSEC=50MB  REQVOLS=01  

Thanks.

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


Re: UNABLE TO RESTORE DSN USING DFDSS

2015-09-18 Thread Lizette Koehler
If you look up the IGD17365I - it states
A SMS VTOC data set services extent reduction request for the data set failed.
One possible reason for the failure is that not enough space could be obtained;
other reasons are indicated by preceding messages.

Do you have sufficient space on the volume for the restore?  Looks like you need
at minimum 4569TRK 
You did not show us your control cards so I am not sure if you are restoring to
the same volume or different volume.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of willie bunter
> Sent: Friday, September 18, 2015 9:09 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: UNABLE TO RESTORE DSN USING DFDSS
> 
> Good Day,
> 
> I am trying to restore a PS dsn using DFDSS with a rename.  However I have hit
a
> roadblock with a few dsns with the same abend MESSAGE :
>  EXTENT REDUCTION FAILED FOR DATA SET
> 
> Can someone suggest how I can bypass this problem?  Below is the abend
message:
> 
> ADR709E (001)-VDSS (01), AN ERROR OCCURRED IN THE STORAGE MANAGEMENT
> SUBSYSTEM WHILE ALLOCATING DATA SET SYSC12.SMFDUMP.G2725V00
>  WITH NEWNAME HESP.SMFDUMP.G2725V00. SMS MESSAGES
> FOLLLOW.
>  IGD17365I EXTENT REDUCTION FAILED FOR DATA SET
>  HESP.SMFDUMP.G2725V00
> ADR809I (001)-VDSS (01), ADDITIONAL DIAGNOSTIC DATA FOR PRECEDING
> MESSAGE:
>  SC=STANDARD MC= DC=
>  REQPRI=004569TRK REQSEC=50MB  REQVOLS=01
> 
> Thanks.
> 

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


Re: IPCS BLS18028I message suppression

2015-09-18 Thread J O Skip Robinson
I have no particular insight into this design, but I know a few things about 
TPUT vs. PUTLINE. For one thing, TPUT does not even work at all in batch. 
Neither can it be captured by OUTTRAP in foreground or background. PUTLINE 
works for both. So from the evidence presented, I would guess that BLS18028I 
issued in batch via PUTLINE but interactively via TPUT. So why the difference? 
Sounds like a bug, whether at the design level or in implementation. 

You could try first to get an APAR. Sigh, good luck. Failing that an RFE. I 
can't imagine that IBM would defend the current function as, Yes, that's 
exactly what we had in mind. Like the cat who bounces off the patio glass and 
tries to look purposefully nonchalant. An oops is an oops.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Hardee, Chuck
Sent: Friday, September 18, 2015 8:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPCS BLS18028I message suppression

Interesting you should suggest that.
I did a batch IPCS run with my REXX and sure enough, in TSO/Batch the BLS18028I 
is captured by OUTTRAP and my REXX displays it as expected.

Question now is, why isn't it captured with the REXX is executed interactively?

So, if IPCS is executed in interactive TSO, the BLS18028I messages is issued to 
the "print" file that is displayed upon the terminal.
If, however, the same REXX is executed in TSO/Batch, the message is captured by 
OUTTRAP and placed in the stem that was passed in the first OUTTRAP call. It 
does not appear in the print file nor on the output associated with SYSTSPRT.

Interesting.

Since the primary use of this REXX will be batch as opposed to interactive, I 
can live with it I guess.
Just wish it would work the same regardless of environment.

C-

Charles (Chuck) Hardee
Senior Systems Engineer/Database Administration EAS Information Technology

Thermo Fisher Scientific
300 Industry Drive | Pittsburgh, PA 15275 Phone +1 (724) 517-2633 | Mobile +1 
(412) 877-2809 | FAX: +1 (412) 490-9230 chuck.har...@thermofisher.com  | 
www.thermofisher.com

WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this 
e-mail or the information herein by anyone other than the intended recipient, 
or an employee or agent of a system responsible for delivering the message to 
the intended recipient, is prohibited. If you are not the intended recipient, 
please inform the sender and delete all copies.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of J R
Sent: Friday, September 18, 2015 10:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPCS BLS18028I message suppression

Assuming it is a TPUT and assuming your logic doesn't depend on it, (yeah, I 
know) could you run it in batch?  This may prevent the message messing up your 
report.  
 

 
> Date: Fri, 18 Sep 2015 14:12:45 +
> From: chuck.hardee
/snip/
> Charles (Chuck) Hardee
> Senior Systems Engineer/Database Administration EAS Information 
> Technology

> > It's more frustrating than technical, but I'm trying to produce a 
> > custom
> report from
> > the dump and this message gets in the way of the report's information.

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


Re: Dataset enqueue, how to find the culprit.

2015-09-18 Thread J O Skip Robinson
As others have pointed out, enqueue is often a fleeting problem. By the time 
you get around to looking into it, it's long gone. After experiencing this 
problem a while back, we instructed our automation product to issue a D GRS 
command at the time of the conflict based on msgid IKJ56225I.  

IKJ56225I DATA SET already-in-use-dataset ALREADY IN USE, TRY LATER+
IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER

D GRS,RES=(*, already-in-use-dataset)  

If you decide to implement a similar process, be aware of some gotchas. (1) The 
msgid appears twice. If you're not careful, you'll be issuing D GRS for dataset 
'IS'. Not a big deal, but it looks squirrelly. (2) The command itself might be 
issued too late to capture the contention. It can happen, for instance, that a 
task is actually enqueuing on itself (!). If the task terminates upon the 
enqueue, D GRS will find no contention. As odd as this sounds, we have seen 
cases like this. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steely, Mark
Sent: Friday, September 18, 2015 9:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dataset enqueue, how to find the culprit.

I created a REXX called WHI (who has it). Here is the code:

PROC 1 DSN   
/* CLRSCRN */
ISRDDN E 

Then in 3.4 enter WHI and it will display any enqueue. 

Thanks

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Friday, September 18, 2015 11:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dataset enqueue, how to find the culprit.

Sorry, you have to hit PF1 twice to get the display I mentioned.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Friday, September 18, 2015 12:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dataset enqueue, how to find the culprit.

One of the quickest ways, is to go to ISPF option 3.4, and pull up that 
dataset, and do a "R" to rename it(don’t really rename it though).  When it 
says 'dataset in use", hit PF1 and you get a list of jobs with enqueues on it.  

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Toni Cecil
Sent: Friday, September 18, 2015 12:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Dataset enqueue, how to find the culprit.

Hello,
yesterday I got the following dsn enqueue:
IKJ56225I DATA SET TLF.ZPT.JCL.CNTL ALREADY IN USE, TRY LATER+ IKJ56225I DATA 
SET IS ALLOCATED TO ANOTHER JOB OR USER SDAA004I - RETURN=(DD),PERM=YES 
DSN=TLF.ZPT.JCL.CNTL(ZZZTXXXB), DISP=SHR SDAB005I - ERR=0210, INFO=, 
REQUESTED DATA SET NOT AVAILABLE.
SDAB005I ALLOCATED TO ANOTHER JOB.

Is there a way to find today, who was "locking" the pds library ?? I run DAF 
tool against TLF.ZPT.JCL.CNTL to see if something was shown about the enqueue, 
but I didn't find anything, am I doing something wrong ?? Or is there any other 
utility that could be more appropriate to check this "problem" ??

Many thx, A.Cecilio.


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