Re: EZTrieve

[Itschak Mugzach]

Easytrieve inteprater uses program name eztpa00, so look for it in you FB
80 libraries. If you compiled your easytrieve programs, run a searchfor
(ISPF opt3.14) and find where it uses modules starting with et.

ITschak

On Sat, Jan 7, 2012 at 2:52 AM, gsg  wrote:

> Does anyone know of a way to locate all JCLs/Proc members that are using
> EZTrieve?
>
> Any help would be greatly appreciated.
>
> Thanks
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: EZTrieve

[Bryan Klimek]

Every execution of Easytrieve, whether it be EZTPA00 or a compiled program 
access the Easytrieve Options table. The options table is a created from the 
JOB06EOP install job. Simply scan your SMF data looking for all jobs that 
access this file.

Bryan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: ACF2/RACF User Appliation Logical Access

[Shmuel Metz (Seymour J.)]

In
,
on 01/06/2012
   at 11:18 AM, Wayne Driscoll  said:

>Based on my past experiences with ACF2, I believe that ACF2 acts as
>if  each rule line contains, in RACF terms, as asterisk after the
>last character.

That doesn't explain what the OP meant by "iterating through a list of
applications", which makes no sense.
 
-- 
 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: S72A-10 Abend

[Binyamin Dissen]

On Fri, 6 Jan 2012 13:04:59 -0600 Donald Likens 
wrote:

:>I am getting the following Abend:

:>IEA995I SYMPTOM DUMP OUTPUT  172   
:>SYSTEM COMPLETION CODE=72A  REASON CODE=0010   
:> TIME=10.15.04  SEQ=01338  CPU=  ASID=0042 

:>The book states:

:>Explanation: During processing for an ATTACH
:>macro, the system encountered an error.
:>Register 15 contains a hexadecimal reason code that
:>explains the error:

:>10 A caller using the ATTACHX macro
:>encountered nonzero access list entry tokens
:>(ALETs). The ALETs should have been set to
:>zero, but they were not.

:>I do not understand what the book is taking about. My attachx follows:

:>ATTACHX EPLOC=MEASTSMN,ETXR=TSMNDOWN,PARAM=(TSMNWKSA) 

:>I do not see tokens involved with ATTACHX.

:>Can someone please explain what IBM is talking about?

My guess is that you are in AR mode and the AR15 is non-zero.

Always issue SYSSTATE ASCENV=AR when in AR mode so that system macros generate
correct code.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Error apply ZAP

[Ed Gould]

Robert:

I used to have a vendor that would send out zaps almost weekly and  
IDR space was at a premium on the vendors modules. We dropped the  
vendor so I don't know how they did resolve the constant zap issue. I  
can't remember of ever having the issue with IBM as they send out  
module replacement (thanks!)
I feel its important to maintain the IDR to find out what level the  
module is at. With the vendor I spoke of it was somewhat of an issue  
at times.
That is why I am a strong supporter of module replacement and zaps  
are for emergency fixes only.


Ed

On Jan 6, 2012, at 11:54 PM, Robert A. Rosenberg wrote:

At 14:29 -0600 on 01/06/2012, Staller, Allan wrote about Re: Error  
apply ZAP:


First the IDR (forget what the acronym stands for) is an optional  
list
of zaps applied to this module (load module?). Due to the  
structure of

the directory, IIRC, you are limited to 19 IDR entries
per module (load module?). The IDR data is set by an AMASPZAP control
statement. IDENTIFY.

The message AMA120I message below may be safely ignored. It is  
indicated

that there is no space left to record additional IDR information. The
only impact of this is that it will make it difficult to determine  
which

zaps have already been applied.


If you relink as the AMA120I suggests/instructs the Binder adds  
another (empty) IDR record so you can use the IDENTIFY statement  
(think this is automatic although it may be triggered by supplying  
a Binder command to add more IDR Space). As you note, this allows  
you to track what ZAPs have been installed. If I remember IDR is ID  
Record. There are IDR records for each CSECT in the Load Module  
(they come from the Assembler) so you can see what the assembly  
date of the CSECT is (there is only one for the last linkedit).


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: EZTrieve

[Ed Gould]

Lizette:

That is indeed the best way to go.
One caveat is that it will not catch TSO (users).
Short of running GTF (forever) you will have a hard time catching  
every use.
I think the only way is to talk to all the users and see if they know  
of any tso users out there that might be using it.
If the reason is "discontinuance" and how dispersed you user  
community is allow probably 6 months (each installation is different).
If the reason is something else and depending how politicized your  
environment is you may have to write email(s) and wait and see.


Ed

On Jan 6, 2012, at 9:10 PM, Lizette Koehler wrote:



Does anyone know of a way to locate all JCLs/Proc members that are  
using

EZTrieve?


Any help would be greatly appreciated.

Thanks



If you have  SAS and MXG or MICS then you can use that to begin the
analysis.

Or you can download the CBTTAPE.ORG file containing DAF.

If you have JCLPLUS from SEA Software, then you might also have the  
JCLPUS

XREF process

Or if you have Endeavor or Changeman, you might be able to see what  
is in

their processes.

But as it has been pointed out, it will most but possibly not all.

Let me know if you need more details.

What you may not be able to see are end users of Easytrieve.   
Production use

of Easytrieve might be easier.

Lizette

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Internal text

[Clark Morris]

On 6 Jan 2012 10:56:09 -0800, in bit.listserv.ibm-main you wrote:

>I have been tasked with an update to JES2 exit 6. One of the functions I
>need to implement is to forbid all use of a certain JCL parameter.
>
See the Philips Lighting mods - File 175 on the CBT tape for an exit 6
that does a fair amount of parsing of the JOB and DD cards to among
other things set the JOBCLASS in the JCT.  While the exit is over 20
years old, it still should be useful as one way to handle parsing.

Clark Morris
> 
>
>Initial testing indicates the INTTXT presents the parameter in the order
>specified in the JCL. Since the "forbidden" parameter may be in the
>"middle" of the string, 
>
>I will need to manipulate the INTTXT buffer to eliminate the "forbidden"
>parameter" by shifting the characters to the right of the forbidden
>parameter, to the left.
>
> 
>
>What would be preferable is to "nullify" the parameter in the internal
>text string without shifting the string. (i.e. create a noop) without
>the character shift.
>
> 
>
>Does anyone know if this is possible? If so, what is the INTTXT key? I
>have been all over the IEFVKEYS macro, and can't seem to find one.
>
> 
>
>TIA,
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Error apply ZAP

[Chris Hoelscher]

I seem to remember (20+ years ago?) that re-linkediting the load module would 
preserve the existing IDR entries and allow for another 19 (but I could be 
mistaken on this)

Chris hoelscher
Database Administrator |Technical Services
Humana
123 East Main Street |Louisville, KY 40202
T 502.476.2538
choelsc...@humana.com
Humana.com
Keeping CAS and Metavance safe for all HUMANAty


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Ed Gould
Sent: Saturday, January 07, 2012 2:32 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: [IBM-MAIN] Error apply ZAP

Robert:

I used to have a vendor that would send out zaps almost weekly and IDR space 
was at a premium on the vendors modules. We dropped the vendor so I don't know 
how they did resolve the constant zap issue. I can't remember of ever having 
the issue with IBM as they send out module replacement (thanks!) I feel its 
important to maintain the IDR to find out what level the module is at. With the 
vendor I spoke of it was somewhat of an issue at times.
That is why I am a strong supporter of module replacement and zaps are for 
emergency fixes only.

Ed




The information transmitted is intended only for the person or entity to which 
it is addressed and may contain CONFIDENTIAL material.  If you receive this 
material/information in error, please contact the sender and delete or destroy 
the material/information.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: USS Education (Was: Calling all experts on SMFPRMxx SUBSYS)

[Ford Prefect]

Disturbing.

On Fri, Jan 6, 2012 at 9:56 AM, Chris Mason  wrote:

> Barbara
>
> > You know how ignorant I am about USS, don't you?
>
> Well, no, I didn't at all but, since you mention it, perhaps I can help,
> assuming you would like to be educated in USS.
>
> These days you most probably use USS as described in Chapter 11,
> "Accessing remote hosts using Telnet" of the z/OS Communications Server IP
> Configuration Guide, most specifically the section "Using the Telnet
> solicitor or USS logon screen":
>
>
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b3b0/2.2.1.4.15
>
> If you want to know about the original USS created in the second half of
> the 1970s decade and still very much in use and which indeed your
> installation may use in conjunction with OSA features configured as an
> "Integrated Console Controller" (ICC) (CHPID OSC), the description is in
> the following sources:
>
> - Chapter 12, "Establishing and controlling SNA sessions" in the z/OS
> Communications Server SNA Network Implementation Guide, most specifically
> in section "Logon and logoff requests from dependent logical units"
>
>  http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B5B0/12.8
>
> - Chapter 5, "User-defined tables and data filter" in the z/OS
> Communications Server SNA Resource Definition Reference section
> "Unformatted system services tables":
>
>  http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b6c0/5.11
>
> If you detect any conflicts between the "IP" and "SNA" sources, you should
> use the "SNA" (VTAM) version as authoritative.
>
> If you ever need help with the topic, please don't hesitate to submit a
> post with a title such as "Help needed with USS" or something clear and
> unambiguous like that.
>
> -
>
> Thanks to your comment, I noted that there had been changes in the
> description of USS as used by the SNA-oriented TELNET server in V1R13.
> However the changes were mostly extremely trivial - "panel" to "screen", I
> ask you! - except for the addition of "password phrase" support - when you
> happen to use the "Telnet solicitor" rather than USS!
>
> -
>
> Incidentally, while scanning for the changes, I noticed some mendacity!
> It's actually not really the fault of the Communications Server developers
> that the SNA-oriented TELNET server can mimic the action of VTAM only for
> the *LOGON* command. Rather it is a deficiency of RFC 2355. In order
> completely to support the following claim:
>
> 
>
> For ease of migration, Telnet simulates SNA USS processing very closely.
>
> 
>
> full implementation of the handling of the *LOGOFF* command would be
> required. Unfortunately, while having done a good job for the most part the
> author of RFC 2355 fell down very badly in the area of the USS LOGOFF
> command - more's the pity for end users and their help desk support.
>
> -
>
> Chris Mason
>
> On Thu, 5 Jan 2012 23:39:12 -0600, Barbara Nitz  wrote:
>
> >> ...
>
> >You know how ignorant I am about USS, don't you?
>
> > ...
>
> >Barbara
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: DFHSM QUESTION : Allocation/migration Threshold

[willie bunter]

Thanks to all for your helpful comments.  I guess nothing more can be done.  
Thanks to you all.

 


 From: Hervey Martinez 
To: IBM-MAIN@bama.ua.edu 
Sent: Thursday, January 5, 2012 1:45:57 PM
Subject: Re: DFHSM QUESTION : Allocation/migration Threshold
 
Well, if there is no migration then adjusting the thresholds will not get you 
much. The only space that will be released will be from those files that are 
over-allocated or expired. In this case, then you have to look at the files to 
make sure that you have no un-cataloged files, these will take up space but 
will never go away. Also, if you have GDGs with an expiration date, these may 
stay around even though they are not in the base and this is governed by the 
"rolled off gds action" attribute in the management class; In other words, you 
have to get to know the data much better to determine if there is space that 
should be released. Another way to release space on a file is by the use of 
"partial release" attribute on the management class. Also, files that are 
"Fixed" instead of fixed-blocked will waste quite a bit of space.


Hervey

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
willie bunter
Sent: Thursday, January 05, 2012 1:06 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: DFHSM QUESTION : Allocation/migration Threshold

I should have mentioned that there is no ML0/ML1 migration in this pool as 
well.  PSM is only being run.  I understand that this is not a good thing but 
the client insists upon having NO migration of the dsns from this pool this 
woould explain why the Threshold is low.  Would adjusting the Threshold help 
eventhough there is no migration?



From: Hervey Martinez 
To: IBM-MAIN@bama.ua.edu 
Sent: Thursday, January 5, 2012 9:46:34 AM
Subject: Re: DFHSM QUESTION : Allocation/migration Threshold

If there is no ML2 migration then everything is migrating to the ML1 pool and 
the ML1 pool may be full; if so, then it needs to be expanded. Normally, ML2 
migration is governed by the management class; so, how do you keep this pool 
from ML2 migration? Also, Interval migration runs every hour on the hour 
provided that PSM & SSM are not running and it uses the mid-point of your hi-lo 
threshold; thus, your pool will start migrating around 36% capacity during 
interval migration.

Thanks,

Hervey
813.878.6097

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Staller, Allan
Sent: Thursday, January 05, 2012 9:15 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: DFHSM QUESTION : Allocation/migration Threshold

Migration will begin when the SG occupancy exceeds the high threshold and 
continue until less than the SG low threshold, or no additional datasets are 
eligible for migration.
This is subject to additional constraints specified in the MGMTCLAS for 
migration eligibility.

IMO your low thresholds are "too low" causing "thrashing" (needless 
migration/recall of dataset due to interval migration), which will compound the 
. Your high thresholds seem pretty good. 

As presented, every migration "empties" the pool, and dataset reference fills 
it back up.

There is an art to setting thresholds. A thorough analysis, taking into 
consideration the MGMTCLAS(s), STORGRP(s), thresholds, relative data set sizes, 
and reference patterns needs to occur.

HTH,



I have a problem with a SMS managed storage pool which is increasing quite 
rapidly.  In this pool there is no ML2 migration .  We have Auto Migrate & Auto 
Backup turned on and INTERVAL MIGRATION.  
 
Below is the THRESHOLD which we are using for this pool.
 
Allocation/migration Threshold : High . . 75  (1-99)  Low  . . 3   (0-99)
Alloc/Migr Threshold Track-Managed:  High . . 85  (1-99)  Low  . . 1   (0-99)

If I lowered the THRESHOLD would that help and free up some space?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: EZTrieve

[Martin Packer]

Ed (and others) this has been a useful discussion for me so thanks! My 
purpose is to recognise such steps when I see them in the SMF for a 
particular job, The program name and data set are very useful footprints 
in the sand (and the lack of applicability to TSO doesn't bother me).

Cheers, Martin

Martin Packer,
Mainframe Performance Consultant, zChampion
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

IBM Mainframe Discussion List  wrote on 07/01/2012 
19:25:35:

> From:
> 
> Ed Gould 
> 
> To:
> 
> IBM-MAIN@bama.ua.edu, 
> 
> Date:
> 
> 07/01/2012 19:59
> 
> Subject:
> 
> Re: EZTrieve
> 
> Sent by:
> 
> IBM Mainframe Discussion List 
> 
> Lizette:
> 
> That is indeed the best way to go.
> One caveat is that it will not catch TSO (users).
> Short of running GTF (forever) you will have a hard time catching 
> every use.
> I think the only way is to talk to all the users and see if they know 
> of any tso users out there that might be using it.
> If the reason is "discontinuance" and how dispersed you user 
> community is allow probably 6 months (each installation is different).
> If the reason is something else and depending how politicized your 
> environment is you may have to write email(s) and wait and see.
> 
> Ed
> 
> On Jan 6, 2012, at 9:10 PM, Lizette Koehler wrote:
> 
> >>
> >> Does anyone know of a way to locate all JCLs/Proc members that are 
> >> using
> > EZTrieve?
> >>
> >> Any help would be greatly appreciated.
> >>
> >> Thanks
> >>
> >
> > If you have  SAS and MXG or MICS then you can use that to begin the
> > analysis.
> >
> > Or you can download the CBTTAPE.ORG file containing DAF.
> >
> > If you have JCLPLUS from SEA Software, then you might also have the 
> > JCLPUS
> > XREF process
> >
> > Or if you have Endeavor or Changeman, you might be able to see what 
> > is in
> > their processes.
> >
> > But as it has been pointed out, it will most but possibly not all.
> >
> > Let me know if you need more details.
> >
> > What you may not be able to see are end users of Easytrieve. 
> > Production use
> > of Easytrieve might be easier.
> >
> > Lizette
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Error apply ZAP

[Gerhard Postpischil]

On 1/7/2012 2:31 PM, Ed Gould wrote:

constant zap issue. I can't remember of ever having the issue
with IBM as they send out module replacement (thanks!)
I feel its important to maintain the IDR to find out what level
the module is at. With the vendor I spoke of it was somewhat of
an issue at times.
That is why I am a strong supporter of module replacement and
zaps are for emergency fixes only.


I've had the issue with IBM modules a long, long time ago. 
Assuming ZAPs are sequential, I prefer putting an identifier, 
APAR or whatever, into the eyeball text at the beginning of the 
module. That way I can see in a dump how it's been updated, 
rather than having to run a report.


Module replacements take more effort and disk space, so ZAPs are 
closer to being green 


Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Internal text

[Shmuel Metz (Seymour J.)]

In <45e5f2f45d7878458ee5ca679697335502e25...@usdaexch01.kbm1.loc>, on
01/06/2012
   at 12:53 PM, "Staller, Allan"  said:

>I have been tasked with an update to JES2 exit 6. One of the
>functions I need to implement is to forbid all use of a certain JCL
>parameter.

What do you mean by "forbid"? The word is not synonymous with
"ignore".

>What would be preferable is to "nullify" the parameter in the
>internal text string without shifting the string. (i.e. create a
>noop) without the character shift.

Why? Assuming that you really aren't supposed to fail the jobs using
the parameters, adjusting the internal text buffer to remove the key
is what you are expected to do.

-- 
 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Error apply ZAP

[Shmuel Metz (Seymour J.)]

In , on
01/06/2012
   at 08:00 PM, Helio Jose Da Silva  said:

>How can I resolve this error?

 !. Relink

 2. Contact the vendor

There are two separate issues. The AMA120I message means that you
won't have an audit trail unless you relink. The AMA104I message means
that either the zap is inappropriate or you already ran it.
 
-- 
 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Error apply ZAP

[Paul Gilmartin]

On Fri, 6 Jan 2012 14:29:12 -0600, Staller, Allan wrote:
>
>The real problem is the AMA104I message - VERIFY REJECT. The most likely
>cause is that this zap has already been applied.
>Another possibility that a pre-requisite zap is missing.
>
>The fastest way to determine this is to take a copy SYSIN  and delete
>the VER statements. Change the REP statements to VER and run the JCL.
>If this zap has already been applied, you should get a return code of
>zero.
> 
It's a major design shortcoming that one can't REDO a ZAP.  It would
be so easy -- if PARM=REDO and the content of the module matches
the REP, assume it's OK.  And SMP/E should supply the REDO parm
to AMASPZAP for APPLY REDO.

(There should also be a PARM=UNDO.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: ACF2/RACF User Appliation Logical Access

[Shmuel Metz (Seymour J.)]

In
<04b3da7b71b3ab408ca62ba6046bcf8f23d673a...@gvw0676exc.americas.hpqcorp.net>,
on 01/06/2012
   at 07:34 PM, "Henke, George"  said:

>I suspect this may be generating a separate SAF call for each
>application for each user and there are 1000's of users, whereas ACF2
>may be *wildcarding* it.

Whether ACF2 is wildcarding it has nothing to do with the number of
calls from the application. This looks like an issue with your session
manager, so I'd start by looking at the security code in it.
 
-- 
 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Error apply ZAP

[Rick Fochtman]

---
I seem to remember (20+ years ago?) that re-linkediting the load module 
would preserve the existing IDR entries and allow for another 19 (but I 
could be mistaken on this)


You are correct, but that won't fix the verify reject that is the real 
problem.


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Error apply ZAP

[Shmuel Metz (Seymour J.)]

In
<4bbf0d2ae8a42b43b88ff0033094ed124c34e...@simmbxwpg02s02.rsc.humad.com>,
on 01/07/2012
   at 08:44 PM, Chris Hoelscher  said:

>I seem to remember (20+ years ago?) that re-linkediting the load
>module would preserve the existing IDR entries and allow for another
>19 (but I could be mistaken on this)

You are not mistaken in general, although I don't recall whether 10 is
the correct number.
 
-- 
 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Error apply ZAP

[Robert A. Rosenberg]

At 13:31 -0600 on 01/07/2012, Ed Gould wrote about Re: Error apply ZAP:


Robert:

I used to have a vendor that would send out zaps almost weekly and 
IDR space was at a premium on the vendors modules. We dropped the 
vendor so I don't know how they did resolve the constant zap issue. 
I can't remember of ever having the issue with IBM as they send out 
module replacement (thanks!)
I feel its important to maintain the IDR to find out what level the 
module is at. With the vendor I spoke of it was somewhat of an issue 
at times.
That is why I am a strong supporter of module replacement and zaps 
are for emergency fixes only.


As I noted, and someone here confirmed, doing a relink adds extra IDR 
room (if the current IDR Record is full). IOW: The AMA120I message by 
suggesting the relink would add another IDR record with room for 
another 19 IDENTIFY commands. The IDR record is on a per-loadmodule 
basis and thus is shared by all the CSECTs in the Load Module. In the 
case of your vendor, so long as the ZAPs came with IDENTIFY commands 
and you did not supply the PARM override, every 19 ZAPs (~5 months) a 
relink would be needed to add another IDR record to be used.



Ed

On Jan 6, 2012, at 11:54 PM, Robert A. Rosenberg wrote:


At 14:29 -0600 on 01/06/2012, Staller, Allan wrote about Re: Error apply ZAP:


First the IDR (forget what the acronym stands for) is an optional list
of zaps applied to this module (load module?). Due to the structure of
the directory, IIRC, you are limited to 19 IDR entries
per module (load module?). The IDR data is set by an AMASPZAP control
statement. IDENTIFY.

The message AMA120I message below may be safely ignored. It is indicated
that there is no space left to record additional IDR information. The
only impact of this is that it will make it difficult to determine which
zaps have already been applied.


If you relink as the AMA120I suggests/instructs the Binder adds 
another (empty) IDR record so you can use the IDENTIFY statement 
(think this is automatic although it may be triggered by supplying 
a Binder command to add more IDR Space). As you note, this allows 
you to track what ZAPs have been installed. If I remember IDR is ID 
Record. There are IDR records for each CSECT in the Load Module 
(they come from the Assembler) so you can see what the assembly 
date of the CSECT is (there is only one for the last linkedit).


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Debugging CICS Global User Exits

[Micheal Butz]

Hi,

 

 

 Would anyone know the best method to debug CICS Global User Exits For MVS I
usually used XDC 

 

 

 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Debugging CICS Global User Exits

[Edward Jaffe]

On 1/7/2012 8:12 PM, Micheal Butz wrote:

Hi,

  Would anyone know the best method to debug CICS Global User Exits For MVS I
usually used XDC


z/XDC?

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN