Re: HSM question

[Richard Marchant]

Tony,

When DFHSM does migration and backup by dataset (not an auto-function) it
will not MARKFULL the tape.

Make sure you users are not doing this.

An HBACKUP or a HMIGRATE command should send the result to ML1 DASD unless
ML2 is specified on the HMIGRATE command.

There are settings in the management class to stop the users issuing these
commands. .

Richard

On Fri, Nov 25, 2016 at 12:39 AM, Tony Thigpen  wrote:

> That's what I thought, but it does not seem to be working. So, I figured I
> was misreading or doing something wrong.
>
> Tony Thigpen
>
>
> retired mainframer wrote on 11/24/2016 04:42 PM:
>
>> Doesn't SETSYS PARTIALTAPE(BAKCUP(MARKFULL)) do what you want?
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Tony Thigpen
>> Sent: Thursday, November 24, 2016 7:30 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: HSM question
>>
>> The elapsed time is 10 minutes.
>>
>> Before we get off-track too much, the end result we are looking for is:
>> We want the HSM backup process to *always* use a scratch tape. We never
>> want it to ask for an existing tape to append to.
>>
>> --
>> 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: zIIP Processor availability Display

[Peter Hunkeler]

>On a z12 Mainframe with two physical box, with 8 LPARS on a Sysplex 
>configuration and Coupling Facility option, there are 6 Lpars for production 
>and 2 Lpars for previous environment (development or test); how can I display 
>if zIIP processor are assigned or used by Lpars of previous environments?


If you have RMF, the CPC report in RMF III or the CPU Activity report from the 
RMF Postprocessor will show the zIIP assignment and usage by LPAR. I guess CMF 
has similar reports.


--
Peter Hunkeler



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

Re: zIIP Processor availability Display

[Roger Lowe]

On Fri, 25 Nov 2016 03:42:18 +, Carlos Cordero  
wrote:

>Hi all..
>
>
>On a z12 Mainframe with two physical box, with 8 LPARS on a Sysplex 
>configuration and Coupling Facility option, there are 6 Lpars for production 
>and 2 Lpars for previous environment (development or test); how can I display 
>if zIIP processor are assigned or used by Lpars of previous environments?
>
>
>I hope my question is clear.
>

D M=CPU

Roger

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

zIIP Processor availability Display

[Carlos Cordero]

Hi all..


On a z12 Mainframe with two physical box, with 8 LPARS on a Sysplex 
configuration and Coupling Facility option, there are 6 Lpars for production 
and 2 Lpars for previous environment (development or test); how can I display 
if zIIP processor are assigned or used by Lpars of previous environments?


I hope my question is clear.



Thanks in advance

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

Re: HSM question

[Tony Thigpen]

That's what I thought, but it does not seem to be working. So, I figured 
I was misreading or doing something wrong.


Tony Thigpen

retired mainframer wrote on 11/24/2016 04:42 PM:

Doesn't SETSYS PARTIALTAPE(BAKCUP(MARKFULL)) do what you want?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: Thursday, November 24, 2016 7:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: HSM question

The elapsed time is 10 minutes.

Before we get off-track too much, the end result we are looking for is:
We want the HSM backup process to *always* use a scratch tape. We never
want it to ask for an existing tape to append to.

--
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: HSM question

[retired mainframer]

Doesn't SETSYS PARTIALTAPE(BAKCUP(MARKFULL)) do what you want?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: Thursday, November 24, 2016 7:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: HSM question

The elapsed time is 10 minutes.

Before we get off-track too much, the end result we are looking for is:
We want the HSM backup process to *always* use a scratch tape. We never 
want it to ask for an existing tape to append to.

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

Re: A true discussion in today's world (at least here)

[scott Ford]

My father an engineer in the hard school of knocks would say cars keep the
parts companies in business. Being a ISV, software has bugs, enhancements
which have to be resolved or written and implemented. I can tell you from a
lot of experience some management ppl don't 'get it' ...

My $.02 worth

Scott

On Thursday, November 24, 2016, Mick Graley  wrote:

> I'm a DB2 SysAdm/SysProg and DB2 maint always has reams of hold data. The
> longer you leave it the bigger the job to wade through it all and build the
> required jobs. Multiply it by many DB2 sub-systems and the job gets bigger
> and bigger. You have to have the toleration fixes on the current release of
> DB2 before you can upgrade to the next release (in case of fallback to the
> old release with the new release catalog/directory structure) and that can
> be a big job if you are way back on maintenance.
> Cheers,
> Mick.
>
>
> On 24 November 2016 at 05:35, Edward Gould  > wrote:
>
> > > On Nov 23, 2016, at 8:32 PM, Joel C. Ewing  > wrote:
> > >
> > > I think the car analogy with computer systems  breaks down on a number
> > > of points (at least in the case of mainframes):
> > >(1) while bleeding-edge-current is certainly not essential, the
> > > further you get behind on software maintenance, the more costly it gets
> > > in terms of time and person-hours to get reasonably current; and
> without
> > > being reasonably current you may not be able to utilize new hardware
> > > that could be more cost effective, or needed when old hardware dies, or
> > > needed to adapt to growing business requirements.  The  cost of failure
> > > to do preventive maintenance on a car is bounded by the time and cost
> > > for replacement transportation, no matter how much maintenance was
> > skipped.
> > >(2)software maintenance relating to security or data exposures may
> > > need prompt attention to avoid much more expensive data loss or data
> > > exposure scenarios, which may also have serious legal implications.
> > > Failure to do preventive maintenance on a car doesn't generally make it
> > > more susceptible to hackers or have legal implications, unless you fail
> > > to repair an obvious safety hazard and that results in a
> personal-injury
> > > accident or death..
> > >(3)Unexpected failures of a lesser-maintained car more often than
> > > not just causes a temporary loss of availability which with sufficient
> > > funds can be easily resolved, as there are many ready substitutes for
> > > the basic function of transportation.  A corporate computer system has
> > > company-specific data and company-specific applications which cannot
> > > just be replaced by any generic computer system, and it may be
> > > impossible for the company to stay in business very long without that
> > > data and those applications.  Recovery from some software failures that
> > > result in data loss is only possible with adequate DR planning in
> place,
> > > and if adequate planning was not in place, recovery may not even be
> > > possible at any price.  While I believe a valid argument can be made
> > > against applying maintenance just for the sake of maintenance, some of
> > > the problems addressed by HIPER PTFs are so dire you really don't want
> > > to wait for that failure to occur before installing the fix.
> > >
> > > Even with a car, while it may be cost-effective to avoid or stretch out
> > > some preventive or recommended maintenance, I strongly suspect it would
> > > not on balance be cheaper for you to take that to the extreme and, say,
> > > never change the engine oil (unless of course your plan is to sell
> > > the.car after a few years without disclosing the potential shortened
> > > engine life and cheat the next owner).
> > >Joel C. Ewing
> > about 20 years ago I worked at such a place. They did NOT believe in
> > applying maintenance.
> > Along comes the Y2K problem and they were in a bind (to say the least).
> > They decided to order a servpac (new at the time).
> > They were a  big user of DB2 (I have no knowledge of it) but they were
> > really hurting in order to get up to snuff.
> > They were non going to ORDER COBOL (current as it cost $5 more than the
> > old) then LE hit them in the face and they *HAD* to order that. That
> almost
> > burst their gut.
> > I am glad I got out of there.
> > Ed
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu  with the message:
> INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu  with the message:
> INFO IBM-MAIN
>

--
For IBM-MAIN 

Re: HCM security

[Jesse 1 Robinson]

We use HCM. I cannot find any RACF profile specifically for HCM. Since HCM 
involves downloading an IODF and later uploading the modified IODF back to the 
host, I suspect that HCM is controlled by the HCD profiles: CBD.* in class 
FACILITY plus related DSN profiles. 

.
.
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 R.S.
Sent: Thursday, November 24, 2016 8:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):HCM security

 From the RTFM: HCM access to the host can be controlled using CL(APPL) 
CBDSERVE profile.
But it seems to be true only for z/VM.

Q: Is there any profile controlling user access to HCM on z/OS ?

--
Radoslaw Skorupka
Lodz, Poland

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

HCM security

[R.S.]

From the RTFM: HCM access to the host can be controlled using CL(APPL) 
CBDSERVE profile.

But it seems to be true only for z/VM.

Q: Is there any profile controlling user access to HCM on z/OS ?

--
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: TSO Setup on SSH

[Jack J. Woehr]

venkat kulkarni wrote:

Also please help me to find difference in tn3270 and tn3270e and when
should we use tn3270e instead of tn3270.


I believe that basically tn3270e is the modern protocol currently in use and is effectively what is meant when people 
talk about the tn3270 protocol.


http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.halz002/telnet_tn3270e_conn_mode.htm
https://tools.ietf.org/html/rfc2355

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

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

Re: HSM question

[Tony Thigpen]

The elapsed time is 10 minutes.

Before we get off-track too much, the end result we are looking for is:
We want the HSM backup process to *always* use a scratch tape. We never 
want it to ask for an existing tape to append to.


We will recycle the tapes to combine them at our convenience.

But, as best I can tell, the HSM control parms are already set to not 
use an existing tape:

SETSYS
  PARTIALTAPE(
   BACKUP(MARKFULL) -
   MIGRATION(MARKFULL))
SETSYS
  SELECTVOLUME(
  BACKUP(SCRATCH)
  MIGRATION(SCRATCH) -
  DUMP(SCRATCH))

Tony Thigpen

Elardus Engelbrecht wrote on 11/24/2016 09:09 AM:

Tony Thigpen wrote:


The remote operator is a human.
Tape management system is CA1
Still researching logs.


Thanks. I see that output and logs you gave to Lizette.

I see you have MOUNT WAIT TIME=010 MINUTE(S), but what are the [elapsed] times 
for these messages and reply?

*IEC501A M 0C01,015010,SL,COMP,DFSMSHSM,DFSMSHSM,DFHSM.BACKTAPE.DATASET
*0037 ARC0310A CAN TAPE 015010 BE MOUNTED? REPLY Y OR N
   R 37,N

You said it asked for another mount, is that for this message for which you 
drove in your car to do that mount?

ARC0421I BACKUP VOLUME 015010 IS NOW MARKED FULL

Just probing questions, because when I was a HSM admin ages ago, I got many 
gray hairs about those mounts...

It is one of those things for which an autoreply is not going to work always in 
a 'lights-out 24/7' environment.

Good luck! You will need all the help you are deserving. I hope you can get a 
good solution for this PITA.

Groete / Greetings
Elardus Engelbrecht

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




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

Re: HSM question

[Lizette Koehler]

Other options:
 1) Use Automation tool or MPF to automatically respond Y or N 
 2) Find out where the tape resides physically.  Is it on a desk or next to the 
tape drives?
 
At some shops I have worked at, we automatically responded N to this message 
and just let DFHSM pick it up next time and allow it to move on to the next 
task.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Thursday, November 24, 2016 7:36 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: HSM question
> 
> So I would say your MOUNTWAITTIME of 10mins is too short.  The default for HSM
> is 15 mins if it is not coded.
> 
> You probably need to do the following
> 
>  1)  Change the mount wait time to make it longer.
>  2)  Review the history of tape mounts in general and see what is going on
> when HSM is getting the ARC0310A
>  3)  Review IBMLINK for OS/390 V2.10 and see if there are any ptfs you have
> not installed on DFHSM.
>  4)  Look at the running STC JCL for DFHSM. See what Parmlib member it is
> running with.
>  What you think is the right dataset(member) might be different in the STC
> JCL.
> 
> When working with mount wait times, if HSM is held up too long, it may cause
> issues as well.
> 
> See if the mount wait time in the ARCCMDxx member is the same as the Q SETSYS
> information.
> 
> See when the last date the ARCCMDxx member was changed.  If recent, then it is
> possible someone updated it
> 
> 
> There are tools to help with analyzing tape mount issues.  IBM has Volume
> Mount Analyzer, as well as the TAPETOOLS.
> 
> If you have other products that can read SMF, then you could use those as
> well.
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Elardus Engelbrecht
> > Sent: Thursday, November 24, 2016 7:09 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: HSM question
> >
> > Tony Thigpen wrote:
> >
> > >The remote operator is a human.
> > >Tape management system is CA1
> > >Still researching logs.
> >
> > Thanks. I see that output and logs you gave to Lizette.
> >
> > I see you have MOUNT WAIT TIME=010 MINUTE(S), but what are the
> > [elapsed] times for these messages and reply?
> >
> > *IEC501A M
> > 0C01,015010,SL,COMP,DFSMSHSM,DFSMSHSM,DFHSM.BACKTAPE.DATASET
> > *0037 ARC0310A CAN TAPE 015010 BE MOUNTED? REPLY Y OR N
> >   R 37,N
> >
> > You said it asked for another mount, is that for this message for
> > which you drove in your car to do that mount?
> >
> > ARC0421I BACKUP VOLUME 015010 IS NOW MARKED FULL
> >
> > Just probing questions, because when I was a HSM admin ages ago, I got
> > many gray hairs about those mounts...
> >
> > It is one of those things for which an autoreply is not going to work
> > always in a 'lights-out 24/7' environment.
> >
> > Good luck! You will need all the help you are deserving. I hope you
> > can get a good solution for this PITA.
> >
> > 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: HSM question

[Lizette Koehler]

So I would say your MOUNTWAITTIME of 10mins is too short.  The default for HSM 
is 15 mins if it is not coded.

You probably need to do the following

 1)  Change the mount wait time to make it longer.
 2)  Review the history of tape mounts in general and see what is going on when 
HSM is getting the ARC0310A
 3)  Review IBMLINK for OS/390 V2.10 and see if there are any ptfs you have not 
installed on DFHSM.  
 4)  Look at the running STC JCL for DFHSM. See what Parmlib member it is 
running with.  
 What you think is the right dataset(member) might be different in the STC 
JCL.

When working with mount wait times, if HSM is held up too long, it may cause 
issues as well.

See if the mount wait time in the ARCCMDxx member is the same as the Q SETSYS 
information.

See when the last date the ARCCMDxx member was changed.  If recent, then it is 
possible someone updated it


There are tools to help with analyzing tape mount issues.  IBM has Volume Mount 
Analyzer, as well as the TAPETOOLS.

If you have other products that can read SMF, then you could use those as well.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Elardus Engelbrecht
> Sent: Thursday, November 24, 2016 7:09 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: HSM question
> 
> Tony Thigpen wrote:
> 
> >The remote operator is a human.
> >Tape management system is CA1
> >Still researching logs.
> 
> Thanks. I see that output and logs you gave to Lizette.
> 
> I see you have MOUNT WAIT TIME=010 MINUTE(S), but what are the [elapsed] times
> for these messages and reply?
> 
> *IEC501A M 0C01,015010,SL,COMP,DFSMSHSM,DFSMSHSM,DFHSM.BACKTAPE.DATASET
> *0037 ARC0310A CAN TAPE 015010 BE MOUNTED? REPLY Y OR N
>   R 37,N
> 
> You said it asked for another mount, is that for this message for which you
> drove in your car to do that mount?
> 
> ARC0421I BACKUP VOLUME 015010 IS NOW MARKED FULL
> 
> Just probing questions, because when I was a HSM admin ages ago, I got many
> gray hairs about those mounts...
> 
> It is one of those things for which an autoreply is not going to work always
> in a 'lights-out 24/7' environment.
> 
> Good luck! You will need all the help you are deserving. I hope you can get a
> good solution for this PITA.
> 
> 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

IBM Survey on Documents

[Lizette Koehler]

I found this entry while doing some research.  I thought I would share it
in-case someone else wants to provide IBM Input. It is a document survey

https://www.surveygizmo.com/s3/3091187/IBM-z-OS-Product-Documentation-Survey-Fal
l-2016?cm_mc_uid=70282342604914785249342_mc_sid_5020=1479995058

or tinyurl
http://tinyurl.com/zzqj6a6




Lizette Koehler
statistics: A precise and logical method for stating a half-truth inaccurately

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

Re: HSM question

[Elardus Engelbrecht]

Tony Thigpen wrote:

>The remote operator is a human.
>Tape management system is CA1
>Still researching logs.

Thanks. I see that output and logs you gave to Lizette.

I see you have MOUNT WAIT TIME=010 MINUTE(S), but what are the [elapsed] times 
for these messages and reply?

*IEC501A M 0C01,015010,SL,COMP,DFSMSHSM,DFSMSHSM,DFHSM.BACKTAPE.DATASET
*0037 ARC0310A CAN TAPE 015010 BE MOUNTED? REPLY Y OR N
  R 37,N

You said it asked for another mount, is that for this message for which you 
drove in your car to do that mount? 

ARC0421I BACKUP VOLUME 015010 IS NOW MARKED FULL

Just probing questions, because when I was a HSM admin ages ago, I got many 
gray hairs about those mounts...

It is one of those things for which an autoreply is not going to work always in 
a 'lights-out 24/7' environment.

Good luck! You will need all the help you are deserving. I hope you can get a 
good solution for this PITA.

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: HSM question

[Lizette Koehler]

So what was your analysis of the ARC0310A message

ARC0310A
CAN TAPE volser BE MOUNTED ON DEVICE devno? REPLY Y OR N
Explanation

The wait time as established by the DFSMShsm SETSYS command for open or 
end-of-volume (EOV) processing of a tape data set has elapsed and open or EOV 
processing has not returned control to DFSMShsm. If the tape with volume serial 
number volser is available and can be mounted within the next mount wait time 
period, reply Y. Otherwise, reply N. If the reply is Y, and the wait time again 
elapses before open or EOV processing completes, open or EOV fails and the 
currently running task is detached.
System action

The current DFSMShsm task waits until a reply is received. If the waiting task 
holds resources critical for DFSMShsm processing, all of DFSMShsm may 
eventually be waiting for the reply.

If the reply is Y, DFSMShsm resets the time to the user mount wait time and 
continues to wait for mount completion.

If the reply is N, the mount request ends and the DFSMShsm function (migration, 
recall, backup, recovery, or recycle) ends if the mount was for an input volume 
or continues using another volume if the mount was for an output volume. If the 
reply is N and the DFSMShsm function is volume dump or volume restore using 
DFSMSdss, the mount request ends and the DFSMShsm function ends.
Operator response

If the tape with volume serial number volser is available and can be mounted 
within the time allowed, reply Y and mount the specified tape. Otherwise reply 
N. If the time period is not known, issue the QUERY command with the SETSYS 
parameter and look at the MOUNT WAIT TIME value displayed in message ARC0147I.

Did you check out the Wait time in HSM to see why it was taking longer than 
normal for the tape mount?

>From the DFHSM Storage Admin manual:
  MOUNTWAITTIME: Specifying the time DFSMShsm waits for a tape mount and open
  Explanation: MOUNTWAITTIME(minutes) is an optional parameter specifying the 
time, in minutes, that DFSMShsm waits for the tape volume to be mounted and 
opened. For minutes, substitute a decimal number from 1 to 120 to represent how 
long DFSMShsm waits for a tape to be mounted and opened. If the first time 
period expires, DFSMShsm sends message ARC0310A to the operator asking whether 
to mount the tape volume. If the operator answers Y to message ARC0310A, 
DFSMShsm resets the timer to minutes.  If the input volume has not been mounted 
and opened when the second time period expires, DFSMShsm automatically ends the 
task. If the output volume has not been mounted and
opened when the second time period expires, DFSMShsm marks this volume as 
unavailable and selects another tape volume.

  If you have not mounted an output tape dump volume when the second time 
period expires, DFSMShsm automatically ends the dump task.

  DFSMShsm default: If you do not specify this parameter on any SETSYS command, 
the DFSMShsm default is 15 minutes.

This may be due to a slow response to the mount request.


Have you analyzed your tape mount process for DFHSM and see what it is okay 
sometimes and not okay other times?

You may need to specify this parameter to extend how long HSM should wait.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tony Thigpen
> Sent: Thursday, November 24, 2016 6:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: HSM question
> 
> Answers:
> 1) OS/390 2.10
> 
> 2) output from Q SETSYS:
> 
> QUERY SETSYS COMMAND STARTING ON HOST=1
> BUDENSITY=*, BUUNIT=TAPE90, BU RECYCLE 609
> (CONT.) PERCENTAGE=033%, MOUNT WAIT TIME=010 MINUTE(S),
> (CONT.) TAPESPANSIZE(0100)
> SELECTVOLUME=SCRATCH, 610
> (CONT.) TAPEDELETION=SCRATCHTAPE, PARTIALTAPE=MARKFULL,
> (CONT.) DISASTERMODE=NO
> INPUT TAPE ALLOCATION=NOWAIT, OUTPUT TAPE 611
> (CONT.) ALLOCATION=NOWAIT, RECYCLE TAPE ALLOCATION=NOWAIT,
> (CONT.) TAPEFORMAT=SINGLEFILE
> TAPE INPUT PROMPT FOR BACKUPTAPES=NO
> TAPE INPUT PROMPT FOR DUMPTAPES=NO
> TAPE INPUT PROMPT FOR MIGRATIONTAPES=NO
> TAPE OUTPUT PROMPT FOR TAPECOPY=NO, DUPLEX 615
> (CONT.) BACKUP TAPES=NO, DUPLEX MIGRATION TAPES=NO
> TAPEMIGRATION=ML2TAPE(TAPE(TAPE90)), 616
> (CONT.) MIGDENSITY=*, MIGUNIT=TAPE90, ML2 RECYCLE
> (CONT.) PERCENTAGE=033%, TAPEMAXRECALLTASKS=01, ML2 PARTIALS
> (CONT.) NOT ASSOCIATED GOAL=010, RECONNECT(NONE) TAPESECURITY=EXPIRATION,
> DEFERMOUNT RECYCLEOUTPUT BACKUP=**NONE**, 618
> (CONT.) MIGRATION=**NONE**
> MAXRECYCLETASKS=01, RECYCLE INPUT 619
> (CONT.) DEALLOCATION FREQUENCY BACKUP=000 MIGRATION=000 MONITOR STARTUP
> NOSPACE NOVOLUME, MCDS(080), 620
> (CONT.) BCDS(080), OCDS(080), JOURNAL(080) JOURNAL=RECOVERY, LOG=YES,
> TRACE=NO, 621
> (CONT.) SMFID=0240, DEBUG=NO, EMERG=NO, JES=2, SYS1DUMP=YES,
> (CONT.) RACFIND=NO, ERASEONSCRATCH=NO, PDA=ON DAYS=380, ML1DAYS=003, 622
> (CONT.) PRIMARYSPMGMTSTART=(0030 0430),
> (CONT.) MAXMIGRATIONTASKS=0002, INTERVALMIGRATION=NO,
> (CONT.) MIGRATIONCLEANUPDAYS(0014 0007 0003), SDSP=NONE,
> 

Re: A true discussion in today's world (at least here)

[Mick Graley]

I'm a DB2 SysAdm/SysProg and DB2 maint always has reams of hold data. The
longer you leave it the bigger the job to wade through it all and build the
required jobs. Multiply it by many DB2 sub-systems and the job gets bigger
and bigger. You have to have the toleration fixes on the current release of
DB2 before you can upgrade to the next release (in case of fallback to the
old release with the new release catalog/directory structure) and that can
be a big job if you are way back on maintenance.
Cheers,
Mick.


On 24 November 2016 at 05:35, Edward Gould  wrote:

> > On Nov 23, 2016, at 8:32 PM, Joel C. Ewing  wrote:
> >
> > I think the car analogy with computer systems  breaks down on a number
> > of points (at least in the case of mainframes):
> >(1) while bleeding-edge-current is certainly not essential, the
> > further you get behind on software maintenance, the more costly it gets
> > in terms of time and person-hours to get reasonably current; and without
> > being reasonably current you may not be able to utilize new hardware
> > that could be more cost effective, or needed when old hardware dies, or
> > needed to adapt to growing business requirements.  The  cost of failure
> > to do preventive maintenance on a car is bounded by the time and cost
> > for replacement transportation, no matter how much maintenance was
> skipped.
> >(2)software maintenance relating to security or data exposures may
> > need prompt attention to avoid much more expensive data loss or data
> > exposure scenarios, which may also have serious legal implications.
> > Failure to do preventive maintenance on a car doesn't generally make it
> > more susceptible to hackers or have legal implications, unless you fail
> > to repair an obvious safety hazard and that results in a personal-injury
> > accident or death..
> >(3)Unexpected failures of a lesser-maintained car more often than
> > not just causes a temporary loss of availability which with sufficient
> > funds can be easily resolved, as there are many ready substitutes for
> > the basic function of transportation.  A corporate computer system has
> > company-specific data and company-specific applications which cannot
> > just be replaced by any generic computer system, and it may be
> > impossible for the company to stay in business very long without that
> > data and those applications.  Recovery from some software failures that
> > result in data loss is only possible with adequate DR planning in place,
> > and if adequate planning was not in place, recovery may not even be
> > possible at any price.  While I believe a valid argument can be made
> > against applying maintenance just for the sake of maintenance, some of
> > the problems addressed by HIPER PTFs are so dire you really don't want
> > to wait for that failure to occur before installing the fix.
> >
> > Even with a car, while it may be cost-effective to avoid or stretch out
> > some preventive or recommended maintenance, I strongly suspect it would
> > not on balance be cheaper for you to take that to the extreme and, say,
> > never change the engine oil (unless of course your plan is to sell
> > the.car after a few years without disclosing the potential shortened
> > engine life and cheat the next owner).
> >Joel C. Ewing
> about 20 years ago I worked at such a place. They did NOT believe in
> applying maintenance.
> Along comes the Y2K problem and they were in a bind (to say the least).
> They decided to order a servpac (new at the time).
> They were a  big user of DB2 (I have no knowledge of it) but they were
> really hurting in order to get up to snuff.
> They were non going to ORDER COBOL (current as it cost $5 more than the
> old) then LE hit them in the face and they *HAD* to order that. That almost
> burst their gut.
> I am glad I got out of there.
> Ed
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: A true discussion in today's world (at least here)

[David L. Craig]

On 16Nov23:1420-0500, Tony Harminc wrote:
> 
> The analogy is cute, but I think it fails The problem is that in some
> circumstances that's a perfectly reasonable way to manage a car.
> Depending on the age, how much you depend on it, whether you ever
> drive a significant distance from home, etc. etc. there may be nothing
> wrong with deferring or not doing some maintenance.

I agree--the automotive analogy is not compelling.  Even the
aerospace analogies fail to make it personal enough for the
average PHB.  A blood pump analogy gets a LOT closer to the
"heart" of the matter, though.  "I've never had a heart attack,
so I don't need to see any expensive cardiologists or pay for
their exhorbitant tests."
-- 

May the LORD God bless you exceedingly abundantly!

Dave_Craig__
"So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe."
__--from_Nightfall_by_Asimov/Silverberg_

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

Re: A true discussion in today's world (at least here)

[Mick Graley]

I agree with Tony, the analogy doesn't fit. Not fixing a car that isn't
broken makes sense. Not applying fixes for KNOWN errors usually doesn't
make sense. We all know that PTFs can go PE and cause problems, but you
have to weigh up the likelihood of a known error causing you serious
problems. Also your car failing doesn't normally cost your business
millions of £$€.
Cheers,
Mick.

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

Re: HSM question

[Tony Thigpen]

Elardus,

The remote operator is a human.
Tape management system is CA1
Still researching logs.

Tony Thigpen

Elardus Engelbrecht wrote on 11/23/2016 02:04 AM:

Tony Thigpen wrote:


Once a week, HSM performs an AUTOBACKUP. Until about 3 months ago, if nobody was at the 
shop, HSM would ask for an exiting tape, wait 10 minutes, and if no tape was mounted, it 
would ask "Can tape be mounted?". If our remote operator replied 'N', then HSM 
would us a scratch tape. About once ever month or so, we would run a recycle job to 
combine all the tapes.


What remote operator? A person or automated task?



Discussions with all the 3 others involved in the discussion 3 months ago came back with 
"I did not change anything 3 months ago."


Really? Do you have any tape management system?



So, I have come to the conclusion that somebody issued a command to HSM but did 
not update the config file so it would be handled at the next IPL.


Hmmm, yes something *has* changed!

What command(s) was issued? What are the results of that change(s)? Can you get 
RACF / SMF / SYSLOG records of that ?


Lizette gave you good questions. I will certainly listen to her! ;-)

Groete / Greetings
Elardus Engelbrecht

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




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

Re: HSM question

[Tony Thigpen]

Answers:
1) OS/390 2.10

2) output from Q SETSYS:

QUERY SETSYS COMMAND STARTING ON HOST=1
BUDENSITY=*, BUUNIT=TAPE90, BU RECYCLE 609
(CONT.) PERCENTAGE=033%, MOUNT WAIT TIME=010 MINUTE(S),
(CONT.) TAPESPANSIZE(0100)
SELECTVOLUME=SCRATCH, 610
(CONT.) TAPEDELETION=SCRATCHTAPE, PARTIALTAPE=MARKFULL,
(CONT.) DISASTERMODE=NO
INPUT TAPE ALLOCATION=NOWAIT, OUTPUT TAPE 611
(CONT.) ALLOCATION=NOWAIT, RECYCLE TAPE ALLOCATION=NOWAIT,
(CONT.) TAPEFORMAT=SINGLEFILE
TAPE INPUT PROMPT FOR BACKUPTAPES=NO
TAPE INPUT PROMPT FOR DUMPTAPES=NO
TAPE INPUT PROMPT FOR MIGRATIONTAPES=NO
TAPE OUTPUT PROMPT FOR TAPECOPY=NO, DUPLEX 615
(CONT.) BACKUP TAPES=NO, DUPLEX MIGRATION TAPES=NO
TAPEMIGRATION=ML2TAPE(TAPE(TAPE90)), 616
(CONT.) MIGDENSITY=*, MIGUNIT=TAPE90, ML2 RECYCLE
(CONT.) PERCENTAGE=033%, TAPEMAXRECALLTASKS=01, ML2 PARTIALS
(CONT.) NOT ASSOCIATED GOAL=010, RECONNECT(NONE)
TAPESECURITY=EXPIRATION, DEFERMOUNT
RECYCLEOUTPUT BACKUP=**NONE**, 618
(CONT.) MIGRATION=**NONE**
MAXRECYCLETASKS=01, RECYCLE INPUT 619
(CONT.) DEALLOCATION FREQUENCY BACKUP=000 MIGRATION=000
MONITOR STARTUP NOSPACE NOVOLUME, MCDS(080), 620
(CONT.) BCDS(080), OCDS(080), JOURNAL(080)
JOURNAL=RECOVERY, LOG=YES, TRACE=NO, 621
(CONT.) SMFID=0240, DEBUG=NO, EMERG=NO, JES=2, SYS1DUMP=YES,
(CONT.) RACFIND=NO, ERASEONSCRATCH=NO, PDA=ON
DAYS=380, ML1DAYS=003, 622
(CONT.) PRIMARYSPMGMTSTART=(0030 0430),
(CONT.) MAXMIGRATIONTASKS=0002, INTERVALMIGRATION=NO,
(CONT.) MIGRATIONCLEANUPDAYS(0014 0007 0003), SDSP=NONE,
(CONT.) MIGRATION PREFIX=DFHSM, SCRATCH EXPIRED DATA SETS=YES,
(CONT.)  SECONDARYSPMGMTSTART=(0015 0330)
PRIMARY SPACE MGMT CYCLE LENGTH=07 DAYS, 623
(CONT.) CYCLE=NNNYNNN, TODAY IS DAY=07, CYCLE START
(CONT.) DATE=01/01/26, SECONDARY SPACE MGMT CYCLE LENGTH=07
(CONT.) DAYS, CYCLE=NNNYNNN, TODAY IS DAY=07, CYCLE START
(CONT.) DATE=01/01/26
MAXINTERVALTASKS=0002
ACCEPTPSCBUSERID=NO
MAXRECALLTASKS=02, RECALL=PRIVATEVOLUME(LIKE), 626
(CONT.)  MAXEXTENTS=10, CONVERSION=NO, VOLCOUNT=*NONE*,
(CONT.) TAPERECALLLIMITS(TASK=00015, TAPE=00020)
SCRATCHFREQ=0007, SYSOUT(CLASS=T, COPIES=01, 627
(CONT.) SPECIAL FORMS=NONE), SWAP=NO, PERMISSION=NO, EXITS=TV,
(CONT.)  UNLOAD=NO, DATASETSERIALIZATION=DFHSM
TAPEUTILIZATION PERCENT=0097, LIBRARYMIGRATION
TAPEUTILIZATION PERCENT=0097, LIBRARYBACKUP
TAPEUTILIZATION PERCENT=0097, UNIT=3480 630
(CONT.) CAPACITYMODE=**NONE**
TAPEUTILIZATION PERCENT=0097, UNIT=3480X 631
(CONT.) CAPACITYMODE=**NONE**
TAPEUTILIZATION PERCENT=0097, UNIT=3490 632
(CONT.) CAPACITYMODE=**NONE**
TAPEUTILIZATION PERCENT=0097, UNIT=3590-1 633
(CONT.) CAPACITYMODE=**NONE**
TAPEUTILIZATION PERCENT=0097, UNIT=TAPE90 634
(CONT.) CAPACITYMODE=**NONE**
MAXDUMPTASKS=01, ADSTART=(1500 1730 2230), 635
(CONT.) DUMPIO=(4,4), VOLUMEDUMP=(NOCC)
BACKUP=YES(TAPE(TAPE90)), SPILL=NO, 636
(CONT.) MAXDSRECOVERTASKS=01
MAXBACKUPTASKS=01, ABSTART= (1530 2100 2145), 637
(CONT.) VERSIONS=002, FREQUENCY=002, SKIPABPRIMARY=NO, BACKUP
(CONT.) PREFIX=DFHSM, INCREMENTALBACKUP=CHANGEDONLY,
(CONT.) PROFILEBACKUP=YES, INUSE=(RETRY=YES, DELAY=002,
(CONT.) SERIALIZATION=PREFERRED)
DATA SET DASD BACKUP TASKS=02 DATA SET TAPE 638
(CONT.) BACKUP TASKS=02, DEMOUNTDELAY MINUTES=0060,
(CONT.) MAXIDLETASKS=00, DATA SET BACKUP MAXIMUM DASD
(CONT.) SIZE=003000, DATA SET BACKUP STANDARD DASD
(CONT.) SIZE=000250, SWITCHTAPES TIME=,
(CONT.) PARTIALTAPE=MARKFULL
USER UNIT NAMES=TAPE90
CDSVERSIONBACKUP, 640
(CONT.) MCDSBACKUPDSN=DFHSM.MCDS.BACKUP,
(CONT.) BCDSBACKUPDSN=DFHSM.BCDS.BACKUP,
(CONT.) OCDSBACKUPDSN=DFHSM.OCDS.BACKUP,
(CONT.) JRNLBACKUPDSN=DFHSM.JRNL.BACKUP
BACKUPCOPIES=0004, BACKUPDEVICECATEGORY=DASD, 641
(CONT.) LATESTFINALQUALIFIER=D0004293, DATAMOVER=DSS
CSALIMITS=YES, CSA CURRENTLY USED=0 BYTES, 642
(CONT.) MWE=4, MAXIMUM=100K BYTES, ACTIVE=90%, INACTIVE=30%
COMPACTION OPTIONS ARE: TAPEMIGRATION=YES, 643
(CONT.) DASDMIGRATION=YES, TAPEBACKUP=YES, DASDBACKUP=YES,
(CONT.) TAPEHARDWARECOMPACT=YES
COMPACT PERCENT IS 30%
SOURCENAMES: ASM  COBOLFORT PLI 645
(CONT.)SOURCE
SOURCENAMES: SRC  SRCLIB   SRCE CNTL 646
(CONT.)JCL
OBJECTNAMES: OBJ  OBJECT   LOAD 647
(CONT.) LOADLIB  LOADMODS
OBJECTNAMES: LINKLIB
OPTIMUMDASDBLOCKING=YES, LOGGING 649
(CONT.) LEVEL=EXCEPTIONONLY, LOG TYPE=SYSOUT T
AGGREGATE BACKUP/RECOVERY PROCNAME = DFHSMABR
AGGREGATE BACKUP/RECOVERY MAXADDRESSSPACE = 01
AGGREGATE BACKUP/RECOVERY UNIT NAME = 3590-1
AGGREGATE BACKUP/RECOVERY ACTIVITY LOG 653
(CONT.) MESSAGE LEVEL IS FULL
AGGREGATE RECOVERY ML2 TAPE UNIT NAME = 3590-1
NUMBER OF ABARS I/O BUFFERS = 01
ABARS ACTIVITY LOG OUTPUT TYPE = SYSOUT(T)
AGGREGATE RECOVERY UNIT NAME = 3590-1
AGGREGATE BACKUP OPTIMIZE = 3
AGGREGATE RECOVERY TGTGDS = SOURCE
AGGREGATE RECOVERY ABARSVOLCOUNT = *NONE*
AGGREGATE RECOVERY PERCENTUTILIZED = 080
AGGREGATE BACKUP/RECOVERY ABARSDELETEACTIVITY 662
(CONT.) = NO
AGGREGATE BACKUP/RECOVERY ABARSTAPES = STACK
AGGREGATE BACKUP ABARSKIP = NOPPRC, NOXRC
PLEXNAME=ARCPLEX0,PROMOTE PRIMARYHOST=NO, 665
(CONT.) PROMOTE SSM=NO
QUERY SETSYS COMMAND COMPLETED ON HOST=1

3) 

Re: IBM Java 8 SR2

[Veerendra H]

Hi Al,

Thank you for your detailed assistance. Appreciate it

Also thank you all for the replies.

Regards,
Kumar

On Wed, Nov 23, 2016 at 10:24 PM, Nims,Alva John (Al) 
wrote:

> If you do want to get the SR2 specific without SR3
>
> http://www-03.ibm.com/systems/z/os/zos/tools/java/
>
> You will need an IBM ID & Password, eventually when you start with this
> page.  Click on one of the links under "Java Technology Edition, Version
> 8."   In the next web page, scroll down to: "Getting the Product" and the
> link is the word "Download" in "Download the non-SMP/E format of the
> code."   At this point it will ask some questions and check "I Agree" and
> click the "I Confirm" button (I cannot remember if it asks for the IBM
> UserID before this page or after, but it is asked).  On the "Downloads"
> page that comes up, scroll down to locate a SR2 level you would like, "SR2
> FP10" or "SR2".
>
> I thought there was a link on that first page that would map IBM's SR#
> FP## to Oracle's ##'s, but I could not find it off hand.
>
> Al Nims
> Systems Admin/Programmer 3
> UFIT
> University of Florida
> (352) 273-1298
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Veerendra H
> Sent: Wednesday, November 23, 2016 11:25 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IBM Java 8 SR2
>
> Hi,
>
> I am looking for help in finding a website/location from where i can
> download IBM Java version 8 SR2, I went to the below website and can find
> SR3 but not SR2
>
> https://developer.ibm.com/javasdk/downloads/
>
> Please advise.
>
> Regards,
> Kumar
>
> --
> 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