On 5/24/2019 11:24 AM, Styles, Andy , ITS zPlatform Services wrote:
I have the SMPGLOG (GLOBAL log), but not the jobs. I'm reluctant to post a
large amount of SMPLOG output here, but here (hopefully relevant) snippets:
RECEIVE
ORDER(ORDERSERVER(ORDRINFO)
CONTENT(RECOMMENDED)
CLIENT(CLNTINFO)
)
.
ORDER ORD00018 HAS BEEN SENT TO THE SERVER AT
https://eccgw01.boulder.ibm.com/services/projects/ecc/ws/.
ENQ WAS SUCCESSFUL FOR EXCLUSIVE USE OF ORD00018-05April2019-08.45.34.407 FOR
RECEIVE PROCESSING.
Unfortunately the SMPLOG doesn't show us the ASSIGN statements and
SOURCEIDs that were processed, which is what I was hoping to see in your
output.
We then received a bunch of PTFs as a result - I can list them if you wish.
Now, yesterday I noticed that I didn't specify a target zone here. There are
two target zones in the GLOBAL zone - the previous iteration of this process,
and a clone of it (which is the one RSU1903 was eventually applied to), so we
can look across multiple target zones to see if/where a PTF is applied.
When I re-did the RECEIVE ORDER, I added FORTGTZONE, though to me, that should
have made no difference.
Hmmm... probably FORTGTZONE is not interesting here, but depending on
other activity in your global and target zones, I wouldn't completely
rule it out as a factor.
I then ended up with this:
RECEIVE
ORDER(ORDERSERVER(ORDRINFO)
CONTENT(RECOMMENDED)
CLIENT(CLNTINFO)
FORTGTZONES(TGTD)
)
.
ORDER ORD00020 HAS BEEN SENT TO THE SERVER AT
https://eccgw01.boulder.ibm.com/services/projects/ecc/ws/.
ENQ WAS SUCCESSFUL FOR EXCLUSIVE USE OF ORD00020-22May2019-17.19.02.141 FOR
RECEIVE PROCESSING.
And then received the following fixes:
SYSMOD ENTRY UA98295 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98305 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98317 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98340 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98341 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98707 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98723 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98804 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98840 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98845 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98920 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98954 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98965 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99018 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99029 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99050 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99059 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99094 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99149 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99208 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99224 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99278 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99283 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99306 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UI60691 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UI61245 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UI61642 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UI61783 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UI62355 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UI62458 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UI62648 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UI63041 WAS STORED IN THE GLOBAL ZONE.
Were any of these PTFs also received in the prior RECEIVE ORDER? And
Were they applied and accepted, perhaps purging them from the global
zone prior to the latest RECEIVE ORDER? Were they assigned the RSU1903
sourceid in the first, second, or both RECEIVEs?
This last question about when/if RSU1903 was assigned is the important
one, but I fear you may not know the answer without the SMPRPT output
for the RECEIVEs.
Now, looking back through the log, I can also see quite a few messages like
this:
MCS UA98840 WAS DELETED FROM THE SMPPTS LIBRARY.
MCS UA98840 WAS DELETED FROM THE SMPPTS1 LIBRARY.
MCS ENTRY UA98840 WAS STORED IN THE SMPPTS LIBRARY.
SYSMOD ENTRY UA98840 WAS STORED IN THE GLOBAL ZONE.
RECEIVE PROCESSING WAS SUCCESSFUL FOR SYSMOD UA98840.
Which confuses me (not difficult) - why is it already in the SMPPTS dataset?
Nonetheless, I didn't do a REJECT of anything first, so it was RECEIVEd ok.
The "MCS WAS DELETED..." messages are simply SMP/E making sure there are
no duplicate PTF members across your SMPPTS and SMPPTS1 data sets. You
can ignore these messages.
Kurt Quackenbush -- IBM, SMP/E Development
Chuck Norris never uses CHECK when he applies PTFs.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
