>Since the JES2-L list seems to be defunct, and I have not found a conclusive
>answer in the archives nor the books, ...
Have you been able to search the archives of the JES2-L list? Last time I tried
I did not succeed.
--
Peter Hunkeler
Point of clarity here. When SMP/E added the HOLDDATA report, they added
the ability to exclude any category, and many sysprogs immediately
excluded DOC, thinking they were a waste of time to look at. Whenever I
talked about looking at ALL HOLDDATA, even the DOCs, because sometimes
it's
Agreed, a better wording for me would have been "I would prefer it included an
action hold rather than JUST a doc hold in this case."
Rex
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tom Marchant
Sent: Thursday, May 18, 2017 3:38
On Thu, 18 May 2017 20:26:03 +, Pommier, Rex wrote:
>I would prefer it be an action hold rather than a doc hold in this case.
It isn't either/or. Sometimes it is appropriate to have both a DOC and an
ACTION hold.
--
Tom Marchant
Whether ACTION or DOC, these instructions need to be qualified many times over.
IBM occasionally PEs a PTF over some problem with HOLD data--usually when it's
missing. There may be nothing wrong with the code, just the packaging and
accompanying--or not--documentation.
I'm obviously perturbed
On Thu, 18 May 2017 14:14:10 -0600, Paul Gilmartin wrote:
>Can IBM repair this even after the fact? I know SMPHOLD may contain
>++HOLD ... ACTION. But I doubt that LIST ERRSYSMODS will show it,
Do you mean LIST HOLDERROR? or perhaps REPORT ERRSYSMODS?
Either way, it will not. Doc and Action
I don't know of any sysprog in his/her right mind who would willy-nilly perform
any SMP/E action hold without going through the hold actions to see if they are
required or need tweaking at a particular shop.
It's no different from the ServerPac jobs that slam a whole slug of security
changes
On 5/18/2017 4:00 PM, Jesse 1 Robinson wrote:
This is a swampy area captured in the caveat 'perform these steps if you choose
to use it'. If a shop has not already RDEFINEd MVS.MCSOPER.* with elaborate
profile support in place, blandly issuing these commands as documented would
immediately
On 2017-05-18, at 14:01, Jesse 1 Robinson wrote:
> This is a swampy area captured in the caveat 'perform these steps if you
> choose to use it'.
>
Ugh.
On 2017-05-18, at 13:10, Burrell, Todd wrote:
> Well this really should have been labeled as HOLD(ACTION).And I usually
> look through
This is a swampy area captured in the caveat 'perform these steps if you choose
to use it'. If a shop has not already RDEFINEd MVS.MCSOPER.* with elaborate
profile support in place, blandly issuing these commands as documented would
immediately bring a shop to its knees. Putting a HOLD(ACTION)
Well this really should have been labeled as HOLD(ACTION).And I usually
look through the DOC for stuff like this, but I've never seen something quite
so egregious.
Todd Burrell | Sr. Mainframe Systems Administrator
CSX Technologies| 550 Water St. (634I), Jacksonville, FL 32202
For those of you who always laughed when I said read your HOLD(DOC) for
buried HOLD(ACTION) items. Here it is kids, so for those of you who
still ignore HOLD(DOC), keep telling yourselves that you're saving time
and I'm crazy for looking at HOLD(DOC).
++HOLD(UI43841) SYSTEM FMID(HSMA21A)
On Thu, 18 May 2017 08:09:03 -0700, Charles Mills wrote:
>I hope you are getting the idea how risky this entire approach is. You are
>playing "you bet your mainframe." You might get it right today
And if you don't get it right, you might discover that, or you might not.
It is very difficult
On 18 May 2017 at 08:56, Robin Atwood wrote:
> What is the situation of a module that is loaded from an authorised library
> but was linked with AC=0? Is it authorised? Can it get authorised?
>
Modules are not authorized. Job steps are authorized.
If you are able to get
"Magic" SVCs are the scourge of z/OS integrity.
The amount of validation you have to do to make a magic SVC airtight exceeds
the burden of simply doing it right: linking the program AC=1 into an
APF-authorized library.
They used to be common in vendor products: easier to write a magic SVC than
Early versions of SDSF provided an SVC that would make the user authorized. It
was 'supported' in that it was part of an official IBM program product. There
was a general discomfort with this strategy even though the SVC code tried very
hard to validate the environment. Eventually (I believe)
Tom answered most of your question but in addition
> Can it get authorised?
I don't think there is any supported way for a program that is already
running to "get authorized."
I hope you are getting the idea how risky this entire approach is. You are
playing "you bet your mainframe." You might
>UPDATE JOB(*) is dangerous
>However, we use it with no ill effect.
To be picky, that cannot be a wholly correct statement. What might be
correct is that you have observed no ill effects in the times that you
have used it so far.
Peter Relson
z/OS Core Technology Design
On Thu, 18 May 2017 19:56:27 +0700, Robin Atwood wrote:
>What is the situation of a module that is loaded from an authorised library
>but was linked with AC=0? Is it authorised? Can it get authorised?
Loaded by whom?
When you EXEC PGM=x, if program X is linked AC=1 and is loaded from
an APF
What is the situation of a module that is loaded from an authorised library
but was linked with AC=0? Is it authorised? Can it get authorised?
Thanks
Robin
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: 16 May 2017
IBM has announced CICS Transaction Server Version 5.4:
https://www.ibm.com/common/ssi/rep_ca/3/897/ENUS217-113/ENUS217-113.PDF
This release of CICS supports the *full* Java Enterprise Edition (JEE) 7
specification -- really quite amazing. There are also some interesting and
useful batch
21 matches
Mail list logo