Re: AW: Re: Experience with ADRDSSU patch X'54' to enable usage of Catalog Search INterface (CSI)

[Doug]

Thank you for asking the question!
It's time for the IBM folks to chime in on this one. 
We are 1.12 going to 2.1 or 2.2.
What is the current default and which zap does what?

Best Regards,
Doug

.

> On Dec 30, 201, at 16:36, Peter Hunkeler  wrote:
> 

> But a search in IBMLINK for the APAR cited yields a number of hits, one of 
> which is info APAR II14616 .

I was pointed to this and other APARs by a colleague after I posted here. The 
net as I understand now is:
o The new, optional function was introduced with an APAR in z/OS V1.9. The 
default was left to be to old behaviour.
o IBM decided to change the default to the new function (CSI) with z/OS V1.11
o Later, problems were reported with the new function. IBM decided to change 
the default back to the old behaviour via APAR on z/OS V1.11 and V1.12. z/OS 
V2.1 was delivered with the old behaviour being the default.

Very confusing if you read the manual at different z/OS levels. The value X'00' 
for the patch byte sometimes means old behaviour, sometimes new behaviour. Not 
nice.


No matter what the default is, I'd like to hear what anyone having used the new 
function (CSI) can tell.



--Peter Hunkeler




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

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

Re: Rexx and member statistics question

[Paul Gilmartin]

On Wed, 30 Dec 2015 22:12:37 -0600, Dale R. Smith wrote:
>
>According to the TSO REXX Reference, if "*" is used with DISKW and a STEM, 
>then stem.0 is ignored and it writes stem. records until it finds either a 
>null record or an uninitialized stem value.  For example, it you read a member 
>of a PDS into STEM mem. and the member contained 100 records, (mem.0 = 100), 
>then you wrote the stem to another member or file with EXECIO * DISKW and 
>(STEM MEM., it would write 100 records to the file, (mem.101 is not set).  If 
>you now read a PDS member with 90 records into the same stem name, (mem.0 = 
>90), and you wrote it out with EXECIO * DISKW and (STEM MEM., then it would 
>write the 90 records from the current member and the last 10 records from the 
>previous member!  Not good!
> 
All this provided that the input file contains no null record in which case it
would stop even sooner, at that null record.  Such a null record is what
caused the OP's problem.

>It would be best to use "EXECIO" mem.0 "DISKW" instead of "*" or to "Drop 
>mem." after the write and before the next read.  If the REXX program is 
>processing a lot of members, it may be a good idea to do both, because 
>dropping the stem will free up storage.
>
Dropping does not eliminate the hazard of the null record.  Do both.

-- gil

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

Re: Rexx and member statistics question

[Itschak Mugzach]

You might have blanks lines in input. Stem . It stops the writing of the stem 
to dataset. Try changing null lines to blanks.

ITschak

נשלח מה-iPad שלי

‫ב-31 בדצמ׳ 2015, בשעה 00:25, ‏‏Ze'ev Atlas 
‏<004b34e7c98a-dmarc-requ...@listserv.ua.edu> כתב/ה:‬

> Hi AllI have a Rexx program and here is the relevant snippet:
> THEMEMBER = THEPDS || "(" || MEMBER || ")"   /*say themember */   
> "alloc shr file(input) dataset(" THEMEMBER ")"   "execio 
> * diskr input (stem input. finis)"   IF RC \= 0 THEN  
>call DIE 'READ MEMBER failed' RC  say member 
> input.0 "LINES READ"  "free file(input)"  
>  "EXECIO" input.0 "DISKW XXOUT (STEM INPUT."  IF RC \= 0 THEN 
> call DIE 'WRITE MEMBER failed' RC 
> Originally, I had "EXECIO * DISKW XXOUT (STEM INPUT."  
> but that would work only for members that had statistics (i.e. have been 
> updated).  When I changed the '*' to input.0 it works fine.  Is that a normal 
> behavior?  (I ran on z/OS 2.2! Ze'ev Atlas
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Rexx and member statistics question

[Dale R. Smith]

On Wed, 30 Dec 2015 22:25:49 +, Ze'ev Atlas  wrote:

>Hi AllI have a Rexx program and here is the relevant snippet:
>THEMEMBER = THEPDS || "(" || MEMBER || ")"       /*say themember */            
>                   "alloc shr file(input) dataset(" THEMEMBER ")"   "execio * 
>diskr input (stem input. finis)"       IF RC \= 0 THEN                         
>            call DIE 'READ MEMBER failed' RC              say member input.0 
>"LINES READ"                  "free file(input)"                               
>"EXECIO" input.0 "DISKW XXOUT (STEM INPUT."      IF RC \= 0 THEN               
>                      call DIE 'WRITE MEMBER failed' RC             
>Originally, I had "EXECIO * DISKW XXOUT (STEM INPUT."  
>but that would work only for members that had statistics (i.e. have been 
>updated).  When I changed the '*' to input.0 it works fine.  Is that a normal 
>behavior?  (I ran on z/OS 2.2! Ze'ev Atlas

According to the TSO REXX Reference, if "*" is used with DISKW and a STEM, then 
stem.0 is ignored and it writes stem. records until it finds either a null 
record or an uninitialized stem value.  For example, it you read a member of a 
PDS into STEM mem. and the member contained 100 records, (mem.0 = 100), then 
you wrote the stem to another member or file with EXECIO * DISKW and (STEM 
MEM., it would write 100 records to the file, (mem.101 is not set).  If you now 
read a PDS member with 90 records into the same stem name, (mem.0 = 90), and 
you wrote it out with EXECIO * DISKW and (STEM MEM., then it would write the 90 
records from the current member and the last 10 records from the previous 
member!  Not good!

It would be best to use "EXECIO" mem.0 "DISKW" instead of "*" or to "Drop mem." 
after the write and before the next read.  If the REXX program is processing a 
lot of members, it may be a good idea to do both, because dropping the stem 
will free up storage.

-- 
Dale R. Smith

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

Re: Experience with ADRDSSU patch X'54' to enable usage of Catalog Search INterface (CSI)

[Bruce Hewson]

Hello,

I first came across the CATALOG ENQUEUE problem with ADRDSSU DUMP with GENERIC 
INCLUDE MASK in 2001.

In general the use of the CSI catalog search interface does provide a shorter 
catalog enqueue elapsed time.

The bypass solution we came up with was to provide a 300 line REXX exec to 
build an INCLUDE/EXCLUDE FILTER LIST DATASET based on the DUMP INCLUDE/EXCLUDE 
mask specifications in one step, and the run the ADRDSSU DUMP in the next step 
specifying the FILTERDD() parameter.
As the generated FILTERDD dataset contains explicit dataset names.

The BILDFILT exec is still used in some cases, but the ADRDSSU use of the 
Catalog Search Interface has eliminated most noticeable catalog enqueue hangs.

Regards
Bruce

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

Re: Experience with ADRDSSU patch X'54' to enable usage of Catalog Search INterface (CSI)

[Marc Manuel]

In the APAR, I understand that since z/OS 1.11, the default is that ADRDSSU
will use CSI...
You can patch if you want to go back to Generic Catalog Locate



2015-12-30 13:59 GMT+01:00 Peter Hunkeler :

> I'm chasing a problem where some ADRDSSU dump jobs are holding the catalog
> enqueue SYSIGGV2 for an unexcted long time. The jobs specify a couple of
> generic dsn specifications in the INCLUDE clause.
>
>
> I found APAR OA25644 from 2009 which introduces the choice to tell ADRDSSU
> to use the Catalog Search Interface (CSI) instead of Generic Catalog
> Locates to search for data set matching the INCLUDE mask. The new function
> is enabled via PATCH area, offset X'54'.
>
>
> Has anyone enabled the CSI interface by patching ADRDSSU? Any expecience
> you're willing to share?
>
>
>
>
> --
> Peter Hunkeler
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: IXGLOGR on RSM usage

[Nathan Astle]

Hi Andrew

Thank you for the pointer which helped me in tuning up the SMF logstream.

So when it comes to other logstream structures for DB2,CICS. Is there a way
to limit their RSM usage as well ?

Nathan


On Wednesday 23 December 2015, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> Andrew Metcalfe wrote:
>
> >Do you have SMF in Logstream mode?
>
> The OP said he has SMF in Logstream in thread 'Re: S00C Slip trap for any
> Stc'.
>
> He wrote: "Our SMF logstream has been defined in IXGLOGR with dasdonly. "
>
>
> >If so how many logstreams are defined? Each logstream has its own
> dataspace/buffers. There are some parameters which govern Logstream/SMF
> real storage requirements that you may need to tune.
>
> Good questions. Thanks for asking.
>
> Groete / Greetings
> Elardus Engelbrecht
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu  with the message:
> INFO IBM-MAIN
>

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

Re: Experience with ADRDSSU patch X'54' to enable usage of Catalog Search INterface (CSI)

[Skip Robinson]

I'm not a storage guy and cannot comment on the actual effect of using or not 
using CSI. But a search in IBMLINK for the APAR cited yields a number of hits, 
one of which is info APAR II14616 . I have perused this doc and confess to not 
understanding what is being said about what will or will not happen when 
setting or not setting patch byte x'54' to x'00' or x'11' or x'FF'. Maybe I 
should have focused more on literacy in grade school. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net
jo.skip.robin...@gmail.com

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Marc Manuel
> Sent: Wednesday, December 30, 2015 10:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Experience with ADRDSSU patch X'54' to enable usage of Catalog
> Search INterface (CSI)
> 
> In the APAR, I understand that since z/OS 1.11, the default is that ADRDSSU 
> will
> use CSI...
> You can patch if you want to go back to Generic Catalog Locate
> 
> 
> 
> 2015-12-30 13:59 GMT+01:00 Peter Hunkeler :
> 
> > I'm chasing a problem where some ADRDSSU dump jobs are holding the
> > catalog enqueue SYSIGGV2 for an unexcted long time. The jobs specify a
> > couple of generic dsn specifications in the INCLUDE clause.
> >
> >
> > I found APAR OA25644 from 2009 which introduces the choice to tell
> > ADRDSSU to use the Catalog Search Interface (CSI) instead of Generic
> > Catalog Locates to search for data set matching the INCLUDE mask. The
> > new function is enabled via PATCH area, offset X'54'.
> >
> >
> > Has anyone enabled the CSI interface by patching ADRDSSU? Any
> > expecience you're willing to share?
> >
> >
> >
> >
> > --
> > Peter Hunkeler

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

Re: Is there a source for detailed, instruction-level performance info?

[Tony Harminc]

On 30 December 2015 at 18:42, Charles Mills  wrote:
>On 30 December 2015 at 18:08, Jerry Callen  wrote:
>> How about it, IBM? Surely there must be someone Poughkeepsie who wants to 
>> visit San Antonio in
>> March? :-)

> Or possibly in Toronto!

I'll have you know we were all convinced Toronto wasn't going to have
a winter this year! It was golfing weather until two days ago and ski
places a bit north of here had given up and re-opened their summer
hiking and golf programs. Well, ahem... A green Christmas and a
frozen-clods-of-ice New Year. I guess San Antonio does sound
appealing.

Tony H.

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

Re: Is there a source for detailed, instruction-level performance info?

[Tony Harminc]

On 30 December 2015 at 17:10, Charles Mills  wrote:
> I would assume there is some sort of a compiler/hardware architecture
> liaison group within IBM. I would bet that if someone from that group were
> to put together a SHARE presentation called "Write Machine Code Like a
> Compiler -- How to Write the Fastest Code Possible for the z13 (z14,
> whatever)" that it would be a big hit.

I'm sure it would be. I've wondered over the years just how the
compiler and architecture people interact, and what influences what.
Clearly there's been a change in that many (most?) new hardware
features seem to be geared quite obviously to language features, which
surely wasn't the case in e.g. 1964.

Tony H.

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

Re: questions about converting CA-MIM to IBM GRS RNL

[Lizette Koehler]

Usually when you convert from one vendor product (CA MIM) to another vendor
Product (IBM GRS) the vendor - IBM - should be able to assist you with the
conversion.  

Both products are stable, so the conversion from the CA MIM to a GRS RNL
definition in SYS1.PARMLIB should be fairly simple.  If you contact your IBM
Sales Rep that person should be able to assist you with your questions.  Or you
can hire a consulting company that does this type of conversion.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mowry, Norma E CIV DISA (US)
> Sent: Wednesday, December 30, 2015 2:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: questions about converting CA-MIM to IBM GRS RNL
> 
> We are in the process of planning to convert our current CA-MIM to IBM GRS RNS
> with GRS running STAR mode, tape is not an issue.  I'm looking for
> documentation that will help with converting CA-MIM to GRSRNLs.  I did search
> google and found some things that were old, was hoping to find something more
> recent.
> 
> Thanks
> 
> Norma Mowry

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

Re: Rexx and member statistics question

[Charles Mills]

Let's see if I have this right.

You EXECIO DISKR a PDS member into stem INPUT.

You then attempt to write it out using EXECIO DISKW * from stem INPUT. The 
write fails unless the member has ISPF statistics.

However, EXECIO DISKW INPUT.0 succeeds.

Do I have that right? If so, no, that sounds wrong to me.

What is the exact error? Any messages in the message log?

Have you checked
- did the read really work? Do the member's records appear to be in INPUT.1, 
INPUT.2, etc.?
- what is in INPUT.0? Is it the correct line count?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ze'ev Atlas
Sent: Wednesday, December 30, 2015 2:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Rexx and member statistics question

Hi AllI have a Rexx program and here is the relevant snippet:
THEMEMBER = THEPDS || "(" || MEMBER || ")"   /*say themember */ 
  "alloc shr file(input) dataset(" THEMEMBER ")"   "execio * 
diskr input (stem input. finis)"   IF RC \= 0 THEN  
   call DIE 'READ MEMBER failed' RC  say member input.0 
"LINES READ"  "free file(input)"   
"EXECIO" input.0 "DISKW XXOUT (STEM INPUT."  IF RC \= 0 THEN
 call DIE 'WRITE MEMBER failed' RC 
Originally, I had "EXECIO * DISKW XXOUT (STEM INPUT."  
but that would work only for members that had statistics (i.e. have been 
updated).  When I changed the '*' to input.0 it works fine.  Is that a normal 
behavior?  (I ran on z/OS 2.2! Ze'ev Atlas

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

Re: Is there a source for detailed, instruction-level performance info?

[Jerry Callen]

Charles Mills wrote:

> I would assume there is some sort of a compiler/hardware architecture
> liaison group within IBM. I would bet that if someone from that group were
> to put together a SHARE presentation called "Write Machine Code Like a
> Compiler -- How to Write the Fastest Code Possible for the z13 (z14,
> whatever)" that it would be a big hit.

I second that!

Bob Rogers (no longer at IBM...) ran a series of "How Do You Do What You Do 
When You're a (z10/z196/z13) CPU?" sessions over the years. But they were more 
focused on overall characteristics of the system, not on specifically how an 
assembly language programmer can best exploit the hardware. A session that 
presumes that background knowledge and really gets down into the weeds would be 
great. And maybe follow it up with a BOF for assembly weenies to address 
specific questions.

How about it, IBM? Surely there must be someone Poughkeepsie who wants to visit 
San Antonio in March? :-)

-- Jerry

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

Re: Rexx and member statistics question

[Paul Gilmartin]

On Wed, 30 Dec 2015 14:49:04 -0800, Charles Mills wrote:

>Let's see if I have this right.
>
>You EXECIO DISKR a PDS member into stem INPUT.
>
>You then attempt to write it out using EXECIO DISKW * from stem INPUT. The 
>write fails unless the member has ISPF statistics.
>
>However, EXECIO DISKW INPUT.0 succeeds.
>
>Do I have that right? If so, no, that sounds wrong to me.
>
It's documented that if a count is specified, that number of lines is written
from STEM.

If count is given as "*", writing terminates at the first null member of STEM.

Now, I'll conjecture:

If the member has ISPF statistics, it was probably created by ISPF EDIT, and
ISPF will never write an empty record.

If the member lacks ISPF statistics, it was probably created other than by
ISPF EDIT and may contain empty members.  The write will terminate at
the first empty line.

Bad design.  It would be better, when count is "*" to write until a DROPped
line of STEM. is encountered.

What happens if STEM.0 exceeds the number of defined lines of the compound?

What happens if count is "*", but a DROPed line is encountered before
an empty line?

All in all, a bad hangover from CMS which does not support empty records in
MDFS or SFS.

-- gil

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

Re: Rexx and member statistics question

[Charles Mills]

> to write until a DROPped line of STEM. is encountered.

My Rexx reference says "When EXECIO writes an arbitrary number of lines from a 
list of compound
variables, it stops when it reaches a null value or an uninitialized variable 
(one
that displays its own name)."

> What happens if STEM.0 exceeds the number of defined lines of the compound?

My Rexx reference says "The 0th variable has no effect on controlling the 
number of lines written from
variables."

But a good conjecture (that or something similar) on the OP's problem.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, December 30, 2015 3:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Rexx and member statistics question

On Wed, 30 Dec 2015 14:49:04 -0800, Charles Mills wrote:

>Let's see if I have this right.
>
>You EXECIO DISKR a PDS member into stem INPUT.
>
>You then attempt to write it out using EXECIO DISKW * from stem INPUT. The 
>write fails unless the member has ISPF statistics.
>
>However, EXECIO DISKW INPUT.0 succeeds.
>
>Do I have that right? If so, no, that sounds wrong to me.
>
It's documented that if a count is specified, that number of lines is written 
from STEM.

If count is given as "*", writing terminates at the first null member of STEM.

Now, I'll conjecture:

If the member has ISPF statistics, it was probably created by ISPF EDIT, and 
ISPF will never write an empty record.

If the member lacks ISPF statistics, it was probably created other than by ISPF 
EDIT and may contain empty members.  The write will terminate at the first 
empty line.

Bad design.  It would be better, when count is "*" to write until a DROPped 
line of STEM. is encountered.

What happens if STEM.0 exceeds the number of defined lines of the compound?

What happens if count is "*", but a DROPed line is encountered before an empty 
line?

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

Re: Is there a source for detailed, instruction-level performance info?

[Charles Mills]

Or possibly in Toronto!

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jerry Callen
Sent: Wednesday, December 30, 2015 3:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there a source for detailed, instruction-level performance info?

Charles Mills wrote:

> I would assume there is some sort of a compiler/hardware architecture 
> liaison group within IBM. I would bet that if someone from that group 
> were to put together a SHARE presentation called "Write Machine Code 
> Like a Compiler -- How to Write the Fastest Code Possible for the z13 
> (z14, whatever)" that it would be a big hit.

I second that!

Bob Rogers (no longer at IBM...) ran a series of "How Do You Do What You Do 
When You're a (z10/z196/z13) CPU?" sessions over the years. But they were more 
focused on overall characteristics of the system, not on specifically how an 
assembly language programmer can best exploit the hardware. A session that 
presumes that background knowledge and really gets down into the weeds would be 
great. And maybe follow it up with a BOF for assembly weenies to address 
specific questions.

How about it, IBM? Surely there must be someone Poughkeepsie who wants to visit 
San Antonio in March? :-)

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

Re: Multiprise 3000 internal DASD hardware issues

[Tony Harminc]

On 28 December 2015 at 20:36, Mike Ross  wrote:
> I'm bringing up an old Multiprise 3000 - 7060-30. For fun and
> education rather than production needless to say!

Is this my old MP3000, or did you get another one? If it's the one
from here, I'm sure I have some stuff on its original configuration,
and the disk upgrade that was done, iirc.

Tony H.

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

questions about converting CA-MIM to IBM GRS RNL

[Mowry, Norma E CIV DISA (US)]

We are in the process of planning to convert our current CA-MIM to IBM GRS
RNS with GRS running STAR mode, tape is not an issue.  I'm looking for
documentation that will help with converting CA-MIM to GRSRNLs.  I did
search google and found some things that were old, was hoping to find
something more recent.

Thanks

Norma Mowry

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

Rexx and member statistics question

[Ze'ev Atlas]

Hi AllI have a Rexx program and here is the relevant snippet:
THEMEMBER = THEPDS || "(" || MEMBER || ")"       /*say themember */             
                  "alloc shr file(input) dataset(" THEMEMBER ")"   "execio * 
diskr input (stem input. finis)"       IF RC \= 0 THEN                          
           call DIE 'READ MEMBER failed' RC              say member input.0 
"LINES READ"                  "free file(input)"                               
"EXECIO" input.0 "DISKW XXOUT (STEM INPUT."      IF RC \= 0 THEN                
                     call DIE 'WRITE MEMBER failed' RC             
Originally, I had "EXECIO * DISKW XXOUT (STEM INPUT."  
but that would work only for members that had statistics (i.e. have been 
updated).  When I changed the '*' to input.0 it works fine.  Is that a normal 
behavior?  (I ran on z/OS 2.2! Ze'ev Atlas


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

AW: Re: Experience with ADRDSSU patch X'54' to enable usage of Catalog Search INterface (CSI)

[Peter Hunkeler]

>But a search in IBMLINK for the APAR cited yields a number of hits, one of 
>which is info APAR II14616 .

I was pointed to this and other APARs by a colleague after I posted here. The 
net as I understand now is:
o The new, optional function was introduced with an APAR in z/OS V1.9. The 
default was left to be to old behaviour.
o IBM decided to change the default to the new function (CSI) with z/OS V1.11
o Later, problems were reported with the new function. IBM decided to change 
the default back to the old behaviour via APAR on z/OS V1.11 and V1.12. z/OS 
V2.1 was delivered with the old behaviour being the default.

Very confusing if you read the manual at different z/OS levels. The value X'00' 
for the patch byte sometimes means old behaviour, sometimes new behaviour. Not 
nice.


No matter what the default is, I'd like to hear what anyone having used the new 
function (CSI) can tell.



--Peter Hunkeler




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

Re: Is there a source for detailed, instruction-level performance info?

[Charles Mills]

I would assume there is some sort of a compiler/hardware architecture
liaison group within IBM. I would bet that if someone from that group were
to put together a SHARE presentation called "Write Machine Code Like a
Compiler -- How to Write the Fastest Code Possible for the z13 (z14,
whatever)" that it would be a big hit.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jim Mulder
Sent: Monday, December 28, 2015 9:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there a source for detailed, instruction-level performance
info?

> An example: which of these code sequences do you suppose runs faster?
> 
>  la rX,0(rI,rBase)   rX -> array[i]
>  lg rY,0(,rX)rY = array[i]
>  agsi 0(rX),1++array[i]
> * Now do something with rY
> 
> vs:
>  lg rY,0(rI,rBase)   rY = array[i]
>  la rX,1(,rY)rX = rY + 1
>  stg rX,0(rI,rBase)  effect is ++array[i]
> * Now do something with rY
> 
> The first is substantially faster. I would have GUESSED that the 
> second would be faster, since I need the value in rY anyway. (I'm in 
> 64-bit mode, so using "LOAD ADDRESS for the increment is safe...)

  "Substantially faster" is probably a cache effect.  Assuming a cache miss
on array[i], in sequence 2, the LG will miss and install the cache line
shared, and then the STG will need to do an upgrade to exclusive.  The AGSI
in sequence 1 will miss and install the cache line
exclusive, avoiding the upgrade to exclusive.   Adding a PFD 2,0(rI,rBase)
before the LG in sequence 2 may make these sequences perform similarly.

 Also, in sequence 1, changing lg rY(0(,Rx) to lg rY,0(rI,rBase)  may avoid
some Address Generation Interlock effects (although various machines have
various AGI bypasses for various instructions).  And it may just transfer
some of the AGI effect from the LG down to the AGSI. 

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

Re: Rexx and member statistics question

[Ze'ev Atlas]

You have it right
There is no error message, the lines are just not written!
ZA

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

Re: Rexx and member statistics question

[Walt Farrell]

On Wed, 30 Dec 2015 19:03:22 -0600, Ze'ev Atlas  wrote:

>You have it right
>There is no error message, the lines are just not written!

Perhaps you should display the contents of the input. stem variable before the 
EXECIO WRITE statement. That may give you (or us) a clue to what's happening.

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

Re: Rexx and member statistics question

[Paul Gilmartin]

On Wed, 30 Dec 2015 19:03:22 -0600, Ze'ev Atlas wrote:

>You have it right
>There is no error message, the lines are just not written!
>ZA
>
WAD.  Did your input contain empty records?

HEX on in ISPF BROWSE (*not* VIEW; *not* EDIT) will manifest empty records.
A dismaying example:

RC = BPXWDYN( 'alloc dsn('userid()'.TEMP.NULLS) shr rtddn(DD) msg(WTP)' )
line.1 = 'First '
line.2 = ''
drop line.3  /* WTF!?  */
line.4 = 'Fourth.'
address 'MVS' 'EXECIO 4 DISKW' DD '(finis stem LINE.'

creates (note line 3!):

 Top of Data ***

.

.
 ---
First   
.
C89AA4  
.
699230  
.
 -

.

.

.
 -
LINE.3  
.
DCDC4F  
.
3955B3  
.
 -
Fourth. 
.
C9A9A84 
.
664938B 
.
 -
*** Bottom of Data ***

IIRC:
o CMS filesystems do not support empty records (possibly excepting
  the new-fangled BFS.)
o CMS EXEC2 does not distingushed uninitialized variables from
  variables set to null string.

It appears that EXECIO on z/OS attempts to emulate the worst design features
of EXEC2 on CMS.

Rexx on CMS lately supports Rexx standard I/O.  Rexx on z/OS is hardly there 
yet:
o I believe compiled Rexx supports Rexx standard I/O. but only for legacy data 
sets.
o Rexx under OMVS has a function package for much of Rexx standard I/O,
  but only for UNIX files, and it does not provide SIGNAL ON NOTREADY.

Sigh,
gil

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

Re: Rexx and member statistics question

[Ze'ev Atlas]

I have to take it back
In one of the libraries, I consistently have an empty line as the first line 
and I did do some of my tests on that library.
Mystery resolved!

Thank you all

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

Experience with ADRDSSU patch X'54' to enable usage of Catalog Search INterface (CSI)

[Peter Hunkeler]

I'm chasing a problem where some ADRDSSU dump jobs are holding the catalog 
enqueue SYSIGGV2 for an unexcted long time. The jobs specify a couple of 
generic dsn specifications in the INCLUDE clause.


I found APAR OA25644 from 2009 which introduces the choice to tell ADRDSSU to 
use the Catalog Search Interface (CSI) instead of Generic Catalog Locates to 
search for data set matching the INCLUDE mask. The new function is enabled via 
PATCH area, offset X'54'.


Has anyone enabled the CSI interface by patching ADRDSSU? Any expecience you're 
willing to share?




--
Peter Hunkeler

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