Re: In-depth tutorials on using ASMIDF?

[Philippe Cloarec]

Did send an email to Peter...with some documents I did write using that tool.

Re: Rif: Re: EXECUTE Instruction and location of its target instruction

[Philippe Cloarec]

Hi Steve,

Thx for the input.  Right.   Yes, I know about the idea to have a macro to 
align to a 256 bytes boundary. 

Philippe

Re: Rif: Re: EXECUTE Instruction and location of its target instruction

[Philippe Cloarec]

Hi Paul,

Thx much for the input.  

ref:Is LOCTR a help? 
Actually, I got nicely some  infos from Martin T,  about LOCTR possible use in 
such case, this can be found at 
http://www.pi-sysprog.de/free/makerel.html  

Philippe 

Re: EXECUTE Instruction and location of its target instruction

[Philippe Cloarec]

Hi Abe, 
Very good point, about old processors.  Thx much Philippe

Re: EXECUTE Instruction and location of its target instruction

[Philippe Cloarec]

Hi Steve,
Thx for the additional infos relating some similar experience you got.  Philippe

Re: Rif: Re: EXECUTE Instruction and location of its target instruction

[Philippe Cloarec]

Hi Aldo, 
Thx much for the input. Unfortunately I cannot for that project to implement 
Baseless processing therefore I cannot use EXRL instruction.   Point is to keep 
the target of the execute is in a I-bank cache line, to be ok.  
regards Philippe 

Re: EXECUTE Instruction and location of its target instruction

[Philippe Cloarec]

Hi Steve,
Thx for your input, yes this is my understanding of the process.  
Philippe

Re: EXECUTE Instruction and location of its target instruction

[Philippe Cloarec]

Martin,

Thx for the input.  Unfortunately for current project I am working on, to 
convert old asm programs to Baseless processing is NOT an option, there is no 
time and no budget to :) . 

Later
Philippe 

Re: EXECUTE Instruction and location of its target instruction

[Philippe Cloarec]

Hi Rob,

ref:It's in the same cache line or it's not.

Actually this was exactly my point and I was confused about seen various coding 
approaches to reach that purpose to optimize
as much as possible CPU use.

later 

Philippe

EXECUTE Instruction and location of its target instruction

[Philippe Cloarec]

Hi,

My understanding is, we should keep as closest as possible, the EXECUTE 
instruction and its target instruction...EXECUTE instruction being  greedy 
enough in term of CPU use...to be clear dozens of Cycles needed to complete its 
execution.

Reviewing old Assembler programs, I guess I am surprised to see enough often 
that all target instructions for ALL the Execute instructions coded in the 
programs grouped mostly at the end...

Sometimes I can see offset between EXECUTION and its Target instruction to be 
enough BIG like below!!:
>
001214 4490 B94201942  1142EXR9,LIBCLE2
..
..
001942 D200 BC76 BD3F 01C76 01D3F  1607 LIBCLE2  MVC   SCLE2(0),ZONLIB
>

I did read many articles, and read often EX should be closed to Target 
instruction but no recommendation in term of offset between both elements ?!?  
From my humble understanding, more far is the Target instruction from EX one 
more costly will be its execution - right ? ; So knowing dozens of Cycles is 
"normally" required to complete one EX instruction, actually to change the 
program to minimize the offset between EX and its Target instruction CAN 
GREATLY reduce CPU use by comparaison with previous code - right ? 

Thx in advance for  input you may have.  regards Philippe 

Re: z/OS Bug Busterz SHARE Academy in San Jose

[Philippe Cloarec]

No way to register, by clicking on URL...not found  lol

On Wed, Nov 16, 2016 at 4:51 PM, Ed Jaffe 
wrote:

> The z/OS Bug Busterz SHARE Academy in Atlanta was a tremendous success,
> but there was room for more attendees.
>
> Many folks complained to me throughout the week that they didn't hear
> about this amazing, Sunday deep-dive intensive until _after_ their travel
> plans were already made and asked if it could be offered again at a future
> SHARE event.
>
> Based on this demand, we've been given the go ahead to repeat this
> incredible offering at SHARE in San Jose!
>
> This time it's being announced well in advance, so people have adequate
> time to register and plan their trips accordingly.
>
> http://www.share.org/san-jose-academy-zos?utm_source=prospec
> tiveattendee_content=academy
>
> "Back by popular demand! The SHARE Academy z/OS Bug Busterz class is
> presented by experienced z/OS Level 2 professionals and will provide you
> with the skills to analyze and make sense of diagnostic data captured by
> z/OS. You will gain the knowledge necessary to perform preliminary analysis
> of dumps and trace data using IPCS, and learn how to capture information
> through diagnostic tools, including GTF trace, CTRACE and SLIP. The class
> is designed for z/OS Systems Programmers and Application Programmers that
> support products running on z/OS, and will include a pre-event webcast. No
> prior IPCS experience is required."
>
> NOTE: There is great demand across the various SHARE Programs for Sunday
> SHARE Academy deep-dive showcase placement, so it's unlikely we'll be
> repeating z/OS Bug Busterz again after San Jose. If you or someone else at
> your company wants to take advantage of this training, this is your chance!
>
>
> --
> Edward E Jaffe
> Phoenix Software International, Inc
> 831 Parkview Drive North
> El Segundo, CA 90245
> http://www.phoenixsoftware.com/
>

Re: SIIS "issue" after upgrade to z13 machine.

[Philippe Cloarec]

Hi Pieter, 
Yes I did figure out that to use  of MF=E/L or SF=E/L will help to avoid the 
SIIS scenario for IBM Macros.
Thx much for your input have a good day Philippe

Re: SIIS "issue" after upgrade to z13 machine.

[Philippe Cloarec]

Hi John, 
Thx much for your input.  Yes, I was planning to use newer instructions but I 
did realize seeing current design of the applications I am reviewing this will 
generate some extra needed time to be sure all is ok and  I cannot afford this 
in current context.  To implement Baseless pgm or HLASM for readibility purpose 
would have been great but here as well no time and related resources, data and 
people to redo some tests for applications changed, and for sure there is no 
budget for this :) . 
Yes, I was aware of the point related to needed alignment to a 256 bytes 
boundary and for some options at Linkedit time to ensure alignement. 
Beside User Code, I have to check all macros including IBM ones...for SIIS 
occurences.  We can change User macros code but I am not sure IBM does plan to 
fix SIIS cases for delivered macros on a short timeframe or even ever.  You 
have also the case of User macro including IBM ones behalf its code.  I was 
giving some arbitrary list of programs to review and I do NOT have at the time 
the listings but the source code only.  Basically SIIS audit phase may be 
larger and time consuming than expected I will inform involved people in the 
project for this point.  Have a great day, regards Philippe 

Re: SIIS "issue" after upgrade to z13 machine.

[Philippe Cloarec]

Apparently this is needed for some...sure SIIS is NOT new for sure, BUT 
performance issue was obviously revealed after upgrade
to a z13, please do read documents referenced in previous updates.  Have a good 
evening.

Re: SIIS "issue" after upgrade to z13 machine.

[Philippe Cloarec]

Hi Rob and Martin, 
Thx for your input.  MY primary purpose is to detect SIIS scenarios across code 
I have to scan and to fix them.  Code is not complicated I mean you do have 
basic i/o processing against files and some characters and numerics fields are 
processed.
There are some Ex(ecute) instructions to review..and some Save_areas fields 
setting to review as well.   Yes, macros used should
be reviewed...Save_areas setting...Yes IBM ones or use of them should be 
reviewed as well.   
I will be careful when changing some code, I mean at instruction level  to 
optimize current code.   Thx much for your recommendations.   TTYL  Philippe

Re: SIIS "issue" after upgrade to z13 machine.

[Philippe Cloarec]

Hi Martin and Rob, 

First thx much for your input.  Here are 3 links which relate the "issue" and 
common code for which we fall into a SIIS scenario:
https://www.google.fr/#q=istream_flash_062606_v4
http://s3-us-west-1.amazonaws.com/watsonwalker/ww/wp-content/uploads/2016/03/06173415/18017-The-Cheryl-and-Frank-zRoadshow.pdf
http://conferences.gse.org.uk/attachments/presentations/ibHo4j_1446285934.pdf

Unfortunately I have more than 1000 pgms to review and handle on a short 
timeframe,  so I will have no time to implement "Baseless  processing".   I do 
plan to SAK(Search And Kill) SIIS occurences for scenarios described in above 
links I will find   and implement newer instructions as immediate ones  to 
eliminate memory references and constants in storage as well. 

I will check cases where two instructions can be replaced by one only...to use 
CIJE in place of LTR/BZ combination as for example.   

Since we do talk of CPU cycles savings here I will check for AGI cases and 
their resolution and try to implement instruction grouping as much I can. 

From my humble point this is a real topic and all z13 sites having old 
productions Batch programs should perform some action.

regards
Philippe 

SIIS "issue" after upgrade to z13 machine.

[Philippe Cloarec]

Hi,
As you may know, there is some kind of performance issue because of SIIS(Store 
Into Instruction Stream) after upgrade to a z13 machine in some scenarios.  CPU 
increase of 30% can be seen in some case, so it may be good to perform to 
related changes to avoid issue from reoccuring.  Did start to work on this case 
since some time.   Here we do talk of code written years ago, hundreds of 
programs for which there is no time to rewrite them as RENT, so I am interested 
to talk with any having some experience about this.   More generally, dealing 
with old even old code, I would like to change the code beside SIIS case to 
improve the performance  at execution time.   I mean by using newer 
instructions and optimizing the code to save some CPU cycles.  Did find some 
interesting documents but wanting to discuss of any scenario we can think 
about.   TTYL then. Philippe   (philippe.cloa...@gmail.com)