RE: CICS/TS Storage Violation

[Randy Evans]

I suggest starting with the storage violation dump first, since there is
a better than even chance that the storage violation caused the
subsequent OC1/AKEA abend. The SM0102 dump will be most useful for
identifying the scope of the storage violation problem, since you can
usually get a pretty good idea where the storage violation starts and
maybe even where it stops. Knowing where the storage violation starts is
the one of the most useful pieces of information for troubleshooting
storage violations.

Since CICS itself detected the storage violation, run the "ANALYZE CICS
DUMP" function of storage dump management on the SM0102 dump, with level
3 options for trace (TR) and storage management (SM) domains. The output
from that should be helpful in identifying the start of the corrupted
storage area - it may be tedious research if it is a large/active CICS
partition, but the info should be in there.

Analyzing the SR0001 dump may be superfluous after reviewing the
preceding SM0102 dump, since it is quite likely that the storage
violation caused the subsequent 0C1/AKEA. But if you're of a mind to
pursue it, run the ANALYZE CICS DUMP with level 3 option for the trace
domain. There will be a trace entry detail item with 0C1/AKEA that
contains the PSW and saved registers from the abend. This information is
also available else where in the dump, but the trace entry may be the
quickest way to extract it - just run the dump and search for the
0C1/AKEA trace entry.

Randy Evans, Viaserv, Inc.

> Subject: [148383] CICS/TS Storage Violation
>
> Based on the two system dumps taken (I don't have any
transaction
> dump), is it possible to determine where the TPDNLOAD program
(transaction
> TPS1) messed up? If so, I need someone to teach me how to do this.
> Thanks.
>
> I2 0124 DFHSM0102 CICSDATA A storage violation (code X'0D11') has been
> 08:13:37
> detected by module DFHSMMF . 08:13:37
> I2 0124 DFHME0116 CICSDATA 08:13:37
> (Module:DFHMEME) CICS symptom string for message DFHSM0102 is
> 08:13:37
> PIDS/564805400 LVLS/411 MS/DFHSM0102 RIDS/DFHSMMF PTFS/VSE411
> 08:13:37
> PRCS/00000D11. 08:13:37
> I2 0124 DFHDU0201 CICSDATA ABOUT TO TAKE SDUMP. DUMPCODE: SM0102 ,
> DUMPID:
> 345/0003 08:13:37
> I2 0124 0S24I AN SDUMP OR SDUMPX MACRO WAS ISSUED 08:13:37
> I2 0124 0S29I DUMP STARTED 08:13:37
> I2 0124 0S30I DUMP STARTED. MEMBER=DI200764.DUMP IN
SUBLIB=SYSDUMP.SUBLIB
>
> I2 0124 1I51I DUMP COMPLETE 08:13:43
> I2 0124 DFHDU0202 CICSDATA SDUMPX COMPLETE. SDUMPX RETURN CODE X'00'
> 08:13:43
> ------- --------------------------------------------------------------
> --------
> I2 0124 DFHSR0001 CICSDATA An abend (code 0C1/AKEA) has occurred at
offset
>
> X'FFFFFFFF' in program TPDNLOAD. 08:13:44
> I2 0124 DFHME0116 CICSDATA 08:13:44
> (Module:DFHMEME) CICS symptom string for message DFHSR0001 is
> 08:13:44
> PIDS/564805400 LVLS/411 MS/DFHSR0001 RIDS/DFHSRP PTFS/VSE411
> AB/S00C1
> AB/UAKEA RIDS/TPDNLOAD ADRS/FFFFFFFF. 08:13:44
> I2 0124 DFHDU0201 CICSDATA ABOUT TO TAKE SDUMP. DUMPCODE: SR0001 ,
> DUMPID:
> 345/0004 08:13:44
> I2 0124 0S24I AN SDUMP OR SDUMPX MACRO WAS ISSUED 08:13:44
> I2 0124 0S29I DUMP STARTED 08:13:44
> I2 0124 0S30I DUMP STARTED. MEMBER=DI200765.DUMP IN
SUBLIB=SYSDUMP.SUBLIB
>
> I2 0124 1I51I DUMP COMPLETE 08:13:50
> I2 0124 DFHDU0202 CICSDATA SDUMPX COMPLETE. SDUMPX RETURN CODE X'00'
> 08:13:50
> ------- --------------------------------------------------------------
> --------
> I2 0124 DFHPEP: TPS1 ABEND ASRA IN TPDNLOAD ON BY CICSUSER
08:13:50
> LAST FN=X'0E08' RC=X'000000' RS=000 R2=000 DS=DAPSYSF 08:13:50
>
> Sincerely,
>
> Dave Clark
>
> WinWholesale Group Services
> 3110 Kettering Boulevard
> Dayton, Ohio 45439 USA
> (937) 294-5331
>

[indust...@winwholesale.com]

owner...@Lehigh.EDU wrote on 01/28/2009 10:22:41 AM:
> I suggest starting with the storage violation dump first, since there
> is a better than even chance that the storage violation caused the
> subsequent OC1/AKEA abend.

        Yes, once I realized the second dump was for an operation exception, I knew that it was a result of the storage violation and not really something I needed to pursue.  So, now I'm left with the problem of how to tell who actually caused the storage violation.  I thought that CICS/TS made it easy to know this -- because it would terminate the violator.  Thus, I thought the second dump was because of CICS terminating the violator.  So now I'm lost.

> ... CICS itself detected the storage violation, run the "ANALYZE CICS

> DUMP" function of storage dump management on the SM0102 dump, with

> level 3 options for trace (TR) and storage management (SM) domains.

        I actually ran my standard CICS/TS dump analysis options on it:

SELECT DUMP VIEWING                                    
       CALL DFHPD410 DATA AP=3,DS=3,KE=3,LD=3,TR=3,SM=3
       PRINT FORMAT                                    
       RETURN

        I found three large areas that had been overlaid, but the overlaying data was not something I recognized.  It seems it should be significant that two of these areas had both beginning and ending SAA's overlaid, but the first area had only the ending SAA overlaid.  So is task number 15323 the culprit?

   1280 -    12FF LINES SAME AS ABOVE                                                                                    006CE280
   1300  40404040 40404040 C2F0F0F1 F5F3F2F3                                       *        B0015323                *    006CE300

USER24.15323 006EB000 USER storage below 16MB

   0000  C2F0F0F1 F5F3F2F3 0980F0F0 F9F9F640  40404040 40404040 40404040 40404040  *B0015323..00996                 *    006EB000
   0020  40404040 40404040 097EF0F0 F9F9F640  40404040 40404040 40404040 40404040  *        .=00996                 *    006EB020
...snip...
   2FE0  40404040 40404040 046EF0F0 F7F1F240  40404040 40404040 40404040 40404040  *        .>00712                 *    006EDFE0
   3000  40404040 40404040 046FF0F0 F7F1F240                                       *        .?00712                 *    006EE000

** DFHPD0125  Storage violation detected at 006EB000. Trailing SAA is invalid.

Sincerely,

Dave Clark

WinWholesale Group Services
3110 Kettering Boulevard
Dayton, Ohio  45439  USA
(937) 294-5331

This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission.

[Tony Thigpen]

Was the space with only one bad SAA before the ones with both bad SSA's?
If so, then 15323 is a good candidate.

Do you have storage protection turned on?

Tony Thigpen

[Eshu...@aol.com]

Hi Dave:

 

SAAs in CICS TS are used for terminal storage (TIOAs).  It looks like someone is moving a larger output message than what was GETMAINed.  Anyone make any changes to programs recently?  (Private note: Run SU/PROG/C and do you have the abend handler on?).

 

Regards,

Gene

---

A Good Credit Score is 700 or Above. See yours in just 2 easy steps!

[Martin Truebner]

> So is task
> number 15323 the culprit?

Maybe-

If it has a table of item-length 16 where the item has
at some location a binary field with 4 or less digits followed by a
numeric field with five digits:

very likely.

--
Martin
--
XML2PDF - create PDFs from within z/VSE or z/OS; more at
http://www.pi-sysprog.de

[Martin Truebner]

Tony,

> Do you have storage protection turned on?

I bet it is off. Why: the last modification (.?00712) was done to a page
which had no grumple zone. HW would have cought that at the moment it
happened as opposed to when the freemain for damaged piece is issued.

[indust...@winwholesale.com]

owner...@Lehigh.EDU wrote on 01/28/2009 11:50:07 AM:
> Do you have storage protection turned on?

        Yes, but I also had STGRCVY=YES, too.   ;-)   So I turned it off.

[indust...@winwholesale.com]

owner...@Lehigh.EDU wrote on 01/28/2009 11:42:57 AM:
> Anyone  make any changes to programs recently?  (Private
> note: Run SU/PROG/C and do  you have the abend handler on?).

        Yes, the abend handler is on, but don't know how to use it or the dump analyzer.  Also, yes, the following program was listed first, by your product, and is also the one which was the cause of the SV.   ;-)

PANA WINWHOLESALE               C\TREK ON-LINE      02F9DC30   DATE 01
APPLID  CICSDATA            C\TREK SUMMARY SCREENS             TIME 13
VERSION 4.1               COBOL PROGRAM DATE ANALYSIS          TERM I5
                                                                     
APE-NAME  COMP-DATE COMP-TIM PRG-NAME APE-ADDR LOAD-PNT ENTRY-PT  KEY
CMDPPGM  2009/01/26 17:22:44 CMDPPGM  02F9DC30 034BA000 834BA020 USER

[indust...@winwholesale.com]

owner...@Lehigh.EDU wrote on 01/28/2009 12:00:09 PM:
> I bet it is off. Why: the last modification (.?00712) was done to a page
> which had no grumple zone. HW would have cought that at the moment it
> happened as opposed to when the freemain for damaged piece is issued.

        Well, for some reason, storage protection is on but it waited until the FREEMAIN anyway:

15323 1 AP 00E1 EIP   ENTRY FREEMAIN                                              0004,006D7018 ._..,09000C04 ....
15323 1 SM 0D01 SMMF  ENTRY FREEMAIN              006EB008,EXEC,USER
15323 1 XM 1001 XMIQ  ENTRY SET_TRANSACTION       INCREMENT
15323 1 XM 1002 XMIQ  EXIT  SET_TRANSACTION/OK
15323 1 AP 1700 TFIQ  ENTRY SET_TERMINAL_FACILITY YES
15323 1 AP 1701 TFIQ  EXIT  SET_TERMINAL_FACILITY/OK
15323 1 SM 0D11 SMMF  *EXC* Storage_check_failed_on_freemain_request FREEMAIN,006EB008,EXEC,USER
15323 1 ME 0301 MEME  ENTRY SEND_MESSAGE          66,SM0102,0841B206 , 00000002,0841B1E8 , 00000008,SM

[Tony Thigpen]

With the branch address being 'FFFFFFFF', I suspect an overlay on
program storage. To overlay program storage, the 'bad' transaction would
need to be running with storage protection turned off. That normally
only happens with vendor code. (Or, TCP code.)

Tony Thigpen

-----Original Message -----
From: indust...@winwholesale.com

[Edward M Martin]

Hello Dave,

 

     Since you know the area of storage that was over laid, and INFOANA.

You will have to eyeball what is there.   I would think that 15323 is a victim and not the culprit.

If looks as if 15323 was finished and was freemaining the storage.

 

Eric is right about looking at the Storage violation first.  Maybe they are related to each other.

 

 

// EXEC INFOANA,SIZE=3172K        

   SELECT DUMP MANAGEMENT         

     DUMP NAME SYSDUMP.F2.DF200053

   RETURN                         

   SELECT DUMP VIEWING            

   PRINT 600000 601000                Just put in the address range.                 

   RETURN                          

   SELECT END                     

 

Ed Martin

Aultman Health Foundation

330-588-4723

ext 40441

---

From: owner-vs...@Lehigh.EDU [mailto:owner-vs...@Lehigh.EDU] On Behalf Of indust...@winwholesale.com
Sent: Wednesday, January 28, 2009 1:47 PM
To: VSE Discussion List
Subject: Re: CICS/TS Storage Violation

[Martin Truebner]

> Well, for some reason, storage protection is on but it waited
> until the FREEMAIN anyway

I have no idea what hardware you have that can wait.

All I can say is that if you run in USERKEY and try to modify a page
that is unowned (and hence in CICS-KEY) you get a "protection exception".

This is controlled by a single bit in a CR. If you have a case where it
waited until later ....

[indust...@winwholesale.com]

owner...@Lehigh.EDU wrote on 01/28/2009 01:57:47 PM:
> Since you know the area of storage that was over laid, and INFOANA.
> You will have to eyeball what is there.   I would think that 15323
> is a victim and not the culprit.
>
> If looks as if 15323 was finished and was freemaining the storage.

        Yep, and I've now verified that the data being overlaid across three different storage areas, starting in the one owned by task 15323, is also generated from within task 15323.  The data is a 2-byte TS item number and its related 30-byte sort key.

[indust...@winwholesale.com]

owner...@Lehigh.EDU wrote on 01/28/2009 02:11:05 PM:
> > Well, for some reason, storage protection is on but it waited
> > until the FREEMAIN anyway
> I have no idea what hardware you have that can wait.

        We're on a z/890-A04.

> All I can say is that if you run in USERKEY and try to modify a page
> that is unowned (and hence in CICS-KEY) you get a "protection exception".
> This is controlled by a single bit in a CR. If you have a case where it
> waited until later ....

        All I can testify to is that the SIT specifies that storage protection is on, CICS is running in a dynamic partition, and the transaction is defined in user key.  The only thing I see that says otherwise is in the RDO profile used by the transaction -- but that has to do with transaction isolation, yes?

PROTECTION          
 MSGInteg     ==> No
 Onewte       ==> No
 PROtect      ==> No
 Chaincontrol ==> No

        When CICS comes up, it says this:

I2 0056 DFHPA1103  CICSDATA END OF FILE ON SYSIPT.
I2 0056 DFHTR0103 TRACE TABLE SIZE IS 1024K
I2 0056 DFHSM0122I CICSDATA Limit of DSA storage below 16MB is 5,120K.
I2 0056 DFHSM0123I CICSDATA Limit of DSA storage above 16MB is 96M.
I2 0056 DFHSM0115I CICSDATA Storage protection is active.
I2 0121 DFHDM0101I CICSDATA CICS is initializing.

Sincerely,

Dave Clark

WinWholesale Group Services
3110 Kettering Boulevard
Dayton, Ohio  45439  USA
(937) 294-5331

> --
> Martin
> --
> XML2PDF - create PDFs from within z/VSE or z/OS; more at
> http://www.pi-sysprog.de

[Eshu...@aol.com]

Hi Dave:

 

I imagine that you have already asked the programming department to look at this program as there is a high probability (if the SV was not occurring before) that the changes they made are the cause.  Normally when the ending SCZ or SAA is the damaged area, it is usually the transaction in control that caused the storage violation.  You may want to look at the program and see if it does a GETMAIN for the terminal area or if there was a change to the terminal output as the area could be passed from a different program. The transaction that identified the program is one that is heavily used by clients when faced with SVs,especially when they start appearing for the 1st time and everything was fine before then.  It gives you a quick look at what changed from an application perspective.

 

The abend handler is quite simple to use once it is installed and activated.  Use the function XX/SVEX.  Option 1 can be used to turn it on if you didn't bring it up in the PLT. If you use this option you may want to check AP/TRUE to see that CTREKSVR is up and KE/GTAU to see if there is along running transaction called TSVR that captures the information.  The handler can be turned off by using option 2.  Option 3 presents any ASRAs (AP0001/SR0001), SVs (SM0102/SM0103) and SOSs that have occurred since midnight today.  If you want to see previous days,use PF2. In the case of an SV, you will get a view of the damaged areas and will inform whether the SV affected the front, back or both of the SCZ/SAA. It also gives you a list of who was in memory at the time the SV occurred. Normally, this list is just informative.  However,it is very useful when you determine that the transaction reflecting the SV was not the cause, that is, another transaction caused the SV.

 

In many cases, these types of SVs are usually the hardest to debug because the person that caused the SV, may or may not be in memory. So, as C\TREK captures different SVs, it also can be used to build a list of how many times a particular transaction was in memory when the SV occurred.  You could do this manually  but C\TREK has an option 5 that can do the accounting for you without you having to do it manually.  You simply use PF2 to identify the range (dates and if desired time) of SV instances on the VSAM file you want to summarize.  There is a chapter in the documentation that describes the abend handler and talks about SVs.

 

Sorry for the long email. The XX/SVEX is where we are adding the function you requested regarding the AEIx abends. Let me know if you have any questions.

 

Regards,

Gene

[Eshu...@aol.com]

Hi Dave:

 

The parameter STGRCVY=YES simply tells CICS to try and fix (recover) the damaged area when an SV occurs. It does not provide any type of storage protection for SVs.

 

Regards,  

[indust...@winwholesale.com]

owner...@Lehigh.EDU wrote on 01/28/2009 04:09:48 PM:
> Option 3 presents any ASRAs (AP0001/SR0001), SVs (SM0102/SM0103)
> and SOSs that have occurred since midnight today.
> If you want to see previous days,use PF2.

        Yep, CTREKSVR is loaded and TSVR is running.  I use the PLT to load these at CICS startup time.  I also tried PF2 -- but still got nothing.

########################################
#           SHOW DUMPS BETWEEN         #
#        APPLID CICSDATA               #
# FROM CCYYMMDD 20090126 HHMMSS 000000 #
# TO   CCYYMMDD 20090128 HHMMSS 161518 #
# TYPE OF DUMP ALL  SVO, TXD, SOS, ALL #
#                                      #
########################################

Sincerely,

Dave Clark

WinWholesale Group Services
3110 Kettering Boulevard
Dayton, Ohio  45439  USA
(937) 294-5331

[indust...@winwholesale.com]

owner...@Lehigh.EDU wrote on 01/28/2009 04:21:02 PM:
> The parameter STGRCVY=YES simply tells CICS to try and fix (recover)
> the  damaged area when an SV occurs. It does not provide any type of
> storage  protection for SVs.

        Right, but I figured if there was damaged storage, then I want an abend so that I can start working on the issue right away.

[Eshu...@aol.com]

Hi Dave:

 

The storage protection that is available in the SIT (STGPROT) only protects from a user key program trying to overlay a CICS key area.  If your application programs run in USER key, they could overlay other USER key areas belonging to the same task or another USER key task. Unfortunately, the vast majority of SVs are found at FREEMAIN time and also during task end processing.  If it was during task end processing, you will probably not have a TCA. 

 

Regards,

Gene

[Eshu...@aol.com]

Hi Dave:

 

The parameters

 

PROTECTION          
 MSGInteg     ==> No
 Onewte       ==> No
 PROtect      ==> No
 Chaincontrol ==> No

 

are not associated with transaction isolation (TI).  The RDO transaction definition parameter that has to do with TI is ISOLATE and the default is yes. The parameter you mention deal with multi-segment messages and how to recover when one of the segments (chain) fails. There are other issues but this is what they are used for.

 

Regards,

Gene

[Eshu...@aol.com]

Hi Dave:

 

Let me take a look.

 

Regards,

Gene

[indust...@winwholesale.com]

owner...@Lehigh.EDU wrote on 01/28/2009 04:33:53 PM:
> The RDO transaction definition parameter that has to
> do with TI is ISOLATE and the default is yes.

        Hmmm, that is strange because I can't find the ISOLATE parameter listed anywhere in my RDO screens.

[Eshu...@aol.com]

Hi Dave:

 

The only way you can do this is by using CSFE or a TRAP supplied by IBM (or a 3rd party debugging package).  The IBM/CSFE options adds a lot of CPU overhead because the entire storage chain obtained by the tasks are analyzed continuously.  If you can afford the overhead, then this is the option you want to use.  In this case you will get an SM0103 dump and it will automatically shut off when the dump is captured. So,if you can force or recreate it during off hours, then the tool is useful.

 

Regards,

Gene 

[Eshu...@aol.com]

Hi Dave:

 

Probably because IBM removed it because TI is not supported.  I'll send you a copy of the RDO screen from a z/OS system offline.

 

Regards,

Gene

[indust...@winwholesale.com]

owner...@Lehigh.EDU wrote on 01/28/2009 04:48:52 PM:
> The only way you can do this is by using CSFE or a TRAP supplied by
> IBM (or  a 3rd party debugging package).

        Yes, I'm familiar with that, and have used the following before.

CSFE DEBUG,FAQE=ON
CSFE DEBUG,TASKSTG=ON

        But that is not what I was referring to.  My understanding is that the STGRCVY option tells CICS to rebuild the SAA/SCZ pointers and let the transaction continue if it can.  Well, I don't want CICS to do that.  Thus, I expect the alternative is that CICS will abend the transaction.  Is that not so?

[Eshu...@aol.com]

Hi:

 

I must apologize to all of you for my mistake in responding to Dave. I did not notice that he responded to the list and not to me. I should have been more careful.

 

Regards,

Gene 

[Kevin Corkery]

That's OK Gene ... I always learn a few new things whenever you post  :-)

---

From: owner...@Lehigh.EDU [mailto:owner...@Lehigh.EDU] On Behalf Of Eshu...@aol.com
Sent: Wednesday, January 28, 2009 5:08 PM

To: VSE Discussion List
Subject: Re: CICS/TS Storage Violation

[Eshu...@aol.com]

Hi Dave:

 

This parameter usually causes a lot of confusion because the name (storage recovery) can be confused with storage protection. If I understand you correctly, what you are interested in is that CICS cancel the task when the SV occurs.  Unfortunately, CICS does not work that way when looking for SVs. CICS in general looks for the SM0102/SM0103 when the area is freed.  A lot can happen between the GETMAIN and FREEMAIN. In your case (the one presented), setting STGRCVY yes or no, will still only discover the SV at FREEMAIN and not when it occurred.

 

STGRCVY simply states whether or not you want the damaged area to be recovered for future use.  In the case of no, the damaged area is not recovered and the task is canceled. In the case of yes, the area is recovered and the task continues to execute. However, as the vast majority of SVs are discovered at task end and the task simply continues to finish which for all effects and purposes is like it was "canceled". If you look at the trace table before the SV for the case you posted, you will probably find that the task was at an end.  I've included a copy from the CICS TS 3.2 (unfortunately I don't have the VSE version available) of the STGRCVY parameter.

 

The storage areas checked before task end are areas that are acquired and freed during execution. Most of this type of storage is acquired by CICS for its use servicing a user request 

 

What you want can only be achieved by using CSFE, an SM trap or a 3rd party monitor.

 

Regards,

Gene 

 

 

 

STGRCVY STGRCVY={NO|YES} specifies whether CICS should try to recover from a storage violation. NO CICS does not try to repair any storage violation that it detects. YES CICS tries to repair any storage violation that it detects.In both cases, CICS continues unless you have specified in the dump table that CICS should terminate. In normal operation, CICS sets up four task-lifetime storage subpools for each task. Each element in the subpool starts and ends with a ’check zone’ that includes the subpool name. At each freemain, and at end-of-task, CICS checks the check zones and abends the task if either has been overwritten. Terminal input-output areas (TIOAs) have similar check zones, which are set up with identical values. At each freemain of a TIOA, CICS checks the check zones and abends the task if they are not identical. If you specify STGRCVY(YES), CICS resets the check zones correctly and the task continues running. If you specify STGRCVY(NO), CICS abends the task if it is still running. The storage is not reusable and is not returned to the DSA for the remainder of the CICS cycle. If an error is detected when the task ends, no abend is issued. Any sync point that has taken place could save data that is corrupted.

[indust...@winwholesale.com]

owner...@Lehigh.EDU wrote on 01/28/2009 05:43:17 PM:
> If I understand you  correctly, what you are interested
> in is that CICS cancel the task when the SV  occurs.

        No, that is not what I wanted.  I just don't want CICS to do any recovering and letting the task continue regardless.

> In your case (the one presented), setting STGRCVY yes or no, will
> still only discover the SV at FREEMAIN and not when it occurred.

        That is fine.

> In the case of no, the damaged area is
> not  recovered and the task is canceled.

        That is what I want.

[Eshu...@aol.com]

In a message dated 2009-01-28 18:56:54 SA Western Standard Time, indust...@winwholesale.com writes:

In the case of no, the damaged area is
> not  recovered and the task is canceled.

        That is what I want.

Hi Dave:

 

You have to be careful if the area is below the line. If the SV occurs a lot and/or the damaged areas are large, you could go SOS.  Some people recommend that the integrity of CICS could be affected as a result of the SV and therefore, the  CICS system should be brought down. 

 

Regards,

Gene

[indust...@winwholesale.com]

owner...@Lehigh.EDU wrote on 01/28/2009 06:44:51 PM:
> You have to be careful if the area is below the line. If the SV
> occurs a  lot and/or the damaged areas are large, you could go SOS. 
> Some people  recommend that the integrity of CICS could be affected
> as a result of the SV and  therefore, the  CICS system should be
> brought down. 

        OK, so are you saying that CICS has the ability to detect and recover *other* storage which is *not* associated with damaged storage detected and its task?  Because I was of the understanding that all of the damage detected by CICS will be taken care of just by terminating the associated task and freeing up all storage allocated to the task.

[Eshu...@aol.com]

Hi Dave:

 

No,CICS repairs the damaged storage. The difference is whether it does the repair or just leaves the storage in limbo.  It is easy to recover the damaged storage because the pointers are physically separate from the actual allocated storage and under the control of the SM Domain. The control block used to determine where the storage is located and its length is called a Storage Control Element (SCE).  Some times the overlay goes into allocated but unused storage (free).  The free areas location and length are controlled by a Storage Control Free (Element) (SCF).  For example,you ask for 800 bytes. If there is no storage available to fit the request, CICS will allocate a 4 K page from the (E) DSA.  It will use 816 bytes (add the 2 Storage Check Zones and rounds up to a double-word boundary).  The difference between 4096 and 816 is a free area assigned to the task but unused, available for the task to GETMAIN.  Note that overlaying an assigned free area does not cause a protection exception. The SCE will have the pointer and length to the used area and the SCF will point to the free area plus the length and the storage belongs to the task.

 

Someone also mentioned that you could get a protection exception if you went into unassigned storage. I guess the answer is "it depends".  If the affected unused storage is within the same (E) DSA extent, then you will not get a protection exception.  However,if you go beyond the (E) DSA extent, you may get a protection exception depending on whether the contiguous storage has been GETMAINed for another extent or not GETMAINed.  If the area following the affected extent has not been GETMAINed or has been GETMAINed with a different protection key (i.e., USER to CICS), then you could get a protection exception. 

 

The difference is that if you have recovery on and the SV occurred in this 4 K page by overlaying past the ending SCZ entering into an unused area but belonging to the task, CICS would clear the information related to the page (SCE and the SCF) and give it back to the SM to use. Otherwise, it would leave the page marked as used even though the task is gone.  Once the task is gone,the SCE/SCF control blocks that were used to account for the storage area are deleted, then CICS has no way of ever recovering the virtual storage without an extensive overhead, that,to the best of my knowledge, is not built into the product. You can think of this condition as an "orphan page" that cannot be used by anyone but occupies space in the (E) DSA.  (E) DSA page use is controlled by something called the Page Allocation Map (PAM) which is used to indicate whether the particular page is free and available for use (X'00') or assigned to someone (not X'00').  As this is a 1 byte indicator, you can have only 255 kinds of storage subpools (X'00' is unused). (I make this comment because newer releases of CICS TS have more than 255 subpools). 

 

Sorry to have drifted into the details but the net of what I was trying to say is that if you get a lot of these orphan pages because there are a lot of SVs or the areas that were affected were large, then you could create an artificial SOS condition by specifying STGRCVY as no. The danger is more below the line than above because of the limitations set by the 16 MB line and the size of the OS and OS related areas below the line.  

 

The question may be why you would want STGRCVY off? Most of the cases I've seen the parameter set to no usually have that CICS stop running when the SV occurs so that you can see what is there without CICS modifying too much of the control blocks. There was a big discussion about this issue last year or so in CICS-L regarding the use of STGRCVY in case you want to find out more of the reasons for using or not using STGRCVY.  I guess a lot depends on your SLAs and CICS up time targets at the risk of maybe having some type of integrity problem.

 

Regards,

Gene

[indust...@winwholesale.com]

owner...@Lehigh.EDU wrote on 01/28/2009 10:40:12 PM:
> The question may be why you would want STGRCVY off? Most of the
> cases I've  seen the parameter set to no usually have that CICS stop
> running when the SV  occurs so that you can see what is there
> without CICS modifying too much of the  control blocks. There was a

> big discussion about this issue last year or so in  CICS-L ...

        OK, I'll turn it back on -- there should just be some kind of option to recover storage but also terminate the task.  I don't want my transactions working with bogus data put there by some other task.  After all, CICS can fix the SAA/SCZ pointers/tags, but it can't fix the area between the pointers/tags.

[Horlick, Michael]

Greetings,

 

We went from VSE 2.6.1 to z/VSE 4.1.0 awhile back and I have noticed that it seems to act differently with regards to using the resources of the physical machine.

We run under z/VM 5.1.

 

We have 5 z/VSE virtual machines, all running CICS/TS and if some batch jobs are running within one machine then it can slow down the whole system significantly. That didn’t seem to me occurring in the past with VSE 2.6.1. There always seemed to be some “juice” left for other users.

 

I have the feeling that z/VSE can more effectively use the resources given to it and this creates fewer resources available for other virtual machines effectively causing slow response time for CMS users.

 

I wish I could “cut” a VSE machine into separate virtual CPUs with one virtual CPU running VTAM,TCPIP and CICSTS and another virtual CPU running batch. Then it would also be nice if z/VM would allow you to specify SHARE values for each virtual CPU within a VSE virtual machine.

 

I know I can play with the PRTY command with z/VSE but can anyone think of how to give all interactive users (CICS and CMS) better response time than some batch jobs running in a z/VSE virtual machine.

 

One idea I had was just to create a VSE machine just running a CICS/TS system and another just running batch but with the overhead in having 2 virtual machines running instead of one (with also having access to the same files) as well as operational issues doesn’t make it very appealing.

 

Any ideas?

 

Mike     

 

 

   

[Rich Smrcina]

You can have finer control over priority with the VSE SHARE command as well. Partition
priorities can be adjusted similarly to virtual machine priorities. Also, I thought
z/VSE Version 4 introduced a requirement for z/VM 5.2, but I can't find a statement to
that affect... :(

--
Rich Smrcina
VM Assist, Inc.
Phone: 414-491-6001
Ans Service: 360-715-2467
http://www.linkedin.com/in/richsmrcina

Catch the WAVV! http://www.wavv.org
WAVV 2009 - Orlando, FL - May 15-19, 2009

[Martin Truebner]

Rich,

> z/VSE Version 4 introduced a requirement for z/VM 5.2,

not realy- only if you have the desire to run CMT (datacollection for
SCRT).

[Horlick, Michael]

Sorry, I have 5.2 not 5.1

I've played with the SHARE but this I use for a group of batch
partitions. I always put POWER,VTAM,TCPIP,FAQS and CICSTS above the
other partitions

Mike

-----Original Message-----
From: owner...@Lehigh.EDU [mailto:owner...@Lehigh.EDU] On Behalf
Of Rich Smrcina
Sent: January 29, 2009 11:38 AM
To: VSE Discussion List

[Horlick, Michael]

Sorry meant 5.2. Slip of the fingers.

-----Original Message-----
From: owner...@Lehigh.EDU [mailto:owner...@Lehigh.EDU] On Behalf
Of Martin Truebner
Sent: January 29, 2009 11:45 AM
To: VSE Discussion List
Subject: Re: z/VSE performance change?

[Rich Smrcina]

Martin Truebner wrote:
> Rich,
>
>> z/VSE Version 4 introduced a requirement for z/VM 5.2,
>
> not realy- only if you have the desire to run CMT (datacollection for
> SCRT).
>

It was very clear in the announcement and if you bring it up under z/VM 5.1 you get this
little nastygram:

BG 0000 0J86I WARNING: VM RELEASE NOT SUPPORTED BY VSE 4.1 - Z/VM 5.2 OR LATER
REQUIRED

The message apparently wasn't changed for 4.2, the system is definitely z/VSE 4.2.
Also, you may get a little push back calling for support (maybe alot).

[Edward M Martin]

Hello Mike,

We use the z/VM (5.3) priority to control the high level resource usage.

(all z/VSE 4.1.2 systems)

PROD gets more that TEST/BETA/TECH/Install/ and some CMS users.

And then with in PROD the prty is set to allow more control of some
partitions.

PRTY G,R,FA,BG,F8,F7,F6,F5,C=I=H=F2,F4,L,F9,E,F3,FB,F1

Ed Martin
Aultman Health Foundation
330-588-4723
ext 40441

[Horlick, Michael]

Hi Ed,

What sort of z/VM priority do you use? Do you use the SET SHARE?

Regards,

Mike

[Edward M Martin]

Yes we use the SHARE RELATIVE only.

PROD is RELATIVE 7500 with no limit.

[Mark Pace]

Don't forget to add in the increased overhead of VSE.  Every new version of VSE has driven up the overhead a few percentage points.

--
Mark Pace
Mainline Information Systems
1700 Summit Lake Drive
Tallahassee, FL. 32317

[Horlick, Michael]

Yeah , I guess you’re right about that.

 

Thanks,

 

Mike

---

From: owner...@Lehigh.EDU [mailto:owner...@Lehigh.EDU] On Behalf Of Mark Pace

Sent: January 29, 2009 1:42 PM
To: VSE Discussion List

[Edward M Martin]

Hello Mike,

Did you change over to NOPDS for your VSE systems?

Ed Martin

Aultman Health Foundation

330-588-4723

ext 40441

From: owner...@Lehigh.EDU [mailto:owner-vs...@Lehigh.EDU] On Behalf Of Mark Pace
Sent: Thursday, January 29, 2009 1:42 PM
To: VSE Discussion List
Subject: Re: z/VSE performance change?

[Horlick, Michael]

Yup, a long time ago. We page about 1/sec

 

---

[Edward M Martin]

Hello Mike,

 

Yea, sound like you are doing well there.  The other thing that I learned on the VM page is to separate out

The SPOOL area from the PAGE area from the User disks.

 

We have a separate 3390 for SPOOLING and another for PAGING only.

 

It does seem to have helped our system, but I don’t have hard facts.

 

Ed Martin

Aultman Health Foundation

330-588-4723

ext 40441

From: owner-vs...@Lehigh.EDU [mailto:owner-vs...@Lehigh.EDU] On Behalf Of Horlick, Michael
Sent: Thursday, January 29, 2009 2:24 PM
To: VSE Discussion List
Subject: RE: z/VSE performance change?

 

Yup, a long time ago. We page about 1/sec

 

---

From: owner-vs...@Lehigh.EDU [mailto:owner-vs...@Lehigh.EDU] On Behalf Of Edward M Martin
Sent: January 29, 2009 1:46 PM
To: VSE Discussion List
Subject: RE: z/VSE performance change?

 

Hello Mike,

Did you change over to NOPDS for your VSE systems?

Ed Martin

Aultman Health Foundation

330-588-4723

ext 40441

[Eshu...@aol.com]

Hi Dave:

 

This is the main thrust of the CICS-L discussion. However, please remember that there may be storage violations occurring that are not detected by CICS, e.g,, altering data without affecting the SCZ/SAA structure.  This is a design problem and transaction isolation nor storage protection will fully resolve.

 

Regards,

Gene

[Horlick, Michael]

Yes, we have VM SPOOL and PAGE on different packs.

 

Thanks for your interest,

 

Mike

[Edward M Martin]

Hello Mike,

 

And (just to make sure), The spool and page should be separate from all other functions.

The way the spool and page CCW are constructed they are long running and tend to keep the track held for longer

That normal I/O would.

 

Ed Martin

Aultman Health Foundation

330-588-4723

ext 40441

From: owner...@Lehigh.EDU [mailto:owner...@Lehigh.EDU] On Behalf Of Horlick, Michael
Sent: Friday, January 30, 2009 7:39 AM
To: VSE Discussion List
Subject: RE: z/VSE performance change?

 

Yes, we have VM SPOOL and PAGE on different packs.

 

Thanks for your interest,

 

Mike

 

From: owner...@Lehigh.EDU [mailto:owner...@Lehigh.EDU] On Behalf Of Edward M Martin
Sent: January 29, 2009 3:31 PM
To: VSE Discussion List
Subject: RE: z/VSE performance change?

 

Hello Mike,

 

Yea, sound like you are doing well there.  The other thing that I learned on the VM page is to separate out

The SPOOL area from the PAGE area from the User disks.

 

We have a separate 3390 for SPOOLING and another for PAGING only.

 

It does seem to have helped our system, but I don’t have hard facts.

 

Ed Martin

Aultman Health Foundation

330-588-4723

ext 40441

---

From: owner-vs...@Lehigh.EDU [mailto:owner-vs...@Lehigh.EDU] On Behalf Of Horlick, Michael
Sent: Thursday, January 29, 2009 2:24 PM
To: VSE Discussion List
Subject: RE: z/VSE performance change?

 

Yup, a long time ago. We page about 1/sec

 

From: owner...@Lehigh.EDU [mailto:owner...@Lehigh.EDU] On Behalf Of Edward M Martin
Sent: January 29, 2009 1:46 PM
To: VSE Discussion List
Subject: RE: z/VSE performance change?

 

Hello Mike,

Did you change over to NOPDS for your VSE systems?

Ed Martin

Aultman Health Foundation

330-588-4723

ext 40441