Yes, very high level of amintenance RSU1301 z/OS 1.3
Bernard
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
We were at 5876.8? something and upgraded this past weekend to 5876.159
but we didn't see any big increase either this past weekend or when we
went from 5875 to 5876.
ddk
I was so close. The level is 5876-159
That is what I get from doing it from memory.
Lizette
This e-mail
Hi...I am having some discussions with an application programmer about how
programs are loaded and the search sequence - STEPLIB/JOBLIB/LNKLST, etc.
Can someone point me to the IBM doc that spells this out clearly so I can
refer him and his teammates to the right place?
Thank you and best
Bill,
try this link:
http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zos.zsysprog/zsysprogc_searchorder.htm
Paolo Cacciari
Senior IT Specialist - Certified
From: Bill Ashton bill00ash...@gmail.com
To: IBM-MAIN@listserv.ua.edu
Date: 21/03/2013 15:31
How about:
http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zos.zsysprog/zsysprogc_searchorder.htm
-Original Message-
From: Bill Ashton [mailto:bill00ash...@gmail.com]
Sent: Thursday, March 21, 2013 10:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Program load
Good Day Readers,
Several jobs are failing due to the following :
IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01,SYS2.HESP.BPROCLIB
IEF196I IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01,
IEF196I SYS2.HESP.BPROCLIB
$HASP307 HESPD01 UNABLE TO OPEN PROC02
Hello everyone!
After using Health Checker for z/OS for several months now, I'm having
doubts about some checks, so please feel free to comment :)
Check: ASM_LOCAL_SLOT_USAGE
Comment: This one pops up regularly on LPAR's with Websphere software.
It's almost impossible to keep the usage below
Thanks Paolo and Anthony...you both pointed me to the same book, and it is
just what I needed!
Have a great day!
Billy
On Thu, Mar 21, 2013 at 10:42 AM, Sambataro, Anthony (NIH/NBS) [E]
anthony.sambat...@nih.gov wrote:
How about:
Hi Willie,
its not as simple as getting it recalled to the same volume. I believe it's
still the case that at jes startup it maps the dataset extents so you would
need to get it back to exactly the same place(s) on the pack.
The best solution is to make all your jes proclibs non migrateable.
A
Devnie,
Thanks for the tip. I will heed your advice. I will need to fill out lots of
paper work to change the rule. Thanks.
From: David Devine david.dev...@sse.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thursday, March 21, 2013 11:37:15 AM
Subject: Re: DFHSM
IIRC, After restoring the dataset to the same volume I believe you can submit a
job with a /*JOBPARM PROCLIB=ddname where that's one of the proclib
concatenation DD's in the JES2 proc. That will have JES reallocate the
proclibs and you should be ok.
Alan Schwartz
ITO Global Services
There are some datasets which shouldn't migrate (probably shouldn't be in SMS
pools at all). JES proclibs are in this set of datasets that shouldn't migrate.
:)
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of willie bunter
Sent:
Comments interspersed:
Check: ASM_LOCAL_SLOT_USAGE
Comment: This one pops up regularly on LPAR's with Websphere software.
It's almost impossible to keep the usage below 30%.
Documentation says: To maximize the efficiency of ASM slot management, you
should keep the slot usage on all local page
Willie,
As others have pointed out, a couple of solutions.
1) Use USER PROCLIB datasets in JCLLIB datasets in your JCL.
2) Have a NOMIG class in SMS that will not migrate the dataset.
PROCLIBs are touchy to JES2. I typically have my users code JCLLIB
statements, and I think the job will
Walter,
I checked the SC. It doesn't have Guaranteed Space.
From: Walter Marguccio walter_marguc...@yahoo.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thursday, March 21, 2013 11:34:52 AM
Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
From:
Alan,
That's the problem. Restoring the dsn on the same volume.
From: Schwartz, Alan alan.schwa...@xerox.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thursday, March 21, 2013 12:02:31 PM
Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
IIRC,
On Thu, 21 Mar 2013 10:37:15 -0500, David Devine wrote:
its not as simple as getting it recalled to the same volume. I believe it's
still the case that at jes startup it maps the dataset extents so you would
need to get it back to exactly the same place(s) on the pack.
The best solution is to
Lizette,
Thanks for the advice. I have taken note of the suggestions and hopefully I
can have the changes done.
Thanks.
From: Lizette Koehler stars...@mindspring.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thursday, March 21, 2013 12:18:03 PM
Subject: Re: DFHSM
No. HSM will not migrate a file if it is open. IIRC, But proclibs have short
usage. So it is possible the proclib is not used within the timeframe for
migration is specified. JES2 does not always open PROCLIBs after the TTRs are
read into JES2 ASID. Unless the environment has multiple
On Thu, 21 Mar 2013 09:31:31 -0700, Lizette Koehler wrote:
No. HSM will not migrate a file if it is open. IIRC, But proclibs have short
usage. So it is possible the proclib is not used within the timeframe for
migration is specified. JES2 does not always open PROCLIBs after the TTRs are
Maybe so, but JES2/HASP has done this since day 1 (circa 1975).
Many decisions made many moons ago are maintained for historical compatability.
Those decisions would not necessarily be the same today.
snip
No. HSM will not migrate a file if it is open. IIRC, But proclibs have short
usage.
On Thu, Mar 21, 2013 at 11:15 AM, Staller, Allan allan.stal...@kbmg.com wrote:
Comments interspersed:
Check: ASM_LOCAL_SLOT_USAGE
Comment: This one pops up regularly on LPAR's with Websphere software.
It's almost impossible to keep the usage below 30%.
Documentation says: To maximize the
Add FORCENONSMS UNIT(3390) VOL(volser) to the recall command.
hlq.CLIST(HRECN)
PROC 2 D V
HSEND RECALL D VOL(V) UNIT(3390) FORCENON
END /* PROC */
On Thu, Mar 21, 2013 at 10:21 AM, willie bunter williebun...@yahoo.com wrote:
Good Day Readers,
Several jobs are failing due to the following :
Exactly. Think back to the days before you had multiple systems
to change things from - or even back to before TSO/ISPF. For
example, if you had to enlarge a proclib how could you submit
a job to do so if it was in use by JES2 and JES2 was up in order
for you to submit (read in) a job. You
From: willie bunter williebun...@yahoo.com
I checked the SC. It doesn't have Guaranteed Space.
Willie,
if the SC doesn't have Guaranteed Space, then there is no way to force hsm to
recall a migrated dataset on the original volume (at least that I'm aware of).
If your dataset would have
Have some DB2 questions not seeing group on listserv ??
under a different area ??
--
Email Disclaimer
This E-mail contains confidential information belonging to the sender,
which may be legally privileged information.
_www.idug.org_ (http://www.idug.org) should get you pointed in right
direction. Doesn't show up on lsoft.com catalist and sub db2-l to
listsrv.ua.edu sends you off to american edu?
In a message dated 3/21/2013 4:01:09 P.M. Central Daylight Time,
ron.we...@slfs.com writes:
Have some
thanks
From: Ed Finnell efinnel...@aol.com
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 03/21/2013 04:21 PM
Subject:Re: DB2
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
_www.idug.org_ (http://www.idug.org) should get you pointed in right
direction. Doesn't
Sign up at idug.org
Lizette
-Original Message-
From: Ron Wells ron.we...@slfs.com
Sent: Mar 21, 2013 2:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DB2
Have some DB2 questions not seeing group on listserv ??
under a different area ??
On Thu, 21 Mar 2013 08:34:52 -0700, Walter Marguccio wrote:
how can I force HSM to�recall the dsn to�the original volume?�
IIRC, if the datasets belongs to a SC whose Guaranteed Space = Yes, then hsm
recalls
the dataset on the same volume where the dataset originally was.�
I'm pretty sure I
Some of you asked for updates.
Update: the problem has reappeared after a while in the version 1.3 code.
I got a packet trace and it seems to me to show everything exactly as I
would expect.
I have told the customer that it may be our problem but someone on the
network side or in IBM is going
According to the official history:
History
In the mid-1960's a small group of IBM employees working at the
Manned Spacecraft Center
in Houston worked on a program called HASP (please see next section
for How HASP got
its name) which eventually was made available as an FDP. Its
popularity
32 matches
Mail list logo
