SMP/E BYPASS( HOLDSYS( <reason-list> ) )

[Paul Gilmartin]

Why do programmers use "BYPASS( HOLDSYS( <reason-list> ) )"
rather than merely BYPASS( HOLDSYSTEM )? Are there some
reason codes to which they particularly want to be alerted
while others can be routinely bypassed by appearing in the
list?

What's the process? Perhaps first:

APPLY CHECK BYPASS( HOLDSYS( <ordinary-reasons> ) ) ...,
then resolve the unusual reason codes (GIM35965I) and do
APPLY BYPASS( HOLDSYSTEM ) ...?

(Just wondering what we should supply in our JCL samples.)

(In internal testing of PTFs, I'm inclined to supply a list
to detect typos in ++HOLD SYSTEM REASON( bogus ) ... MCS.)

Thanks,
gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Skip Robinson]

I always use the vanilla HOLDSYS with no qualifications. On the other
hand, I'm comfortable with letting sysmods fail for 'obvious' reasons like
missing co-reqs that are not yet available. RC 8 is not scary if you can
see in the CAUSER report that life will go on for now. Frankly, I'm
suspicious of a sizable APPLY that gets RC 0. Something must be getting
overlooked. ;-)

.
.
JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
JO.Skip....@sce.com

[Scott Rowe]

I too use the generic HOLDSYS, and since I run APPLY CHECKS first, and
review the hold listing, I see (and review) every hold that I'm bypassing
before I do the real APPLY.

CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains
confidential and privileged information intended only for the addressee.
If you are not the intended recipient, please be advised that you have
received this material in error and that any forwarding, copying, printing,
distribution, use or disclosure of the material is strictly prohibited.
If you have received this material in error, please (i) do not read it,
(ii) reply to the sender that you received the message in error, and
(iii) erase or destroy the material. Emails are not secure and can be
intercepted, amended, lost or destroyed, or contain viruses. You are deemed
to have accepted these risks if you communicate with us by email. Thank you.

[Bill Johnson]

The real apply when doing a bypass holdsys does not get a zero return code but a
4.

________________________________
From: Scott Rowe <scott...@JOANN.COM>
To: IBM-...@bama.ua.edu
Sent: Tue, April 5, 2011 3:04:18 PM
Subject: Re: SMP/E BYPASS( HOLDSYS( <reason-list> ) )

[Paul Gilmartin]

On Tue, 5 Apr 2011 12:10:53 -0700, Bill Johnson wrote:

>The real apply when doing a bypass holdsys does not get a zero return code but a 4.
>

I thought that lately there was an option to cause RC=0 in this case.
But I can't find it in the manuals.

-- gil

[Gerri Booth]

Beginning with SMP/E V3.5 the severity of messages issued for
BYPASS(HOLDSYS) changed from “warning” to “informational”, so they result in
RC=00. In order to get the old behavior (RC=04) you have to add the
COMPAT(WARNBYPASS) parm to the EXEC stmt for the SMP/E job.

[Bob Rutledge]

Paul Gilmartin wrote:
> On Tue, 5 Apr 2011 12:10:53 -0700, Bill Johnson wrote:
>
>> The real apply when doing a bypass holdsys does not get a zero return code but a 4.
>>
> I thought that lately there was an option to cause RC=0 in this case.
> But I can't find it in the manuals.
>

Actually, these days (V3R5) you have to specify PARM='COMPAT(WARNBYPASS)' to get
the RC=4. It's in the User's Guide.

Bob

[R.S.]

W dniu 2011-04-05 22:25, Bob Rutledge pisze: > Paul Gilmartin wrote: >> On Tue, 5 Apr 2011 12:10:53 -0700, Bill Johnson wrote: >>> The real apply when doing a bypass holdsys does not get a zero return >>> code but a 4. >> I thought that lately there was an option to cause RC=0 in this case. >> But I can't find it in the manuals. > Actually, these days (V3R5) you have to specify > PARM='COMPAT(WARNBYPASS)' to get the RC=4. It's in the User's Guide. I noticed the change, but I was to lazy to check it in the manual. BTW: I always enumerate HOLDSYS reasons. Why? This is kind of documentation. I always archive the jobs and outputs. A list of reasons quickly tell me what can I look for. Yeah, I know, I should use autorun.inf <vbg> Radoslaw Skorupka Lodz, Poland tej wiadomo ci mo e zawiera informacje prawnie chronione Banku przeznaczone wy cznie do u ytku s bowego adresata. Odbiorc 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 wiadomo omy kowo, prosimy niezw ocznie zawiadomi nadawc wysy c odpowied oraz trwale usun wiadomo 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 authorised 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. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, e-mail: in...@brebank.pl d Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru S dowego, nr rejestru przedsi biorc w KRS 0000025237, NIP: 526-021-50-88. ug stanu na dzie 01.01.2011 r. kapita zak adowy BRE Banku SA (w ca ci wp acony) wynosi 168.346.696 z otych. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Bill Johnson]

15.43.10 JOB08993 -STEPNAME PROCSTEP
Not reacting that way here.

15.43.10 JOB08993 -STEPNAME PROCSTEP RC EXCP CONN
15.43.10 JOB08993 -S1 04 310K 97228
15.43.10 JOB08993 -XXXXAPLY ENDED. NAME-APLY RSU1012

. APPLY
. PTFS
. BYPASS (
. HOLDSYSTEM
. (
. ACTION
. DB2BIND
. DELETE
. DOC
. EXIT
. IPL
. MULTSYS
. )
. )
. EXCLUDE (
. UK59308
. UK59650
. )
. SOURCEID (
. RSU1012
. )
. RETRY(YES)

01/10/11 TIME 15:35:07 SMP/E 35.32

________________________________
From: Gerri Booth <gerri...@WISCONSIN.GOV>
To: IBM-...@bama.ua.edu
Sent: Tue, April 5, 2011 4:22:14 PM

Subject: Re: SMP/E BYPASS( HOLDSYS( <reason-list> ) )

Beginning with SMP/E V3.5 the severity of messages issued for

[Gerri Booth]

The RC=0 from BYPASS(HOLDSYSTEM) under SMP/E 3.5 is for both APPLY CHECK and
APPLY. Try an APPLY CHECK job with the COMPAT(WARNBYPASS) parm on the EXEC
and you'll get RC=4 for the job.

The primary reason you'd get RC=4 on the APPLY after getting RC=0 on the
APPLY CHECK is because of RETURN CODE = 4 from the binder. Look at the
GIM42001 and GIM35966 msgs in the output. Those are the messages that
result from the BYPASS(HOLDSYS). If they end with an I rather than a W then
that means they are returning RC=0. Only messages ending in W result in
RC=4. In my APPLY jobs those are always GIM23913W (LINK-EDIT PROCESSING FOR
SYSMOD UA55316 WAS SUCCESSFUL FOR MODULE ISTAPCTQ IN LMOD ISTAPVL1 IN THE
SISTCLIB LIBRARY. THE RETURN CODE WAS 04).

[Bill Johnson]

Thanks for clearing that up. I received RC=4 under earlier releases of SMP/E and
still receive RC=4 but because of the reason you point out. Yes, the old bypass
warnings are now informational. Never really paid that much attention to RC=4
under most circumstances.

________________________________
From: Gerri Booth <gerri...@WISCONSIN.GOV>
To: IBM-...@bama.ua.edu

Sent: Wed, April 6, 2011 9:46:13 AM