In [EMAIL PROTECTED], on
12/03/2008
at 04:02 PM, Mark Pace [EMAIL PROTECTED] said:
How would I determine which of these 3 PTFs apply to my system?
The release is actually the trailing characters of the FMID.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see
In [EMAIL PROTECTED], on
12/03/2008
at 02:10 PM, Mark Pace [EMAIL PROTECTED] said:
What is this trying to tell me?
You don't have the toleration PTF for the FIXCAT functionality.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see
I'm doing RECEIVE processing for the latest RSU and I got a lot of these
errors.
What is this trying to tell me?
sample:
++HOLD(HCYT71Q) FIXCAT FMID(HCYT71Q) REASON(AA27056) RESOLVER(UA44721)
** THERE IS A SYNTAX ERROR IN THE CONTROL STATEMENT AT COLUMN 17.
** THERE IS AN ERROR IN A ++HOLD MCS
You may need SMPE ver 3.5 or add required PTF's to ver 3.4 to handle new FIXCAT
FMID.
Mark Pace [EMAIL PROTECTED] 12/3/2008 2:10 PM
I'm doing RECEIVE processing for the latest RSU and I got a lot of these
errors.
What is this trying to tell me?
sample:
++HOLD(HCYT71Q) FIXCAT FMID(HCYT71Q)
My concern here is that, as I understand it, a ++HOLD is to prevent a piece
of maintenance from being applied. With this syntax error will the PTF end
up being applied if I run APPLY?
Obviously I'm an SMPE newb.
On Wed, Dec 3, 2008 at 2:12 PM, Matt Dazzo [EMAIL PROTECTED] wrote:
You may need
FIXCAT is a recent introduction. You can continue without change but may see
additional error (noise) messages. PTFs are available to SMPE 3.4 to tolerate
FIXCAT.
Bob Shannon
Rocket Software
--
For IBM-MAIN subscribe / signoff
after the general availability of z/OS 1.10.
Lizette
-Original Message-
From: Mark Pace [EMAIL PROTECTED]
Sent: Dec 3, 2008 2:20 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SMPE question
My concern here is that, as I understand it, a ++HOLD is to prevent a piece
of maintenance from being
Message-
From: Mark Pace [EMAIL PROTECTED]
Sent: Dec 3, 2008 2:20 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SMPE question
My concern here is that, as I understand it, a ++HOLD is to prevent a
piece
of maintenance from being applied. With this syntax error will the PTF
end
up being applied
release prior to 3.3 will not be able to
process ++HOLDs after the general availability of z/OS 1.10.
Lizette
-Original Message-
From: Mark Pace [EMAIL PROTECTED]
Sent: Dec 3, 2008 2:20 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SMPE question
My concern here is that, as I
.
Note: Users running a SMP/E release prior to 3.3 will not be able to
process ++HOLDs after the general availability of z/OS 1.10.
Lizette
-Original Message-
From: Mark Pace [EMAIL PROTECTED]
Sent: Dec 3, 2008 2:20 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SMPE
Even more embarrassing, it is on the first line of just about every
output page.
TO the right on mine it shows DATE 11/14/08 TIME 14:27:02 SMP/E
35.05
SMP/E Rel 3.5 (35).
Alan
Subject: Re: SMPE question
Yes, that part I knew. The embarrassing part is that I'm still trying
to
figure out
-Original Message-
From: Mark Pace [EMAIL PROTECTED]
Sent: Dec 3, 2008 2:20 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SMPE question
My concern here is that, as I understand it, a ++HOLD is to prevent a
piece
of maintenance from being applied. With this syntax error
Sent: Wednesday, December 03, 2008 11:58 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SMPE question
Yes, that part I knew. The embarrassing part is that I'm still trying
to
figure out how to get SMPE to tell me what versions of software I'm
running. It was so much easier in VSE. MSHP RETRACE
@bama.ua.edu
Subject: Re: SMPE question
Yes, that part I knew. The embarrassing part is that I'm still trying
to figure out how to get SMPE to tell me what versions of software I'm
running. It was so much easier in VSE. MSHP RETRACE
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Mark Pace
Yes, that part I knew. The embarrassing part is that I'm still trying
to
figure out how to get SMPE to tell me what versions of software I'm
running. It was so much easier in VSE. MSHP RETRACE.
It's on
On Wed, 3 Dec 2008 14:58:29 -0500, Mark Pace [EMAIL PROTECTED] wrote:
Yes, that part I knew. The embarrassing part is that I'm still trying to
figure out how to get SMPE to tell me what versions of software I'm
running. It was so much easier in VSE. MSHP RETRACE.
Mishap? :-)
Other response
Mark -
Thanks. That was close to what I was looking for. Here is what I am trying
to figure out. This is from the APAR to fix the holddata problem
*Applicable component levels* RF00 PSY
UO00700https://www14.software.ibm.com/webapp/set2/ordermedia/shopCart?ptfs=UO00700
UP08/01/28
P F801 RG00
On Wed, 3 Dec 2008 16:02:26 -0500, Mark Pace [EMAIL PROTECTED]
wrote:
Mark -
Thanks. That was close to what I was looking for. Here is what I am trying
to figure out. This is from the APAR to fix the holddata problem
*Applicable component levels* RF00 PSY
On Wed, 3 Dec 2008 16:02:26 -0500, Mark Pace [EMAIL PROTECTED] wrote:
Mark -
Thanks. That was close to what I was looking for. Here is what I am trying
to figure out. This is from the APAR to fix the holddata problem
*Applicable component levels* RF00 PSY
In [EMAIL PROTECTED], on 05/20/2007
at 09:33 AM, Lizette Koehler [EMAIL PROTECTED] said:
Those datasets are related to the GLOBAL zone and not the TLIB or
DLIB.
Some, not all. You really don't want to share, e.g., MTS between
target zones.
So yes they are shared.
Sharing the data sets
I have a CSI dataset with many different target and dlib zones defined for
different products and different versions of those products.
Can the following datasets be shared between all the zones?
SMPPTS, SMPLTS, SMPMTS, SMPSDS, SMPSCDS
Specifically, I'm dealing with a skeleton JCL job that
Jerry,
Those datasets are related to the GLOBAL zone and not the TLIB or DLIB. So
yes they are shared. And yes all your different TLIB and DLIB zones can
point to those datasets from your one global zone. In otherwords, they are
used during the RECEIVE Process for any product. Then when you
On Sun, 20 May 2007 09:33:04 -0400, Lizette Koehler wrote:
Those datasets are related to the GLOBAL zone and not the TLIB or DLIB. So
yes they are shared. And yes all your different TLIB and DLIB zones can
point to those datasets from your one global zone.
Ummm. No. From:
Title: SMP/E
On Sun, 20 May 2007 09:33:04 -0400 Lizette Koehler [EMAIL PROTECTED]
wrote:
:Those datasets are related to the GLOBAL zone and not the TLIB or DLIB. So
:yes they are shared. And yes all your different TLIB and DLIB zones can
:point to those datasets from your one global zone. In otherwords,
On Sun, 20 May 2007 19:39:54 +0300, Binyamin Dissen wrote:
You definitely do not want to share SMPMTS between different versions of the
same product. Or SMPLTS.
SMPPTS should be OK.
Here, TFM fails me (or I didn't R carefully enough). My intuition is that
SMPPTS belongs to the GLOBAL zone and
Paul Gilmartin wrote:
On Sun, 20 May 2007 19:39:54 +0300, Binyamin Dissen wrote:
You definitely do not want to share SMPMTS between different versions of the
same product. Or SMPLTS.
SMPPTS should be OK.
Here, TFM fails me (or I didn't R carefully enough). My intuition is that
SMPPTS
I have a CSI dataset with many different target and dlib zones defined for
different products and different versions of those products.
Can the following datasets be shared between all the zones?
SMPPTS, SMPLTS, SMPMTS, SMPSDS, SMPSCDS
Specifically, I'm dealing with a skeleton JCL job that
Basically we have CLASSPATH set to /usr/lpp/smp/classes as the
documentation states. The actual class files being looked for by the
job are in /usr/lpp/smp/classes/com/ibm/smp. What I don't understand is
how SMP knows to look beyond /usr/lpp/smp/classes for the class files.
What is telling
We are using RECEIVE ORDER here and it is working fine. I am trying to
understand how one piece of this works and have not been able to find any
documentation to explain it.
Basically we have CLASSPATH set to /usr/lpp/smp/classes as the documentation
states. The actual class files being
[EMAIL PROTECTED]
Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU
06/28/2006 12:37 PM
Please respond to
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU
To
IBM-MAIN@BAMA.UA.EDU
cc
Subject
SMPE question RECEIVE ORDER
We are using RECEIVE ORDER here and it is working fine. I am
Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf
Of Howard Rifkind
Sent: Wednesday, March 01, 2006 10:52 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: SMPE Question
I'm looking for the following APARS in the SMP Global zone.
PQ92344 OA14861
Can I find
-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf
Of Howard Rifkind
Sent: Wednesday, March 01, 2006 10:52 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: SMPE Question
I'm looking for the following APARS in the SMP Global zone.
PQ92344 OA14861
Can I find these by doing
I'm looking for the following APARS in the SMP Global zone.
PQ92344 OA14861
Can I find these by doing a cross zone query or do I need to first do a
search for the associated PTF numbers on say IBMLINK?
Thanks.
-
Yahoo! Mail
By PTF. For example, APAR PQ92344 for FMID EDU1H01 is UQ91568.
Regards,
Kevin
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Howard Rifkind
Sent: Wednesday, March 01, 2006 10:52 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: SMPE Question
I'm
:52 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: SMPE Question
I'm looking for the following APARS in the SMP Global zone.
PQ92344 OA14861
Can I find these by doing a cross zone query or do I need to first do a
search for the associated PTF numbers on say IBMLINK?
Thanks
Of Howard Rifkind
Sent: Wednesday, March 01, 2006 10:52 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: SMPE Question
I'm looking for the following APARS in the SMP Global zone.
PQ92344 OA14861
Can I find these by doing a cross zone query or do I need to first do a
search for the associated PTF numbers on say
: Wednesday, March 01, 2006 10:52 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: SMPE Question
I'm looking for the following APARS in the SMP Global zone.
PQ92344 OA14861
Can I find these by doing a cross zone query or do I need to first do a
search for the associated PTF numbers on say IBMLINK
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin
[ snip ]
Howard did specify GROUPEXTEND, which should automatically
APPLY needed corrective maintenance. In Howard's text, I see:
SYSMOD STATUS TYPE FMIDreqUISITE SYSMODS, SUPBY
Do you mean that the PTF that fixes AQ64238 is in PE status?
But its not in PE status. More specifically, SMP/E doesn't think its PE
because there's no HOLDDDATA in the global zone to indicate that its PE.
Notice in the SYSMOD Status Report AQ64238 is NOT annotated with an
asterisk (*).
In [EMAIL PROTECTED], on 12/20/2005
at 03:01 PM, Paul Gilmartin [EMAIL PROTECTED] said:
Howard did specify GROUPEXTEND, which should automatically APPLY
needed corrective maintenance.
No; it will only automatically apply needed maintenance that is in the
PTS. It is quite common for hold data
In [EMAIL PROTECTED], on 12/20/2005
at 03:57 PM, Paul Gilmartin [EMAIL PROTECTED] said:
Nonetheless, since AQ64238 is known to SMP/E and manifest to the
customer, wouldn't it be a courtesy to casual and naive (such as me)
browsers, to make AQ64238 known in IBMlink, perhaps as a keyword
for
1st suggestion - Remove the FORFMID and just APPLY S() GROUPEXTEND.
Any remaining HOLDE* need to be resolved. Actions should be (at least) reviewed
.
HTH,
snip
APPLY
PTFS
BYPASS (
HOLDSYSTEM
)
JCLINREPORT
FORFMID(
HOS1110
)
CHECK
GROUPEXTEND
SELECT (
UK00286
)
In [EMAIL PROTECTED], on
12/19/2005
at 03:03 PM, Howard Rifkind [EMAIL PROTECTED] said:
The following show up in an SMPE Causer report and I'm confused
what to resolve next...the chicken or the egg.
Neither; first read.
Do I have to fix the missing and/or hold items
Yes, except for
On Tue, 20 Dec 2005 09:24:51 -0500, Shmuel Metz (Seymour J.) shmuel+ibm-
[EMAIL PROTECTED] wrote:
...
Do I have to fix the missing and/or hold items
...
and when I do it just leads to more things to resolve.
Do you mean that the PTF that fixes AQ64238 is in PE status? That's
the only thing
In a recent note, Shmuel Metz (Seymour J.) said:
Date: Tue, 20 Dec 2005 09:24:51 -0500
Do you mean that the PTF that fixes AQ64238 is in PE status? That's
the only thing that I see that could potentially lead to more things
to resolve. Everything else is a question of reading the
Paul Gilmartin wrote:
Howard did specify GROUPEXTEND, which should automatically APPLY
needed corrective maintenance. In Howard's text, I see:
SYSMOD STATUS TYPE FMIDreqUISITE SYSMODS, SUPBY SYSMODS, HOLD RE
UQ67494 APPLIED PTF HIP6140 PRE UQ66384 HOLDE
If this is a live APPLY (as opposed to an APPLY CHECK), don't you have
to specifically state the Hold Reason codes, e.g.,
BYPASS(HOLDSYS(ACTION,DOC))
so that the APPLY process can include the requisites?
Also, if the APPLY is for one specific PTF or APAR, SELECT(UK00286) should
suffice. AFAIK, the
In a recent note, Bob Rutledge said:
Date: Tue, 20 Dec 2005 17:39:42 -0500
... is it possible AQ64238 is a typo for PQ64238?
No. AQ64238 would be an APAR fix issued prior to the PTF fixing PQ64238.
(Multiple such would be BQ..., etc.) UQ6888x will SUP AQ64238 plus any other
At 15:57 -0700 on 12/20/2005, Paul Gilmartin wrote about Re: SMPE Question:
Nonetheless, since AQ64238 is known to SMP/E and manifest to
the customer, wouldn't it be a courtesy to casual and naive (such
as me) browsers, to make AQ64238 known in IBMlink, perhaps as
a keyword for PQ64238?
I
The following show up in an SMPE Causer report and I'm confused what to
resolve next...the chicken or the egg.
Do I have to fix the missing and/or hold items and when I do it just leads to
more things to resolve.
Thanks.
APPLY
PTFS
BYPASS (
HOLDSYSTEM
)
JCLINREPORT
50 matches
Mail list logo
