Re: CICS down after transaction exec wait macro.

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 03/28/2006
   at 09:04 PM, Chris Mason <[EMAIL PROTECTED]> said:

>One interpretation of what Shmuel says is that it is still something 
>a CICS transaction programmer shouldn't even think of doing.

Is there another interpretation[1]? But note that the "it" in question
was doing the WAIT in the CICS main task; the current CICS allows a
transaction to request execution in a subtask.

[1] That's a separate question from whether you agree with what I
wrote. IAC, it's not my dog.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: CICS down after transaction exec wait macro.

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on
03/28/2006
   at 03:28 PM, Jorge Arueira Campos <[EMAIL PROTECTED]> said:

>Issuing a wait macro in a CICS transaction, in the main task, is 
>forbidden. Why no have a protection for not down the CICS ???

It would be expensive to enforce the various rules that a transaction
should follow. However, usually issuing a WAIT will only cause
performance problems.

>Is necessary open a call in support IBM for this problem ???

Only if it's an IBM product issuing the WAIT. Also, keep in mind that
this applies only to a WAIT in the CICS main task. The current CICS
has support for a transaction to request execution in a subtask.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: CICS down after transaction exec wait macro.

[Chris Mason]

Jorge,

If this were 30 years ago, I would say that the understanding of the way
CICS works would have prevented you from thinking about putting a WAIT into
a CICS transaction. Because IBM could reasonably have expected you to know
that as someone who had been given the job of writing a CICS transaction, I
would say there's no case to answer. Today I just wouldn't know whether CICS
had changed enough for that still to be the case. Some of the responders to
this thread have speculated that issuing the WAIT might be acceptable - with
some rather complex provisions. One interpretation of what Shmuel says is
that it is still something a CICS transaction programmer shouldn't even
think of doing.

I then tried to think how CICS could "police" the transaction code. If CICS
were interpreting the programming statements in some way as is done with
REXX or APL code, the code interpreter could spot anything that was
"forbidden" - but why have the instruction/statement at all if it was
forbidden?  In a sense, issuing SVCs is comparable to running with an
interpreter so it's possible to imagine there could be an MVS function to
filter issuing SVCs, which, if it existed - and I'm so ignorant of MVS these
days, maybe such a function does exist - CICS could use for its "policing".

It might be more productive to explain what it was you were trying to do. It
may also be better to ask in the presence of CICS specialists. I just peeked
at the "About Group" for "bit.listserv.cics-l", the "CICS Discussion List",
and the activity is very low at the moment. However, last September had more
than 400 posts within the month so, unless a small number of subscribers had
a "frank exchange of views", there may be quite a few lurking.

Chris Mason

- Original Message - 
From: "Jorge Arueira Campos" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: 
Sent: Tuesday, 28 March, 2006 8:28 PM
Subject: Re: CICS down after transaction exec wait macro.


> Hi !!!
>
> Issuing a wait macro in a CICS transaction, in
> the main task, is forbidden. Why no have a protection for not down the
CICS
> ??? There are a problem if the user coded a macro WAIT in your program and
> issue in CICS region and shutdown the entire product. Is necessary open a
> call in support IBM for this problem ???
>
> Thanks for help me
>
> Jorge Arueira Campos
>
> CAIXA ECONOMICA FEDERAL - OSASCO - SP - BRAZIL
>
> On 3/26/06, Shmuel Metz (Seymour J.) <[EMAIL PROTECTED]> wrote:
> >
> > In <[EMAIL PROTECTED]>, on 03/25/2006
> >   at 06:33 PM, Chris Mason <[EMAIL PROTECTED]> said:
> >
> > >I'm glad other, sharper "problem vultures" have spotted the two - so
> > >far - flaws in the original code. But the matter here is whether
> > >issuing a WAIT in a CICS transaction at all is "a good thing" or not.
> >
> > I'd go farther and say that issuing a wait in a CICS transaction, in
> > the main task, is forbidden.
> >
> > --
> > Shmuel (Seymour J.) Metz, SysProg and JOAT
> > ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
> > We don't care. We don't have to care, we're Congress.
> > (S877: The Shut up and Eat Your spam act of 2003)

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

Re: CICS down after transaction exec wait macro.

[Jorge Arueira Campos]

Hi !!!

Issuing a wait macro in a CICS transaction, in
the main task, is forbidden. Why no have a protection for not down the  CICS
??? There are a problem if the user coded a macro WAIT in your program and
issue in CICS region and shutdown the entire product. Is necessary open a
call in support IBM for this problem ???

Thanks for help me

Jorge Arueira Campos

CAIXA ECONOMICA FEDERAL - OSASCO - SP - BRAZIL

On 3/26/06, Shmuel Metz (Seymour J.) <[EMAIL PROTECTED]> wrote:
>
> In <[EMAIL PROTECTED]>, on 03/25/2006
>   at 06:33 PM, Chris Mason <[EMAIL PROTECTED]> said:
>
> >I'm glad other, sharper "problem vultures" have spotted the two - so
> >far - flaws in the original code. But the matter here is whether
> >issuing a WAIT in a CICS transaction at all is "a good thing" or not.
>
> I'd go farther and say that issuing a wait in a CICS transaction, in
> the main task, is forbidden.
>
> --
> Shmuel (Seymour J.) Metz, SysProg and JOAT
> ISO position; see 
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

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

Re: CICS down after transaction exec wait macro.

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 03/25/2006
   at 06:33 PM, Chris Mason <[EMAIL PROTECTED]> said:

>I'm glad other, sharper "problem vultures" have spotted the two - so
>far - flaws in the original code. But the matter here is whether  
>issuing a WAIT in a CICS transaction at all is "a good thing" or not.

I'd go farther and say that issuing a wait in a CICS transaction, in
the main task, is forbidden.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: CICS down after transaction exec wait macro.

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Ted MacNEIL
> 
> >Strictly verbotten in every shop I've ever been in, but there  are 
> >always exceptions.
> 
> If you can get the wait off of the main TCB (TCA?), it's not 
> as bad, but IBM (and almost every CICS sysprog I know) still 
> strongly recommends against it.

For the past few releases of CICS (since TS 1.3; possibly earlier) the
EXEC CICS WAIT EVENT and EXEC CICS WAIT ECBLIST commands have been
available for the kinds of processing for which the WAIT macro is
intended.

With CICS TS 3.1 (and presumably follow-on releases) and appropriate
exploitation of the enhanced Open Transaction Environment (OTE), use of
traditionally "frowned-upon" MVS services within CICS tasks will become
moot as long as those tasks are running on their own TCBs rather than
the CICS QR TCB.  The basis for "frowning upon" invoking MVS services
that could cause a WAIT was that such a WAIT would effectively "stall"
the CICS address space:  The CICS (sub-)dispatcher would be unable to
dispatch other work while WAITing for whatever because it ran on the
same TCB.

-jc-

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

Re: CICS down after transaction exec wait macro.

[Tom Schmidt]

On Sat, 25 Mar 2006 20:13:29 -0500, Don Poitras wrote:

>In article <[EMAIL PROTECTED]> you wrote:
>> On Fri, 24 Mar 2006 21:58:00 -0300, Jorge Arueira Campos wrote:
>
>> >I don't know what happened in cics region. Anybody have a information of
>> >PTF or APAR related with this problem, macro WAIT of SYS1.MACLIB
>> >executed under CICS 220 ???
>
>You can now have a CICS transaction call MVS WAIT if it is defined as
>"thread safe" and uses the newish OPENAPI support. The transacation is
>switched from the QR (Quasi-reentrant) TCB that runs traditional CICS
>work to a separate TCB that is allowed to issue commands that directly
>or indirectly call MVS WAIT. See:
>
>http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?
topic=/com.ibm.cics.ts.doc/dfhe4/OpenAPI/dfhe4_overview.htm
>
>Some work is needed to ensure that the program truly is thread safe or
>serialization problems could occur.

Yes, for some value of "now" that would NOT include his version of CICS
(CICS 220).  His level of CICS precludes threadsafe processing by several
releases.  (It might even preceed the TRUE processing I previously
mentioned, I'm not sure.)

--
Tom Schmidt
Madison, WI

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

Re: CICS down after transaction exec wait macro.

[Don Poitras]

In article <[EMAIL PROTECTED]> you wrote:
> On Fri, 24 Mar 2006 21:58:00 -0300, Jorge Arueira Campos wrote:

> >I don't know what happened in cics region. Anybody have a information of
> >PTF or APAR related with this problem, macro WAIT of SYS1.MACLIB executed
> >under CICS 220 ???


> Did your SUPX transaction execute in USERKEY or in CICSKEY?  I expect that
> an MVS WAIT such as yours would require CICSKEY.

> Your transaction does not seem to be well-designed (or well written?).  You
> ought to either be using EXEC CICS WAIT-style API calls to accomplish your
> synchronization or else you ought to be using a CICS TRUE to accomplish the
> multi-tasking.

You can now have a CICS transaction call MVS WAIT if it is defined as
"thread safe" and uses the newish OPENAPI support. The transacation is
switched from the QR (Quasi-reentrant) TCB that runs traditional CICS
work to a separate TCB that is allowed to issue commands that directly
or indirectly call MVS WAIT. See:

http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=/com.ibm.cics.ts.doc/dfhe4/OpenAPI/dfhe4_overview.htm

Some work is needed to ensure that the program truly is thread safe or
serialization problems could occur.

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
[EMAIL PROTECTED]   (919) 531-5637Cary, NC 27513

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

Re: CICS down after transaction exec wait macro.

[Tom Schmidt]

On Fri, 24 Mar 2006 21:58:00 -0300, Jorge Arueira Campos wrote:

>A test of transaction(SUPX) under CICS V2.2.0, in instructions wait coded
>below, down the CICS.
>
>289  WAIT  5,ECBLIST=LISTECBS
>290+*MACDATE  10/20/88
>292+ LA0,5(0,0)LOAD PARAMETER REG 0
>294+ LA1,LISTECBSLOAD PARAMETER R
>295+ LCR   1,1 INDICATE ECBLIST USED
>296+ SVC   1   LINK TO WAIT ROUTINE
>
>LISTECBS DSA
>  DCX'80',AL3(WAITECB)
> WAITECB  DCF'0'
>The cicslog:
>
>+DFHXM0212 A23CICSF Transaction SUPX has been attached with unknown
>tranclass CLASSE03
>+DFHSR0606 A23CICSF Abend (code 201/AKEB) has been detected.
>+DFHME0116 A23CICSF
>273
> (Module:DFHMEME) CICS symptom string for message DFHSR0606
>is
> PIDS/5697E9300 LVLS/620 MS/DFHSR0606 RIDS/DFHSRP
>PTFS/UQ83467 AB/S0201 AB/UAKEB
>+DFHDU0205 A23CICSF A SYSTEM DUMP FOR DUMPCODE: SR0606  , WAS SUPPRESSED BY
>THE OPTION

...

>+DFHDU0303I A23CICSF Transaction Dump Data set DFHDMPA closed.
>+DFHKE1800 A23CICSF ABNORMAL TERMINATION OF CICS IS COMPLETE.
>IEF450I CICSFA CICSFA - ABEND=S000 U1800 REASON=  341
>TIME=18.28.40
>IEF404I CICSFA - ENDED - TIME=18.28.41
>IEF352I ADDRESS SPACE UNAVAILABLE
>$HASP395 CICSFA   ENDED
>
>I don't know what happened in cics region. Anybody have a information of
>PTF or APAR related with this problem, macro WAIT of SYS1.MACLIB executed
>under CICS 220 ???


Did your SUPX transaction execute in USERKEY or in CICSKEY?  I expect that
an MVS WAIT such as yours would require CICSKEY.

Your transaction does not seem to be well-designed (or well written?).  You
ought to either be using EXEC CICS WAIT-style API calls to accomplish your
synchronization or else you ought to be using a CICS TRUE to accomplish the
multi-tasking.

Also, as Richard (I believe) already pointed out -- your ECB list is not
properly constructed; you have "LISTECBS DS A " where you should
have "LISTECBS DS 0A " and that is most likely the cause of the initial
failure.  Your ECB list storage was not properly initialized/setup.  My
other suggestions (above) should be considered once you get past that
failure (by inserting the '0' where appropriate).

(Free advice - worth at least what you paid for it.)

--
Tom Schmidt
Madison, WI

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

Re: CICS down after transaction exec wait macro.

[Ted MacNEIL]

>Strictly verbotten in every shop I've ever been in, but there  are always 
exceptions.

If you can get the wait off of the main TCB (TCA?), it's not as bad, but IBM 
(and almost every CICS sysprog I know) still strongly recommends against it.

-
-teD

I’m an enthusiastic proselytiser of the universal panacea I believe in!

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

Re: CICS down after transaction exec wait macro.

[Chris Mason]

Ed,

I'm glad other, sharper "problem vultures" have spotted the two - so far -
flaws in the original code. But the matter here is whether  issuing a WAIT
in a CICS transaction at all is "a good thing" or not.

In the old days, the early seventies when I first came across CICS, issuing
a WAIT in a CICS transaction would have been suicide for CICS. This is
because it relied upon the famous "multiple wait" to schedule all
transactions under one operating system task, a construction all who had
struggled with BTAM programming had had to learn the hard way (for disk
access you could fudge it and claim it was fast enough anyhow not to bother
joining the "multiple wait"). What the situation is lately - which, in my
terms with regard to CICS, is from the early eighties to now - I have very
little idea.

Again, thinking about those early days of CICS, having to delay within a
transaction would have meant splitting the transaction into two at the point
of the delay and then arranging to schedule the second part using some CICS
function I really can't recall now. It's just the principle that remains
burned in my memory.

Chris Mason

- Original Message - 
From: "Ed Finnell" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: 
Sent: Saturday, 25 March, 2006 6:04 PM
Subject: Re: CICS down after transaction exec wait macro.


>
> In a message dated 3/25/2006 10:36:03 A.M. Central Standard Time,
> [EMAIL PROTECTED] writes:
>
> Isn't  WAITing in a CICS transaction frowned upon?
>
>
>
> >>
> Strictly verbotten in every shop I've ever been in, but there  are always
> exceptions.

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

Re: CICS down after transaction exec wait macro.

[Ed Finnell]

 
In a message dated 3/25/2006 10:36:03 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

Isn't  WAITing in a CICS transaction frowned upon?



>>
Strictly verbotten in every shop I've ever been in, but there  are always 
exceptions.

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

Re: CICS down after transaction exec wait macro.

[Bob Rutledge]

Assuming there's nothing missing from this code sample, there are too few 
entries in LISTECBS to satisfy the wait count (5).


Isn't WAITing in a CICS transaction frowned upon?

Bob

Jorge Arueira Campos wrote:

Hi all

A test of transaction(SUPX) under CICS V2.2.0, in instructions wait coded
below, down the CICS.

289  WAIT  5,ECBLIST=LISTECBS
290+*MACDATE  10/20/88
292+ LA0,5(0,0)LOAD PARAMETER REG 0
294+ LA1,LISTECBSLOAD PARAMETER R
295+ LCR   1,1 INDICATE ECBLIST USED
296+ SVC   1   LINK TO WAIT ROUTINE

LISTECBS DSA
  DCX'80',AL3(WAITECB)
 WAITECB  DCF'0'


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

Re: CICS down after transaction exec wait macro.

[Richard Tsujimoto]

Jorge coded:

>A test of transaction(SUPX) under CICS V2.2.0, in instructions wait coded
>below, down the CICS.

>289  WAIT  5,ECBLIST=LISTECBS
>290+*MACDATE  10/20/88
>292+ LA0,5(0,0)LOAD PARAMETER REG 0
>294+ LA1,LISTECBSLOAD PARAMETER R
>295+ LCR   1,1 INDICATE ECBLIST USED
>296+ SVC   1   LINK TO WAIT ROUTINE

>LISTECBS DSA
>  DCX'80',AL3(WAITECB)
>WAITECB  DCF'0'

Does LISTECBS actually have an address of an ECB, or did you mean:

LISTECBS DS 0A

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

Re: CICS down after transaction exec wait macro.

[Lizette Koehler]

Jorge,

One last thought, have you asked on the CICS-L list.  They may have some 
experience with this type of issue.

Lizette

-Original Message-
>From: [EMAIL PROTECTED]
>Sent: Mar 24, 2006 6:15 PM
>To: IBM Mainframe Discussion List 
>Subject: Re: CICS down after transaction exec wait macro.
>
>Jorge,
>
>I assume you are CICS TS2.2  what version of operating system?
>
>
>I am not sure but I think you need to start with a S0201 abend with MVS or 
>z/OS.  In the MVS messages & codes (or z/OS) the error indicaties:
> 201   
>   
> Explanation:  During processing of a WAIT macro, the system found either: 
>   
> O   The macro expansion contained an incorrect address for an event   
> control block (ECB)   
>   
> O   The program issuing the WAIT macro was not running under the same 
> storage protection key as the storage containing the ECB  
>   
> System Action:  The system abnormally ends the program that issued the
> WAIT macro.   
>   
> Programmer Response:  Ensure that the ECB address specified is a valid
> virtual storage address and that it was not incorrectly modified. Correct 
> the error. Run the job again. 
>   
>
>Not sure if this helps.  If I had a dump to look at, I could see if this 
>applies or not.  If this is the case, then I would ask what has changed.  Any 
>code changes, ptfs installed,  the normal drill.
>
>Lizette Koehler

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

Re: CICS down after transaction exec wait macro.

[Lizette Koehler]

Jorge,

I assume you are CICS TS2.2  what version of operating system?


I am not sure but I think you need to start with a S0201 abend with MVS or 
z/OS.  In the MVS messages & codes (or z/OS) the error indicaties:
 201   
   
 Explanation:  During processing of a WAIT macro, the system found either: 
   
 O   The macro expansion contained an incorrect address for an event   
 control block (ECB)   
   
 O   The program issuing the WAIT macro was not running under the same 
 storage protection key as the storage containing the ECB  
   
 System Action:  The system abnormally ends the program that issued the
 WAIT macro.   
   
 Programmer Response:  Ensure that the ECB address specified is a valid
 virtual storage address and that it was not incorrectly modified. Correct 
 the error. Run the job again. 
   

Not sure if this helps.  If I had a dump to look at, I could see if this 
applies or not.  If this is the case, then I would ask what has changed.  Any 
code changes, ptfs installed,  the normal drill.

Lizette Koehler

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